[ros-users] sensor_msgs Low Cost/Android review

Tue Nov 13 20:51:00 UTC 2012

"+1, that's the same way I see it (and what I considered "best practice").
The topic name can give you the semantics while the message gives you the
syntax, i.e., just names what is stored in it (see e.g. PoseStamped or the
"Empty" srv that is used for all kinds of tasks). Just call rename the
fields "temperature", "illuminance", "fluid_pressure" etc to "value" and
you have the same message definition."

This is convenient, but there are a few problems with this approach.
 First, with common_msgs, we try to make data as standardized as possible.
 This is so that any dataset could be a reference dataset for
another institution and that that all messages "stand alone".  See this
great answer by Ken Conley on why "stamped" std_msgs do not exist:
http://answers.ros.org/question/9715/stamped-std_msgs/

One of the most important things for processing quantitative information is
the unit of measure.  It's important to define a well documented message in
order to standardize units.  Besides the obvious (using arcane units like
'foot-candle' instead of lux for illuminance:
http://en.wikipedia.org/wiki/Foot-candle), there can be issues with SI
units as well.  For instance, most people (and hardware) work more
with Celsius rather than Kelvin.  Kelvin is most important for absolute
energy and entropy calculations.  ROS REP 103 (
http://www.ros.org/reps/rep-0103.html) suggests the use of SI base units
(Kelvin) and SI derived units (Celsius).  It just so happens that most
modern electronics tend to operate somewhere between 0C and 100C before
issues arise.  People are also used to thinking on 0 to 100 scales, so
Celsius is an acceptable use of a derived unit.  It's important to define
the unit in the "Temperature" message, so that there will be no confusion
with one person interpreting the message using Kelvin and another using
Celsuis.  We don't want to end up with negative Kelvin temperatures on our
robots!  (Probably. http://en.wikipedia.org/wiki/Negative_temperature#Lasers
)

Another important point is that many of the rosbag tools will assume that
all messages with the same md5 sum are interchangeable.  The most important
example of this is rosbag migration (http://ros.org/wiki/rosbag/migration).
 This uses the md5 sum in order to migrate ALL messages and topics matching
that md5 sum in the rules to a new message.  So if you wanted to add a
"static vs dynamic" constant to the FluidPressure message and trigger a
migration - you will have converted all your logged temperatures,
illuminances into fluid pressures!  The way the md5 sum is calculated (
http://www.ros.org/wiki/ROS/Technical%20Overview#Message_serialization_and_msg_MD5_sums)
is why each message has a "tempreature"/"illuminance" field instead of a
"value" field, so that I can guarantee unique md5 sums between them.

What would be the approach to the use case that Shaun discussed?

Would there be separate nodes for filtering each ROS message?

This is an interesting case.  The best way to accomplish this is to follow
standard practices and write a good underlying library in the language of
your choice.  For each message type needed, you should then write a very
thin ROS wrapper to handle providing data to the library and publishing
data from the library.  As an example, it's possible to provide a rospy
node that takes in arbitrary parts of messages and produces a single float
as output: let's say this node calculates a moving average.  The float
output will not have units and will have the same problems as above.  The
output type should be specified just as clearly as the input types and have
its own clearly defined meaning.  An average temperature is a still
a temperature, so that message could be appropriate.  Therefore, the
sensor_msgs/Temperature wrapper should subscribe to a Temperature and
publish a Temperature.

Writing a thin (less than 50 lines of code) wrapper with library is also a
good sanity check for each type.  A moving average filter would work great
for Temperature, Pressure, etc.  But if someone tried to publish sound
intensity in decibels encoded as a Float64Stamped and finds the average
sound intensity using our moving average node, it would not produce the
correct result.  (http://personal.cityu.edu.hk/~bsapplec/manipula.htm See
section b)

On Tue, Nov 13, 2012 at 8:09 AM, Advait Jain <advaitjain at gmail.com> wrote:

> What would be the approach to the use case that Shaun discussed?
>
> Would there be separate nodes for filtering each ROS message?
> On Nov 13, 2012 8:03 AM, "Lorenz Mösenlechner" <moesenle at in.tum.de> wrote:
>
>> +1 Brian
>>
>> On Tue, Nov 13, 2012 at 5:01 PM, Brian Gerkey <gerkey at osrfoundation.org>
>> wrote:
>> > On Tue, Nov 13, 2012 at 7:45 AM, Advait Jain <advaitjain at gmail.com>
>> wrote:
>> >> I agree with Shaun.
>> >>
>> >> My personal preference is for the message name to reflect the message
>> data
>> >> type as opposed to what the message is used for.
>> >>
>> >> The topic name can then tell us whether the message is being used for
>> >> humidity or pressure.
>> >
>> > While that approach can make it easier to develop certain tools, it
>> > runs contrary to what we've been trying to do with standard message
>> > formats.  The message definition tells you as much about the semantics
>> > of the data as it does about the syntax.  I think that we're better
>> > off using semantically typed messages wherever possible.
>> >
>> >     brian.
>> > _______________________________________________
>> > ros-users mailing list
>> > ros-users at code.ros.org
>> > https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>>
>> --
>> Lorenz Mösenlechner            | moesenle at in.tum.de
>> Technische Universität München | Karlstraße 45
>> 80335 München                  | Germany
>> http://ias.cs.tum.edu/         | Tel: +49 (89) 289-26910
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20121113/b0224347/attachment-0004.html>