[ros-users] sensor_msgs Low Cost/Android review

Tue Nov 13 22:55:11 UTC 2012

I understand why you would want messages to have semantic meaning, but I think the thin node wrapper method is problematic from a coding and usability standpoint.  From a coding standpoint, each wrapper node would be a near copy and paste.  This is almost universally bad coding practice.  From a usability standpoint, it would require someone to code *something* anytime they wanted to take an average of a reading.  I had a recent application where I wanted to plot averages and current readings at the same time to determine options for reducing noise.  I'd hate to have to program a special node every time I wanted to perform the experiment.

Perhaps there is a way (probably in python) to use some message introspection to achieve a generic node.  The node could simply look for int/real types and then perform the filtering automatically.  Perhaps a parameter list could be used to specify the message members (as strings) that should be filtered, intead.  Such an approach may also work with messages of multiple members (I'm thinking pose).   What do you think?

Shaun Edwards
Senior Research Engineer
Manufacturing System Department

http://robotics.swri.org
http://rosindustrial.swri.org/
http://ros.swri.org<http://ros.swri.org/>
Southwest Research Institute
210-522-3277

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<mailto: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<mailto:moesenle at in.tum.de>> wrote:
+1 Brian

On Tue, Nov 13, 2012 at 5:01 PM, Brian Gerkey <gerkey at osrfoundation.org<mailto:gerkey at osrfoundation.org>> wrote:
> On Tue, Nov 13, 2012 at 7:45 AM, Advait Jain <advaitjain at gmail.com<mailto: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<mailto:ros-users at code.ros.org>
> https://code.ros.org/mailman/listinfo/ros-users

--
Lorenz Mösenlechner            | moesenle at in.tum.de<mailto: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<tel:%2B49%20%2889%29%20289-26910>
_______________________________________________
ros-users mailing list
ros-users at code.ros.org<mailto:ros-users at code.ros.org>
https://code.ros.org/mailman/listinfo/ros-users

_______________________________________________
ros-users mailing list
ros-users at code.ros.org<mailto: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/d90a902e/attachment-0004.html>