This robot is designed to compete in the Robocup Junior Soccer A Lightweight competition. In the game, there is an electronic ball that gives off an infrared signal. Teams consisting of two 1.25kg robots play against each other on a 1.2m × 1.8m pitch. There are rules governing the size and shape of the robots. The robots play football autonomously for two 10 minute halves.
A short video of the robot in action can be found on youtube
I entered this competition with my friend Andrew Wightwick. He focused on the chassis design and manufacturing, while I was more involved in the electronics and software aspect of the robot. As such, this document does not describe the entirety of the robot.
Version control - Git
To keep track of the software as it was written, as well as this document, a distributed version control system was used - Git. Essentially, this allows changes to be "committed" to a history, such that you can see what changes have been made, as well as revert to older versions.
Additionally, it provides a maintainable way of working from multiple locations. The Git repository containing this information, as well as being stored locally, can be "pushed" to a remote server. This can then be "pulled" off the server to a different computer, which means that if work is lost, it can be restored from the online copy.
The controller can be though of as the "brain" of the robot. It reads from and writes to the sensors, and drives the robot in response.
The robot uses a FEZ Panda II, from GHI Electonics. It's an Arduino based design, but boasting more GPIO pins, and programmed in C#, rather than C++. I'd had experience with the Arduino before, but had found the software frustrating. Since the FEZ runs the .NET Micro Framework, C# is available, which is a much nicer language.
The wheels are designed such that they are effectively frictionless in one axis. This is achieved by mounting a set of smaller perpendicular wheels around the circumference. These smaller wheels are free to turn even when the main wheel is held still, allowing a free component of motion along the axis of the wheel. At the same time, the wheel can be powered as normal wheel.
The small wheels in my design are washers. These are sufficient, as the sharp edge of the washer provides plenty of friction in the direction of drive, and the perpendicular friction is fairly low. Additionally, washers are cheap! The axles for the washers needs to be a ring. The easiest way to get a ring is from a keychain. The ones the wheels use is a 5.1mm split ring. The next thing needed is a way of holding the split ring onto the motor shaft. This was done with a circular laser-cut aluminum hub, held onto the split ring with cable ties.
The most time consuming part of this aspect of the artefact was designing the aluminum hub. This is partly because of the accuracy required. A technical drawing program was used to design this. The design went through multiple sizes, as the measurements of the washers and split ring were gradually improved. The final design was set off to microkerf, where it was laser cut in 4mm aluminum.
Motors and Drivers
The motors chosen can take up to 3.3A of current. In order to drive these safely, the driver chips have to be able to take at least this much current. Initially, the plan was to buy pre-built motor drivers, but they were generally too expensive, and either insufficiently powerful, or much more powerful then they needed to be. In the end, I decided to build the drivers myself.
The chip used was an L298 dual H-bridge, which allows two DC motors to be powered in both direction, drawing up to 2A of current. By paralleling the outputs, a current of 4A can be drawn. This is more than than the motors will draw, but it means there's no chance of the chip blowing up. The other thing the driver requires are clamp diodes to clamp the motor outputs to the supply voltage, preventing reverse EMF, which can damage the driver chip.