SInce the message code is auto-generated from the message definition, it
should be relatively easy to add in auto-generation of adaptor and cast
functions.  Then, you could treat the data as a native type, and have the
casting mechanism do all the heavy lifting for you.  You could (probably)
even set it up to deliver a common API look-and-feel (foo.data, for
example), even if the name of the data element was different (by setting up
references to the actual data element: double data = &temperature;, or
similar).

"you could" != "you'd want to"

-- Bill


On Tue, Nov 13, 2012 at 2:55 PM, Edwards, Shaun M. <sedwards@swri.org>wrote:

>  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****
>
> 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@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@in.tum.de> wrote:
> ****
>
> +1 Brian
>
> On Tue, Nov 13, 2012 at 5:01 PM, Brian Gerkey <gerkey@osrfoundation.org>
> wrote:
> > On Tue, Nov 13, 2012 at 7:45 AM, Advait Jain <advaitjain@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@code.ros.org
> > https://code.ros.org/mailman/listinfo/ros-users
>
>
>
> --
> Lorenz Mösenlechner            | moesenle@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@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users****
>
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users****
>
> ** **
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>