0
$\begingroup$

It is useful to my project to have data of the state of the arduino available in ROS. Depending on what is going on it might be for example the current PID parameters, the number of errors that were detected as the arm is moving and so on. As the particular variables might change from time to time I am toying with a different idea.

I would like to define a message that is flexible with respect to what it contains. The message would be published by the Arduino and available to ROS for display or other actions.

I have considered the following approaches:

  1. I could of course simply modify the message and rebuild everything if I want to add or change a variable. That's what I am trying to avoid.
  2. I could have a message that contains a JSON string. I would have to convert the data to JSON on the arduino and back from JSON in ROS. The string could be very long.
  3. I could have a message with an array of doubles and an equal length array of string which would be the name of the variable. I am not sure about arrays in messages.

I have to think this problem has been addressed in the past. Any recommendations or pointers would be appreciated.

$\endgroup$

1 Answer 1

1
$\begingroup$

Embedding data with different semantics into the same message is an anti design pattern in ROS. One of the greatest values of ROS messages is that they're fully defined and semantically meaningful.

As you mention you can clearly embed any data into a string using json. However if you do that, every single introspection and debugging tool will no longer be able to help you. It will look like a string that is opaque to the tools. You won't know what datatype is inside until after you parse it. So you can't potentially plot it in plotjuggler, you can't render it in rviz or rqt. You can echo it to the console if you just want to see json. If you really just want readable text. Why don't you send log messages?


I'd like to go back to your premise that you want to send these things in the same message. I would suggest that you consider sending it in multiple messages. One that contains the PID parameters, in a clearly defined datatype. One that contains statistics about your error statistics, maybe even a little bit more robust than a single number, adding a timestamp and a period and maybe a list of error types or error codes, or what context the errors were collected in. This information is semantically very different and will have very different consumers so should travel on separate channels.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.