Hi,
See the thread from last year on this topic:
http://lists.gnu.org/archive/html/paparazzi-devel/2011-05/msg00075.html
With some nice plots Antoine made showing this problem.
Quick recap on the basic principle of all these pure attitude filters:
- Integrate the angular rate measurements from the gyros to get attitude angles.
This is correct in the short term.
- Support this estimate by an "absolute" roll/pitch measurement by computing attitude w.r.t. the gravity vector (and maybe yaw via mag or GPS). The attitude gets slowly corrected by this estimate. This is more or less correct in average over the long term (especially for quads where you normally don't have sustained accelerations).
Now this assumes you actually measure gravity (vehicle is not accelerating). For flying coordinated turns this gets roughly corrected so ideally you get only gravity again to compute the roll/pitch.
When you launch on a bungee you get a high acceleration forwards, which means that the "correction" via accelerometers during that time is wrong. The pitch angle computed from the acceleration measurement (assumed to be only gravity) will be positive (pitch up) even if you are flying level in reality. Hence it tries to correct downwards.
The int_cmpl_quat estimator was mainly written/tuned for quadrotors near
hover condition. I think it has a higher "gain" on the correction via
accelerometers than the float_dcm and hence the effect is stronger there.
Additionally:
- The int_cmpl_quat gains are tuned for a high frequency IMU loop of ~500Hz
https://github.com/paparazzi/paparazzi/issues/240
- In the case of bungee takeoff the gyro bias estimation actually does more harm than good:
Since the basic assumption in the filter is violated you get a wrong bias estimate which makes the problem even worse.
The bias will converge to the true value again as soon as you fly at constant velocity, but by then you probably have already crashed...
Possible solutions (as already discussed several times):
- Do the same "compensation" as when flying circles for forward velocity
- problematic since when you get this info it might be too late
- Use the gravity norm heuristic to automatically reduce the gain when then acceleration norm differs from 9.81m/s²
Antoine added this to float_cmpl_rmat (see linked thread). It has also been added to int_cmpl_quat but is untested. Also the gain reduction in int_cmpl_quat is smaller than in float_cmpl_rmat due to they way it's implemented in fixed-point.
Feel free to test this and improve it! You can use sw/airborne/test/ahrs/compare_ahrs.py to compare and plot these in simulation...
- Also make the gains for the accel correction adjustable
- first of all adapt them according to correction frequency
- make the gain for the bias correction adjustable separately (possibly disabling it)
- Write a full INS filter (estimates pos, vel, attitude together) does not have these problems...
Cheers, Felix
On Fri, Aug 3, 2012 at 8:47 AM, Reto Büttner
<address@hidden> wrote:
The guys of ZHAW Switzerland faced the same nasty nose down behaviour
when bungee launching and were not able to solve it.
How has OSAM of Utah State (or someone else) avoided this problem?
Regards, Reto
2012/8/3 Eduardo lavratti <address@hidden>:
> Today i do 5 perfect flights using float_dcm and bungee takeoff.
>
> For the last flight i used int_cmpl_quat but when i release the bungee the
> flywing fly for about 10 meter and loss altitude / crash.
>
> Does anyone know if "AHRS_GRAVITY_UPDATE_NORM_HEURISTIC: lower the gain of
> the gravity update based on a acceleration norm heuristic (e.g. good for
> bungee takeoff)" need to be used ?
>
> This is the 10th attemp to use int_quat and i ever hae problem with bungee
> takeoff.
>
> regards
>
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel