[rotorcraft] improve in_flight detection heuristic

[flixr]

Simply checks if thrust, speed and acceleration are above a threshold.
Does not rely on RC thrust command anymore, but only on actual thrust command.

Attempt to improve issue #201 and replaces #468

While here fix the takeoff-landing-takeoff sequence in navigation...

[flixr]

Works ok for me here... anyone else tested this?
Anyone some more comments?

[flixr]

@dewagter unless you object I'll merge this...

[podhrmic]

Was it tested in flight? At least once? Just making sure, unfortunately I can't test it right now.

[flixr]

I did a short test flight with my quad and it was working ok... but it might not detect the change from in_flight to not in_flight as good if your velocity and acceleration estimates are bad.

[dewagter]

Code looks nice. (I like the very low throttle but still high downward speed = airborne)

Still must check in-flight though. Should this solve the airborne kill mode in auto-land? I'm not a huge fan of airborne kill mode.

[flixr]

This is not intended as a replacement for the KILL_ON_GROUND_DETECT using DetectGroundEvent()
or airborne kill mode as you put it ;-)

[Drumettaz]

I just tested that in flight:

On landing, the motors were stopped by nav_detect_ground function.
As you can see, it took 3 seconds to change the status from "in_flight" to "on_ground".
It looks like the vertical speed measurement is quite delayed compared to real speed.
I was't aware of that, maybe this can be reproduced in sim?
For take-off everything looks OK:

[flixr]

Should we leave these values at default? Or maybe set higher throttle threshold, so that it doesn't go into in_flight if your rc is not calibrated well and you already have a small throttle command at throttle stick down?
And maybe raise velocity thresholds as well to be a bit more robust to bad velocity estimates?

[flixr]

If you look at the vertical velocity estimate it seems to go back to zero (actually a bit further) and then up again.
Is this maybe exactly the instant where it touched the ground and basically got an upwards acceleration due to the bump? Due to the propagation of the accel measurements this would estimate and upwards velocity (negative z) and then be corrected again by the baro...

[dewagter]

We also tested this... (the 2nd takeoff the motors did not spin so it did
not takeoff, that is normal).

-Christophe

On Thu, Aug 29, 2013 at 6:19 PM, Felix Ruess notifications@github.comwrote:

If you look at the vertical velocity estimate it seems to go back to zero
(actually a bit further) and then up again.
Is this maybe exactly the instant where it touched the ground and
basically got an upwards acceleration due to the bump? Due to the
propagation of the accel measurements this would estimate and upwards
velocity (negative z) and then be corrected again by the baro...

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/469#issuecomment-23502309
.

[flixr]

With the last two commits the issue of not being able to properly takeoff again after a landing should be fixed as well (without going to halting point with kill in between, e.g using KILL_ON_GROUND_DETECT).

[flixr]

Does anyone want to do some further tests before we merge this to master?
Are the default values OK for you?

[flixr]

@dewagter can we merge this? I also increased the default MIN_THRUST threshold to 500 (~5%) as that should make it more robust to slightly miscalibrated RC...

[dewagter]

yes. now takeoff after a land works fine.

-Christophe

On Wed, Sep 4, 2013 at 3:30 PM, Felix Ruess notifications@github.comwrote:

@dewagter https://github.com/dewagter can we merge this? I also
increased the default MIN_THRUST threshold to 500 (~5%) as that should make
it more robust to slightly miscalibrated RC...

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/469#issuecomment-23788840
.