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

[Michal Podhradsky]

Ok, let me talk more general about some use-cases and possible scenarios, it will be a bit longer email:)

First the big picture:
We (at Utah State University) are developing high performance, but small and low cost UAVs for Personal Remote sensing, the project is called AggieAir (http://aggieair.usu.edu/ - although the web pages are bit outdated).


The idea is, that having a reliable and affordable UAV, a small business, a farmer, a scientist, or anybody who need to take aerial images (RGB, infrared, multispectral...) can easily get them. 

The use-case (or lets call it a "mission") is collecting aerial multi-spectral images at various places (mountains, river basins, populated areas...), which can be hard to access and remote (for example deserts, wilderness, wetlands). The whole set-up (UAV, ground station, crew) should fit into a car, and eventually into a backpack - for sake of easy transportation.

Another use-case is animal tracking - imagine an UAV being able to follow or track migrating or endangered species. Very useful for animal research. Even in this case the set-up is identical as for the previous use-case (i.e. ground station, UAV, crew fitting into a car).

The mission(s) can be heterogeneous (i.e. a fixed wing and a rotorcraft flying together), or homogeneous (multiple identical UAVs) - to do that the the software and hardware architecture of avionics should be universal and modular. Then it is easy to use the same avionics for the fixedwings, rotorcrafts, transition vehicles, just with different settings and maybe some sensors. Imagine one ground station for one UAV right now.

More information about aerial remote sensing and its applications is here: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5417547&tag=1 


To do so, there is the smaller picture:
When flying an UAV for remote sensing, there will always be a payload - typically a camera (or multiple cameras) with some dedicated controller (e.g. Gumstix, Pandaboard...) to capture and store images.

There probably should be also black box memory for storing flight data (much more data than you can transmit over telemetry channel). To further improve safety a safety copilot can be added to take care of all nearby UAVs, to avoid known obstacles etc. 

Some theory about UAV architecture and safety can be shown here: http://mechatronics.ece.usu.edu/uav+water/MESA09-SUAVTA/DETC2009-87671.pdf 
and here: http://ieeexplore.ieee.org/xpl/articleDetails.jsp;jsessionid=qWF9Q86Z8cDM3r8QJpMfS0XpjM2JrZpGkKN07G730MqTVyq7HhSm!-338030556?arnumber=6309316&contentType=Conference+Publications
and here http://asmedl.org/getabs/servlet/GetabsServlet?prog=normal&id=ASMECP002011054808000937000001&idtype=cvips&gifs=yes&ref=no


An idea how such system architecture can look like is shown in  system_architecture_future.png


And now even smaller picture:
Implementation-wise: people will use Paparazzi with different IMU/AHRS/INS subsystems. So all three cases (IMU+AHRS algorithm, AHRS sensor with attitude on output+position estimation algorithm, INS which has its own GPS receiver and outputs attitude and position estimates) should be covered. 

There should be some nice way of communicating with payload. UART is probably most convenient, but the ports can be occupied with different sensors (external IMU, GPS, radio, telemetry and you are more or less done). SPI is great as well as I2C. Unfortunately, there is currently no slave driver for Linux, so in case you want to use Gumstix as a payload computer, you cannot use it in slave mode. That's why I was asking about the Slave I2C drivers for LisaM.

And there should be an easy way of implementing additional sensors (airspeed, angle of attack etc.) - which can be already done by adding specific modules.

And finally an example of how a small low cost UAV could look:
Right now, we are working on hexarotor (see attached pictures - one is at the test bench, other one is from an indoor flight - ATT_DIRECT mode). We are flying with Lia (Lisa M 2) + GX3 and starting to play with Aspirin IMU.


In summary, I hope I explained well those use-cases and the big picture. I am not sure about the implementation details, but I am more than happy to help and contribute back to Paparazzi, because I think that open-source is the right way to go. 

So, what do you think about it?:)
M

On Thu, Jan 24, 2013 at 11:35 AM, Felix Ruess <address@hidden> wrote:

Hi,

I still believe that there should be no need to implement IMU interfaces if you are not going to use them... e.g. all the callbacks to propagate/update the ahrs when new measurements are available are totally useless/unneeded if you already get the attitude directly.

You currently can't use the um6 "imu" driver only and then use another ahrs algorithm. This is because in the "imu" driver it directly writes the resulting angles to ahrs_impl.ltp_to_imu_[euler|quat]. All the ahrs_extern does, is to rotate that to the body frame and push it to the state interface. So this is really not very nice...

It would be cleaner to write one "driver" for the UM6 (or other such devices) and then wrap that as appropriate to the ahrs or imu only, depending on how you want to use it. There is no need for code duplication regarding the parser itself.

As already said, there is some restructuring to be done before we can only use an ahrs directly without the imu...

But it is also true that there are things to do with higher priority...

About I2C Slave mode: do you actually need that at the moment? It would of course be nice to have, but in almost every case the autopilot is the I2C master....

More important is to get the new SPI driver finished/fixed so it can handle all cases that we need...

Cheers, Felix

On Thu, Jan 24, 2013 at 6:34 PM, Michal Podhradsky <address@hidden> wrote:

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

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

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

hexarotor_test_bench.JPG
Description: JPEG image

indoors_att_direct.JPG
Description: JPEG image

system_architecture_future.png
Description: PNG image