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 python code

Here’s the Python code so far for driving the LEDs representing the two stepper motors’ incremental steps. It starts up the system with the first three GPIO ports as outputs (to drive the 74HC595), with the remaining four set to outputs.

Then it has a “for” loop, lighting up LED 1,2,3,4 in a repeating sequence. Those inputs of 1,2,3,4 are then mapped to setting bits 1-4 (i.e. 1, 2, 4, 8), and then the results for “left” and “right” wheels are combined to make (left + 16 x right). This is “fed” bitwise into the 74HC595 data port (GPIO pin 11). Each bit update is then accepted by toggling the GPIO port 12 (a “chew” event), before finally “swallowing” (GPIO port 13) which lights up the LEDs to match the 8 bits (4 each per wheel) previously fed in.

Finally the code sleeps for a second, so I can check LEDs against the prints on screen, before moving on again.

My apologies for lack of comments in the code. I’ll get round to adding this once I stop adding this first batch of features.

Virtual Turtle python code

Turtle Pi

Back when I was a teenager, 30 or so years ago, I had a BBC micro and I used it to built a turtle driven by the BBC computer in Basic. By command, it could move forwards, backwards, spin on its axis, and drop a pen into contact with a paper surface to allow it to plot its path, allowing it to draw pictures.

30 years later, I’m reproducing what I did in my teenage years, but this time with a RaspberryPi controlled from Python via the GPIO ports. Here’s the plan:

  • get my RaspberryPi setup – [DONE] couldn’t be easier for an IT engineer like me, thanks heavens!
  • teach myself basic python – [DONE] a combination of the RaspberryPi user guide combined with this quick reference I found
  • teach myself how to use the gpio port using python – [DONE] starting with the RaspberryPi User Guide
  • extend the basic GPIO code to flash 7 LEDs – the total number of easy accessed GPIO I/O pins [DONE]

Then my first problem. A stepper motor used to drive the turtle has 4 control wires. How to direct 2 motors (8 wires total) when I have only 7 available from the GPIO? Enter the 74HC595 serial in, serial or parallel out latch. This means with only 3 pins, I can drive both stepper motors exactly as needed, leaving me 4 pins to do something else (for example, it’s possible to get joystick switches to provide the inputs to make the Turtle go forward, backwards and rotate. On we go…

  • read and understand the spec for the chip – [DONE]
  • write the python to drive it – [DONE]
  • try it out, using LEDs to represent the motor coils – [DONE]

I’m pretty pleased with progress so far (even though I do say so myself), since I only got my RPi 2 weeks ago. So what next…

  • build a body for the motors in LEGO – [IN PROGRESS]
  • fit the wheels which I kept from my original Turtle to the steppers
  • swap the LEDs for the motors – this means adding some buffering and power as the motors (unlike the LEDs) cannot be powered off the GPIO port
  • add joystick control
  • use a second RPi to control it wirelessly – currently the initial plan is for turtle to be tethered to an immobile RPi via a very long ribbon cable

As a man approaching middle age, I’ve not been this excited since I was a teenager, and even better, doing this means I can help my kids learn to use their own RPi’s when the time comes (they are a little young at the mo!)

I intend to get some pictures up here soon showing progress so far.