Quote:
|
Originally Posted by ChrisH
1) When they fail, how do you test to determine that they have failed and what was the failure mode?
2) How would we determine whether the failure was in software or in hardware?
3) If it in hardware (like a fried encoder) how would we determine whether the source of failure was a mechanical overload or some electrical problem?
|
Chris,
1) Usually I'll setup a timer in code that will periodically printf my encoder counter to the programming port - like a constantly running diagnostic mode. It prints about once a second or so - slow enough that it doesn't hamper performance during competition, but fast enough to get meaningful information for troubleshooting in the pits. The first check is to power on the robot while disabled, read the encoder counts, rotate the encoder a known amount, check encoder counts again. Repeat in opposite direction.
2) After doing 1), in general if the encoder counts agree, you have a software problem elsewhere. If counts don't agree you have a hardware problem. If counts only decrement, or increment no matter which way you turn your encoder, your non-interrupt phase is disconnected or blown. If you get no counts in either direction, the phase connected to your interrupt is disconnected or blown - or both phases are disconnected or blown.
3) With the encoders we use, the only clue to mechanical failure we've found is to compare the rolling resistance to a brand new encoder. With optical encoders with no detents, too much resistance means you've destroyed the bearing which we've done in the past with excessive side-loads. We don't have a scope either, so our electrical diagnostic is just swapping it out with a new one and seeing if it flies.
If you're reluctant to drop money on a scope,
this might interest you. Some isolation circuitry is recommended though... your mileage may vary =).
-SlimBoJones...