HolyBro Pixhawk4 mini has yaw angle drifting incorrectly while at zero velocity (UNARMED)

[comperem]

Describe the bug This issue is a direct follow-up, but separate issue from this issue.

The previous issue was a serial freezing problem while using the Pixhawk4 mini as a motion measurement device without being armed.

The new issue is the same use-case (it is unarmed) but the yaw angle seems to be drifting while at zero velocity.

To Reproduce Steps to reproduce the behavior:

1. Mount HolyBro Pixhawk 4 mini in a vehicle on the dashboard and turn on, but do not arm.
2. Drive Bellevue Avenue near Daytona Beach FL USA because it has nearly perfectly North-South and East-West road segments.
3. Stop on the side of the road, preparing for the next out-and-back test drive.
4. Watch the yaw angle drift, quite uniformly and incorrectly while at zero velocity.
5. The yaw angle was correct when vehicle stopped, and pops back into correct value when velocity resumes above some non-zero threshold.

Expected behavior The yaw angle should not drift at all while at zero velocity. Sensor fusion or the magnetometer or compass should remain pointed at approximately -107 degrees because the stopped-vehicle location is quite clear and located here: https://goo.gl/maps/TeH2scRbzQgi6fLy6

Log Files and Screenshots The Pixhawk native .ulg flight log is uploaded here.

A powerpoint with illustrated diagrams explains the issue more clearly. The drift is during the period between 2 out-and-back drives, while stopped, on the side of the road.

Why is it drifting??? It's massive drift, in 1 direction, and totally incorrect.

The yaw seems to be correct when the vehicle is moving, but yaw drifts lots when it's still.

This is likely a result of some trigger related to the yaw angle sensor fusion algo not getting enabled because this use-case has the Pixhawk UNARMED.

Drone (please complete the following information): There is no drone flight involved here. It was entirely on the dashboard of a smooth car driving a smooth road.

Additional context Previous directly related issue that is now resolved: https://github.com/PX4/PX4-Autopilot/issues/19231

Sequence of powerpoint slides illustrating the issue:

[dagar]

Did you see the raw magnetometer readings drift over that same period?

Typically EKF2 magnetometer bias estimation is only active in flight with enough yaw movement and above 1.5 m (to avoid mag anomalies). You could try setting EKF2_MAG_TYPE 2 (3-axis) so that it's running constantly, but I'm not sure if that will cause other problems, so we may have to review this usage a little more closely.

[dagar]

It looks like it could be the standalone mag bias estimator that runs when you're disarmed.

@bresch

[dagar]

Was the car idling?

You could enable the gyro notch filter at 30 Hz (IMU_GYRO_NF_FREQ 30) and reduce the low pass cutoff significantly (maybe IMU_GYRO_CUTOFF 10). You could also reduce MBE_LEARN_GAIN a bit.

[dagar]

It might be safer to turn off the standalone mag bias estimator entirely (MBE_ENABLE 0).

Within ekf2 there's another yaw estimator (Gaussian sum filter) that uses only GPS + IMU, but it's only active when you're "in air" and it requires movement. That might work well for your use case if we adjust the conditions.

[dagar]

Here's a small change that allows the yaw estimator to run when disarmed. https://github.com/PX4/PX4-Autopilot/pull/19398

[comperem]

Did you see the raw magnetometer readings drift over that same period?

Typically EKF2 magnetometer bias estimation is only active in flight with enough yaw movement and above 1.5 m (to avoid mag anomalies). You could try setting EKF2_MAG_TYPE 2 (3-axis) so that it's running constantly, but I'm not sure if that will cause other problems, so we may have to review this usage a little more closely.

Hello, great catch. Absolutely. This is the cause of the drifting orientation.

I had not seen this and am uncertain of what to do. But you've replied twice more. Answering now.

[comperem]

It looks like it could be the standalone mag bias estimator that runs when you're disarmed.

@bresch

Hello, understood and agreed. I'm familiar with magnetometer calibration concepts but not clear on exactly how this particular hardware or software functions.

It sounds like the standalone magnetometer bias estimator is: (a) generally a Good Thing (b) only supposed to trigger once, perhaps soon after boot, then stop and not run continuously (c) the disarmed or unarmed use-case is your best guess as to why the mag bias estimator is running continuously, changing the magnetometer bias values

this all makes sense. 👍

[comperem]

Was the car idling?

You could enable the gyro notch filter at 30 Hz (IMU_GYRO_NF_FREQ 30) and reduce the low pass cutoff significantly (maybe IMU_GYRO_CUTOFF 10). You could also reduce MBE_LEARN_GAIN a bit.

Yes, the car was idling while stopped on the side of the road. it's a Toyota Avalon, v6 and the engine is quite smooth. You can barely tell it's running. But, yes, the Pixhawk 4 mini was mounted on the dash and probably picked up some small vibration.

I'll have to study the parameters your mentioned. The PSD shows 30Hz is where vibration is showing up.

[comperem]

It might be safer to turn off the standalone mag bias estimator entirely (MBE_ENABLE 0).

Within ekf2 there's another yaw estimator (Gaussian sum filter) that uses only GPS + IMU, but it's only active when you're "in air" and it requires movement. That might work well for your use case if we adjust the conditions.

Ok, this is certainly one option to try. It's curious the Gaussian sum filter is only enabled above 1.5m and with movement. The Gaussian sum filter seems to be working properly during motion. The problem only manifests itself during no-motion conditions.

[comperem]

Here's a small change that allows the yaw estimator to run when disarmed. #19398

Thank you. This could work. I don't know the rest of the code, but allowing the EKFGSF to run while disarmed seems promising.

Apparently there's a compass (magnetometer) in the GPS unit and also in the Pixhawk IMU. Once they're calibrated at startup, neither should drift if the surrounding magnetic fields are not changing. I'm not sure why they do, and it's also not entirely clear why someone originally thought the EKFGSF should only run in flight. 🤷‍♂️

The GPS course over ground is reported during flight, but COG is definitely different from yaw angle.

I'll definitely test this code change to see if orientation remains constant during zero motion conditions.

[comperem]

hello, what's the status with the proposed code change?

I saw a 'force-push' but merging is blocked with 1 pending review.

it this code ready to test? It seems not. What is the next step in this code modification?