Persistent low-frequency Position-mode oscillation across two FMUv6C flight controllers and internal/external magnetometers

Flight Testing & Log Analysis
1

Hi PX4 community,

I am troubleshooting a persistent low-frequency horizontal oscillation in Position/Loiter mode on a quadrotor running PX4 v1.16.0. I have tested the same problematic airframe with two different flight controllers and both internal and external magnetometers, but the oscillation still occurs.

I would appreciate help determining whether the remaining problem is related to GNSS velocity/latency, IMU–GNSS inconsistency, yaw estimation, mechanical dynamics, or the position controller.

System configuration

  • PX4: v1.16.0
  • Flight controller: FMUv6C / Pixhawk 6C-class hardware
  • Airframe: Generic Quad X, SYS_AUTOSTART=4001
  • Companion computer and ROS 2 were not running during these tests
  • Position source: GNSS/RTK
  • The GNSS receiver normally reports:
    • fix_type=6
    • approximately 42–44 satellites
    • horizontal accuracy around 1–2 cm
  • No optical flow or external vision is used

I have one normal reference aircraft and one problematic airframe.

Normal reference aircraft

This is a separate but mechanically similar aircraft that can hover normally in Position mode.

Problematic airframe — configuration 1

  • Original flight controller, referred to below as FC1
  • Internal magnetometer, device ID 396809
  • Same motors, ESCs, frame, GNSS and power system used in the later FC2 tests

Problematic airframe — configuration 2

  • The FC1 flight controller was replaced by a second flight controller, FC2
  • An external magnetometer with device ID 396817 was added
  • The frame, motors, ESCs, propellers, GNSS receiver, GNSS mounting and power system remained the same

This FC swap and external-compass test was intended to determine whether the fault followed the original flight controller or internal compass.

Main symptom

In Position mode the vehicle develops a slow horizontal oscillation:

  1. It moves away from the hold point.
  2. The position controller commands a correction.
  3. The vehicle passes through the target.
  4. It then moves away in the opposite direction.
  5. The oscillation can grow to several metres.

This is not primarily a high-frequency attitude oscillation. Roll and pitch generally track their setpoints, and there is no persistent control-allocation saturation before the oscillation becomes large.

What I have tested

1. Original FC1 with automatic magnetometer fusion

In log88, with:

EKF2_MAG_TYPE=0

the EKF changed from heading-only magnetometer fusion to 3D magnetometer fusion. This was followed by:

  • magnetometer faults,
  • EKF instance switching,
  • large yaw resets,
  • position and velocity resets,
  • rapid worsening of the horizontal motion.

This initially suggested that the internal magnetometer was the root cause.

2. Full sensor recalibration

I recalibrated:

  • magnetometer,
  • accelerometers,
  • gyroscopes,
  • level horizon.

A subsequent static attitude scan showed much better three-axis magnetic-field consistency and no rejected magnetometer observations.

3. FC1 with magnetometer used only for initial yaw

I then changed:

EKF2_MAG_TYPE=6

In logs102 and 103:

  • cs_mag_hdg=0 in flight,
  • cs_mag_3d=0 in flight,
  • there was no previous type of 3D magnetometer-fusion failure,

but the Position-mode oscillation still occurred.

Log102 used Altitude mode first and then switched to Position mode.

Log103 took off directly in Position mode. The vehicle developed a large horizontal oscillation and was manually killed. The final rollover occurred after manual lockdown, not because of a detected motor failure.

This indicates that in-flight 3D magnetometer fusion was an important failure amplifier in log88, but it was not the only cause of the underlying Position-mode oscillation.

4. Replacing the flight controller and adding an external compass

I installed FC2 on the same problematic airframe and added external magnetometer 396817.

Some early configurations accidentally gave the internal and external magnetometers equal priority, and the internal magnetometer was still selected.

After disabling the internal magnetometer and selecting only external magnetometer 396817, the flight behaviour improved, but the vehicle was still not as stable as the normal reference aircraft.

Important comparison logs include:

  • log123: external compass, reduced horizontal position/velocity gains, but oscillation still developed
  • log136: continuous Position-mode flight with external compass; repeated low-frequency oscillation grew significantly
  • log138: internal compass selected
  • log143: external compass selected exclusively; better than log138, but still not fully stable

Therefore, replacing the flight controller and using an external compass did not completely remove the problem.

GSF yaw versus main EKF yaw

Several logs show a large difference between:

yaw_estimator_status.yaw_composite

and:

vehicle_local_position.heading

However, the difference is not a fixed 45-degree offset.

Examples:

  • log87: the difference was temporarily around +55 degrees and later around −45 to −55 degrees in the same flight
  • log88: it was initially close to zero, then became unstable after estimator/magnetometer failures
  • log103: it was relatively stable around −47 to −50 degrees during part of the flight
  • normal reference log19: generally around 3–7 degrees

Because the sign and magnitude change between flights and even within a flight, I do not think this is simply a fixed SENS_BOARD_ROT or 45-degree mounting error.

My concern is that the main EKF yaw, the GSF yaw and the observed GNSS horizontal motion are repeatedly becoming inconsistent.

GNSS velocity innovations

The most repeatable difference between the normal aircraft and the problematic airframe is the GNSS velocity innovation.

In the normal reference log:

  • horizontal GNSS velocity innovations are relatively small,
  • velocity test ratios remain well below the rejection threshold.

In the problematic-airframe logs:

  • horizontal GNSS velocity innovations are much larger,
  • velocity test ratios frequently approach 0.5–1.0 and occasionally exceed 1,
  • the EKF sometimes reports horizontal velocity innovation failures,
  • some flights contain EKF instance switches and position/velocity resets.

This remains present:

  • with FC1 and the internal compass,
  • with EKF2_MAG_TYPE=6,
  • with FC2 and the external compass,
  • and even in some logs with relatively low vibration.

The physical GNSS receiver, antenna, cable and mounting arrangement were common to FC1 and FC2.

The receiver reports a good RTK fix.

Current hypotheses

I am currently considering the following possibilities:

  1. GNSS velocity or timing/latency problem

  2. Dynamic IMU–GNSS inconsistency

Questions

  1. Does the repeated GNSS velocity innovation pattern suggest incorrect GNSS delay or dynamic velocity data?
  2. Is the time-varying GSF-to-main-EKF yaw disagreement meaningful in these flights, or can GSF converge to an incorrect mode during periodic oscillation?
  3. Are there any known receiver settings that could produce excellent reported RTK accuracy but poor or delayed dynamic velocity measurements?

Representative logs

Normal reference

Problematic airframe with FC1

Problematic airframe with FC2 and external magnetometer

Thank you for any suggestions on how to separate a GNSS timing/velocity issue from an IMU/yaw-estimation issue before conducting more risky Position-mode flights.

2

Update: the issue appears to be temporarily resolved.

The main cause was the UM982 output configuration. On the problematic receiver, AGRICA was not being sent to the flight-controller port, so PX4 did not receive the full 3D GNSS velocity and velocity-accuracy data. In addition, many unnecessary messages such as high-rate GSV, VTG, and THS were enabled, which caused irregular updates and multi-second GNSS data gaps.

I cleared the messages on UM982 COM1 and used a reduced configuration:

GPGGA COM1 0.2
AGRICA COM1 0.2
GPGST COM1 1
GPGSA COM1 1
GPRMC COM1 1
CONFIG COM1 230400
SAVECONFIG

I disabled the unnecessary high-rate messages. It is important to configure COM1, which is connected to the flight controller, rather than the USB/current port in UPrecise.

After this change, AGRICA was received continuously, GNSS position/velocity fusion no longer stopped, and the Position/Hold failsafes disappeared. For similar problems, I recommend enabling GPS_DUMP_COMM and checking that AGRICA arrives at the expected frequency without multi-second gaps.