Closed kschwan closed 1 year ago
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?
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 https://github.com/collaborative-robotics/documentation/issues/1#issuecomment-984155975, 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.
I have pushed some code related to this issue to a few repositories:
_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:
TransformStamped
by PoseStamped
and remove all references to TransformStamped
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
.
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_id
field, which implies that it "specifies a transform from the header'sframe_id
tochild_frame_id
" (again, a hierarchy of transforms). PoseStamped only has aframe_id
which makes more sense for representing end-effector poses that are given in, e.g., the robot'sbase_link
frame.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