It's been a while since I've posted an update on the progress of the AutoQuad flight controller.  The event that we've all been waiting for has arrived with ST Micro's announcement and subsequent release of their STM32F4 product line.  As expected, the micro-controller is pin for pin compatible with their STM32F2 series which the AQ v6.1 hardware was designed for.  This meant it was a drop-in replacement.  The most important new feature of the chip is the implementation of ARM's Cortex M4 core with a hardware FPU!  This means that we can now do floating point operations in a single clock cycle.  All forms of add / subtract / multiply / integer conversion, etc are single clock cycle instructions with the divide and square root instructions taking 14 cycles.  This is a significant step forward for math hungry applications like AutoQuad.

As soon as I could get my hands on one (around November I think) I had it on a board working to port my ground Unscented Kalman Filter code to fit into the 168MHz MCU.  With some optimizations, it ended up fitting with processing room to spare.  The current version leaves ~40% idle time during flight.  The filter is interesting because it brings all of the important estimated states and observations under a single mathematical model.  This means that each observation can influence any number of state estimates if there is determined to be co-variance between them.  The theoretical performance improvements over my old fixed gain techniques is high.  17 states and 16 process noise terms are estimated at 200Hz observed by 13 sensor measurements.

A benefit to using such a filter onboard is that it can adapt to changing variance of sensors and measurements on the fly.  This removes the need to do ground based flight calibration simulations which was a drawback to the original fixed gain methods.  Once you have a calibrated IMU, it can provide accurate state estimates "out of the box."  While this is nice, the biggest improvement is the accuracy of the state estimates it can produce.  States like 3D accelerometer bias and 3D rate gyro bias are critical to accurate attitude estimates which is the only way that you can propagate acceleration measurements through velocity and position estimates with any kind of accuracy.

Other than the upgrade of the MCU, the hardware is mostly unchanged from the original v6.1 layout.  However, there have been a lot of new features added to the firmware since last year.  What I call DVH (dynamic velocity hold) allows the pilot to control the craft's velocity in 3 dimensions while AQ handles everything else.  Let go of the sticks and the machine holds position.  AQ now speaks mavlink so it can be configured and controlled from any ground station that supports the protocol.  A comprehensive parameter set has been established that allows configuration of almost all aspects of operation.  Gimbal support and expanded mission capabilities have been added.  1-wire support for pre and post flight communications with ESC32.  Too many more to list here.

With the help of Max Levine I created this video to demonstrate the autonomous mission capabilities of the current firmware (version 6.6):

If you use the uBlox LEA-6T as the onboard GPS module, AQ can record raw satellite observations to its uSD card along with the normal flight log.  With this data and data from a local base station, you can use post RTK to get extremely accurate position and velocity estimates (~ centimeter accuracy.)  In fact, I use the RTK velocity estimates as an absolute data point in scoring the filter's performance in the ground simulations used to tune the variance and noise parameters used by the UKF.  Future work might include onboard RTK calculations using a linux based application processor mounted on a daughter board.  This would bring the system's performance to an entirely new level.

Here is what the actual flight path looked like of the flight shown in the above video using post processed RTK:

I need to thank the small group of people who have worked very hard to test, write utility software and interfaces, create documentation and generally improve the AQ  platform.  It is still very far from a finished, polished flight controller, but it has come a long way because of their help.

As with ESC32, I have decided to release the AutoQuad FC firmware under an open source license.  It can be found at:

I would also like to invite anyone interested to participate in a public beta test of the system.   Sensor calibration, setup and configuration is still a lengthy and sometimes tedious process so I would discourage anyone who thinks they can bolt the board to a frame and start flying as that is not at all what you should expect.  I have authorized manufacture and sale by ViaCopter and Flyduino who are taking orders in a few days.

Views: 23252

Comment by Bill Nesbitt on July 11, 2012 at 4:24am

Yes, the angle PID's target is the desired angle and the rate PID's target is 0.  There is typically no P or I terms for the rate PID, only D, so it is only really fighting to maintain a 0 *change* in rate, not necessarily a 0 rate.

Comment by Jeroen van de Mortel on July 11, 2012 at 4:29am

So it is mostly a damper for the angle control.

Comment by Norbert Machinek on July 17, 2012 at 2:01pm

The beta batch is sold out. But we're already planning a new one... 

Comment by Ayush Gupta on July 29, 2012 at 5:18am

Hey guys any news from the early adopters.... How many have already hooked it up to their machines??

Comment by Alexey on October 28, 2012 at 7:28am

Hi Bill, i noticed that you including accelerometer biases in your KF. Wonder what happens when quad-rotor hovers for prolonged time in steady wind. Since GPS position is not changing it should slowly leak into accelerometer bias. Which should lead to incorrect attitude estimation eventually. Do you observe it ? If not what is preventing this from happening ? 

Comment by Bill Nesbitt on October 28, 2012 at 8:24am

Alexey: Initially I was also concerned about this, but it turns out not to be a problem for a few reasons.  First, shortly after takeoff the filter learns what the acc biases are and quickly realizes that their variance is quite low so their estimates get locked down pretty tight.  Secondly, if the estimates start to drift from the actual values, it would quickly lead to attitude estimation errors which would cause some velocity and position drift.  The GPS will then notice these changes and force corrections to the biases.  This only needs to happen at a very small scale for the filter to correct itself - 10ths of a meter/s or less - so it is not really noticeable.  The same thing happens with the gyo bias estimates.  Precisely estimating these 6 bias states (3x acc + 3x gyo) is one of the keys to achieving very precise position and velocity estimates.

Comment by Alexey on October 28, 2012 at 9:09am

Bill, thank you. As i understand this effect is present but on the small scale and scale will be very dependent on how accurately actual sensor noise variance setup in the filter. Thanks for sharing you very non-trival code!

Comment by Matthew Watson on November 29, 2012 at 4:38am

Hi Bill. I saw earlier you referred to the MPU6xxx sensors as high end toys, have you had any time to further research this? I ask as I am currently struggling to temperature calibrate the gyroscopes on mine, as I seem to get a completely different relationship with every heat/cool cycle, I was wondering if you'd had similar trouble.

Also, I must say, your implementation of the unscented KF is beautiful, I haven't seen any superior estimation out there. Nice job!
Comment by Charles lakins on February 5, 2013 at 9:49pm

Any news on the new batch?

Comment by Larry on February 6, 2013 at 7:02am


The AQ board is available at dealers now. It's still not a board for people without a lot of experience with autopilots.


You need to be a member of DIY Drones to add comments!

Join DIY Drones


Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service