-
Notifications
You must be signed in to change notification settings - Fork 77
Feature/joint wrench msgs #221
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
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks the addition. I have some minor comments
Co-authored-by: Christoph Fröhlich <[email protected]>
…sistent formatting. Co-authored-by: Christoph Fröhlich <[email protected]>
|
@christophfroehlich I implemented all the requested changes. |
christophfroehlich
left a comment
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.
LGTM
| string wrench_frame | ||
| geometry_msgs/Wrench wrench |
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.
Can we use the WrenchStamped here instead?
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.
| string wrench_frame | |
| geometry_msgs/Wrench wrench | |
| geometry_msgs/WrenchStamped wrench |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes!
Let's discuss in the PMC Meeting
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WrenchFramed
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.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
saikishor
left a comment
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.
Rest looks good to me :)
Co-authored-by: Sai Kishor Kothakota <[email protected]>
saikishor
left a comment
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.
LGTM
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.