Python for robots

A robot program is a loop that repeats three steps: read the world, decide, act. Python is good at the middle step, because deciding is mostly about data and logic, which is where the language shines. This lesson covers the parts of Python that show up in nearly every robot, and each idea comes with code you can run right here in the browser, with no hardware.

Functions: name your ideas

A function gives a name to one idea, such as "convert a raw reading to centimetres". Once named, you can test it alone, reuse it, and fix it in one place. Robot code that has grown without functions turns into one long loop where nobody can find the bug.

Prefer small functions that take values in and give values back, with no hidden global variables. A function like that can be tested on your laptop without a robot, which is exactly what the runners in this lesson do.

Data structures that robots actually use

• list: an ordered, changeable sequence, such as the last ten readings.
• tuple: a fixed group like (x, y) or (left_speed, right_speed). Returning two motor speeds as a tuple keeps them together.
• dict: names to values, such as "FORWARD": (0.6, 0.6) mapping a state to wheel speeds. A dict lookup replaces a long chain of if statements.
• deque: from collections, a list with a maximum length. Adding a new item pushes the oldest one out, which is ideal for a sliding window of recent readings.

Filtering noisy sensors

Real sensors are noisy. An ultrasonic sensor might read 50.2, 49.1, 51.4 cm while the wall is perfectly still. If your robot reacts to every wobble, it will twitch. A moving average reduces noise by averaging the last N readings. With noise of standard deviation s, averaging N independent readings reduces it to about s / sqrt(N), so 4 readings halve the noise.

The price is lag: the filtered value trails behind real changes by roughly N/2 samples. Pick N as small as the noise allows.

moving_average.py

ResetRun

from collections import deque class MovingAverage: def __init__(self, size): self.window = deque(maxlen=size) def update(self, value): self.window.append(value) return sum(self.window) / len(self.window) f = MovingAverage(4) raw_readings = [20.0, 21.0, 20.5, 35.0, 20.8, 21.2, 20.9] for raw in raw_readings: print("raw %5.1f filtered %5.2f" % (raw, f.update(raw)))

Change the 35.0 spike to something else and watch how far it drags the average. A single bad reading still pulls the output up for 4 samples. That is a weakness of averaging, and you will see a better tool for it shortly.

A simple state machine

Robots do different things at different times: drive, turn, stop. A state machine makes this explicit. You keep one variable that holds the current state, and a function that decides the next state from the current one plus the sensor input.

The key design trick is hysteresis: use different thresholds to enter and leave a state. Below, the robot turns when something is closer than 20 cm but only drives again once the way is clear beyond 35 cm. Without that gap, a reading hovering around 20 cm would flip the state back and forth every cycle.

state_machine.py

ResetRun

def next_state(state, distance_cm): if state == "FORWARD" and distance_cm < 20: return "TURN" if state == "TURN" and distance_cm > 35: return "FORWARD" return state readings = [80, 60, 40, 25, 18, 22, 28, 30, 36, 50, 70] state = "FORWARD" for d in readings: new_state = next_state(state, d) note = " (changed)" if new_state != state else "" print("%3d cm %-8s%s" % (d, new_state, note)) state = new_state

Notice that readings of 22, 28 and 30 do not cause a switch back to FORWARD. That is hysteresis doing its job.

Units: the quiet source of bugs

Many robot bugs are unit bugs: centimetres treated as metres, degrees fed to a function that wants radians. The fix is to convert at the edge of your program and keep the rest in one consistent unit.

An ultrasonic sensor measures the echo time, and the sound travels to the wall and back, so the distance is half of speed times time. The speed of sound also depends on temperature: v = 331.3 + 0.606 x T metres per second, with T in degrees Celsius.

units.py

ResetRun

def speed_of_sound(temp_c): return 331.3 + 0.606 * temp_c # metres per second def echo_to_cm(echo_seconds, temp_c=20.0): return speed_of_sound(temp_c) * echo_seconds / 2 * 100 def cm_to_inches(cm): return cm / 2.54 for echo_ms in (1.0, 2.9, 5.8, 11.6): cm = echo_to_cm(echo_ms / 1000) print("echo %5.1f ms = %6.1f cm = %5.1f in" % (echo_ms, cm, cm_to_inches(cm))) print("sound at 0 C: %.1f m/s, at 30 C: %.1f m/s" % (speed_of_sound(0), speed_of_sound(30)))

Between 0 and 30 degrees the speed changes by more than 5 percent, which is close to 3 cm of error at 50 cm. Whether that matters depends on your robot.

Simulating a sensor

You can develop most of your logic without the sensor. Write a fake one that behaves like the real thing: Gaussian noise around a true value, plus the occasional bad reading. Then test your filter against it.

A median filter handles bad readings better than an average. It sorts the window and takes the middle value, so one wild value is simply ignored.

simulated_sensor.py

ResetRun

import random random.seed(7) TRUE_CM = 50.0 def read_distance(glitch=False): if glitch: return 400.0 # dropout: sensor reports max range return random.gauss(TRUE_CM, 2.0) # normal noise, sigma = 2 cm def median(values): s = sorted(values) return s[len(s) // 2] window = [] for i in range(12): raw = read_distance(glitch=(i in (4, 9))) window.append(raw) window = window[-5:] mean = sum(window) / len(window) print("%2d raw %6.1f mean %6.1f median %6.1f" % (i, raw, mean, median(window)))

On the glitch samples the mean jumps to around 120 cm while the median stays near 50. If your robot used the mean, it would think the path was clear and drive into the wall.

The real loop, with timing

On the robot, the same functions plug into a loop that reads, decides and acts at a steady rate. A naive time.sleep(0.05) at the end of each cycle drifts, because it adds 50 ms on top of however long the work took. A fixed schedule using time.monotonic() stays on time:

import time
from gpiozero import DistanceSensor

sensor = DistanceSensor(echo=24, trigger=23)   # echo needs a voltage divider
PERIOD = 0.05                                  # 20 Hz control loop
next_tick = time.monotonic()

try:
    while True:
        distance_cm = sensor.distance * 100    # gpiozero reports metres
        # filter, choose state, set motors here
        next_tick += PERIOD
        time.sleep(max(0, next_tick - time.monotonic()))
finally:
    pass   # stop the motors here, even if the program crashes

The try and finally block matters: if your code crashes mid-run, finally still executes, so you get a chance to stop the motors instead of leaving them spinning.