Getting the Phenoptix MeArm to work with ScratchGPIO

tl:dr

Buy, or build your own robotic arm from the plans available from phenoptix.  Connect it to a Pi using an Adafruit I2C servo controller board.  Control it using ScratchGPIO.  Get creative.  This is perfect for KS2 or KS3 students who want a build challenge, but aren’t quite ready for the challenge of coding the robot control in python.

Background

I bought a MeArm from Phenoptix before the Christmas break, as my STEM club kids had wanted to build a Mars Rover style robot with a robotic arm.  I thought I’d start small and work my way up to building my own  so I bought a retail kit from the phenoptix website after being really impressed with the V3 at the Poole Raspberry Pi Jam 2014.

The kit is sold by Phenoptix (www.makersify.com) and comes with everything needed to build the robot, including laser cut acrylic parts, M3 nuts and bolts for fixing, and 4x 9g Turnigy servo motors.   They also entered the design into the Hackaday I/O contest, and open sourced the hardware so you can roll your own if you need to.    This makes it an amazing choice for school STEM projects if your school has access to a laser cutter or a 3D printer, as you can make the robot for less than £20 quid and a dig around in the parts bin.  Controlling the robot is left up to you: There are build instructions for Arduino, Pi, and Beaglebone (and presumably ninja skills with 555 timers and pots) as the control methods.  The code for all these has been hosted on gitub.

Our own laser-cut MeArm parts, as shared on Thingiverse.
Our own laser-cut MeArm parts (well, they’ve been removed from the acrylic), as shared by Ben on Thingiverse.
The build was moderately difficult for KS3/KS4 students, and was not helped by the sometimes obtuse instructions on www.instructables.com.  The Stem club were going to try and document a clearer build – I think the instructions could be done in a different colour acrylic to make it clearer, or perhaps add some 3D or wireframe instructions like an IKEA flatpack build! One of our improvements was to add engraved numbers to adjoining edges, so 2 fits with 2, 5 with 5 etc.  But then again, solving problems is part of the whole STEM process!

The Build

My initial kit had the incorrect number of parts, so the build stalled about 2/3 of the way through but a quick email to the website meant they dispatched replacement parts in about 4 days.  It’s really important to get the initial positions of the servos correct in the build, as it can have two consequences:

  • Having to disassemble the robot to correct the servo position in order to get the full range of movement. (A pain)
  •  If the base servo is misaligned, the robot can end up pushing against the supports and burning out your servos. The claw servo can also burn out easily if you haven’t set limits in software and misaligned the servo before assembly.
    Robots building robots. Skynet!
    .Retail Kit meArm is in the background.  Our own version is in the foreground. I watched them build it without setting the servo positions correctly and kept quiet.    Then they worked it out for themselves, and disassembled, reset and rebuilt without my help!

Once assembled, the robot looks pretty awesome  but  the robot won’t be able to move without precisely timed PWM signals generated from a Pi, Arduino, Beaglebone or a servo controller unit.  These have to be precisely timed, and require a PWM pin, +5 V and ground for each servo.

Connections to the GPIO

This how-to is for a Raspberry Pi Model B or B+ (not a Pi 2) , using Adafruit’s 16 channel servo controller board, Scratch GPIO 7.

I decided to use the Adafruit 16 channel servo controller. It works over i2C, and so only requires 4 pins from the GPIO.  You will have to enable i2C on your Pi first, by following the tutorial online at Adafruit Learning Centre

1. Assemble the Adafruit board by soldering in the header pins

2. Enable i2C on your pi by following the instructions at the Adafruit Learning Centre.  This is just editing a config file and then rebooting  down the Pi

3.Attach the breakout pins on the Adafruit board pins to the correct GPIO pins as shown below.

The Pins we need are GPIO 1 (3v3), GPIO 3 (SDA), GPIO 5 (SCL) and GPIO 6 (GND)
This picture is from a B+ GPIO.

Make sure that the Pi is turned off before attaching pins to the controller board!

VCC is attached to 3V3 (GPIO 1 )       This provides the voltage for the controller chip at 3V.

Gnd is attached to Gnd (GPIO 6 )         This provides a ground voltage for the controller chip at 0V

SDA is attached to SDA  (GPIO3 )                  This pin is the Serial Data pin, where all of the PWM signals are pushed to the different servos

SCL is attached to SCL (GPIO5 )         This pin is the Serial Clock pin, where the timed pulses for i2C master-slave communication are generated.

The correct pins are on the header on the left hand side: The GND, SDA, SCL, VCC pins are the ones we want.
and you should get output that it has detected your device (mine was 0x40)

Connecting the servos to the board.

Connect each servo to the board correctly:

Make sure that the Black wire is connected to ground, The red wire to V+, and the White wire to PWM.

I connected the servos to the board as follows:

  • Base servo: Channel 0
  • ‘Shoulder’ servo: Channel 1
  • ‘Elbow’ servo: Channel 2
  • ‘Gripper’ servo: Channel 3

I usually have a whole bunch of female-female header leads for experiments with Raspberry Pis, and then I use solid jumper leads to connect these to the servo leads.  You should thread the leads through the centre of the arm to keep the leads tidy, and to minimise snagging whilst the robot is moving.  You’ll need to extend the servo leads of the micro servos in order to prevent any tension whilst the robot is in motion.  I’ve got 20cm jumper leads bought on Amazon, and can highly recommend them for STEM projects.

The Adafruit 16channel 12bit i2c board, allows the Pi to control the 4 servos using i2c over the GPIO.  You need to use an external 5V power source to power this board, otherwise the Pi will brown out whenever the servos are moving.  You can damage your Pi if you try to drive 4 servos with the GPIO.  I used an external bench power supply to make sure the servos got  a constant voltage supply.

Make sure that you connect the servos to the Adafruit board, the Adafruit board to the GPIO and the External Supply to the Adafruit board whilst the Pi is powered down.    Check, check and check all your connections again.  The GPIO can be a fickle beast, and connecting it incorrectly can damage the Pi.  Be nice to your Pi.

Once you reboot your Pi, you should see the adafruit board will light up, and you can check that the Pi can see the i2C device with

 sudo i2cdetect

Connecting the Adafruit Servo Board to Scratch GPIO.

Install ScratchGPIO on the pi using

 wget http://bit.ly/1wxrqdp -O isgh7.sh

followed by

sudo bash isgh7.sh

ScratchGPIO7 should then be installed.  If you don’t get a link on the desktop, you might need to dig around in /etc/ to locate the scratchGPIO7.sh file.

Start ScratchGPIO.  The program should automagically detect the i2c device if it can be seen using the i2cdetect command.

Set up some variables:

AdaServo0       – This is channel 0, the base servo, and should only be sent values ranging from -90 to 90

AdaServo1        -This is channel 1, the shoulder servo, and should only be sent values ranging from 70 to 0

AdaServo2        -This is channel 2, the ‘elbow’ servo, and should only be sent values ranging from 20 to 70

AdaServo3        -This is channel 3, the gripper servo, and should only be sent values from 0 to 30.

These values are all assuming that you have assembled the arm according to instructions.  You might find that your ranges are slightly different.

You can choose to increment the values of the variables by using the arrow keys, or you might create a generator script which will automatically scan through the values for each variable.   we had a ‘panic’ function that set the robot to a home state with a single button press if things got hairy!

Here’s a video of it in action:

Be careful not to exceed the maximum values for the servos.  The 9g servos have relatively weak plastic gear trains, and can strip their gears easily!

We’ll share our scratch code, and will post our python code as soon as we can get coding again.

Advertisements

MeArm update – Work in progress.

Here’s an update of what we’ve been up to in the last 4 weeks of STEM club.

Team MeArm.

We initially built the excellent MeArm from a phenoptix kit, priced £29.99. It’s a nice robot with 4 degrees of freedom, that can be controlled via Arduino, Rasberry Pi, Beaglebone etc.  We managed to get it working really nicely with a Raspberry Pi and ScratchGPIO, Simon Walter’s excellent version of Scratch for the Pi.   The challenge for the group is to control the arm using Python.  It was suggested to use a Wii Nunchuk, or perhaps a Microsoft Kinect, but early experiments have suggested that keyboard input is challenging enough!

Robots building robots.  Skynet!
Progress on our MeArm build. The kit version is in the background, and our JCB yellow in the foreground.  We’re about 2 weeks away from movement control!

Once the robot is mechanically sound, and the servo positions are set, then we should be able to connect it via I2C using the Adafruit 16 channel Servo I2C board.  Once this is done, then we’ll release the python geeks, and let them run wild with their programming and imagination.

Running an in-house Scratch Jam.

Having run a really successful Pi Scratch Jam in my school for 30 year 9 students, I thought I’d share some ideas, tips and resources from our day. It involved a lot of planning, prep and problem solving, and we had a surprise visit from OfSted that day! They were really impressed with the problem solving, creativity and resilience that the kids showed, as well as the engagement and enjoyment all-round. I was really impressed with the quality of the finished projects.

We’d had a visit to Bournemouth University to try their Scratch Jam where our kids scooped top prize, and they asked us to run an internal version in-house.

The brief was fairly simple: Connect Scratch to the real world and Create something Fun.
This was the original brainstorm that Mike and I did on wrapping paper.

All great ideas start out as a sketch.
All great ideas start out as a sketch.

Originally we’d drafted 6 different challenges:
-Make a giant interactive boardgame
-Make an interactive floor piano.
-Create an e-reader hidden inside a real book.
-Create an interactive Nerf firing range.
-Create a fruit based controller for Pong
-Create a skeleton sensitive scratch games using a Kinect.
-Create a sound and light controlled game.
-Make a tilt-sensitive burglar alarm.

(We ditched the burglar alarm due the kids unfamiliarity with the GPIO, and the e-reader we felt was too challenging as we couldn’t source a suitable screen at the time).  We hooked up and hashed out a quick table of projects and made a shopping list, together with what we thought the programming difficulty was like, including any python handlers or requisitions we needed to make.
Project WRAP

We also made a list of what we’d require from IT services, including projectors, portable speakers, phono leads, 4-way extensions etc.  All that stuff makes the biggest difference on the day.

In  the end, we used a mixture of Pis and Windows PCs running Scratch.  We used Makey Makeys, Kinect and a picoboard to do the real world connecting. (We’ll run a Pi/GPIO challenge next time, but we decided to start with something they already knew.

Here’s my tips list, in no particular order.

  1. Work backwards – Make sure you have a clear goal state that you want the students to achieve in their groups. Work backwards from this to structure your challenges.
  2.  Use code experts to help out with the code challenges in groups. Either get Ks4 or Ks5 students to help out. Teach them to ask questions, not provide readymade solutions.
  3.  Enable flexibility in the challenge – The kids love to be able to be able to solve problems their own way, not a pre-prescribed way.
  4.  Provide structure to the challenges – We used programming goals, construction goals and creative goals.
  5.  Reward problem solving, teamwork – This means that you are embedding and rewarding the skill sets that you want to see develop.
  6.  Have prizes, certificates pre-organized. (Our prize fund dwindled spectacularly, so we had to improvise).
  7. Mix up the teams a little.  I had a STEM team who knew how to code for the Kinect really well in Scratch, so I gave them a project they were unfamiliar with.  Their ideas were much better as a result.
  8.  Share the judgement criteria in advance – If they know what to do in advance, they can plan for it at the start of the day, and there’s less last minute inclusions into the code, something which often breaks code at the crucial moment.
  9.  Fuel – Biscuits were welcome.  Malted Milk were particularly prized for the combination of low crumb, high flavour.
  10.  Build time for a showcase – Sharing their creations is paramount. If they don’t feel like their input is valued or shared, they won’t value the whole activity. We had an hour’s showcase, and had a visiting class and Senior Team from the school.  Watching them jump around with the Kinect-Controlled shooter was priceless.
  11. Bookmark the day with a purpose, and a link to real STEM careers.  I chose to link the day to problem solving, and also different interface designs.  We tried to have industry speakers and visitors to come and judge, but we had a last minute cancellation.
  12.  Share all projects online – We uploaded all of the kids code to the Scratch Website to showcase their work.  For future Code Jams, we’ll upload our code to github.

There were some technical issues, but our school’s technicians are really supportive, and we made sure we’d put our requisitions in the week before, so there was not much unexpected hardware faffing to do.

The quality of the final builds and programs were incredible. The winning team had build a Giant Version of operation called Dogeration, which unsurprisingly, had a Vetinary twist. They hooked up the BBQ tongs to the Makey with wires, and then had different scoring and penalties based on how many times you touched the sides of the cavities. Their prize for the day was to get their project made into a permanent laser-cut wooden version (still under construction).

Here’s the final document that was printed and shared with the groups on the day: It pretty much covered most of what they needed to know, and they could research their code, or instructables using the links.

The Great Purbeck Scratch3 (Word Document – Sorry!)

If you do use it, then give us a shout and tell us how your Jam went down!

I hope this helps other teachers to take the leap and run their own Scratch Jam in-house.  Our next step is to run this in other feeder Primary schools, and use our students as the code experts, and build their skills in mentoring and helping others to come to their own solutions to problems.

Kinect2Scratch – The power of joint tracking in Scratch.

Microsoft Kinect units can be found second hand on eBay for £20 or so, and they are STEM gold.  There are so many amazing pieces of code out there that let you extract the joint info from Kinect and make it ready for other apps in the form of OSC, midi, or raw data  (NI mate is a commercial venture).

One of the best uses of a Microsoft Kinect I’ve seen is with Scanect, a piece of software that lets you map the video data to the distance data in order to make accurate 3d models of small objects, people or rooms rapidly and cheaply.  However, that’s quite an advanced STEM project, and I needed something that could use the power of the Kinect, and combine it with the rapid prototyping and easily accessible code of Scratch.

Using a great piece of software developed by Stephen Howell called Kinect2Scratch,  (http://scratch.saorog.com/ for the download) it’s possible to import skeleton data from the kinect directly into Scratch and use it to code with.  You have to install the Kinect runtime for Windows first, but once running, The Kinect2Scratch program runs in the background, extracts the joint information, and sends it to Scratch.  (setup guide here: http://scratch.saorog.com/setup.pdf)

Mac users have an option that is coded by Kenta Hara:  http://github.com/mactkg/kinect2Scratch4Mac

Once Kinect2SCratch is working in the background, it just chugs away and sends skeleton tracking data to Scratch, with very few issues.  The student reactions to having such profound input into Scratch was incredible.  Within about 20 minutes, they had brainstormed at least 8 different ways of using joint input to make games, animations, presentations.

It comes with some really great sample programs to get you started, but my favourite one was the skeleton tracking.  It uses some crafty code to draw a live skeleton in scratch with very little lag, and puts Kitty Cat’s head on the top.

Over the course of the Purbeck 2014 Scratch Jam, Team Kinect made a game from the bottom up that used the Chest Centre tracking point (Around where the solar plexus is) to control the Horizontal movement of a space ship in a vertical scrolling shooter.  This actually made playing the game a real workout, as to avoid incoming meteorites, you need to move your entire body, ducking and jumping at times!   The ship fires by raising arms to prepare the lasers, and then bringing them below the shoulders to fire.

It’s a great game, with randomised meteorites, good scoring mechanic, menacing score and great workout to boot.

The Project is shared at:

http://scratch.mit.edu/projects/37598364/