The latest version of Raspbian Jessie (2016-02-03) includes a some great software updates that you can read on the blog post.
The one that caught my eye was the inclusion of experimental OpenGL hardware accelerated support.
For gaming and other computer graphics programs this is a big thing and means more games will work well on the Pi2.
At the moment it is still experimental which is why in the video below when showing the OpenGL demo a section at the bottom of the screen is greyed out. No ide a why (yet) as all works perfectly without OpenGL support enabled. This is a VGA monitor using an HDMI-VGA adapter where the config works perfectly without OpenGL enabled.
Below is a short video of the glxgears demo. First without OpenGL support and then with.
It's an amazing improvement.
With soft-OpenGL support it's really slow and there is a lot of flashing. With OpenGL enabled it looks great.
What a day. More than double the attendees. More than double the stands, more teachers and kids attending. More fun and learning than ever before.
When the Egham Jam was announced back in December I thought we would do better than the last Jam (46 registrations) but was blown away by the response.
Maybe a lot of new Raspberry Pis were sold at Christmas.
We were not only 'SOLD OUT' but also had more people who wanted to attend as well as people who register who advised me they couldn't make it so their tickets were released.
In the end 90 attended, more than double the October event and a record for the Egham Jam.
I was also really delighted the number of educators who attended looking for ways to integrate the Raspberry Pi into their schools Computing work.
There were at least 12 show and tell standard, some of them had multiple displays making for a very interesting day. Also, very delighted that on a number of stands children were leading the show and tells. Giving great demonstrations on what they have build.
I tried to meet everybody who attended as possible and got the chance to connect teachers and people with specific needs with others who I know from previous Jams demoed a similar project.
Below are some pictures from the event. Lots of fun. Roll on the next Egham Raspberry Jam.
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: http://www.tigoe.net/pcomp/code/circuits/motors/stepper-motors/
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
GPIO.setmode(GPIO.BOARD)
GPIO.cleanup()
# 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.init()
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)
try:
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
GPIO.output(8,GPIO.LOW)
GPIO.output(16,GPIO.LOW)
GPIO.output(18,GPIO.HIGH)
GPIO.output(22,GPIO.HIGH)
if m2 == 1: # motor 2 go forward
# step 1 motor 2
GPIO.output(11,GPIO.LOW)
GPIO.output(13,GPIO.LOW)
GPIO.output(15,GPIO.HIGH)
GPIO.output(21,GPIO.HIGH)
time.sleep(stepDelay)
if m1 == 1: # motor 1 go forward
# step 2 motor 1
GPIO.output(8,GPIO.HIGH)
GPIO.output(16,GPIO.LOW)
GPIO.output(18,GPIO.LOW)
GPIO.output(22,GPIO.HIGH)
if m2 == 1: # motor 2 go forward
# step 2 motor 2
GPIO.output(11,GPIO.HIGH)
GPIO.output(13,GPIO.LOW)
GPIO.output(15,GPIO.LOW)
GPIO.output(21,GPIO.HIGH)
time.sleep(stepDelay)
if m1 == 1: # motor 1 go forward
# step 3 motor 1
GPIO.output(8,GPIO.HIGH)
GPIO.output(16,GPIO.HIGH)
GPIO.output(18,GPIO.LOW)
GPIO.output(22,GPIO.LOW)
if m2 == 1: # motor 2 go forward
# step 3 motor 2
GPIO.output(11,GPIO.HIGH)
GPIO.output(13,GPIO.HIGH)
GPIO.output(15,GPIO.LOW)
GPIO.output(21,GPIO.LOW)
time.sleep(stepDelay)
if m1 == 1: # motor 1 go forward
# step 4 motor 1
GPIO.output(8,GPIO.LOW)
GPIO.output(16,GPIO.HIGH)
GPIO.output(18,GPIO.HIGH)
GPIO.output(22,GPIO.LOW)
if m2 == 1: # motor 2 go forward
# step 4 motor 2
GPIO.output(11,GPIO.LOW)
GPIO.output(13,GPIO.HIGH)
GPIO.output(15,GPIO.HIGH)
GPIO.output(21,GPIO.LOW)
time.sleep(stepDelay)
if m1 == 2: # motor 1 go reverse
# step 4 motor 1
GPIO.output(8,GPIO.LOW)
GPIO.output(16,GPIO.HIGH)
GPIO.output(18,GPIO.HIGH)
GPIO.output(22,GPIO.LOW)
if m2 == 2: # motor 2 go reverse
# step 4 motor 2
GPIO.output(11,GPIO.LOW)
GPIO.output(13,GPIO.HIGH)
GPIO.output(15,GPIO.HIGH)
GPIO.output(21,GPIO.LOW)
time.sleep(stepDelay)
if m1 == 2: # motor 1 go reverse
# step 3 motor 1
GPIO.output(8,GPIO.HIGH)
GPIO.output(16,GPIO.HIGH)
GPIO.output(18,GPIO.LOW)
GPIO.output(22,GPIO.LOW)
if m2 == 2: # motor 2 go reverse
# step 3 motor 2
GPIO.output(11,GPIO.HIGH)
GPIO.output(13,GPIO.HIGH)
GPIO.output(15,GPIO.LOW)
GPIO.output(21,GPIO.LOW)
time.sleep(stepDelay)
if m1 == 2: # motor 1 go reverse
# step 2 motor 1
GPIO.output(8,GPIO.HIGH)
GPIO.output(16,GPIO.LOW)
GPIO.output(18,GPIO.LOW)
GPIO.output(22,GPIO.HIGH)
if m2 == 2: # motor 2 go reverse
# step 2 motor 2
GPIO.output(11,GPIO.HIGH)
GPIO.output(13,GPIO.LOW)
GPIO.output(15,GPIO.LOW)
GPIO.output(21,GPIO.HIGH)
time.sleep(stepDelay)
if m1 == 2: # motor 1 go reverse
# step 1 motor 1
GPIO.output(8,GPIO.LOW)
GPIO.output(16,GPIO.LOW)
GPIO.output(18,GPIO.HIGH)
GPIO.output(22,GPIO.HIGH)
if m2 == 2: # motor 2 go reverse
# step 1 motor 2
GPIO.output(11,GPIO.LOW)
GPIO.output(13,GPIO.LOW)
GPIO.output(15,GPIO.HIGH)
GPIO.output(21,GPIO.HIGH)
time.sleep(stepDelay)
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.
Having caught Raspberry Pi fever and attending
the excellent Milton Keynes Raspberry Jam on a couple of occasions I
approached my employer about running a Raspberry Jam at our offices
in Egham. After a bit of explaining what a Raspberry Pi is and what a
Raspberry Jam is they gave the green light and we put the 20th
of January in the calendar as the date for the Raspberry Jam.
Eventbrite page was set up to allow
registration to keep the numbers to a reasonable level and started to
promote the event on the Raspberry Pi forum and on Twitter through my
@Winkleink account. Through retweets from @Raspberry_Pi and
@Teknoteacher we got 50 registrations with over a week to go.
I put out the call for presenters and two
people stepped forward
Dave Ackerman the Pi in the Sky man offered to
present on sending balloons into the stratosphere and using a
Raspberry Pi transmitting live images from the flight.
Stephen Cornes offered to present on using a
hard drive as your primary drive and also connecting to the Raspberry
Pi over serial using the GPIO serial connection.
The 20th January rolled around and after
snowing for 3 days I expected the day to be a flop. Giving myself
loads of time I got there for 12:30 with a 2:00 start and began
getting things organised.
Then to my joy Dave arrived about 1:00 with 3
boxes of bits and a presentation so I knew it wasn't only going to
be me.
We both got ourselves set. Dave in the
boardroom with the projector and the theatre seating and me the main
area where the show and tell activity was going to go on.
I’d spent the week getting a small cheap
remote control car to be controlled through Scratch (see previous
post) but due to my mad/bad wiring when I set it up interference
between the wires meant the car always wanted to go left. I could
show the wheels spinning forward and backwards but the grand plan of
having people try to figure out how to program Scratch to get the car
to navigate an obstacle course did not materialise.
Alongside my nearly working demo Dave set up
his ballooning bits.
Paschal Egan showed using the GPIO to produce
433MHz home automation control signals to switch on and off domestic
appliances.
Ian Law brought along his set up to see if
someone could help with debugging the Python snake game he was
working through from the Raspberry Pi Users Guide.
Robin Fordham set up his circuit that expanded
the GPIO pins using I2C controls.
At the far end Leo White brought along his
Raspberry Pied BigTraks with robotic arm and webcam.
In the end over 30 people made it out in the
snow to attend. An amazing turnout considering the weather. Ranging
in age from 15 to a much older.
Once most people had arrived Dave presented Pi
in the Sky. I was so wrapped up I failed to keep him to time so we
got a lot of details on what was involved.
Then Stephen presented on using a hard drive as
your main file system and also connecting over GPIO using serial. His impetus for both was issues with SD cards
giving errors and not wanting to have to attach the Raspberry Pi to a
screen. If you connect over serial then you even get to see the boot
sequence. This is not the case if you SSH in over the network as
networking has to be active for the SSH connection to happen.
Stephen kept to time and by the rush of people
to the front after he finished his presentation was of interest to a
number of people attending.
After the presentations we went back to the show and tell area.
Where we mingled and chatted. Those of us with demos answered
questions and tried our best to explain what we did, how we did it,
why we did and what use it was.
I must admit seeing the BigTraks with the
robotic arm controlled by the PS3 controller over Bluetooth and live
streaming to a browser was fantastic. It really showed the power of
the Raspberry Pi and the number of things it can do at the same time.
There was a crowd around Ian’s Raspberry Pi
trying to figure out what was wrong with his code. In the end Robin
Fordham came to his rescue and worked out there was a rogue file in
the directory with the program causing problems. Once this was
deleted then everything worked as it should after a simple typo error
was fixed.
From the feedback people have provided it
sounds like the event was enjoyable and achieved its goal in
inspiring people to do more. One person has invested in a Raspberry
Pi, another purchased a Pi Cobbler and others found answers to their
questions that would allow them to continue with their projects.
From my point of view as an organiser of a
Raspberry Jam I must admit it was quite painless. Just set things
up. Let people know it’s on. Manage registration on Eventbrite and
then play host on the day.
A few things I would tweak are
Maybe have each person do a 10-20 second intro
(name, own a Pi, what done so far, what do you wish to do) so people
can connect and also any gaps in the official(ish) agenda can be
filled by meeting like minded people.
Keeping presentation to 30 minutes. Extra
detail for those interested can be do one on one in the show and tell
area.
Have people demoing put a sign or sheet out
showing what they are demoing so it’s easier to figure out which
projects are of most interest.
Encourage others to take pictures and videos as
I was either presenting or running around so took very few
photographs and no video.
Here’s looking forward to the next Egham
Raspberry Jam.
After the little bits of coding and small videos that I have posted already I now have a working version of the classic game Columns working on an Arduino using the TVOut Lobrary to drive a composite video display.
I need to do a little cleaning up of the code, but if you want a copy just ask. Happy to share.
Here's the usual video showing it working.
As promised now that I've tidied up the cdoe a bit here it is.
August last year I posted that I tried the TVOut library with the Arduino but didn't post a video as it was just the usual TVOut demo that I used.
Well, today I again used the standard TVOut Pal Demo but this time something of my own.
We have a NextBase dual screen portable DVD player for keeping the kids occupied in the car. Fantastic invention, would recommend to any parent who has to drive more than an hour with small kids.
While wiring it up I saw the Video port says in/out, so it is Composite, so should work with the Arduino/TVOut combo.
1 re-purposed headphone lead and a couple of resistor later and I had the Arduino outputting video to the NextBase screen.
This means the 14" portable in the garage is now redundant as this is far more compact.
Below is a short video showing it working.
I'd suspect there may be many a household with one of these lying around. Either with the DVD player part broken or because the kids have upgraded to a Nintendo or iPad. So, ready to become part of the tinkers box of bits.
Update: I did a bit more coding and managed to creat my own bitmaps and get them to move down the screen. Not a major achievement but a step in the right direction.
The following video shows it. There are 6 bitmaps all 7x7. The program selects a random column to start and then scrolls the graphic down the screen.
