General message standards

udgcirs / marine_ros_conventions_discussion

A repossitory to discuss about new standard marine messages

11 stars 2 forks source link

General message standards #4

Open smaria opened 5 years ago

smaria commented 5 years ago

Currently, over 60 message ideas are waiting to become ROS messages. Before we start 60 separate discussions, maybe some ground rules should be defined. What do we aim for with the messages? What are general rules for ROS messages we should comply with?

smaria commented 5 years ago

Relevant notes from the ros workshop session on standard msgs:

sensor timestamp
units (default SI)
many sensors have standard, optional and derived data
optional sensors, for example attached to a CTD, go in separate message

narcispr commented 5 years ago

Additionally:

Not only timestamp but also reference frame. This is solved including a Header field to each message.
Messages should be self-explanatory. Do not use a generic valueor measurefield unless it is defined by some other filed.
Include not only measurement values but also their variance.
Not only attached sensors go in separate messages but compound messages like CTD can be published as 3 independent messges and a 1 CTD message. For example, a location filter module may need the pressure to compute the vehicle position but does not have to understand a CTD message. On the other hand, a scientífic that is processing the CTD data prefers to have the 3 element toghether.
We can take a lot of inspiration looking at the sensor_msgs package.

smaria commented 5 years ago

I wonder if the 'sensor timestamp' may sometimes be something distinct from the typical procedure of adding a HEADER timestamp to a message. E.g. sonar multibeam mapping may be sensitive to small time offsets, where it may be better to use the device internal timestamp as opposed to the ROS time when the message is generated. This way the device internal time may have a constant offset, but no variation due to reading and processing the data is added.

smaria commented 5 years ago

Further sources that might help improve the quality of the marine msgs:

all packages in common_msgs
REP 138: LaserScan Common Topics, Parameters, and Diagnostic Keys
REP 103: Standard Units of Measure and Coordinate Conventions
REP 105: Coordinate Frames for Mobile Platforms
REP 145 (draft): Conventions for IMU Sensor Drivers
REP 147 (draft): A Standard interface for Aerial Vehicles
REP 117: Informational Distance Measurements
REP 118: Depth Images

smaria commented 5 years ago

I think the radar msgs may also be useful, e.g. for processed multibeam data.

smaria commented 5 years ago

A few more notes on defining new message types vs. using existing types:

If you have another ranging device with different behavior (e.g. a sonar array), please find or create a different message, since applications will make fairly laser-specific assumptions about this data http://docs.ros.org/api/sensor_msgs/html/msg/LaserScan.html

it's usually "better" (in the sense of making the code easier to understand, etc.) when developers use or create non-generic message types http://wiki.ros.org/std_msgs

These super generic datatypes also lost their semantic meaning because they are so generic making introspection and debugging much harder. (If you recieve a Int8MultiArray on the wire do you pass it to an image viewer or a point cloud viewer?) As such they've basically been unused, but left for quick prototyping so as not to break anyone already using them. https://github.com/ros/std_msgs/issues/8