Stopping Is Not the Same as Being Stopped

Overview

Last lab, your robot used its touch sensor to back into the wall and reset its origin. Today you’ll use that same reliable starting point to run an experiment. You’ll drive forward a short distance and stop — two different ways — and measure which way is more consistent. The two ways of “stopping” are not the same, and your own data is going to prove it.

By the end of this activity you will be able to:

• Explain the difference between braking a motor and letting it go neutral.
• Reuse back_until_pressed() to start every trial from the same reset origin.
• Run a controlled experiment: same move, two stopping methods, five trials each.
• Use your own data to decide which method is more consistent in distance and direction.

New This Time: Brake vs. Neutral

motor(0, 0);   // BRAKE: actively holds the motor at zero, resisting motion
motor(3, 0);

ao();          // "all off": cuts power; motors go NEUTRAL and COAST

motor(0, 0);
motor(3, 0);
msleep(50);    // give the motors a moment to settle and lock

Phase 1 — Activate: Two Ways to Stop a Bike

Picture riding a bike to a line on the ground. You could squeeze the brakes and stop right on it — or you could just stop pedaling and coast, hoping you roll to a stop at the right spot. One is controlled. The other depends on your speed, the ground, and luck.

A coasting bike and a braking bike can both stop. Why is the braking one more predictable? Connect this to a robot that needs to stop in the same place every run.

Phase 2 — Concept: Consistency and Evidence

Consistency Is a Measurable Thing

A robot that drives “about 6 inches” isn’t good enough for a competition — you need it to drive the same distance every single time. Consistency means the results cluster tightly together. You can’t tell how consistent something is from one run; you have to run it several times and look at the spread.

An Experiment Compares One Change

To test which stopping method is better, you change only the stop — everything else stays the same. Same start (the wall reset), same forward move, same five trials. The only difference is brake vs. coast. That’s a fair experiment: when one thing changes and the rest is held still, you know the difference is caused by that one thing.

Why can’t you judge which stopping method is more consistent from just one run of each? What does running five trials let you see that one run hides?

Phase 3 — Plan

The Experiment

Predict First

Before you run anything: which version — coast or brake — do you think will be more consistent in distance? Which will stay straighter? Why?

Set Your Forward Distance

You’ll reuse your drive_forward() function and pick a time that travels roughly 6 inches. What time will you start with?

Phase 4 — Build & Run the Experiment

The Two Versions

Both versions are identical except for how they stop. Build Version A first, run your five trials, then change only the stop to make Version B and run five more. Keep the prototype above main() and the definition below, as always.

// Unit 2, Big Idea 2: Brake vs. Coast
// Name: _______________________   Date: ___________

#include <kipr/wombat.h>

int x_position = 0;
int y_position = 0;

void back_until_pressed();   // from last lab: backs into wall, resets origin
void drive_forward();        // drives forward ~6 inches (you set the time)

int main()
{
	back_until_pressed();    // reset to a known zero at the wall
	drive_forward();         // move forward about 6 inches

	// ---- VERSION A: COAST (neutral) ----
	ao();                    // cut power: motors coast to a stop

	// ---- VERSION B: BRAKE (active hold) ----
	// Comment out the ao() above and use these three lines instead:
	// motor(0, 0);
	// motor(3, 0);
	// msleep(50);            // let the brake settle and hold

	return 0;
}

void drive_forward()
{
	motor(0, 50);
	motor(3, 50);
	msleep(____);            // your ~6-inch time from Phase 3
}

void back_until_pressed()
{
	while (digital(0) == 0)
	{
		motor(0, -50);
		motor(3, -50);
		msleep(10);
	}
	ao();
	y_position = 0;          // home: reset origin
}

Version A — Coast (ao())

Run five trials. After each, measure the distance the robot traveled forward, and note whether it stayed straight or drifted (and which way).

Version B — Brake (motor(0,0); motor(3,0); msleep(50);)

Change only the stop. Run five more trials and record the same way.

Phase 5 — Analyze Your Data

Now look at your two sets of five. Don’t guess — read what your numbers actually say.

Based on your data: which version looks more consistent in distance? A smaller spread means more consistent.

Based on your data: which version stayed straighter? What did the drift notes show?

Did your data match your Phase 3 prediction? If it surprised you, what surprised you?

Phase 6 — Connect: The AI Literacy Bridge

Today you didn’t take anyone’s word for which stop was better — you ran it ten times and let the numbers decide. That’s exactly how real autonomous systems are built. A self-driving car’s braking isn’t shipped because it “seemed fine”; it’s tested thousands of times and measured for consistency. When a system has to do the same thing reliably, engineers gather data on how much it varies — just like you did.

Read each scenario. Think it through, then write your answer.

A robot drives “about 6 inches” but sometimes 5 and sometimes 7. Across a long mission with many moves, why does a small inconsistency on each move become a big problem by the end?

You proved which stop was better with data instead of opinion. Why is “the data shows it” more trustworthy than “it felt better” when building something that has to work every time?

Phase 7 — Individual Reflection

Complete this section on your own.

1. Explain the difference between motor(0,0) and ao() in your own words. Which one brakes, and which one coasts?

2. Why does coasting tend to make the robot drift off a straight line?

3. What is the msleep(50) after the brake for? What is it NOT for?

4. Complete this in 2–3 sentences: “A reliable robot is built on data, not hope. This means that before I trust a behavior in a real match, I should…”

Extension Challenges

Finished early? Try one or more of these.

Extension A — Does Settle Time Matter?

• Try the brake version with msleep(50), then again with no pause, then with msleep(200).
• Does more settle time change the consistency? What’s the smallest pause that still holds well?

Extension B — Faster Speed, Bigger Difference?

• Run both versions again at a higher motor power. Does coasting get even less consistent when the robot is moving faster? Why would that be?

Extension C — Stack Five Moves

• Make the robot do five forward-and-brake moves in a row in one run. Does the braking version land where you’d predict after all five? Compare to coasting.

Extension D — Build a “stop_and_hold” Function

• Wrap the brake-and-settle lines into their own function (prototype above, definition below) so you can reuse one clean call every time you stop.
• What did you name it? Where would you use it across the whole game?

Extension E — Check It Against Reality

• Look up one real, credible source (a robotics or automotive article/spec sheet — not a forum post) about why sudden braking causes more positional error than gradual braking. Note where you found it.
• Log your 5 trial results in a spreadsheet instead of just this table. Does a spreadsheet make the pattern easier to spot than the table did?