One of the biggest problems I see in people with troubleshooting is not knowing where to start.
There's people that will blame it all on the programming, or blame it all on the mechanical. There's people that will ask you "what's the problem" as if you knew what it was and simply were slow to fix it.
Troubleshooting is difficult, and it usually requires a lot of experience. In FIRST, we're lucky to have almost identical control systems. Most robots use the same concepts. (e.g. limit switches, joystick drive, button toggles, pistons and motors) Most of us run into the same sorts of problems, if not the same exact problems. However, many of us do not get adequate testing before the regional. We end up finding out
at the regional that major components of our robot don't function.
It seems reasonable that we could make some sort of document to help people in troubleshooting. You may think "they can just search the forums", but as stated in Bill's Blog, wifi hotspots at regionals are disallowed this year. In addition, forums aren't very printer-friendly – they are post-centric, not content-centric – and don't lend themselves to definitive and well-organized content.
While it's true that there are many teams at the regionals that are more than eager to help, it's much harder to communicate the process of finding the problem than to communicate the problem. Saying "you plugged your PWM cables in backwards" doesn't help them find a problem in the future, except for that one thing. Because of this, rookies often have to rely on veterans for help and troubleshooting. Ideally, we would like to shift from reliance to collaboration as the team progresses. Usually this happens, but this can take a couple years. The faster a team can switch from reliance to collaboration, the earlier it can provide an engineering experience to its students.
There are other resources that would aid in troubleshooting. (e.g. documentation and clarity, how to use instrumentation, predicting how your robot will fail, compartmentalizing and isolating the parts of the design). This thread is about creating a document to describe what problems are often run into, and a checklist to methodically check common points of error or failure.
As for why I'm posting it here: I want to make the resources I create available to the FIRST community. Collaboration and sharing of resources is an important part of FIRST, and as we improve the resources available, we can overcome greater technical challenges.
I welcome input, collaboration, questions, and other resources.
Below I've listed some categories that problems fall under:
- low battery
- no communication
- Robot radio
- Driver station
- Main router
- programming laptop
- cables
- watchdog
- no communication / intermittent communication
- code executing too slow (user watchdog)
- robot disabled
- Power wiring
- Data wiring
- Mechanical
- friction / binding
- leverage
- opposing forces
- motor speed / torque
- programming
- forgot to implement
- error in coding
- concept doesn't work