ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
3

Optional Fields in ROS Messages

asked 2012-09-28 10:05:36 -0600

PerkinsJames gravatar image

Is there a way in ROS messages to have optional fields? I'm having a little trouble finding an answer to this or if there is any other method to make this possible.

For example, I would like to define a message that has 10 fields and sometimes only fill out 5 of those fields and publish the message. The issue is that the user on the other side does not have a way of knowing whether these 5 fields have been filled out or not and thus may pull garbage from some of the fields. There may be ways to get around it, such as define another variable that somehow signifies to the user that only a certain subset of data is filled out (they would know through the documentation).

I was wondering if there is any ROS-specific way of doing this that I've overlooked, if there are any plans to implement something like this, or if there are any suggestions people might have on how to do it?

Thanks!

edit retag flag offensive close merge delete

Comments

Has any progress been made on supporting optional fields?

catch22 gravatar image catch22  ( 2022-08-10 02:40:00 -0600 )edit

2 Answers

Sort by ยป oldest newest most voted
6

answered 2012-09-28 10:53:50 -0600

ahendrix gravatar image

ROS doesn't currently have native support for optional fields, but there are a few ways that you could go about building something that would work.

You could build the system you've suggested, where you have all the the possible fields defined in the message, and a final bitmask field that indicates which fields are valid; maybe something like:

int32 a
int32 b
float32 c
string d

int32 A_VALID = 1
int32 B_VALID = 2
int32 C_VALID = 4
int32 D_VALID = 8
int32 valid_fields

You could also build a message consisting of an array of key-value pairs. This has the advantage that you only send those fields that valid across the network, and would allow you to add new fields later without changing the message type. It also has the disadvantage that the values are restricted to a single type, and it has more overhead than a fixed message with the same number of fields. It might look something like this (compressed for readability):

package/KeyValue[] pairs
  string key
  int32 value

Long-term, there has been talk of changing the message serialization scheme used by ROS to use an off-the-shelf serialization library which might support a feature like this, but that's still quite a ways out (at least 6 months, probably much more).

edit flag offensive delete link more

Comments

@ahendrix Thanks for the great info. This is what I was thinking to do. I was hoping there were some built in, maybe more elegant ways to do this.

PerkinsJames gravatar image PerkinsJames  ( 2012-10-01 09:01:02 -0600 )edit

Hi, it is 2 years later now. Any update about that topic? I currently had the same issue as James :)

Stopfer gravatar image Stopfer  ( 2014-11-28 10:13:37 -0600 )edit

There are no plans to add optional fields to the current message spec in ROS 1.0; that would be a pretty big change to the serialization layer. ROS 2.0 will use DDS as the serialization and transport layer, I don't think there are any plans to add optional fields to the message spec.

ahendrix gravatar image ahendrix  ( 2014-11-29 18:21:20 -0600 )edit

If you're interested in influencing the design of ROS 2.0, you should review and join the SIG mailing list,

ahendrix gravatar image ahendrix  ( 2014-11-29 18:22:58 -0600 )edit
1

answered 2016-06-03 17:00:55 -0600

sytelus gravatar image

Two other options are:

First, if you are using float/double, you can use NaN to indicate absence of value.

Second, define new custom message called float32opt.msg like this:

float32 my_val
bool valid

Then use that type in your messages:

float32opt thrust
float32opt yaw
edit flag offensive delete link more

Question Tools

Stats

Asked: 2012-09-28 10:05:36 -0600

Seen: 4,161 times

Last updated: Aug 10 '22