We've recently made the move from the old clunky DCM implementation to a new Quaternion approach, and it seems to perform better, or at least the code is much smaller and takes almost no time at all to execute on our 72MHz 32-bit flight controller. I'll be writing an article on the Quaternion method as part of our series on Engineering Insights.

We've also added MAVLink support, and full integration with QGroundControl GCS.  This helps greatly with debugging, and of course enables waypoint flying.  The ROFL quadcopter kits have GPS built-in, and wireless versions that include an integrated XBee module are available.

As always, more videos on our youtube channel: http://www.youtube.com/user/UAirLtd

And the kits are still on sale! http://www.universalair.co.uk/catalog/rofl

Still to come: waypoint flying, and FPV: The flight controller GPS code just needs a bit of tuning, and we'll have the thing flying autonomously in no time.  The full-range of waypoint options in QGroudControl are supported, including waypoint tolerances, and yaw angles.  (See image below):

Tuning the quad is also possible over QGroundControl, this is a massive improvement in useability over our previous custom solution:

Loads more to come, I'll keep you guys posted.

Views: 7075

Comment by Anish on January 6, 2012 at 10:05am

@henry @yuan great work look forward to the session at #hackerspace London

Comment by Randy on January 6, 2012 at 5:43pm

Not sure an unqualified "clunky" comment is fair.

Comment by Yuan Gao on January 6, 2012 at 11:43pm

I think in comparison, the quaternion takes around a half the arithmetic operations compared with the DCM, and only one square-root operation compared to three, this is including orthogonalisation and normalisation.  Also DCM requires about three times more variables be used (which isn't necessarily itself a big impact on performance).  Therefore, "clunky" I think is valid.

Comment by Andrew Rabbitt on January 7, 2012 at 2:36am

I think this is good stuff.  I worked through all the quaternion maths to put together an algorithm for the APM, but I have to admit, I still keep getting lost in all the code, trying to stitch it in to the existing system in a way that might actually function!  Modularity (and consistent naming conventions) aren't huge features in the APM codebase, it seems, however well it works in the real world.

Anyone else out there dream of modularising APM to allow easier insertion of new-fangled ideas?

Comment by DaveyWaveyBunsenBurner on January 7, 2012 at 2:43am
With APM 2, when using the MPU 6000 to do the math, this can be enabled can it not?
Comment by Sebastian Gralla on January 7, 2012 at 7:07am

what about axis coupling? does it work as well as in dcm?

@davey: the algorithm used in MPU 6000 is not changeable and, as far as I  know, it's the best you could get out of this sensor

Comment by William Premerlani on January 7, 2012 at 8:31am

Hi Henry and Yuan Gao,

Regarding the square-root operation, I am surprised that you are wasting CPU cycles computing clunky square roots when you do not need to. It is not necessary to compute square roots for the renormalization step in either DCM or quaternion computation methods. For example, in MatrixPilot, neither a square root operation nor a division is required in the renormalization step. Take a look at the MatrixPilot code. The only arithmetic that is used is multiplications and additions in a Taylor's expansion for the reciprocal of the square root. The Taylor's expansion works because the magnitudes of the rows and columns of the computed direction cosine matrix never drift far from the correct values, so the renormalization adjustments are always small.

Best regards,

Bill Premerlani

Comment by Yuan Gao on January 7, 2012 at 8:40am

William, this implementation uses the fast inverse-square root involving the magical 0x5f3759df number, which potentially is only a little slower (requiring two subtractions, one bitwise shift, and 5 multiplications) than a first or second order Taylor expansion.  And the quaternion uses only one of these, unlike the DCM's three.

Comment by William Premerlani on January 7, 2012 at 8:53am

Hi Henry,

DCM and quaternion representations are equivalent. You can transform between the two in either direction. Some computations work best with DCM, some with quaternions. In the present version of MatrixPilot, I actually use both, starting with a DCM representation, and computing quaternions whenever I need them. The DCM computations in MatrixPilot presently consume less than 1% of the CPU processing power.

But the core representation of the attitude is just the "tip of the iceberg" in an autopilot. There are lots of other computations that need to be done, and effects to be taken into account, such as:

Wind estimation.

Gyro gains that are off-nominal.

Magnetometer misalignment.

Magnetometer offsets.

Dead reckoning.

And, in my opinion, the above computations are best done with a direction cosine matrix representation of attitude. It makes the theory easy to understand, and it simplifies the implementation.

I do agree that updating a quaternion is slightly computationally more efficient than updating a direction cosine matrix, but I take exception to the characterization of DCM as "clunky".

Best regards,

Bill Premerlani

Comment by William Premerlani on January 7, 2012 at 9:22am

Hi Yuan,

I think you just supported a point I was trying to make: the CPU loading of doing the renormalization step can be miniscule in the implementation. But if you really want to squeeze all the performance that you can, why are you not using a first order Taylor's expansion for the renormalization? It also eliminates a division.

Just out of curiosity, how does your hardware do a divide? On the PIC, divides require 17 CPU cycles, so I avoid them as much as possible, though lately we have been using them more liberally. Even so, CPU loading in MatrixPilot is around 10% for all computations, including A/D conversion and communications.

Do you do anything about compensating for gyro gain error during fast, sustained rotations? For example, a gyro gain error of 5% will produce an error of 18 degrees in 1 turn, and an error of 180 degrees in 10 turns. This can be a killer during acrobatics.

Best regards,



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

Join DIY Drones

© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service