Back in 2011, we did not build our first 3D printer just for the sole purpose of doing it, we also did it (and probably mostly) to be able to build other things, and more specifically robot parts. Taking part to the French Robotics Cup had been a project some of us had even before creating the club, but we were lacking momentum and tools. One of the main issues is that ENS is not an engineering school, but rather a pure theoretical science school, which left us with no prior experience and almost no access to proper hardware tools (the only ones we could have access to belonged to Physics labs and were securely locked).
Thus, being able to create our own parts and build them from the bottom up (as opposed to machining from top down) was a huge thing. With our custom-designed plastic parts and a few pieces of wood, we have been able to build very light yet sturdy robots (as opposed to the huge all-metal ones most engineering schools teams bring to the Cup).
Webcam holder used on our 2011 robot
We used stepper motors for propulsion. While this might sound like a weird choice, using steppers let us not spend a shitton of money (which we did not have anyway) on odometry and buy some servomotors and electronics instead. Indeed, as a stepper is controlled by sending steps which increment or decrement the motor axis rotation angle, we could move with a very decent accuracy by just trusting that our system worked, which implied calibrating things well so that tires did not skid and that we were not getting bumped by other robots. Sadly, while the second part was mostly verified in 2011 and 2012, it seems that in 2013 robots were getting more and more agressive, and we might need to add some form of odometry for future years.
We also tried to stay KISS (Keep It Simple, Stupid) for the actions and strategies. For instance in 2011, after spending a long while trying to write a super awesome AI that would user computer vision to understand the game board and act upon the other robot actions, we moved onto first following a scripted plan with hardcoded positions and actions and then running a simple IA which would try to detect game items and correctly act on them. Using this very simple technique scored us the 24th rank, which was an awesome achievement for a team with no prior experience and no engineering support (and I’m not just boasting there, that was other teams told us :)).
In 2012, the global theme was Pirates, and the main goal was to grab CDs (which pictured coins) and wooden blocks (picturing gold ingots) and bring them into a predefined area. A bunch of ingots and CDs were placed on towers called “totems”:
“Totems” full of monies !!1
We decided that our main goal would be to simply get everything from one of these totems, not by using some fancy robotic arm, but simply by making a hollow robot which could go over the totem, with appropriately cut doors to capture the game items. I guess we were the only team to use this fun strategy, which paid quite well (we ranked 56 even though 3 or the 5 games went very bad because of hardware issues). Here’s a video of the robot beautifully performing its script:
[vimeo width=”600″ height=”400″]http://vimeo.com/42726821[/vimeo]
To conclude, the main take home message of this post is: KISS. Don’t shoot way too high before having a simple prototype that works. Many teams coming to the French Robotics Cup bring heavy and super complicated robots with dozen of sensors, but this complexity kills everything and they can’t correctly move or perform their actions, because the robot is too heavy, because writing software is super painful when you have to deal with dozens of inputs and because debugging (both software and hardware) is close to impossible. Don’t try to be too smart too. Writing an efficient AI is totally non trivial, especially when you have to rely on noisy signals (such as computer vision and whatever technique you might use to locate the other robots). A simple hardcoded plan might work just as well and be 10 times easier and shorter to develop. So yeah, KISS.
