Distance Lab

Setup — ten minutes

• One long strip of tape on the floor per team, as a start line. Bots always start with wheels behind it.
• One tape measure or meter stick per team. This is the most important object in the room today.
• Measure in centimeters. Written down.
• Each team needs their MakeCode project open.

The lab — run this loop for the whole block

1. Trial 1 is calibration: drive for exactly 1 second.Run it, and measure how far the bot traveled in centimeters.Write it down. This number is the bot's speed in cm per second. Every team's will be different — that is the point.
2. Now predict, before touching anything. "If our bot drives for 3 seconds, it will travel ______ cm."They get this by multiplying: cm per second × 3. Written down before the bot moves.
3. Run it for 3 seconds. Measure the actual distance in cm.
4. Gap sentence, out loud and written: "We predicted ___ cm. We got ___ cm. The gap was ___ cm. Because ___."Almost every team will travel further than predicted, and the miss grows the longer they drive. That is real, and it is the discovery of the whole lab — let them find it, do not tell them.
5. Change exactly ONE number in their model or their code, and write down which one.Usually: subtract a start-up lag from the prediction, or adjust the cm-per-second figure.
6. Predict a new distance for a new time (try 3 s, then 4 s, then 5 s), run, measure, gap sentence again.Aim for five trials per team. Five predicted-vs-actual pairs is plenty of data for Tuesday.

The code — paste this once, then never re-download

Open MakeCode, add the Cutebot Pro extension, switch to JavaScript, select all and delete, then paste this in. It is the whole program.

// ═══════════════════════════════════════════════════════
//  DISTANCE LAB
//  A  = run one trial
//  B  = add 0.5 s to the drive time
//  A+B = reset to 1.0 s
// ═══════════════════════════════════════════════════════

let SPEED = 5                          // <-- your team's Speed stat
let motorPower = SPEED * 100 / 20      // same formula as your match code
let driveMs = 1000                     // start at 1.0 second

// The display shows TENTHS of a second:  10 = 1.0s,  25 = 2.5s
basic.showNumber(driveMs / 100)

// A -- run one trial
input.onButtonPressed(Button.A, function () {
    basic.showString("GO")
    CutebotPro.pwmCruiseControl(motorPower, motorPower)
    basic.pause(driveMs)
    CutebotPro.stopImmediately(CutebotProMotors.ALL)
    basic.showNumber(driveMs / 100)
})

// B -- add half a second. No re-download needed.
input.onButtonPressed(Button.B, function () {
    driveMs += 500
    basic.showNumber(driveMs / 100)
})

// A+B -- back to 1.0 second
input.onButtonPressed(Button.AB, function () {
    driveMs = 1000
    basic.showNumber(driveMs / 100)
})

The mathematics they are actually doing

This is not a consolation activity. It is an alternative version of the same modeling the matches were supposed to produce — and the relationship here is linear, so the equation behaves:

Start-up is a negative number, so + start-up reads as a subtraction — e.g. 38 × time + (−7) = 38 × time − 7. And speed here is the bot's cm per second from Trial 1, not the 1–17 Speed stat set in the code.

• m (the slope) is the bot's speed in cm per second — a number with a real physical meaning they measured themselves.
• b (the intercept) is the start-up lag and it comes out negative — the bot loses a few centimeters while it accelerates.
  Here is the trap, and it is a good one: a team that calibrates on the 1-second run bakes that lag into their rate, so their cm-per-second figure is too low. They then under-predict every longer drive, and the miss gets bigger the further they go. Finding that — and fixing it by taking the rate from the difference between two runs instead — is the strongest thing that can happen in this lab.
• x is drive time in seconds; y is predicted distance in cm.

Data sheet — one per team, print and hand out

Team: _______________________ · Our bot's speed: _______ cm per second
For each trial, circle what you saw:  too far  /  too short  /  not straight  /  different every time

Worked example — real numbers from a Gotham bot

Every number in this table was actually measured. Use it as your reference for what a good sheet looks like.

3-second run:   38 × 3  − 7   = 107
2-second run:   38 × 2  − 7   =  69
subtract:       38 × 3 − 38 × 2  =  38      <-- the −7 cancels

What success looks like today

• Every team has five rows filled in. That is the whole target.
• The gap column gets smaller down the page. Not perfectly, not for everyone — but the trend should be visible and they should be able to say why.
• Every team can state their bot's cm per second and that it differs from the team next to them.
• Nobody is troubleshooting a soccer match. If a bot drives straight for 5 seconds and lands where predicted.

How this feeds Tuesday exactly like matches would have

Tuesday's lesson needs a scatter plot, two points, a slope, an intercept and a residual. This lab gives all five:

If the bots will not move at all

Then it is a technical fault, not a math problem. Work down this list, fastest check first:

• Do the LEDs show a number? If not, the program did not flash. Re-copy the file to the micro:bit.
• Fresh batteries, and the Cutebot's own power switch ON. This is the single most common cause.
• Is the Cutebot Pro extension in the project? Without it the drive blocks do nothing.