Keeping the SkySpy under control…

Here’s the remote control I’ve put together.  Hardware is complete, and software isn’t too far off; all that missing is the message definitions that the controller sends to SkySpy and the code on the SkySpy to act upon those.  But before then, I want to get this controller to be a wireless access point, so that I can test the pair outdoors without needing to somehow connect them via the internet wireless phone hub in the house.

SkySpy Controller

SkySpy remote control

There’s a couple of digital joysticks where each has a switch too.  The left-side one will control up and down, the right side, forwards, backwards, left and right, and I’ll be using switches to trigger automated stable take-off or landing plus pressing both together will be an emergency shutdown.   It’s the switch actions I’m aiming to achieve first, and I think it’s gonna be a lot of trial and error – hence my need to get out of the house to do the testing, and therefore the independent WAP.

Other minor details – there’s a Ninja PiBow, a Lithium Ion battery and 3 breadboards on here.  The boards are particularly  perfect as they have six rows of connectors instead of five, and the power track points are aligned with the main board connects.  Together that means more connectors, more densely packed, and in this case, that means they fit under the Ninja Pi posts snug as a bug in a rug.

You’ll also note the +3dB antennas used in preparation for outdoor use both on SkySpy and the controller.

Lithium Ion Battery Power

All of my headless projects use Lithium Ion batteries.  These are made up of 1 or more battery cells which each produce 3.7V and potentially many amps in a small, light package.  Their only downside is you need 5v to run a Raspberry Pi, and so need to add some form of regulator.  My three projects have 3 different power requirements, and use 3 different regulator circuits which I thought I’d share:

  • Turtle needs a 5V supply able to supply up to 3A for the stepper motors.  This means starting with a 2 cell combination delivering 7.4V.  However delivering 7.4V at 3A means 2.4V (7.4 – 5) @ 3A is wasted as heat – given it’s a recharchable battery, I don’t really want that level of waste (nor heat melting the Lego Turtle!).  So the turtle uses a low drop out, switched mode regulator LM2596T-5.0 with the circuitry as suggested by the data sheet (a schottky zener diode, a couple of electrolytic capacitors and a 33uH 2.5A inductor).  This has proved perfect in all but one respect – the LM2596T has 5 pins packed into a TO-220 package – that means the pins are closer that the standard 0.1″, meaning they need to be bent carefully to fit.  I broke one doing so, so caveat emptor!
  • SkySpy has an 11.1V LiPo (Lithium Polymer) battery to supply up to 30A to the blade motors.  So the low-drop out is not needed in this case, but since the drop-out is now 6.1V at up to 1A for the Raspberry Pi, I still don’t want to waste the power; once again another switching regulator steps in: 78SR105HC. this one is not cheap, but it’s efficient, has only 3 pin (like a TO-220 plus heatsink) and lies flat on the breadboard which is critical when you have helicopter blades whizzing round.
  • Finally for the SkySpy controller, this is using the same battery as the Turtle, but doesn’t need anything like the high current, so the wasted power will be minimal, so I’ve gone for a non-switched regulator (LM2940T-5.0) which has feedback circuitry to minimize the loss in high drop out situations

All of these came from Farnell as always!

A Porky Pi

Ok, so I’ve been a bit light on the truth; the turtle has a problem.  Much of the time, the turtle reboots as soon as I run the turtlesvr python script.  Occasionally however, it works just fine.  After swearing alot, it became apparent that with a fully charged battery, supplying ~ 8.4v, all was fine.  However as the battery discharges to lower output (but still plentiful to power up the RPi via the 5V GPIO port) it rebooted.

Then I noticed (with the motors replaced by LEDs) that on booting the Turtle, all LEDs flashed together for a fraction of a second before going out again.  Some serious speculation has led me to this conclusion:  as part of the python code / electronic boot sequence, all outputs are set high (or are floating high) just for a fraction of a second on the 74HC595 chip, before settling – that’s a bug I’m in the process of solving still.  But why did that cause an RPi reboot?

My supposition is that, with the motors attached, the “flash of LEDs” is the equivalent of powering up all 8 stepper motor coils thus drawing up to 10A!!!!!!  With the battery charged, it could (just) cope because the switching regulator could convert the excess voltage above 5V  to extra available current; hence all was well.   However…

With the battery down by a few tenths of a volt, the extra current is being drawn directly from the battery rather than the regulator, and this leads to the battery protection circuitry kicking in (to prevent explosions and other unwanted symptoms), thus the power vanishes for a brief interval before shortly being restored, but rebooting of the RPi as a bi-product..

The more I think about this, the more I’m convinced this is the problem.  So all I need to do now is work out why all LEDs are engaged for a flash at turtlesvr boot up.  This could be python, electronics or just timing at heart, but with the LEDs proving to be great diagnostic tools yet not rebooting the TurtlePi, I at least stand a chance of solving the problem.

To cut a long storey short, it was the master reset pin on the 74HC595 causing the problem.  I’d pulled it high with a reisitor thus not causing a master reset on power up; in turn that meant that when the initialization of the chip happens, any old junk inside would be used to operate the motors – this turned out to be all bits set, leading to the 10A draw, and immediate battery cut-out.

So, the fix involves another GPIO output pin wired to the 74HC595 MR pin, and a 10k pull-down resistor.  The resistor means the master reset happens on power up, and the GPIO pin can then clear the master reset once the turtlesvr code is running.  Hence another tweak to the turtlesvr code to drive that new GPIO pin.  Code to follow shortly, and I’ll try to put together a circuit diagram.

 

Wrong again: the problem is that is wasn’t possible to preset the value of a GPIO port prior to setting it to an output.  So the default was 0, and on the /OE pin, this meant that motors coils were engaged prior to feeding the desired values over the serial interface for those motors to take.  By bad luck, it engaged all coils and tripped the safety cutout in the battery.  So the Python could be fixed in my case as I could keep /OE high through a pull-up resistor until I’d fed the motors data into the data registers.  Only then could I safely set /OE as an output and set it LOW. There was no need for the /MR pin to keep the chip reset.

Having said that,  the problem wouldn’t have occurred were it possible to preset the pin output values prior to setting them to be outputs.  Hopefully a fix will come for the GPIO Python library, but for now, it’s not a necessity for me and my Turtle.

 

Turtle Power!

A headless Turtle really needs to be tail-less too.  It’s hardly free to roam with a mains lead shoved somewhere indelicate, is it?  It’s been a little tricky and so costly getting this to work, so I’ll share with you the final magic ingredients…

Lithium Ion battery 7.4v 2.2AH – why?

  • Even without monitor, keyboard and mouse, RPi boots and then dies without a 3.3v and 5v supply even though the 5v isn’t used for much outside the GPU
  • Lithium Ion cells produce 3.7v, so you need to get a couple in series to get >5v required
  • I bought 2.2Ah batteries to give me > 2 hours running the Turtle between charging
  • So 7.4V 2200mAH it is, but I don’t want to just warm up the ecosystem with the extra  voltage over 5v, so…

switch mode regulator is needed as the most efficient way to convert 7.4V to 5V at up to 3A without producing 7W of heat –  the 5V powers the stepper motors as well as pieces of Pi and they can draw > 1A each if they’re in a mood.

Then I need to take the 5V 3A DC, and tap off a 3.3V @ ~700mA to run the bulk of the Pi – that I used a Low Drop Out regulator as the voltage drop was 1.7V and the current < 0.7 =>  1.2W heat generated – the regulator doesn’t even start to get warm.

Put that lot together and this is what you get – a well stuffed breadboard, to the extent that I bought many heat sinks and inductors while trying to find a combination that would fit on the breadboard.

A headless RPi

TurtlePi, powered from a Lithium Ion rechargeable 7.4V battery with just WiFi to the outside world

P.S.  A little logical thought (too late) meant I realised the 3.3V regulator was unnecessary. The 5V regulated from the battery was fed via the GPIO pin 2 to the RPi 3.3V regulator, thereby feeding 3.3V back to the breadboard via GPIO pin 1.  Which is lucky because I was running out of breadboard lines, but this frees a couple.