Skip to content

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

Open
wants to merge 12 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 7 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions control_msgs/CMakeLists.txt
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,8 @@ set(msg_files
msg/JointJog.msg
msg/JointTolerance.msg
msg/JointTrajectoryControllerState.msg
msg/JointWrenchTrajectory.msg
msg/JointWrenchTrajectoryPoint.msg
msg/MecanumDriveControllerState.msg
msg/MultiDOFCommand.msg
msg/MultiDOFStateStamped.msg
Expand All @@ -39,6 +41,7 @@ set(action_files
action/FollowJointTrajectory.action
action/GripperCommand.action
action/JointTrajectory.action
action/FollowJointWrenchTrajectory.action
action/PointHead.action
action/SingleJointPosition.action
)
Expand Down
54 changes: 54 additions & 0 deletions control_msgs/action/FollowJointWrenchTrajectory.action
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
# The joint trajectory to follow
control_msgs/JointWrenchTrajectory trajectory

# Tolerances for the trajectory. If the measured joint values fall
# outside the tolerances the trajectory goal is aborted. Any
# tolerances that are not specified (by being omitted or set to 0) are
# set to the defaults for the action server (often taken from the
# parameter server).

# Tolerances applied to the joints as the trajectory is executed. If
# violated, the goal aborts with error_code set to
# PATH_TOLERANCE_VIOLATED.
control_msgs/JointTolerance[] path_tolerance

# To report success, the joints must be within goal_tolerance of the
# final trajectory value. The goal must be achieved by time the
# trajectory ends plus goal_time_tolerance. (goal_time_tolerance
# allows some leeway in time, so that the trajectory goal can still
# succeed even if the joints reach the goal some time after the
# precise end time of the trajectory).
#
# If the joints are not within goal_tolerance after "trajectory finish
# time" + goal_time_tolerance, the goal aborts with error_code set to
# GOAL_TOLERANCE_VIOLATED
control_msgs/JointTolerance[] goal_tolerance
builtin_interfaces/Duration goal_time_tolerance

---
int32 error_code
int32 SUCCESSFUL = 0
int32 INVALID_GOAL = -1
int32 INVALID_JOINTS = -2
int32 OLD_HEADER_TIMESTAMP = -3
int32 PATH_TOLERANCE_VIOLATED = -4
int32 GOAL_TOLERANCE_VIOLATED = -5
int32 TRAJECTORY_ABORTED = -6
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please add a description to TRAJECTORY_ABORTED (this is new compared to FollowTrajectory action)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also add PREEMPTED or it doesn't make sense?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added TRAJECTORY_ABORTED as a general message to cover most (if not all) possible reasons a trajectory might be aborted. The idea is that the specific reason can go in the error_string field.
Does that sound reasonable to you?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aborted is when the goal is aborted by the controller itself right?
Is preempted somehow handled in ROS 2 actions?. I'm not sure about it. If it is handled. All good

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aborted is when the goal is aborted by the controller itself right?

Yes, TRAJECTORY_ABORTED indicates that the trajectory was aborted by the controller.

Regarding preemption in ROS 2 actions: from what I’ve seen, existing action messages don’t explicitly handle preemption using an error code. This is the first message to introduce an error code like TRAJECTORY_ABORTED as a general indicator of an aborted trajectory. That said, new controllers can choose to use this error code if other codes don’t suit their case.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok 👍


# Human readable description of the error code. Contains complementary
# information that is especially useful when execution fails, for instance:
# - INVALID_GOAL: The reason for the invalid goal (e.g., the requested
# trajectory requires a command that differ significantly from the
# robot's current state).
# - INVALID_JOINTS: The mismatch between the expected controller joints
# and those provided in the goal.
# - PATH_TOLERANCE_VIOLATED and GOAL_TOLERANCE_VIOLATED: Which joint
# violated which tolerance, and by how much.
string error_string

---
std_msgs/Header header
string[] joint_names
control_msgs/JointWrenchTrajectoryPoint desired
control_msgs/JointWrenchTrajectoryPoint actual
control_msgs/JointWrenchTrajectoryPoint error
10 changes: 10 additions & 0 deletions control_msgs/msg/JointWrenchTrajectory.msg
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
# The header is used to specify the reference time for the trajectory durations
std_msgs/Header header

# The names of the active joints in each trajectory point. These names are
# ordered and must correspond to the values in each trajectory point.
string[] joint_names

# Array of trajectory points, which describe the joint positions, velocities,
# accelerations and/or efforts, and task space wrenches at each time point.
control_msgs/JointWrenchTrajectoryPoint[] points
7 changes: 7 additions & 0 deletions control_msgs/msg/JointWrenchTrajectoryPoint.msg
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
# A joint-wrench trajectory point defines joint positions, joint velocities, joint accelerations, joint efforts, and a task space wrench, typically used by controllers.
# Note: The time_from_start field is included in the joint trajectory point.
trajectory_msgs/JointTrajectoryPoint point

# The wrench is expressed in this reference frame.
string wrench_frame
geometry_msgs/Wrench wrench
Comment on lines +6 to +7
Copy link
Member

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
string wrench_frame
geometry_msgs/Wrench wrench
geometry_msgs/WrenchStamped wrench

Copy link
Author

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.

Copy link
Member

@saikishor saikishor Jul 14, 2025

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

Copy link
Contributor

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?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Introducing a new message like WrenchFramed could be a valid solution to keep the information together and avoid duplicating headers.
Let me know if this will be on the agenda for the Wednesday PMC meeting.

Copy link
Member

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

Copy link
Author

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WrenchFramed

Copy link
Author

@my-rice my-rice Jul 17, 2025

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 WrenchFramed message as part of this PR, or submit it in a separate one?

  • Should WrenchFramed be added to the control_msgs package or another one?

Loading