Add a RangeArray message? about common_msgs

[tfoote]

Looking at the bitcraze one, it does not seem to be self describing. It can't be rendered in a visualizer as it doesn't have enough metadata to capture the relative information between the arrays etc. An example of a range of ranges is the LaserScan which is nicely encapsulated.

For your message you're publishing a collection of readings in a batch, where each already has a full header and stands on its own. Why does it make sense to publish them in a batch with another header rather than let them stand on their own?

[msadowski]

We found this approach to be easier to handle in various circumstances. Usually with our sensors we receive 8 readings in one frame, all those readings would have the same timestamps and sensor characteristics.

I see LaserScan is pretty to close to what we need. In fact before we used to have a node producing a LaserScan. If I remember correctly it didn't support 'distributed sensors' approach as all of them needed to converge to a single point (at least if you wanted to work with it in RVIZ).

Having multiple sensors working at once we noticed that depending on application we need to have them appear as single ranges (one per topic), array of ranges, laser scans or point clouds. Through trial and error we arrived to a conclusion that having a RangeArray as a starting point was the most robust way to package the sensor data. To convert to different message types we created a converter package.

[tfoote]

Through trial and error we arrived to a conclusion that having a RangeArray as a starting point was the most robust way to package the sensor data.

So can you explain what you tried and why this is "most robust"? Coupling separate readings and adding redundant information makes reusing the data generally much harder. For example although it has a header, it cannot be transformed as all the data is not necessarily in the same coordinate frame or at the same time.

Naively without more information your use case seems more like an application specific usage with specific semantic meaning, and as such should have a message define to reflect that semantic meaning, not a generic Array message with a header.

[msadowski]

You might be right and it's quite possible that our applications so far were quite specific.

Let's take an oversimplified example and say we have a strip of sensors like these and for some reason we wanted to create a node that calculates an average value of all the sensor readings. If we were publishing each reading on a separate topic we would quite likely need to subscribe to all of them and then average all the readings when 8 messages are received.

I think we run into similar cases twice before it made sense for us to start using a RangeArray. I think the reason it worked for us is that in most cases we had a node that was handling all of the readings.

If you have some other thoughts on how to handle such cases, ideally with standard message types we would really appreciate some feedback.

[tfoote]

Let's take an oversimplified example and say we have a strip of sensors like these and for some reason we wanted to create a node that calculates an average value of all the sensor readings.

This use case captures exactly how use case specific your setup is. Computing the average distance only is valuable if the sensors are in a specific known configuration, however this configuration is not encapsulated in the proposed message and is likely specific to your setup. If you want to support that sort of operation in the message the message should contain the offset information etc that allows you to know that an averaging operation is valid to run on the data. As an example the LaserScan includes the offsets between the lasers, an assumption of them having a single origin etc. The value in having the standard message is that you expect others to have the exact same setup.

If we were publishing each reading on a separate topic we would quite likely need to subscribe to all of them and then average all the readings when 8 messages are received.

Yes, that's not unreasonable to do, if you really need them all. A standardized enumeration of topics within a namespace for the array would make this a trivial for loop. You can also publish them all on the same topic and differentiate them by the frame ids. There are several different approaches for synchronizing parallel topics/messages. You already have the policy for doing that in your single node that's publishing them in aggregate, it can trivially be moved to after the messages are published. Moving the aggregation and averaging policy later will allow potentially multiple implementations to be used simultaneously. (For example if you have an array of sensors across the front of the robot, with left array, right array, and center array. You may want to aggregate across left and center for one metrics and right and center for another metric, with overlapping fields of view (used sensors) If you were to force the messages to be published together you'd end up needing to republish overlapping arrays. And at the same time if another algorithm wanted just the left most sensor for wall following it would not be accessible on it's own, despite being a fully self contained and valid message.

Now if you were to start distributing a robot with the sensors fixed and mounted in a standard pattern that might make sense for a robot specific message as that could be reused in the context of that robot. But it still would not make sense to be a generic message as it would only be semantically meaningful for sensors in the exact same configuration as that robot, thus it's semantically tied to the robot. robot_name_msgs/SensorArray might make more sense. However even then I'd recommend avoiding that as it would lock in the exact sensor array configuration to the data processing pipeline. And you'd have to reimplement it if either a similar robot with a similar array of sensors (but different with say a slightly different mounting angles) or the next generation of the same robot with an improved sensor suite was added you'd have to implement a parallel data processing pipeline to support the alternative arrangement.

In general the messages should have strong semantic meaning and be able to encapsulate their full meaning so that data pipelines using them don't need to change even if the configurations change.

[tfoote]

Without a specific proposal for this I'm going to close this.