Sumobot

Sumobot Design

Times have been very busy since the end of the Sumo bot competition but I thought it would be a good idea to go through and document some of the process.

Over all the competition was, as always, exhilarating. Unfortunately, we didn’t win as promised but … we certainly learnt a lot more than both the previous years combined. To recap, the first year the goal was simple : to have a moving robot. The second year we decided to spice things up a bit and designed our own arduino board, albeit it was damaged in the soldering process and never got tested. This year we wanted to change the design while also being sensible about it.

Goals of the new design:

  • faster response to sensors
  • completely interrupt driven
  • very fast robot with simple, but bullet proof logic

With these goals in mind we decided to stick with the Arduino Uno board but program it in pure C, using avr-gcc directly. This was clearly the best trade off as it saved us time from having to redesign the board but we also achieved all of the performance gains as though were running our code directly on the metal, because we were! What do we mean by all this? Well let’s think about the Arduino project for a second. The first things that come to mind are the blue and white controller boards they sell, but really we should be thinking about the Arduino software tools as well. TheArduino ecosystem involves an abstraction layer, some of us like to call it the Arduino Language. This is great for starting off but many of the high level abstractions are expensive.

For example here’s a quote from the Arduino Reference

“You may need to be able to turn pins on and off very quickly, meaning within fractions of a microsecond. If you look at the source code in lib/targets/arduino/wiring.c, you will see that digitalRead() and digitalWrite() are each about a dozen or so lines of code, which get compiled into quite a few machine instructions. Each machine instruction requires one clock cycle at 16MHz, which can add up in time-sensitive applications. Direct port access can do the same job in a lot fewer clock cycles.”

The gist of it is that the layer of abstraction simplifies port manipulation at the cost of a few processor cycles, unfortunately this goes against our goal of having a very fast and interrupt driven system. This ultimately led to the decision that the only way to get the maximum performance from the board was to bypass the Arduino software altogether.

Initially, this meant picking up a copy of AVR Programming and working through the chapters to learn about Data Direction Registers, PINs, PORTs, Timers and other really interesting features of the 8-bit microcontroller. It took a few days to get past blinking lights, but soon I had a binary clock setup then even managed to add an alarm feature to it. All very neat ideas, but soon it was time to get to work on actually designing the program to be run on the Sumo bot. I won’t speak too extensively about that process here, but if you want you can take a look at the source code here. The main takeaway however, was that I learnt many different skills such as Interrupt-Driven programming, volatile memory management and bit manipulation, all of which are transferable to future microcontroller projects. I have gone through and made sure there are useful comments in the code for anyone that wants to take a look who isn’t familiar with microcontroller programming.

Here’s a video of one of the more intense matches! Our robot is the red beast called “Shadow”

Here’s a gallery of the competition day and also some photos taken during the build process.