paparazzi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Paparazzi-devel] Generic AHRS/IMU interface for AHRS sensors (such as G


From: Michal Podhradsky
Subject: [Paparazzi-devel] Generic AHRS/IMU interface for AHRS sensors (such as GX3, UM6, etc.)
Date: Fri, 18 Jan 2013 10:35:58 -0700

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);
}


reply via email to

[Prev in Thread] Current Thread [Next in Thread]