Blogs

Propeller DCM

Posted by Jason Dorie on April 13, 2011 at 3:30am

This is a Parallax Propeller chip running a partial implementation of Premerlani and Bizard's work on Direction Cosine Matrix computation for orientation sensing. I'm hoping to use this in a quad-rotor without a GPS or magnetometer - I wanted to see how good the algorithm was at stabilizing pitch and roll.  So far it looks very promising.

All the work is done on the Propeller itself. It reads the gyro and accelerometer values on one core, and computes the DCM from those readings on another core. At this point the code is still written in the high-level language, Spin. Since all the math is fixed point, there's a strong chance I won't actually have to write an assembly version - I haven't timed it yet, but my update loop is running at 200Hz, so it's at least that fast.


This post over at the Parallax Forums contains source:http://forums.parallax.com/showthread.php?131022-Propeller-DCM-Now-with-source
Tags: dcm, imu, parallax, propeller
E-mail me when people leave their comments –
Follow

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

Join diydrones

Comments

  • Developer
    John Arne Birkeland April 14, 2011 at 4:05am
    "un-drifting" gyros with a mean average offset, work to a certain degree and does produce better results. But gyro drift is not constant, so it will never be perfect. The best approach I have found is to read the gyro as often as possible (helps compensating for linear reading of nonlinear sensor) and integrate the values (with drift correction) for further processing.
  • Jason Dorie April 13, 2011 at 5:50pm
    You know, thinking about it a little more, you might be onto something. You're right in that if you have a measurable quantity that you can compare against your axis you should be able to un-drift them... I think it might actually work. It'd make it a little harder to use the rotation values, since they'd be off-axis, but the DCM algorithm should be able to work in an arbitrary space as long as you know what it is.

    It might be moot - I've gotten the gyro drift down very low as it is. If you look at my other video (First Crash) toward the end, I take my hands off the remote and let it hover for 10 seconds or so. Heading and level don't really change, and that was without the DCM algorithm - just integrating the gyro readings.
  • Simon Wood April 13, 2011 at 5:10pm

    This might be due to my (mis)understanding of how drift compensation works. I'm thinking that you compensate for drift on each gyro axis separately (as they would all be drifting at different/slowly varying rates anyhow).

    If you are static and have a 'down vector' which has enough of a component in each of the XYZ axis/planes, then can you confirm/cancel out the drift for each axis separately (prior to using the gyro values in the DCM)?

    I'm not suggesting this would be a solution for everyone, but for a slow moving quad it might work...

    Simon.

     

  • Jason Dorie April 13, 2011 at 12:35pm
    Intuitively, I think what'll end up happening is that you'll end up drifting around whatever vector you use as "down", since you don't have a second vector to produce a valid frame of reference - the problem is that you can't generate a stable orientation frame from a single direction vector - you need two of them, and then a cross product can infer the third.  It's why the GPS-based DCM algorithm can't properly correct a plane flying straight up - once the gravity vector and the heading vector coincide, you only have one vector.
  • Simon Wood April 13, 2011 at 12:09pm

    I did mean just in the yaw direction... since it is just 'a degree every few seconds' you could try my 'to cheap for gps' idea. I mentioned this before a while ago and am too stubbon (or stupid ;-) to understand why it would not work for heli/quads. I never got it proven one way or the other...

    If you place the sensor pack at a weird/offset angle, the gravity vector will be 'in' all of the gyros and will hence be able to compensate for drift. For normal level flight this should be stable, for short agressive manovers you might find that a gyro is uncompensated.

    If you have a habit of continously flying in a tight circle you may have problems...

    Simon

  • Jason Dorie April 13, 2011 at 11:50am
    Simon - if you're referring to pitch and roll, those are corrected by the accelerometer, so they're spot on most of the time, and re-align within a few seconds if they go off. Only the yaw is uncorrected. (I just realized you may have meant the other axis as well)
  • Jason Dorie April 13, 2011 at 11:48am
    Simon - There is no yaw correction in place now, so it does accumulate integration error. At the moment it's well less than a degree every few seconds when stationary. Adding correction from a magnetometer, compass, or GPS should be pretty straightforward and would eliminate that.

    Stephen - I haven't decided yet whether to put a compass on it or not. I wanted to see how bad the drift was without it, since I'm planning on making this "augmented" flight, not completely autonomous.

    I do plan on sharing the code, and so far it's written for readability as much as anything else. I started with a from-scratch implementation on the PC, then ported that to the prop once I had it all debugged. At present there's no control scheme of any kind - it's just the attitude estimator, but getting there from here shouldn't be too hard.

    I'll post what I have within the next couple days. Sleep, work, and life need a little time right now - I've been up 'till 4am the past few nights getting this done. :)
  • Simon Wood April 13, 2011 at 10:45am

    If left flat on the table does it maintain correct rotation (on the screen) after a long period of time?

    If not, what sort of duration does it take to become un-synced and does it self correct when (board is) moved?

    Simon

  • simonl April 13, 2011 at 10:05am
    @Jason Dorie: Nice to see a fellow Propeller-head on here. I'm also in the throes of building a Propeller brained 'copter - mine's a Y6. Still building the hardware, but sure could use a copy of your DCM code if you'd be happy to share it.
  • Stephen Dwyer April 13, 2011 at 10:01am
    I was just wondering if you were planning on making the code available, and also whether you were going to include the yaw and velocity correction references (ie magnetometer/gps heading and body velocity) in the code, even though you were planning on trying to avoid using these sensors for your quad? With that kind of update rate, could provide a bit better performance as a standalone IMU than an Arduimu. Awesome work!
This reply was deleted.