This year will be the 3rd time that I have entered Eurobot as a serious competitor (Last year, in 2011, I attempted to throw an entry together the night before the UK competition for a bit of fun and never really had time to write the software). I’ve spent a lot of time of late reflecting on my experiences in the competition, and it has become apparent that there are several reasons why people enter the competition:
- Small-budget entrants, who are in the competition to see how far they can go.
- ‘Work-in-progress’ teams, who are using the competition as a focus to develop a particular algorithm or technology. These teams are in the competition for the learning potential rather than the winning potential, but are in the competition to demonstrate what they are capable of.
- Large team, large budget entries seem to be the most successful overall. Often, these teams have entered for several years and know the competition inside out. They are serious competitors, who aim to develop a sickeningly impressive machine with the resources available to them.
My previous entries have fallen into the first category, which is arguably the most challenging position to be in. It is very easy to get carried away in the design of the robot, giving yourself too much to do in the limited time available. I was lucky enough in 2009 to be enrolled on a degree course that involved developing a Eurobot entry as one of the modules. It allowed us to devote a lot of time to the robot, and in the weeks running up to the competition, we were more or less constantly at the game table, fine tuning the software, writing escape routines for all sorts of different scenarios which would render the robot useless in a match. An example of this is when the robot reversed up to the scoring zone, there was a chance of some stray playing elements blocking our approach, meaning that the robot couldn’t position itself correctly. A timeout mechanism was introduced that caused the robot to ‘wiggle’ if it was reversing for too long, which knocked the playing elements out of the way. This was ingenious, but was never needed during a ‘live’ game.
We were so focussed on writing these software mechanisms, however, that we failed to notice a fundamental flaw in the design of the robot. We were relying on the stopping distance of the drive system to position the collection mechanism over the column elements. In all our testing, we had the opportunity to fine-tune this distance for the specific table used in the UK competition, (even then it didn’t work flawlessly). On progressing to the finals in France, we discovered that every table was slightly different, and we struggled to adjust the software to compensate. What we had done, quite naively, was gain a misplaced confidence in the mechanics of the collection system, and assumed that it was our software that we needed to adjust in order to correct the problems.
In 2010, we returned with ‘Agent Orange’. This time, we had other commitments which meant that we only had around 4 weeks before the competition to build and program the robot. We were therefore pushed to come up with simple physical mechanisms that didn’t require millimetre-perfect positioning of the robot, which we agreed would be very difficult to achieve on the budget and time restrains with which we were operating.
This highlighted several factors to consider when building a robot for the competition:
- Point scoring capability (PSC) – The number of points the robot is designed / programmed to achieve in a game.
- Point scoring ability (PSA) – The number of points the robot can actually achieve in a game.
- Reliability – How likely it is that PSA = PSC in a game.
- Complexity – Represented by the amount of ‘stuff’ the robot needs in order to achieve its PSC.
- Resources – Time, money, people, knowledge, skills, any external input needed to build the robot. (N.B. I’ve excluded university ranking here, as this is an imaginary resource made up by teams who feel they need to try and mask the fact that they are lacking in other areas.)
The higher the PSC, the more complex the robot will become. As this complexity increases, it requires more resources to keep the robot performing reliably. Therefore, with inadequate resources, complexity has an adverse effect on PSA. It is also important to note that different resources are required for different parts of the project. Your people, time and money will only get you so far towards achieving the ultimate goal of 100% reliability and knowledge, people and skills can not be used to their full potential without the support of time and money.
So in order to realise your team’s full potential, you need to balance the complexity of the robot with the resources that you have. I call this ‘proportional simplicity’.
This is how Agent Orange reached the 1/4 finals in Switzerland, out-performing some of the larger and more ambitious teams. We had a relatively low PSC (6 oranges), but also low complexity. This meant a higher reliability and less demand on resources, which suited our small team, small budget and short time scale.
There were many teams that we encountered that had a higher PSC than ourselves but, their imbalance of complexity and resources meant that their reliability was affected. This was most apparent in the 1/8 finals:
Some could argue that we were ‘lucky’ that our opponents’ robot failed (or the opponents were unlucky) but I say, if you have to rely on luck for your robot to work reliably, there’s something fundamentally wrong!
Of course, having a low PSC can only get you so far when up against teams with a higher PSC AND higher reliability, and all you can do is pull the chord, and watch them show you how it’s done:
This year, the team and I are aiming for R.Me.R.T. to be a transition between ‘small-budget’ and ‘work-in-progress’. Things already haven’t gone to plan; it has taken longer than anticipated to secure funding from one of our sponsors. This has meant that we’ve had to cut back on some of the features that we wanted for the robot, in order to keep our resources and complexity balanced, but I think we’ve managed to stay realistic with what we can achieve. Whether or not this is the case will become apparent as the hardware starts coming together. More on this soon.