Repository navigation
PoseStamped instead of TransformStamped for Cartesian space positions #1
Copy link
Copy link
Closed
Description
Activity
Agreed. One of our heavy ROS user made a similar comment a while back. This will break users's code since the payload will change. So if we get a consensus for this change (@pkazanzides @blake5634 @melodysu83), I'd like to keep this in the devel branch until we get to a proper release (2.1?). Should we synchronize this with the next round of Raven, dVRK, CRTK ROS2... releases?
Reacted by Kim Lindberg Schwaner
I am fine with that change.
Thanks for monitoring the new GitHub issue!
That makes a lot of sense to me.
best,
Melody
…--
Yun-Hsuan (Melody) Su
Assistant Professor of Computer Science
Mount Holyoke College
Email: ***@***.***
Office: Clapp 222
Phone: (413) 538-3468
On Wed, Dec 1, 2021 at 6:36 PM Anton Deguet ***@***.***> wrote:
Agreed. One of our heavy ROS user made a similar comment a while back.
This will break users's code since the payload will change. So if we get a
consensus for this change ***@***.*** <https://github.com/pkazanzides>
@blake5634 <https://github.com/blake5634> @melodysu83
<https://github.com/melodysu83>), I'd like to keep this in the devel
branch until we get to a proper release (2.1?). Should we synchronize this
with the next round of Raven, dVRK, CRTK ROS2... releases?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AETGMMCWZFBANSJEQ47D4IDUO2WQXANCNFSM5JFUEA5Q>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
added 5 commits that reference this issue on Jan 7, 2022
I have pushed some code related to this issue to a few repositories:
- ROS1 cisst/SAW CRTK bridge (device side)
- ROS1 Python and Matlab client libraries
- ROS2 cisst/SAW CRTK bridge (device side)
- ROS2 Python client library (there is no Matlab for ROS2 yet)
All cisst/SAW users (including dVRK) will need to update their code if they created their own ROS publishers/subscribers for_cpcommands instead of using the client libraries (develbranches and upcoming releases).
Regarding the documentation (https://github.com/collaborative-robotics/documentation/wiki/Robot-API-motion). Should I:
- just replace
TransformStampedbyPoseStampedand remove all references toTransformStamped - keep the old specification and add new one. If so, do we use versions for the specifications or do I just mention the date of change.
As far as I am concerned, CRTK is still a draft and not released (not 1.0 yet) so I'd be fine just replacing TransformStamped by PoseStamped.
Reacted by Kim Lindberg Schwaner
added a commit that references this issue on Apr 6, 2022
added a commit that references this issue on Apr 7, 2022
Metadata
Metadata
Assignees
Labels
No labels
Hi,
I would like to suggest a change to the CRTK specification. I know the following is a breaking change and so may not be accepted because of that.
I propose using the PoseStamped message type for representing "single" (i.e., not a heirarchy of transformations) measurements/commands in Cartesian space. My arguments for doing so:
child_frame_idfield, which implies that it "specifies a transform from the header'sframe_idtochild_frame_id" (again, a hierarchy of transforms). PoseStamped only has aframe_idwhich makes more sense for representing end-effector poses that are given in, e.g., the robot'sbase_linkframe.TFDisplay, i.e., updating the view of the whole TF transform heirarchy.My reason for asking this is that I was looking to implement the CRTK spec in our MOPS surgical system, and here I found a discrepancy.
Thanks for your consideration,
Kim