Summary: Gyroscopes drift. Accelerometers get confused by motion. Magnetometers are easily disturbed. None of them works well alone. The open-source Fusion library combines all three IMU data streams, outputs real-time device attitude and gravity-free linear acceleration — available in both C and Python, perfect for robotics, wearables, and motion detection.
Rotate your phone and the screen follows. Tilt a drone and the flight controller instantly stabilizes it. Wear a fitness band on your wrist and it detects movement direction.
Behind every one of these features is the same fundamental question: how does a device know how much it has rotated, and which way it’s pointing?
Most people’s first answer is: read the gyroscope. But anyone who’s actually tried it discovers the ugly truth: integrate gyro data over time and the angle slowly drifts away. Accelerometers can sense the gravity vector, but they mistake sudden acceleration for attitude changes. Magnetometers can determine heading, yet they’re easily thrown off by motors, steel structures, and magnets.
The open-source project featured today — Fusion — was built specifically to handle all three of these headaches at once.
Fusion’s operating logic: don’t blindly trust any single sensor — let them correct each other.
None of the Three Is Perfect. Combine Them, and They Become More Reliable.
Fusion is an open-source IMU sensor fusion library by x-io Technologies, purpose-built for AHRS — Attitude and Heading Reference Systems.
It processes:
- Gyroscope: Fast response, excellent for capturing short-term rotation — but long-term integration drifts.
- Accelerometer: Points to gravity when stationary, helping correct roll and pitch — but easily confused by linear acceleration during motion.
- Magnetometer or external heading: Constrains yaw — but can jump unpredictably when the local magnetic field is disturbed.
The algorithm starts with gyroscope-integrated attitude as its baseline, then uses other sensors to compute feedback errors and apply corrections. The simplified logic: trust the gyroscope in the short term, and let gravity and heading pull the drift back over time.
Notably, Fusion uses the revised AHRS algorithm from Chapter 7 of Dr. Sebastian Madgwick’s PhD thesis — not the more commonly circulated Chapter 3 initial version under a different name.
The Practical Insight: It Knows When Not to Trust the Data
The worst enemy of sensor fusion is bad data entering the algorithm with high confidence.
Shake a device violently, and the accelerometer no longer sees pure gravity. Place it near a motor, and the magnetometer’s idea of north can be completely wrong. If the algorithm still unconditionally trusts these inputs, the output attitude can be instantly pulled off target.
Fusion addresses this with two critical mechanisms:
- Acceleration rejection: When the detected acceleration vector deviates too far from the current attitude estimate, accelerometer data is temporarily de-weighted or ignored.
- Magnetic rejection: When heading error exceeds a threshold, the magnetometer input is temporarily suppressed to prevent sudden orientation jumps.
If an anomaly persists for too long, the algorithm enters a recovery process to avoid accumulating severe drift from relying on the gyroscope alone. There’s also an angular velocity recovery mechanism for when rotation rates exceed the gyroscope’s full-scale range.
Reproduced using Fusion’s official sample data: orange is a standard compass calculation; blue is AHRS heading after gyroscope fusion. When magnetic anomalies occur, the difference between the two is visually striking.
Feed It Raw Sensor Data — What Do You Get Out?
Fusion’s most commonly used outputs include:
- A quaternion representing device attitude
- Roll, pitch, and yaw Euler angles — easier to interpret
- Gravity direction in the device coordinate frame
- Linear acceleration with gravity removed
- Linear acceleration transformed into the Earth reference frame
For coordinate conventions, it supports three common frames: NWU, ENU, and NED — plus sensor axis remapping. If your IMU mounting orientation doesn’t match your device’s coordinate axes, you don’t need to rewrite formulas everywhere just to swap one axis.
Run against the project’s built-in sensor_data.csv: the top two plots are raw gyroscope and accelerometer data; the bottom plot shows the attitude angles output by Fusion.
Get It Running in Python in Minutes
Fusion’s core is a C library optimized for embedded systems, but the official Python package — imufusion — lets you test and prototype without building a complex embedded project first:
pip install imufusionThe minimal processing flow is straightforward:
import imufusion
ahrs = imufusion.Ahrs()
ahrs.set_settings(imufusion.AhrsSettings(sample_rate=100))
# Update once per gyro + accelerometer reading
ahrs.update_no_magnetometer(gyroscope, accelerometer)
quaternion = ahrs.get_quaternion()
euler = imufusion.quaternion_to_euler(quaternion)
print("Roll / Pitch / Yaw:", euler)The repository also ships with simple_example.py, advanced_example.py, compass_vs_ahrs.py, and a sensor data file. It’s recommended to run the official CSV first, confirm the sample rate, coordinate axes, and output are all correct, then swap in your own serial or log data.
What’s It Good For?
Robot and vehicle attitude. Determine whether a chassis is tilted, whether steering is continuous, or serve as attitude input for SLAM, odometry, and control systems.
Drones and gimbals. Provide high-speed attitude estimation to help stabilization and compensation in flight controllers and camera gimbals.
Wearable motion devices. Recognize limb orientation, motion amplitude, and movement phases — useful for running form analysis, racket sports, fitness motion prototypes, and more.
VR controllers and interactive installations. Map handle or prop rotation into virtual space in real time.
Electronic compass with tilt compensation. Compute meaningful heading even when the device isn’t level — combine attitude with magnetometer for tilt-corrected compass output.
It’s MIT-licensed, the core code is compact, and it works from both C and Python. For developers looking to go from “I can read IMU registers” to “I can output stable attitude,” this is an ideal entry point.
Before You Jump In — Avoid These Pitfalls
First, calibration is not optional. Fusion provides models for applying gyroscope, accelerometer, and magnetometer calibration parameters — but it won’t auto-compute them for you. Zero bias, scale factor, axis misalignment, and magnetic soft/hard iron errors must all be handled first.
Second, sample timing must be accurate. If the actual sampling interval differs significantly from the configured value, angular velocity integration will fail. When the sampling period is unstable, pass the real elapsed time for each update to the algorithm.
Third, unify units and coordinate frames upfront. Gyroscope input uses degrees per second. Accelerometer is typically in g. Sensor axes, device axes, and the NWU/ENU/NED convention must all be consistent before data enters the filter.
And the most commonly misunderstood point: Fusion excels at attitude estimation — it is not a complete positioning and navigation system. It can output gravity-free linear acceleration, but integrating that acceleration twice will not give you accurate long-term position. Reliable trajectory and absolute positioning still require GNSS, vision, UWB, wheel odometry, or other external constraints.
This is precisely why Fusion is worth recommending: it doesn’t pretend that a single cheap IMU can do everything. Instead, it tackles the genuinely difficult problems of sensor fusion — startup, drift, bias, violent motion, and magnetic interference — with a lightweight, transparent, ready-to-run open-source toolkit.
Project link: https://github.com/xioTechnologies/Fusion
For drone and UAV engineers, reliable attitude estimation is the foundation of every flight controller, gimbal stabilizer, and autonomous navigation stack. At Aomway, our FPV goggles and drone telemetry systems depend on precise IMU fusion to deliver the responsiveness and stability pilots demand. Whether you’re building a custom flight controller, integrating sensor fusion into an embedded system, or developing next-generation drone attitude estimation pipelines, Fusion provides a battle-tested reference implementation that scales from prototype to production. If you have questions about IMU sensor fusion, drone attitude estimation, or integrating AHRS into UAV platforms, contact us at [email protected].
Have questions about this article? Feel free to contact us at [email protected] — we’re happy to help!
Frequently Asked Questions
1. How is Fusion’s Madgwick implementation different from the commonly-used Arduino MadgwickAHRS library?
The widely-circulated Arduino MadgwickAHRS library and most blog implementations are based on Chapter 3 of Madgwick’s PhD thesis — the original 2010 algorithm. Fusion uses the revised algorithm from Chapter 7, which incorporates improvements to the gradient descent step, magnetic distortion compensation, and gyroscope bias drift estimation. The practical difference: Fusion handles fast motion and magnetic anomalies more gracefully, with fewer overshoot artifacts during recovery. The Chapter 7 revision also formalizes the acceleration and magnetic rejection logic that many Chapter 3 implementations lack entirely.
2. Can I run Fusion directly on an STM32, ESP32, or nRF52 microcontroller?
Yes. The core C library is designed for embedded targets. It has no heap allocation, no OS dependencies, and a tiny memory footprint (a few hundred bytes of state). On an STM32F4 at 168 MHz, a single AHRS update takes roughly 3–5 microseconds. On an ESP32, the Python wrapper works through the imufusion package for prototyping, but for production deployment you’d compile the C library directly. The C API is documented in the repository with examples for bare-metal and RTOS integration.
3. What’s the minimum sample rate for usable results?
The algorithm needs at least 50 Hz from the gyroscope to track human-scale motion reasonably. Below 50 Hz, rapid rotations will be under-sampled and the attitude estimate will lag. For drone applications with aggressive angular rates (300–2000°/s), a minimum of 200–400 Hz is strongly recommended. Fusion’s sample rate setting is informational — it uses the rate for integration math — so you must pass the actual time delta if your real sample interval isn’t perfectly constant.
4. Does Fusion support 9-axis IMUs with an onboard magnetometer?
Yes. Use ahrs.update(gyroscope, accelerometer, magnetometer) instead of update_no_magnetometer. The magnetometer input constrains yaw drift, which is the axis that gravity alone cannot observe (rotation around the gravity vector looks identical to the accelerometer). However, the magnetometer must be calibrated first — Fusion’s magnetic rejection guards against transient interference from nearby magnetic objects, but it cannot compensate for an uncalibrated sensor with unknown hard-iron bias.
5. Can I use Fusion’s linear acceleration output for drone position estimation or dead reckoning?
Fusion’s gravity-removed linear acceleration is an excellent input for short-term motion detection — detecting takeoff, landing, impacts, or abrupt maneuvers — but it is not sufficient for dead reckoning on its own. Double-integrating acceleration to get position amplifies bias errors quadratically over time (a 1 mg accelerometer bias becomes a 180-meter position error after 60 seconds). For practical drone navigation, Fusion’s attitude output should feed into a sensor fusion pipeline that also incorporates GNSS, barometer, optical flow, or visual odometry. Think of Fusion as the attitude foundation layer, not the navigation solution.
