AHRS2\EKF2\EKF3 attitude and altitude estimation

[danielh]

I have been working on an optical flow\lidar based position controller to fly a small quadcopter indoors, which raised some questions regarding attitude and altitude estimation in Arducopter which I haven’t been able to resolve. I would greatly appreciate any explanation of the following observations, or even better - solution as to how to get the best attitude estimate.

Attitude Estimation

The quadcopter is holding its position within a 25cm radius circle, yet the pitch and roll reported in the Attitude mavlink message settle at around 10 degrees. Obviously at such values the quad should accelerate and not hold its position. I looked at the logs, comparing the Attitude estimated by EKF2, EKF3 and AHRS2 as well as at the accelerometer measurements. The best agreement with the accelerometer was obtained from AHRS2 – with the quad holding its position, the pitch and roll are close to zero, whereas the EKF2 and EKF3 drift away from zero and settle at rather large angles.
I have attached the log file for a flight which used EKF3 for navigation. In this flight it was mainly the roll angle that exhibited the behavior I described (See image). All of the filters seemed to agree on the pitch.
I uploaded the log file here:

1 1-1-1980 2-00-00 AM.bin

Altitude Estimation
I observed that the altitude estimate of both EKF2 and EKF3 deviate from the lidar measurements. The altitude estimated is between 25%-50% less that the lidar measurement. Looking at the accelerometer measurement, Az seems to be rather small (9.6m/s^2), so this might explain it.

Thank you!

[anbello (Andrea Belloni)]

I have a similar problem of difference between the ATTITUDE and AHRS2 messages on a simpler system: a quadcopter without optical flow / lidar.
In an indoor test flight in ALT_HOLD the copter, a little bit after take off, keep going back with stick at center (the AHRS_TRIM was adjusted).
When I keep the stick at center the ATT msg give near zero pitch, as should be, but the AHR2 msg gives a pitch near 3 deg (growing in time) and the copter drift back.

I attach an image and a dataflash log.

I also would like to understand better the difference of meaning between the ATT and the AHR2 msgs. Is it a difference between estimated and measured values? I would appreciate some link where I can study this stuff.

80-01-01_01-00-00_42.zip (427.1 KB)

[danielh]

great question, it clarifies my previous question The AHRS2 is the result of the DCM estimation algorithm. From my experience, the pitch and roll angles closely resemble the angles measured by the accelerometer. The ATT packet can be any one of the estimator instances- ahrs2 or ekf2, on any one of the imus.
The question is, how does arducopter decide which estimate to trust?

[anbello (Andrea Belloni)]

Thanks, from your answer I understand a little bit more. In my log posted above pitch and roll from ATT msg follows pitch and roll from NKF1 msg. So ATT should be from EKF2 and AHR2 from DCM but I don’t understand why my copter drift back even if the right stick is centred (mode 2) and EKF2 gives near 0 pitch value. Maybe the IMU in my FC is faulty.
Anyway I would like to understand better this stuff, on the wiki I did not found relevant materials, maybe I have to search better or, in extremis, I have to study it in the code (difficult path).