General Principles: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
This section describes general practices of designing, building and debugging the robot. These practices may involve multiple disciplines. Students are highly encouraged to learn multiple disciplines because when the robot ''does not work'', you have no idea if the problem is ''mechanical'', ''electrical'' or ''programming''. Knowing just one discipline will render you handicapped in debugging the root cause. For example, the most common problem is: ''a subsystem does not respond to control''. A programmer may try for hours looking into the code trying to figure out why the code is not controlling the mechanism. But in reality, the cause could be as simple as the motor was unplugged. Therefore, when something is not working, one needs to understand how the mechanism works in the big picture involving both mechanically, electrically and programmatically. The most useful debugging technique is ''divide and conquer''. To apply this technique, you need to understand how the mechanism works in the complete picture. | This section describes general practices of designing, building and debugging the robot. These practices may involve multiple disciplines. Students are highly encouraged to learn multiple disciplines because when the robot ''does not work'', you have no idea if the problem is ''mechanical'', ''electrical'' or ''programming''. Knowing just one discipline will render you handicapped in debugging the root cause. For example, the most common problem is: ''a subsystem does not respond to control''. A programmer may try for hours looking into the code trying to figure out why the code is not controlling the mechanism. But in reality, the cause could be as simple as the motor was unplugged. Therefore, when something is not working, one needs to understand how the mechanism works in the big picture involving both mechanically, electrically and programmatically. The most useful debugging technique is ''divide and conquer''. To apply this technique, you need to understand how the mechanism works in the complete picture. | ||
# Code reading | # Code reading gamepad controls. | ||
# Code sending | # Code sending gamepad values to robot controller. | ||
# Robot controller sending control signals to | # Robot controller sending control signals to motor controller. | ||
# Motor controller sending electricity to the motor. | # Motor controller sending electricity to the motor. | ||
# Motor moving the mechanism. | # Motor moving the mechanism. | ||
With this complete picture, you can pick a point where you can easily figure out if the control successfully reached that point. For example, point 3 above was about the robot controller sending control signals to the motor controller. Ask yourself this question: ''how can you tell if the motor controller received signal from the robot controller?'' For a TalonSRX motor controller used in FRC, one can tell by looking at the LED light on the controller. If the motor controller received a ''forward'' signal, it should flash green. If it received ''reverse'' signal, it should flash red. If this is indeed the case, you can rule out problems from point 1 to point 3. Therefore, the problem is not in the code. If the motor controller does not have status light (e.g. FTC motor controllers), you may pick point 4. Then, the question is: ''how can you tell if the motor controller is sending electricity to the motor?'' You can easily prove that by getting a known good motor and plug it in to the motor controller and see if the code will spin the known good motor. If it does, then the problem is the motor. If it does not, the problem is upstream from point 1 to point 3. | With this complete picture, you can pick a point where you can easily figure out if the control successfully reached that point. For example, point 3 above was about the robot controller sending control signals to the motor controller. Ask yourself this question: ''how can you tell if the motor controller received signal from the robot controller?'' For a TalonSRX motor controller used in FRC, one can tell by looking at the LED light on the controller. If the motor controller received a ''forward'' signal, it should flash green. If it received ''reverse'' signal, it should flash red. If this is indeed the case, you can rule out problems from point 1 to point 3. Therefore, the problem is not in the code. If the motor controller does not have status light (e.g. FTC motor controllers), you may pick point 4. Then, the question is: ''how can you tell if the motor controller is sending electricity to the motor?'' You can easily prove that by getting a known good motor and plug it in to the motor controller and see if the code will spin the known good motor. If it does, then the problem is the motor. If it does not, the problem is upstream from point 1 to point 3. | ||
Latest revision as of 21:17, 5 May 2024
This section describes general practices of designing, building and debugging the robot. These practices may involve multiple disciplines. Students are highly encouraged to learn multiple disciplines because when the robot does not work, you have no idea if the problem is mechanical, electrical or programming. Knowing just one discipline will render you handicapped in debugging the root cause. For example, the most common problem is: a subsystem does not respond to control. A programmer may try for hours looking into the code trying to figure out why the code is not controlling the mechanism. But in reality, the cause could be as simple as the motor was unplugged. Therefore, when something is not working, one needs to understand how the mechanism works in the big picture involving both mechanically, electrically and programmatically. The most useful debugging technique is divide and conquer. To apply this technique, you need to understand how the mechanism works in the complete picture.
- Code reading gamepad controls.
- Code sending gamepad values to robot controller.
- Robot controller sending control signals to motor controller.
- Motor controller sending electricity to the motor.
- Motor moving the mechanism.
With this complete picture, you can pick a point where you can easily figure out if the control successfully reached that point. For example, point 3 above was about the robot controller sending control signals to the motor controller. Ask yourself this question: how can you tell if the motor controller received signal from the robot controller? For a TalonSRX motor controller used in FRC, one can tell by looking at the LED light on the controller. If the motor controller received a forward signal, it should flash green. If it received reverse signal, it should flash red. If this is indeed the case, you can rule out problems from point 1 to point 3. Therefore, the problem is not in the code. If the motor controller does not have status light (e.g. FTC motor controllers), you may pick point 4. Then, the question is: how can you tell if the motor controller is sending electricity to the motor? You can easily prove that by getting a known good motor and plug it in to the motor controller and see if the code will spin the known good motor. If it does, then the problem is the motor. If it does not, the problem is upstream from point 1 to point 3.