Ask Your Question

Msg type for publishing JointCommands?

asked 2021-09-26 05:44:47 -0600

ijnek gravatar image

Is there a commonly used msg type for sending JointCommands across topics?

It has been bugging me for a while that I can't seem to find something like sensor_msgs/msg/JointState.msg, but for commanding positions for multiple joints to move immediately.

I want to avoid writing a custom message if possible.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2021-09-27 02:07:35 -0600

gvdhoorn gravatar image

updated 2021-09-27 02:09:39 -0600

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 (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).

edit flag offensive delete link more


@gvdhoorn Thank you for your insight on this topic.

I feel that it would have been more natural if the joint_names[] field of JointTrajectory.msg was inside JointTrajectoryPoint.msg, but I think that design decision comes from trying to avoid having the joint_names repeated for every point in time.

Nonetheless, I think it makes sense to have a separate data type such as JointCommand.msg:

string[] names
float64[] positions
float64[] velocities
float64[] accelerations
float64[] effort

or even separate msgs for JointPositionCommand.msgJointVelocityCommand.msgJointAccelerationCommand.msg and JointEffortCommand.msg .

I also think that such msgs should be part of std_msgs, rather than control_msgs if possible. Perhaps this should be moved to a Discourse discussion rather than a Q&A, what do you think?

ijnek gravatar image ijnek  ( 2021-09-27 04:15:26 -0600 )edit

You can always post a topic on Discourse.

re: in std_msgs: please refer to the linked ros2_control issue. std_msgs is deprecated. I would be very much surprised if any more additions to it would be accepted.

I also don't agree with your assertion that "it should be in std_msgs". From a semantics point-of-view, control_msgs seems much more appropriate.

gvdhoorn gravatar image gvdhoorn  ( 2021-09-27 04:17:41 -0600 )edit

Oops, I meant common_interfaces, not std_msgs.

ijnek gravatar image ijnek  ( 2021-09-27 09:04:03 -0600 )edit

I believe that wouldn't change my response. This is clearly a message which is intended to be used in situations where you want to control some mechanism / robot. What is your motivation for wanting to put it in common_interfaces?

gvdhoorn gravatar image gvdhoorn  ( 2021-09-27 09:50:29 -0600 )edit

For a motor that has a position controller onboard, there is no need to use the ros-control package. My thought process is "Well, I'm not using ros-control, why should I use msgs from ros-control?".

My understanding of control_msgs is that it contains msgs used when communicating to the ros2_control package. That's the part where I may be wrong, perhaps control_msgs isn't tied to ros-control but is intended to be more general?

ijnek gravatar image ijnek  ( 2021-09-27 19:20:45 -0600 )edit

control_msgs is not tied to ros_control at all. It's a stand-alone message package with quite some usage outside ros_control.

And the context you describe would actually fit very well with ros_control. The fact your motor "has a position controller board" does not really change anything. ros_control is first and foremost a resource management framework.

gvdhoorn gravatar image gvdhoorn  ( 2021-09-28 01:41:13 -0600 )edit

control_msgs is not tied to ros_control at all


ros_control is first and foremost a resource management framework.

I thought ros_control was specifically for performing control calculations, good to clarify that that's not the case.

ijnek gravatar image ijnek  ( 2021-09-30 18:45:37 -0600 )edit

You won't find many people describing ros_control the way I did/do. But once you get more familiar with it, I believe my description starts to make more sense.

gvdhoorn gravatar image gvdhoorn  ( 2021-10-01 00:37:05 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2021-09-26 05:44:47 -0600

Seen: 46 times

Last updated: Sep 27