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: https://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.
Comments
I think this grammar needs some explaining: "the old clunky DCM implementation". The "clunky" part of this paragraph refers to the "old implementation", not the "DCM". In this sense we are talking about "the old (previous) and clunky implementation of the DCM algorithm", as opposed to "the implementation of the old and clunky DCM algorithm".
We make no claims to have attempted or presented a comparison between these two algorithms in the general case.
For those reading this thread that are completely new to the maths for representing orientation ( e.g. DCM and Quaternions and Euler Angles ), I have found this book ( 3D Math Primer for Graphics and Game Development ) to be helpful. It is for undergraduates, starts with first principles, gives a good overview of the strengths of each representation, and when to use them. The book works right through to examples of code and libraries in C.
Best wishes, Pete
Yes, because today you still need to switch back and forth between the quaternion and the DCM representations for feedback purpose, the DCM algorithm is not so "clunky" !
And thank you Bill for having given DCM to all the DIY Drone community a couple of years ago. If somebody finds an algorithm as straightforward but more accurate, please tell us about it. But don't bite the hand that feeds you ! :)
Oh yes! Woops, good spot Bill. 3x3 is 9 but the DCM is a 3x3 matrix ... !
Yes, perhaps "clunky" wasn't the best word there! I just got a little carried away with the fact I had got my gyro updated variables down from 9 to 4, I guess it satisfied my mathematical "less is best" brain!
But I can certainly see why you have both the DCM and Quaternions stored in your latest version of MatrixPilot. In the ROFL code we recreate parts of the DCM from the Quaternion for accelerometer feedback purposes. At a later date I'm going to see if it's possible to use some "complex " - hehe (sorry, weak joke) quaternion maths (which I am still learning, it has many subtleties!) to take a more direct route. But for now, both representations have their merits, and it's possible that the shortest route to the accelerometer feedback is indeed via the DCM elements.
Hi Henry,
Very well said, a good description of the situation. The only statement that I would take issue with, it must have been a typo, was:
"The DCM is a 9x9 matrix
The Quaternion is a 4x1 vector."
I am sure that you meant to say:
"The DCM is a 3x3 matrix
The Quaternion is a 4x1 vector."
And I would like to follow up on your statement, "Both of them are control specialists and looked rather disparagingly at my linear approximations!"
I agree with your control specialist friends. When I ever get some time, I am going to redo the core IMU and control computations of MatrixPilot to eliminate a few of the linear approximations that are usually made, and use the exact nonlinear equations instead.
I also agree with you, that it would be best for everyone if we provide the community at large with useful information.
Regarding a comparison of rotation representations, an obvious thing for folks to do is to look at the wiki entries for "rotation matrix" and for "quaternion rotation".
At the risk of repeating myself, the best side-by-side comparison of matrix and quaternion representations is done in Robert Mahony's papers on the subject of control of VTOLS. Mahony is an advocate of quaternions, but in his papers he does a parallel treatment of matrix and quaternion formulation of his ideas.
Finally, I want to point out that the latest version of MatrixPilot uses both matrices and quaternions. I have found a few places where quaternions were better than matrices, so I bit the bullet and used them in those places. I have routines for converting back and forth, they do not take much CPU power or use much memory.
Best regards,
Bill
This is a good discussion! I have been following it closely :) I can always learn a thing or two about hardware interfacing! I wrote much of the DCM code and the quaternion implementation we are now using, and I have already had it scruntinized by two of my colleagues here at Cambridge. Both of them are control specialists and looked rather disparagingly at my linear approximations!
I responded rather witheringly that if their more complex and capable code was ready, I wouldn't have had to write this code to fly the airframes I have designed in the first place! I guess it's just a question of time, at Universal Air we have an astonishingly fast development rate. It's crucial to be aware of the limitations I agree, but right now if any of my airframes are rotating too fast for my algorithm to keep up, it's more likely that I've just flown into a tree by mistake and lost a prop or two!
For anyone reading these comments and working out what to take away from it about the DCM and Quaternion systems I'd like to reiterate some of the points already made:
The DCM is a 9x9 matrix
The Quaternion is a 4x1 vector.
They are both useful for different things BUT express the SAME information, you can derive one from the other.
They both state the relative rotation between one coordinate frame, and another.
The DCM is easy to visualise, depending on which way you have it set up, the rows are the unit vectors of coordinate system A in coordinate system B, and the columns are the unit vectors of coordinate system B in coordinate system A.
The DCM is great for doing dot and cross products with other vectors provided by other sensors.
The Quaternion stores all the information in less variables and takes less updates.
NEITHER suffer from gimbal lock. This is a problem associated with the EULER angle system only (but can be avoided).
In a flight computer both are essentially an integration of the gyro signals. Remember, gyros give rotational speeds, the DCM/ Quaternion expresses rotational position (angles). Speed integrated = Position.
This integration can be done in a number of different ways, some are more accurate than others, typically extracting more accuracy requires more processor time.
Bill, feel free to add anything to that list that you think might be helpful to others reading this. More point in us telling other people things that might be useful to them, rather than each other things we already know, heh heh. Though one thing could be useful...do you know of a list of useful papers/sources around this subject? I have read quite a few now and thought it'd be beneficial if I posted a little list of the best, if one doesn't already exist!
Best wishes,
Henry
Hi Henry and Yuan,
One more question, and then I will try my best to not ask any more questions or make any more comments...
Perhaps I misunderstood your statement "the old clunky DCM implementation".
Did you mean that using a direction-cosine-matrix for autopilot computations is inherently clunky? If so, I strongly disagree.
Or perhaps did you mean that your implementation of DCM was clunky? If so, I cannot argue the point.
Best regards,
Bill
Hi Yuan,
Hardware interrupts are nice to have. They should allow you structure your code so that there are no blocking operations anywhere. Blocking operations are a bad idea. They can cause code at that interrupt priority or lower to lock up, and they waste CPU cycles.
Best regards,
Bill
The gyro is specced to 2000 degrees/second, this does not mean we intend for the quad to be actually rotating at 2000 degrees/second.
Thank you kindly for your multiple links to your post on this topic. I can assure you that we are well aware of the limitations of control systems and sensors, and we are giving consideration to any issues that may be caused caused by them when the quadcopter is operating within its designed parameters.
Hi Yuan,
Another question about the gyros...are you doing anything about the calibration error? The spec sheet on the ITG3200 lists a gain variation of 6%. At 2000 degrees/second, this is an error of 120 degree/second, so there could be an accumulated error of 120 degrees in 1 second, unless you either manually calibrate the gyros, or use some sort of in-flight gyro auto calibration technique.
Best regards,
Bill
-
1
-
2
-
3
-
4
of 4 Next