PiWars 2017

Well – we’ve been beavering away in the background on the next Metabot, and we’ve had 2 prototypes so far to the ‘remote control car’ stage.

The changes to skittles and the unknown quantity of the “slightly deranged golf” are causing mechanical design headaches and we’ve got big plans for the software that might or might not come to fruition in time for the event. With less than 2 months to go, its certainly squeaky bum time!

This time I’ve tried experimenting with making my own PCBs:IMG_20170121_180217

Before eventually deciding that I couldn’t get enough accuracy for a 0.5mm pitch SSOP device and getting Ragworm to make the boards for me.  I’ll post pictures of those when they arrive.  I’m sure I’ll have good enough accuracy for traditional through-hole PCBs at 0.1″ pitch though.

And here’s out latest prototype.  TBD if this will be the chassis that we actually compete with, but its a good starting point for playing with the software:

IMG_1011 IMG_1012


PiWars 2015 was awesome.  The most amazing thing was the number of different solutions to the same set of requirements.  The competitors was friendly, the event was well organised and a good time was had (by us anyway!).  Tim and Mike should be very proud of what they’ve done here.

Metabot did us proud – coming second in the Obstacle Course and Skittles challenges and second overall in the “A4 and under” category.

Full results can be found here: http://piwars.org/2015-competition/results-of-the-2015-competition/

There are some things we should have done differently and things we did correctly.  We’ll be looking at what lessons we’ve learned over the next few weeks (and maybe prepare for PiWars 2016?!)

In the meantime, here are some videos of Metabot in action:


Final tinkering

Over the week we got the last hardware pieces finished – the ball flinger is complete and the body covers are cut and attached. And team mate Emily did a cracking job on the decorative touches (see below).

The rest of today is going to be a day of tinkering – software tuning and testing. The trick today will be to not regress anything – changes need to be small and self contained.

We’ll be at the meetup this evening – hope to see some of you there. I’ll leave you with a final glamour shot of the robot for those of you who won’t be there to see it in the flesh.


The home straight

This time next week, we’ll be in the Computer Lab, setting up our mobile pit and staring in wonder at the other roboteer’s creations.

So where are we?

Its always easier to list the things which still remain to be done, so lets start with those:

  • Make more options configurable via the command line UI
  • Finish our ball flinger (for the skittles event)
  • Add decorative touches to the robot
  • Get the connection to the IMU working properly and write code to process the output into a useful form
  • Integrate that data into the event code
  • Lots of motion control improvements (smooth acceleration, tuning to get the most out of our motors)
  • 3 point turn code needs improvement

Its clearly going to be a very busy week!

But what have we achieved?  If PiWars were today, how would we do?

  • Proximity Alert has code which would do, though it could always be closer
  • Speed Test has code which would do, though it could do with driving straighter
  • Pi Noon has code which would do and a wire holder which should work, but the driver needs more practice!
  • Obstacle course has code which would do (but see above for driver)
  • Line following code has code which would do, but it can always be faster

So I’d better get on with it…

We’re planning to be at the meetup at the Cambridge MakeSpace on Friday evening – hopefully we’ll see some of you there 🙂

Proximity Alert

With the rebuild complete, we can finally move on to fine tuning the code for the events.  John had a great weekend here, with working code for the proximity alert.

The robot uses optical sensors to spot the wall – we’re using A to D converters on the Arduino to read the amount of reflected IR light.  Away from the wall, virtually no light is reflected.  As you get closer, the reflection gets brighter.  The trick is to decide at what level you should stop.  We have multiple sensors on the front so that if the robot doesn’t approach the wall perfectly straight on, one of the side sensors will still spot the wall and stop us before collision.

The next task in the tuning will be to test many times and against different types of wall – that’ll tell us what sort of repeat-ability we have – which will be key to getting a good result on the day.

Total rebuild 2

After a mammoth weekend effort, John got the robot back into (almost) working order in the new chassis.

We’ve had a fun evening driving it round the office, testing out the line following sensors and seeing what sort of slopes it can climb up.

Snags we’ve hit:

  • the line following doesn’t work
    • we *think* that the line following sensor array has been bolted on backwards, so the robot is turning away from the line instead of turning towards it.
  • The new chassis has a slight twist in it
    • But it doesn’t seem to affect the straightness of travel (phew)
      • probably because our front wheels don’t do any steering anyway
  • The motors were wired backwards initially

Things which are great about the new chassis:

  • We’ve managed to fit in bigger motors for moar powa!
    • Which makes us quite a lot heavier too, but hey-ho
  • The battery compartment is big enough for our bigger batteries
    • and as a result, the batteries lasted for this evening’s testing session
  • The logic power switch has been moved away from the motor power switch, so no more accidental turning off the wrong one!
  • It has an external USB programming port for the arduino
    • so no more fishing around a cramped compartment trying to get the connector to go in
  • It still fits inside the A4 footprint (with about 1mm to spare!)
  • It’s red!
    • Which is obviously the colour of fast things 🙂

20151116_223117 20151116_223148

Total rebuild

So what should you never do in the run up to a competition? Throw away your robot and start again. But that’s (almost) what we’ve done…

So the old robot chassis was always intended to be temporary – made of 3mm cardboard and aluminium brackets. We finally got round to replacing it with a chassis made of 5mm PVC foamboard cut on a CNC router. But it means a tedious task of removing all the parts from the old chassis, bolting them on the new and re-routing all the wires.

We’ll see shortly if we’ve managed to do that without error…

Here’s a picture of the job half done.


Line following

John and I had a session last week trying to get the line following sensors to produce the results we expected. To cut a long story short, we ended up putting blinkers on the sensors which seems to have made all the difference.

John then went away and put together some line following software – and it seems to work. There might be a bit of tuning to be done and some alterations to the calibration code, but it does seem to get round a test course:

Its alive!

So after the “serial over USB” problems (see last post), we removed USB completely, switching over to use the built in UART port on the Raspberry Pi and connecting direct to another serial port on the Due (it has lots!).  Both devices run at 3.3 volts, so only 3 wires are needed – Tx, Rx and Gnd.  A quick search and replace and recompile of the Due code to change the port it is listening to and we fired up the code again – and it worked!

Here’s video of us driving it round the office under joystick control:

Arduino serial over USB problems

Our design calls for an Arduino (to allow real-time stuff like outputting steps, running control loops, etc). We’re using an Arduino Due.

We had planned to get the Raspberry Pi to talk to the Due over ‘serial over USB’ – i.e. we connect the USB port on the Due into the Pi and then send bytes to the /dev/ttyACM0 device that gets created by the OS.

This worked, but after a while (30s or so of chatter) the port would stop responding. A quick google showed that a few other people have seen similar behaviour, but no one had a solution. 🙁

Now to find a workaround…

The plan here is to get last year’s Metabot code (with as few changes as possible) working on the new robot so that we can try it out and check the performance is sufficient.  If we need new motors shipped from China, I’d like to know now rather than halfway through November!