Quadshot progress

Today I went into the office to sort out the remainder of the electronics that have been piling up on my desk and also taking over the nearby storage surface. That took some time, sifting through the bits and pieces and putting them back where they should be.

Anyway, progress continues on the Quadshot:

I ordered the Cappuccino variant form the original Kickstarter funding which delivered the airframe, but it means I must add my own flight hardware and software.  This is what I want to do because, although I'd like to fly it, what really interests me is the software that is needed to fly it.  The hardware is already done, I have a SolderCore and the CoreMPU.  For those unfamiliar with the CoreMPU, it's a small unit containing an MPU-6050 and an HMC5883L which is a 9DOF sensor array: accelerometer, gyroscopes, and magnetometer. In addition, I have a CorePressure module that can accurately measure altitude using barometric pressure so, hopefully, a programmed controlled landing on autopilot will be possible!

Quo Vadis?

On its own the CoreMPU doesn't do much (though InvenSense's marketing of the MPU-6050 would have you think different).  What you need is an Attitude and Heading Reference System (AHRS) that fuses the data from the sensors and updates an estimation of the CoreMPU's orientation so the "strategy" software knows where the Quadshot is pointing.

I have already written the AHRS software in both fixed and floating point.  Why both fixed and floating point you ask?  Well, that's a good question, and I'll answer it here.

Fixed vs floating point

It's very easy to implement algorithms in floating point because you really don't have much to worry about with the dynamic range of the data that you're dealing with; you can deal with quantities as small as 1e-20 just as well as you can with something that is 1e+20.  So, it's a nice way to prototype an algorithm and get a feeling for how things are working out.  The downside is that you have to settle for 24 bits of precision in single floating arithmetic which works out to about six decimal digits.  And you have to live with the fact that floating point can be fairly slow, slower than fixed point in software anyway.

Now, if you are working with data that can be scaled correctly and the magnitude of the values you're dealing with lie within certain bounds, it's possible to chuck away all that floating point nonsense and use pure fixed point with scaled integers.  (As an aside, some of the algorithms I work on that implement floating point functions use scaled integers.) The AHRS lends itself nicely to a fixed point implementation because all data can be normalized appropriately:

• Accelerometer output doesn't need to be in g, all you are really interested in is the normalised vector indicating the direction of gravity so you can correct gyro drift in pitch and roll.
• Magnetometer output can be similarly normalized as a reference for the earth's magnetic field for long term correction of yaw.
• Gyro rates can be limited to 2,000 degrees per second which works out to about 35 radians per second.  2,000 degrees per second is common on many of the better gyroscopes.  Are you really going to spin at five revolutions per second around any axis?  Probably not, and if you are, your quadcopter is probably already preparing to crash...
• Intermediate quaternions don't grow too large in magnitude when passing through the AHRS and, besides, we're mostly dealing with normalized quaternions so we can use the fact that the inverse of a quaternion is its conjugate.

Progress

So how far have I come?  Well, I have the AHRS complete and I can control the motors.  What I need now is some more time to make the fly-by-wire software work nicely.  I think writing the software for this, as a combination of quadcopter and flying wing, is a bit too much for a first attempt and I may well regroup and just get the quadcopter flight software under my belt.

Stay tuned!