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: http://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.

Views: 5368

Comment by Roy Brewer on January 18, 2012 at 6:24am

Hi Bill,

It seems we are thinking along similar lines, although I am more focused on quaternions (and related parameterizations, at least for the moment) and you are sticking with rotation matricies. Once you know omega and delta_t, you can find the "exact non-linear" delta rotation. The only downside is that the delta rotation computation requires trig functions in all representations (as far as I can tell). Are you planning to use low-order talyor series approximations in your calculations? CORDIC functions? Table lookup? Something else? Since you should know your max omega and your delta_t, you know how large delta_theta could get. I'd imagine its still pretty small such that low order trig approximations would work pretty well.

- Roy


T3
Comment by William Premerlani on January 18, 2012 at 7:07am

Hi Roy,

In the past, I have used CORDIC functions, table lookups, and low-order Taylor series, any of them could be used. I think that for this application I would use a combination of a table lookup and a low order Taylor series. I would use a rather coarse lookup table, but it would include a few coefficients for a Taylor series for each entry in the table. If one keeps the steps between entries in the table small, that would do it just fine. And, of course, you can use the symmetries of trig functions to advantage. I am thinking 256 entries in the table between 0 and 90 degrees, so the Taylor series expansion would be in terms of a delta x no larger than 0.006 radians. I It would wind up being rather accurate, without requiring much memory or CPU load.

Of course, in order to keep the accuracy from getting diluted from other sources of error, such as gyro calibration error, you will probably want to do things like in flight auto-calibration of gyro gain.

Eventually I might want to be able to support rotations at 2000 degrees/second. At 40 Hz frame rate, that would be 50 degrees per step, at 200 Hz frame rate, that would be 10 degrees per step.

Best regards,

Bill

Comment by bernienepper on January 22, 2012 at 11:13am

EE 71 - You guys are super math gods - thanks for letting me follow you discussions -

Comment by Justin on February 26, 2012 at 4:23pm

I would like to drop in a comment about the need for wind estimation in or around DCM.

I believe the original design of DCM was to *let the wind yaw the matrix*, in this way the UAV began to compensate for the wind, and could still navigate. How quickly it did this depended on the yaw drift correction. This was probably because compass corrected DCM was expensive, or rarely in place. It did well on long legs, and poorly on turns.

My opinion is that wind has no place in DCM, and it does not need estimating. the DCM should show the correct attitude and correct yaw, all the time, and not assume that the plane moves in the direction the nose is pointing. Precisely because of wind. Wind is compensated at a navigation level, using the GPS ground track. If the plane has to settle on a pronounced yaw with respect to the ground track, to move along said ground track, that is what it does. You should not need to estimate winds (which are inherently variable anyway) to get a good result, the GPS ground track reveals the wind at all times. The job of flying in a cross-wind, or flying in a variable wind is nothing to do with the DCM, and is everything to do with the navigation layer. A good navigation layer responds dynamically to the presence and variability of wind, or the difference in ground speed and air speed.

I'd be interested to know where exactly in a full sized plane wind is continually estimated and input into flight control movements. For final approach a guess at wind is useful but ultimately how the plane responds second by second trumps any wind estimation. It can be inferred, yes, by your movement over ground versus the compass heading of the nose, and your airspeed, but is merely an interesting and often variable by-product of navigation over ground, rather than a vital bit of information needed up front. I feel this idea has sprung from the original DCM paper, which talked about the need for wind estimation to improve the way yaw was being drift corrected.

Someone convince me that continual wind estimation and input (where?) is vital for an autopilot.


T3
Comment by William Premerlani on February 26, 2012 at 4:36pm

Hi Justin,

I agree with you. In the latest version of MatrixPilot, wind related computations have been moved to the navigation layer. The computation of the direction cosine matrix elements is now "pure".

We have worked out a way to estimate airspeed and wind speed without needing air flow sensors. The estimated wind speed is then used in the navigation calculations.

Airspeed is used for speed control.

Best regards,

Bill Premerlani

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2014   Created by Chris Anderson.

Badges  |  Report an Issue  |  Terms of Service