The most important ideas are sequence, variables, loops, conditionals, sensors, actuators, and debugging. A robot usually follows the pattern read sensors, process information, choose an action, then control motors or other outputs. Programs often use formulas such as distance = speed x time and error = target value - measured value to control movement.
Good robot code is organized, tested in small steps, and designed to handle unexpected sensor readings.
Key Facts
- A sequence runs commands in order, so command 1 finishes before command 2 begins.
- A variable stores a value that can change, such as speed = 50 or targetDistance = 100 cm.
- A loop repeats commands, such as repeat 4 times: move forward, then turn right.
- A conditional uses logic to choose an action, such as if distance < 20 cm then stop.
- A basic robot control cycle is read sensors, make a decision, run actuators, then repeat.
- The distance formula for constant speed is distance = speed x time.
- A simple correction formula is error = target value - measured value.
- Debugging means finding and fixing problems by testing one part of the robot program at a time.
Vocabulary
- Pseudocode
- Pseudocode is a plain-language plan for a program that describes the steps before writing real code.
- Sensor
- A sensor is an input device that measures something in the environment, such as distance, light, touch, color, or rotation.
- Actuator
- An actuator is an output device that makes the robot do something physical, such as a motor, servo, wheel, or gripper.
- Loop
- A loop is a programming structure that repeats a set of commands while a condition is true or for a set number of times.
- Conditional
- A conditional is a programming structure that runs different commands depending on whether a statement is true or false.
- Debugging
- Debugging is the process of testing a program, finding errors, and changing the code so the robot behaves correctly.
Common Mistakes to Avoid
- Forgetting to update sensor values inside a loop is wrong because the robot keeps using old information instead of reacting to the current environment.
- Using if when a repeated check needs while is wrong because the robot checks the condition only once instead of continuing to respond.
- Setting motor speeds with opposite signs by accident is wrong because the robot may spin instead of driving straight.
- Ignoring units is wrong because mixing seconds, milliseconds, centimeters, or motor rotations can make movements too short, too long, or unsafe.
- Testing the whole program at once is wrong because it makes errors harder to find than testing one sensor, motor, or behavior at a time.
Practice Questions
- 1 A robot drives at 25 cm/s for 4 seconds. Using distance = speed x time, how far does it travel?
- 2 A distance sensor reads 12 cm. Write the action for this rule: if distance < 20 cm then stop, else move forward.
- 3 A robot needs to make a square path. Write pseudocode using a loop that moves forward and turns right 4 times.
- 4 Why should a robot program read sensors repeatedly instead of reading them only once at the start?
Understanding Robot Programming Basics
Robot programs must deal with the real world, where measurements are rarely perfect. A distance sensor can give slightly different values even when the robot is still. Light levels change when a shadow passes over a line follower.
Motors on the left and right side may turn at different speeds because of battery level, friction, or small manufacturing differences. Good code expects this variation. It may take several sensor readings and use an average.
It may ignore values outside a sensible range. A small buffer around a target prevents the robot from switching rapidly between two actions when a reading is near the limit.
Timing is a major part of robot behavior. A command that runs a motor for one second does not guarantee one metre of travel. Wheel slip, carpet, slopes, and battery charge all change the result.
For accurate movement, robots often use encoders. These sensors count wheel rotation. The program can stop after a chosen number of counts rather than after a fixed delay.
This is called feedback because the robot checks what actually happened. Students often first meet feedback when tuning a robot to drive straight, follow a line, or stop near an object.
A useful program separates jobs into small named sections. One section might read a sensor. Another might calculate a steering adjustment.
Another might control the motors. This structure makes faults easier to locate. For example, a robot that turns the wrong way may have reversed motor wiring, a reversed sensor direction, or a sign error in its calculation.
Print values to a screen or computer while the program runs. Record the sensor value, chosen speed, and motor command.
These observations turn guessing into evidence. Change one setting at a time, then repeat the same test under similar conditions.
Robots need safe behavior when something unexpected happens. A sensor can disconnect, return no useful value, or become blocked by dust. A motor can stall when it hits an obstacle.
Programs should set limits on speed, turning force, and how long a movement is allowed to continue. A timeout can stop a robot that fails to reach its goal after a reasonable period. Start testing with low motor power and with the wheels raised when possible.
Watch for code that waits forever, repeated commands that never end, and values that grow beyond sensible limits. Clear comments, meaningful variable names, and careful tests help other people understand the program later.