Software Principles - Revision history

Mikets: /* Debug Process */

2024-06-03T20:31:15Z

Debug Process

← Older revision		Revision as of 13:31, 3 June 2024
Line 23:		Line 23:
	* '''Code is crashing:''' The code is causing an ''Exception''. This is the most common and easiest type of bugs to fix because when an Exception occurs, you will get a stack dump which shows you the reason and the exact line of code that caused the Exception. It also shows you the history of calls leading to the code that caused the Exception.		* '''Code is crashing:''' The code is causing an ''Exception''. This is the most common and easiest type of bugs to fix because when an Exception occurs, you will get a stack dump which shows you the reason and the exact line of code that caused the Exception. It also shows you the history of calls leading to the code that caused the Exception.
	* '''Code is hung in TeleOp:''' The robot stopped responding to human input.		* '''Code is hung in TeleOp:''' The robot stopped responding to human input.
	* '''Code is hung in Autonomous:'''		* '''Code is hung in Autonomous:''' This is typically caused by an asynchronous operation that never completed.
	* '''Unexpected code behavior:'''		* '''Unexpected code behavior:''' This is typically caused by logic error in the code.
	* '''Robot lost communication:''' This is generally an electrical issue caused by power interruption to the robot radio. The root cause may be in the wiring where the power wire/connector to the radio is not secured so that any impact to the robot will cause power to disconnect. In FTC, it is also commonly caused by Electrostatic Discharge (ESD). The FTC robot running on the field ~~Mat~~ building up static electric charge and discharging to a metal object it hits. This caused the Control Hub to malfunction and disconnected WiFi.		* '''Robot lost communication:''' This is generally an electrical issue caused by power interruption to the robot radio. The root cause may be in the wiring where the power wire/connector to the radio is not secured so that any impact to the robot will cause power to disconnect. In FTC, it is also commonly caused by Electrostatic Discharge (ESD). The FTC robot running on the field mat building up static electric charge and discharging to a metal object it hits. This caused the Control Hub to malfunction and disconnected WiFi.
	When the code does not work as expected, it needs to be debugged and fixed. It is often tempting for programmers to hypothesize the cause and formulate a hack without proving the actual cause. Sometimes the hack seems to address the symptom but most likely the wrong fix. For example, when the robot is going the opposite direction in autonomous, programmers often just find a place to negate a value to force the robot to go the correct direction without understanding why it was going the wrong way in the first place. The following video humorously describes that exact problem-solving mentality.		When the code does not work as expected, it needs to be debugged and fixed. It is often tempting for programmers to hypothesize the cause and formulate a hack without proving the actual cause. Sometimes the hack seems to address the symptom but most likely the wrong fix. For example, when the robot is going the opposite direction in autonomous, programmers often just find a place to negate a value to force the robot to go the correct direction without understanding why it was going the wrong way in the first place. The following video humorously describes that exact problem-solving mentality.

Mikets: /* Debug Process */

2024-06-03T20:28:42Z

Debug Process

← Older revision		Revision as of 13:28, 3 June 2024
Line 25:		Line 25:
	* '''Code is hung in Autonomous:'''		* '''Code is hung in Autonomous:'''
	* '''Unexpected code behavior:'''		* '''Unexpected code behavior:'''
	* '''Robot lost communication:'''		* '''Robot lost communication:''' This is generally an electrical issue caused by power interruption to the robot radio. The root cause may be in the wiring where the power wire/connector to the radio is not secured so that any impact to the robot will cause power to disconnect. In FTC, it is also commonly caused by Electrostatic Discharge (ESD). The FTC robot running on the field Mat building up static electric charge and discharging to a metal object it hits. This caused the Control Hub to malfunction and disconnected WiFi.
	When the code does not work as expected, it needs to be debugged and fixed. It is often tempting for programmers to hypothesize the cause and formulate a hack without proving the actual cause. Sometimes the hack seems to address the symptom but most likely the wrong fix. For example, when the robot is going the opposite direction in autonomous, programmers often just find a place to negate a value to force the robot to go the correct direction without understanding why it was going the wrong way in the first place. The following video humorously describes that exact problem-solving mentality.		When the code does not work as expected, it needs to be debugged and fixed. It is often tempting for programmers to hypothesize the cause and formulate a hack without proving the actual cause. Sometimes the hack seems to address the symptom but most likely the wrong fix. For example, when the robot is going the opposite direction in autonomous, programmers often just find a place to negate a value to force the robot to go the correct direction without understanding why it was going the wrong way in the first place. The following video humorously describes that exact problem-solving mentality.

Mikets: /* Debug Process */

2024-06-03T20:15:07Z

Debug Process

← Older revision		Revision as of 13:15, 3 June 2024
Line 26:		Line 26:
	* '''Unexpected code behavior:'''		* '''Unexpected code behavior:'''
	* '''Robot lost communication:'''		* '''Robot lost communication:'''
	When the code does not work as expected, it needs to be debugged and fixed. It is often tempting for ~~students~~ to hypothesize the cause and formulate a hack without proving the actual cause. Sometimes the hack seems to address the symptom but most likely the wrong fix. For example, when the robot is going the opposite direction in autonomous, ~~students~~ often just find a place to negate a value to force the robot to go the correct direction without understanding why it was going the wrong way in the first place. The following video humorously describes that exact problem-solving mentality.		When the code does not work as expected, it needs to be debugged and fixed. It is often tempting for programmers to hypothesize the cause and formulate a hack without proving the actual cause. Sometimes the hack seems to address the symptom but most likely the wrong fix. For example, when the robot is going the opposite direction in autonomous, programmers often just find a place to negate a value to force the robot to go the correct direction without understanding why it was going the wrong way in the first place. The following video humorously describes that exact problem-solving mentality.

	<youtube>https://www.youtube.com/watch?v=IVmWh97H-OA</youtube>		<youtube>https://www.youtube.com/watch?v=IVmWh97H-OA</youtube>

Mikets: /* Debug Process */

2024-06-03T19:46:25Z

Debug Process

← Older revision		Revision as of 12:46, 3 June 2024
Line 26:		Line 26:
	* '''Unexpected code behavior:'''		* '''Unexpected code behavior:'''
	* '''Robot lost communication:'''		* '''Robot lost communication:'''
	When the code does not work as expected, it needs to be debugged and fixed. It is often tempting for students to hypothesize the cause and formulate a ~~fix~~ without proving the actual cause. Sometimes the ~~resulting fix~~ seems to address the symptom but most likely the wrong fix. For example, when the robot is going the opposite direction in autonomous, students often just find a place to negate a value to force the robot to go the correct direction without understanding why it was going the wrong way in the first place. The following video humorously describes that exact problem-solving mentality.		When the code does not work as expected, it needs to be debugged and fixed. It is often tempting for students to hypothesize the cause and formulate a hack without proving the actual cause. Sometimes the hack seems to address the symptom but most likely the wrong fix. For example, when the robot is going the opposite direction in autonomous, students often just find a place to negate a value to force the robot to go the correct direction without understanding why it was going the wrong way in the first place. The following video humorously describes that exact problem-solving mentality.

	<youtube>https://www.youtube.com/watch?v=IVmWh97H-OA</youtube>		<youtube>https://www.youtube.com/watch?v=IVmWh97H-OA</youtube>

Mikets: /* Debug Process */

2024-06-03T19:44:48Z

Debug Process

← Older revision		Revision as of 12:44, 3 June 2024
Line 26:		Line 26:
	* '''Unexpected code behavior:'''		* '''Unexpected code behavior:'''
	* '''Robot lost communication:'''		* '''Robot lost communication:'''
	When the code does not work as expected, it needs to be debugged and fixed. It is often tempting for students to hypothesize the cause and formulate a fix without proving the actual cause. Sometimes the resulting fix seems to address the symptom but most likely the wrong fix. For example, when the robot is going the opposite direction in autonomous, students often just find a place to negate a value to force the robot to go the ~~right way~~ without understanding why it was going the wrong way in the first place. In order to debug the code properly, you need to apply the following debugging process:		When the code does not work as expected, it needs to be debugged and fixed. It is often tempting for students to hypothesize the cause and formulate a fix without proving the actual cause. Sometimes the resulting fix seems to address the symptom but most likely the wrong fix. For example, when the robot is going the opposite direction in autonomous, students often just find a place to negate a value to force the robot to go the correct direction without understanding why it was going the wrong way in the first place. The following video humorously describes that exact problem-solving mentality.

			<youtube>https://www.youtube.com/watch?v=IVmWh97H-OA</youtube>

			In order to debug the code properly, you need to apply the following debugging process:
	# Identify the code that was performing the unexpected operation.		# Identify the code that was performing the unexpected operation.
	# Trace that code to understand why it is performing the unexpected operation.		# Trace that code to understand why it is performing the unexpected operation.

Mikets at 19:07, 2 June 2024

2024-06-02T19:07:30Z

← Older revision		Revision as of 12:07, 2 June 2024
Line 45:		Line 45:

	=== Trace Logging ===		=== Trace Logging ===

			== Use Our Robotics Framework Library in FTC ==
			Our club has created an extensive Robotics Framework Library. In order to use it effectively, we have created an [https://github.com/trc492/FtcTemplate FTC Template] repository on GitHub. The FTC Template project allows you to fork the project at the beginning of the season. It contains all the code you need to run a basic robot drive base right out of the box. The [https://github.com/trc492/FtcTemplate/blob/main/README.md README] in the repository explains what to do after forking the project and how to add season specific code to the project.

	== FRC Guidebook ==		== FRC Guidebook ==

Mikets: /* Debug Process */

2024-06-02T18:55:50Z

Debug Process

← Older revision		Revision as of 11:55, 2 June 2024
Line 31:		Line 31:
	# Once the root cause is understood, formulate a proper fix and code it.		# Once the root cause is understood, formulate a proper fix and code it.
	# Test the fix to prove that the code is now behaving properly.		# Test the fix to prove that the code is now behaving properly.
	# Make sure the fix works in all ~~possibly~~ scenarios by running the fixed code in all code paths.		# Make sure the fix works in all possible scenarios by running the fixed code in all code paths.
	# If some scenarios are still not behaving correctly, repeat this process until everything works as expected.		# If some scenarios are still not behaving correctly, repeat this process until everything works as expected.
			# Before checking in the final fix, have a mentor/peer to code review the fix.
			# Add detail comments in the code to explain the issue and how the fix remedy the problem.
			# Check in the fix and add check-in notes on what the fix is for.

	== Debugging Techniques ==		== Debugging Techniques ==

Mikets: /* Debug Process */

2024-05-05T17:58:11Z

Debug Process

← Older revision		Revision as of 10:58, 5 May 2024
Line 21:		Line 21:
	== Debug Process ==		== Debug Process ==
	The following shows a list of typical bugs you will encounter:		The following shows a list of typical bugs you will encounter:
	* '''Code is crashing:''' The code is causing an ''Exception''. This is the easiest type of bugs to fix because when an Exception occurs, you will get a stack dump which shows you the reason and the exact line of code that caused the Exception. It also shows you the history of calls leading to the code that caused the Exception.		* '''Code is crashing:''' The code is causing an ''Exception''. This is the most common and easiest type of bugs to fix because when an Exception occurs, you will get a stack dump which shows you the reason and the exact line of code that caused the Exception. It also shows you the history of calls leading to the code that caused the Exception.
	* '''Code is hung in TeleOp:''' The robot stopped responding to human input.		* '''Code is hung in TeleOp:''' The robot stopped responding to human input.
	* '''Code is hung in Autonomous:'''		* '''Code is hung in Autonomous:'''

Mikets: /* Debug Process */

2024-05-05T17:57:36Z

Debug Process

← Older revision		Revision as of 10:57, 5 May 2024
Line 20:		Line 20:

	== Debug Process ==		== Debug Process ==
			The following shows a list of typical bugs you will encounter:
			* '''Code is crashing:''' The code is causing an ''Exception''. This is the easiest type of bugs to fix because when an Exception occurs, you will get a stack dump which shows you the reason and the exact line of code that caused the Exception. It also shows you the history of calls leading to the code that caused the Exception.
			* '''Code is hung in TeleOp:''' The robot stopped responding to human input.
			* '''Code is hung in Autonomous:'''
			* '''Unexpected code behavior:'''
			* '''Robot lost communication:'''
	When the code does not work as expected, it needs to be debugged and fixed. It is often tempting for students to hypothesize the cause and formulate a fix without proving the actual cause. Sometimes the resulting fix seems to address the symptom but most likely the wrong fix. For example, when the robot is going the opposite direction in autonomous, students often just find a place to negate a value to force the robot to go the right way without understanding why it was going the wrong way in the first place. In order to debug the code properly, you need to apply the following debugging process:		When the code does not work as expected, it needs to be debugged and fixed. It is often tempting for students to hypothesize the cause and formulate a fix without proving the actual cause. Sometimes the resulting fix seems to address the symptom but most likely the wrong fix. For example, when the robot is going the opposite direction in autonomous, students often just find a place to negate a value to force the robot to go the right way without understanding why it was going the wrong way in the first place. In order to debug the code properly, you need to apply the following debugging process:
	# Identify the code that was performing the unexpected operation.		# Identify the code that was performing the unexpected operation.

Mikets: /* Debugging Techniques */

2024-05-05T17:42:25Z

Debugging Techniques

← Older revision		Revision as of 10:42, 5 May 2024
Line 30:		Line 30:
	== Debugging Techniques ==		== Debugging Techniques ==
	To understand the root cause of a bug, you need to trace through the code to find out why it is behaving erroneously. There are two ways to trace through the code.		To understand the root cause of a bug, you need to trace through the code to find out why it is behaving erroneously. There are two ways to trace through the code.
	* '''Real Time Debugging:''' Setting code breakpoints and trace through the code in real time.		* '''Real Time Debugging:''' Setting code breakpoints and trace through the code in real time. Generally, this is not a preferred way in robotics because if you trace through code that turns on a motor, the motor will remain on for the duration while you are tracing the code until the code turns the motor off. If the motor is controlling an arm or elevator, it would have gone beyond its position limit. This way is only desirable if the code doesn't involve anything that's time sensitive.
	* '''Trace Logging:''' Do a postmortem analysis of the trace log.		* '''Trace Logging:''' Do a postmortem analysis of the trace log. This involves adding trace logging code in appropriate places to log the values or states of the component you are debugging.

	=== Real Time Debugging ===		=== Real Time Debugging ===