Problem
Compass misorientation is a common silent setup error on multirotor airframes. Unlike fixed-wing aircraft — which travel forward at speed and can derive heading from GPS ground track — multirotors rely on the compass for heading when stationary or at low speed. A compass mounted rotated 90° or flipped may pass static checks but produce GPS navigation that fights the airframe, typically discovered only when the vehicle fails to hold a line or RTH heads the wrong direction.
The current workflow requires the user to manually identify the physical compass orientation, look up the correct align_mag value, and set it correctly. Automatic detection during calibration would catch this class of error at bench setup, before the first GPS-assisted flight.
Two approaches
Option A — On-FC calculation
During calibration the FC captures a static sample buffer of (attitude, raw mag) pairs. After calibration solves, it runs a variance-minimisation pass over INAV's 8 standard sensor_align_e orientations, picks the best fit, and exposes the result via MSP for the configurator to display.
ArduPilot validates this algorithm with 300 samples and 49 orientations. INAV's 8 orientations cover all practical mounting cases; 100 samples is sufficient for reliable discrimination (confidence ratio: second_best / best variance).
Sample buffer cost: 100 × 9 bytes = 900 bytes static RAM.
Resource cost on constrained targets:
- F405 (128 KB RAM): 900 bytes is held statically — allocated permanently even during flight, for a task run once at bench setup
- F722 (448 KB usable flash, compiled at
-Os): algorithm code adds pressure on the most constrained F7 targets
- Requires a
USE_AUTO_MAG_ORIENTATION guard and per-target exclusion decisions
Advantage: calibration can be performed outdoors, away from the PC and any local magnetic interference.
Option B — Stream to PC, calculate in configurator
During calibration the FC emits a new MSP message each calibration tick: current attitude + raw mag vector. No buffer on the FC. The configurator accumulates the stream, runs the variance-minimisation pass locally after calibration completes, and presents the detected orientation.
FC resource cost: near zero — one small MSP message handler, no buffer, no algorithm. No per-target guards needed.
Concern: this approach requires the aircraft to be USB-connected to the PC during calibration. A PC, monitor, power supply, and USB cable all generate local magnetic fields. Multirotor calibration is commonly done indoors or at a bench — exactly the environment where this interference is most likely — and this is also exactly the use case where compass orientation matters most. If the interference is strong enough to degrade the calibration itself, the orientation detection will also be unreliable.
The key question for Option B: are typical PC-proximity fields strong enough to corrupt orientation detection, or does the variance-minimisation remain robust because the interference is relatively static and consistent across all samples?
Comparison
|
Option A (on-FC) |
Option B (stream to PC) |
| FC RAM cost |
900 bytes static |
None |
| FC flash cost |
~1–2 KB algorithm |
Minimal (one MSP handler) |
| Per-target guards |
Yes |
No |
| Calibration environment |
Outdoors, away from interference |
Must be USB-connected (near PC) |
| Magnetic interference risk |
Low |
Present — PC, PSU, USB cable |
| Detection reliability |
High |
Uncertain |
| Configurator work |
Small (display + Apply button) |
Larger (accumulation + algorithm) |
Questions for community
- In practice, how significant are PC-proximity magnetic fields relative to Earth's field during a bench calibration? Is the variance-minimisation robust to this level of interference?
- Is there a middle ground — FC stores samples during outdoor calibration and transfers them to the PC on reconnect — that avoids both the permanent static RAM allocation and the interference problem?
- Are there multirotor targets where 900 bytes of static RAM is a real constraint?
Problem
Compass misorientation is a common silent setup error on multirotor airframes. Unlike fixed-wing aircraft — which travel forward at speed and can derive heading from GPS ground track — multirotors rely on the compass for heading when stationary or at low speed. A compass mounted rotated 90° or flipped may pass static checks but produce GPS navigation that fights the airframe, typically discovered only when the vehicle fails to hold a line or RTH heads the wrong direction.
The current workflow requires the user to manually identify the physical compass orientation, look up the correct
align_magvalue, and set it correctly. Automatic detection during calibration would catch this class of error at bench setup, before the first GPS-assisted flight.Two approaches
Option A — On-FC calculation
During calibration the FC captures a static sample buffer of (attitude, raw mag) pairs. After calibration solves, it runs a variance-minimisation pass over INAV's 8 standard
sensor_align_eorientations, picks the best fit, and exposes the result via MSP for the configurator to display.ArduPilot validates this algorithm with 300 samples and 49 orientations. INAV's 8 orientations cover all practical mounting cases; 100 samples is sufficient for reliable discrimination (confidence ratio: second_best / best variance).
Sample buffer cost: 100 × 9 bytes = 900 bytes static RAM.
Resource cost on constrained targets:
-Os): algorithm code adds pressure on the most constrained F7 targetsUSE_AUTO_MAG_ORIENTATIONguard and per-target exclusion decisionsAdvantage: calibration can be performed outdoors, away from the PC and any local magnetic interference.
Option B — Stream to PC, calculate in configurator
During calibration the FC emits a new MSP message each calibration tick: current attitude + raw mag vector. No buffer on the FC. The configurator accumulates the stream, runs the variance-minimisation pass locally after calibration completes, and presents the detected orientation.
FC resource cost: near zero — one small MSP message handler, no buffer, no algorithm. No per-target guards needed.
Concern: this approach requires the aircraft to be USB-connected to the PC during calibration. A PC, monitor, power supply, and USB cable all generate local magnetic fields. Multirotor calibration is commonly done indoors or at a bench — exactly the environment where this interference is most likely — and this is also exactly the use case where compass orientation matters most. If the interference is strong enough to degrade the calibration itself, the orientation detection will also be unreliable.
The key question for Option B: are typical PC-proximity fields strong enough to corrupt orientation detection, or does the variance-minimisation remain robust because the interference is relatively static and consistent across all samples?
Comparison
Questions for community