It’s happened to all of us. You’re at competition, something breaks, and you rush frantically to fix it. With the drive team breathing down your neck because they have to go queue, you put the last bolt in place and the robot is wheeled out of sight and onto the field. So you sigh, and run to the stands, only to see the robot sitting there twitching instead of running, because something in the repair wasn’t correct. Something that could have been found with a 30 second test.
With the time constraints we have during the build season and at competition, it’s extremely easy to forget to test, or to not leave enough time for testing. Sadly, this isn’t a phenomenon experienced only in FIRST. Corporations constantly release products with bugs in them that could have (and in some cases really should have) been identified and fixed with a testing process. A great example of this occurred yesterday - Antivirus maker McAfee released an update that shutdown 100’s of thousands of computers. (see http://blogs.zdnet.com/hardware/?p=8108 for reference). The impact of this is huge for affected companies.
So, as you start to plan for next year, I want to encourage everyone to take this as a lesson, and add some time to your schedule for testing. During the build season, spend some time figuring out exactly how you’ll test each component. Figure out and write down somewhere what the test results should be. If you need to test something with the drive train, is it enough to spin the wheels with the robot on blocks, or do you need to set it down and actually have it move? If you’re testing a manipulator of some sort, what field elements do you need readily available to confirm that it actually works? Spend some time now thinking about these things - I can guarantee 9 months from now you’ll be too busy to figure it out.
Our team has a system of testing every mechanical action of the robot after we change the battery before a match to ensure everything is working. If a problem occurs on the field, we don’t touch anything and turn it on in the pit to diagnose and fix the problem. We even do a thorough check before matches and eliminations to ensuring the robot’s status and you would be surprised at what you can find changed within a match. Before an elimination last year we were extremely close to losing the sprockets on our left drive system, several crucial cables and connections were about to come undone(we now use zipties on power and other connections known to come lose so that it does not happen again), lots of bolts and screws were nearing coming out, and other minor issues that would have affected the outcome of our matches.
Lessons learned, system checks take time but are worth it in the long run!
We also added some self-test software to the robot this year. It helps us to check mechanical operation of the robot, sensors, limit switches, motor currents within expected limits etc.
Part of a “quick test plan” includes a good robot cart where you can run the robot wheels in place without having to worry that the robot will drive off the cart or fall over. For those who are looking for somewhere to start, start there. Bonus features include spots for test batteries, multimeters, small tools, and zip ties in case something is noticed in queue.
Team 45’s “preflight checks” are done before changing the battery. This conserves power for the actual match, but it does leave the potential for a battery problem to be missed.
I understand that doing a system check and not wasting power to use in a real match, but 2.5 minutes of play does not drain a battery and neither will adding at most 60 seconds of testing. Like you said, battery problems can be missed and it is nice to have the assurance that when you shut it off everything works and you do not have to change/fix anything.
Ditto for 177. We always do a 30 second functional test before changing the battery and sending the robot out. The drivers are trained never to leave the pit without it and or drive coach won’t let us forget it either.
I want to tell two stories that REALLY illustrate the point the original poster was getting at.
Before 2001, there were no divisions at the championship. Each year there were 200-250 teams in one large competition, with the top 8 getting to pick alliance partners for the eliminations (that might have been expanded to a top-12 in 2000, but I can’t remember).
In 1999, my team at the time (308 - Walled Lake Monsters) were ranked 4th with one match to play. We were paired with Team 1 (The Juggernauts, one of the eventual winners of the championship) and we were going up against a couple of lesser robots. All we had to do is have a mediocre score to jump into the #1 spot. Just prior to the match we had to do some pit work on the drive train and the pit crew plugged the motors in such that the front motors were fighting the rear motors. Thanks to Team 1 we won the match, but due to us not being able to drive, we had a poor qualifying score. We dropped to the 10th seed and we weren’t picked for eliminations. One mistake sent us from the #1 seed to watching from the sidelines. That killed me. (note that we went to the match without testing because of the fix taking too long and we didn’t have much time to make it to the match)
At the 2000 championship, we had a similar situation. The pit crew had to unplug the drive motors in order to demonstrate something to some judges in the pit. Like in 1999, we had to rush to make our match and didn’t do a function check. When the match started, we quickly realized that the motors weren’t plugged in. We salvaged a few points by using the arm on the robot to drag the robot to the ramp. That was match 6 of 7 and we were ranked 6th going into that match. We wound up with a poor qualifying score in that match and we finished ranked 14th. Had we had a mediocre score we would’ve ranked around 7-8. Once again, we weren’t picked and we watched from the sidelines in eliminations. The only solace is that the presentation to the judges apparently worked since we won the Leadership in Control award, but I would have rather been playing in the eliminations.
I am one of the biggest advocates you will find of having a pre-match checklist that gets done just before pushing the robot out of the pits. It’s unfortunate that it took such horrible experiences to make me that way.
We actually (try) to keep 2 checklists for pre-match. One is a no-power test, which is mainly just visual inspection (broken wires, pneumatics closed, physical damage, etc). If we have time, we go for a power-on test of all the systems. I also do a quick test of the control board right before the match once we plug the cypress back in (it gets taken out to increase the classmate charging rate)
We had an issue a couple of seasons back with a sensor cable that got dislodged when the battery was changed, so now we always do our checks with the new battery.
At our second regional this year, we wer convinced that we we’re having significant battery issues, because the robot couldn’t strafe. It was only untill 1.5 hours before pit closed on thusday that we learned our mechanum wheels had bent due to all the banging after coming off a bump. Luckily we were able to show some amazing team work and fix all for wheel in time for pits to close…
now we have to check the wheels after every match (we also bought new ones, as the ones we were using were used from 2007)
Team 604 does a few things to ensure robot reliability. Some of it is a lot of excess, perhaps unnecessary work, but it’s served us really well this season; we haven’t had a single “dead robot” issue. We probably would have gotten away with a lot of our precautions, but it’s better to be safe than sorry.
Before the competition:
-Design the robot to be robust and electronics to be clean. The latter helps greatly during the competition to debug any problems and reduce the risk of electrical failure.
During the competition in the pits:
-Pre-match power-on test and test all functions (We use an old battery, then switch in a new one)
-Keep a list of battery rotations
During the competition while queuing:
-Check the Classmate joysticks before each match (We’re afraid that it won’t hold USB1, USB2, etc.). As an FYI, if you go to the “Diagnostics” tab on the classmate, and pull the trigger of your joystick, the green LED under “USB Devices” should turn blue.
-Visually inspect the mechanical systems
-Check the tightness of the nuts holding the large AWG wires leading to the PDB
Once the robot is on the field:
-I push in every PWM on a victor, push the modules into the cRIO, and push any other small signal wire that might jiggle loose. It takes about 15 seconds, and I do it while the robot is booting up, so I don’t get yelled at by the field crew =)
-Check the lights on the radio (for both power and Ethernet comms), any breakout boards, sidecar, and victors.
we learned the hard way