Butterworth, 2nd order, 0.1Hz cutoff, 71Hz sampling

Zoë with 2nd order, 0.1Hz cut-off and 71Hz sampling butterworth IIR filter from Andy Baker on Vimeo.

Currently the code which calculates the Butterworth coefficients and implements the filter only covers 2nd order – I need to do some more reading / understanding to go higher.  I suspect 4th order at 0.2Hz might be better.  Cut-off and sampling frequencies are already configurable.

The accelerating drift to the right suggests calibration errors rather than a take-off problem which normally leads to a fixed velocity drift. Calibration cube out again, I think.

Wow, what an exciting day!

Despite the bitter temperature, Zoë’s been out lots over the past few days to see what the new temperature control was like regarding vertical climb during hover.  She takes just over a minute to warm the sensors up to 40ºC and for the sensors to stabilize regardless of ambient temperature. And for the first time since I swapped to motion control processing rather than angular control, she just hovered – she didn’t drift up or down during the hover phase:

Zoë in the snow from Andy Baker on Vimeo.

The ‘fix’ to the problems I’d been seeing due to wind chill was solved by a lump of blue-tak covering the MPU6050 to help keep it warm.  Well, that along with a complete rewrite of the start up code that waits for temperature and sensor stabilizationbefore anything else happens.  The transformation is amazing!

I’ve also recalibrated the sensors to be confident as she’d been showing a consistent slight drift to starboard. Clearly that’s still there but much better, though also clearly, I need to work on the landings / shutdown to make sure the ESCs have shutdown completelly before the PWM signal to them is turned off!

You might have spotted the golden foam dome has reappeared on her underside to protect the battery and keep it warm.  I’m not sure I’ve ever mentioned what the landing dome is: it’s a Slazenger Shortex foam tennis ball sliced up with an electric carving knife normally used for the Sunday joint!

I did run a few more flights after this one, but one of the blades had fractured, so they were a lot less good.  As always, it was a right hand blade that got broken, so no more flights until the new ones arrive, probably tomorrow.

Here’s the blade graveyard, just to give you an idea of how many I’ve got through in the last week or so.  These are only the ones where the blade was ripped completely off the prop.  Ones where the prop still has two blades, but with one damaged go into the bin indoors.  Each prop is £15.  Ouch!

Blade graveyard

Blade graveyard

Code updated on GitHub

I’ve reworked the code so the bulk is a python import library (Quadcopter.py), and qc.py is now just a shim header to import the bulk of the code.  Imported libraries are pre-interpreted and the results stored in bitcode (Quadcopter.pyc).  If the .py code hasn’t changed since the previous run, then the interpreter picks up the .pyc file instead; the .pyc file is automatically generated if the .py and .pyc don’t match.

Why bother?  I thought I’d see what sort of performance improvement it would yield.  The answer is minimal – perhaps 2% – not really a surprise as the bulk of the processing is reading the sensors, and that happens at a fixed period that the code can never go faster than, but it was worth a try, and now it’s done, I’ll leave it in place on GitHub.

In passing, you may have noticed that Phoebe’s new built is not using the URF; that’s because I’m missing a connector that Farnell have on back order, but in the meantime I need to test the physical rebuild.  A Cube Calibration of gravity seems to have sorted her consistent forward drift, and now I have the same sort of sluggish self-correcting drift I had previously.

Next step is to do a double check on horizontal velocity tuning, as I think I may not be putting enough P gain into the PID.  Weather looks good this weekend, so I’ll let you know how it goes.

Countdown to CamJam: 2 days left

I’m off to London tomorrow morning, and up to Cambridge after work, so I’m packing her up ready for her journey.

She’s probably doing the best she can given the inaccuracy of the sensors, but I’m still not quite confident she’s good enough for an indoor demo, based upon a few tuning test flights this morning.

So fingers crossed for a safe journey and a good day on Saturday, and I’ll update you on the results.

Wish us luck!

P.S. Just cheated and run her through the calibration cube again with the aim of getting the best possible set of sensor readings for the show.

Duct tape is like the force…

it has a dark side and a light side, and it holds the universe together.

Tenuous link, but I thought I’d share my final version of my calibration kit:

Calibration Cube

Calibration cube

  • There’s a 10mm x 500mm x 500mm acrylic base with corner wingnut bolts and a spirit level to create a stable flat horizonal platform
  • Upon that is a 5mm x 400mm x 400mm cube with one side missing
  • Inside that is my drone, but with blades removed
  • And binding it all together is duct tape.

The duct tape sticks the drone into one of the corners of the cube, and to be base, so that as the cube is reoriented through 90 degrees to stand on all 6 sides, the drone moves with it. Readings from the accelerometer over 10 seconds in each direction are each averaged and offseted to ensure each direction reads true.

There’s one final step not shown here, done separately where the drone sits on the horizonal platform and the vertical z axis is read over 10s, and averaged to a factor to ensure it reads 1g. That’s critical to ensure the z axis reads 1g when the x and y axes read zero representing a stable hover.