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).<div>
<br></div><div>"you could" != "you'd want to"</div><div><br></div><div>-- Bill</div><div><br><br><div class="gmail_quote">On Tue, Nov 13, 2012 at 2:55 PM, Edwards, Shaun M. <span dir="ltr"><<a href="mailto:sedwards@swri.org" target="_blank">sedwards@swri.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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 *<b>something</b>* 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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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?<u></u><u></u></span></p><div class="im">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Shaun Edwards<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Senior Research Engineer<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Manufacturing System Department<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><a href="http://robotics.swri.org" target="_blank">http://robotics.swri.org</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><a href="http://rosindustrial.swri.org/" target="_blank">http://rosindustrial.swri.org/</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><a href="http://ros.swri.org/" target="_blank">http://ros.swri.org</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Southwest Research Institute<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><a href="tel:210-522-3277" value="+12105223277" target="_blank">210-522-3277</a><u></u><u></u></span></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div><blockquote style="margin-left:30.0pt;margin-right:0in">
<div>
<p><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">What would be the approach to the use case that Shaun discussed?<u></u><u></u></span></p>
</div><div><div class="h5">
<div>
<p><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">Would there be separate nodes for filtering each ROS message?<u></u><u></u></span></p>
</div>
</div></div></blockquote><div><div class="h5">
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">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. (<a href="http://personal.cityu.edu.hk/~bsapplec/manipula.htm" target="_blank">http://personal.cityu.edu.hk/~bsapplec/manipula.htm</a> See
section b)<u></u><u></u></p>
<div>
<p class="MsoNormal">On Tue, Nov 13, 2012 at 8:09 AM, Advait Jain <<a href="mailto:advaitjain@gmail.com" target="_blank">advaitjain@gmail.com</a>> wrote:<u></u><u></u></p>
<p>What would be the approach to the use case that Shaun discussed?<u></u><u></u></p>
<p>Would there be separate nodes for filtering each ROS message?<u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">On Nov 13, 2012 8:03 AM, "Lorenz Mösenlechner" <<a href="mailto:moesenle@in.tum.de" target="_blank">moesenle@in.tum.de</a>> wrote:<u></u><u></u></p>
<p class="MsoNormal">+1 Brian<br>
<br>
On Tue, Nov 13, 2012 at 5:01 PM, Brian Gerkey <<a href="mailto:gerkey@osrfoundation.org" target="_blank">gerkey@osrfoundation.org</a>> wrote:<br>
> On Tue, Nov 13, 2012 at 7:45 AM, Advait Jain <<a href="mailto:advaitjain@gmail.com" target="_blank">advaitjain@gmail.com</a>> wrote:<br>
>> I agree with Shaun.<br>
>><br>
>> My personal preference is for the message name to reflect the message data<br>
>> type as opposed to what the message is used for.<br>
>><br>
>> The topic name can then tell us whether the message is being used for<br>
>> humidity or pressure.<br>
><br>
> While that approach can make it easier to develop certain tools, it<br>
> runs contrary to what we've been trying to do with standard message<br>
> formats. The message definition tells you as much about the semantics<br>
> of the data as it does about the syntax. I think that we're better<br>
> off using semantically typed messages wherever possible.<br>
><br>
> brian.<br>
> _______________________________________________<br>
> ros-users mailing list<br>
> <a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
> <a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br>
<br>
<br>
--<br>
Lorenz Mösenlechner | <a href="mailto:moesenle@in.tum.de" target="_blank">
moesenle@in.tum.de</a><br>
Technische Universität München | Karlstraße 45<br>
80335 München | Germany<br>
<a href="http://ias.cs.tum.edu/" target="_blank">http://ias.cs.tum.edu/</a> | Tel:
<a href="tel:%2B49%20%2889%29%20289-26910" target="_blank">+49 (89) 289-26910</a><br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>
<br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br></div>