$4,000 Bounty For A Working AHRS Software Implementation
As most of you know, we’re working on a hardware add-on for FlightBox that will include AHRS – the sensors and software necessary to drive a virtual attitude indicator or provide attitude data to a synthetic vision system. We’ve made good progress on this. Our hardware engineer has selected components and is currently working on the board design. What may not seem obvious is that the hardware is the easy part. Software is where the real challenge begins.
If you’ve ever played with a motion-sensitive game on a smartphone that may seem counterintuitive. A $100 Android phone can easily determine attitude, right? Well, yes – in some situations. It’s easy to accurately determine attitude when standing still or moving at a steady pace. It’s far more complicated when you take into account fixed-wing flight dynamics.
There are several products on the market today that claim to provide backup attitude, and they appear to do – as long as you’re flying straight and level. Drop into a 30° bank and the screen will show it – for a few seconds. But hold the turn for a few seconds and you’ll notice something disturbing: the display starts to level out. After another few seconds the display shows straight and level again – while you’re still turning. Huh?
It turns out that without some very clever software, the hardware sensors fall victim to the same effect that makes your inner ear such a bad attitude indicator – centrifugal force. In straight and level flight, your ear and the inertial sensors in the phone both detect one acceleration, that of gravity. When you’re turning, you are subject to two accelerations: gravity and the “false gravity” of centrifugal force. In VFR your brain compensates for this using your view of the horizon to override what your inner ear thinks is happening. To accurately display attitude the AHRS system needs something similar – a means of determining what sensory inputs it should ignore.
Many, perhaps most, off the shelf IMUs (inertial measurement units) – the core sensors of an AHRS – are built for use in cell phones or quadcopter drones. Neither of these are subjected to fixed wing flight dynamics. To build a real AHRS, the data from the IMU must be filtered to eliminate noise and must have the inertial (centrifugal) vector factored out of the readings. This is the real challenge of AHRS. Without this, you don’t have an AHRS – you have a toy.
Fortunately, there are people out there who are very good at the kinds of mathematics required and who could create a set of algorithms that combines data from an IMU and a GPS to provide a realistic attitude solution. Unfortunately, I am not one of those people. Thus the Open Source AHRS challenge:
Falken Avionics in partnership with Aerovie, Hilton Software, and DroidEFB is offering a bounty of $4,000 to the first developer or team of developers who can provide an open source AHRS implementation that can successfully return an accurate and timely orientation based on raw IMU (3 axis accelerometer, magnetometer, and gyroscope) and GPS data. Please see “The Rules” for details on the requirements and terms.
If you are a developer and you think you might be able to solve this, please jump in. If you know any developers who might be interested, please pass this along. We’re know that this problem can be solved in a way that makes GA safer and more affordable.
UPDATE: We’ve decided to extend the challenge through July 15, 2016.
