ElMo: post mortem

We did it!  PiWars took place almost a week ago and we had a blast!  A massive thank you to Mike and Tim for organising, to all the judges and jam makers, the sponsors, exhibitors, the show and tellers and the robot makers who all made the day so much fun.  It was brilliant to chat with other robot fans and makers - a great time was had by all in Team ElMo.  The day really seemed to fly by and the venue was always busy.  Matthew Manning has posted a great video of some of the action

Here is a link to some of the days photos and other video

And to a write up by Femi, a fantastic young blogger who featured on the raspberry pi blog

How did we do?  I am delighted that we finished in sixth place in the A4 and under category.  Congratulations to KEITH Evolution who won our category, and to Revenge of Pyrobot who won in the larger than A4 - both really impressive.  In fact well done to everyone - we all built robots, which is awesome!  We rarely scored  very highly in any given round, but must have been consistent overall.  Here are a few thoughts on how we fared and what we have learned from the day

Obstacle Course: 15th/27
The course was created with help from Piborg, and I thought we were due for an early bath when crashing over the very first hump killed the power to ElMo :(  Luckily the loose wire was soon back in place and given we had to wait to reboot before continuing, I think 15th was pretty good!
Learning:  make sure all your wiring is firmly connected!  Plenty of torque is required to get up the inclines.  A bit more speed might have helped us to avoid being crushed on the rotating platform.  Watching your robot being crushed is a horrific emotion!

Line Following: 9th/11
Thanks to cannybots for a fairly fiendish course - much more twisting than our home built test track.  We had to really slow down to get round and even then we came off a few times and had to rescue.  So a fairly low standing, but we got some points for having a go!
Learning:  I think a couple more IR sensors might have helped - I read a great piece on robotroom about a fast linefollower called Jet, which could follow a line at over a metre a second - something to aspire to next time.  One of the spectators suggested our sensors were a bit too far in front of our wheels, so we didn't turn quickly enough - we'll have to experiment with placement of the sensors.

Proximity Test:  10th/21
This one I thought we did OK - and I think we benefited from erring on the side of caution.  We stopped about 30-40mm from the wall each time.  But we spoke to a team that had a couple of runs with only millimetres of gap, but they incurred a 30cm penalty for touching the wall on their other run.  The winners were awesome - only a couple of mm from the wall on each attempt.  I'd like to find out how they managed that :)
Learning:  maybe we could have been a bit less cautious, but I'm happy we didn't hit the wall.  Check out other sensor options, ultrasonic is OK, but I think light/IR might be better?

Skittles:  10th/30
Again, we did OK - and might have done better if our code had not let us down on the day.  For some reason, the cannon failed to fire on our first couple of runs, so we got zero skittles.  We then resorted to firing the cannon from a stationary position and knocked over 12 or so from our next four attempts.  The guys with the flywheel were awesome and the winners got strikes and spares and scored around 40 points I think!
Learning:  Check your code thoroughly.  A few more volts might have given us even more va va voom.  I think robot football would be a challenging problem.

Straight Line Speed: 23rd/30
We're definitely not the quickest - even when we upped the voltage to the motors.  We must have been more that 20 seconds slower than the fastest team.  But I was pleased we were autonomous and we didn't hit the sides :)  The 12v motors supplied with the diddyborg metal edition meant it completed the course much more quickly than we did
Learning:   Faster motors would help here, but controlling something quick might be more difficult.  And you'd still need plenty of torque for other challenges.

Three Point Turn: 13th/22
We got the distances right after much calibration - but ElMo was somewhat prone to veering off at a jaunty angle, so we struggled to get back into the starting box.  Some of the other teams did very well - I think this challenge would benefit from a reliable compass or wheel encoders.  Or both.
Learning: more tech required to have a decent stab at this - relying on just timing is only going to get you so far

Code Quality:  15th/27
Mid table - I'm not sure what the judges were looking for. We used a lot of other peoples libraries, so we were perhaps less home rolled than some,  Our code is on bitbucket if you want to take a look.
Learning: check out the winners code and see how the professionals do it.

Build Quality:  21st/30
Not great - I assume we lost a few marks because we were mostly built from a kit.  And we did have a loose connection.  And the beautiful triangula was a very worthy winner here.
Learning:  we should get down to Makespace and learn how to use their laser cutter and build something more beautiful and bespoke next time.

Blog: 3rd/21
Our highest mark!  I hope one of two of you have enjoyed reading our exploits - it has been an interesting experience writing about the process
Learning:  keep writing!  Although a few weeks of peace might not go amiss

Aesthetic:  29th/30
Again, I hope that we were marked down because we came from a kit - although we did mill our own lid.  I thought the orange perspex was very fetching.  There were plenty of people who commented favourably on the ElMo theme during the day.  But next time we'll have to go more bespoke and add more bling.  Again, the beautiful triangula set the bar very high in this category
Learnings:  more lasers, more lights :)  Beauty is in the eye of the beholder.

PiNoon:  Round two (having got a bye through round one)
We didn't really stand a chance against the mighty triangula, who went on the win the PiNoon challenge.  It was a definite rabbit in the spotlights moment - mercifully swift!  I thought the pin and balloon idea was great fun, it didn't matter where you were in the venue, hearing the pop meant another competitor had bitten the dust.
Learning:  need to be more nimble - and maybe get a bit of luck in the draw as well :)

Right, that's probably the longest post of the PiWars season - well done if you've managed to read down to here and hopefully see you again next year.  We'll be the ones with bigger motors, more light, extra sensors, snazzier chassis, etc, etc - this robot building lark can become addictive :)

ElMo: one week to go

This time next week it'll be PiWars eve - how exciting!  Do come and say hello - we should be quite easy to spot in our spiffy new t-shirts

We've had our timetable for the day through - and we are assured of at least one small victory as we have received a bye through the first round of PiNoon - I think we might need to do some work on our robot victory dance routine ;)

See you next week - and may the odds be ever in your favour...

ElMo - menus and configuration files

We have continued to tweak ElMo this week - our hardware is as ready as it will ever be, so it is all about the testing and subsequent software changes.  We have now added a configuration file so we can get and set key parameters from the OLED menu.  The parameters we can tweak as of now are

• voltage in - because when the batteries get used up, the motors slow down and we want to compensate for that.  
• voltage out - so we can recklessly run our 6V motors at 9V during the speed test ;)
• time1m - this records how long to run the motors to travel 1 metre (used during 3 point turn)
• time360 - records how long to run the motors to rotate 360 degrees (ditto)
• slowprox - the speed to run the motors at during the slow approach phase of the proximity test (the default 0.25 was not enough to move ElMo forward when the batteries were running low, so we can increase that now)
• linefollowspeed - the speed to run the motors at during the line following challenge.  We have a better chance of staying on the line when we move slowly, but we can increase the motor speed to go for a faster lap.  Our line following is a bit hit and miss - I'm hoping that is due to the low quality construction values on our test course and that the sensors will perform well on the day.

I'd refer the interested user to our bitbucket source code to see the configuration file (elmo.cfg) and how it is used  (search in elmo.py for eg "voltagein").  We use the python ConfigParser module to read the config file (elmo.cfg) as part of the ElMo __init__ method.  We can get a numeric value from the config file using the getfloat method.  Parameters are set by calling eg setvoltagein (each of the setter methods is listed in our OLED menu list) - this in turn calls the method changevalue, which displays a value on the OLED screen and uses the up down buttons to change the value by an increment (0.01 for slowprox, 0.1 for settime1m, 1.0 for voltage out) and the centre button to return the new value.  When we have changed a value we call the writeconfig method to write the updated config file to disk.  This means that next time we reboot ElMo, we read the most recent configuration.

Here is some video demonstrating the menu in action - with a bit of last weeks Nigella in the background.  Do we get bonus points for having to work under these conditions ;) The font we are using is called Mario-Kart-DS which we found on dafont.com - seemed a bit more appropriate than Times New Roman ;)

This week we shall be testing, testing and retesting - and recording more video to share in the final week running up to PiWars - eek!

ElMo: finishing the finishing touches

Not a lot of time for blogging this week - too much coding to do:)  But we finally drilled and shaped our orange perspex lid for ElMo.  Looking good - a bit waspy perhaps?

We've spent quite a lot of time coding this week - as the deadline for the code review is on Saturday.  You can see how that is going at our bitbucket.  The new straight line speed test code uses an ultrasonic sensor to keep track of how far we are from the wall.  It does not work at all well unless the sensor is at right angles to the wall - because the reflections just don't bounce back otherwise.  We needed a bit more metal to be able to do this - we are making judicious use of wing nuts so we can swing the sensors to face forwards or sideways.  The line sensor is the last bit of code and is still 'bleeding edge' software - this is using 3 IR sensors that can detect black and white (as shown in the photo).  But it turns out we can use the same code to stay over the line as to stay close to the wall - we just need to change the comparison functions we use.  The technique uses something called a proportional integral derivative controller.  See this page for more details.  We've also checked our code using an online pylint tool - you can upload your python code and see how well it conforms to python standards.  After much refactoring we now score a fairly respectable 9.66 out of 10.

There are a number of parameters that we will need to change on the day.  Our very naive three point turn relies on knowing how long it takes to travel one metre and rotate 360 degrees - but these values change depending on the how much power is left in the batteries.  So we'll write a calibration function that will allow us to change this from the menu - and write the values to a configuration file so we can read them back in if we reboot.  We need to tweak the parameters for the various challenges.  And we need to stop the ball rolling away from the cannon as we push it forwards.  But it feels like we are getting there - which is probably just as well given there are only 3 weeks to go :)

ElMo: hardware finishing touches

Our last session involved tidying up our power cables (with a terminal block that bolts to the lid of ElMo), the addition of an on/off switch (rather than having to disconnect the battery pack each time), and a simple menu system comprising a 128x64 pixel OLED screen and three buttons (move up the menu list, move down the menu list and select the menu item).  The screen is i2c compatible and so daisychains in with the other i2c items (the PicoBorgReverse and UltraBorg boards).  Adafruit provide an Adafruit_SSD1306 python library for sending images to the display.  The buttons (picked up in Maplin) use one GPIO pin each and are also connected to a ground pin.  Ideally we'd like to print out a proper circuit board (maybe using fritzing) and solder these items to it - but time is getting short, so we'll probably stick with the breadboard look.  We are planning to add a vibrant orange perspex lid, so we'll cut that next time, using the clear lid as a template.  And add somewhere for our mascot to sit.  And maybe some wing nuts for the ultrasonic sensors, so they are easier to swing into another position.  But hopefully that will be the final few cosmetic changes to the hardware.

There is still a lot of software to write - but we have now set up a bitbucket project to track changes - you can view it at https://bitbucket.org/elmorobogo/elmorobogo

We did have a major crisis of confidence last week - after adding the OLED screen, ElMo stopped working - the raspberry pi went into a constant reboot cycle.  Cue sleepless nights, rushed purchases of replacement hardware, etc, etc.  It turns out that our batteries were out of juice... once they were recharged, everything was good to go once again.  Lesson learned :)

And finally - we're really enjoying reading how everyone else is getting on - the other PiWars blogs are getting us excited.  Not long to go now...

ElMo's Cannon Takes Shape

This weekend we put the electronics mostly to one side and concentrated on some mechanical engineering.  It was time to construct our cannon.  We already have a tris10 kickball kit and they provided a CAD file to 3D print a mount that it can sit in.  We spoke to the family design engineer (aka the lovely Uncle Tone) and he got in touch with his ever so helpful friend Tim - who just happens to own a 3D printer.  A massive, massive thank you to Tim from Team ElMo for helping us out.  He even provided an action shot of the mount being printed

We spent the afternoon cutting and drilling the perspex that the mount would be attached to

The kitchen table got a little bit messy - but we did tidy up afterwards

 We eventually came up with something that ought to do the trick quite nicely

Alas, a tiny miscalculation means that the upper piece does not caress the bowling ball as snugly as we were hoping (ok - its miles off) - we might add some foam pieces to bulk that out if it helps.  And the casters we ordered did not arrive in time to fix to the base - they finally arrived yesterday.  So we don't have a moving cannon - yet.  BUT - we did test it using a raspberry pi GPIO pin to control the discharge - and that doesn't appear to have any adverse effect on ElMo (huge sigh of relief there) - so hopefully we'll soon be able to attach our shiny green and purple appendage to ElMo and try it out in anger!

We're nearly done with the construction of ElMo now - we'd still like to try adding an OLED menu screen and some select buttons.  And  then there is quite a bit of coding to do.  But we're getting there - and having fun doing it :)

ElMo goes ultrasonic

This weekend we managed to add ultrasonic sensors to ElMo.  We bought an UltraBorg from the PiBorg people, which made this very straightforward - although we did seek out some warm words of encouragement on their forum before starting.  Piborg also sell a mounting kit to hold an SR04 ultrasonic sensor, so we grabbed some of those as well.  Fitting the screws was a job for small fingers

We brilliantly designed the metalwork we added last time so the spacing was exactly the same width as the mounting holes on the ultraborg - or was that just a very satisfying fluke?!

Communication with the board is using I2C - the same 6 pin set up as the picoborg reverse, so we were able to just daisy chain this board in between the picoborg and the raspberry pi - simple.  The ultraborg would apparently need an extra power supply if we were to add servos, but this is not required for ultrasonic sensors, they can just draw power from the pi.  We fitted two sensors to the front (they are connected with the white/lilac/purple/blue wires in the picture above.  We may add two more on the side later, to help with steering in the straight line speed test.  Looking good :)

We also swapped the crazy breadboard connection to the line following sensor for some female/female wires in fetching rainbow colours - these came from robotshop.

We seem to be getting relatively reliable readings from the sensors, which is pleasing - I thought we might end up using an IR distance sensor instead, but actually these seem OK.  We wrote a little program that approaches a wall at full speed, drops to quarter speed when the distance is less than 300mm and stops when the distance is less that 30mm.  It might need some fine tuning and we may not get as close to the wall as some (apparently they needed calipers last year), but I think this is a great start.  Here's the video of take two - take one didn't go quite so well ;)

Next time we'll hopefully be harnessing the power of the cannon...

ElMo - now we're moving

On Friday we took full advantage of a school inset day and cracked on with building ElMo - now the motors were soldered into place, the rest was pretty straightforward.

We powered up... and then wrestled with the PS3 controller for quite a while - it just wouldn't connect first time, but after randomly connecting via a cable and disconnecting again, we finally got the two paired and were able to run the example script that we downloaded from the piborg website.  Behold, a moving robot :)

After playing with our new toy for a while it was time to add some more hardware.  We were planning to incorporate a number of individual IR sensors for line following, but a recent MagPi article mentioned a 3 way sensor from Ryanteck, so we sent for one of those.  We cut some Vex aluminium to mount it

The line follower has 5 pins (Vin, 3 sensor outputs and Gnd).  At this point we realised we had no female/female jumper wires (some arrived today from robotshop), but we cobbled something together via a breadboard.  

The way the pi gpio pins are laid out we can attach 3.3v from pin 17, use pins  19, 21 and 23 for sensor inputs and pin 25 for ground - all in a neat row.  Note those are the physical pin numbers - the sensors are actually connected to GPIO10, GPIO09 and GPIO11

Once we power up, there are 3 leds on the top of the line follower board that go out to show when a line is detected, which is very useful.  There is also a variable resistor that can be used to adjust the sensitivity - keep turning until a black surface turns off the LED.  One of the sensors seems to be a bit more sensitive than the others - it might be a tiny bit too close to the ground?  So we may eventually swap this unit out for 3 separate detectors which each have their own variable resistor to adjust the sensitivity - definitely more testing required.  I'll post (and maybe talk through) the code another time, but we did get it working - like I say, it feels like we need to tweak things a bit, but overall we made good progress :)

Next time we will be adding some ultrasonic sensors to the front and thinking about attaching the cannon

ElMo Cannon Creation

A long time ago, I posted about adding a solenoid to ElMo, that we could use to kick the ball as part of the skittle challenge.  Well, I found that Tris10 Robotics sell something called the kickball kit - a whole heap of capacitors that can be charged up and then discharged rapidly into the solenoid.  The force could apparently puncture a football - which appealed to the hooligan in me :)  We sent them some cash and a parcel arrived from Australia.  This weekend it was time to put it together.

The kickball comes as a kit of parts

that need to be soldered to the circuit board

 The finished circuit - comprising a few headers, 3 capacitors, a relay switch, a few resistors, a diode and a transistor

I was sceptical as to whether my soldering skills were up to the job - but it works!  For now we have only tested it using the supplied arduino code - I thought I'd rather fry the arduino than the pi if things went wrong!

The solenoid is attached to the kickball controller using 2 pins.  There are two more pins for Vin and ground - I used a 9V rechargeable battery first of all.  Another pin is used as the trigger (set the pin high for 70ms to trigger the 'kick' - you then need to wait ~10s for the capacitors to recharge) and a final optional pin can be used to query the charge of the capacitors (I didn't connect this - I don't think we need this for PiWars where we only need one kick).

9V was certainly enough to move the test ball - but it wasn't enough to kick the ball from a standing start and knock any skittles over.  The diddyborg we are using for ElMo has a 12V battery pack and when we connected that we did manage to knock over one skittle - yay!  I finally tried wiring up 2 9V batteries to give 18V and that felt pretty punchy - we managed to knock over 4 skittles with that.  So we might power ElMo with 18V (for that challenge at least).  It may be that with the robot pushing the ball, the 12V kick will be enough - once we have a moving robot (hopefully this weekend!) we can think about how to attach the cannon and do some more tests (and post some video)

Controlling Raspberry Pi With A PS3 Controller

Lets try and get our PS3 controller talking to the raspberry pi. I started by attempting to do this on an old raspberry pi model B, but eventually realized this would require 3 available USB sockets - for the keyboard, bluetooth dongle and PS controller.  I suppose you could remove the keyboard and login in via ssh, or get a USB hub, but I decided instead to switch to using the raspberry pi 2, which has four USB ports on the board.  I am going to want the controller on ElMo in the end anyway.

There are some instructions on the diddyborg website (in the getting started tab) explaining how to do this, so lets give it a go.

First, install the joystick package

sudo apt-get -y install joystick

which installs and sets up evtest, inputattach and joystick.
I then need to look at another diddyborg page to get the details about installing QtSixA, also known as sixad

sudo apt-get -y install bluez-utils bluez-compat bluez-hcidump checkinstall

that installs a whole heap of additional packages as well as those listed.  I'm not convinced we will actually need all of those, but no matter.  Go make a cup of tea while that lot is unpacked and set up.  Then, some development libraries,

sudo apt-get -y install libusb-dev libbluetooth-dev joystick pyqt4-dev-tools

ahh - so you don't need that first install of joystick, if we include that here.  Another bunch of packages to install...

wget http://www.pabr.org/sixlinux/sixpair.c

gcc -o sixpair sixpair.c -lusb

wget http://sourceforge.net/projects/qtsixa/files/QtSixA%201.5.1/QtSixA-1.5.1-src.tar.gz

tar xfvz QtSixA-1.5.1-src.tar.gz

cd QtSixA-1.5.1/sixad 

make 

sudo mkdir -p /var/lib/sixad/profiles

sudo checkinstall

the checkinstall command creates a package that we can manage - when prompted, I called mine 'sixad'.  I didn't change any values, I just hit enter at the next prompt and it all seemed to go OK - I now have a package that could be removed at a later date.
Now, attach the bluetooth usb module - mine is a dynamode USB bluetooth adapter, bought from piborg at the same time as I bought the diddyborg

and attach the ps3 controller via it's usb cable and pair them using

~/sixpair

which says something about setting master bd_addr to some hex address - presumably that of my controller?  Now start the sixad software and press the PS3 button when prompted to do so

sudo sixad --start &
sixad-bin[8077]: sixad started, press the PS button now
sixad-bin[8077]: unable to connect to sdp session
sixad-bin[8077]: Connected Sony Computer Entertainment Wireless Controller

that looks promising?  I didn't feel it vibrate though, so lets try

jstest /dev/input/js0

Result! When I hold down buttons or move the joysticks, I get a notification that the button is on, or see that the axes coordinates change.  I think we are in business :)

I tried shutting down the pi, which also appears to turn off the ps3 controller - excellent :)

When I restart the pi, I don't need to rerun the sixpair program - that would appear to be a one off operation.  I just need to restart the sixad daemon.  I could probably do that as part of the boot up, but I would need to know when to press the ps3 button - which might be confusing if we don't have a terminal to look at?  So perhaps best to do it manually - at least until I have more of an idea of what I am actually doing :) - or maybe we could flash an led to alert us as to when we should press the button?

So I just need to remember to a) make sure the ps3 controller is charged and b) that I start the sixad program and pair the controller when I reboot the pi.

Google tells me that the ps3 controller should be good for at least 12 hours or so, so it ought to last the day at piwars without needing to worry about it.  Charging takes around 2 hours.

ElMo Construction - session two

This weekend we continued the construction of ElMo - we drilled some holes in the perspex base using a dremel drill press

These will be used to bolt on some vex metal that we will attach sensors to

We also soldered wires to the motors and connected them up to the picoborg reverse controller

Next time we will be connecting the pi and the batteries and if all goes well we may be in a position to run our first test program - exciting :)

On the software front, we also managed to get a PS3 controller to connect to a raspberry pi - more details in a later post.  There are a few more package installations required to use the diddyborg, I'll be downloading those this week

ElMo Construction - first session

This week we got started on construction of ElMo, a modified diddyborg.  We're basically following along with the excellent build  instructions from the piborg website.

here are the diddyborg bits and pieces in their anti static bags

screwing in the motor brackets was a bit fiddly

adding the motors

and the motor hubs

With the picoborg reverse in place.  And we just couldn't resist trying the wheels for size - but will take those off again while soldering

All quite straightforward so far.  A couple of minor gotchas - we managed to put two of the motors in upside down, so had to do those twice.  We also put the raspberry pi pillars in the wrong place, so that needed fixing as well.  We have invested in a new raspberry pi 2 model B for ElMo - it has a beefier processor and more GPIO pins than the original model B.  As I type, I am upgrading the packages on the original model B - we plan to use that for testing some of the sensors before adding them to ElMo.  That just required (as the root user)

apt-get upgrade

Next time we are hopefully going to bolt on a few bits of vex hardware to attach our sensors to, then get the wires to the motors soldered.  We have about two hours of soldering experience between us, so that might be fun!

Skittles and Solenoids

Before we go off on our holidays, I've been thinking about the skittles challenge - we will be trying to add some extra 'kick' to the ball when we reach the halfway line.  To do that, I'm hoping we can use a solenoid connected to a lever (most solenoids I have seen only move around 1cm, so we can hopefully attach a lever to give us a bit more oomph).  I've not done anything with solenoids before, so this instructable (admittedly for an arduino) has given me some ideas about how everything goes together.

Controlling solenoids with arduino

I also found a youtube video of a raspberry pi connected to a solenoid - here's hoping we can acheive something similar

We'll be back in a couple of weeks, when we will start to build our diddyborg

We've been selected to take part in PiWars on 5th December - wahey!  So we'd better crack on and build ourselves a raspberry pi powered robot then.  We'll be documenting the creation of ElMo1.0 on this blog, so be sure to check back for updates.