sustained rotations : pushing the envelope

This is an update of a previous post, with a link to a report that I promised that I would write. The above plot shows the results of the automatic calibration of the Z axis gyro during tests of methods to improve the performance of attitude estimation during sustained, high rate rotations. In this case, calibration was computed to better than 0.5%. The following is the original post:

No, thats not the light at the end of the tunnel, that is a time exposure of a spinning UAV DevBoard (UDB) during some research that I have been doing recently.
The goal of the research was to push the envelope of the sustained rotation limits of the direction-cosine-matrix algorithm. The idea is to be able to maintain highly accurate estimation of attitude during sustained (meaning forever) high speed rotation (maximum rating of the gyros) around any axis, such as a continuous turn, or multiple barrel rolls, or a spin, without  sacrificing any performance during straight-line flight or interfering with
any other function, such as wind estimation.
So, I put a UDB on an old record player spinning at 78 RPM (468 degrees per second), let it spin for 20 minutes, and measured, analyzed, and corrected various sources of errors that arise during high speed, sustained rotation, including:

Accumulation of numerical errors in the drift integrators.
The linear approximation to the rotation matrix in the DCM algorithm.
Latency in magnetometer measurements.
Gyro calibration errors.

The first picture was taken during measurement of magnetometer latency, in which a special test program flashed an LED on the board as it spun. The test was inspired by the strobe light method of measuring engine timing. By photographing the pattern at both low speed and high speed rotation, it is possible to determine the latency. In the first picture, the board was spinning very slowly, so this picture was a benchmark. The board was rotated a little more than two revolutions. The "dot" points to true north.

Then the board was spun at 78 RPM, and a similar picture was taken, only with more revolutions. It was easy to determine that, in the case of UDB + MatrixPilot, there is a delay of 0.085 seconds (40 degrees at 78 RPM) between the time the magnetometer makes a measurement, and when it is used in the yaw calculations. It was a simple matter to compensate for the delay in software, and another picture was taken at 78 RPM to verify the improvement:

Similar tests were performed to measure the other sources of error and to verify that the methods I developed to eliminate them actually worked, including a method for automatically calibrating the gyros in flight. I plan to explain these techniques in reports to be posted here, when I find some time to write them up.

Once everything seemed to work ok on my record player, the next step was flight testing. I turned to Ric Kuebler, (thank you, Ric) who did the following flight test on 4 separate flights, 2 with EM406 GPS, and 2 with uBlox GPS, without magnetometer, with his FunCub:

Circle 30 times at 12 RPM.
Spinning vertical dive at 90 RPM, 30 complete revolutions.
Pull out into level flight and switch to waypoint mode.

Telemetry showed that attitude estimation tracked perfectly the entire time, and then the controls transitioned smoothly into waypoint mode immediately after the spinning dive. Here is the track while Ric was pulling his plane out of the spinning dive:

Coincidentally, Ric's flight was a good test of the "dead-reckoning" algorithm that is used in MatrixPilot. Here is a portion of the reported track from the EM406 at 12 RPM:

Here is the track reported by the "dead-reckoning" algorithm:

Anyway, version 949 of MatrixPilot in the code repository contains the improvements that have been made to compensate for the errors that arise during sustained high rate rotations. With it, you can spin around any axis at 500 degrees/second for as long as you like.

Best regards,

Views: 11851

Comment by Ben Levitt on June 12, 2011 at 5:22pm
Impressive work, Bill! It's always fun to follow along with the rapid progress of your R & D.

And for others reading this, but not interested in using the bleeding-edge code from our subversion repository: Good news! This will be included in the official MatrixPilot 3.1 package which we hope to release soon.


Comment by Randy on June 12, 2011 at 5:52pm

I'd like to hear more about "it was a simple matter to account for the delay in the software".


Do you keep a historic version of the dcm matrix around and calculate the error on that and then apply that same error to the most up-to-date dcm matrix?

Comment by William Premerlani on June 12, 2011 at 6:32pm

Hi Randy,

You are correct. When a magnetometer reading becomes available, a timer starts running. At the appropriate time, a snapshot is taken of the matrix, and used with the next magnetometer reading to determine yaw drift. Think of it as a "pre-trigger". Basically, the technique is a simple time shift.

Yaw drift is determined as follows:

1. Magnetometer vector is transformed into earth frame.

2. In the earth frame, horizontal component of magnetometer reading is used to compute yaw drift error.

3. Yaw drift error is transformed back into body frame, and used for drift compensation.

Best regards,


Comment by Lew Payne on June 12, 2011 at 11:48pm
I'm always fascinated by how much performance Bill is able to eek out of a small piece of hardware.  Impressive!
Comment by Riccardo Kuebler on June 13, 2011 at 12:16am
Hi Bill,

so another milestone.
This seems to be the milestones year for MatrixPilot / UavDevoard.
This way I will go out of Champagne :D
Congratulations and thank you very much for all your research and development work.
Best regards,

Comment by Gary Mortimer on June 13, 2011 at 12:36am
Oh no Bill, your starting with Jack Crossfire type images, your doomed man, doomed.

I also like the idea of airframes turning at record player rates. Very made me smile.

Excellent work chaps, excellent.

Comment by Doug Weibel on June 13, 2011 at 6:49am

@Bill - Very nice!


@Gary - LOL

Comment by Mark Colwell on June 13, 2011 at 7:05am
This should work well in rockets too.

Comment by William Premerlani on June 13, 2011 at 7:55am
Hi Mark,

Yes, it should work with rockets just fine. I have been working with Frank Hermes, who flies very large model rockets. He is in the process of designing and building his own board for use in rockets, with the UAV DevBoard as the starting point. He calls his system RTOM (rocket tiltometer). Here is his website:

An article on Frank's system:

Frank has also written a multi-part article that is published in Rockets magazine.

Best regards,
Comment by Frank Hermes on June 13, 2011 at 9:49am


Better site ref is since everything is aggregated there on the background and current state of the RockeTiltometer...working on RTOM2 now and expect it will implement a magnetometer and Bill's new code so I can significantly increase the current spin rate limitation!


Frank Hermes


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