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,

Bill

## Comments

Well Done Bill

Best Regards

navigator

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.

regards

robert

@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.

Cheers,

Emile

@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...

best

robert

If yes it would be great to include it in the code... If only I knew how... :)

Great job Bill!

Cheers,

Emile

Jack,

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.

Bill

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,

Bill

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,

Alex

Next