search

PX4 / PX4-Autopilot

PX4 Autopilot Software
https://px4.io
BSD 3-Clause "New" or "Revised" License
8.17k stars 13.36k forks source link

EKF not fully reliable #2998

Closed mswingtra closed 8 years ago

mswingtra commented 8 years ago

Yesterday we have done some hover tests where we wanted to tune mc_pos_control for altitude and position. We flew with master 0fed23a and we chery-picked EKF fix https://github.com/PX4/Firmware/pull/2968. The fix itself works as before it, our LPOS_Z was totally different then baro signal, and it was causing way too much CPU load. Now the load dropped down to ~25% for us, and EKF performance is much better, but still not as good as before pulling the https://github.com/PX4/Firmware/pull/2815#event-413847903.

Note: We had quite bad GPS signal yesterday, but it was pretty much the same for all the tests. The main issues are sudden jumps/spikes in the position setpoint, and the fact that position setpoint rises although throttle stick is in or below the deadzone - basically we had a situation that aircraft was rising a couple of meters up while throttle stick was at zero (http://logs.uaventure.com/view/ekETmDV6hEsFNhENV7CAkA! - unfortunately logmuncher does not display rc inputs - I think we have some naming mismatch), ergo estimator does not work properly.

Below are two snaps showing the spikes and lpos not fully following baro: alt_ekffix baro_ekffix (http://logs.uaventure.com/view/WPiHd9TEXGvyGoSjZgidkh)

Then we switched to the branch with old version of EKF and its performance was far more reliable (pilot finally had control in altitude control), although not fully perfect due to bad gps signal. But the difference has been significant. (http://logs.uaventure.com/view/gNoRJNsCHftMQ6pAJcFgn7) alt_oldekf baro_oldekf

LorenzMeier commented 8 years ago

I'm not too confident about a cherry-picked state. The changes on the system level were profound and you might have ended up with a bad merge. Could you do a bench test with current master vs. your stable state and let me know what you find?

mswingtra commented 8 years ago

Hi @LorenzMeier, sorry for a bit late response, frankly we had quite a lot of troubles dealing with the new compilation method and including our own modules. Anyway, we've just done indoor string test with master bb2e5b7, and we did not observe improvement as there are still weird spikes in altitude estimation. We'll probably do outdoor test with gps signal in next hour or so, but I do not think the behaviour will change for better.

With all the changes in estimators you've done, are there actually maybe any params that we should look into which change could improve performance of ekf?

(http://logs.uaventure.com/view/KH4HkCrG3Rem7qJDv4ryT3) alt_newekf baro_newekf

LorenzMeier commented 8 years ago

It looks like the filter is resetting quite often. Could you attach the MAVLink message log file from the SD card as well?

What is immediately visible is that the Z variation spikes correlate to changes in airspeed.

mswingtra commented 8 years ago

Message log:

DISARMED by RC [cmd] arming state: STANDBY Flight mode: ACRO baro healthy No geofence set Flight mode: MANUAL settings autosaved ARMED by RC [cmd] arming state: ARMED [sdlog2] log dir: /fs/microsd/log/sess001 [sdlog2] starting: log001.px4log Flight mode: ACRO TAKEOFF DETECTED DISARMED by RC [cmd] arming state: STANDBY LANDING DETECTED SENSOR FAILSAFE! RETURN TO LAND IMMEDIATELY [sdlog2] logging stopped settings autosaved Flight mode: MANUAL ARMED by RC [cmd] arming state: ARMED [sdlog2] log dir: /fs/microsd/log/sess002 [sdlog2] starting: log001.px4log Flight mode: ACRO TAKEOFF DETECTED DISARMED by RC [cmd] arming state: STANDBY LANDING DETECTED [sdlog2] logging stopped settings autosaved

About the airspeed - we do not fuse it in hover. We always have observed weird spikes when in hover (even before estimator changed), but we do not use it.

LorenzMeier commented 8 years ago

@SimonWilks @AndreasAntener A wing-wing flight with master would be much appreciated. I'm not sure if the EKF has an issue per se or its a VTOL thing.

@mswingtra You are very clearly "using" the airspeed, since it correlates with your Z spikes. I just need to work out if that's an issue with the filter or the fact that you are using it outside its design space.

mswingtra commented 8 years ago

In the previous dataset airspeed spikes seem to be correlated, but spikes in LPOS_Z occur more often. Bench-test with creating airspeed spikes by tapping and blowing to pitot. Airspeed spikes do not correlate to spikes in LPOS_Z in this dataset. Note: data is re-scaled (aircraft was all the time on ground, max. airspeed reached almost 45 m/s): (http://logs.uaventure.com/view/PWLmMDyHpdVtxJquGmz78m) airspeed

And here is dataset when we flew in hover with old EKF, there are spikes in airspeed but they're again not correlated. airspeed_oldekf

surberj commented 8 years ago

The estimator diverges only in states 6 and 9 (the local position and velocity in world-z direction).

I just did a diff between our working estimator before the update and the current one after update and want to ask if the changed way of including the accel measurements could cause the problem? Newly we use _sensor_combined.accelerometer_integral_m_s signals to propagate the states, see ekf_att_pos_estimator_main.cpp:line1262

SimonWilks commented 8 years ago

@LorenzMeier sorry, the wingwing has been stripped down and retired for now. Maybe when I get another small autopilot that will fit well I can bring it back to life. Don't have any other wing at the moment that can handle ground bounce ;)

RomanBapst commented 8 years ago

@LorenzMeier @mswingtra @SimonWilks Scheduling a test flight for this tomorrow morning.

LorenzMeier commented 8 years ago

We have not been able to reproduce this after our fixes. Please re-open with new logs if it persists on master (and please merge / rebase, cherry-picking is hopeless).