The days following the Race to the Wall provide a great opportunity for reflecting on what you have learned. It’s the right time to think about what worked well, what went wrong, and what you need to do differently to turn your team into a well-oiled engineering machine and your robot into a champion.
With this in mind, I thought I would share some observations on common mistakes I saw in this year’s Race to the Wall.
1. No gears on the motors
As soon as I see a robot with no gearing between the motors and the wheels, I know there are problems in store. With a great deal of care, you can just about get away with this in the race to the wall. If your robot gets off the starting blocks at all, it may well gradually build to an impressive terminal velocity before hammering into the wall. However, stopping abruptly on the black line at the end of the return journey usually proves impossible.
Although you can just about get away with ungeared motors in the Race to the Wall, where speed is of the essence, using them in the RoboSumo tournament makes no sense. Nevertheless, we see this every year: One or two robots without gears limping feebly around the arena before being mown effortlessly off the table by quite modest opponents.
2. 9V connected to the PIC
In previous years, the rules of our in-house RoboSumo tournament specified a limit of 4 x AA batteries, which effectively limited the nominal supply voltage to 6V. I probably shouldn’t be surprised that, having relaxed the constraint this year, we are now presiding over a rapidly growing mountain of blown PIC microcontrollers. As soon as I saw the first 9V battery in class, I should have known this would happen.
Solution: Commit this generally applicable rule to memory: Before connecting a voltage supply to any electronic component, consult the datasheet to find out the maximum rating. I’ll give you a clue what the maximum voltage rating of the PIC18F4620 is – it’s not 9V!
3. No colour coding of wires
One thing I think all the RoboSumo tutors agree on is that inconsistent colour coding of wires in a breadboard circuit is the single biggest cause of electrical errors. I just don’t understand why people do this.
People tell me “I was just working something out, so I used whatever colours came to hand. Once I get it working, I’ll tidy it up and fix all the colours.”
The most important time to have consistent colour coding is when you’re working on the circuit, trying to iron out any problems. Tidying up isn’t something you do at the end of the build to make it presentable so that the teacher gives you a good mark. When you’re working with complex systems, working neatly and methodically is the only way to get things working reliably.
Repeat after me:
- Red (and only red) for positive supply wires (e.g. 5V).
- Black (and only black) for ground wires (0V).
- Never use red or black for wires that change voltage.
4. Stripped ends on wires are too long
When you’re stripping the end of single core wires to insert them into a breadboard, you should only strip the insulation from the last 5mm of the wire. If you strip much more than that, you will either have the excess bare metal snaking around inside the board, or else it will be exposed above the surface where it could easily cause a short circuit by touching another exposed wire (or the leg of a resistor).
5. Stranded wires inserted into breadboard
Several things you’ll want to connect to the breadboard (battery holder, light sensor, etc) come with stranded wires. This is a good thing because stranded wires are much more flexible than single core ones. However, a common mistake is to insert the stranded wires directly into the breadboard. This doesn’t work very well at all. It can be done, but the wires are prone to fraying or falling out. In the end, it cause a lot of headaches.
Solution: Solder pin connectors onto anything that has stranded wires. This makes for a much more stable connection and generally a much neater circuit.
6. Over complicated circuits
When a RoboSumo team doesn’t know a lot about circuits, a tempting strategy is to go looking for a circuit they can just go ahead and build without understanding it. Big mistake. My advice is to restrict your RoboSumo design to things you understand. In the long run, choosing a simpler circuit, and investing the time in understanding it, produces much better outcomes.
Solution: If you’re building a circuit from a diagram you don’t completely understand it, stop right now! Either study it until you do understand it, or look for something else that you can understand.
7. Bad breadboards
When I see a breadboard that has had a part chopped off it, I know in my heart of hearts that it can never again really be relied upon. Personally, I never use a chopped breadboard if I can possibly help it. Even if it’s not the reason that, for example, the PICkit 2 can’t program your PIC, the possibility that it might be to blame will muddy the waters considerably.
Solution: Start with a breadboard that’s the right size and if the back ever comes off it, just discard it.
8. Over complicated code
Over the last week or so, I’ve read some incredibly complicated code for the Race to the Wall. Now don’t get me wrong – it’s a good thing to get creative when trying to work out how to control your robot. Trial and error costs you nothing other than time and effort, and it’s a great way to learn. However, please bear in mind that the final program for a relatively simple robot behaviour should be simple and concise.
I’m just saying…
while (PORTDbits.RD7 == 0) LATD = 0b00001010; // forwards to wall while (read_analog_channel(0) < 512) LATD = 0b00000101; // reverse to line while (1) LATD = 0; // stop forever
9. Leaving things until the last minute
I’ve been asking a lot of teams about their experiences in the Race to the Wall. In particular, I asked teams what they would do differently to avoid whatever problems they encountered. The most common answer was to prepare much further in advance and not leave things to the last minute. I think this is perhaps the single most important lesson of the Race to the Wall.
10. “He/She/It is at home”
I spend a lot of time chatting to RoboSumo teams, especially those who are having problems with their robots. Of course, it’s perfectly normal to have some problems with your robot, but a lot of people just can’t help feeling defensive about it and loudly blaming someone else.
- JOHN/JANE did all the programming and he/she isn’t here today.
- JOHN/JANE built the circuit and he/she isn’t here today.
- JOHN/JANE took the robot home and he/she isn’t here today.
I know these statements are sometimes just the honest truth, but I’m just telling you that I hear them repeated a lot 😉
Solution: Make sure everyone on the team understands the program, circuit, etc.
You’re all expected to understand these things, even if you’re not the one that wrote, designed or built them. If you need to spend time teaching each other to achieve this, that’s time very well spent. Make sure you document this kind of peer instruction on your blog so that we can take it into account when assigning marks for contribution to group process. Both teacher and learner will be rewarded for this activity since knowledge sharing is such an important aspect of effective team work.