sustained rotations : pushing the envelope

3689412338?profile=originalThis 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:

3689412424?profile=originalNo, 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:

3689412455?profile=originalSimilar 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:

3689412449?profile=originalCoincidentally, 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:

3689412395?profile=originalHere is the track reported by the "dead-reckoning" algorithm:

3689412566?profile=originalAnyway, 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,

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • Well Done Bill

    Best Regards


  • yes, it might be the cause of oscilations.

    i also have these low frequent oscilations.

    lowering kp and kp for the stabilize mode did not solve it completely.

    i quess you need to set the i and d part to zero before playing with rollpitch values.

    have not yet found a reliable solution.

    build a new small jakub drame at the moment - a tri ... will see how it flies :)

    the old is def. gone.



  • Thnks Bill, unfortunately I have to believe you 'cause my last turntable has probably (hopefully) been recycled into some monitor plastic casing.
    @Robert, while you were writing, I was submitting some questions about those vars in the AC 2.x forum. I believe they are a cause of my perpetual oscillation even with very low P and high D. Vibrations are probably also a good cause, but I would like to understand the effects on flying. If you care to anwser here is the post: http://www.diydrones.com/forum/topics/info-about-kprollpitch
    Thanks to both for your precious time.
  • @emile,

    take the missionplaner and watch the articial horizont when you shake the apm board.

    you need to have mavlink enabled.

    then you modify in system.pde the following two line:

    // setup DCM for copters:
     dcm.kp_roll_pitch(2.0);  // higher for quads
     dcm.ki_roll_pitch(0.025);  // 1/4 of the normal rate

    start shaking again...



  • T3
    Well, there could be any number of reasons for drift after aggessive manuvers. The effect that I describe in this post emerges after several high rate turns in the same direction, in rapid sequence. To get a feel for that, estimate the calibration error of your gyros, (typically 3%, but could be higher). That means that, during high rate turns, there is an error of about 11 degrees for each complete rotation, and in 4 turns, the error is about 45 degrees.
    Of course, the are several other suspects, including:
    1. Saturation of gyros and/or accelerometers.
    2. Variation in supply voltage to the gyros, accelerometers, and/or A/D.
    3. Vibration.
    4. Problems in estimation of acceleration for acceleration compensation of the accelerometer readings.
    If you want to investigate further, you could try something similar to my ground tests. Program up your autopilot to flash an LED when it passes through north. Then, spin just your autopilot on a record turntable and take photographs at both low and high spin rates.
    Best regards,
  • Could this be the reason why in our quads we have a drift issue after aggressive flights?
    If yes it would be great to include it in the code... If only I knew how... :)
    Great job Bill!
  • T3


    Follow up comment for a numerical example. With the UDB running MatrixPilot, we routinely see an uncompensated drift rate of 2 degrees per minute, or 0.033 degrees per second. When the UDB is spinning at 500 degrees per second, this represents a 0.006 percent error, which is tiny compared to a calibration error of 1 or 2%. So, the gyro offsets can be completely ignored in the calibration computations in any case.


  • T3

    Hi Jack,


    The problem with gyros depends on the type of flight. For low rotation rates, zero rate offset is important. For high rotation rates, its all about calibration errors. For best overall performance, you need to account for both.


    Actually, we are separately compensating for both the zero rate offset and the calibration error in such a way that the two computations do not interfere with each other.


    Zero rate offset is computed only when the plane is not spinning. Gyro calibration is only computed when the plane is spinning at a high rate. Ground tests and flight tests show the technique works beautifully.


    Even without any compensation of either zero rate offset or calibration errors, we have managed to get the zero rate offset down to a couple of degrees per minute by using an "integrate and dump" technique. It turns out that many people mistakenly refer to as gyro drift is really a random walk resulting from noise.


    The errors from the two effects have entirely different orders of magnitudes. Zero rate offset is on the order of a few degrees per minute. Calibration error can give you an error of 25 degrees per second. So actually, the problem is reversed. Calibration errors can give you large errors in the estimate of offsets. In any case, best thing to do is to compute them separately.


    Best regards,





  • The main problem with gyros is the zero rate offset, which constantly drifts.  The scale factor derived from a high turn rate in 1 direction is going to also going to contain whatever the zero rate offset was at that moment.
  • OMG, bill. Every work you have accomplished is so creative and legendary. As a big fan, I will implement the algorithm in my UAV platform (both 450 heli and easyglider fixed wing) soon and share the results with the whole team.


    Thanks very much for sharing.


    Best regards,


This reply was deleted.