[Rock-dev] Fwd: Re: Fwd: Re: IMUSensor - temperature and inclinometers values

[Jakob Schwendner]

On 09/26/2012 06:11 PM, Leif Christensen wrote:
>
> Am 26.09.2012 17:42, schrieb Alexander Duda:
>> On 09/26/2012 05:22 PM, Leif Christensen wrote:
>>> Why do we always have type discussions? And what is basic about
>>> temperature readings? Why stuff like that has to be defined at all. Why
>>> not generate types on the fly from primitives (that was my understanding
>>> of base/types anyhow).
>>>
>>> http://www.ros.org/wiki/msg
>> The idea of base temperature is to provide a type which has setter and
>> getter for different units (Kelvin, Celsius) but internally always uses
>> the same unit. This removes a lot of errors due to a misinterpretation
>> of units.
>>
> I was more concerned about the 'basic' character of a temperature
> measurement.
Not sure if I get the point. On the C++ level, the unit argument is 
pretty strong to have some form of type (not saying it couldn't be a 
generic basic type with unit checking though). On the Framework level 
having a specific type for it makes sense also, since this prevents 
connected lets say an angle (hey that's also in degrees!) to a 
temperature input.
I understand ROS is different in this way. Not sure if this is by design 
or for technical reasons. But having everything with basic types and 
using convention to enforce interpretation seems a bit risky to me 
(maybe I understood their concept wrong). The point that we have in Rock 
is that we can directly use C++ types as messages, and can therefore 
enforce types.

>> Generating types on the fly is compromising the idea of sharing
>> components between different projects as the types would not be
>> compatible.
>>
> Yes, but that is always a tradeoff. It somehow reminds me of the
> discussion between roman(also german) law and angloamerican case law.
> Trying to define everything for all times to be globally consistent
> doesn't work out in the end.
Sure it is a Trade-Off. But lets say a temperature (as in a physical 
property) hasn't changed even between the romans and the americans. How 
you quantify it has though, and that is captured by having a canonical 
representation with accessors for different scale systems.

>>> Or are we talking about more complex, but common types for sensor
>>> readings, navigational messages, etc.? If so, there should be some sort
>>> of structure in the the whole type-thing like here:
>>>
>>> http://www.ros.org/wiki/common_msgs
>> You mean this?
>> http://www.rock-robotics.org/stable/documentation/base_types.html
>>
> No. I was talking about a structure in commonly shared messages. The
> link I posted was dealing with the common_msgs stack, which has a
> structure, since there are groups for diagnostic messages, geometry
> messages, nav messages, sensor messages, etc.
Not sure I get the point. The ROS message structure looks very similar 
to what is in Rock. You mean you are missing something like a grouping?

Jakob