Revision history [back]

I'm not aware of any standardised messages for this specifically.

JointState is indeed for reporting state. Not for commanding it.

For trajectory(-like) interfaces, we have JointTrajectory (and the related FollowJointTrajectory action).

I've seen authors accept JointTrajectoryPoint, but the disadvantage of that message is that it does not contain a names field (or something similar), which obviously means you have no way of checking any semantics of the incoming data.

Other nodes accept Float64MultiArray, but that's obviously less than ideal as well as it has almost no semantics whatsoever (except perhaps "here is a bunch of float numbers in a list). ros_control is a good example of a context where that message is used, but see ros2_controllers#157 where they recognise they need something else (similar to your question really).

Yet another alternative: accept JointTrajectory instances, but limit them to a maximum length of two (or one). While somewhat strange, this solves the problem of not having access to the targetted joint names, while also using something which has been traditionally used for commanding new state. It's also a nice intermediary between trajectory-based control interfaces and position-streaming ones (with trajectory-replacement allowing for even more gradual changing between the two).

On the Cartesian side, I've seen geometry_msgs/Pose (or PoseStamped of course) and even plain Point being used. It's slightly easier here, as the dimensionality of the message corresponds directly to the number of degrees of freedom of the mechanism being controlled, so there is less need for a names field to help interprete the data.

The FZI: Cartesian Interface in ROS project took that a bit further and designed a complete set of messages for Cartesian (position/velocity/etc) control of ROS robots, which resulted in cartesian_control_msgs. That's not in ROS 2 right now though (and doesn't directly address your need).

I'm not aware of any standardised messages for this specifically.

JointState is indeed for reporting state. Not for commanding it.

For trajectory(-like) interfaces, we have JointTrajectory (and the related FollowJointTrajectory action).

I've seen authors accept JointTrajectoryPoint, but the disadvantage of that message is that it does not contain a names field (or something similar), which obviously means you have no way of checking any semantics of the incoming data.

Other nodes accept Float64MultiArray, but that's obviously less than ideal as well as it has almost no semantics whatsoever (except perhaps "here is a bunch of float numbers in a list). ros_control is a good example of a context where that message is used, but see ros2_controllers#157 where they recognise they need something else (similar to your question really).

Yet another alternative: accept JointTrajectory instances, but limit them to a maximum length of two (or one). While somewhat strange, this solves the problem of not having access to the targetted joint names, while also using something which has been traditionally used for commanding new state. It's also a nice intermediary between trajectory-based control interfaces and position-streaming ones (with trajectory-replacement allowing for even more gradual changing between the two).

On the Cartesian side, I've seen geometry_msgs/Pose (or PoseStamped of course) and even plain Point being used. It's slightly easier here, as the dimensionality of the message corresponds directly to the number of degrees of freedom of the mechanism being controlled, controlled (we only have 3 dimensions of space ..), so there is less need for a names field to help interprete the data.

The FZI: Cartesian Interface in ROS project took that a bit further and designed a complete set of messages for Cartesian (position/velocity/etc) control of ROS robots, which resulted in cartesian_control_msgs. That's not in ROS 2 right now though (and doesn't directly address your need).