Firmware 1.8.0 Pixracer altitude hold

[Ralfde]

With the Firmware 1.8.0 the altitude hold function does not work good any more. The copter is jumping.

With Ardupilot 3.5.5 I had no problems and also 1.7.3 seem to work much better.

[TSC21]

Please follow the issue template. Without any further information, logs, etc., we are not able to help you. Also, Ardupilot is a different flight stack, so I don't see any reason to bring it to the comparison.

[mhkabir]

Potentially because of IMU cutoff options being changed. Need logs to verify. Please post logs with v1.7.3 and v1.8.

[tops4u]

@mhkabir could you elaborate on this or is it somehow documented? I have a similar impression, that the Altitude is kind of more "jumpy" than before.

[mhkabir]

@bkueng made some changes to IMU cutoff settings in this PR : #9367. This explicitly sets the on-chip lowpass filter (which affects data to estimators) to 98Hz from 42Hz. This can increase noise in the estimation depending on vibration levels on the vehicle.

See these lines :

1. https://github.com/PX4/Firmware/pull/9367/files#diff-7dd27df37a9973066febdeaca8dde3acL213
2. https://github.com/PX4/Firmware/pull/9367/files#diff-4ea98c33840731f6054af5ce02bab8d3L191

[mhkabir]

You can try reverting it to 42 and see if this helps. Logs from v1.7.3 and v1.8 would be useful, as I said above.

[Ralfde]

I think this could be the reason. 42Hz should be better.
I compared 1.7.3 with Pixracer in a 250 quad and with a 15inch Prop quad with Pixhawk PRO3.

[Ralfde]

I hope you can see which flight was with which software. The logfiles are from the Pixracer.
2018-06-22.zip
2018-06-14.zip

[RomanBapst]

@Ralfde In none of your logs I see you entering an altitude controlled mode. Do you have more logs?
@tops4u Could you also provide a log please?

[Ralfde]

2018-06-26.zip
New log file in poshold and alt mode mode.
Could you please tell me how to prevent the very hard stops with high angles in the GPS flying mode?
Today the Altitude hold was a little better. Maybe my adjustments in the settings helped a little bit.
2018-0~4.zip

[tops4u]

@mhkabir Is this what I see here (should the settings be made to avoid the peaks from the Frame?):

@RomanBapst
Here is a log (which is kind of special since there was strong wind and the Pixracer is open, so it's Baro might be affected by the wind.) https://logs.px4.io/plot_app?log=876bde08-967e-4f0c-bd0b-d93e309a8f0d

Check the here where it went into Geofence Violation -> Loiter Mode:

[Ralfde]

Sure the wind does have an influence, but it had less influence in the 1.7.3.
Changed now to Arducopter 3.5.5, which has less problems with the altitude hold with the same copter configuration.

[RomanBapst]

@Ralfde From the log it looks like your barometer is influenced a lot by wind. To see the difference you could try using gps altitude (set EKF2_HGT_MODE to GPS altitude and reboot vehicle).

[priseborough]

@Ralfde have you tested the effect of changing MPU6000_DEFAULT_ONCHIP_FILTER_FREQ from from 98Hz to 42Hz as suggested by @mhkabir?

The possibility of motor and propeller induced vibration aliasing into the IMU due to the 1kHz sampling rate PX4 uses cannot be ruled out and it is not known if lowering the IMU chips internal DLPF helps with those types of errors because we have very limited knowledge of the internal signal processing chain used by the chip makers. The only advice I can offer for reducing aliasing effects is to make the mounting of the pixracer as soft as practical. On my pixracer setup I use a 10mmx10mm soft latex foam square mount on each corner and loop wiring to minimise direct transfer of vibration.

There are also couple of areas where where your sensor data quality differs from the baseline that PX4 is tuned for:

1. High levels of Baro height variation due to body relative wind speed and direction changes. Try increasing EKF2_BARO_NOISE from the default of 2.0 to 3.0m
2. High levels of GPS velocity noise.

[Ralfde]

EKF2_BARO_NOISE from the default of 2.0 to 3.0m

I updated to the final 1.8.0 stable release. This seem to make the things worse.
EKF2_BARO_NOISE from the default of 2.0 to 3.0m: This change did not improve anything.

I would say, for this kind of copter it's maybe not worth to do more engery inside this, as long as you have good results in the bigger copters.

Otherwise you would need to use software lowpass filters for the vario and accels instead of using the internal ones.

Can the weight be set more to GPS and less to barometer, or is it only possible to switch from barometer to GPS completely for the altitude hold?

[jfcisneros]

Hi everyone,
The vehicle that I am flying seem to have a similar issue with the altitude hold.
It is a quadcopter in x configuration, the flight controller is a pixracer mounted on foam. As a range aid it is using the Lidar Lite V3.
The following logs were obtained after flying the vehicle in altitude old, with small corrections of pitch and roll to avoid crashing the walls since I am flying indoors. As it can be noticed in the logs, the z position estimated seems to be underestimating the z true position (comparing with the measurement the distance sensor).
The vehicle seems to perform much better in altitude hold with version 1.7.3 than with version 1.8.

Using version 1.7.3 the following flight log was obtained:
https://logs.px4.io/plot_app?log=ff3a149b-efc4-4f3d-b867-038da28db6e9

Using version 1.8 the following flight log was obtained:
https://logs.px4.io/plot_app?log=4f1bc6fe-dabb-4197-88d2-bdedc486be22

Using version 1.8 with MPU9250_DEFAULT_ONCHIP_FILTER_FREQ 42 (It didnt seem to improve the altitude hold) the following flight log was obtained:
https://logs.px4.io/plot_app?log=192b8164-4606-47cf-8c91-819c3f6d60f0

[RomanBapst]

@jfcisneros Hi, and thanks for reporting! You seem to have your vibration levels very much under control so it will be interesting so see what exactly caused the difference. I've tested the difference in IMU cutoff frequency before but I also came to the conclusion that it did not have a noticeable impact on the altitude and altitude rate. I'll keep you posted on my findings.

[jfcisneros]

So, in the previous post for the log using version 1.8 the only changes we made were:
9250_DEFAULT_ONCHIP_FILTER_FREQ 41
MPU6000_DEFAULT_ONCHIP_FILTER_FREQ 42

For the following log, we reverted all the deletions shown in the following link to the v1.8:
4ef3d25#diff-69db339e8e67a7fa157a26901f807976

The altitude hold performance improved significantly. The Z position estimated seems to be closer to the ground truth(Assuming that distance sensor is closer to ground truth).
The following log was obtained after flying the vehicle in altitude hold, with small corrections of pitch and roll to avoid crashing the walls since I am flying indoors.
https://logs.px4.io/plot_app?log=e4b716cc-7ef3-45fa-badb-861ebe7d872b

The only thing that is not clear still to us is that we have 2 more similar vehicles (same hardware, pixracer mounted in the same place with the same foam) that are able to perform altitude hold with the v 1.8 without the changes mentioned in this post:
https://logs.px4.io/plot_app?log=5151f0b3-fac2-4ffb-a0ae-f67079c6dff7

[priseborough]

To rule out (or otherwise) the estimator changes as a contributor I will try back to back replays on the same log data using the 1.7.3 code base and compare results using the estimator versions from 1.7.3 vs 1.8

[priseborough]

@jfcisneros When I try replaying your log
https://logs.px4.io/plot_app?log=ff3a149b-efc4-4f3d-b867-038da28db6e9 using master at https://github.com/PX4/Firmware/releases/tag/v1.7.3 I am unable to do so because of incompatible message formats. Also your log file shows that it was built from commit d3ef9b9 which i have been unable to locate.

Can you please provide a link to the commit that you built your code from.

[dagar]

@jfcisneros When I try replaying your log
https://logs.px4.io/plot_app?log=ff3a149b-efc4-4f3d-b867-038da28db6e9 using master at https://github.com/PX4/Firmware/releases/tag/v1.7.3 I am unable to do so because of incompatible message formats. Also your log file shows that it was built from commit d3ef9b9 which i have been unable to locate.

Can you please provide a link to the commit that you built your code from.

https://logs.px4.io/plot_app?log=ff3a149b-efc4-4f3d-b867-038da28db6e9 is v1.8.0

[jfcisneros]

I am sorry, it seems that in #9740 (comment), I misplaced the log urls in the comment. It should have been:

v1.7.3
https://logs.px4.io/plot_app?log=4f1bc6fe-dabb-4197-88d2-bdedc486be22

v1.8.0
https://logs.px4.io/plot_app?log=ff3a149b-efc4-4f3d-b867-038da28db6e9

[RomanBapst]

I've recently flown PX4 1.8 on a vehicle with good baro shielding (vehicle was fully covered and using Pixhawk 2.1) and the altitude hold performance using baro was really good. Almost no drops observable during or after fast movements in any direction.
Therefore, I'm closing this as I'm pretty sure all problems can be lead back to inconsistent baro data.