How to build an AlarmPi

Here’s the contents of the breadboard. Some of this stock was ordered from but was sent by Newark, their US partner. As a result, postage costs £16 per order, so make sure you include all you need. In my case it was

Here’s the code – you can tell from GPIO_SWITCH, GPIO_LED, GPIO_PIR and GPIO_SOUNDER which device (sensor or output) is connected to which pin on the breadboard Pi Cobbler.

Here’s a bigger pic of the breadboard.  +3.3v from Cobbler pin one is connected to both red lines.  Ground from Cobbler pins 6 & 9 are connected to both the blue rails.

AlarmPi breadboard

AlarmPi breadboard details

That’s all for now, both because I’m gonna have another shot (metaphorically for the moment) at the Drone, and also, there’s a minor restriction in the RPi.GPIO library which needs fixing (by me?) before I can progress on the hubs.  I’ll explain more in another post.

What do you get when you cross a Raspberry Pi, a PiBow and a Steamroller?

In preparation for getting a camera board to sling under my drone, I’m in the process of tweaking a RaspberryPi Model A, and designing my own variant of the PiBow case to match – although in doing so, I’ve found much broader use…

For the RPi changes, I’ve removed the A/V socket, and replaced the GPIO pins with an IDT connector so I can lose a couple of layers in the Model B PiBow. That’s now complete – removing the A/V connector wasn’t too bad, but removing the GPIO pins was a right PITA – more on that in another post. Here’s the end result.

For the PiBow, I wanted a cross between the Model B and Model A PiBows: thinner like the model A, but with bolts in the corner like the model B so it could be a direct but thinner replacement for the Model B Ninja PiBows I’m using at the mo on the drone and its RC. Primarily this is to reduce the weight, centre of gravity, profile and power consumption of both.

In the end, I had to compromise, and took 2 layers out of the model B, and sealed up the A/V socket, and opened up the GPIO hole to allow the larger GPIO connectors. I got a local laser cutter company to produce this from my Pibow001-AB3. Here’s what it looks like….

PiBow A + PiBow B

PiBow A + PiBow B cross

Note the addition of the IDC connector isn’t mandatory – there are 90 degree sets of pins available, and they were my first choice, but for the connectors on the ribbon cable, the 90 degree pins weren’t quite long enough.  They would still take the single wire pin connectors though if that’s what you’re after.

Running to stand still…

Just as my python code was nearly complete, GPIO interrupt support has been added. To me this is fantastic as I loathed the fact my drone remote control and the drone itself we’re having to periodically (every 0.1 seconds) check its inputs to update itself. Now I’ll be able to

  • add the joystick interrupts on the RC, for both the switches and the joystick movements, so the remote control can just sleep pending an interrupt. It’s not actually quite that simple as in fact, the remote control periodically sends a KEEPALIVE message to the drone so the drone knows it’s still in contact with the RC. If it finds it’s not, it switches to auto-landing mode, but it does at least reduce the work when there is no change on the joysticks.
  • add accelerometer interrupts to the drone itself, so if it’s running smoothly, there’s no need for it to poll the accelerometer; it can just sleep on select() waiting for the next RC commands.
  • Together this means lower battery usage on both, and faster reaction to critical events. A double plus!

    The only downside is the rewrite of the code scheduling and resultant testing. I think for the mo, I’ll add this to my todo list and concentrate on getting the drone airborne and stable first.

    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

    Virtual-turtle photos

    Just a couple of shots showing the set up of my virtual turtle.

    The RPi itself is a B, 256MB RAM, not made in Britain. I have two GB ones on order to offset my guilt! It’s powered from the USB port – I went for a good one (11 ports, mains powered) to limit the number of cables & wiring I had. RPi is running 2012-09-18-Wheezy, and that has worked beautifully with the Edimax Wi-Fi dongle, which is relatively cheap, tiny and works well!

    My overall setup

    My “workspace”

    Here you can see in a bit more detail, the GPIO port wiring – note the LEDs / breadboards are powered from the 3.3v output from the GPIO port – hence my choice of a quality USB port to power the RPi

    RPi, 74HC595, +LED simulated stepper motor coils

    The setup of the virtual turtle, with yellow LEDs representing the left stepper motor coils, and red representing the right