The Long Run

Overview

Every lab so far taught you that the real world is imperfect — motors overshoot, turns drift, batteries fade, models are never exact. A short move can hide those errors. But a long run with many steps? The tiny errors pile up until the robot is completely lost. Today’s capstone is the reliability answer: a long, multi-part mission where the robot constantly re-checks reality and wipes out its accumulated error along the way. You’ll touch Botguy and return both cones to the starting box — and stay accurate the whole time by squaring up again and again.

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

• Plan a long, multi-objective run that avoids obstacles.
• Use square-ups as deliberate error-reset checkpoints.
• Combine your whole library into one reliable competition run.
• Explain how re-referencing known features keeps a long run accurate.

Phase 1 — The Mission & Its Rules

The rules that make it hard

• Verify your start: begin with a backward touch (back_until_pressed) against the wall — this confirms you’re really in the starting box and resets your origin before you move.
• Avoid the large cube: there’s a large cube on the pallet right next to the starting box. Your path must not touch it. Plan around it.
• Stay accurate: your run must include at least 6 square-ups, placed as error-reset checkpoints throughout.

Say the mission back in your own words, including the three rules. Why does starting with a backward touch make the whole rest of the run more trustworthy?

Phase 2 — Concept: The Square-Up Is an Error Reset

In your own words, why does error “accumulate” over a long run? How does a square-up reset it?

Phase 3 — Plan: Map the Path

Draw your whole run. Mark the right starting box (drawn for you), Botguy, both cones, and the large cube you must avoid. Sketch the path: out to Botguy, over to the cones, and back to the box — routed clear of the large cube.

Sketch: Botguy, both cones, the large cube to avoid, and your path

Draw on the printed copy, or describe your planned path below.

Phase 4 — Plan: Place Your 6+ Error Resets

Now walk your path and decide where each square-up goes. Good reset points are right before something precise (TOUCHING Botguy, grabbing a cone, entering the box) — so you’re accurate exactly when it matters. List each leg of the run and mark where you reset.

How many square-ups did you plan, and where did you put them? Why did you choose those spots instead of others?

Phase 5 — Build: The Run in main()

Write your run in main(), translating your plan into library calls. Start with the backward touch, then follow your path — and put a square_up() at each reset checkpoint you planned. Scoring is optional here; you can print() milestones if you like, but the real goal is a reliable, accurate run.

#!/usr/bin/python3

# Unit 4, Big Idea 5: The Long Run

# Name: _______________________   Date: ___________

import os, sys
sys.path.append("/usr/lib")
import _kipr as k
from yourname import *     # your full library

def main():
    k.enable_servo(0)
    k.enable_servo(1)

    # ===== VERIFY START =====
    back_until_pressed()       # backward touch: confirm we're in the box, reset origin
    square_up()                # RESET #1 establishes a known heading before we move.

    # ===== LEG 1: to Botguy (avoid the large cube!) =====
    # Drive(...) / Turn(...) around the large cube to Botguy
    square_up()                # RESET #2 squares up before the precise touch.
    # ...touch Botguy...

    # ===== LEG 2: to the first cone =====
    # Drive(...) / Turn(...) to cone 1
    square_up()                # RESET #3
    # ...collect / push cone 1...

    # ===== LEG 3: to the second cone =====
    # Drive(...) / Turn(...) to cone 2
    square_up()                # RESET #4
    # ...collect / push cone 2...

    # ===== LEG 4: back to the starting box =====
    # Drive(...) / Turn(...) toward the box
    square_up()                # RESET #5
    # ...bring the cones into the box...
    square_up()                # RESET #6 provides the final alignment in the box.

main()

Phase 6 — Run It, Then Test Its Reliability

Get it working one leg at a time. Then do the real reliability test: run the whole thing several times from the same start, and see how consistent it is. A reliable run succeeds the same way every time.

How many of your runs fully succeeded? If a run failed, was it because a square-up was missing where you needed one? Where would adding a reset help?

Phase 7 — Connect & Reflect

Your robot succeeded across a long run not by being perfect, but by never trusting its own drift for too long. Every square-up pulled it back to a known truth. This is one of the deepest ideas in reliable autonomy. A spacecraft re-checks its position against the stars. A self-driving car re-locates itself against lane lines and landmarks constantly. A surveyor re-references known benchmarks. None of them assume their internal estimate is still correct — they keep measuring reality and correcting. You just built that same discipline into a robot: act, but keep re-checking the world and resetting your error before it grows.

Complete the reflection on your own.

1. Why does error accumulate over a long run, and why can’t you just “drive more carefully” to avoid it?

2. How does a square-up reset accumulated error? Why did this run need at least six of them?

3. Why is a run that succeeds 4 out of 4 times better than one that scores higher but only works sometimes?

4. Complete in 2–3 sentences: “Reliable systems constantly re-check reality and reset their error. This means that over a long mission, a robot should…”

Extension Challenges

Finished early? Try one or more of these.

Extension A — Remove a Reset

• Delete one of your square-ups and run it several times. Does the run get less reliable? Which reset mattered most?

Extension B — Score It

• Add score tracking with print() like the red-cube run. Touching Botguy and returning cones are worth real points — report your total.

Extension C — Handle a Failure

• What if the robot misses a cone? Sketch a recovery: how could it back up, re-square, and try again instead of continuing blindly?

Extension D — Fewer, Smarter Resets

• Could you succeed with only 4 well-placed resets instead of 6? Where would the most valuable resets be, and why?

Extension E — Splitting the Work

• If you’d built today’s Long Run with a partner instead of solo, how would you split the work into roles — for example, one person tunes Drive/Turn constants while the other plans the reset sequence?
• What collaborative tool (a shared doc, GitHub, a group chat) would help you combine your work without overwriting each other’s changes?