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.

 

Leave a Reply

Your email address will not be published. Required fields are marked *