paparazzi-devel
[Top][All Lists]
Advanced

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

Re: [Paparazzi-devel] Generic AHRS/IMU interface for AHRS sensors (such


From: Michal Podhradsky
Subject: Re: [Paparazzi-devel] Generic AHRS/IMU interface for AHRS sensors (such as GX3, UM6, etc.)
Date: Thu, 24 Jan 2013 10:34:09 -0700

Hi,

what Loic said makes sense to me and it works just fine for now.

Just in general, I think modularity is the way to go. Imagine each subsystem would be modular, and I could specify at what frequency is each function executed (so I can run AHRS loop at 512Hz, 300Hz etc.). Or use just the INS module, which would read data from some external INS (so we wouldn't need GPS connected etc.). But maybe this variable timing is already possible with current architecture?

I am not sure about code duplicity though, because the only difference between AHRS driver and pure IMU driver for GX3 will be different settings and different packet parser.

But right now I think it is more important to finish drivers for basic functionalities - for example I2C slave for STM32 architecture etc. So we can reliably use all the peripherals the board offers (imagine controlling ESCs through CAN for example:)

What do you think?
M

On Thu, Jan 24, 2013 at 4:05 AM, Loic Drumettaz <address@hidden> wrote:
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);
}




_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



reply via email to

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