Hermione in wonderland.

Took her outside this morning, and the safety test without LiPo consistently threw I²C errors as yesterday.  I brought her straight indoors, still powered up, both her and my piPad and ran the same test; she worked perfectly. Curiouser and curiouser.


P.S. Shortly after writing the above, I had a eureka moment in the shower: I remembered reading LiPos don’t work well in the cold, and even the Mavic instructions suggest letting it run for a while before take off to let the battery chemistry warm out.  Next test then is to wrap both LiPos (batter bank and the main power) in bubble wrap, boot her up indoors, and then take her outside to fly.  I’ll report back here anon.


P.P.S. It worked!!!!! I wrapped both LiPos in some neoprene foam (normally used for scuba suits), set everything up and running the code and therefore the GLL and PWM to keep the LiPos warm indoors. After a couple of minutes, I lugged everything outside, and she did two flights without a glitch. Roll on spring / summer!

In the deep mid winter…

Hermione got thrown…

…up into the air at full acceleration!

It was less than -5°C when I took Hermione out wearing her salad bowl lid.  I knew the end result would be a destructive crash but I wanted to compare against Zoe’s inability to get of the ground yesterday.

Before 0.9s, things were looking promising…

Double brrr!

Double brrr!

…right up to the point something went wrong with the I2C readings of the IMU:

WTF?

WTF?

At that point she launched into the air at high speed to counteract the negative vertical distance she was (falsely) sensing.  By the time I hit Ctrl-C, she was 3m up and climbing hard towards the house roof.  When she hit the ground, she was doing about 7ms-1, so unsurprisingly, there was damage.  Luckily minutes later, the postman arrived with the replacement parts – I knew they were coming which is why I could do the flight bound to end in damage.  It’s worth noting that no “FIFO overflows” or “I2C errors” were detected at the point everything went wrong.

Here’s the equivalent of Zoe’s flight yesterday when she couldn’t get off the ground.  She was flying at about +5°C.  I cut this flight because she was sitting on the ground with the props spinning at the minimal speed.

Zoe's cold

Zoe’s cold

They were running identical code but Zoe’s IMU worked perfectly throughout.  I’m assuming Hermione has power brown outs due to her A+ and all her sensors.  I’m not sure why Zoe’s not taking off well – both she and Hermione showed the same temperature change during takeoff, and the corresponding accelerometer drift.  Next step is to take Zoe out into the sub-zero back garden and see how she reacts at that temperature.

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:

Brrr!

Brrr!

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.

A box it is then!

I’ve tried various ways to acclimatise Zoe’s sensors prior to flight.  The best so far is to set the props spinning at minimum speed, and after 5 seconds, grab a FIFO full of data (42 batches of samples in the 512 byte FIFO and 12 byte batch size), and use these to calculated start-of-flight gravity.  The props then continue to run at this base speed up to the point the flight kicks off.

The net result is a stable flight with no vertical drift during hover, but with horizontal drift of about a meter.  Without this code, horizontal drift is half this but she continues to climb during hover.

I’m not sure how I can improve this, so I’ll leave it alone for now and instead have a look at making a DIY cardboard box to keep Zoe out of the wind.

In passing, I did a quick analysis of the code size: 1021 lines of python code, 756 lines of comments and 301 blank lines giving a total of 2078 lines in Quadcopter.py.  Here’s the script I knocked together quickly FYI:

code = 0
comments = 0
spaces = 0

with open("Quadcopter.py", "rb") as f:
    for line in f.readlines():
        line = line.strip()
        if len(line) == 0:
            spaces += 1
        elif line[0] == '#':
            comments += 1
        else:
            code += 1
 
    print "Code %d, Comments %d, Blank Lines %d, Total %d" % (code, comments, spaces, code + comments + spaces)

I’ve put Zoe’s code up on GitHub as the best yet, although the either / or of vertical / horizontal drift is seriously starting to pᴉss me off.

Note that since I’ve moved the IMU FIFO into the Quadcopter.py code, QCIMUFIFO.py is not longer on GitHub; Quadcopter.py is the latest best working version and QCDRI.py is the best version that uses the data ready interrupt in case you are seeing the I2C errors like I used to.

Gravity vs. Temperature

Here’s a short and slightly chaotic indoor flight tracking IMU temperature, and the value of earth gravity from the sensors.  It looks like it takes roughly 2.5s for the IMU temperature to stabilize once the props are spinning.

Gravity is only being updated during the RTF time used to bring the motors up to near hover speed before lift off – currently 1.5s.

Gravity vs. Temperature

Gravity vs. Temperature

I think I need to separate the cooling period from the RTF period.  For a few seconds before the flight controller code kicks off, run the props a minimum speed to generate the breeze to cool the IMU.  Then read the base-level gravity at that point.  And then kick off the flight which will take less time as the props will already be half way through the standard RTF spin-up process.

Ignore the spikes in temperature;  the temperature readings are not from the FIFO, they are direct reads of the temperature register, and I’m not using the data ready interrupt to trigger these, so periodically, the temperature register is read at the same time as the IMU is updating it, leading to the spikes.

Temperamental @ Temperature

So I lied by omission in my previous post; I’d assumed Zoe would fly better in the cold (it’s only just above freezing outside), but I posted before I tested.  So I took outside, left her sampling without the props running to find her ambient, and flew her a couple of times.  Both flights were about 5m drift forwards, compared to the indoors 1m drift with the same flight plan.

So once more temperature change is critical.  I’ve previously done two different attempts at temperature control:

  1. the BYOAQ-BAT series uses the IMU temperature sensor, and a resistor to try to keep the IMU at a fixed temperature (40°C).  This was a completely OTT approach and I think I fried my IMU at one point.
  2. The Butterworth IIR digital low pass filter extract gravity from acceleration, letting through linear changes but excluding spike – this only works for the DRI code as the filter is timing critical, and required ‘ an indeterminate number of samples for the filter to settle – this is the 20s ‘warm up’ in the DRI code. It also wouldn’t handle the rapid cooling when the props start up in cold-ambient conditions.

But there are two much easier ways to do this (trust me to do it the hard way first).

  1. The base level for gravity is currently taken when the props aren’t spinning and so aren’t cooling the IMU.  But there is a one and a half second period before each flight where the props spin up to hover speed – the ready to fly (RTF) period.  Sampling gravity during this period with a complementary filter will provide a much better base-level value for gravity due to the props providing the cooling air-stream.
  2. Even simpler, popping Zoe into a little cardboard box would shelter her from the cooling breeze from the props.

Option 1 is easier as it’s a simple code change; finding or making the box is hard because there’s little vertical space between the HoG and the frame, but I’ll be keeping my eyes peeled.


P.S. I’ve just taken Zoe out into the pitch black and freezing cold and flew her for 2 short flights with Option 1. The horizontal drift has vanished, but vertical was still there: the first flight descended during hover, and the second ascended. There’s clearly some tuning to be done, but it’s looking promising, and safe enough for further testing indoors tomorrow.

HoG & CoG

What have I been up to?

  1. Phoebe’s HoG PCB is now out for manufacturing – hopefully this will fix the I2C problems and allow me to progress with adding the magnetometer (orientation), URF (height) and camera (motion) sensors into the mix.  The new PCBs are due to arrive on or before 29th.
  2. Zoe’s undergone a minor rebuild of her frame to lift her CoG nearer to prop height to reduce the swinging in an otherwise stable flight – her main battery now resides on the top plate, and her power bank underneath.  I could improve this further by getting rid of the power bank completely, but that will require a new PCB to incorporate the regulator.

Other than that, I’m flying Zoe indoors daily tuning her PIDs ready for her upcoming performances.  She still drifts, and because she’s now using the IMU FIFO code, I’m back to considering sensor drift due to temperature.  She performs best in the freezing cold with the large difference between cold ambient and her IMU operating temperature.  However I won’t be investigating this further within the timeframe of the performances.

Wrapping up warm

To overcome the reduced battery power in cold temperatures, I bought some 3mm thick adhesive neoprene foam mat.  I wrapped one of my batteries in it, and took Phoebe out to fly.  She behaved beautifully over several flights so I’ve popped the latest code up to GitHub.  Note there are no significant changes here, just temperature diagnostics and some tidying.

Neoprene wrap

Neoprene wrap

The battery is now held down by just a single silicone rubber band.  The tension in the band compresses the foam cover a little which keeps the battery locked in place, and the neoprene protects the battery from the frame on the underside – a couple of unexpected benefits.

LiPo temperature ratings

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.

LiPo batteries’ performance in low temperatures

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.