General Principles - Revision history

Mikets at 05:17, 6 May 2024

2024-05-06T05:17:10Z

← Older revision		Revision as of 22:17, 5 May 2024
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 ~~the~~ gamepad controls.		# Code reading gamepad controls.
	# Code sending ~~the~~ gamepad ~~value~~ to ~~the~~ robot controller.		# Code sending gamepad values to robot controller.
	# Robot controller sending control signals to ~~the~~ motor controller.		# 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.

Mikets at 19:17, 5 May 2024

2024-05-05T19:17:55Z

← Older revision		Revision as of 12:17, 5 May 2024
Line 5:		Line 5:
	# 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 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.

Mikets at 19:08, 5 May 2024

2024-05-05T19:08:54Z

← Older revision		Revision as of 12:08, 5 May 2024
Line 5:		Line 5:
	# 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 ~~status~~ 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 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 ~~then in the~~ 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 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.

Mikets: Created page with "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 no..."

2024-05-05T19:04:57Z

Created page with "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 no..."

New page

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 the gamepad controls.
# Code sending the gamepad value to the robot controller.
# Robot controller sending control signals to the 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 status 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 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 then in the upstream from point 1 to point 3.