I did a flight outdoors this morning; as expected the flight was rubbish but I got the diagnostics I wanted: the IMU dropped by 0.1 degrees during the short flight – a negligible amount which rules out IMU temperature drift as the cause for Phoebe’s motion drift.
After a bit more LiPo digging I found out:
- they work best in a range of 20 – 60°C
- a modern LiPo has such a low internal resistance that it doesn’t heat up even under heavy load
- as a result, the battery needs to be charged at >20°C, and warmed up to the working temperature band prior to cold flights.
- microwaved dry rice seems to be a common way to give the batteries a pre-flight warm up.
So I need to put together a system to warm up the battery prior to flight, and insulation to maintain the heat during the flight.
The cunning plan is hatching. More anon.
I took both Phoebe and Chloe outside to fly yesterday, and things were worse than ever; both struggled to get off the ground. To be honest it was so bizarre it was almost comical. It couldn’t possibly be sensor drift so perhaps it’s the battery?
A very little bit of research (i.e. googling) soon showed LiPo batteries are intended to work above 20°C and their internal resistance rises significantly as the temperature drops below that point. That would explain why the 3S (11.1v) LiPos run so well during the summer, but seem powerless now in the colder side of Autumn.
So I wrapped Phoebe’s battery up in bubble wrap and took her outside again this morning; normal behaviour has resumed; it seems that even LiPo batteries needs a snuggly down duvet in winter to keep them warm.
I’ve got a self-adhesive neoprene rubber sheet on order from ebay to wrap around my batteries now; these’ll be my winter batteries, and I’ll leave a couple unwrapped for summer use. I’ve also bought an IR temperature gun so I can be more scientific and less speculative about the temperature the battery is running at.
I flew Phoebe a few times yesterday (with blu-tack), and she consistently drifted several meters during a 10s flight – worse than ever.
This morning I brought her indoors just to confirm this massive deterioration in flight stability was temperature related. Sure enough, indoors she just hovered perfectly:
Checking the temperature from Andy Baker on Vimeo.
I ran a quick passive exploratory test tonight, again temperature related with the blu-tack installed. The aim was to understand how much the IMU temperature drift is related to being worked hard, and how much is related to the wind from the props.
I ran a test indoors with no prop power – here’s what I got. Look at the resolution of the temperature: over an 11 second flight, the temperature range spans 35.79 – 35.93°C, or 0.14°C peak-to-peak which is tiny. I think I can safely say it’s solely environmental changes (i.e. the breeze front the props) which cause IMU temperature- and therefore sensor drift.
Passive flight temperature change
I think I need to add some more blu-tack to the underside of the IMU PCB to give it the same breeze resistance the top now has.
A bigger blob of blu-tack
Another test this morning with a bigger blob of blu-tack providing thermal insulation and protection from the breeze.
The temperature profile is much better: it dropped only 0.25°C in 11s seconds, compared to yesterday’s 1.2°C with a smaller, thinner piece of blue tack, and 1.4°C when completely exposed to the ambient temperature and breeze from the props.
Given the sensors drift about 0.1% / °C according to the specs, and a 0.1% error in gravity is 0.01ms-2 acceleration error or a 1m vertical drift during a 10s flight, it’s got to be good thing the blu-tack has made the thermal drift linear, and so the butterworth can deal with it well.
A graph – haven’t had one of these for a long time:
2 flights outdoors before the mist had gone away, so ambient temperature is under 10°C. The flights are 1.5s spinning up the blades, 3 seconds ascent, 3 seconds hover, 3 seconds descent. I’m not at all sure about the temperature scale – Invensense do not provide a scale factor to convert between temperature readings and units – I’ve just use a value which is what they told me when I got in touch with their support, but I’m not convince it’s right – other stuff their support have told me in the past about the temperature sensor has turned out to be garbage.
Anyway, to the point:
- blu-tack temperature drifts slowly and approximately linearly
- breezy temperature has peaks and troughs that correlate quite nicely to prop speed changes.
So my theory about temperature drift is to some extent proven, but
- I’m surprised the temperature drift in both is pretty much identical, I’d expect blu-tack to cool down more slowly.
- I’m also surprise blu-tack started drift down earlier, but in a steadier way.
Anyway, the net is that the butterworth will be able to filter out sensor drift with blu-tack due to its near linear drift, whereas the peaks and troughs in the breezy graph mean that temperature related drift of the accelerometer / gyro will make it through into the gravity values churned out by the butterworth, and so drift will be larger.
Both did still drift, but blu-tack was slow and steady compared to that of breezy, which I think correlates with the non-linear part of blu-tack temperature changes at the start.
So what to do? It might just be as simple as adding more blu-tack – I only used a thin shim layer, less than 1mm thick; a larger piece fixed to both size should soften that curve in the first 2 seconds.
*”Nemetic” is the adjective for the noun “nemesis” by logical derivation
I took Phoebe out this morning for get video proof of her new low drift 12 second flights. But she drifted – up to 4 meters. The code was untouched so what had changed? All I could think of was her nemesis: the sensor drift against temperature.
Phoebe self-calibrates for this prior to each flight while she’s sitting on the ground with no props moving: the butterworth is set to let through low frequency sensor drift. What was special about this morning is that the ambient temperature was low – about 10°C; during the 20s calibration prior to flight, the IMU would have warmed up to an extent the butterworth could handle. My speculation was that as she leapt off the ground immediately after calibration, the draft from the props acted like cooling fans, and because of the the cool ambient temperature, they worked very well to the extent the sensor readings started drifting faster than the dynamic calibration of the butterworth could keep up with.
This was very very speculative, but I could test the theory. By sticking a lump of blu-tack on the IMU, it was thermally insulated and protected from the wind; sure enough, the drift was much reduced. However, blu-tak is opposite of the cooling fan problem. It’s thermal insulation means the IMU could now warm up during flight as it couldn’t dissipate heat.
What’s really needed is a box to block the breeze from the props while allowing the heat the IMU generates to dissipate gradually allowing the Butterworth to keep up with the temperature drift. I’ll do some more tests with the blu-tack in the cool of tomorrow morning, but I suspect my speculation might actually be fact.
I took Chloe out onto the drive – horizontal drift didn’t exist – a perfect vertical rise and fall. There were only two flights; the first rose to 50cm but then descended slowly during the hover phase, landing gently even before descent phase of the flight plan has started. The second flight also didn’t drift laterally, but in contrast, it rose to 2 meters during ascent phase, and continued to climb during the hover phase; at that point, I killed the flight.
There’s a few possible causes I can think of off the top of my head:
- the Butterworth filter needs turning as its filtering out of gravity is lagging behind sensor drift – this is my prime suspect
- the complementary filter needs tuning as its merging of angle sources is lagging behind sensor drift – this is much less likely however, if only because it would affect lateral drift also
- IMU temperature drift between the first flight and the second – again I’m doubtful as although it could affect hover height, there shouldn’t be vertical drift during hover phase – this is what’s pointing to the Butterworth lagging too.
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
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:
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.