Monday, November 4, 2013

4th Egham Raspberry Jam - 3rd November 2013

Yesterday was the 4th Egham Raspberry Jam and we had a great day with a variety of projects on show and nice range of people attending.
Everything from people learning about the Raspberry Pi so they could teach their grand children about computers and computer technology to children looking to be inspired for school projects.

I arrived about 12:00 noon to get set up and people showing started to arrive around 1:00.

We had a great mix of projects.
Leo White's Big Trak
Now upgraded with a new metal robotic arm.

Leo also has a project that just looked like flasking LEDs on the PiGlow until I had a quick chat with Leo and found out that it was all being done in BBC BASIC using RISCOS running on the Raspberry Pi. So, if your old enough to have programmed in BBC BASIC you will be right at home.

Carl Monk brought along his DeLorean Time Machine control panel and flux capacitor as featured on the Raspberry Pi website

Carl also brought along his Pumpkin Game. Great fun using Pumpkins to play a Scratch based game.

Stephen Cornes brought his excellent LED clock which displayed the time in multiple formats.  This project uses the excellent Pi-Lite board which communicates with the Raspberry Pi over serial.

Alan has his bi-direction motor controller running. Even though this is a small project it is a major milestone as Alan knew nothing about Linux, programming or electronics when he came to his first Jam and now he is writing python code on a Linux computer to control a real world motor using a H-bridge.

Matt Sendorek brought along his excellent Maplin robotic arm controlled from Scratch using an intermediary Python script.  Matt has been building this to to use in his after school computer club and from his picture on his write up of the  Egham Jam it looks like it's the perfect thing to get kids interested in computing

Matt has also put together a guide to getting the robotic arm working with Scratch

Marcus Taylor-Moore brought along his robots that were used in a maze challenge and also a really small quadcopter. All very exciting and I know I want both...

Nicholas Herriot had a great set up of home automation. I must admit I didn't get a change to chat much to Nick and so my knowledge of his project is very limited.

Then the amazing Neil Ford came with a show of his own. Not content with 1 display he brought 5
2 Wheel Robot controlled by Raspberry Pi. Perfect as a beginner robotic project with a build that requires no soldering and only a bit of glue.

Neil set up a station where visitors could try out Scratch. See how easy it is to use and how through some simple steps interesting and fun projects can be built.

We had some great music being composed using SonicPi. I must get some time to check this out as it really looks like a great way to introduce programming and giving immediate feedback in a fun way.

How about controlling real world objects with Python

Finally, a great Minecraft set up that was very busy during the day. With kids doing some playing and programming. 

My own little project was Halloween based with a PIR detecting motion and then flashing LEDS inside a couple of clear/greenish skulls and a 'Scream' mask and at the same time played a creepy sound. The sound was so convincing that my daughter didn't like me playing it at home.  All programmed up in Python and using Pygame to play the audio. I did up a PDF Guide with the build instructions and also the Python code. Special call out for Raspberry Pi Spy for his guide and code I used for the PIR motion sensor.  I was just looking for the details on the PIR as I bought it on ebay and so received no instructions. Not only did Raspberry Pi Spy provide details on the PIR he also provided code that works..

I also brought along the Surrey & Hampshire Hackspace 2 pager cheat sheet with details on programs to install on the Raspberry Pi, Controlling an LED, building a Sphere in Minecraft and other useful information on one page and the FOSSWire Linux Cheat Sheet which is a great reference for the often need Linux commands that somebody starting out may not have experience with.
The Hackspace is based in Farnborough and is a great place to meet like minded people who are interested in Raspberry Pi, Arduino, Linux, 3D Printing, Online security as many other fun activities.

I hope those who came had a great time and were inspired to try something new with their Raspberry Pi. It's an amazing little bit of kit that can be used in many different ways (as can be seen from the projects on show)

Here's looking forward to the next Egham Raspberry Jam.

Also, if you're into seeing what's going on with the Raspberry Pi and have a focus on Education the the Raspberry Jamboree on the 27th-28th February 2014. Some great presentations and workshops are already announced and more will be announced closer to the time. I plan to be there on the 28th at least. Maybe stay over for the party.  

Monday, August 26, 2013

Getting ready for the Brighton Mini Maker Faire on the 7th of September 2013

On the 7th of September the Surrey & Hampshire Hackspace will be showing at the Brighton Mini Maker Faire . We'll have a few things on show and one of them is an Arduino Shrimp based kit.
I've spent the last few weeks working out the wiring and also the Sketch for the kit.
We wanted something that wasn't too complex to build but was fun to use once it was completed.  So sound and LEDs were the natural choice.Who doesn't like buzzing sounds and flashing lights.
Also, we wanted the kit to do something the moment it is powered up. Giving instant gratification but also importantly a way to test if the Shrimp is wired correctly. No use trying to use the activities if there is a wiring problem.

I was refining the code tonight and did a quick video on my phone so please excuse the quality.

All working as expected.  
Turn the pot and the note changes and the middle LED goes bright/dark
No touch music player - 3 LDRs control 3 notes
Reactions Game for 2. He who presses their button first after the middle LED lights up is the winner. Might be worth playing 2 out of 3.

There are a few tweaks to be done but after the Maker Faire we will be releasing the breadboard layout build instructions and also the Sketch.

If you can't wait until the 7th of September then leave a message and I'll get back to you.

If you are going to the Brighton Maker Faire on the 7th of September drop by the Surrey & Hampshire Hackspace stall and say Hi.

Friday, July 19, 2013

Indigogo - $9 Arduino compatible board.finishes 15th August 2013

I just signed up for the $22.00 perk of 2 Arduino Leonardo compatible boards on this Indigogo campaign.
It ends on the 15th of August 2013

They have passed their goal of $12,000 and as of today they have raised $15,421 and are now talking about stretch goals.

If you don't mind the risks associated with crowd funded products this looks like a really cheap way to get an Arduino Leonardo.

Tuesday, June 4, 2013

Raspberry Pi Model A - Scratch performance with 2013-05-25 Raspbian image

With the new Raspbian 2013-05-25 image Scratch is suppose to be faster due to the work on the Pixman library.
So, I thought I would do a comparison between the new image and the 2012-07-15 image.
With the expectation that Scratch will mainly be used in schools and that these may be kitted out with Model As I did the testing on a Model A, so limited to 256MB of RAM

Video Below:

I download the images and flashed them fresh to 8GB SD cards - same make and model.
Then on boot up expanded the partition.
No updates were done and only a wireless keyboard/mouse USB dongle was plugged into the single USB port.

The Scratch program has 3 sprites + Stop Sprite. Each main sprite has 2 costumes and they move around the screen bouncing off the edge.
1 Sprite (Felix) also increments a global variable by 1 for each step.
This whole thing is repeated 500 times, giving a long enough time for the task to get a fair comparison. Shorter and the difference in speed would have been harder to measure. Longer and I would have fallen asleep.

Raspbian 2012-07-15 Image
Login was rejected a few times before I was allowed it. This is with the default username/password and using the same keyboard as for the 2013-05-25 image so it looks like some USB based issues were resolved since the 2012-07-15 image was released.
Scratch felt sluggish in loading and resizing the program to full screen
To keep it consistent I ran the program full screen. On the 2012-07-15 image full screen did not stretch but just put a 480 x 360 window in the middle of the screen
Test ran in 1m 22s

Raspbian 2013-05-25 Image
Login worked first time every time.
Scratch felt responsive in loading and resizing the program to full screen
Full Screen stretched to the resolution of the screen, so was true full screen experience.
You will see the updating of the Variable is not real time. It looks like variable updates on screen do not happen every time the variable is changed.
Test ran in 0m 51s 
37% faster than the 2012-07-15
An amazing increase in performance purely based on a software update

Raspbian 2013-05-25 Image Turbo Mode (1GHz)
I used raspi-conf to set the the Raspberry Pi to Turbo Mode to see what the maximum performance is.
Login worked first time every time.
Scratch felt really responsive in loading and resizing the program to full screen
Full Screen stretched to the resolution of the screen, so was true full screen experience.

You will see the updating of the Variable is not real time. It looks like variable updates on screen do not happen every time the variable is changed.

Test ran in 0m 33s 
60% faster than the 2012-07-15 (non-Turbo)
35% faster than 2013-05-25 (non-Turbo)

Compared to stock 2012-07-15 image the new 2013-05-25 image with Turbo mode set is nearly 3 times faster in Scratch.
All without a hardware upgrade and with user changeable settings.

The only limitation appears to be the speed at which variable are updated on the screen. The variables are updated in the background it is purely the screen update that is slow.

For most thing I'd expect the variable issue will not be a problem so a fantastic result.

Scratch is now definitely usable on the Raspberry Pi.

Thursday, April 18, 2013

Raspberry Pi, Unipolar Stepper motors, ULN2003 Darlington Pairs, USB Gamepad, Python

For the Raspberry Jam on Sunday I want to bring something that moved and was also interested in getting stepper motors to work with the Raspberry Pi so I decided to build a vehicle using stepper motors to drive the wheels (very slowly) and control it with a USB Gamepad/Joystick

The first thing I had to do was to sort out the sequence of pulses for the Stepper Motors. I did this originally with an Arduino Uno as I wanted to remove as many opportunities for human error as possible and since this would be the first time I would user stepper motors with the Raspberry I thought it best to begin with a platform where I was use to doing I/O.

To operate a stepper motor you send signals to the 4 lines in a set sequence.
For the motors I purchased are 28BYJ48 DC 5V and their sequence is. Yours may be different.

        Line1 Line2 Line3 Line4
Step 1    0     0     1     1  
Step 2    1     0     0     1  
Step 3    1     1     0     0  
Step 4    0     1     1     0  

To get the motor to go in reverse you just run this sequence in reverse order.
Also, strangely if you are doing this using an Arduino the stepper library worked first time for me even though  the sequence is different. But when I tried a second, third or more times it failed unless I changed the sequence.  See here for the details on the sequence in the Arduino Stepper Motor library:
This post also has a lot of useful information on stepper motors generally

The first thing that I discovered was that the stepper motors and driver board that was a ULN2003 and some indicator LEDS with the right connector for the motors I bought (Amazon UK / Amazon US - these are available cheaper on eBay) had a slightly different pulse sequence than the examples I found so once I figured that out the motors turned clockwise and anti-clockwise as I expected.

All good, motors and driver board working as expected.

Next to get it wired up to the Raspberry Pi.

Here is an layout using a breadboard and a couple of UNL2003 Darlington Pair ICs. These are the same ICs as on the board so the wiring is the same. The board just makes it a lot easier.

NOTE: I used Fritzing to make the layout and it shows the motor as having 6 wires. There are 6 terminals on  unipolar stepper motor, but the model I bought had the two power lines tied together so only came out to a single wire.  Depending on the unipolar motor you have it may have 5 or 6 wires.

With all the wiring done next it was onto the code.

As I said above the goal was to get the motors controlled by a USB gamepad. The gamepad I used is a Saitek P380 (Amazon UK / Amazon US). I bought mine in PC World for about £10.00 For this I decided to use Python as learning to code properly in Python is one of my 2013 resolutions. Also, Python has a nice library in Raspbian for the GPIO pins and I knew that Pygame which works with Python 2.6x had the ability to read USB gamepads.

After figuring out all the mad stuff to do with getting the motors to work on the Arduino I was delighted that using Python and the GPIO library I got the motor to spin with no real problems.

After a bit of hunting on the Internet I got the code to read the USB gamepad and depending on how you push/pull the analog sticks the motors turned.  Effectively allowing you to drive the vehicle like a tank with independent control for both wheels.

Here is the code I used. It is very simplistic as my hope is that it will be easily understandable by others so it can form the basis of something more interesting. I would expect with a bit of effort even I could reduce the code to about a 3rd of its current size and someone who can code properly could get it even shorter. But for this exercise I wanted to literally show every step in the sequence so it is easy to read, easy to understand and east to adapt.

#!/usr/bin/env python

import os, sys, pygame 
from pygame import locals
import time
import RPi.GPIO as GPIO


# set the delay between steps
stepDelay = 0.002

# set up motor 1
GPIO.setup(8, GPIO.OUT)
GPIO.setup(16, GPIO.OUT)
GPIO.setup(18, GPIO.OUT)
GPIO.setup(22, GPIO.OUT)

GPIO.output(8, GPIO.LOW)
GPIO.output(16, GPIO.LOW)
GPIO.output(18, GPIO.LOW)
GPIO.output(22, GPIO.LOW)

# set up motor 2
GPIO.setup(11, GPIO.OUT)
GPIO.setup(13, GPIO.OUT)
GPIO.setup(15, GPIO.OUT)
GPIO.setup(21, GPIO.OUT)

GPIO.output(11, GPIO.HIGH)
GPIO.output(13, GPIO.HIGH)
GPIO.output(15, GPIO.HIGH)
GPIO.output(21, GPIO.HIGH)

os.environ["SDL_VIDEODRIVER"] = "dummy"

pygame.joystick.init() # main joystick device system

deadZone = 0.6 # make a wide deadzone
m1 = 0 # motor 1 (1 = forward / 2 = backwards)
m2 = 0 # motor 2 (1 = forward / 2 = backwards)
   j = pygame.joystick.Joystick(0) # create a joystick instance
   j.init() # init instance
   print 'Enabled joystick: ' + j.get_name()
except pygame.error:
   print 'no joystick found.'

while 1:
   for e in pygame.event.get(): # iterate over event stack
      if e.type == pygame.locals.JOYAXISMOTION: # Read Analog Joystick Axis
         x1 , y1 = j.get_axis(0), j.get_axis(1) # Left Stick
         y2 , x2 = j.get_axis(2), j.get_axis(3) # Right Stick

         print x1
         print y1
         print x2
         print y2

         if x1 < -1 * deadZone:
             print 'Left Joystick 1'

         if x1 > deadZone:
             print 'Right Joystick 1'

         if y1 <= deadZone and y1 >= -1 * deadZone:
    m1 = 0 # Dont go forward or backwards

         if y1 < -1 * deadZone:
             print 'Up Joystick 1'
             m1 = 1 # go forward
             print m1
         if y1 > deadZone:
             print 'Down Joystick 1'
             m1 = 2 # go forward
             print m1

         if y2 <= deadZone and y2 >= -1 * deadZone:
    m2 = 0 # Dont go forward or backwards
         if y2 < -1 * deadZone:
             print 'Up Joystick 2'
             m2 = 1

         if y2 > deadZone:
             print 'Down Joystick 2'
             m2 = 2

         if x2 < -1 * deadZone:
            print 'Left Joystick 2'

         if x2 > deadZone:
            print 'Right Joystick 2'

   if m1 == 1: # motor 1 go forward
# step 1 motor 1

   if m2 == 1: # motor 2 go forward
# step 1 motor 2


   if m1 == 1: # motor 1 go forward
# step 2 motor 1

   if m2 == 1: # motor 2 go forward
# step 2 motor 2


   if m1 == 1: # motor 1 go forward
# step 3 motor 1

   if m2 == 1: # motor 2 go forward
# step 3 motor 2


   if m1 == 1: # motor 1 go forward
# step 4 motor 1

   if m2 == 1: # motor 2 go forward
# step 4 motor 2


   if m1 == 2: # motor 1 go reverse
# step 4 motor 1

   if m2 == 2: # motor 2 go reverse
# step 4 motor 2


   if m1 == 2: # motor 1 go reverse
# step 3 motor 1

   if m2 == 2: # motor 2 go reverse
# step 3 motor 2


   if m1 == 2: # motor 1 go reverse
# step 2 motor 1

   if m2 == 2: # motor 2 go reverse
# step 2 motor 2


   if m1 == 2: # motor 1 go reverse
# step 1 motor 1

   if m2 == 2: # motor 2 go reverse
# step 1 motor 2


Once I put together the physical vehicle using cardboard, Nutella jar lids and some glue I tried it out.
It worked. The main thing that would need to be improved is the wheels.
As the Nutella jar lids are light plastic they wobbled a lot causing them to grind on the cardboard chassis. I used some toothpicks to stop the wheels turning in too much and this for the most part stopped the problem.
Here is a short video of it working.

As you can see I definitely won't be racing this bad boy, but it was great to work with stepper motors, python and pygame as well as upgrade some of my cardboard cutting and shaping skills.

Tuesday, February 26, 2013

Raspberry Pi Minecraft and Python - create lots of blank worlds to mess about in.

I've been playing with Python and Minecraft on the Raspberry Pi.  Using the API included you can write Python scripts to build in Minecraft.
I like to work with a blank world rather than an existing landscape because the landscape may not work or if I make a mistake it can be hard to undo.

So, I wanted to quickly create a bunch of disposable worlds that I can run my very rough scripts in to see where I need to tweak them.

NOTE: for some reason some flowers and things are left behind. It might be an attribute thing...

Code Below:


import sys
import mcpi.minecraft as minecraft
import mcpi.block as block

mc = minecraft.Minecraft.create()

mc.postToChat("Clearing ALL")

blockId =

mc.postToChat("create floor")

blockId =

There are no indents so should just work if cut and pasted to a text file and saved.  I used

Start Minecraft
Create a World


The whole world is made of AIR with a 'ground' of DIRT is added at Y=0.
This will take a while to run so be patient.

Now you have one blank world.

But that would be slow to do that every time you need a blank world.

Well with a bit of jiggery pokery you don't have to.
The method I used is probably a bit manual but it is faster than coding for new worlds every time.
Maybe somebody brighter than me can automate it.

Step 1. Make sure you can see hidden folders when browsing on your Raspberry Pi.
The got to ~/pi (if your username is pi)
Open .minecraft/games/com.mojang/minecraftWorlds
This is the directory where your saved Worlds are stored.
One per folder. For me the blank world I created was called world

Create a bunch of new directories. I used world-blank1, world-blank2 etc....
Make as many as you want.

Go into the original world directory and copy all the files.
Then paste those files into each of your world-blank directories.
Now you have replicated the blank world you created with the above script too all of these world maps.

If you go back into Minecraft they will be there. Only problem is they will all have the same name. Not ideal when you want to know which ones you have broken and which are still clean.

This is where it gets a bit more low level but still quite simple.

Installed ghex a gui based hex editor with sudo apt-get install ghex

Then for each folder open level.dat using ghex and find where it says world
Modify the text to a different name making sure to keep it the same size.  Maybe B0001.
Save the updated level.dat.
Do this for each of your new directories making sure to use a different name (B0002,B0003,...) .

If you run minecraft you will get a list of Worlds all with different names.  For me the order was still a bit mixed up but I can live with that.

Finally, rather than having to do this every time I created a new directory under com.mojang called backup-blank and copied all my newly made blank world into that directory.

Now I can mess about with the blank worlds. Building all kinds of strange shapes not caring about  it being perfect as I can just delete that world and replace it with a new clean one by just copying the saved worlds in backup-blank  back into the minecraftWorlds directory and start again.

Note: For me I have 20(ish) blank worlds created as I mess up a fair bit and this usually allows me to do one good session without having to copy across or create a new blank world.

Happy Coding.

Friday, February 22, 2013

Surrey and Hampshire Hackspace evening - 21st February

Last night was another great evening at the Hackspace with more new people coming along which is fantastic.

During the week a kind person contacted the hackspace and offered to donate some test equipment and books.  One of the members offered to go to Croyden and collect the stuff.
some of the donated books and kit
What a great donation. It included many electronics books. Some were of great interest from a nostalgia standpoint but will be great for introducing new concepts to members starting out.The book on the 741 op-amp is a great little read and introduces the fundamentals of analogue signals and circuits in a nice easy but practical way.  Amongst all the books were an lcd projector and an oscilloscope. Both in perfect working order and will be a great addition to the resources the hackspace has for meet-ups and building circuits.

With new blood came new and interesting possibilities. There were great discussions about pic programming in assembly, control circuitry for race cars, home heating automation with a Raspberry Pi at the heart of it amongst other tops.

A real interesting topic was a satellite developed in Surrey that is controlled using a mobile phone.
More details on the University of Surrey website
Below is video showing what is in the satellite, what it does and how it's all put together.

So, the hackspace is going from strength to strength with more people taking part.

Here's looking forward to the next meet-up and some more interesting discussions and demos.

A selection of pictures from the evening. (sorry for the poor quality - mobile phone pics)

Tuesday, February 19, 2013

Raspberry Pi + GPIO + Scratch + Remote Control Car

At the beginning of 2013 I started a Code Club at my local primary school and the kids love making and playing the games.  Due to the way the club is set up in the school there is expected to be a few classes after the official Code Club sessions are completed so I've been trying to come up with some ideas of things I could bring in to the class to show the kids that Scratch can do more than make a cat move around the screen.

Then on my regular trawl of the web I found this fantastic code for controlling the GPIO pins on the Raspberry Pi using Scratch.

With an old cheap remote control car in a drawer I had the makings of a fun project for me that (hopefully) will be of interest to the kids.

 Having read that the Raspberry Pi GPIO pins are not protected, so one silly mistake on my part could cause the death of my Raspberry Pi I dusted off my old electronics knowledge and put together a small transistor based driver circuit for the 4 pins used.

one circuit per pin

I originally wired this up on a protoboard and it worked, except for when it failed. Did I mention the remote control car was cheap. Well, the aerial was just a bit of wire and with all the other wires I added to the circuit there was regular interference that caused the remote to activate the wrong signal making it unreliable. Knowing the circuit was good the logical thing to do was to put the circuit on a proper board. Rather than going all the way to etching my own circuit board I made it up on a stripboard

again, 1 circuit per pin. white blobs under resistors are cuts in the tracks

After a false start (details of things I almost did wrong) I got the 4 circuits soldered up and tested.  Worked first time.

Not the prettiest soldering but after doing near no soldering for over 20 years I was happy with the result.

Now I the circuit soldered up and it worked. With a bit of coding in Scratch I could program the remote control car for a sequence of actions like
Forward 2 second
Left 0.5 seconds.
Reverse Right 2 seconds

As you'd expect from a simple remote control car the was no way to give very accurate instruction. The motor was either on or off, no variable speed or feedback.  Even with these limitations it felt great when I clicked on the code in Scratch and car actually did what I expected it to do.

the vehicle of my success!!!

And finally he is a short video of the car in action.

This is why I love the Raspberry Pi and the fun of hacking.  With a little bit of effort you can have a lot of fun. Now I have a remote control car that I can control with drag and drop commands in Scratch on a £30 computer.

Sunday, February 17, 2013

Quiz Master Raspberry Pi version now working

I copied the Windows code on to my Raspberry Pi last night and it worked perfecty if run from IDLE. But, if I ran it from either a terminal window or double clicked on the icon it failed.

There were 2 problems.

First was that IDLE on Windows put a ^M at the end of every line so the shebang statement on the first line was failing.
To fix this I copied it all into vi and saved it out. This stripped put all the ^M things.  I must admit I didn't expect this from IDLE.
Then after some more searching  and trial and error I eventually figured out that the directory for the program is not set to where the program is run from so when I try to open the players.txt file it fails and dumps me out.

Using os.getcwd() I can find out which folder the program was run from and set it to the path for players.txt and the sound files.

I revised the code and attached a new pack to the forum that now works on the Raspberry Pi.

Make sure to chmod +the .py to make it executable.

Friday, February 15, 2013

Quiz Master Lockout follow up

Following yesterdays post about the Quiz Master code I have been doing a bit of tweeking and enhancing. Dropbox link to ZIP file

Enhancements in this version.
1. Number of players, their names and sound played when they press their button is taken from a text file (example included)
2. Quiz master can go into lockout mode at any time by pressing return. An X appears top right to show in lockout mode
3. Text at the top of the screen is now taken from the text file - so it can be personalised
4. Now runs full screen ( ran in a window to take the screen shot below)

screen shot

This version is reading keyboard presses. You can buy a USB keyboard on ebay for about £5 and with the aid of some buttons and soldering you can attach the buttons to the keys as defined in your file. Still leaving you with the full keyboard. As mentioned before I see this as the easier option than looking to use GPIO inputs when run from a Raspberry Pi.
These buttons from ebay look perfect.

So, for about £40 (+ cost of connecting wires and housing) you would have a quiz master set up.

NOTE: I would never describe myself as a Python programmer. The code is done in the true hacker sense in that I figured it out as I went along. It all works with the testing I have done but be aware your mileage may be different.

Thursday, February 14, 2013

Quiz button lockout system using Python & Pygame

I read the following post on the Raspberry Pi forum where somebody was looking for a quiz button system for 10 buttons where only the first button pressed was registered.

I posted a replay saying this should be possible with Python as it has an event queue so you should be able to find out which button was pressed first. I also mentioned that starting with a cheap USB gamepad would give the 10 buttons with little wiring effort and no need to do anything with the GPIO.

After posting instead of feeling like I helped somebody I mainly felt I had given them homework.
So, I decided to see if with the help of Google I could actually do the code.

Following a bit of tinkering and searching and getting spacing wrong and forgetting the colons at the end of lines I put together something quite rough that does the job.

I posted this back to the forum, but also the code is below.

The code is for four (4) buttons using the arrow keys on the keyboard.
It waits for a keys to be pressed.
Checks if it is one of the 'button' keys and registers the first button by changing the colour of that players on screen button to red.
It then waits until the 'Return' key is pressed and resets the buttons to black.

This provides the lockout system required and only registers the first button pressed.

#! /usr/bin/python
# Import a library of functions called 'pygame'
import pygame

# Initialize the game engine

# Define the colors we will use in RGB format
black = [ 0, 0, 0]
white = [255,255,255]
red = [255, 0, 0]

# Set the height and width of the screen
# Fill the screen White
# Put something in the application Bar
pygame.display.set_caption("Testing key presses")

# Set the font for the text. Windows computer so usd Ariel
myfont = pygame.font.SysFont("Ariel", 30)

# Created Variable for the text on the screen
label = myfont.render("Quiz Buttons!", 1, black)
player1 = myfont.render("Player 1", 1, black)
player2 = myfont.render("Player 2", 1, black)
player3 = myfont.render("Player 3", 1, black)
player4 = myfont.render("Player 4", 1, black)

# Draw the 4 empty rectangles for the players
pygame.draw.rect(screen, black, (20,200,150,150), 0)
pygame.draw.rect(screen, black, (210,200,150,150), 0)
pygame.draw.rect(screen, black, (400,200,150,150), 0)
pygame.draw.rect(screen, black, (590,200,150,150), 0)

# put the text on the screen
screen.blit(label, (10, 10))
screen.blit(player1, (20, 150))
screen.blit(player2, (210, 150))
screen.blit(player3, (400, 150))
screen.blit(player4, (590, 150))

# show the whole thing

done=False # used to allow exit when you click close on the window
first = 0 # used to signify the first key pressed and stops other being used
waitReset = 0 # Reset section for the while loop

while done==False: # keep going unless I exit application

    # Stay in the loop until one of the 'button' keys is pressed
    while first==0 and done==False:
        for event in pygame.event.get():
            if event.type == pygame.QUIT:
            # User pressed down on a key and it is not the first one
            if event.type == pygame.KEYDOWN and first==0:

                # Figure out which arrow key
                # Check of LEFT arrow key and that it was the first key pressed
                if event.key == pygame.K_LEFT and first==0:
                    print("left key pressed.") # Print to console
                    pygame.draw.rect(screen, red, (20,200,150,150), 0) # colour rectangle red
                    first=1 # set first to 1 so no other key presses will count
                if event.key == pygame.K_RIGHT and first==0:
                    print("right key pressed.")
                    pygame.draw.rect(screen, red, (210,200,150,150), 0)
                if event.key == pygame.K_UP and first==0:
                    print("up key pressed.")
                    pygame.draw.rect(screen, red, (400,200,150,150), 0)
                if event.key == pygame.K_DOWN and first==0:
                    print("down key pressed.")
                    pygame.draw.rect(screen, red, (590,200,150,150), 0)
                # a 'button' was pressed and shown on screen
                # now got to the reset code

    # loop waiting until the 4 'button' are reset
    while waitReset==0 and done == False:
            for event in pygame.event.get():
                if event.type == pygame.QUIT:

                # User pressed down on a key
                if event.type == pygame.KEYDOWN:
                # Pressed Return Key which does a reset
                    if event.key == pygame.K_RETURN:
                        # Draw the 4 empty rectangles for the players
                        pygame.draw.rect(screen, black, (20,200,150,150), 0)
                        pygame.draw.rect(screen, black, (210,200,150,150), 0)
                        pygame.draw.rect(screen, black, (400,200,150,150), 0)
                        pygame.draw.rect(screen, black, (590,200,150,150), 0)   
# Quit in a clean way when done=True
pygame.quit ()

Next I will expand this to add the score and also run it full screen. 
Possibly even have sounds when the buttons are pressed.

Friday, February 8, 2013

Surrey & Hampshire Hackspace evening 7th February 2013

Last night was the second Surrey & Hampshire Hackspace session I have attended at GamesGalaxy in Farnborugh.  Last time I had planned to solder up my Raspberry Pi interface for a remote control car but got sucked into the excellent Eagle tutorial by Bob, so this week I was determined to get it done.

Ohms Law
Bob and Doug
While I was quietly getting on with stuff Bob for his second tutorial gave an introduction to Ohms Law.

Alan busy soldering
What he's soldering
Alan was soldering up an SMD board. A lot more complex and precise than my efforts. Not sure the circuits purpose but as you can see from the pictures Alan had 2 soldering irons at his disposal.

circuit on proto-board. too many wires
For the remote control project I needed to move the components from a proto-board that due to the number of wires hanging off it causing too much interference and stopping the remote from working reliably.  I wanted to build it on a stripboard to get rid of all the wires and also as a small, simple introduction to using stripboard as this was my first time using stripboard.

When I arrived I realised I had left my computer at home and in it’s case were my notes. Nothing too detailed but not a great start.  I also left my soldering iron at home so a quick trip to Maplin around the corner sorted that out.

figuring out the circuit
So began the task of taking a simple circuit with 4 components and figuring out how to do it on stripboard. It’s amazing how something that makes perfect sense on a proto-board suddenly appears more complex than it needed to be.

After a bit of head scratch I figured out the layout and it only used 5 strips.  one for 0V, one for 3V (from remote) and 3 for the transistor and the 3 resistors.  Hopefully a nice neat circuit. 

I then turned the board over to start placing components and thankfully Doug pointed out that I needed to mirror the circuit compared to put the components in on the strip side.  I expect this saved me a lot of troubleshooting later on.

first one soldered
top side components
I soldered in the first circuit after figuring out the mirrored circuit and where I needed to cut the tracks to make it work.
(sorry for the poor picture quality)

Really happy about getting it done and was then about to solder in the second circuit when Robin popped over so I explained the layout and again noted a mistake. I was missing a location where I could take the output to the remote. If you look at the hand drawn circuit above there is no output at the transistor.  Whoops, another mistake averted.  I had to move the transistor forward one hole to create the point where the remote wire would attach.  If you look at the 1st solder side picture above and the final one below with the 4 circuits in place you will see the one on the left has moved to the edge with no spare holes left. Lucky I had the space to move it.

Also, on the first one I thought I’d be clever and use the legs of the resistors to do the bridging by just bending over the pins and soldering them. It worked perfectly, but looked a bit of a mess so I decided for the other three I would use jumper wires on the top of the board. That is why there are no jumper wires on the first circuit but the other three all have small jumper wires.

All 4 solder in - see the one on the left has moved...

component side up. 3 on the right have  jumper wires
Here is the final layout for 1 of the circuits as a schematic diagram and also on the strip board. I put the jumper links on the strip side for illustration purposed but you can see for 3 of the 4 circuits above the jumpers are on the top.

white under resistors are cuts in the strip
So, that was it all wired up.  I then added the wires to connect to the remote control and the wires to connect to the GPIO pins on the Raspberry Pi through the Adafruit PiCobbler.
After hooking it all up and attaching a screen and keyboard I loaded GPIOScratch, Opened my test code and it worked.  Sending commands from Scratch on the Raspberry Pi made the car drive.
All the problems I had with interference due to the tangle of wires have been fixed and I now have a reliable circuit that I can possibly bring into the CodeClub I run to show the kids that Scratch is not just for making a cat run around the screen.

In my joy it slipped my mind to photograph the finished circuit all wired up to the remote and the Raspberry Pi. So, for the next post I will do some more pictures, a video and show the Scratch Code.

It was an excellent evening at the Surrey & Hampshire Hackspace and next get together is the 21st of February. If this type of thing interest you then visit the website and join the mailing list. Or even better come along on the night. For more going on you can follow on Google+.

Roll on the 21st and some more computing and electronics fun.