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
Thank Bill, Much good stuff at Franks site!
I will try for 29.000 feet with small beefed up (two tubes with carbon rods between) Quest Nike Smoke with G-250 on top of second stage booster a J-500, on top of 3rd stage with H-285 it will have live TM on OSD down link @ 5.8 Ghz. Flight Computer will control all 3 stages and dual deployment using nichrome wire to cut loose main chute AT 700' I hope I can get it all in the small nose cone.
Mark/Bill...
Better site ref is www.RocketElectronics.com 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
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:
http://frankhermes.com/
An article on Frank's system:
http://frankhermes.com/cos_article_teaser.htm
Frank has also written a multi-part article that is published in Rockets magazine.
Best regards,
Bill
@Bill - Very nice!
@Gary - LOL
I also like the idea of airframes turning at record player rates. Very made me smile.
Excellent work chaps, excellent.
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,
Ric
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,
Bill
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?
-
1
-
2
-
3
of 3 Next