A Simulator to Test In

Programming for Robotics 1 section 7 built a seam between the robot logic and the world, three methods (range_m, ticks, set_duty), and tested the logic against fakes that were one line of world each: a scripted list of ranges, a wall in one dimension. Programming for Robotics 2 made the other side of the seam real with PicoHardware. This chapter builds the third thing that plugs into the same seam, and the one the rest of the course leans on: a simulator, a small two-dimensional world with a differential-drive robot that really drives around in it, whose wheels turn, whose range sensor sees walls and posts, whose encoders count whole ticks and whose readings have noise. It is written in this chapter, in about 330 lines of standard-library Python, in stages that you can run one after another, and it ends as one file, sim.py (the reference listing of section 14). From here on, “the simulator from Programming for Robotics 3” means that file, and later chapters import it instead of rebuilding it.

1. Why simulate, and what a simulator cannot tell you

A simulator is a program that pretends to be the world and the robot’s hardware. The robot code does not know the difference, because the contract between them is the three methods of Programming for Robotics 1 section 7. What it buys:

The last row is the catch, and it has a name, the reality gap: the difference between how the simulated robot behaves and how the real one does. Every model leaves things out (section 13 lists the ones this simulator leaves out), and code can be tuned to the simulator’s quirks until it works only there. The right use is therefore specific: a simulator is for finding logic bugs, running regression tests, comparing designs and choosing first values of parameters, quickly and safely. It is not for proving that a robot works. A passing simulation is evidence, and the final test is always the robot.

Seeds: repeatable, and still random

Real sensors are noisy, so the simulated ones must be too, or the code is never tested against noise. Python’s random.Random(seed) makes a stream of numbers that looks random but is the same every time for the same seed. That gives both properties: a seed is a replay button (a failing run can be reproduced exactly, then debugged), and a different seed is a different draw of the noise (so a test can be repeated over 100 seeds to see the spread, not just one lucky run). Three rules keep it that way, and the code follows all of them:

• No global random state. Not random.random() or random.seed(1) at the top of a file. Every random thing owns a random.Random object, so adding one more sensor does not change the numbers another one draws (given the same seed, only the order in which sensors are created matters).
• No wall clock. Time in the simulator is a number the simulator advances itself, in whole microseconds (section 7), never time.monotonic(). A run then does not depend on how fast the PC is, or on what else it is doing.
• Draw the same numbers whatever happens. A sensor draws its noise every time it measures, even when it then reports “no echo”, so a change of geometry does not shift the random stream of later readings.

2. The design: six small pieces and one contract

The simulator is a stack of small classes, each with one job and a clear input and output, as in Programming for Robotics 1 section 6. The robot code sees only the top box.

The pieces and the order they are built in:

Conventions (so that every later chapter agrees): the arena is in metres, with x to the east (right) and y to the north (up). A pose is (x, y, θ) with θ in radians, counter-clockwise from the x axis, as in Robotics Fundamentals 4 section 5. In the robot’s own frame, forward is the direction it faces and left is 90 degrees counter-clockwise from it; a sensor is mounted at (forward, left, angle) in that frame. Times are seconds (floats) or whole microseconds inside the clock, and the unit is in the name (_m, _s, _rad, _mps), as in Programming for Robotics 1 section 8.

Who moves first. A simulated loop must say, once, in what order the world and the robot act, because the order sets the delay between a command and its effect. The simulator uses the order of the simulate function of Programming for Robotics 1 section 7: the world moves under the last command, then the robot senses, decides and acts.

3. Geometry first: rays, segments and circles

Everything a range sensor does comes down to one question: if I shoot a ray from a point in a direction, how far is it to the first thing it hits? The things are of two kinds: segments (walls, and the sides of boxes) and circles (posts). The ray is the set of points o + t d with t ≥ 0, where o is the origin and d a unit vector (length 1), so that t is a distance in metres.

A ray and a segment

The segment runs from p to p + e, the points p + u e with 0 ≤ u ≤ 1. The ray meets the line of the segment where the two expressions are equal. Write the 2D cross product a × b = a_x b_y − a_y b_x, and q = p − o for the vector from the ray’s origin to the segment’s start:

A ray and a circle

A point of the ray lies on the circle (centre c, radius r) when its distance from the centre is r. Put f = o − c, the vector from the centre to the ray’s origin. Because d has length 1, squaring the distance gives a quadratic in t:

One more helper is needed for collisions: the point of a segment nearest to a given point. Project the point onto the segment’s line, u = (a − p) · e / (e · e), and clamp u to the range 0 to 1 so that the answer cannot leave the segment. The block below holds all four functions and the header of sim.py.

The numbers of the worked examples, and the cases that must return nothing:

The first two lines are the hand calculations above. The other four are the cases that go wrong in real code: a post the ray passes by, a segment parallel to the ray, a segment behind the ray’s origin, and a segment that is too short to reach (the line through it is hit, the segment is not, because u is greater than 1).

4. The world: an arena, obstacles and contact

A World is a list of segments, a list of circles, and a list of painted lines. The four walls of the arena are four segments; a rectangular obstacle is four more; a post is a circle. raycast tests a ray against all of them and returns the nearest hit within the sensor’s maximum range. Every ray-shape test increments a counter, ray_tests, which section 12 uses to count the cost.

For collisions the robot’s body is a disc of radius R (the body_radius_m of the robot, 9 cm here). A disc overlaps a segment when its centre is nearer than R to the segment’s nearest point, and overlaps a circle of radius r when the centres are nearer than R + r. contact returns the deepest overlap as (n_x, n_y, depth): the normal, a unit vector pointing from the obstacle towards the robot, and how far the disc has sunk in. The normal tells the bumper where the contact is (section 6).

An arena with a box and a post, a few rays, and a few contact tests (a body radius of 0.09 m):

The corner of the box is the instructive case: the nearest point of the box’s walls is the corner itself, so the normal points diagonally away from it, (−0.71, −0.71), the direction from the corner to the robot’s centre, and the overlap is the body radius minus the distance to the corner. The last ray test gives “no echo” because the maximum range (1 m) is shorter than the distance to the east wall (2.7 m): a real sensor times out the same way, and the robot code of Programming for Robotics 1 section 11 turns that into None.

5. The robot model: pose, wheels and a lazy motor

The model has to answer one question each physics step: given what the motors were told, where is the robot now, and how far has each wheel turned? Two things are needed, the way the wheels respond to a command, and the way two wheel motions move a body.

The unicycle model, exactly

Over one step the two wheels roll distances Δd_L and Δd_R along the ground. The centre of the robot travels the average and the heading changes by the difference over the track width L (Robotics Fundamentals 4 section 3). If the wheel speeds are constant over the step, the robot moves along an arc, a piece of a circle about the instantaneous centre of curvature (ICC), and the exact new pose follows by rotating the old position about the ICC:

The motor: a first-order lag

A command to a real motor is not obeyed instantly: the wheel speeds up over a fraction of a second. The simplest model that captures this is a first-order lag: the wheel speed ω moves towards the commanded speed ω_c at a rate proportional to the gap, with a time constant τ. The model integrates the angle exactly, in closed form, so the result does not depend on how long the step is:

The model also carries a scale for each wheel, scale_left and scale_right: the ground distance the wheel really rolls per radian it turns, relative to what the software believes. A value of 1.01 on the right wheel is a tyre that is 1 % too big (Robotics Fundamentals 4 section 6, worked example 1); 0.98 is a wheel that loses 2 % of its distance to slip. The encoders count the wheel’s angle, which does not know about the scale, which is exactly why odometry drifts. The robot’s commands are speeds in m/s, converted to wheel angular speeds with the nominal radius, like the software does it on a real robot.

First the motor lag, against its formula. The model is given full speed from standstill and stepped for 0.5 s in passes of 0.02 s:

The simulated speed and the formula agree to every digit shown, because the model uses the closed form. One time constant gives 63.2 %, and 2.5 time constants (0.20 s) give 91.8 %. The lag costs 3.2 cm at full speed: after 0.5 s the robot has gone 0.1681 m instead of the ideal 0.2000 m.

Now the three pose integrators, on a robot with no lag so that the wheel speeds are exactly constant and the answer is known. The wheels run at 0.20 and 0.30 m/s for 2.4 s, a turn of 1.6 rad along an arc of radius 0.375 m, and the exact answer comes from one advance_pose call over the whole motion. Then the same motion is integrated in 4, 8, 24 and 120 steps:

The error of euler falls in proportion to the step (17.9 mm at 0.1 s, 3.6 mm at 0.02 s), and it matches the formula above: the chord is 2 × 0.375 × sin(0.8) = 0.538 m, and with 4 steps each turning 0.4 rad the error is 0.538 × 0.4 / 2 = 0.1076 m, close to the 107.8 mm shown. Even at 120 steps it is still 3.6 mm, in a 1.2 m run. Midpoint falls with the square of the step (3.60 mm, then 0.90 mm when the step is halved), as the chord factor says. The arc update is exact for any step, because constant wheel speeds are an arc. That is why sim.py uses it by default, and why the Euler option is there: to show you what the cheap formula costs. (With the motor lag the wheel speeds are not constant, but both wheels follow the same lag curve from rest, so a run that starts from standstill with constant commands is still a perfect arc. With changing commands the arc update has a small second-order error too, which the physics step of section 7 keeps tiny.)

6. Simulated sensors

A sensor is a model of what comes out of the part, not of the physics inside it. The same recipe fits every one: take the true value, turn it into what the part would report (limits, noise, whole counts, delay), and give back None where the part would fail to answer.

The range sensor

An ultrasonic or infrared sensor (Robotics Fundamentals 5 section 3), as a ray from a mount point on the robot (forward, left, angle): the true range is the ray cast, then Gaussian noise of standard deviation σ, then the limits: nothing within the maximum range is a timeout (None), and anything under the minimum range is the blind zone (also None). Three options make it realistic:

• A cone (fov_rad, n_rays). A real ultrasonic beam is wide (about 15 degrees each side, Robotics Fundamentals 5 section 3), and it reports the nearest thing in it. The model casts n_rays rays across the cone and takes the shortest. Section 12 shows what too few rays do.
• A rate (period_s). The sensor measures every period_s and holds the last value in between, like a ping every 25 ms.
• A delay (latency_s). A reading is delivered latency_s after it was measured, through a queue. This is the option for the latency chain of Programming for Robotics 1 section 12; section 13 shows what it does to a controller.

The noise assumption deserves a caution. Gaussian noise is a good first model of the small random jitter of a reading, and it is the kind that averaging removes (the standard error σ/√N, Robotics Fundamentals 5 section 9). It is a poor model of the outliers of a real ultrasonic sensor: an echo from the wrong wall, a missed pulse. The simulator’s noise is therefore the easy case, and a filter that only passes the simulator’s noise has not been tested against the hard one.

The encoders

An encoder counts whole ticks of the wheel’s angle: ticks = floor(angle / 2π × N) with N = 600 ticks per wheel revolution. The error of the count is the fraction of a tick that was cut off. If the wheel is at a random position, that fraction is uniformly spread over 0 to 1, so the error e = ticks − exact has mean −1/2 and variance 1/12 (the variance of a uniform distribution of width 1), a standard deviation of 1/√12 = 0.2887 tick. At 0.34034 mm per tick (Robotics Fundamentals 4 section 5) that is 0.098 mm: tiny for a distance. It matters in a speed computed from the difference of two counts over one short pass (section 8), and Robotics Fundamentals 6 section 2 treats it as the quantisation error of speed. The class also takes an optional counting scale and bias (a lost count, a wrong zero), which the drift experiments of section 11 can use.

The line sensor and the bump sensor

The line sensor (Robotics Fundamentals 5 section 4) is a row of n points across the front of the robot; each reads 1 if its point is over paint, which is a line of given width, the distance of the point from the polyline being at most half the width. Index 0 is the leftmost sensor. The bump sensor (Robotics Fundamentals 5 section 5) is a bumper over an arc of the body: pressed when the contact point lies inside the arc. The contact point is on the side of the robot opposite to the contact normal, so its bearing relative to the heading is the angle of (−n_x, −n_y) minus θ. The default arc is the front half (180 degrees).

First the range sensor against the statistics. A robot 1 m up in a 3 m by 2 m arena faces the east wall; 1000 readings at 50 Hz, a sigma of 5 mm, then the two limits, then the encoder error over 100 000 random wheel positions:

The mean is within 0.14 mm of the truth, inside the 0.16 mm that the standard error predicts, the spread is the 5 mm that was asked for, and 95.1 % of the readings fall inside two sigma (a Gaussian puts 95.4 % there). The encoder error has the mean −0.500 tick and the spread 0.2888 tick of the uniform-fraction argument, the 1/√12 = 0.2887 tick above. In other words the simulator behaves as the algebra said it would; that is the check that the code is right.

The line sensor and the bump sensor next. The robot crosses a painted line at several offsets, and a wall touches the bumper from several bearings:

The line sensor sees the paint through the one sensor that is over it, and the 1 moves left or right as the robot moves off the line, and sees nothing beyond about 4 cm. The bumper is pressed for contacts up to 80 degrees from the heading either side, and silent for 100 and 180 degrees: it covers the front half only. Programming for Robotics 4 turns these raw readings into a position estimate.

7. The clock and the Simulator: one object with the robot’s three methods

SimClock is the simulator’s own time. It keeps the time in whole microseconds (an integer) and exposes now_s() like time.monotonic(), in the way FakeClock of Programming for Robotics 1 section 4 did, so adding up 50 passes of 0.02 s gives exactly 1.000000 s, not 0.9999999999999999. Simulator ties everything together:

• The interface. range_m(), ticks() and set_duty(left, right) are the three methods of Programming for Robotics 1 section 7, with the same meaning (a distance in metres or None; two whole counts; duty cycles from −1 to +1, where 1.0 is the maximum wheel speed). line() is the method PicoHardware of Programming for Robotics 2 section 10 also has. The extras, bump(), range_of(name), now_s() and advance(dt_s), are for the world and the tests.
• advance(dt_s) moves the world. It is the advance that the fakes of Programming for Robotics 1 had, so the simulate function of that chapter works on a Simulator unchanged. The control pass is 0.02 s but the physics runs in smaller steps (physics_dt_s, 5 ms by default, so 4 physics steps per pass), because a coarse step is less accurate and can step through a thin wall (section 12). After the physics, every sensor takes one new reading.
• Collision. After each physics step the body is tested against the world. If it overlaps something, the step is undone (pose and wheel angles restored), the wheels are stopped, and the contact is recorded. The robot stops where it touches, within one physics step of travel (2 mm at 0.4 m/s, 5 ms), and because the wheel angles are restored, the encoders stop counting, as the wheels of a robot pushing against a wall stall. The motors are still being commanded, so a robot that keeps pushing keeps registering the contact on every pass.
• Seeds. Simulator(seed=...) creates one random.Random(seed) and gives every sensor its own stream from it.

The first thing to try is the simplest: the robot code is not involved at all. Command duty 0.5 on both wheels for 2 s with set_duty and compare the distance to the formula of section 5:

The robot moved 0.3840 m, not the 0.4000 m of 0.20 m/s times 2 s: the lag costs 0.20 × 0.08 = 1.6 cm. The two wheels counted 1128 ticks (the formula says 1128.3, rounded down to a whole tick), and the sensor-side calls, range_m(), line() and bump(), answer like those of a hardware class, which is what the last line confirms: the three-method interface is a subset of the WallWorld of Programming for Robotics 1, so everything written against a fake runs here.

8. Scenarios: driving straight, a wall, a collision

A scenario is a simulator, a robot, and a loop. The first is the one that matters: the Robot of Programming for Robotics 1 section 6, unchanged, driving at a wall. The wall is 3.0 m from the arena’s west wall, the robot starts at x = 0.3 m with its range sensor 0.07 m ahead of its centre, and the rule is the Programming for Robotics 1 one: cruise at 0.30 m/s, slow down from 0.60 m and stop at 0.25 m. The loop is two lines, in the order of section 2:

This is the result the whole chapter has been working towards: the code of Programming for Robotics 1 section 6 ran on a world with a lagging motor, noisy readings and whole-tick encoders, and stopped at the stop line. The true range is 0.250 m (the 0.250 m stop line), the body is 23 cm from the wall and nothing was bumped. Two details are worth a look. The speed from the encoders is 0.289 m/s in the lines above, and the last line shows that it is not constant: it takes only the values 0.289 and 0.306 m/s while the command is 0.300: at that speed the robot moves 17.6 ticks per pass, the count is a whole number (17 or 18), and one tick per pass is 0.00034034 / 0.02 = 0.017 m/s. That is the quantisation of section 6, now visible; Programming for Robotics 4 filters it. And the approach is slow at the end: the proportional rule shrinks the speed as the range shrinks, so the last few centimetres take seconds (the gap closes with a time constant of 1 / 0.857 = 1.2 s).

The second scenario is the one the simulator exists to make safe: a collision. The robot starts 1.0 m from the wall and is told to drive at full speed, with no stopping rule at all:

The first bump comes at 2.36 s with the body 1.9 mm from the wall (one physics step away, as the model promised), and the wheel speed drops to nearly nothing as the step is undone and the wheels are stopped. Pushing for six more seconds moves the robot a further 1.9 mm as it creeps to a stop at the wall, and bump() stays true on every pass after the first. The encoders count 2673 ticks, 0.9097 m of wheel travel, which matches the 0.9100 m the robot really moved: they stopped when the wheels did, and a stalled real robot would behave the same (a real one would also draw a lot of current, which Robotics Fundamentals 10 section 7 turns into a stall check). Reversing clears the contact: bump() is false and contact is None.

9. Recording a run and drawing it

A run that scrolls past on the screen cannot be checked, compared or plotted. Recorder keeps one row per control pass, the same way Programming for Robotics 1 section 10 logged a robot: the time, the true pose, the true wheel speeds, what the robot actually read (the noisy range, the tick counts), and the bump flag. Putting the truth and the reading in one row is the main thing a simulated log has that a real one cannot. to_csv writes it as text, with fixed digits, so two logs from two runs can be compared character by character. run is the loop of section 8 as a function, and ascii_map draws the arena from above as a grid of characters. A character is about twice as tall as it is wide, so each cell is twice as tall as wide in metres; # is an obstacle or wall, * the path, S the start and E the end, with y pointing up.

A path is more interesting than a straight line, so the next demonstration drives a route open loop, from a script of (left duty, right duty, seconds) steps, around a post and past a box: east, a left quarter-circle of radius 0.3 m, north, a second left quarter-circle of 0.25 m, then west. The duties come from the arc formulas of Robotics Fundamentals 4 section 3 (for R = 0.3 m the inner wheel runs at (R − L/2) / (R + L/2) = 0.6 of the outer one). The recorder takes a row on every pass:

The picture shows a start, a route that clears the post and the box with room to spare, and an end pose with the heading 179.9 degrees, nearly due west, as scripted. The top rows of the CSV show what a log row looks like: the first rows show the lag at work (the true wheel speed climbs 0.053, 0.094, 0.127 m/s towards the 0.24 m/s commanded) and the tick counts 1, 6, 12. If you have matplotlib installed, plotting the CSV is three lines (plt.plot(x_column, y_column) and plt.show(), from memory and not run here); it is optional, and the text map is what makes every run in this chapter checkable in a file and in a test.

10. Replay and assertions: tests that use the simulator

A test is a simulated run followed by assertions about the log or the final state. Two kinds are worth writing for every behaviour: does it do the right thing (the robot stops before the wall, never goes faster than the cruise speed) and is the run itself reproducible (the same seed gives the same log, a different seed gives different noise). The second is a test of the simulator, and it catches the commonest simulator bug there is: a hidden source of randomness or of wall-clock time that makes runs differ.

All three pass. The first checks the behaviour (the body is 23 cm from the wall, there was no bump, and no wheel went faster than the cruise speed plus a tolerance). The second runs the whole 14 s scenario twice with the same seed and compares the two CSV texts for equality: 701 identical lines, byte for byte. The third changes the seed and finds that 700 of the 701 lines differ (the header is the one that does not), which proves the noise really depends on the seed. This is the replay: given a seed, any run that ever failed can be run again and again while the code is fixed.

11. Measuring odometry drift in the simulator

Robotics Fundamentals 4 section 6 worked out by hand what odometry error does to a robot: a right tyre 1 % too big, and a track width 3 % out. Here is the same experiment on the simulator, where the truth is available to compare with. OdometryTracker is a short dead-reckoning class: it turns the encoder counts into distances with the nominal wheel radius and track width (what the software believes) and applies the exact arc update of section 5. It is an instrument for this chapter; Programming for Robotics 5 builds the real odometry, with calibration.

The robot drives “straight” (the same duty on both wheels) until its odometry says 3.0 m, and then coasts to a stop. Its right wheel is really 1 % bigger (scale_right = 1.01), a fact that only the simulated world knows. Next to the simulator’s truth is the formula of Robotics Fundamentals 4 section 6, applied to the distance the left wheel really rolled. The block ends with the second experiment, the track width of 0.155 m against the 0.150 m believed, in a spin of “360 degrees”:

Odometry thinks it drove dead straight: y = 0 and heading 0, as it must, because the two tick counts are equal. The truth is 30.5 cm to the side and 11.5 degrees round. The formula, which is a few lines of algebra with no simulation in it, agrees with the simulator to 0.17 mm in x and 0.03 mm in y. That agreement is the check on both: the formula describes the robot, and the simulator implements the model the formula describes. The numbers differ from Robotics Fundamentals 4 section 6 (2.995 m, 0.300 m, 11.46 degrees) only because the run is longer: the motors coast 1.6 cm after the stop command, so the odometry distance is 3.0198 m, not 3.000 m, and the sideways drift grows with the square of the distance, 0.3005 × (3.0198 / 3.000)² = 0.3045 m. The spin is the second worked example: the robot believes it turned 360.0 degrees and actually turned 348.4 degrees, the number of the book, and the ratio of the two angles, 0.9678, is the ratio of the track widths, 0.150 / 0.155 = 0.9677, which is also how the calibration of Robotics Fundamentals 4 section 6 recovers the true track width.

12. Fidelity against cost: the step and the rays

A simulator is always a bargain between accuracy and the time it takes. There are two dials, and both are easy to get wrong in a way that gives no error message:

• The physics step. Too coarse and the pose integration is inaccurate (section 5) and the robot can move through a thin wall in a single step: at 0.4 m/s a 20 ms step moves 8 mm, so a wall thinner than that, or a collision test that only looks at the end of each step, could miss a hit. Too fine and a long run is slow. The rule of thumb: the distance moved in one physics step should be much smaller than the smallest obstacle and than the tolerances you care about (0.4 m/s × 5 ms = 2 mm here), and the motion model should not be sensitive to the step (the arc update is not).
• The number of rays. Each ray costs one test per wall segment and circle, every sensor update. More rays find thinner things, at a linear cost.

The control period is not a dial. It is whatever the real robot’s loop period is (0.02 s here, 50 Hz), because the robot code, with its filters and its gains, is written for that dt. Only the physics step is the simulator’s own.

First the step: a lagged curve for 6 s, integrated with euler and with the arc update at several steps, against a reference of the arc update with a step of 0.2 ms. Then the rays: a post of radius 2.5 cm (a 5 cm pole) 2.03 m from the sensor, moved across a 30 degree cone, and what share of positions each ray count finds. The cost is counted, not timed (a count does not change from one PC to the next), as ray tests per second at the 50 Hz pass rate:

The step table says euler needs a step of about a millisecond to get under 0.2 mm, which is 6000 steps for a 6 s run, where the arc update is exact at 60 steps. It is cheaper to be exact than to be fine. (The arc column is exactly zero here for the reason given in section 5: a start from rest with constant commands is an exact arc. A run of changing commands would show a small error, much smaller than the euler column.) The ray table is the more surprising one. A pole 5 cm wide seen from 2 m is only 1.41 degrees across, so rays further apart than that can slide past it. With 5 rays (7.5 degrees apart) the sensor finds the pole in 18.9 % of its positions, 9 rays find 37.3 %, 21 rays find 92.6 %, and 23 rays or more find every position. That is a discovery by arithmetic before the experiment: the rays must be no further apart than the angular size of the smallest object that matters, 2 atan(r / d) = 1.41 degrees, so the 30 degree cone needs at least 30 / 1.41 + 1 = 22.3, in practice 23 rays. A 1 ray sensor has the pole in view only 5.1 % of the time, and a real ultrasonic sensor with its wide beam finds the pole everywhere: a one-ray model of it would be badly pessimistic. The cost is 5750 ray tests a second for 23 rays on this small arena, trivial for a PC and the reason not to put 23 rays on every sensor of a big map.

13. The reality gap

Everything above is a model, and the robot is not. The honest way to use a simulator is to write down what it leaves out and decide which omissions can break the program being tested. These are the ones sim.py leaves out, what each does to a real robot, and what it would take to add it:

Of these, the one the simulator can show quickly is latency, because the sensor option exists. The experiment is the Programming for Robotics 1 controller against a delayed range sensor, run twice: the original controller, which slows down gently (gain 0.30 / 0.35 = 0.86 per second), and a sharper one that slows down between 0.30 and 0.25 m (gain 0.30 / 0.05 = 6 per second). Each table entry is the closest the robot ever got to the wall, from a 14 s run at each delay:

The gentle controller shrugs off a delay of 0.3 s and starts to overshoot the stop line at 0.5 s (0.229 m); it still does not hit anything at 0.8 s, though it gets to 0.150 m. The sharp controller loses its margin at once: even with no sensor delay it overshoots a little (0.237 m, because of the motor lag and the range filter), and at 0.8 s it hits the wall. A standard result for delayed feedback (from memory, and shown here only by this table) explains the pattern: for a rule of the form “the speed is proportional to how far the reading is above the stop line”, with gain k per second and a delay T, the approach is smooth when kT is under 1/e = 0.37, overshoots when it is over, and becomes unstable at kT over π/2 = 1.57. For the gentle controller that puts the overshoot at a delay of about 0.43 s, and for the sharp one at about 0.06 s (both a little earlier here, since the motor lag adds to the delay): what the table shows. The lesson is the reason for having a simulator at all: this robot, a controller with a high gain, and a slow sensor is a crash that costs nothing to find in the simulator and a broken robot to find on the floor.

14. The reference listing: sim.py

The blocks of sections 3 to 7, 9 and 11, in order, are the complete module. This is the one file later chapters mean by “the simulator from Programming for Robotics 3”; save it as sim.py. It needs only the standard library. (A copy that is the same as this listing was run against every demonstration of this chapter before the chapter was finished.)

Using it takes four lines, and the robot code does not change:

15. Challenges

Work these with Python and the simulator. The solutions are text files with the working, and the code in them was run, so the output shown is what it printed.

Next: Programming for Robotics 4, Sensor Code and Filtering

This chapter built the world the rest of the course runs in. The Programming for Robotics 1 robot ran in it unchanged and stopped at the stop line, and the simulator showed what the real world will show too: readings that jitter (5 mm of range noise, a speed that flickers by one tick per pass), a sensor that is late, and a controller that is fine with a gentle gain and dangerous with a sharp one. Programming for Robotics 4 (planned; not yet written) is the answer to the readings. It writes the sensor code properly, for ultrasonic, infrared and line sensors and for encoder counts, and the filters that turn raw readings into usable ones (debouncing, the median for outliers, the moving average and the exponential filter, with their delays measured), calibration code, and the quadrature decoder; and it tests every filter on the simulator of this chapter with the noise turned up and with outliers added, which is where the simulator’s easy Gaussian noise stops being enough.