What it the ROS way to represent invalid data in a message

Question

I have a sensor that outputs static or slowly changing data at a low rate and dynamically changing data at a higher rate.

I would like to have one message that aggregates this data together but doesn't have to wait for a 'static data' update before it publishes the first message (due to the lossy medium these messages come over it may never get one).

I'm looking for a way that a subscriber can tell which fields of the message are populated and which are not.

The options so far:

1. Have a bitfield that holds whether each field is valid or not.
2. Have pre-defined invalid values as default values for each field.
3. Represent each value as an array of the corresponding message type and publish an array of length 0 or 1.

Am I missing a ROS way to specify that a field in a message is optional or invalid?

Unfortunately it's not as simple as just having a seperate message for static vs. dynamic data because depending on the source of the data some fields in each of those messages may also be omitted...

For interest I am trying to integrate an AIS receiver (http://en.wikipedia.org/wiki/Automatic_Identification_System)

---

Originally posted by techno74 on ROS Answers with karma: 90 on 2014-11-24

Post score: 0

---

Original comments

Comment by dornhege on 2014-11-24:
I'd say: It depends. Can you come up with an exemplary message for your data + comments which kind of data might not be filled? I have seen 2) and 3) being used in standard messages.

Answer 1

I don't think there is a "ROS-way" for doing this. I presume you can figure this out yourself, I cannot add something to your options list. A "shared-pointer-like" field which can optionally be populated is not included in the ROS msg format.

Addition on your 2) option: If your data never contains zeros maybe it be smart to use this one and check the received data for non-zero, because all ros message field are defaulted in the constructor to zero (or false for booleans).

---

Originally posted by Wolf with karma: 7555 on 2014-11-24

This answer was ACCEPTED on the original site

Post score: 1

---

Original comments

Comment by techno74 on 2014-12-02:
I think the invalid default values is probably the way to go in this case. Thanks.

Answer 2

The NavSatFix message uses NaNs to represent altitudes that aren't available from the sensor.

---

Originally posted by Tom Moore with karma: 13689 on 2014-11-24

This answer was NOT ACCEPTED on the original site

Post score: 1