Quote:
Originally Posted by Chief Hedgehog
So my question is this: What is your order of trouble-shooting the robot? FRC 4607 is lacking on this (as evident by our showing). How do we get beyond this in the future so we never deal with this problem again?
|
I am interpreting the OP's question as "How does one do quick and effective troubleshooting?"
Start by calmly and coolly analyze the problem to get insight into the possible root cause. "Hurrying too fast" may lead one to miss important clues.
Try to observe the failure, multiple times, from different view points. Use tools to give you more view points; i.e. take voltage readings, check for glitches using an oscilloscope, use a camera with a high frame-rate.
Often your robot will have sub-systems that contain "closed loops" where some component is controlled by another and there are sensors monitoring the status of the sub-system. A fault of any kind at one point can manifest itself as a fault at another point in the loop. Probe the system (physically or in software) to systematically follow around the loop to find the fault. Do "sanity checks" for the values measured at various points around the loop.
Disable sub-systems, one at a time, to exonerate them and narrow down the location of the fault.
"Torture" or (over)load the system to cause it to exhibit the fault more frequently or more strongly.
Once the fault is narrowed down to a particular sub-system, work through it in a thorough and systematic way to identify the problem; i.e. signal is present on PWM output of RoboRio, signal is present at motor controller, motor controller has power, motor controller output has appropriate voltages for control input, voltage present at motor, motor shaft is spinning in the correct direction --> find one gear slipping on shaft in gearbox.
If a system is open-loop, it is sometimes possible to speed the trouble shooting process up by using a "binary search" technique. Start by probing at some point near "the middle" of the system and checking if the values seen are good. If they are good, probe at a point half way towards "the end". If they are bad, probe at a point half way back towards "the beginning". Eventually, one arrives at a point where the input to a component or sub-system looks good but the output looks bad.
Discuss the evidence with people with the relevant expertise (on your team and from others). Keep an open mind. A mechanical problem could cause a brief brown-out and cause something that appears to be a software problem.
A checklist is helpful to ensure that one covers all likely points of failure but it is no guarantee that one can discover the cause of a failure. A checklist is much more effective if one can get some insight regarding the possible cause of the failure so certain items can be skipped. The OP's post indicated software/configuration and electrical issues so it would probably have been fruitless to check things like chain tension.
Trouble shooting is a skill that has elements of nature and nurture. You will find that some people have the natural ability to quickly home in on the root cause of a problem. If you can identify such a person (student or mentor) on your team, make sure they are on your development team and your pit crew. One could say that the team member's trouble shooting abilities will be nurtured and developed as part of their FRC experience.