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
>
>
(text/plain)