PROJECT: Differential-drive simulator

AThe project

This first portfolio project builds a differential-drive simulator (a program that models a differential-drive robot moving in 2D and shows its trajectory), bringing together the Pass-1 geometry and motion lessons into something that runs‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍. You implement the differential-drive kinematics (wheel speeds to motion), the motion model (step the pose forward over time), the coordinate frames (the robot's pose in the world), and visualisation (draw the path), and watch the robot drive straight, arc, and spin, observing how odometry tracks (and would drift). It's the natural first build: pure software, fully observable, and it makes the abstract math concrete.

The simulator is a small loop over the robot's state: its pose (x, y, ) in the world frame. Each timestep you take the commanded wheel speeds, apply the differential-drive kinematics to get the robot's linear and angular velocity (v, ), and apply the motion model to update the pose (move distance vdt along the heading, turn omegadt). Exactly the integration that real odometry does. Then you draw the robot and its trajectory. Driving the wheels in different patterns reproduces the kinematics you learned: ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍equal speeds -> a straight line, unequal -> an arc, equal and opposite -> spinning in place. Building this cements how wheel commands become motion, how the motion model integrates pose, and how everything lives in a coordinate frame, and because it's a simulation, you can see and verify all of it (and it's the safe, cheap first step the testing lesson advocates).

Simulate a differential-drive robot: kinematics + motion model + frames + visualisation:

STATE: the robot's pose (x, y, theta) in the WORLD frame
EACH TIMESTEP dt:
  1. take commanded WHEEL SPEEDS (vL, vR)
  2. KINEMATICS -> v = (vR+vL)/2,  omega = (vR-vL)/L        (wheel speeds -> robot velocity)
  3. MOTION MODEL -> integrate: x += v*dt*cos(theta); y += v*dt*sin(theta); theta += omega*dt   (update pose)
  4. VISUALISE -> draw the robot + append to the trajectory
TESTS: equal wheels -> straight | unequal -> arc | equal & opposite -> spin in place | observe odometry tracking
SKILLS: coordinate systems + motion models + kinematics + visualisation (the Pass-1 geometry/motion lessons, running)

‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍The disciplines. Represent the robot's state as a pose (x, y, ) in the world frame. Each timestep: take the wheel speeds, convert to (v, ) with the differential-drive kinematics (, ), and integrate with the motion model (x += v dt cos theta; y += v dt sin theta; theta += omega dt) to update the pose: then visualise the robot and its trajectory. Verify against the kinematics you know (equal -> straight, unequal -> arc, opposite -> spin) and observe how odometry tracks the motion. The habits this builds: turn wheel commands into motion, integrate a motion model to move a pose, keep everything in a frame, and visualise to verify: the core loop of mobile-robot simulation. It makes Pass-1's geometry and motion concrete and runnable‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍.

Formulas & method. Two formulas carry the whole simulator. The kinematics that turn wheel speeds into robot velocity, and the integration that turns velocity into a new pose:

v     = (vR + vL) / 2.0          # linear velocity  (m/s)
omega = (vR - vL) / L            # angular velocity (rad/s), L = wheel separation

x     += v * math.cos(theta) * dt    # integrate in the WORLD frame, so the
y     += v * math.sin(theta) * dt    # heading has to multiply the displacement
theta += omega * dt

‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍The method is verification by known cases rather than by eyeballing the plot: must give a straight line, a circular arc of radius , and a pure spin with and unchanged. Each of those is a hand-computable prediction, which is what makes a wrong sign convention visible instead of merely suspicious.

Everything else you already have, and this is where each piece comes from:

Project layout. Four files, because the kinematics must be testable without the plotting and the plotting must not be able to change the kinematics:

diffdrive-sim/
|-- pose.py        # THE TYPE, and its UNITS. Plus the angle wrap.
|-- kinematics.py  # wheel speeds -> body motion -> one integrated step. No I/O.
|-- sim.py         # THE RIG: run a command sequence, return the trace
`-- main.py        # the hand-checked cases, then the square and its error

Get the geometry provably right first. Every later robotics project reuses this integration step, so a quiet bias here follows you through the whole topic.

Portfolio presentation. Lead with the plotted trajectories: a straight run, a circle with its measured radius against , and a closed shape showing the return error. Those numeric validations turn a drawing into evidence that the kinematics are right. State your units convention explicitly and mention the theta-before-position integration order. This is the foundation every later robot project builds on, so presenting it as verified rather than merely working is the point.

# pose.py - the pose, with its UNITS written down. Metres and radians, everywhere, always.
import math


def new_pose(x=0.0, y=0.0, theta=0.0):
    """(x, y) in METRES, theta in RADIANS measured from +X, CCW positive."""
    return (x, y, theta)


def wrap(theta):
    """Keep theta in (-pi, pi]. Without this, a robot spinning for a minute reports a
    heading of 40 radians, which is correct and unusable."""
    return math.atan2(math.sin(theta), math.cos(theta))

# kinematics.py - wheel speeds to body motion, and the integration. No plotting, no I/O.
import math

from pose import wrap


def body_from_wheels(vL, vR, L):
    """v = average, w = difference / axle length. Two lines, and every differential-drive
    robot in the course rests on them."""
    return (vL + vR) / 2.0, (vR - vL) / L


def step(pose, vL, vR, dt, L=0.30):
    """Integrate one timestep. HEADING FIRST, then position with the NEW heading."""
    x, y, th = pose
    v, w = body_from_wheels(vL, vR, L)
    th = wrap(th + w * dt)                       # ...first
    x += v * math.cos(th) * dt                   # ...then position, using the new theta
    y += v * math.sin(th) * dt
    return (x, y, th)

# sim.py - run a command sequence and record the trajectory.
from kinematics import step
from pose import new_pose


def run(commands, dt=0.01, L=0.30, pose=None):
    """commands: a list of (vL, vR, duration_s). Returns the pose trace."""
    p = pose or new_pose()
    trace = [p]
    for vL, vR, dur in commands:
        for _ in range(int(round(dur / dt))):
            p = step(p, vL, vR, dt, L)
            trace.append(p)
    return trace

# main.py - the three hand-computable cases, then a closed shape and what it costs.
import math

from sim import run
from kinematics import body_from_wheels

L = 0.30
W_SPIN = 1.0 / L                                  # rad/s at vL=-0.5, vR=+0.5

if __name__ == "__main__":
    # --- the three cases whose answers you know WITHOUT simulating -------------------
    v, w = body_from_wheels(0.5, 0.5, L)
    assert abs(v - 0.5) < 1e-12 and abs(w) < 1e-12, "equal wheels: pure translation"
    v, w = body_from_wheels(-0.5, 0.5, L)
    assert abs(v) < 1e-12 and abs(w - W_SPIN) < 1e-9, "opposite wheels: pure rotation"
    v, w = body_from_wheels(0.0, 0.0, L)
    assert v == 0.0 and w == 0.0, "stopped is stopped"
    print("kinematics: 3 hand-checked cases OK")

    # --- straight line: distance must equal v x t, EXACTLY ---------------------------
    x, y, th = run([(0.5, 0.5, 4.0)])[-1]
    assert abs(x - 2.0) < 1e-9, f"straight: x = {x}, expected 2.0"
    assert abs(y) < 1e-12 and abs(th) < 1e-12, "a straight line must not drift"
    print(f"straight:  4 s at 0.5 m/s -> x = {x:.6f} m, y = {y:.1e}, theta = {th:.1e}")

    # --- spin in place: no translation at all ----------------------------------------
    x, y, th = run([(-0.5, 0.5, (math.pi / 2) / W_SPIN)])[-1]
    assert abs(x) < 1e-12 and abs(y) < 1e-12, "a spin must not translate"
    print(f"spin:      commanded 90.000 deg -> got {math.degrees(th):.3f} deg, "
          f"x = {x:.1e}, y = {y:.1e}")

    # --- an arc: curves toward the SLOWER wheel ---------------------------------------
    x, y, th = run([(0.4, 0.5, 3.0)])[-1]
    assert y > 0 and th > 0, "the right wheel faster must curve toward +y, the slower side"
    print(f"arc:       vL 0.4, vR 0.5, 3 s -> ({x:.3f}, {y:.3f}) m, "
          f"{math.degrees(th):.1f} deg - curves toward the SLOWER wheel")

    # --- the square, and what the integrator costs ------------------------------------
    print("\nsquare: 4 x (1 m straight + 90 deg turn). It should return to the origin.")
    print("  dt (s)     closure error (m)   final heading (deg)")
    prev = None
    for dt in (0.05, 0.01, 0.001, 0.0001):
        x, y, th = run([(0.5, 0.5, 2.0), (-0.5, 0.5, (math.pi / 2) / W_SPIN)] * 4, dt=dt)[-1]
        err = math.hypot(x, y)
        print(f"  {dt:<10} {err:>10.5f}          {math.degrees(th):+8.3f}")
        if prev is not None:
            assert err < prev, "halving dt must reduce the error - the integrator converges"
        prev = err

kinematics: 3 hand-checked cases OK
straight:  4 s at 0.5 m/s -> x = 2.000000 m, y = 0.0e+00, theta = 0.0e+00
spin:      commanded 90.000 deg -> got 89.763 deg, x = 0.0e+00, y = 0.0e+00
arc:       vL 0.4, vR 0.5, 3 s -> (1.135, 0.622) m, 57.3 deg - curves toward the SLOWER wheel

square: 4 x (1 m straight + 90 deg turn). It should return to the origin.
  dt (s)     closure error (m)   final heading (deg)
  0.05          0.20703           -16.225
  0.01          0.01170            -0.946
  0.001         0.00225            -0.183
  0.0001        0.00037            -0.030

   THE UNITS GO IN THE DOCSTRING, and this is not pedantry. Every mixed-unit bug in
   robotics looks like a physics problem: degrees where radians were expected gives a robot
   that turns 57 times too far, and the symptom is a robot spinning wildly rather than an
   error message. Write "metres and radians" in `pose.py` and every other file inherits it.

   THE WRAP IS THE OTHER HALF: without it, a robot spinning for a minute reports a heading
   of 40 radians, which is arithmetically correct and useless to compare, plot or feed to
   an atan2. Wrap once, in `pose.py`, so no caller has to remember.

   HEADING FIRST, THEN POSITION WITH THE NEW HEADING. Update x and y with the OLD theta and
   the error is small, systematic and in one direction - it shows up as a slow drift in y on
   a straight line, which looks like a wheel-calibration problem and is not.

   THESE THREE BETWEEN THEM CATCH EVERY KINEMATICS BUG THIS PROJECT CAN HAVE, and it takes
   all three: a sign error in w is completely invisible while the wheels match, and shows up
   the instant they differ. The straight-line case pins the units, the spin pins the sign,
   the arc pins the direction.

   NOTE THE SPIN ALREADY SHOWS THE DISCRETISATION: 89.763 degrees against a commanded 90.
   The turn takes 47.12 timesteps at dt = 0.01 and the loop runs a whole number of them, so
   0.12 of a step is lost. That 0.24-degree error is not a bug - it is the cost of a
   fixed timestep, and the next section is what it compounds into.

   FOUR STRAIGHTS AND FOUR EXACT 90-DEGREE TURNS SHOULD RETURN TO THE ORIGIN. It does not,
   and how much it misses by depends entirely on the timestep:

     dt = 0.05 s   208 mm out, heading 16.2 degrees wrong    <- a fifth of a metre
     dt = 0.01 s    12 mm out, heading  0.95 degrees wrong
     dt = 0.001 s    2 mm out, heading  0.18 degrees wrong
     dt = 0.0001 s   0.4 mm out, heading 0.03 degrees wrong

   THE ERROR IS ROUGHLY PROPORTIONAL TO dt, which is the signature of a first-order (Euler)
   integrator. Halve the timestep and halve the error; there is no timestep at which it
   becomes zero.

   WHY IT ACCUMULATES: each turn is quantised to a whole number of steps, so each is
   slightly short, and the heading error carries into the next straight - which then points
   in the wrong direction for a whole metre. Four of those compound.

   THIS IS EXACTLY WHAT ODOMETRY DRIFT IS. A real robot integrating wheel encoders has this
   same error plus wheel slip, plus a wheel-radius estimate that is a little wrong, plus an
   axle length that is a little wrong - and it compounds in the same way, for the same
   reason. A robot that has driven a hundred metres does not know where it is, and this
   table is why, in a system with no sensor noise at all.

   THE CONCLUSION TO WRITE DOWN: dead reckoning is a short-term tool. It is excellent over
   seconds and useless over minutes, and every localisation method later in this topic
   exists to correct it with something absolute.

Seeing it in 3D, on Windows or macOS, without installing Linux. Nothing above needs a simulator, and that is deliberate: building the rig yourself is what keeps the kinematics visible and testable. But the Gazebo work later in this course does assume Linux, and if you want a robot moving in three dimensions under your own controller before you commit to that, Webots is the shortest route. It is Apache-2.0, it installs natively on Windows, macOS and Linux, and it ships with working robots, so the distance from download to something driving under your code is one sitting rather than one weekend of setup.

The exercise worth doing is not "look at a nicer robot". Open a built-in differential-drive robot, drive it with the same command sequence you used in step 7, and compare the closing error of the square against the one your own sim.py produced. Yours integrates the motion model you chose; Webots integrates a physics engine with wheel contact, slip and mass. The gap between the two numbers is the reality gap in miniature, met on a program you understand completely, which is a far better first encounter with it than meeting it on hardware.

‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍Keep the proportion right. Webots is the on-ramp and the prototyping tool; Gazebo is what ROS 2 jobs expect, and the simulators hands-on guide in Turn 2 sets out when to reach for which. A screenshot is not a substitute for the plotted trajectories and their measured errors, which stay the evidence this project is judged on.

Why it exists. The Pass-1 lessons gave you the math of frames, kinematics, and motion models, but math becomes real understanding only when you build something that uses it. A differential-drive simulator is the ideal first build: it requires exactly those concepts (a pose in a frame, kinematics to get velocity, a motion model to integrate it, visualisation to see it), it's pure software (cheap, safe, fully observable: the simulate-first practice), and it produces a visible, verifiable result. It cements the foundations and gives you a tool (and a portfolio piece) you'll reuse, which is why it's the first portfolio project.

Mental model. The simulator is like a flight simulator for a tiny two-wheeled robot, drawn on graph paper‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍. You hold the robot's situation as a dot with an arrow on the graph paper (its pose, where it is and which way it faces). Each tick of the clock, you read how fast each wheel is turning, work out from that how fast the whole robot is going forward and how fast it's turning (the kinematics), then nudge the dot forward and rotate the arrow by that much (the motion model) and leave a breadcrumb. Do that many times a second and the breadcrumbs trace the robot's path. There's no real robot, no risk, no cost: just the rules of how a two-wheeled robot moves, applied over and over on graph paper, letting you watch the math you learned actually drive a robot around.

Common misunderstandings.

• "A simulator needs a physics engine / it's complicated." A basic differential-drive simulator is just the kinematics + motion-model integration in a loop. A pose updated each timestep from wheel speeds. You don't need a full physics engine to capture the kinematic motion; the simple integration is the simulator (more realism, like noise and slip, is added later).
• ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍"Bigger timesteps are fine." Integrating the motion model with too large a dt introduces error (the robot moves in straight-line chunks each step, approximating curves coarsely). Smaller dt gives a more accurate trajectory. A reminder that the motion model is a discrete approximation of continuous motion.
• "The simulator shows the true position, so there's no drift." The simulator's integration is the ground truth here, but it models exactly what odometry does, so it lets you see that if you fed in noisy/slipping wheel measurements, the integrated estimate would drift from truth. The project is the place to make odometry's drift visible.

Connections. This project makes Pass-1 concrete: it directly implements differential-drive kinematics (the differential-drive kinematics lesson) and the motion model (the odometry lesson), uses coordinate frames (coordinate-frames 08) for the pose, and applies simulate-first (the sim/test/debug lesson). It's the robotics-framed sibling of the ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍C++ diff-drive project and uses the Python/visualisation skills from that topic. It's the foundation for the next project (the explorer adds sensing, mapping, and decision-making on top of this motion core) and a stepping stone to the full Gazebo simulations, your first runnable robot.

BImmediate Active Recall

‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍CConceptual Questions

Answer each in your own words in the box, then reveal the model answer to compare. These ask why, not how, and your answers are saved.

DPractice Problems

P1 (easy). Write the simulator's core and run its three verification cases.

Give step(pose, vL, vR, dt, L) and a run helper, then produce the results table for: ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍straight (vL = vR = 0.5 m/s for 2 s), arc (vL = 0.4, vR = 0.6, one full circle), and spin (vL = -0.5, vR = 0.5 for 1 s), with L = 0.30 m and dt = 1 ms. State the hand-computed prediction for each and the measured result, and explain the one discrepancy.

P2 (medium). Build the test suite that catches sign and scale errors. Write it as three asserts on the three cases, then deliberately introduce three bugs and produce the table of what each verification case reports for each bug:

1. (a sign slip in the linear velocity),
2. (the angular sign reversed),
3. (half the wheelbase used).

Say which case catches which bug, whether any bug survives all three, and what that says about choosing test cases.

‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍P3 (harder). Quantify what the simulator buys and what it cannot.

Time 200 full five-second runs at dt = 1 ms in the simulator, and compare against the same 200 runs on hardware allowing 30 s of setup each. Then write the parameter sweep the simulator makes possible (for example, finding the wheelbase that best explains a recorded trajectory) as code. Finally, list four things about this robot that the simulator cannot tell you, and state the rule for what belongs in simulation and what does not.

import math

def step(pose, vL, vR, dt, L=0.30):
    x, y, theta = pose
    v     = (vR + vL) / 2.0
    omega = (vR - vL) / L
    theta += omega * dt                     # heading first
    x     += v * math.cos(theta) * dt
    y     += v * math.sin(theta) * dt
    return (x, y, theta)


def run(vL, vR, duration, dt=0.001, L=0.30, pose=(0.0, 0.0, 0.0)):
    for _ in range(int(duration / dt)):
        pose = step(pose, vL, vR, dt, L)
    return pose

# tests/test_kinematics.py
import math
from sim import run

L = 0.30

def test_straight():
    x, y, theta = run(0.5, 0.5, 2.0, L=L)
    assert abs(x - 1.0) < 1e-6
    assert abs(y) < 1e-9
    assert abs(theta) < 1e-9

def test_spin_in_place():
    x, y, theta = run(-0.5, 0.5, 1.0, L=L)
    assert abs(x) < 1e-9 and abs(y) < 1e-9
    assert abs(theta - 1.0 / L) < 1e-6          # +3.3333 rad/s for 1 s. Note the SIGN

def test_arc_radius():
    vL, vR = 0.4, 0.6
    v, omega = (vR + vL) / 2, (vR - vL) / L
    assert abs(v / omega - 0.75) < 1e-9         # the radius, computed from the model
    x, y, theta = run(vL, vR, 2 * math.pi / omega, L=L)
    assert math.hypot(x, y) < 0.01              # the circle closes

# calibrate.py  -  find the wheelbase that best explains a recorded run
import math
from sim import run

def closing_error(L, vL, vR, duration, recorded_end):
    x, y, theta = run(vL, vR, duration, dt=0.001, L=L)
    return math.hypot(x - recorded_end[0], y - recorded_end[1])

def best_wheelbase(vL, vR, duration, recorded_end, lo=0.20, hi=0.40, n=201):
    candidates = [lo + (hi - lo) * i / (n - 1) for i in range(n)]
    return min(candidates, key=lambda L: closing_error(L, vL, vR, duration, recorded_end))

L_est = best_wheelbase(0.4, 0.6, 9.425, recorded_end=(0.03, -0.11))

EFeynman Exercise

Explain to a beginner, using the picture of a flight simulator for a tiny two-wheeled robot drawn on graph paper: (1) why you hold the robot as a dot-with-an-arrow (its pose) and, each tick, work out from the wheel speeds how fast it goes forward and turns (the kinematics), (2) why you then nudge the dot and rotate the arrow by that much and leave a breadcrumb (the motion model, integrated step by step), and (3) why doing this on graph paper (with no real robot, risk, or cost) lets you watch the math you learned actually drive a robot around.

FError Analysis Framework

• Thinking a basic simulator needs a full physics engine. Why: simulating motion sounds complex. Recognise: the kinematics + motion-model integration in a loop IS a basic diff-drive simulator. Avoid: implement the simple pose update from wheel speeds; add realism (noise/slip/physics) later.
• Using too large a timestep dt in the integration. Why: a big dt runs faster. Recognise: large dt makes the motion model (a discrete approximation) inaccurate (coarse straight-line chunks). Avoid: use a small enough dt for an accurate trajectory; remember it approximates continuous motion.
• Getting the pose-update trig or frame wrong. Why: just add the motion to x and y. Recognise: motion is along the current heading. Needs in a consistent frame, in the right order. ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍Avoid: integrate x += vdtcos(theta); y += vdtsin(theta); theta += omega*dt, all in the world frame.
• Assuming the simulator shows there's no odometry drift. Why: the simulated position is exact. Recognise: the sim is ground truth, but it models exactly what odometry integrates. Avoid: feed in noisy/slipping wheel readings to make odometry's drift visible (the point of the exercise).

GMini Challenge

Design and explain a differential-drive simulator project for a new roboticist: the state (pose), the per-timestep loop (wheel speeds -> kinematics -> motion-model integration -> visualise), how to verify it, and why building it (in pure software) cements the Pass-1 foundations and embodies simulate-first.

Quiz Check

A quick auto-graded check, separate from the recall cards above. Your score feeds the dashboard Mastery metric. On a project it is optional. Working through the build walkthrough in section A is what completes this module.