Power supply

I’ve an ongoing concern about the power requirements to run an RPi, IMU, Camera, LiDAR, WiFi, GPS, ESCs and soon the Sweep.

Today, I bit the bullet, and cut open a USB cable, split the red-wire, and attached my multimeter to the split wire to measure the current:

 This shot was taken during a passive flight with the RPi 3B running.  All but the LiDAR was powered by the snipped power line i.e. RPi 3B, IMU, GPS, WiFi, ESCs and camera.  When my code wasn’t running, it dropped to about 0.4A.  I was stunned at how low it was!  Adding the LiDAR and Scanse sweep (135mA and 650mA max respectively according to the spec) makes a grand maximum total of 1.37A drawn.

And that means I should be able to simplify the system significantly with just one 2.4A battery bank running everything.  I don’t quite believe it, so the next step is simply try it!


P.S. I couldn’t resist it and plugged the Scanse Sweep in and ran another flight; 1.07A was the highest achieved.  This wasn’t operating its LiDAR, just rotation, but it’s LiDAR is just another Garmin LiDAR-Lite V3, so the total with those two comes out as 1.34A, confirming the best guestimate above!


P.P.S. That went so well, I swapped PCBs to now everything is fed via the RPi micro USB cable from a 2.4A battery bank. I even attached the sweep, and it still only just touched 1A. Next step is to get the rain to stop, and try this for real.


P.P.P.S. I did a very short real flight and at all worked well, confirming each problem over the last couple of weeks was due to SD card corruption. I hope to get a video tomorrow (weather permitting), and then move on to add Scanse Sweep object avoidance.

Hermione’s I/O errors

Rather than spending ages trying to work out how to get rid of Hermione’s electronic errors, I’ve opted for a much simpler solution of powering her HoG from a 5V 2.1A battery bank.  I used to do this in the olden days, and only swappend to LiPo + regulator when I needed space for the LiDAR and camera.  But Hermione has plenty of spare space for both.  Here’s what happened:

She was doing pretty well tracking against the lawn in windy conditions, right up to the point she went nuts and zoomed off into the sky. Shortly after, the LiDAR detected she was higher than the flight plan said she should be and the killed the flight.  Once she vanishes from the shot, watch for her reflection in the window as she falls down to earth.  She landed in a soft flower bed but that still resulted in two cut motor wires.  No I/O error happened (good), but this type of radical error normally accompanies a FIFO overflow, and one wasn’t reported either.  That leaves me stuck having to keep risking these dodgy flights until I can track down the cause.

Status update

I’ve just managed to squeeze in a couple of test flights before the rain came in, and something is messing up the germs fusion code; noise from the props caught by the accelerometer is my best guess.  I’ll keep tinkering so see whether I can improve this; I’m fairly sure the theory is good, but the reality is swamped by noise.

Just in case the theory is flawed, I’ve uploaded the code to GitHub – just search for germs – it’s commented out so this code is still flyable.  Feedback welcome via comments to this post.

In passing, this update includes a minor fix to the RTF timing, and some tweaks to the diagnotics to keeps the separation between screen and logs clearer.

Finally, I can confirm the 4S cell battery works much better, though I do wonder whether the extra power from the motors has actually increased the noise due to the extra torque making the prop motion more jittery as it steps between motor coils – the motors are able to curtail angular momentum of the props better, pulling them back from overshoot?

 

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.

 

Random bits and bobs

Cotswold Jam and Cambridge Robot Wars

Unless I manage to break Phoebe before December, I intend to take her to the Cotswold Jam in September (where I’m one of the founders / organisers) and the Cambridge PiWars in December.

The code I’ll be running there will most like what I uploaded to GitHub yesterday.

Until then?

Over the next couple of months, I’ll probably just enjoy flying Phoebe and Chloe, and perhaps treat them to some new batteries – primarily so the colours match the rest of their frames!

I might add an angular (rather than motion) control version so I can show the difference in behaviours at the Jams.

Otherwise I’ll try to keep my tinkering to PID tuning unless the A2 appears leaving me enough spare CPU’s to play more with threading (QCISRFIFO.py), Kitty and Kitty++.

What I won’t be doing

I won’t be adding a human into the feedback loop – no remote control – sorry to those of you who have nagged me to do this.

I also won’t be blogging as much as I’ll have less to blog about, other than flight videos.  Also it’s clear from the blog stats people are starting to get bored…

Blog bandwidth usage

The underlying decline actually started in February but hidden behind the Build Your Own Automomous Quadcopter – Bill of Materials, Assembly and Testing (BYOAQ-BAT) articles in February, and the fact PC World included me in their 10 insanely innovative, incredibly cool Raspberry Pi projects article in March.

Blog bandwidth

Blog bandwidth

So I think for a while it’s TTFN but no doubt I’ll be back.

The wibbly-wobblies and drift

So the wibbly-wobbly flights from yesterday were due to ever decreasing battery power.  The more flights I did, the more the wobbles and drift were evident.  It’s not surprising really.  Assuming the motors are a fixed impedance (they aren’t but it’s good enough for the point I’m making) then, the power provided to the motors depends on the voltage supplied by the batteries; P = V²/R.

A fully charged 3S LiPo measures about 12.43V

The same battery at 27% charge (yesterday’s wobble level) measures about 11.43V

That means running @85% of full power.

Loss of power is handled by the PIDs to some extent – as the battery voltage drops, the effect of reduced power is compensated for by the (I)ntegral parts of the rotation and Z-axis PIDs.  But (I) is slower reacting and slower to stop reacting, giving rise to the wibbly-wobbles and drift.

This could be handled in the ESCs with the microcontroller tracking the input voltage with an ADC, and upping the pulse widths it sends to each phase of the motors as the battery power level drops.

Or it could also be done with the Raspberry Pi, and a ADC board, with the P-gain increasing as the battery power level drops.

Or I could stop running the batteries down to 27% charge levels.  I think that’s the way for now.  I bought a LiPo battery checker a while ago and it’s worth its weight in gold.

BYOAQ-BAT V: Power

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


Up to now, the HoG has been powered from the mains, but now it’s time to swap to battery power for the next article. My quad has 2 batteries – the main LiPo powering the motors, and one of those phone charger rechargable battery banks (Lithium Ion under the covers) powering the HoG. That way by using optically isolated ESCs (‘Opto-ESCs’), the HoG is electronically isolated from the power demands of the motors: the phone charger power bank provides the 5V to supply the HoG, and the LiPo powers just the motors. There is not electronic connection between them – just an IR LED and photo-transistor.

One word of warning though: some ESCs may claim to be opto but are not. If the ESC has a (U)BEC, the presence of the (U)BEC is to power the flight controller. But due to ignorance in the market, sometimes the lack of a (U)BEC has incorrectly marketed as “Opto”. I came across this with a set of “The Black Sheep” (TBS) ESCs, where the manufacturers do not mention “Opto” whatsover, but a vendor / distributor made the mistake that a lack of (U)BEC must mean “Opto” and they sold it as such.

I took a gamble and bought a set. First thing I did was attach an ESC to the LiPo via the high power wires and measured the voltage on the 3-wire cable between (brown & red) or (black & red). It should read an unstable voltage close to 0v for “Opto” as you are measuring the voltage across an unpowered IR LED. But with the TBS ESCs they measured a clear and stable 5V. There’s nothing wrong with that in itself other than the ignorance of the distributor / vendor, but I wanted to keep my HoG completely isolated from the high-current surge LiPo and provide it with a stable regulated 5V instead.

So it’s your choice whether you go for 2 batteries and opto-isolation or 1 battery and (U)BEC, but be careful on the choice of ESCs in either case.

Breaking into the bank

While waiting for my replacement battery bank, I decided to break into one of the broken ones to see how fixable it may be.

Inside the battery bank vault

Inside the battery bank vault

I ended up using a bit of a brute force and ignorance, but at least as a result I have a pretty good idea of how these are assembled, and hopefully I can disassemble another ‘broken’ one and fix it.

The flaw is that the USB B socket is only surface mount, and it seems the solder joints aren’t very sturdy; an impact of the USB B plug on the ground has torn the socket off the PCB.

So, is it fixable?  Most likely yes, had I not cut the battery wires to the circuit board safety reasins; the button almost certainly wouldn’t work, but given that just turns on the LEDs to show the charge level, it’s not a great loss:

  • the two PCBs just plug together with two rows of pins – there’s an obvious right way to do so; if your PCBs come out connected, then pull them apart.
  • Find the USB B socket – I pulled mine off trying to get the PCBs out of the case – yours may survive.  Either way, it needs resoldering back to the PCB – again, it’s pretty clear how; you’ll need stable hands as the connectors are surface mount.
  • That just leaves reassembly; assuming your battery is still connected to its PCB, replug the PSBs back together and slide them back into the case.  The battery just fits, and the PCBs have a pair of rails each to move along.
  • I suspect you may as well throw away the white button and LED covers – I think it’s these that make it hard to get the stuff out in the first case.
  • Once in, the blank white end screws back into the rails holding the PCBs
  • Finally the end-piece saying “IN” and “5V 1A” just sticks back on.

Next time I’ve got time to kill, I’ll give it a go.  What’s the worst that could happen? Honestly?  The LiPo could explode throwing a 2m flame from the aluminium tube.  Very unlikely, and very unrepairable if this happens!

To be very clear, this problem isn’t specific to the Vinsic ones; in fact it was breakages of 2 cylindrical ones from Leicke which triggered me to swap to the Vinsic ones as they looked better built and being square would sit more solidly on the quad frame.

My tip coming out of this is to never throw away those mini screwdriver kits that come out of Christmas crackers – you never know when they will be needed!

Makeover

I took Phoebe out for a flight yesterday to test a fix for the URF, but she couldn’t get the thermostat to warm up enough towards the calibration temperature for the flight to proceed.

In contrast, I took Chloe (see below) out for her maiden voyage this morning, and she reached calibration temperature in seconds, and flew better than Phoebe has ever done consistently.  That didn’t surprise me; the location of LiPo and A+ have swapped – center of gravity is now only just below the props, Chloe’s sensors are below but nearer the COG and they are protected much better from prop noise as a result.

She ain't heavy, she's my sister.

She ain’t heavy, she’s my sister.

The cause of Phoebe’s heater problem (I think) is the difference in power consumption between the A and A+.  Phoebe is an A possibly drawing 750mA; combined with the heater, drawing 500mA, I suspect that’s breached the battery bank limit of 1A, and it engaged the current limiter.

With Chloe, power convertion of the A+ is much more efficient, and I suspect that means that even with the heater, the battery bank remains happy.

So I’m in the process of converting Phoebe to an A+ and Beret – at the same time, in putting Chloe together yesterday, I found her beret PCB layout I used for her B+ wasn’t good for the A+ – it made it hard to plug in the ESC and heater wires.  So Phoebe is going to get a revised Beret layout.

Chloe and Phoebe will remain functionally different: I’ll continue playing primarily with Phoebe and her URF, while I’ll leave Chloe on the side-lines still pending a new IMU with compass and barometer.

Better batteries.

4 props died during yesterday’s testing; not because of code bugs but because of battery problems.  The DC-DC converter I use to power the RPi can take an input voltage in the range of 10v – 13v, and convert it to 5v.  This is about the same range as a LiPo battery from empty to fully charged. I think my battery is growing old (or I’ve abused it, or both), and the main symptom seems to be very short charging cycles and very fast discharge cycles (i.e. reduced capacity).  I also suspect that its internal resistance has gone up.  All this means that if the ESCs suddenly delivers a power surge to the motors, especially when the battery is already partially discharged, its voltage drops to under 10v; the DC-DC converter stops putting out 5V, and the RaspberryPi does a hard-shutdown in flight.  Of course once the ESCs are not getting PWM from the RaspberryPi, then they stop powering the motors, the battery voltage rises and the RPi boots again, but sadly no leaving any stats to analyse as these are only written to filetdown (including a flight aborted by me).. So I’ve just ordered a couple of Turnigy Nano-Tech LiPo batteries – 3S, 4000mAh 40 – 80c batteries.  WTF does that all mean?

  • 3S = 3 LiPo cells (nominally 3.7v per cell) connected serially → a nominal 11.1v battery
  • 4000mAh = the battery capacity → 4A supplied for an hour @ 11.1v = 44Wh or 158kJ of power which is a lot, though given the motors may draw 10A each in normal flight, 40A total leads to a 6 minute flight maximum
  • 40 – 80c is the constant and peak discharge rate – 40C = 40 x 4000mAh = 160A constant discharge rate or 320A peak flow. I don’t need anything like this, but what it also implies is that the batteries internal resistance is very low, meaning the RaspberryPi reboot risk is hugely reduced when under load due to much lower voltage drop within the battery itself.
  • Once missing parameter is the charge rate; the default safe setting is acknowledged to be 1C – i.e. charge at no more than 4A in the case of my soon to arrive batteries.  Some can apparently take more, but better safe than have an explosion and fire.

Net: 4 props destroyed (luckily still 12 spares in stock), 2 new batteries on the way, and post all the fixing, the first zero drift full flight Phoebe has ever done.  Sadly no video or pictures 🙁 Another day, maybe.