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.
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.
I just signed up for the $22.00 perk of 2 Arduino Leonardo compatible boards on this Indigogo campaign.
