update ecl/EKF and change default integration period 4000 us -> 2500 us

[dagar]

For testing PX4/PX4-ECL#795

[priseborough]

I will get some flight testing for this tomorrow (Wed) on an F7 board with logging from boot so we will have a replay log for diagnostics.

[dagar]

Thanks @priseborough. I've rebased this PR to current master and updated ecl to point to your current pr-ekfCovarianceFix branch.

[priseborough]

Preliminary multi-rotor flight testing has been performed. Estimator performance was nominal. There was a change in POSCTRL flight behaviour compared to testing with earlier versions of master with larger pitch transients during accel decel. I have not yet checked if this is present on my setup for the upstream commit this branch was forked from. Inspection of the log shows that the velocity tracking was nominal

Pitch and Roll tracking was nominal

It appears that the pitch transients behaviour was a result of the velocity demands generated from the position loop and the transition between moving and stopped.

It is unlikely that the observed change in pitch transient behaviour during POSCTRL operation is correlated to the change in this branch.

I also noticed that an accel cal was required after flashing this firmware.

Flight with compass enabled: https://review.px4.io/plot_app?log=6e670eb3-533a-4ebb-b92f-8bed8026fc13

Flyaway recovery test with declination set to -90 deg : https://review.px4.io/plot_app?log=a799a23d-c690-46d4-acf8-bec0e47fff94

Flight with compass use inhibited via EKF2_MAG_TYPE = 5 : https://review.px4.io/plot_app?log=3f653920-26fa-4a95-9c04-9596000fc07d

Extended hover test to low battery in POSCTRL with with compass use inhibited via EKF2_MAG_TYPE = 5 : https://review.px4.io/plot_app?log=8efe4cf4-3c32-49cc-b2c1-4cdac1f5de89

[dagar]

I also noticed that an accel cal was required after flashing this firmware.

I don't suppose you'd be able to find an older log from this same vehicle?

[priseborough]

I also noticed that an accel cal was required after flashing this firmware.

I don't suppose you'd be able to find an older log from this same vehicle?

Yes I can get that. Here is a log before https://review.px4.io/plot_app?log=0ad06c78-d768-41eb-b01a-380fae0b4e6c

What happened after the flash was that I had an accel inconsistency error preventing arming. I then performed an accel cal - here is the log taken during that procedure https://review.px4.io/plot_app?log=66daf97a-e6ac-4332-81be-172522bdd586

It shows that the second IMU X accel was inconsistent at the start.

After the cal there was a significant height offset caused by a bad Z value for both accelerometers, so the cal was not successful. and I had to repeat it.

[dagar]

Yes I can get that. Here is a log before https://review.px4.io/plot_app?log=0ad06c78-d768-41eb-b01a-380fae0b4e6c

The first accel x axis offset was enormous in your old log. I'll take a quick look tomorrow to see if this can be explained by the change to the new driver.

Old Log

CAL_ACC0_ID, 3932170
CAL_ACC0_XOFF, 1.9338665008544922
CAL_ACC0_XSCALE, 0.9271079897880554
CAL_ACC0_YOFF, 0.03339226171374321
CAL_ACC0_YSCALE, 1.0035347938537598
CAL_ACC0_ZOFF, -0.012606620788574219
CAL_ACC0_ZSCALE, 0.974113941192627

New Log

CAL_ACC0_ID, 3932170
CAL_ACC0_XOFF, -0.08791636675596237
CAL_ACC0_XSCALE, 0.9931976795196533
CAL_ACC0_YOFF, 0.0453348234295845
CAL_ACC0_YSCALE, 1.0062685012817383
CAL_ACC0_ZOFF, -0.0562596321105957
CAL_ACC0_ZSCALE, 0.9857292771339417

[MaEtUgR]

There was a change in POSCTRL flight behaviour compared to testing with earlier versions of master with larger pitch transients during accel decel.

What changed is there's acceleration feed-forward from the trajectory generation now applied directly to the vehicle attitude for better velocity tracking in the smoothed flights in which the generator runs and produces acceleration setpoints. I see you were flying the default multicopter configuration which uses bang bang jerk of 8 m/s^3 in manual flight (4 in mission).

Flyaway recovery test with declination set to -90 deg

There's an unwanted glitch in rate setpoint probably because the attitude resets and the setpoint getting adjusted after the estimate.