| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
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.
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).
@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?
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.
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?
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.
Asked: 2021-09-26 05:44:47 -0500
Seen: 387 times
Last updated: Sep 27 '21
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
