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

[Jakob Schwendner]

---------- 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
-----------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20120925/bd7a97ec/attachment.htm