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

[Alexander Duda]

On 09/27/2012 09:55 AM, Matthias Goldhoorn wrote:
> On 27.09.2012 09:50, Alexander Duda wrote:
>> On 09/27/2012 09:04 AM, Matthias Goldhoorn wrote:
>>> On 27.09.2012 08:51, Jakob Schwendner wrote:
>>>> On 09/26/2012 04:59 PM, Alexander Duda wrote:
>>>>> On 09/26/2012 04:24 PM, Matthias Goldhoorn wrote:
>>>>>> On 26.09.2012 16:22, Javier Hidalgo Carrió wrote:
>>>>>>> On 09/26/2012 03:33 PM, Matthias Goldhoorn wrote:
>>>>>>>> Hmh,
>>>>>>>>
>>>>>>>> i think we should add base::Temperature analog to base::angle 
>>>>>>>> WITHOUT an timestamp, becasue the temperature can then be added 
>>>>>>>> to any class without duplicate the time field.
>>>>>>>>
>>>>>>> In this case we will not be able to log the temperature alone in 
>>>>>>> a port with a timestamp. We will need to use the timestamp from 
>>>>>>> other port.
>>>>>> Thats the reason why you should add also the 
>>>>>> "base::TemperatureReading" type, which includes the time and the 
>>>>>> base::Temperature ;).
>>>>>>
>>>>>> In general in the past i was for an generic data type Stamped<T> 
>>>>>> which is in general for this kind of thinks, but there was some 
>>>>>> points against this, but i would like to point to it again ;).
>>>>>
>>>>> I do see Matthias point but I would rather go for:
>>>>> base::Temperature
>>>>> and
>>>>> struct base::samples::Temperature
>>>>> {
>>>>>     base::Time time;
>>>>>     base::Temperature temperature;
>>>>> }
>>>>>
>>>>> Alex
>>>>>
>>>> This seems to be most consistent with what we already have. Come to 
>>>> think of it I wouldn't even mind having an origin string field in 
>>>> the base::samples::Temperature type, as Matthias suggested.
>>> One addition why i would like to have an origin field, the origin 
>>> field could be used for some user GUIs, that can be created 
>>> automatic an overview over all system temperatures, without needing 
>>> the gui-creation-user to know where temperature sensor is located, 
>>> and from what task they came and where the device for the task is 
>>> located inside the system. (for manual connecting gui-parts with tasks)
>>
>> I am against adding a description field as this is doubling the 
>> mechanism of the transformer.
>> In general the transformer stack knows where each temperature sensor 
>> is located if the frame and static transformation is correctly set. 
>> Furthermore sending the same string over and over again, filling up 
>> our log files, has a bad taste.
>>
>> see 
>> http://www.rock-robotics.org/stable/documentation/data_processing/transformer.html 
>> for more informations.
>>
>>
>> Alex
>
> But where is the association between the transformer and the 
> base::samples::temperature reading, there is no connection between then.
Yes, there is. Just like every other sensor the temperature sensor 
belongs to a certain frame which can be set with the help of the 
transformer stack.

> In case for the imu you could _assume_ that the temperature sensor is 
> in the imu. But i have other components that are spread over the 
> system, and can multiple temperatures. So i don't see the relationship 
> to the transformer. Okay you could use an transformation description 
> to that you can display the temperature sensor inside of your system 
> in vizkit3d,
You can use whatever widget you like to display the information. You 
could even display/plot just the associated frame nam and the 
temperature values.

> but the transformer also uses only strings, so if you add an string 
> the transformer could be used for this. But i don't see the point that 
> the string duplicates information....

The transformer uses port annotations to define the frame of each port. 
It does not add any string to a sample. It also gives you a mechanism to 
easily change the frame of your sensor without touching the component.

Alex

-- 
Dipl.-Ing. Alexander Duda
Unterwasserrobotik

DFKI Bremen
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-456620
Fax:   +49 (0)421 178-454150
E-Mail: alexander.duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20120927/f4b168da/attachment-0001.htm