Chicken Pi

Introducing Chicken Pi

Every Easter the school has an egg decorating competition. Last year the boys were victorious with a joint effort that used their soldering skills to create this great (and pun-tastic) scene.

The boys were really keen to use a Pi this year and inspired by the excellent egg-laying machine we saw at the Raspberry Pi birthday party, decided to build a Lego version.

We decided to use the Lego WeDo hub that we had to make fitting a motor easy, and then had the bright idea to use the distance sensor as the trigger: You put your finger in between the chicken's beak and on detecting the change in distance value reported by the sensor, the Pi activates the motor.  Manual re-loading of the egg is then required!

The eggs are inserted into a cage mechanism in the Chicken's body. The motor is mounted perpendicular to the cage and turns it via two a simple 90 degree gearbox. This rotates a central shaft that translates the egg around and over a hole in the bottom of the chicken.  A little trail and error enabled us to calculate how long to power the motor in order to achieve the desired range of motion.

The Pi is contained in a Smart Pi case, which has a number of Lego-compatible plates.

My favourite part of the model is the chicken feet, which you can see here next to the WeDo hub.

The control code was written by my son in Python and is really simple. It uses the excellent WeDo library.

from wedo import WeDo
import time 

wedo = WeDo() 

def turn(num,mote)
    wedo.motor_b = mote
    time.sleep(num)
    wedo.motor_b = 0 

while True:
    if wedo.distance < 7
        turn(0.3,30)
        time.sleep(0.75)
        turn(0.3,-30)
        time.sleep(5)

All the entries were  displayed in a classroom. Because there might not be a mains socket within easy reach, the whole Chicken Pi was powered via an RS battery pack.

Here is a movie of it in action

By the end of the day, the battery pack was exhausted and one egg was completely destroyed (the other just about survived but had a number of serious cracks).  No prize this year unfortunately, but we were up against some tough competition: a solar egg-lipse themed display and the (genius) Egg Sheeran (an egg with a mop of ginger wool on top).

Simple local network with package cacher for Raspberry Pi labs/classes/dojos

We had a great mini-Jam session at CoderDojo Ham yesterday. All the activities that I've put together for Pi Codeclub were available and everyone seemed to enjoy the hardware programming. Making an led blink seems like a simple achievement but everyone seems to find it very satisfying (especially when using a chunky 10mm led).

I wanted to give everyone an opportunity for a bit of Linux sysadmin as well because I think that having a little command line knowledge under your belt can make the difference between a Pi that sits getting dusty on a shelf and one that becomes a really fun and useful device.

Of course installing packages is a key task, but one that requires a network connection. This can be tricky at the youth centre: there are no ethernet ports in the hall, the wifi is a bit flaky and speed can be quite slow, especially if the Scratch sessions are using the online version. Another problems is that we only have a few wifi dongles, not enough for every Pi.

So I wanted a way to enable participants to be able to experience the joy of apt-get. The solution build a simple ethernet network with an apt-caching relay server. This will cache a copy of any packages downloaded so that they can be quickly retrieved, even without an Internet connection.

The dumb switch is not a sophisticated bit of equipment - you can pick up an 8 port TP-LINK one for < £8 on Amazon.

So in the case of my CoderDojo, I simply update and install all the packages that are mentioned in the projects beforehand so that even if there is no Internet connection available at the Youth Centre, participants can still complete the activities.

Here's the procedure I followed.

Server

1. Download the latest Raspbian image and burn an SD card.

2. Change the hostname (edit /etc/hosts and /etc/hostname and change raspberrypi to whatever you want your server to be called).

3. Install these packages using apt-get:

sudo apt-get install dnsmasq
sudo apt-get install apt-cacher
sudo apt-get install apache2

4. Set a static IP address. In this example I'll set it to192.168.50.43 as shown in the diagram above.

5. Start x-windows (startx) and add the wifi network through the GUI.  Obviously if you're preparing this at home like I did, you can test with your own network then add whatever wifi you'll be using at the location where you're running your event when you get there.

6. Dnsmasq will run a DHCP server to allocate dynamic IP addresses to your client Pis. Edit /etc/dnsmasq and set:

interface=eth0
dhcp-option=3,192.168.50.43
dhcp-range=192.168.50.150,192.168.50.165,255.255.255.0,12h

7. To allow your server to act as a router/relay, edit /etc/sysctl.conf and add

net.ipv4.ip_forward=1

8. Edit /etc/default/apt-cacher

AUTOSTART=1 

9.  Create a script to use iptables to act as arealy for packets destined for the Internet. Note that 192.168.1.98 below is the IP address allocated to the wifi interface - you'll need to change this for whatever IP address you receive on the wifi network you're using.

#!/bin/sh
IPT=/sbin/iptables
LOCAL_IFACE=eth0
INET_IFACE=wlan0
INET_ADDRESS=192.168.1.98
# Flush the tables
$IPT -F INPUT
$IPT -F OUTPUT
$IPT -F FORWARD
$IPT -t nat -P PREROUTING ACCEPT
$IPT -t nat -P POSTROUTING ACCEPT
$IPT -t nat -P OUTPUT ACCEPT
# Allow forwarding packets:
$IPT -A FORWARD -p ALL -i $LOCAL_IFACE -j ACCEPT
$IPT -A FORWARD -i $INET_IFACE -m state --state ESTABLISHED,RELATED -j ACCEPT
# Packet masquerading
$IPT -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_ADDRESS

 Client

1. Download the latest Raspbian image and burn an SD card.

2. Change the hostname (edit /etc/hosts and /etc/hostname and change raspberrypi to whatever you want your server to be called).

3. Create a file /etc/apt/apt-conf.d/90-apt-proxy.conf with the following contents:

Acquire::http::Proxy "http://192.168.50.43:3142; 

Raspberry Pi CodeClub week 9

This week was our last chance to talk about Astro-Pi ideas and so I handed out these excellent worksheets and invited them to all come up with their final ideas for next week. I also supplied my son with some spares to hand out in the event of the original copies being eaten by dogs or siblings.

We're starting to get into some tricky Python now. A couple of the group are now well on the way to completing the Intruder alarm project. In fact, one boy had assembled all his circuit on the breadboard and finished the coding. He'd fixed a few syntax errors (the usual missing colons) and was confident that everything would work.

He called me over to demonstrate, hit F5 in IDLE and the program started running. It printed out a message to say that the PIR was armed and so we waved in front of the sensor... and nothing happened. No buzzing buzzer.

We looked at the code: I was suspicious because the PIR had seemed to settle too quickly. I couldn't see any problems so we looked at the wiring. Ah. Two pins on the PIR connected the wrong way round (despite my red, bold text on the diagram, warning of the dangers of getting those connections wrong).

We corrected that problems and tried again. Still not working.

I wondered whether the mis-connection had damaged the PIR so I swapped it for a spare. Still no good.

We checked the code again and it looked OK.

I hadn't actually tested these PIRs - they were fresh out of their bags. Maybe I had a dodgy batch?

Conscious that other children were asking for help, I asked him to re-re-check the code while I went to assist them.

By the end of the session it still wasn't working so I took his SD card, Pi and breadboard circuit home to test it myself.

After tea, my son and I set up the Pi and started debugging. First of all we tested the PIR with code that I knew was correct. It worked.  Not a hardware problem then.

Within a couple of minutes looking at the code, we spotted the problem. A couple of code blocks were incorrectly indented, messing up the logic that triggers the alarm when the PIR state changes. Easy to identify with 2 pairs of eyes in the calm environment of my study, obviously harder to spot in the noisy, hectic Computing suite.

Things to do differently next time?

Looking at the worksheet, I can see why the problem occurred and why I didn't spot it. My indentation in the sample printed code wasn't always consistent and it is quite tricky to follow. When I was debugging during the club I wasn't actually checking the logic: I was just comparing what was on the screen with what was on the sheet. And getting it wrong.  

The code for this project is as about as long as I want the children to be typing: one side of A4. But even then, it can be quite difficult to reproduce correctly. So to try to help with this, I've updated the worksheet to include dotted lines that clearly indicate the position and alignment of the various indented blocks. I will also encourage the children to always use the tab key rather than a bunch of whitespace. 

We'll see how this goes when some of the others try this project next week. 

This was the last week for most school clubs but I asked my bunch if they wanted to have a session next week and the unanimous answer was yes!

Raspberry Pi CodeClub Week 8

It is genuinely amazing how much progress everyone has made. This was really brought home to me today because we had a new pupil joining the club. I asked the usual mob to help him out with getting his Pi setup and watched as they explained the basics and got him up and running within a few minutes (he likes his computers so didn't take long to pick up the basics).

The rest of the session followed the usual formula with the kids working through the various projects. Some are a little further on that others, but everyone is making great progress. I'm increasingly finding that I'm spending my time explaining more complicated aspects of Python and Linux than answering the basic questions ("which one is the HDMI cable again?") I was for the first few weeks.

One chap who has been experimenting with the buzzer using Python discovered that at a certain frequency it makes a screeching, ticking sound that he thought sounded like a bomb about to explode. He decided to hide behind his chair and, apparently without any rehearsal, most of the others followed suit!

This has set them up nicely for a future project using the button, led and buzzer combined with crater-making Minecraft that we'll be starting in a couple of weeks!

Raspberry Pi CodeClub Week 7

Raspberry Pi Codeclub is always a fun and interesting hour but today was even more colourful than usual. Thanks to World Book Day we had a session run by Prof Branestawm and attended by a Jedi, Violet Beauregarde, Dr Frankenstein, Susan from Narnia, Sherlock Holmes and (where's) Wally.

We've settled into a nice routine now and yet again I was impressed by how confident all the children are with building circuits on breadboard and connecting them to the GPIO. As a result the pace is starting to increase now and my top pupil has now completed the Buzzer project. I like this project because it demonstrates the limitations of Scratch, which can only flip the buzzer relatively slowly and produce a ticking rather than a proper tone. This leads nicely into the Python version which can generate tones of different frequencies.

I'll need to finish off the next project worksheet: adding to the buzzer code and using a PIR sensor to make an intruder detector.

I've also added the branding-free worksheets for the reaction game and buzzer projects to Github.

This week also saw the publication of an article in the Surrey Advertiser following their reporter's visit to our club a few weeks ago. All in all the article is not too bad - the description of Raspberry Pi isn't great and I think the mention of soldering refers to the DIY Gamer projects.

At least they got the CodeClub URL correct!