Rusty, Sensors, and the Simulator

Building the laboratory the rest of this book lives in — differential-drive kinematics, wheel odometry from encoder ticks, ray-cast LiDAR, and a seeded simulator whose every run is reproducible to the last bit.

The problem with knowing how far you have gone

Rusty's wheels are its only sense of motion. Each encoder counts the fraction of a revolution its wheel has turned; multiply by the wheel radius and you get how far that wheel rolled. Integrate both, and you have a pose. This is dead reckoning, and it is the oldest navigation algorithm there is.

It also has a defect that no amount of engineering removes. An encoder measures the wheel. It does not measure the floor. Every time a wheel slips a millimetre, skids on a threshold, or turns out to be 0.3 mm larger than the CAD model says, the number the encoder reports and the distance the robot travelled part company — and because dead reckoning integrates, that disagreement is never corrected, only accumulated.

Watch it for thirty seconds before reading on. Three things are worth noticing.

The error grows and never shrinks. There is no mechanism in dead reckoning that could shrink it. A measurement of the outside world can pull an estimate back toward the truth; a measurement of your own wheels cannot, because it carries no information about where you started.

Turns are more expensive than straights. A heading error is nearly free while you stand still and catastrophic once you drive under it: three degrees of heading error becomes half a metre of position error after ten metres of driving. This is why the "drift / distance" readout jumps at each end of the corridor.

With slip set to zero, the two traces coincide exactly. That is worth sitting with. It means the drift you just watched is not a property of dead reckoning as an idea — the arithmetic is exact — but of the physics the arithmetic is being fed. Which raises the obvious question: why can no real robot set that slider to zero? Two reasons, and they behave completely differently. Drag the second slider and watch what a one-percent error in one wheel radius does.

What Rusty is made of

Before the mathematics, the hardware — because every noise model in this book is a claim about a physical device, and it helps to know which one.

Sensors split along two axes that matter more than any device catalog. A proprioceptive sensor measures the robot's own internal state; an exteroceptive one measures the world outside it. An active sensor emits energy and listens for it; a passive one only receives.

The taxonomy earns its keep immediately. Proprioceptive sensors give you increments whose errors accumulate; exteroceptive sensors give you absolute constraints whose errors do not. That single distinction is why the Bayes filter of Chapter 5 has exactly two steps, and why one of them makes the belief worse.

Notation for this chapter

The mathematics

From two wheels to one twist

Rusty is a rigid body in the plane, so its velocity is fully described by a body twist $u = (v, \omega)\T$: forward speed and yaw rate. It has two actuators. Two numbers in, two numbers out, and the map between them is linear.

Integration: the exact arc is the exponential map

Hold $(v, \omega)$ constant for $\Delta t$. What is the new pose?

The textbook answer is to integrate $\dot{x} = v\cos\theta$, $\dot{y} = v\sin\theta$, $\dot\theta = \omega$ numerically — Euler, or Runge–Kutta if you are feeling careful. This is a mistake, and an instructive one: the problem has a closed-form solution that is shorter than the approximation, and Chapter 3 already handed it to us.

No small-angle approximation, no integration error, no step-size parameter. The middle zero is the nonholonomic constraint, expressed in the Lie algebra $\mathfrak{se}(2)$.

Odometry: from integer counts to a pose increment

Now the sensing side. An encoder does not report an angle; it reports an integer. Over one interval each wheel accumulates $\Delta\text{ticks}_i$ counts, and each count corresponds to $\lambda = 2\pi r/N$ metres of wheel travel.

and the dead-reckoned pose advances by

That is the same $\bplus$, with the same $\exp$, as the ground-truth integrator. This is the key structural fact of the chapter: dead reckoning and the simulator's physics run identical arithmetic. If the encoders saw exactly what the floor did, the orange trace would sit on the gray one forever. Everything you watched drift apart in the widget above came from the gap between the wheel and the floor — never from the mathematics.

A worked example you can check by hand

Rusty's track is $\ell = 0.16$ m. Over one interval the left wheel rolls $\Delta s_L = 0.72$ m and the right wheel rolls $\Delta s_R = 0.88$ m. Then

an arc of radius $R = \Delta s/\Delta\theta = 0.80$ m through 57.3°. Apply the closed form from Derivation 2:

In polar form the chord is $0.8 \times \operatorname{sinc}(0.5) = 0.767081$ m at a bearing of exactly $0.5$ rad. Now price the two shortcuts:

• Midpoint Euler puts you 0.8 m out at 0.5 rad — right bearing, 0.032919 m too far. The predicted overshoot $\Delta s\,\Delta\theta^2/24 = 0.8/24 = 0.0333$ m matches to three digits.
• Naive Euler puts you 0.8 m out at 0 rad, which is 0.389012 m wrong — half the step length.

One interval. If your control loop resamples odometry at 2 Hz while turning at 1 rad/s, that is the error you are silently adding to every increment.

To make the encoder round trip concrete: $\lambda = 2\pi(0.033)/4096 = 5.0621\times10^{-5}$ m, so $\Delta s_L = 0.72$ m is 14223.24 counts, reported as 14223. Feeding the rounded counts back through odometry_delta gives $\Delta s = 0.79999476$ m and $\Delta\theta = 1.00008836$ rad — off by 5 µm and 88 µrad, which is the quantization bound doing exactly what the budget above says it should.

The LiDAR forward model

Rusty's LiDAR is a spinning planar time-of-flight sensor: $n$ beams over a $2\pi$ field of view, $z_{\max} = 8$ m. For beam $k$ at body-frame bearing $\varphi_k$, the simulator computes the true first-hit distance by ray casting against the map,

and then corrupts it in one of exactly two ways. With probability $p_{\mathrm{drop}}$ the beam returns nothing at all and the sensor reports its ceiling,

and otherwise it reports the true range plus Gaussian noise, clipped to the sensor's range:

Three observations, each of which becomes a chapter later on.

A scan is a vector of numbers, not a shape. The strip beneath the scene is the entire content of a measurement: 180 floats indexed by beam. The wall you perceive in the top panel is something you inferred. Recovering it is what Chapter 16's scan matcher and Chapter 13's mapping do, and neither of them is free.

Corners are discontinuities in range space. Scrub the beam index past 78, and again past 103, and watch the range fall off a cliff — 2.474 m to 1.179 m — as the beam catches the door frame. In between, the beams fly through the doorway and land on the far corridor wall. Those cliffs are the only places a range scan carries information about along-wall position, which is precisely why a robot in a long featureless corridor knows its distance to each wall and almost nothing about how far down it has driven. That anisotropy is why Chapter 11 draws covariance ellipses rather than circles.

A dropout is the sensor's largest number and its smallest amount of information. Turn the dropout rate up. Every dropped beam reports $z_{\max}$, so a naive model that treats 8 m as evidence of an 8 m wall will happily localize the robot onto a pane of glass. Handling this properly is the $z_{\max}$ spike in Chapter 10's four-way mixture.

The algorithms

Line 7 is not a technicality. A blocked robot's wheels keep turning, so its encoders keep counting, so its dead-reckoned pose keeps advancing — straight through the wall. Hold the throttle against a wall in the widget above and watch the orange ghost leave the building.

Line 4 draws both random numbers on every beam, whether or not the branch on line 5 uses them. That looks wasteful; it is deliberate. Consuming a fixed number of samples per beam means toggling dropout off does not reshuffle the noise on the beams that survive, so two runs that differ in one parameter differ only in that parameter. Random-number discipline of this kind is what makes an A/B comparison between two configurations mean anything.

Implementation in Rust

This section fixes the workspace architecture. Later chapters add crates and modules; none of them restructure what is decided here.

crates/
  pr-core/        # accumulating core: prob (Ch. 2), geom (Ch. 3)
  sim/            # THIS CHAPTER: worlds, robot, sensors, logs
  widget-kit/     # THIS CHAPTER: the chrome every demo reuses
  ...             # bayes_core (Ch. 5), motion (Ch. 9), sensor (Ch. 10), ...
demos/
  ch04-lab/       # one [[bin]] per widget: w4-1-dashboard, w4-2-lidar-anatomy, ...

The world

The map is polyline geometry, not a grid. Exact ray/segment intersection is cheap, exact, and resolution-independent; Chapter 13 builds a grid from these walls, but the walls themselves are never one.

use nalgebra::{Point2, Vector2};
use parry2d_f64::bounding_volume::Aabb;
use parry2d_f64::partitioning::Qbvh;
use parry2d_f64::query::visitors::RayIntersectionsVisitor;
use parry2d_f64::query::{Ray, RayCast};
use parry2d_f64::shape::Segment;

/// Materials exist so a surface can be *optically* different from a wall
/// without being *geometrically* different. Glass is a wall to a planner and
/// nearly invisible to a LiDAR, and that mismatch is a real failure mode.
#[derive(Clone, Copy, PartialEq, Eq, Debug)]
pub enum Material {
    Wall,
    Glass,
    Door(u8),
}

pub struct Wall {
    pub seg: Segment,
    pub material: Material,
}

pub struct World {
    walls: Vec<Wall>,
    /// Quantized BVH over the wall segments. Rebuilt only when the map changes,
    /// which for a static world means exactly once — and it turns the scan cost
    /// from O(n_beams · n_segments) into O(n_beams · log n_segments).
    bvh: Qbvh<u32>,
    pub bounds: Aabb,
}

impl World {
    pub fn hallway() -> Self { /* corridor with three identical doors */ }
    pub fn apartment() -> Self { /* 12 × 9 m, five rooms off one corridor */ }

    /// First hit along a ray, or `max` if nothing is struck.
    ///
    /// The visitor is handed only the segments whose bounding volumes the ray
    /// actually crosses, and it keeps scanning after a hit because a nearer one
    /// may live in a sibling leaf.
    pub fn raycast(&self, origin: Point2<f64>, angle: f64, max: f64) -> Hit {
        let ray = Ray::new(origin, Vector2::new(angle.cos(), angle.sin()));
        let mut best = Hit { distance: max, material: None };
        let mut leaf = |&idx: &u32| {
            let w = &self.walls[idx as usize];
            if let Some(t) = w.seg.cast_local_ray(&ray, best.distance, true) {
                if t < best.distance {
                    best = Hit { distance: t, material: Some(w.material) };
                }
            }
            true
        };
        let mut visitor = RayIntersectionsVisitor::new(&ray, max, &mut leaf);
        self.bvh.traverse_depth_first(&mut visitor);
        best
    }

    /// Would a body of the given radius sweeping from `from` to `to` touch a wall?
    pub fn blocks(&self, from: &SE2, to: &SE2, radius: f64) -> bool { /* ... */ }

    /// Chapter 10's likelihood field wants this, so it lives here from the start.
    pub fn distance_to_nearest(&self, p: Point2<f64>) -> f64 { /* ... */ }
}

The robot

use nalgebra::Vector3;
use pr_core::geom::SE2;
use rand::rngs::SmallRng;
use rand_distr::{Distribution, Normal};

#[derive(Clone, Copy, Debug)]
pub struct RobotParams {
    pub wheel_radius: f64,       // r = 0.033 m
    pub track: f64,              // ℓ = 0.16 m
    pub body_radius: f64,        //     0.11 m
    pub ticks_per_rev: u32,      // N = 4096
    /// Stochastic, zero-mean, redrawn every tick.
    pub slip_std: f64,           // σ = 0.02
    /// Systematic: the *true* right wheel is r(1 + δ). Odometry never learns this.
    pub radius_bias_right: f64,  // δ = 0.0
}

#[derive(Clone, Copy, Debug)]
pub struct Twist { pub v: f64, pub omega: f64 }

pub struct Robot {
    pub pose: SE2,
    /// Cumulative wheel rotation, radians. This — not the ground travel — is
    /// what an encoder integrates, and the difference is the whole chapter.
    wheel_angles: [f64; 2],
    params: RobotParams,
    slip: SmallRng,
}

impl Robot {
    /// Actuate with slip, integrate exactly, refuse to pass through walls.
    pub fn step(&mut self, cmd: Twist, dt: f64, world: &World) -> StepOutcome {
        let RobotParams { wheel_radius: r, track: l, .. } = self.params;
        let half = cmd.omega * l / 2.0;
        let (wl, wr) = ((cmd.v - half) / r, (cmd.v + half) / r);

        // The wheels turn by the commanded amount, always.
        self.wheel_angles[0] += wl * dt;
        self.wheel_angles[1] += wr * dt;

        // The floor is under no such obligation.
        let eps = match Normal::new(0.0, self.params.slip_std) {
            Ok(n) => [n.sample(&mut self.slip), n.sample(&mut self.slip)],
            // σ = 0 is not a valid Normal, and is exactly the noise-free case
            // the regression test in `odometry_zero_noise_is_exact` exercises.
            Err(_) => [0.0, 0.0],
        };
        let ds_l = r * wl * dt * (1.0 + eps[0]);
        let ds_r = r * (1.0 + self.params.radius_bias_right) * wr * dt * (1.0 + eps[1]);

        let ds = 0.5 * (ds_r + ds_l);
        let dtheta = (ds_r - ds_l) / l;
        // Exact arc integration. Not an approximation of one — the arc itself.
        let next = self.pose.boxplus(&Vector3::new(ds, 0.0, dtheta));

        if world.blocks(&self.pose, &next, self.params.body_radius) {
            return StepOutcome::Blocked;  // wheels advanced; pose did not
        }
        self.pose = next;
        StepOutcome::Moved { ds, dtheta }
    }
}

The encoders

use nalgebra::Vector3;
use std::f64::consts::TAU;

/// Cumulative quadrature counts. Integers on purpose: an encoder has no
/// fractional state to report, and pretending otherwise hides the error budget.
#[derive(Clone, Copy, Default, PartialEq, Eq, Debug)]
pub struct EncoderTicks { pub left: i64, pub right: i64 }

pub fn observe(wheel_angles: [f64; 2], p: &RobotParams) -> EncoderTicks {
    let per_rad = f64::from(p.ticks_per_rev) / TAU;
    EncoderTicks {
        left: (wheel_angles[0] * per_rad).round() as i64,
        right: (wheel_angles[1] * per_rad).round() as i64,
    }
}

/// Metres of wheel travel per count: λ = 2πr / N.
pub fn tick_length(p: &RobotParams) -> f64 {
    TAU * p.wheel_radius / f64::from(p.ticks_per_rev)
}

/// `odometry_delta` — counts to a tangent vector, ready for ⊞.
///
/// The middle component is a structural zero, not a rounding artefact: a
/// differential drive has no lateral degree of freedom, and writing the twist
/// this way makes the compiler agree.
pub fn odometry_delta(prev: EncoderTicks, cur: EncoderTicks, p: &RobotParams) -> Vector3<f64> {
    let lambda = tick_length(p);
    let ds_l = lambda * (cur.left - prev.left) as f64;
    let ds_r = lambda * (cur.right - prev.right) as f64;
    Vector3::new(0.5 * (ds_r + ds_l), 0.0, (ds_r - ds_l) / p.track)
}

Determinism, and the log every later chapter consumes

use rand::{Rng, SeedableRng};
use rand::rngs::SmallRng;
use serde::{Deserialize, Serialize};

#[derive(Clone, Serialize, Deserialize)]
pub struct SimConfig {
    pub world: WorldId,
    pub robot: RobotParams,
    pub lidar: LidarParams,
    pub seed: u64,
    pub dt: f64,          // 0.02 s (the widgets on this page tick at 0.1 s, for legibility)
    pub scan_every: u32,  // one scan per 5 ticks
}

/// One RNG stream per noise source, all derived from the single config seed.
///
/// Sharing one generator between wheel slip and LiDAR noise would make the
/// trajectory depend on how many beams the LiDAR happens to have — so adding a
/// sensor would silently invalidate every recorded log in the repository. The
/// streams cost nothing and buy a guarantee.
fn split_streams(seed: u64) -> (SmallRng, SmallRng) {
    let mut master = SmallRng::seed_from_u64(seed);
    (
        SmallRng::seed_from_u64(master.random()),  // wheel slip
        SmallRng::seed_from_u64(master.random()),  // LiDAR
    )
}

/// What every estimator in this book consumes.
#[derive(Clone, Serialize, Deserialize)]
pub struct Frame {
    pub t: f64,
    /// Ground truth. Present in the log, and forbidden to every algorithm that
    /// is not scoring one. The type system cannot enforce that; code review can.
    pub truth: SE2,
    pub ticks: EncoderTicks,
    pub scan: Option<Scan>,
}

#[derive(Clone, Serialize, Deserialize)]
pub struct Log { pub cfg: SimConfig, pub cmds: Vec<Twist>, pub frames: Vec<Frame> }

impl Log {
    /// Chapters 11 and 12 benchmark on *identical* saved logs. That promise is
    /// made here, and `tests/replay.rs` is where it is kept.
    pub fn record(cfg: SimConfig, script: &dyn Script) -> Log { /* ... */ }
    pub fn save(&self, path: &Path) -> io::Result<()> { /* postcard */ }
    pub fn load(path: &Path) -> io::Result<Log> { /* postcard */ }
}

The tests that pin all of it

use approx::assert_relative_eq;

/// The chapter's hand-checkable worked example, to the digit.
#[test]
fn worked_example_ch04_one_arc() {
    let p = RobotParams { track: 0.16, ..RobotParams::rusty() };
    // Exact arc lengths, so the only thing under test is the geometry.
    let (ds_l, ds_r) = (0.72, 0.88);
    let ds = 0.5 * (ds_r + ds_l);
    let dtheta = (ds_r - ds_l) / p.track;
    assert_relative_eq!(ds, 0.80, epsilon = 1e-12);
    assert_relative_eq!(dtheta, 1.00, epsilon = 1e-12);

    let step = SE2::exp(&Vector3::new(ds, 0.0, dtheta));
    assert_relative_eq!(step.x(), 0.673_176_788, epsilon = 1e-9);
    assert_relative_eq!(step.y(), 0.367_758_155, epsilon = 1e-9);
    assert_relative_eq!(step.theta(), 1.0, epsilon = 1e-12);

    // The chord points along half the heading change, and falls short of the
    // arc by exactly what the midpoint rule overshoots by.
    let chord = (step.x().powi(2) + step.y().powi(2)).sqrt();
    assert_relative_eq!(chord, ds * (dtheta / 2.0).sin() / (dtheta / 2.0), epsilon = 1e-12);
    assert_relative_eq!(step.y().atan2(step.x()), dtheta / 2.0, epsilon = 1e-12);
    assert_relative_eq!(ds - chord, 0.032_919_138, epsilon = 1e-9);

    // Naive Euler: right distance, wrong direction, 39 cm of it.
    let euler = (ds - step.x()).hypot(step.y());
    assert_relative_eq!(euler, 0.389_011_810, epsilon = 1e-9);
}

/// Derivations 2 and 3 describe the same map, so with no noise and an encoder
/// fine enough to ignore, dead reckoning must reproduce ground truth exactly.
#[test]
fn odometry_zero_noise_is_exact() {
    let p = RobotParams { slip_std: 0.0, radius_bias_right: 0.0,
                          ticks_per_rev: 1 << 26, ..RobotParams::rusty() };
    let mut sim = Sim::new(SimConfig { robot: p, seed: 7, dt: 0.02, ..cfg() });
    let mut dr = sim.truth();
    let mut prev = EncoderTicks::default();

    for t in 0..3_000 {
        let frame = sim.step(figure_eight(t));
        dr = dr.boxplus(&odometry_delta(prev, frame.ticks, &p));
        prev = frame.ticks;
    }
    let err = (dr.boxminus(&sim.truth())).norm();
    assert!(err < 1e-7, "dead reckoning drifted {err} m with no noise");
}

/// The determinism regression lock. Two runs from the same seed must agree
/// bit-for-bit — not "to 1e-9", bit-for-bit — or a benchmark comparing two
/// algorithms on "the same" log is comparing two different logs.
#[test]
fn replay_is_bit_exact() {
    fn bits(p: &SE2) -> [u64; 3] {
        [p.x().to_bits(), p.y().to_bits(), p.theta().to_bits()]
    }

    let cfg = SimConfig { seed: 20_260_811, ..cfg() };
    let a = Log::record(cfg.clone(), &FigureEight);
    let b = Log::record(cfg, &FigureEight);
    assert_eq!(a.frames.len(), b.frames.len());
    for (fa, fb) in a.frames.iter().zip(&b.frames) {
        assert_eq!(bits(&fa.truth), bits(&fb.truth));
        assert_eq!(fa.ticks, fb.ticks);
    }
}

Measuring the lab like an experimentalist

Every claim above is a claim about a distribution, and a distribution is not something you can see in one run. So do what an experimentalist would: run the same command script many times and look at the spread.

This widget is the reason every benchmark in this book reports over many seeds. Three things it makes visible that no single trajectory can:

A run is a sample. Any one of those orange traces looks like the answer. Forty-eight of them are a distribution over futures, and the honest summary of "what will Rusty do" is the fan, not any member of it.

Growth is superlinear in time. Measured on the straight leg over 480 seeds (the widget runs 48, so expect a little more scatter), the total spread at 1, 2 and 3 seconds is 2.1 cm, 5.7 cm and 10.1 cm — ratios of 2.7 and 4.9 against the $t^{3/2}$ predictions of 2.83 and 5.20. Heading error accumulates as a random walk, $\sqrt{t}$; position error integrates heading error, adding a factor of $t$. Anyone who tells you odometry error grows like $\sqrt{t}$ is quoting the heading.

The spread is anisotropic, and it is the wrong shape for a circle. At the end of the straight leg the cross-track spread is nine times the along-track spread: slip that differs between the wheels turns you, and a heading error only becomes a position error sideways. That crescent is the "banana" distribution Chapter 9 derives analytically, grown here from nothing but per-wheel noise — and it is the first concrete demonstration in this book that a Gaussian is going to be an approximation.

Now push the second slider off zero. The fan stops being centred on the dashed line at all; the whole ensemble leaves together. That is bias, and no number of seeds will average it away.

Anatomy of a book widget

One last piece of infrastructure, and it is the one you will use most: the contract every figure in this book obeys.

Two clauses deserve their own paragraph.

The seed is visible. Not logged, not configurable-if-you-dig — printed in the transport bar of every widget. This is a claim the book makes about itself: a figure you cannot reproduce is a figure you cannot check, and a benchmark whose seed is hidden is a benchmark you should not believe. On the Rust side the same claim is enforced by replay_is_bit_exact, which is why Sim contains no parallelism and no unordered summation. Speed inside the simulator core is worth less than the guarantee.

Autoplay is not decoration; it is an accessibility position. Interaction is an invitation, not a requirement. A reader who never touches a control should still learn the lesson from the default run, which means the default parameters have to be chosen for legibility rather than realism — and where they are, this book says so out loud, as it did for $\sigma_{\mathrm{slip}}$ above.

Where this goes

You now own the instrument. Everything else in the book is measurement.

Chapter 5 puts a belief on top of it and gives the corridor a filter. Chapter 9 fits a probabilistic motion model to this simulator's slip — deliberately in a parametrization the simulator does not use, so the reader meets model mismatch honestly rather than by accident. Chapter 10 learns beam intrinsics from Lidar data recorded here. Chapter 12 runs its grid-versus-MCL benchmark on identical saved Logs. And the Apartment is the arena for all of it, right through Chapter 26.

Exercises

1. Foundation exerciseFDifficulty 1 of 3Inverse kinematics and the ICR

   Derive $(v,\omega) \mapsto (\omega_L, \omega_R)$ from Derivation 1 and show that the instantaneous centre of rotation lies on the wheel axle at signed distance $R = v/\omega$. Then exhibit a body twist that a differential drive cannot produce at any instant, and connect it to the Pfaffian constraint $\dot{x}\sin\theta - \dot{y}\cos\theta = 0$. Finally: Rusty has $r = 0.033$ m and a motor limit of 20 rad/s per wheel. What is the tightest turn it can make at 0.4 m/s?

2. Foundation exerciseFDifficulty 2 of 3Price the approximation over a real trajectory

   Using the polar form of Derivation 2, prove that the midpoint rule's error is purely radial and equal to $\Delta s\left(1 - \operatorname{sinc}(\Delta\theta/2)\right)$. Then bound the total error accumulated over a 60-second figure-eight at $v = 0.5$ m/s, $|\omega| = 0.6$ rad/s, when the odometry is integrated at (a) 50 Hz, (b) 5 Hz, and (c) 2 Hz. At which rate does the integration error exceed the quantization error from a 4096-count encoder? At which does it exceed the slip drift at $\sigma_{\mathrm{slip}} = 0.02$?

3. Foundation exerciseFDifficulty 3 of 3Why t to the three halves

   Model the per-tick heading increment error as i.i.d. $\Normal(0, s^2)$ and the forward step as a constant $d$ metres. Show that the variance of the accumulated cross-track position error after $n$ ticks is $d^2 s^2 \sum_{k=1}^{n-1} k \sim d^2 s^2 n^2/2$, so the standard deviation grows like $n^{3/2}$. Then state precisely which assumption you would have to break for odometry error to grow like $\sqrt{t}$, and give a physical situation in which it does.

4. Conceptual exerciseCDifficulty 1 of 3Predict the fan, then check it

   Before touching the Seed Lab, sketch two pictures. (a) The fan when the right wheel's radius is $1\%$ too large and slip is zero. (b) The fan when slip is at maximum and $\delta = 0$. For each: where is the centre of the fan relative to the gray dashed line, and how wide is it? Now set both sliders and check. Write one sentence per picture distinguishing a systematic from a stochastic error. Then a harder one, which the widget cannot show you: if stochastic slip afflicted only the right wheel, would the fan skew? Argue from the sign of $\Delta\theta = (\Delta s_R - \Delta s_L)/\ell$, and say why that is not the same experiment as turning $\delta$ up.

5. Conceptual exerciseCDifficulty 2 of 3Read the cliff edges

   In LiDAR Anatomy, predict — before scrubbing — the beam indices at which the range jumps as the beam crosses the doorway edges, given that the sensor sits 1.06 m from the corridor's south wall, centred on a doorway 1.0 m wide, with 180 beams over a full circle and beam 90 pointing straight ahead. Verify with the scrubber. There is a third cliff, near beam 5. What is it? Now raise the dropout rate to 20% and answer: if you smoothed the range-versus-beam curve to suppress the dropout spikes, what would you destroy? (This is not a rhetorical question. It is why Chapter 10 models dropouts as a mixture component rather than filtering them out.)

6. Practical exercisePDifficulty 2 of 3Give Rusty a sonar

   Add a Sonar type to crates/sim beside Lidar, exposing the same scan-style API: aperture 15°, return equal to the nearest hit anywhere within the cone plus Gaussian noise. Implement the cone query by sampling the aperture finely enough that the error is below $\sigma$, and say what "finely enough" is. Then write one paragraph explaining why sonar walls smear at corners where LiDAR walls do not, and what that does to a scan matcher.

7. Practical exercisePDifficulty 3 of 3Break determinism on purpose

   Make replay_is_bit_exact pass in your fork, native and WASM. Then break it deliberately in two different ways: (a) share one SmallRng between wheel slip and LiDAR noise, then change n_beams from 180 to 181 and watch the trajectory change; (b) accumulate a per-beam sum over a scan with a rayon parallel reduction instead of a sequential fold, and exhibit two runs that disagree in the last bits. For each, explain in two sentences what property was lost and which downstream chapter's benchmark it would silently corrupt.

References

1. Lynch, K. M. and Park, F. C. (2017) Modern Robotics: Mechanics, Planning, and Control. Cambridge University Press (ISBN 9781107156302).link to Modern Robotics: Mechanics, Planning, and Control (opens in a new tab)

   §13.3 gives the differential-drive kinematics of Derivation 1 and §13.4 the odometry update of Derivation 3 — already in exponential-coordinate form. Their eq. (13.35) is our V(ω)ρ with the algebra spelled out; recognizing it as exp is the only thing this chapter adds.

2. Borenstein, J. and Feng, L. (1996) Measurement and Correction of Systematic Odometry Errors in Mobile Robots. IEEE Transactions on Robotics and Automation 12(6), 869–880.doi:10.1109/70.544770 (opens in a new tab)

   The UMBmark procedure, and the source of this chapter's insistence on separating systematic from stochastic error. Their two dominant terms — uncertain wheelbase and unequal wheel diameters — are exactly the second slider in w4.1.

3. Thrun, S., Burgard, W., and Fox, D. (2005) Probabilistic Robotics. MIT Press.link to Probabilistic Robotics (opens in a new tab)

   §5.2.1 sets up the kinematic configuration this chapter simulates; Chapter 6's beam mixture is the inference model our two-component generative LiDAR is deliberately not.

4. Solà, J., Deray, J., and Atchuthan, D. (2018) A Micro Lie Theory for State Estimation in Robotics. arXiv:1812.01537.link to A Micro Lie Theory for State Estimation in Robotics (opens in a new tab)

   The reference for the ⊞ / ⊟ notation used throughout, and for why composing odometry increments on the group is not the same as adding them in coordinates.

5. Manivasagam, S., Wang, S., Wong, K., Zeng, W., Sazanovich, M., Tan, S., Yang, B., Ma, W.-C., and Urtasun, R. (2020) LiDARsim: Realistic LiDAR Simulation by Leveraging the Real World. CVPR 2020, 11164–11173.link to LiDARsim: Realistic LiDAR Simulation by Leveraging the Real World (opens in a new tab)

   The state of the art in going beyond a ray-cast-plus-Gaussian sensor: physics for the geometry, a learned residual for everything the geometry misses. Read it as the honest upper bound on how wrong our σ_r model is.

6. Guillard, B., Vemprala, S., Gupta, J. K., Miksik, O., Vineet, V., Fua, P., and Kapoor, A. (2022) Learning to Simulate Realistic LiDARs. IEEE/RSJ IROS 2022 (arXiv:2209.10986).link to Learning to Simulate Realistic LiDARs (opens in a new tab)

   Learns ray-drop and intensity from real scans, and shows that dropout is strongly surface-dependent rather than the i.i.d. p_drop we use. The right thing to read before believing any dropout number in this chapter.

7. Macenski, S., Foote, T., Gerkey, B., Lalancette, C., and Woodall, W. (2022) Robot Operating System 2: Design, Architecture, and Uses in the Wild. Science Robotics 7(66), eabm6074.doi:10.1126/scirobotics.abm6074 (opens in a new tab)

   Where the interfaces this chapter's Frame type imitates actually live in production. Useful for seeing which of our simplifications a deployed stack also makes, and which it does not.

8. Fischer, T., Paredes, I., Batchelor, M., Beier, T., Haviland, J., Traversaro, S., Vollprecht, W., Schmitz, M., and Milford, M. (2024) ROS2WASM: Bringing the Robot Operating System to the Web. arXiv:2409.09941.link to ROS2WASM: Bringing the Robot Operating System to the Web (opens in a new tab)

   Independent evidence for this book's central bet: compiling a robotics stack to WebAssembly makes results reproducible and shareable in a way a README never does. Their argument for the browser is our argument for every widget on this page.