Feature/joint wrench msgs#221
Conversation
- [REF] Modified old organization of the message to introduce only two message definitions: JointWrenchTrajectory and JointWrenchTrajectoryPoint - [REF] Adjust CMakeLists.txt to adapt to the new changes
…oryPoint messages
…to feature/joint_wrench_msgs
…intWrenchTrajectory.action
christophfroehlich
left a comment
There was a problem hiding this comment.
Thanks the addition. I have some minor comments
Co-authored-by: Christoph Fröhlich <christophfroehlich@users.noreply.github.com>
…sistent formatting. Co-authored-by: Christoph Fröhlich <christophfroehlich@users.noreply.github.com>
|
@christophfroehlich I implemented all the requested changes. |
| string wrench_frame | ||
| geometry_msgs/Wrench wrench |
There was a problem hiding this comment.
Can we use the WrenchStamped here instead?
There was a problem hiding this comment.
| string wrench_frame | |
| geometry_msgs/Wrench wrench | |
| geometry_msgs/WrenchStamped wrench |
There was a problem hiding this comment.
If we use WrenchStamped here instead of Wrench + wrench_frame, the message would end up with two headers, each containing its own timestamp (one inside the JointTrajectoryPoint and another inside the WrenchStamped field). Generally, I’d expect users of this message to assume that the wrench and the JointTrajectoryPoint are synchronized, meaning they share the same timestamp.
There was a problem hiding this comment.
I agree with you, but I'm not sure about separating it as a wrench_frame_id. It should belong within the same context in my opinion. I understand your point on using stamped, but I'm not convinced with the current variable naming and usage.
Any other proposals? Or thoughts? @my-rice @christophfroehlich
There was a problem hiding this comment.
I understand your point, but would be happy with the current approach as well.
To avoid duplicate header, we could add another layer with a WrenchFramed message?
There was a problem hiding this comment.
Yes!
Let's discuss in the PMC Meeting
There was a problem hiding this comment.
Ok, I wrote an item in the 'New Business' section of the agenda. Feel free to revise it or move it to a different section.
There was a problem hiding this comment.
@saikishor as we discussed in yesterday’s PMC meeting, the proposed solution is to introduce the WrenchFramed message. This would allow us to encapsulate both the wrench_frame_id and the wrench itself in a structured layer.
I have two questions about this:
-
Should I introduce the
WrenchFramedmessage as part of this PR, or submit it in a separate one? -
Should
WrenchFramedbe added to thecontrol_msgspackage or another one?
There was a problem hiding this comment.
Please add it in the same PR in this repository.
|
Hey @saikishor, have you had a chance to review the updates on this PR? |
Hey @my-rice |
saikishor
left a comment
There was a problem hiding this comment.
I left some comments. Please take a look
@saikishor No worries at all. Thanks for getting back to me.
I believe I have responded to all of your comments on the PR. |
…to feature/joint_wrench_msgs
Co-authored-by: Sai Kishor Kothakota <saisastra3@gmail.com>
This PR introduces joint trajectory messages with task space wrench as described in issue #284. In particular, the following message definitions are added:
JointWrenchTrajectory.msgJointWrenchTrajectoryPoint.msgIn addition to these messages, the corresponding action definition,
FollowJointWrenchTrajectory.action, has also been created.To avoid repeating code, I reused
trajectory_msgs/JointTrajectoryPointwhere possible. I am not completely sure if this was the best approach, so I am open to feedback on that.