# This is not autonomy. It is a guess with a timer.
drive(SPEED, SPEED)
time.sleep(3)
drive(-SPEED, SPEED)
time.sleep(0.5)
drive(SPEED, SPEED)
time.sleep(3)

# This is autonomy. It reads the world and decides.
while True:
    cm = read_distance()
    if cm > 0 and cm < STOP_CM:
        back_away()
    else:
        drive(SPEED, SPEED)

'F' → Fullscreen

The Two Events

Event 1: The Obstacle Course — graded

• A marked lane with obstacles placed across it, and a finish line.
• Your rover starts on a button press and runs with nobody touching it.
• Several teams run at once, so you get plenty of attempts rather than one nervous go.
• Recorded each run: whether it finished, how long it took, and how many times it made contact with an obstacle.

Obstacles get moved between rounds. A rover that memorized the course will fail, and that is the point — the event is testing whether it senses, not whether it remembers.

Event 2: The Sumo Ring — not graded

• Two rovers, one circle. Last one still inside wins.
• Refereed by hand. No line sensors needed.
• Run after the graded event, on the last day.

This is deliberately not part of your grade. Whether you win a wrestling match depends mostly on who you were drawn against, which is a poor way to measure your engineering. Build for the course; enjoy the ring.

Writing Your Success Criteria

Every team writes its own. A success criterion has to be something you can check and get a yes or no — not an opinion about how good the robot is.

Not success criteria:

• "The rover works well"
• "It avoids obstacles"
• "It is fast"

Success criteria:

• "The rover does not move until the button is pressed"
• "It stops before touching an obstacle in at least 8 of 10 approaches"
• "Placed in a corner, it gets out within 15 seconds"
• "It crosses the course in under 45 seconds with no contacts"
• "The screen always shows whether it is driving or blocked"

The difference is that you can run the rover and find out. That is what makes Event 1 gradeable, and it is what your final evaluation gets measured against — so write criteria you are willing to be judged on.

The Complexity Bar

Your rover's program must genuinely use what this unit taught. Specifically, all four of these:

• A sense–decide–act loop. The rover reads the distance and chooses what to do, every time round.
• Sensing that actually drives the decision. Moving an obstacle changes the behavior.
• Functions with parameters — drive(left, right), read_distance(), and at least one behavior of your own like back_away().
• Named constants you tuned, with the tuning recorded in your journal.

A rover that drives a fixed timed sequence does not meet this bar, however neatly it is written and however often it happens to finish. Neither does one whose sensor is read but ignored. If moving the obstacles does not change what your robot does, it is not sensing.

One specific thing to get right: your distance function returns -1 when nothing is in range, and -1 is less than any threshold you pick. Guard it, or your rover will back away from empty space forever.

The MYP Criteria, In This Project

• A — Inquiring and Analysing: what your rover needs to do and why, three real robot drive or sensing approaches you looked at, and your success criteria.
• B — Developing Ideas: more than one chassis idea considered, the one you chose and why, and an accurate drawing of it — your cutting file counts.
• C — Creating the Solution: the build and the code, your work plan, and an honest account of what you changed once real testing started.
• D — Evaluating: your obstacle course data measured against your own success criteria, what you would change, and your individual reflection.

Criterion B is where a laser-cut chassis earns real marks: a vector drawing with dimensions is exactly the kind of planning artifact the criterion asks for. Criterion D is where Event 1 earns them — you will have actual numbers rather than an impression.

Task Journal

One entry per work session: what you did, who did it, what went wrong, what is next. Fill it in as you go. A journal reconstructed the night before is obvious to read and worth very little.

This project has one extra journal requirement. Every time you change a tuning constant, log the old value, the new value, and what actually happened. Change one at a time. Four interacting numbers changed together tell you nothing about which one mattered.

Timeline

The stock baseplate from the kit is a perfectly good chassis. A custom cut one is an upgrade, not a requirement — so a cutting problem in session 3 or 4 cannot sink your project.

What You'll Turn In

• Design packet — problem and need, the three approaches you researched, success criteria, chassis drawing, feature plan
• Your code, as the file that actually ran in Event 1
• Obstacle course data — your runs, times, and contacts, checked against your success criteria
• Tuning log — what you changed, and what it did
• Task journal — kept throughout, one entry per session
• Individual reflection — written by you, not by your group

Commence Project