<blockquote style="margin:0 0 0 40px;border:none;padding:0px">"<span style="font-family:arial,sans-serif;font-size:13px">+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."</span></blockquote>




<div>
<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">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:</font></div>





<div><a href="http://answers.ros.org/question/9715/stamped-std_msgs/" target="_blank">http://answers.ros.org/question/9715/stamped-std_msgs/</a><font face="arial, sans-serif"><br></font></div><div><br></div><div>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: <a href="http://en.wikipedia.org/wiki/Foot-candle" target="_blank">http://en.wikipedia.org/wiki/Foot-candle</a>), 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 (<a href="http://www.ros.org/reps/rep-0103.html" target="_blank">http://www.ros.org/reps/rep-0103.html</a>) 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. <a href="http://en.wikipedia.org/wiki/Negative_temperature#Lasers" target="_blank">http://en.wikipedia.org/wiki/Negative_temperature#Lasers</a>)</div>




<div><br></div><div>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 (<a href="http://ros.org/wiki/rosbag/migration" target="_blank">http://ros.org/wiki/rosbag/migration</a>).  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 (<a href="http://www.ros.org/wiki/ROS/Technical%20Overview#Message_serialization_and_msg_MD5_sums" target="_blank">http://www.ros.org/wiki/ROS/Technical%20Overview#Message_serialization_and_msg_MD5_sums</a>) is why each message has a "tempreature"/"illuminance" field instead of a "value" field, so that I can guarantee unique md5 sums between them.</div>



<div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><p dir="ltr" style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">What would be the approach to the use case that Shaun discussed?</p>



</div><div><p dir="ltr" style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">Would there be separate nodes for filtering each ROS message?</p></div></blockquote>

<div class="gmail_extra">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.</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">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)<br>



<br><div class="gmail_quote">On Tue, Nov 13, 2012 at 8:09 AM, Advait Jain <span dir="ltr"><<a href="mailto:advaitjain@gmail.com" target="_blank">advaitjain@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p dir="ltr">What would be the approach to the use case that Shaun discussed?</p>






<p dir="ltr">Would there be separate nodes for filtering each ROS message?</p><div><div>
<div class="gmail_quote">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:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">






+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" value="+498928926910" 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><br>
</blockquote></div>
</div></div><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></blockquote></div><br></div>