-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds ARROW_STRIP to Marker.msg #218
Adds ARROW_STRIP to Marker.msg #218
Conversation
eed9561
to
a2bba62
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for merging into rolling
I think it's safe for backporting too. Publishing of newer data to older implementations will break parsing (hopefully with an unknown datatype type of error) . That should gracefully degrade. If anyone knows of another case we should look into that more if there's strong interest in backporting. I suspect that backporting it will depend on the complexity of the relevant rviz pull request complexity.
30b68e8
to
a848561
Compare
Thanks @tfoote I've added a "currently unimplemented" comment for clarity. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that in order to move forward with this, we'd also want an implementation of the RViz change for RViz2. Then we can remove the unimplemented
comment here and merge the two of them together.
Makes sense. I should have time this week to raise a PR with rviz2. Will update this PR when merged |
Removed the unimplemented comment as the rviz2 PR is underway. In particular, it's waiting on whether the CI for that repo supports compiling against unmerged branches (i.e. this one) in the same way rviz1 does. If that's not possible, would you be happy for us to reverse the order of the merges? i.e. common_interfaces -> rviz? |
Signed-off-by: Tom Noble <[email protected]>
Signed-off-by: Tom Noble <[email protected]>
Signed-off-by: Tom Noble <[email protected]>
Use format codes instead of ambiguous names. Signed-off-by: Christian Rauch <[email protected]> Signed-off-by: Tom Noble <[email protected]>
Signed-off-by: Chris Lalancette <[email protected]> Signed-off-by: Tom Noble <[email protected]>
Signed-off-by: Tom Noble <[email protected]>
Signed-off-by: Yadunund <[email protected]> Signed-off-by: Tom Noble <[email protected]>
Signed-off-by: Tom Noble <[email protected]>
fb2264a
to
2034705
Compare
@clalancette are you happy with this PR ? |
@rr-tom-noble this PR has some conflicts, can you solve it ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be rebased onto the latest, and all changes to files except for Marker.msg
dropped. Then this will be a lot closer to be ready to merge (though I think we should wait for ros2/rviz#972 to be ready before we do that).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mind to rabse this with rolling
?
There are many changes not related with this PR
I've rebased this onto rolling in #242 Closing this as superseded. |
ROS2 version of this PR: ros/common_msgs#190
I won't have a chance to work on the Rviz PR to implement the
ARROW_STRIP
functionality for ROS2 until next month (April), so I suppose we can either leave this PR open until then, or merge with a "currently unimplemented" comment.I've changed the description above the
points
field to include the new type, but have left thecolours
field unchanged as (at least in the ROS1 version of the Rviz PR) this functionality was unimplemented forARROW_STRIP
.