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

[Matthias Goldhoorn]

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.
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, 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....

>
>
>>>
>>> Jakob
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Rock-dev mailing list
>>> Rock-dev at dfki.de
>>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>>
>>
>> -- 
>>   Dipl.-Inf. Matthias Goldhoorn
>>   Space and Underwater Robotic
>>
>>   Universität Bremen
>>   FB 3 - Mathematik und Informatik
>>   AG Robotik
>>   Robert-Hooke-Straße 5
>>   28359 Bremen, Germany
>>
>>   Tel.:     +49 421 178 45-4193
>>   Zentrale: +49 421 178 45-6550
>>   Fax:      +49 421 178 45-4150
>>   E-Mail:matthias.goldhoorn at uni-bremen.de
>>
>>   Weitere Informationen:http://www.informatik.uni-bremen.de/robotik
>>
>>
>> _______________________________________________
>> Rock-dev mailing list
>> Rock-dev at dfki.de
>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>
>
> -- 
> 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


-- 
  Dipl.-Inf. Matthias Goldhoorn
  Space and Underwater Robotic

  Universität Bremen
  FB 3 - Mathematik und Informatik
  AG Robotik
  Robert-Hooke-Straße 5
  28359 Bremen, Germany

  Tel.:     +49 421 178 45-4193
  Zentrale: +49 421 178 45-6550
  Fax:      +49 421 178 45-4150
  E-Mail:   matthias.goldhoorn at uni-bremen.de

  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20120927/05679d16/attachment.htm