In the deep mid winter…

Zoe can’t be flown…

I took her out this morning, controlled by the accelerometer and gyro, but with the LiDAR and Camera running in parallel passively so I could do a comparison.  But she could hardly drag herself off the ground.  However, in her world, she thought she way climbing throughout:



The props span up to hover speed for the first 0.1s, then she ‘climbed’ for 3 seconds and then “hovered” after 3 seconds.  By 5 seconds she was on the ground with the props spinning at the minimum setting.

Throughout (orange line) she thought she was climbing, which is why she struggled to take off.

If you look at the IMU temperature plot, as she starts to climb, it seems the propeller wind cools off the IMU, and that’s shifting the scale of the accelerometer significantly.  The problem is caused because a snapshot of gravity is taken before takeoff, and then is used throughout the flight to extract net acceleration.  That works fine when the temperature is in the teens, but it’s about 5°C today outdoors.

I’ve seen this in the past, and tried lots to do it either by calibrating the accelerometer against temperature – all I got from that was a beer fridge in the office – and using a butterworth low-pass filter to extract gravity dynamically during the flight – I can’t remember how well this worked but I assume “not well enough” since I dropped it from the code a while back.

What she really needs is a wind-proof jacket or scarf to shield her from the draft from the props.  I might try a duct tape wrap.  Alternatively, I could just bring her indoors into the temperature range where the accelerometer doesn’t drift; I’m just a little nervous as I’ve just popped into the lounge, and the scars on the ceiling are quite revealing of past exploits! Finally, I could take Hermione and her salad bowl lid to see if that helps.

Travel sickness

I took Phoebe to Cheltenham on Wednesday to check out the new location for the Cotswold Raspberry Jam (tickets still available but going fast).

Yesterday (Thursday), I took her out for a few more ‘confidence building’ test flights, and she was a changed quad – she climbed too fast and continued to climb during hover and she drifted significantly.  Oh sh1t – we have the perfect location to show her off, but somehow she was no longer fit to be shown.

Today (Friday), she’s back to behaving normally again so I’m concerned her accelerometer had drifted in transit to Cheltenham – while carrying the case, her Y axis was pointing down, sensing gravity and her Z axis was not unlike normal – that matches the drift I was seeing.  I hope that’s not the problem as that would ruin the chance of an indoor flight at the Jam – hopefully the weather will be good on the day, so at least an outdoor flight should still be possible.

Anyway, while trying to work out what was going wrong, I reviewed a couple of things I’d not done for a while.

The first is prop balancing – using my Dremel to lightly strim the underside of the props so that they have a matt surface, and they balance well on one of the maglev prop balancers.  The matt surface allows the air to flow over the props smoother which leads to better more efficient air-flow, and reduced turbulence resulting is greater lift.  For that reason, I used P1000 wet and dry sandpaper to matt and smooth both top and underside of the props.

Balanced blade

Balanced blade

The other is (controversially) to re-add 0g calibration but only on the X and Y axis – the primary directions of drift – in such a way it can be done indoors from a relatively flat surface prior to demo flights, but also can be disabled easily without the risk of coding errors with a destructive resultant flight.  Calibration takes half a second, and results are stored to file, and reloaded each flight; if the calibration is not possible, then the calibration file settings can be set to 0 to disable it, thus dropping back to Phoebe’s performance from the last few days.

I don’t think either of these were related to her travel sickness, though now done, there’s no point in undoing them again!

Oh well, it was worth a try…

Sensor vs Reality

Sensor vs Reality

Phoebe thinks she’s drifting left according to the sensor data shown in the graph, but in real life, I watched her drift right towards the house in compensation for what she perceived as leftward drift. All I can do about that is 0g offset calibration, and all previous attempts have failed. It’s not just Phoebe who can see a brick wall heading her way.

Zero-calibration vs. Zero-G calibration?

I’ve been so focussed on sensor calibration and specifically accelerometer calibration, that I may be missing the blindingly obvious.  As I’ve said many times, I simply cannot believe that any of the off-the-shelf quads out there bother with sensor calibration to anything like the extent I am, and yet there are commercial UAV’s out there which can hover at a fixed height without lateral drift.

It’s the fact these exist that’s stopping me from accepting that HoG is as good as she can be.

So what if I abandon calibration, and instead just rely on the Butterworth filters to track drifting offsets in the accelerometers?  That code is there currently, working in parallel with the calibration code, and seemingly working well to manage vertical drift despite this being the axis with the least reliable calibration of the sensors.  So what would happen if I throw away all my calibration code and just use the Butterworth filters to extract the accelerometer offsets?  The answer is this:

Zero-G calibration vs. Zero-calibration from Andy Baker on Vimeo.

Not perfect, but at the same time, not much different from the calibrated flights, and possibly actually slightly better.  The wind was picking up at this point making life hard.  I also think there are some extensions I can add since the angle calculations still are using the raw values in this flight, and that’s almost certainly the reason for the drift to the right.  If I can use the Butterworth gravity offset readings to correct the angles also, I think I can get even better performance against drift.

More zero-gravity temperature trend graphs



So these batches of zero-g offsets were gathered with care. Each cluster is about 20 samples.  They look good, don’t they, but I’m struggling to trust them.

Here’s why, moving from left to right for the clusters of samples:

  • the leftmost clusters were taken in the garage (ambient 10ºC)
  • for the next pair of clusters, HoG was powered up in the beer fridge stuffed with ice blocks (ambient << 5°), readings taken, then moved out of the fridge (ambient ≈ 20°C) and more readings taken
  • finally the last pair of readings were taken with HoG booting in the office (ambient ≈ 20ºC), and then moved back inside the fridge (ambient << 5ºC).

Or to put it another way, following any set of data left to right, the estimated ambient temperature was 10, 5, 5, 20, 20, yet the corresponding temperature read from the chip is more like 19, 21, 29, 31, 32.  The biggest discrepancy is between the two 5’s in ambient and the 21,29 pair as reported by the sensor.  The next is the fact the garage reading of temperature is lower than the beer fridge packed with ice!

But I don’t have any choice but to use this data for best estimating zero-g offsets against temperature.

Why do I care so much about getting this accurate?  Because the difference between the minimum and maximum varies between 0.03 and 0.1 ms-2 – and that the difference between a stable hover and accelerating in any direction.

Or to make it more explicit, in my back garden, the longest flight I could hope for is 7s before HoG smashes into a brick wall, or flies up over the roof top unless I get this tuning absolutely accurate.

Annoyingly, there are gale force winds for the next to days, so I won’t be able to test the results of this latest calibrating for a while.

Zero-G, ambient and calibration

OK, so I think I’ve got my head around this.  These are the readings taken from the beer fridge packed with ice blocks.

'ice cold' beer fridge

‘ice cold’ beer fridge

Clearly the absolute temperature readings are rubbish, but also clearly, the temperature range of the test is only about 1.5°C.  If you look at yesterday’s graph, these numbers above are the tight little clusters of samples around the 25 – 26°C.  The fact they are tight clusters is because the ice-laden beer fridge was able to hold the chip temperature stable while the testing went on.

Outside of such a temperature controlled environment, the chip temperature changes and so you get the spread of offsets shown in the graph.

So what does this mean?

  • first, for every flight, read the garbage “ambient” value as soon as the chip is powered up – ideally this means boot in the same environment the flight is going to happen
  • throughout the flight, track the changes in temperature – i.e. (raw temperature – “ambient) and use this value to work out the change in the offsets due to temperature drift.

The next step is calibrating offsets against the difference from ambient.  It’s going to take something like booting HoG and reading ambient, and then have her hard loop reading gravity in that environment whilst periodically logging the change in (temperature – ambient) versus offset.

I’ll report when I’ve got some data.



I think I’ve finally worked out how the zero-g offset drift against temperature needs doing, or in fact, why it doesn’t .

But first I feel the need to share this set of figures that got me there:

Ambient Offsets

Ambient Offsets

To get the values for these, I booted HoG in a variety of temperature environments, and read the zero-g offsets.  “Doesn’t look too bad”, you may think?  Except the environments ranged from a beer fridge packed with ice-blocks, through to our warmest room in the house with the heating on full – the graph should show a temperature range greater than 20°C, and yet there’s only 7ºC.  And 7ºC is about the temperature rise from chip-boot to 1kHz sampling.

I’ve had concerns previously about how this sensor works – in the spec, the absolute temperature equations uses “ambient” without providing a concise definition of what that means. But assuming ‘ambient’ is an arbitrary value measured at chip-boot, then regardless of the environment (e.g. Arctic vs. Sahara), then the zero-G offsets need to be calibrated against the temperature difference between current temperature sensor output and the ‘ambient’ temperature sensor when first powered up – in this case 7ºC.

And that means that as long as temperature doesn’t drift too much during a flight (i.e. power her up in the environment she needs to fly in), then the offsets are nearly static (according to the spec ±1.5mg/°C or 1.5cm/s/s/ºC)  , and can be read in any temperature-stable environments and used in any other environment.

I think that means I need to change my calibration method so read the ambient, and then all changes to ambient while doing a 10s 1kHz sampling run.  I’ll try that in my home Arctic and Sahara and see if it holds true.

Zero g offsets against temperature

Zero-g offsets against temperature

Zero-g offsets against temperature

The graph shows the values reported by the accelerometer (in units of g) at various IMU chip temperatures (about 10° above ambient) with a linear trend line courtesy of Excel. The x-axis looks great – virtually zero drift against temperature; ironically although the z-axis looks awful, the combination of this, plus the 4th order, 0.1Hz Butterworth gravity filter means that height is measured accurately, and is sustained throughout an (albeit short) flight.

But the y-axis offset does drift against temperature, and the spread of samples is quite, well, spread compared to the x-axis. This may well be the primary cause of the horizontal drift shown in the last couple of videos.

I think the next step is to move to the local park where I can check by sight whether the drift is of fixed velocity (which rules the above out), or fixed acceleration (which backs-up this speculation) without worrying about walls.

BYOAQ-BAT VIII: Calibration

If you haven’t already, please read the previous BYOAQ-BAT articles first – just search for the BYOAQ-BAT tag.

Calibration used to warrant a vast article, needed special equipment and electronics and took at least an hour as HoG had to be separate from her frame.  With the discovery of 0g offsets the other day, calibration is quick, requires only a flat vertical wall and horizontal floor, and assuming your quad frame is sturdy and the PCB is horizontal, the calibration can take place with the HoG in place in her frame.

HoG sits on the most horizontal surface available.  Use a spirit level if possible, otherwise use a hard floor or kitchen worktop (not a wobbly table and not carpet). Run

sudo python ./ -g

Do this a few times, and then look in There are 3 columns representing acceleration in the X, Y, and Z directions respectively. What we’re interesting in are the zero-gravity offsets: with HoG sitting on the floor, with her Z axis aligned with gravity, the values in the first two columns are the X and Y zero-gravity offsets. Change the code to use these values.  Here’s what I got for HoG in her test on the floor after averaging several readings.

 self.ax_offset = 1166.28
 self.ay_offset = 654.5
 self.az_offset = 0.0

Next do the same, but with HoG held against a wall – i.e. a vertical surface where the Z axis is in a 0g environment. Update the offsets above with the Z axis offset:

 self.ax_offset = 1166.28
 self.ay_offset = 654.5
 self.az_offset = -2688.76

That’s it, job done. These values are specific to each IMU – do not use these values for your quad – all hell will break loose!

Maiden voyage

HoG lost her flight virginity today, and she lost it with enthusiasm – a little too much to be honest.  Three second flight plan – one second takeoff to 0.5m, one second hover and one second descent.  All maiden flights are a huge gamble: in HoGs case, she had

  • new arms
  • new props
  • new motors
  • new frame
  • new calibration method
  • new butterworth filter parameters.

Given that, I’d say her performance was surprisingly good!

She took off vertically from sloping ground.  That alone is nearly an unqualified success.  For it to have been a complete success though, she would have stopped at 0.5m off the ground and hovered.  Instead, she whizzed up to 3m  and then I hit the kill switch even before she had the change to try to hover.

A few lessons learnt even from such a short flight though:

  • zero g calibration seems to work, but it needs doing for X, Y and Z axis
  • having dlpf set to 180Hz rather than the normal 20Hz probably wasn’t a smart move regardless of how good the Butterworth might be
  • aluminium arms bend and don’t straighten when they hit the ground at over 7.5ms-1!

New arms are on the way and will arrive tomorrow, allowing me to do the zero g calibration of the Z axis also!

But what’s Zero-G calibration, and how do you do it without going into space?

Historically, I’ve been jumping through hoops trying to get sensor calibration stable, controlling the temperature to 40°C while rotating her in the calibration cube to measure ±g in all three axes to get gains and offsets.  Yet despite all that effort, the sensors, and hence Zoë, still drifted, even if only modestly over time, still enough that she couldn’t fly in the back garden for more than a few seconds without hitting a wall.

The move to the MPU-9250 for HoG from Zoë’s MPU-6050 IMU initially seemed a retrograde step – it didn’t seem to be able to measure absolute temperature, only the difference from when the chip was powered up.  And that meant the 40°C calibration could no longer work.  Lots and lots of reading the spec’s yielded nothing initially,

But in passing I’d spotted some new registers for storing accelerometer offsets to allow them to be included in the IMU motion processing.  That suggested there was a way to get valid offsets.  Additionally, again in passing, I’d spotted a couple of Zero-G specifications: critically that the Zero-G level change against temperature was only ±1.5mg / ºC.  That means an offset measured in a Zero-G environment hardly drifts against temperature.   And a Zero-G environment doesn’t mean going up to space – it simply means reading the X and Y axis values when the Z-axis is aligned with gravity.  So with HoG sat on the floor, X and Y offsets are read, and then holding her against a wall gives the Z offset.  So calibration and updating the code takes only 5 minutes and requires no special equipment.

Delight and despair at the same time: delight that I now had a way forwards with the MPU-9250 (and it would work with the MPU-6050 also), but despair at the time and money I’d spent trying to sort out calibration against temperature.