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...