Setup
- ArduCopter V4.6.3 (3fc7011a), CubeOrangePlus
- HEXA/X, ~25 kg AUW, 1570 mm wheelbase, T-Motor MN801S 120KV, 29x9.5" props, 2x12S 40Ah
- WP_YAW_BEHAVIOR = 0 (“Never change yaw”)
- WPNAV_SPEED = 800-1000, WPNAV_ACCEL = 250, ATC_RATE_Y_MAX = 50, ATC_ACCEL_Y_MAX = 4500
What I’m seeing
Flying a small repeating 4-waypoint box-loop mission (DO_JUMP, 20 reps) with WP_YAW_BEHAVIOR=0, the aircraft’s heading does not hold — it walks continuously and almost perfectly linearly for the entire mission, at roughly -21 to -22 deg/min, then gets manually corrected by the pilot at RTL. DesYaw tracks actual Yaw with near-zero error the whole time (RMS ~2-3 deg), so the attitude controller isn’t fighting this at all — it looks like the “hold current heading” target is just continuously re-anchoring to wherever the vehicle already is, rather than locking to a fixed value.
This reproduced almost exactly across two independent flights on the identical mission:
- Flight A: ~-22 deg/min over a ~10 min mission body (292 → 72 deg)
- Flight B: -21.25 deg/min over an ~11 min mission body (280 → 43 deg)
- A third, shorter flight (2 laps only) showed the same direction at roughly half the rate (noisier, fewer laps)
What I’ve ruled out
- Pilot input: RCIN yaw channel sat flat at center (1495) for the entire mission body in both flights — the only stick movement is a brief correction right at RTL.
- “Face direction of travel”: ground course (from GPS velocity) swings between ~4 distinct headings each ~8s lap (it’s a box), while DesYaw decreases smoothly and independently of that — no correlation between the two.
- EKF/gyro estimator artifact: checked XKF1.GZ (EKF’s own gyro-Z bias estimate) through the whole drift window — it stayed small and bounded (-0.08 to +0.11 deg/s), not growing. Also compared raw magnetometer-implied heading (independent of the EKF fusion) against the fused Yaw output — they agree almost exactly (both swing ~217 deg over the same window), so the compass is measuring the same real rotation, not just the estimator drifting on its own.
- Wind: split the flight into 20s windows and checked the yaw rate against the aircraft’s actual absolute heading at each point (which sweeps through ~220 deg, nearly every compass quadrant, over the mission). A world-fixed force like wind acting on an asymmetric surface should flip the torque sign (or pass through zero) somewhere in that range. It doesn’t — the rate stays negative at every heading sampled (mean -0.32 deg/s, std 0.19, no heading dependence). EKF wind estimate (XKF2 VWN/VWE) also reads flat 0.00 throughout (no airspeed sensor on this airframe, so not conclusive on its own, but consistent).
So this looks like a real, repeatable, body-fixed effect — not sensor noise, not wind, not pilot input.
My question
Is this expected behavior for WP_YAW_BEHAVIOR=0 in 4.6.3 — i.e., does “never change yaw” implement heading hold as a continuously-re-anchored target (yaw-rate-zero relative to whatever the estimate currently is) rather than a fixed absolute lock, so it has no authority to correct a small real disturbance torque? Or does this point at something else — a bug in how the “hold” target is computed, or something specific I should go check on my airframe?