Re: [Paparazzi-devel] Generic AHRS/IMU interface for AHRS sensors (such as GX3, UM6, etc.)

[Loic Drumettaz]

Hi,

To me, the most interesting configuration is to keep the imu subsystem, and then being able to choose the AHRS subsystem: for example "int_cmpl_quat" (in case we want, for example, to correct current magnetic perturbation ;-)) or "extern_quat" (in case we want to use the GX3 or UM6 AHRS algorithm). 
Is that already the case with the existing code? Then I don't understand clearly what you want to do: remove the IMU subsystem when using AHRS "extern_quat" subsystem?
Would it still be possible to use the GX3 or UM6 as a pure IMU?

Regards

Loïc


Hi all,

a couple more general thoughts on this:

My main idea on how/when to use the IMU/AHRS/INS interfaces was to view this in terms of what information this driver/hardware/algorithm provides as output.

E.g. any subsystem that provides pure IMU measurements is an IMU subsystem, if you already get the attitude (and heading) directly from the device (e.g. XSens or UM6) it would be an AHRS, and if you get a full navigation solution including velocity and position (e.g. XSens Mti-G) an INS.

So basically an AHRS subsystem that already provides attitude doesn't need to implement an IMU _and_ AHRS interface, but only the AHRS interface. Only if you have your own AHRS algorithm that needs to use pure IMU measurements this would be needed. Analogously the same goes for the INS.

However this distinction can't be always clearly made, as AHRS devices usually provide both: the pure IMU measurements and the already computed attitude.

In most cases the IMU measurements themselves are not needed/used by the higher level components. Instead they just get the current attitude/angular rates, etc. from the state interface in the desired format.

However in some cases it is desired to use the IMU acceleration measurements directly if they are available: nav_catapult, energy_ctrl and the rotorcraft ins_int and ins_int_extended

What these basically need is the current acceleration in _body_ frame. Currently on the acceleration in the world frame (ECEF or NED) is part of the state interface, but not in the body frame.

I'm uncertain if it would be a good idea to add this to the state interface as well... maybe not.

All of this of course implies that we will have to get rid of the fixed event callbacks in main.c and hence the explicit dependency on the presence of the IMU interface (and others).

(e.g. on_gyro_event: ImuScaleGyro, run aligner, propagate ahrs and ins).

Comments, thoughts and ideas would be welcome!

Cheers, Felix

P.S. We really need to discuss the architecture and goals in general! 
What are the use-cases that we want to support, what do you guys 
want/need? At which level do we stop and just try to provide better 
interfaces to more capable systems running Linux (e.g. gumstix, rasperry
 pi, etc...)

On Fri, Jan 18, 2013 at 6:35 PM, Michal Podhradsky <address@hidden> wrote:

Hi all,

I moved the discussion from https://github.com/paparazzi/paparazzi/pull/347 to here. 

Basically, if we are using more advanced sensors which are in fact AHRS 
(so they output attitude estimation directly, no additional math is 
needed - such as GX3 from Microstrain, or UM6 from CH Robotics), does it
 make more sense to have a special IMU subsytem to handle the 
communication with the sensor and then AHRS subsystem which would just 
update the vehicle states with estimated attitude/rate?


Or would be better to use IMU subsystem only if we want to run our AHRS math on the gyro/acc/mag data?

Felix has some suggestions below.
Michal

Felix Ruess wrote:

Ok, first some comments on the general situation with IMU/AHRS, etc...
(maybe we should discuss this on the mailing list though?)

With the new state interface that we have now in master most of the ahrs interface is actually gone now (except the function declarations).

In general it seems like for sensors like these which are essentially already an AHRS and not only an IMU, the imu interface would not be needed and it would make more sense to implement them as an AHRS directly. (Disregarding that we still require calls to imu directly from the main.c for the moment).

We definitely have to discuss how to structure this now (e.g. the imu subsystem should only be mandatory if you want to run your own ahrs algorithm on the IMU measurements). The only places we use the imu values directly, are the when the actual acceleration measurements in imu/body frame are needed: nav_catapult, energy_ctrl and INS.
This all ties into the more general modules vs. subsystems discussion..

It might make sense to use the new generic orientation representation in the ahrs_extern.
Then it would be better to use as a wrapper for other ahrs/imus as well (if we want to go that way...) Or we add this to the main ahrs struct (which only has the status left now after we have the state interface)?
Anyway... it could be something along these lines:

struct AhrsExtern {
  struct OrientationReps ltp_to_imu_orientation;
  ..
};
struct AhrsExtern ahrs_impl;

receive_attitude() {
  orientationSetQuat_f(&ahrs_impl.ltp_to_imu_orientation, &UM6_quat);
}