Quote:
Originally Posted by kamocat
...
They sometimes don't know how to tell whether a problem with the robot is due to programming, wiring, field communications, or mechanical.
I'd like to relieve rookie teams from a lot of that stress and misunderstanding.
Is there a document that would help solve this problem, or do I have to make one?
|
Marshall,
The thread seems to have drifted from this first query so I will answer this only. Determining where a fault may lie is a not a science but more of a black art. A document for determining faults would be almost robot specific. As Alan has pointed out, default code is not universally used now that we are using the cRio. There is one thing that I try to get team members to follow which is not robot specific. That is
LISTEN to the robot. The sound it makes, the reaction it performs, the way it drives are all messages that are spoken in robot. You must listen to the robot to determine if there is a fault. Two drive motors wired in opposition make a sound that is almost discernible from across the pit. A good maintenance person often may not speak robot but can understand the language.
I remember a robot problem from two years ago in Atlanta that a team struggled with for most of a day. They called me over on Saturday to help diagnose the problem. When I had them run the robot forward and reverse, there was no doubt that the drive chain was loose and jamming against a frame part. The robot spoke but they didn't hear. Others heard it but were ignored or failed to speak. I know many people who would have understood the problem because they would have listened to the robot. They won't all tell you they "listened" to what the robot had to say, but they would have diagnosed the problem in the same time and arrived at the same conclusion.
Listen to your creations, they speak all the time. If you don't listen, they will get your attention in a much more spectacular fashion using smoke, cracked parts, metal shavings or a lost Einstein trophy.