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

Wed Sep 26 15:33:31 CEST 2012

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.

Add instead an TemperatureReading dataitem which includes base::Time and 
the base::Temperature (and still from my point of view an std::string 
origin)

Greetings,
Matthias

On 26.09.2012 15:21, Javier Hidalgo Carrió wrote:
> Thanks to all the inputs.
>
> The solution took so far is:
>
> 1) Added base::Temperature in types/base. Similar to base::Angle but 
> with a timestamp (base::Time).
>
> 2) I used base::RigidBodyAcceleration for inclinometers output.
>
> Javier.
>
> On 09/25/2012 05:22 PM, Jakob Schwendner wrote:
>>
>> ---------- Original Message ----------
>> From: Jakob Schwendner <jakob.schwendner at dfki.de>
>> To: Matthias Goldhoorn <matthias.goldhoorn at dfki.de>
>> Date: September 25, 2012 at 5:21 PM
>> Subject: Re: [Rock-dev] Fwd: Re: IMUSensor - temperature and 
>> inclinometers values
>>
>> On September 25, 2012 at 3:32 PM Matthias Goldhoorn 
>> <matthias.goldhoorn at dfki.de> wrote:
>> > On 25.09.2012 15:12, Jakob Schwendner wrote:
>> > > On 09/25/2012 02:47 PM, Alexander Duda wrote:
>> > >> On 09/25/2012 02:43 PM, Janosch Machowinski wrote:
>> > >>> On 25.09.2012 14:32, Javier Hidalgo Carrió wrote:
>> > >>>> Dear all,
>> > >>>>
>> > >>>> I am integrating a new IMU in rock, which gives also 
>> Inclinometers
>> > >>>> (m/s^2) and temperature (Celsius Degrees).
>> > >>>> The current IMUSensor structure allows:
>> > >>>>
>> > >>>> /** Timestamp of the orientation reading */
>> > >>>> Time time;
>> > >>>>
>> > >>>> /** raw accelerometer readings */
>> > >>>> base::Vector3d acc;
>> > >>>>
>> > >>>> /** raw gyro reading*/
>> > >>>> base::Vector3d gyro;
>> > >>>>
>> > >>>> /** raw magnetometer reading*/
>> > >>>> base::Vector3d mag;
>> > >>>>
>> > >>>> My question is:
>> > >>>>
>> > >>>> 1) To extend IMUSensor in base/samples/imu.h to have 
>> temperature (like
>> > >>>> the Xsens also gives) and inclinometers (it is given for 
>> better initial
>> > >>>> leveling)
>> > >>>> 2) Create a new data struct in my rock-driver i.e IMUSensorExtend
>> > >>>> structure to this IMU.
>> > >>>>
>> > >>>> Which is the best?
>> > >>>>
>> > >>>> Thanks,
>> > >>>>
>> > >>>> Javier.
>> > >>>>
>> > >>> 1) sound like the better option to me.
>> > >>> Janosch
>> > >>>
>> > >> The temperature gradient will be much slower than the other 
>> values and
>> > >> you could also have n temperature sensors for your System 
>> affecting the
>> > >> IMU. Therefore I would go for a generic temperature structure. This
>> > >> would also improves the overall monitoring of your system as all
>> > >> temperatures can be displayed by a generic widget.
>> > > +1
>> > > Same for inclinometer. I would process the values in the driver 
>> module
>> > > already. Just add additional output ports to the module.
>> > >
>> > > Jakob
>> > >
>> > >
>> > > _______________________________________________
>> > > Rock-dev mailing list
>> > > Rock-dev at dfki.de
>> > > http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>> > We should at this point think about an mapping where the temp is
>> > recorded, some "name", i mean in general for this case it is clear 
>> that
>> > the imu itself output's the temp.
>> > But if we had an general temp-measrument device, this device could be
>> > everywhere, so if we now add an new temperature (in kelvin!) we should
>> > ad also an string with an description. But in general it is this again
>> > an base-type?
>> Don't see why it should come with a description. It's not that we 
>> have datums floating around without knowing where they are coming 
>> from. For the temperature we could have a type like base::Angle, 
>> which stores the temperature in canonical form (which could be Kelvin).
>> Jakob
>> -- 
>> Jakob Schwendner, M.Sc.
>> Researcher
>>
>> DFKI Bremen
>> Robotics Innovation Center
>> Robert-Hooke-Straße 5
>> 28359 Bremen, Germany
>>
>> Phone: +49 (0)421 17845-4120
>> Fax: +49 (0)421 17845-4150
>> E-Mail: jakob.schwendner 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
>> -----------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Rock-dev mailing list
>> Rock-dev at dfki.de
>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>
>
> -- 
> Javier Hidalgo Carrió
> ESA - NPI Programme
> Researcher
>
> DFKI Bremen
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
> http://robotik.dfki-bremen.de
>
> Phone:+49(0)421 17845 6661
> Fax: +49(0)421 17845 4150
>
>
>
> _______________________________________________
> 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

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20120926/79725d6f/attachment-0001.htm 