Page 97 - Toucpad robotics C11

Debugging and Testing: Ensuring Correct and Efficient Program Execution

Imagine building a complex machine like a robot. Even with the best design and programming, it’s almost guaranteed
that things won’t work perfectly the first time. There will be errors – in the code, in the wiring, in the sensor readings, or
in the mechanical assembly. This is where Debugging and Testing come into play. These are systematic processes to
find, analyse, and fix problems (bugs) in the robot’s software and hardware, and then to verify that the robot functions
correctly, efficiently, and safely under various conditions.

Debugging: The Art of Finding and Fixing Bugs
Debugging is the process of identifying, analysing, and removing errors or “bugs” from a computer program or electronic
hardware. A “bug” is simply anything that causes the robot to behave unexpectedly or incorrectly.

Understanding Types of Bugs
Syntax Errors: These are errors in the grammar or rules of the programming language (e.g., a missing semicolon in
u
C, a misspelled keyword). The compiler (the software that translates your code into machine-readable instructions)
usually catches these, preventing the program from even running.
Logic Errors: These are the trickiest bugs. The program runs, but it doesn’t do what you intended it to do. For example,
u
a robot might move forward when it should turn, or it might collide with an object because its obstacle avoidance
logic is flawed.
Runtime Errors: These occur while the program is running, often due to unexpected conditions (e.g., trying to divide
u
by zero, accessing memory that doesn’t belong to the program).
Hardware-Software Interaction Bugs: These are common in robotics, where the code expects a certain signal from
u
a sensor, but the sensor isn’t wired correctly, or the motor doesn’t respond as expected to a command.

Common Debugging Techniques
Print Statements/Serial Monitoring: The simplest technique. Programmers insert special commands into their
u
code to print out the values of variables, sensor readings, or messages about which part of the code is being
executed. This data can be viewed on a computer connected via Universal Asynchronous Receiver-Transmitter
(UART) (serial port).
∑ Example: In a robot struggling with navigation, you might print: “Current X position: 1.5, Y position: 2.3”, “Distance
to obstacle: 15cm”, “Motor speed Left: 100, Right: 90”. This helps identify where the robot’s internal understanding
differs from reality.
Debugging Tools (Debuggers): More sophisticated software tools that allow programmers to:
u
∑ Step Through Code: Execute the program one line at a time to observe exactly what’s happening.
∑ Set Breakpoints: Pause the program’s execution at specific lines of code to inspect the state of variables.
∑ Inspect Variables: View the values of all variables in real-time as the program runs.

∑ Memory Inspection: Look at the raw data stored in the robot’s memory.
∑ Example: Using a debugger, a programmer can pause a robot’s path planning algorithm at a specific point and
check if the calculated path coordinates are correct before the robot attempts to move.
Hardware Debuggers/Programmers: For microcontrollers, specialized hardware tools (like JTAG or SWD debuggers)
u
connect directly to the chip. They allow for much deeper inspection and control over the microcontroller’s internal state.

u Logging: Saving sensor data, motor commands, and internal states to a file (e.g., on an SD card for Single Board
Computers) for later analysis. This is crucial for autonomous robots operating in the field where real-time monitoring
isn’t always possible.
Visualisation Tools: For complex robots (like self-driving cars), special software allows developers to visualise
u
sensor data (e.g., a 3D point cloud from LIDAR, camera feeds with detected objects), internal maps, and planned
trajectories on a computer screen.

95
Computing System