PoseStamped instead of TransformStamped for Cartesian space positions

[kschwan]

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:

• TransformStamped "is mostly used by the tf package".
• Basically, tools like RViz expect an array with a hierarchy of transforms which gets published by, e.g., robot_state_publisher. Typically not at a very high frequency.
• TransformStamped has a child_frame_id field, which implies that it "specifies a transform from the header's frame_id to child_frame_id" (again, a hierarchy of transforms). PoseStamped only has a frame_id which makes more sense for representing end-effector poses that are given in, e.g., the robot's base_link frame.
• PoseStamped is immediately visualizable in RViz, while TransformStamped has to be displayed via. 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

[adeguet1]

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?

[pkazanzides]

I am fine with that change.

[melodysu83]

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>.

[adeguet1]

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 _cp commands instead of using the client libraries (devel branches and upcoming releases).

Regarding the documentation (https://github.com/collaborative-robotics/documentation/wiki/Robot-API-motion). Should I:

• just replace TransformStamped by PoseStamped and remove all references to TransformStamped
• 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.