Using sensor_msgs for control?

answered 2020-01-09 15:16:35 -0500

gvdhoorn
86574 ●283 ●1432 ●1054 http://cor.tudelft.nl/

updated 2020-01-09 15:44:50 -0500

This is my personal opinion. It's not based on any theoretical foundation or necessarily best practice, as agreed upon by "the ROS community".

Would it be considered bad form to use a sensor_msg for a control topic?

You already mention it yourself a couple of times: sensor_msgs contains messages that are meant to be used to encode data from sensors. Not for control signals. The "name mismatch" is actually a very good indication that something is not entirely correct with what you're proposing.

In the JointState example, this is what the comments in the message state (from here):

This is a message that holds data to describe the state of a set of [..] joints.

And that's just the first line. The word "state" appears 5 more times in the 10-ish lines of comments. And not as desired state, but as current (or historical) state.

Using sensor_msgs for control purposes would also mean that you lose the ability to tell whether some nodes are supposed to be able to talk to each other. Again with your JointState example, I could suddenly feed the JointStates coming out of your controller to the robot_state_publisher. This node (from here):

[..] allows you to publish the state of a robot to tf. [..]

So again: the current state, not the desired state. Consumers of TF frames would now not know whether TFs represent future or current state (in other words: the semantics of those messages now also become ambiguous).

These are good examples I believe of what it means to "violate the semantics" of messages: both producers and consumers have certain expectations about message form and meaning. With your proposal, the form (syntax) is kept, but the meaning (semantics) are changed. This complicates life for both producers and consumers, as they cannot rely on what they 'know' about these messages, and you lose the ability to unambiguously interpret a message on its own, without requiring additional knowledge (ie: whether a JointState encodes desired or current state).

Personally I don't think that's a good idea, as I believe one of the strengths of ROS is exactly the standardised semantics of messages (and services, and actions). If you start mucking with that, things will go wrong.

edit flag offensive delete link

Comments

PS: you could of course use different topics for messages which you are abusing. But that leads again to the idea that messages should be interpretable on their own: without knowing which topic it is that a message arrived on and somehow knowing what the meaning is of that topic name (something which you cannot realistically implement in a node), you wouldn't be able to tell which encodes current and which desired state.

gvdhoorn ( 2020-01-09 15:18:42 -0500 )edit

Yes, very good points and I agree. The only reason I considered abusing the message names is the issue of control messages being intimately related to sensor messages in a feedback loop. Right now control messages and sensor messages are in separate packages and repositories and do not seem to be totally compatible. Perhaps that is just due to ROS 2 controller packages not being completely worked out yet.

Do you think it is better to help work on control messages to make them compatible with sensor messages or do you think it is more appropriate to create some new category like goal messages or target messages that are just copies of sensor messages but document that they are desired state instead of current state? Or might it be better to just have one set of messages with a name like feedback messages that could be used either for current ...(more)

peterpolidoro ( 2020-01-10 09:21:42 -0500 )edit

Perhaps it would be good if you could first explain what exactly your issues are with control_msgs.

gvdhoorn ( 2020-01-10 09:24:25 -0500 )edit

Well, for example, control_msgs seems to only apply to joint kinematics. If you wanted to say set a temperature target or fluid pressure as a goal in a temperature controller or fluid pressure controller, would control_msgs be an appropriate place to add those messages?

Plus in the latest versions of control_msgs, the JointJog message was removed, which was most similar to the JointState sensor message, but still seem to imply setting desired kinematic deltas rather than a target value. This particular case is easy to change if the maintainers of control_msgs agree, but some changes might be more debatable.

I just think there is a class of controllers that could use messages that are pretty much identical to sensor_msgs to use as control targets and I am wondering where people think is the most appropriate place to store those messages. Having them in the same package or repository as sensor_msgs ...(more)

peterpolidoro ( 2020-01-10 12:09:50 -0500 )edit

In general we tend not to focus on generating standard messages until there's a class of devices upon which to generalize the interface. As a first pass I would recommend creating an application specific message package that would have your specific requirements.

As an example using temperature, say you wanted to write a ROS based thermostat. You'd create thermostat_msgs. And commonly for a thermostat you'd want a few fields beyond the raw pressure, and the header and variance no longer have real meaning in the control sense. I'd define something like this to start.

ThermostatSetPoint.msg

int32 OFF=0
int32 HEAT=1
int32 COOL=2
int32 HEAT_OR_COOL3

int32 control_mode

float64 target_temperature # Degress Celsious
float64 control_deadband # Degrees Celsius error within which not to trigger the furnace.

As you can see the control message is very different from the sensor message for this application. There's also lots ...(more)

tfoote ( 2020-01-10 16:32:25 -0500 )edit

Thank you, that is great advice. I will just create custom messages and packages for now and someday perhaps open a REP to discuss moving them to standard messages if they are refined enough and generally useful. There are some environments where using standard messages is significantly easier than using custom messages, though, which was making me tempted to abuse standard messages rather than simply create new ones. For example, using ROS with Matlab on Windows only requires a Matlab toolbox when using standard messages, but requires installing Python, CMake, and a compiler to use custom messages. Not that big of a deal and it is pretty trivial using Linux, but enough of a pain on Windows to bias me towards standard messages. Perhaps there are better ways that I could be managing and distributing pre-generated or compiled custom messages rather than regenerating them over and over on each machine.

peterpolidoro ( 2020-01-14 10:00:42 -0500 )edit

For example, using ROS with Matlab on Windows only requires a Matlab toolbox when using standard messages, but requires installing Python, CMake, and a compiler to use custom messages.

strictly speaking, this is not a problem of control_msgs or sensor_msgs, but of Matlab's ROS support. It should also be solved there (ie: Mathworks should make it easier to use custom messages with their software).

(Ab)using sensor_msgs like you suggested would at best be a work-around for this particular issue in this case.

gvdhoorn ( 2020-01-14 10:14:10 -0500 )edit

Yes I agree and I would like to avoid work-arounds and use best practices whenever possible to best maintain long term stability and compatibility with as many packages and people as possible. I guess I am just asking these sorts of questions in an attempt to fully, if slowly, understand what the community considers best practices in these sorts of situations. At some point I would be curious to learn more about the grand future plans that all of you have for standard messages and ros_controls and device drivers and the like. I imagine many people would prefer to keep standard messages to a bare minimum, but it might also be nice to have good standards that minimize custom messages help maintain compatibility across the larger ROS ecosystem.

peterpolidoro ( 2020-01-14 10:34:24 -0500 )edit

add a comment

1 Answer

Comments

Question Tools

Stats

Related questions

Using sensor_msgs for control? edit

1 Answer

Comments

Question Tools

Stats

Related questions

Using sensor_msgs for control?