Python with
Tello

Start with a problem

Put two 30 cm tape marks on the floor. Show 30 and 0.30 on cards. Which value should each robot receive?

A named value lets us change the mission once. A unit conversion prevents the same number from requesting very different distances: Tello distance commands use centimetres; S1 distance commands use metres.

A bare number such as 30 hides its unit. Repeating that number in several commands makes a later route change easy to miss. A variable name documents the quantity, but a name alone does not convert it.

Read, predict, trace

Assignment stores a value under a name. Multiplying metres by 100 produces centimetres. int(round(...)) makes the whole-centimetre command explicit; the supplied distances have exact whole-centimetre targets.

• variable: a name for a value
• unit: what a number measures
• conversion: express the same quantity in another unit

distance_m = 0.30
distance_cm = int(round(distance_m * 100))
print(distance_cm, distance_m)

30 0.3

Practice before you run

These are formative practice prompts. A revealed or assisted answer stays practice; it is not a completed LMS lesson.

print(20 / 100)

length_m = 0.40
print(int(round(length_m * 100)))

leg_m = 0.25
print(int(round(leg_m * 100)), leg_m)

duration_ms = 250
print(duration_ms / 1000)

Build your version

Complete command_units(distance_m). Valid inputs are 0.20 to 0.80 metres, in whole centimetres. Return (Tello centimetres, S1 metres). This function only prepares values; it does not connect to a robot.

def command_units(distance_m):
    return (None, None)

print(command_units(0.4))

assert command_units(0.2) == (20, 0.2)
assert command_units(0.4) == (40, 0.4)
assert command_units(0.8) == (80, 0.8)

• Explain this goal with a concrete input and state trace: Convert a planned distance in metres into Tello centimetres and S1 metres, and explain why both commands represent the same target.
• Modify the starter, pass the public tests, and add one meaningful new case with predicted and observed results.
• Present a labelled artifact from the robot experiment or a declared simulation, with a limitation and an independent changed-context explanation.

Explain and transfer

Why would sending the unlabelled number 30 to both robots be a bad mission specification?

Convert a camera delay in milliseconds to seconds. Explain which unit belongs at the API boundary.

Save your code, prediction, actual result and one limitation. Label a command-log demonstration as simulated. Ask your tutor for a fresh review around day 2 and day 7, adjusted to your needs.

Start with a problem

Show a mission with a clear lane but a low battery, then a charged robot with a blocked lane. Ask which one may start.

The same program needs different behaviour when its inputs change. Combining conditions makes the mission rule explicit and testable before motion.

Starting unconditionally ignores the inputs. Checking only one condition misses the other. A class battery threshold is a teaching policy, not a manufacturer guarantee.

Read, predict, trace

if chooses a branch. >= includes the boundary. A and B is True only when both are True. Use a 40% class preflight rule for Tello; classroom clearance still comes from the supervising person.

• condition: a True/False test
• boundary: the exact threshold
• and: both tests must pass

battery = 40
clear = False
if battery >= 40 and clear:
    print("go")
else:
    print("stop")

stop

Practice before you run

These are formative practice prompts. A revealed or assisted answer stays practice; it is not a completed LMS lesson.

print(40 > 40)

battery = 41
clear = True
print(battery >= 40 and clear)

battery = 39
print("go" if battery >= 40 and True else "stop")

print("enter" if 12 >= 12 and False else "wait")

Build your version

Write permit(battery, clear). Return "go" only for a battery of at least 40 AND a clear lane; otherwise return "stop". Inputs here are a numeric percentage and a boolean.

def permit(battery, clear):
    return "stop"

print(permit(40, True))

assert permit(39, True) == "stop"
assert permit(40, True) == "go"
assert permit(41, False) == "stop"
assert permit(90, True) == "go"

• Explain this goal with a concrete input and state trace: Implement and test a two-condition start rule, including values below, at and above the threshold.
• Modify the starter, pass the public tests, and add one meaningful new case with predicted and observed results.
• Present a labelled artifact from the robot experiment or a declared simulation, with a limitation and an independent changed-context explanation.

Explain and transfer

Why can the same code choose a different branch without being rewritten?

Design a library door rule using age and an adult permission flag. Include the exact age boundary.

Save your code, prediction, actual result and one limitation. Label a command-log demonstration as simulated. Ask your tutor for a fresh review around day 2 and day 7, adjusted to your needs.

Start with a problem

Show a four-leg square patrol. Ask students to change every leg from 30 to 40 cm, then to predict what an indented turn does.

One loop body describes a repeated patrol step. Changing the count or one parameter changes the repeated behaviour consistently.

Four copied blocks can work, but editing three and missing the fourth changes the route. A loop repeats only the indented body; a turn after the loop happens once.

Read, predict, trace

for visits each item in an iterable. range(4) provides 0, 1, 2, 3. Each iteration of a square patrol moves forward and turns 90 degrees; code after the loop runs once.

• iteration: one pass through the body
• range: integers with an excluded stop
• indentation: which lines belong to the body

for leg in range(2):
    print("move", leg)
    print("turn")
print("done")

move 0
turn
move 1
turn
done

Practice before you run

These are formative practice prompts. A revealed or assisted answer stays practice; it is not a completed LMS lesson.

print(list(range(3)))

for leg in range(3):
    print("move")
print("land")

count = 0
for leg in range(4):
    count = count + 2
print(count)

for photo in range(2):
    print("save")
print("close")

Build your version

Complete square_commands(sides). Return alternating "move" and "turn" strings, once per side. The function prepares a plan; the real square demo always uses four sides.

def square_commands(sides):
    commands = []
    # Repeat a move and a turn for each side.
    return commands

print(square_commands(4))

assert square_commands(0) == []
assert square_commands(1) == ["move", "turn"]
assert square_commands(4) == ["move", "turn"] * 4

• Explain this goal with a concrete input and state trace: Trace range(4) and put both move and turn inside the repeated body.
• Modify the starter, pass the public tests, and add one meaningful new case with predicted and observed results.
• Present a labelled artifact from the robot experiment or a declared simulation, with a limitation and an independent changed-context explanation.

Explain and transfer

Which edit changes all four legs, and which indentation error would produce four moves but only one turn?

Plan five photograph-and-log actions, followed by one final upload. Explain why upload belongs outside the loop.

Save your code, prediction, actual result and one limitation. Label a command-log demonstration as simulated. Ask your tutor for a fresh review around day 2 and day 7, adjusted to your needs.

Start with a problem

Hold back a marker, then reveal it at an unpredictable time. Ask how many checks the program should make.

The stopping point depends on incoming evidence rather than a fixed route length. A while condition expresses that dependency; a check budget prevents waiting forever.

A fixed for loop may keep checking after success. A while loop with an unchanged old reading cannot notice a new marker. The same behaviour can also be expressed with for and break; choose the form that makes the stop rule clearest.

Read, predict, trace

while checks its condition before each pass. Update progress and read new evidence inside the body. Stop on success or when the maximum checks are used. A sleep spaces samples; it is not a new sensor reading.

• poll: ask for a new reading
• stale: a previously captured reading
• budget: the maximum checks allowed

readings = [False, False, True]
checks = 0
found = False
while not found and checks < 3:
    found = readings[checks]
    checks += 1
print(checks, found)

3 True

Practice before you run

These are formative practice prompts. A revealed or assisted answer stays practice; it is not a completed LMS lesson.

count = 0
while count < 2:
    count += 1
print(count)

values = [False, True, False]
i = 0
found = False
while not found and i < 3:
    found = values[i]
    i += 1
print(i, found)

values = [False, False, False]
i = 0
found = False
while not found and i < 2:
    found = values[i]
    i += 1
print(i, found)

pages = ["busy", "ready", "ready"]
i = 0
while i < len(pages):
    state = pages[i]
    i += 1
    if state == "ready":
        break
print(i)

Build your version

Complete first_ready(readings, max_checks). Consume at most max_checks available booleans. Return (checks_used, found). Empty inputs and zero budget return (0, False). Recorded inputs simulate fresh polls; this is not an obstacle detector.

def first_ready(readings, max_checks):
    checks = 0
    found = False
    # Update both variables from the next reading.
    return checks, found

print(first_ready([False, True], 4))

assert first_ready([False, True, False], 3) == (2, True)
assert first_ready([False, False, True], 2) == (2, False)
assert first_ready([True], 0) == (0, False)
assert first_ready([], 4) == (0, False)

• Explain this goal with a concrete input and state trace: Explain and implement both a success exit and an exhausted-budget exit, refreshing the input each pass.
• Modify the starter, pass the public tests, and add one meaningful new case with predicted and observed results.
• Present a labelled artifact from the robot experiment or a declared simulation, with a limitation and an independent changed-context explanation.

Explain and transfer

Why does repeating a condition on one old reading fail to detect a new event?

Monitor a print-job queue. Describe what is refreshed, what counts as success and what happens if the budget expires.

Save your code, prediction, actual result and one limitation. Label a command-log demonstration as simulated. Ask your tutor for a fresh review around day 2 and day 7, adjusted to your needs.

Start with a problem

Give the robot a three-leg route, then swap the first and last distance cards without changing the movement code.

An ordered collection keeps route data separate from the code that executes each leg. A growing list also preserves multiple observations instead of overwriting one value.

Three separate variables require separate handling. Reassigning one variable loses the previous observation. A dictionary is better for named fields in one reading; a list is useful for the order of many readings.

Read, predict, trace

A list preserves item order. Index 0 selects the first item and -1 selects the last. append adds one item at the end; iterating reads each route value in order.

• index: an item position
• append: add at the end
• order: the sequence is meaningful

route_cm = [20, 30]
route_cm.append(40)
print(route_cm[0], route_cm[-1], sum(route_cm))

20 40 90

Practice before you run

These are formative practice prompts. A revealed or assisted answer stays practice; it is not a completed LMS lesson.

print([25, 35, 45][0])

log = [20]
log.append(30)
print(log)

route = [20, 40, 30]
print(route[1], route[-1])

playlist = ["intro", "theme"]
playlist.append("end")
print(playlist[1])

Build your version

Return (number_of_legs, total_cm, final_leg_cm) from route_summary(route_cm). An empty route returns (0, 0, None). These are distances, not flight coordinates.

def route_summary(route_cm):
    return (0, 0, None)

print(route_summary([20, 30, 40]))

assert route_summary([20, 30, 40]) == (3, 90, 40)
assert route_summary([50]) == (1, 50, 50)
assert route_summary([]) == (0, 0, None)

• Explain this goal with a concrete input and state trace: Edit an ordered route and append observations without losing earlier values.
• Modify the starter, pass the public tests, and add one meaningful new case with predicted and observed results.
• Present a labelled artifact from the robot experiment or a declared simulation, with a limitation and an independent changed-context explanation.

Explain and transfer

Why does append preserve more evidence than repeatedly assigning reading = new_value?

Store a playlist or a sequence of experiment readings and explain when order changes the meaning.

Save your code, prediction, actual result and one limitation. Label a command-log demonstration as simulated. Ask your tutor for a fresh review around day 2 and day 7, adjusted to your needs.

Start with a problem

Show [70, 80] and ask whether 70 is battery or height. Replace it with a labelled record.

Named fields keep unlike measurements distinguishable. A list of dictionaries represents many observations with the same named columns.

A positional list depends on everyone remembering the same field order. A dictionary gives fields names; it does not validate units or prove that a sensor actually measured the value.

Read, predict, trace

A dictionary maps a key to a value. Reusing the same key replaces its value. Separate reading dictionaries belong in a list when you need a time sequence. None marks a missing quantity; zero is a measured value.

• key: a field name
• record: one observation with named fields
• missing: not measured, rather than zero

reading = {"battery_pct": 70, "height_cm": 80}
reading["height_cm"] = 85
print(reading["battery_pct"], reading["height_cm"])

70 85

Practice before you run

These are formative practice prompts. A revealed or assisted answer stays practice; it is not a completed LMS lesson.

print({"height_cm": 90, "battery_pct": 60}["battery_pct"])

r = {"count": 1}
r["count"] = 4
print(r["count"])

r = {"robot": "s1", "height_cm": None}
print(r["height_cm"] is None)

weather = {"temp_c": 0, "rain_mm": None}
print(weather["temp_c"] is None)

Build your version

make_record(robot, sample, battery_pct, height_cm) returns a new dictionary with exactly those four keys. Missing measurements stay None. Call it twice and show that the dictionaries are separate objects.

def make_record(robot, sample, battery_pct, height_cm):
    return {}

print(make_record("s1", 1, None, None))

a = make_record("tello", 1, 80, 90)
b = make_record("s1", 2, None, None)
assert a == {"robot": "tello", "sample": 1, "battery_pct": 80, "height_cm": 90}
assert b["height_cm"] is None
assert a is not b
assert set(b) == {"robot", "sample", "battery_pct", "height_cm"}

• Explain this goal with a concrete input and state trace: Build a record with meaningful keys, distinguish missing from zero and preserve successive records.
• Modify the starter, pass the public tests, and add one meaningful new case with predicted and observed results.
• Present a labelled artifact from the robot experiment or a declared simulation, with a limitation and an independent changed-context explanation.

Explain and transfer

Why does putting height_cm in a key help readers, and what does that key still fail to guarantee?

Design a weather record with one true zero and one missing value, and explain the difference.

Save your code, prediction, actual result and one limitation. Label a command-log demonstration as simulated. Ask your tutor for a fresh review around day 2 and day 7, adjusted to your needs.

Start with a problem

Ask for a short patrol, then a longer one. Should the student copy the whole program or give the same move a different input?

A function gives a meaningful name to reusable behaviour. Parameters vary the input. Return values let calculations be tested before a hardware method performs an action.

Copying movement code creates multiple places to fix. Printing a converted distance does not return it to another function. tello.move_forward(...) is a method on a particular device object; a plain conversion function needs no device.

Read, predict, trace

def defines a function; calling it runs its body. return sends a value to the caller. A method is accessed through an object, as in samples.append(value) or drone.move_forward(cm). These are both calls, but their owners and effects differ.

• parameter: a name for a supplied input
• return: send a result to the caller
• method: a function accessed through an object

def to_cm(metres):
    return int(round(metres * 100))

commands = []
commands.append(to_cm(0.4))
print(commands)

[40]

Practice before you run

These are formative practice prompts. A revealed or assisted answer stays practice; it is not a completed LMS lesson.

def leg():
    print("move")
print("ready")

def double(x):
    return x * 2
print(double(3))

def to_cm(m):
    return int(round(m * 100))
print(to_cm(0.25) + to_cm(0.35))

def seconds(milliseconds):
    return milliseconds / 1000
print(seconds(500))

Build your version

out_and_back(distance_m) returns [("forward", cm), ("back", cm)]. The parameter is 0.20-0.80 m in whole centimetres. Use a conversion function; do not import a robot library or send motion.

def to_cm(distance_m):
    return 0

def out_and_back(distance_m):
    return []

print(out_and_back(0.3))

assert to_cm(0.2) == 20
assert out_and_back(0.3) == [("forward", 30), ("back", 30)]
assert out_and_back(0.6) == [("forward", 60), ("back", 60)]

• Explain this goal with a concrete input and state trace: Separate a pure conversion function from an action method, and explain what each call returns or changes.
• Modify the starter, pass the public tests, and add one meaningful new case with predicted and observed results.
• Present a labelled artifact from the robot experiment or a declared simulation, with a limitation and an independent changed-context explanation.

Explain and transfer

How is calling to_cm(0.3) different from calling drone.move_forward(30)?

Write a reusable photo filename function; keep generating the name separate from saving a file.

Save your code, prediction, actual result and one limitation. Label a command-log demonstration as simulated. Ask your tutor for a fresh review around day 2 and day 7, adjusted to your needs.

Start with a problem

Lay out a 2 by 3 paper inspection grid. Students predict whether two loops produce five or six inspections.

Two dimensions require visiting every row/column combination. An inner loop handles columns for each row selected by the outer loop.

Adding row and column counts does not enumerate their combinations. A logical grid coordinate is not automatically a flight or wheel command; a route planner must define the geometry.

Read, predict, trace

For each outer row, the inner column loop starts again. A 2-row, 3-column grid has 2 * 3 cells. A physical scan can traverse alternate rows in opposite directions to avoid extra return trips.

• outer loop: chooses one row
• inner loop: visits columns in that row
• coordinate: a row/column pair

for row in range(2):
    for col in range(2):
        print(row, col)

0 0
0 1
1 0
1 1

Practice before you run

These are formative practice prompts. A revealed or assisted answer stays practice; it is not a completed LMS lesson.

print(2 * 3)

n = 0
for row in range(2):
    for col in range(3):
        n += 1
print(n)

for row in range(1):
    for col in range(3):
        print(row, col)

for day in range(2):
    for sensor in ["A", "B"]:
        print(day, sensor)

Build your version

grid_cells(rows, cols) returns row-major (row, col) pairs. Valid inputs are nonnegative integers. Test zero rows and zero columns. The result is a checklist; it must not move a robot.

def grid_cells(rows, cols):
    cells = []
    return cells

print(grid_cells(2, 3))

assert grid_cells(2, 3) == [(0, 0), (0, 1), (0, 2), (1, 0), (1, 1), (1, 2)]
assert grid_cells(0, 3) == []
assert grid_cells(2, 0) == []

• Explain this goal with a concrete input and state trace: Enumerate each grid cell exactly once and distinguish logical coordinates from physical travel.
• Modify the starter, pass the public tests, and add one meaningful new case with predicted and observed results.
• Present a labelled artifact from the robot experiment or a declared simulation, with a limitation and an independent changed-context explanation.

Explain and transfer

Why is the number of inspections rows times columns, and why are grid labels insufficient to command a physical robot?

Schedule each sensor on each day; explain which loop restarts and how many readings are planned.

Save your code, prediction, actual result and one limitation. Label a command-log demonstration as simulated. Ask your tutor for a fresh review around day 2 and day 7, adjusted to your needs.

Start with a problem

Close a program that only printed its results. Ask what evidence the next class can inspect.

A saved table survives program exit and can be reopened by another tool. A stable schema and provenance label make the measurements interpretable.

A list in memory disappears when the process ends. Copying only successful trials creates a biased record. The S1 Lab cannot write a laptop CSV, so the observer records physical trials through the supplied laptop tool.

Read, predict, trace

CSV stores one record per row and named columns in a header. DictWriter uses a field list to align values. CSV text is not typed data: numeric strings need conversion when read back.

• schema: expected columns and meanings
• provenance: where a value came from
• CSV: comma-separated tabular text

import csv
from io import StringIO
text = "robot,target_cm\ntello,30\ns1,30\n"
rows = list(csv.DictReader(StringIO(text)))
print(len(rows), rows[0]["target_cm"])

2 30

Practice before you run

These are formative practice prompts. A revealed or assisted answer stays practice; it is not a completed LMS lesson.

import csv
from io import StringIO
r = list(csv.DictReader(StringIO("x\n3\n4\n")))
print(len(r))

import csv
from io import StringIO
r = next(csv.DictReader(StringIO("cm\n30\n")))
print(type(r["cm"]).__name__)

import csv
from io import StringIO
r = list(csv.DictReader(StringIO("cm\n20\n35\n")))
print(sum(int(x["cm"]) for x in r))

import csv
from io import StringIO
r = list(csv.DictReader(StringIO("day,rain_mm\nMon,0\nTue,2\n")))
print(r[0]["rain_mm"])

Build your version

Read CSV text with header target_cm and return the numeric targets in order. Inputs contain valid integer strings. Then use record_trial.py to save a complete or aborted physical trial with origin=measured; do not edit the synthetic fixture to masquerade as measurements.

import csv
from io import StringIO

def read_targets(text):
    return []

print(read_targets("target_cm\n30\n40\n"))

assert read_targets("target_cm\n30\n40\n") == [30, 40]
assert read_targets("target_cm\n") == []
assert read_targets("target_cm\n0\n") == [0]

• Explain this goal with a concrete input and state trace: Save and reload trial records with field names, units, origin and unsuccessful outcomes.
• Modify the starter, pass the public tests, and add one meaningful new case with predicted and observed results.
• Present a labelled artifact from the robot experiment or a declared simulation, with a limitation and an independent changed-context explanation.

Explain and transfer

Why does a saved row need both an outcome and a measurement method?

Log a weather observation with origin and units so another student can read it a week later.

Save your code, prediction, actual result and one limitation. Label a command-log demonstration as simulated. Ask your tutor for a fresh review around day 2 and day 7, adjusted to your needs.

Start with a problem

Show an empty distance measurement and the number 0. Ask whether filling every blank with zero would improve the robot.

A machine-readable file can still contain unusable or missing values. Explicit conversion and reason flags keep cleaning decisions visible and prevent invented measurements.

Replacing missing distances with zero manufactures a huge error. Deleting all failures makes the robot appear better. Preserve the raw file and write a separate audit of every row.

Read, predict, trace

pd.to_numeric(errors="coerce") turns invalid numeric text into missing data. isna detects it. A boolean mask selects eligible records; the excluded rows and their reasons must remain inspectable.

• DataFrame: a table with named columns
• mask: one True/False choice per row
• coerce: convert invalid numeric text to missing

import pandas as pd
s = pd.to_numeric(pd.Series(["30", "bad", "0"]), errors="coerce")
print(int(s.isna().sum()), int(s.dropna().sum()))

1 30

Practice before you run

These are formative practice prompts. A revealed or assisted answer stays practice; it is not a completed LMS lesson.

import pandas as pd
print(pd.isna(None))

import pandas as pd
s = pd.to_numeric(pd.Series(["20", "oops", "40"]), errors="coerce")
print(int(s.notna().sum()))

import pandas as pd
s = pd.Series([0.0, None, 30.0])
print(int(s.isna().sum()), int((s == 0).sum()))

import pandas as pd
s = pd.to_numeric(pd.Series(["0", "", "2"]), errors="coerce")
print(int(s.notna().sum()))

Build your version

clean_distances(values) converts strings with pandas, drops missing or negative values, and returns the remaining numeric values in input order. This tiny exercise does not remove rows from the trial audit. In the full experiment, outcome counts retain every trial.

import pandas as pd

def clean_distances(values):
    return []

print(clean_distances(["30", "", "-2", "0"]))

assert clean_distances(["30", "", "-2", "0"]) == [30, 0]
assert clean_distances(["bad", None]) == []
assert clean_distances([]) == []
assert clean_distances(["12.5"]) == [12.5]

• Explain this goal with a concrete input and state trace: Convert numeric text, identify missing/impossible values and preserve unsuccessful trial counts.
• Modify the starter, pass the public tests, and add one meaningful new case with predicted and observed results.
• Present a labelled artifact from the robot experiment or a declared simulation, with a limitation and an independent changed-context explanation.

Explain and transfer

Why can keeping a measured zero and excluding a missing value both be correct?

Clean a rainfall column without turning an unobserved day into a dry day.

Save your code, prediction, actual result and one limitation. Label a command-log demonstration as simulated. Ask your tutor for a fresh review around day 2 and day 7, adjusted to your needs.

Start with a problem

Show two settings with the same average error but different spreads. Ask which evidence is missing from a single average.

Grouping compares like trials while counts and spread reveal how much evidence supports a summary. A graph with individual points exposes variation hidden by a mean.

One impressive run is weak evidence. Pooling robots hides different mechanics. Comparing slow runs on one surface with fast runs on another confounds speed with surface.

Read, predict, trace

Signed error is measured minus target; absolute error measures miss size. Group by robot and condition. Count all trial outcomes, then calculate distance statistics only for complete valid measurements. Plot every valid point and report how many trials were excluded.

• group: comparable rows
• absolute error: size of the miss
• confound: another changing factor
• spread: variation between trials

import pandas as pd
df = pd.DataFrame({"setting": ["slow", "slow", "fast", "fast"], "error_cm": [1, -1, 4, -4]})
df["abs_error"] = df["error_cm"].abs()
print(df.groupby("setting")["abs_error"].mean().to_dict())

{'fast': 4.0, 'slow': 1.0}

Practice before you run

These are formative practice prompts. A revealed or assisted answer stays practice; it is not a completed LMS lesson.

print((4 + -4) / 2)

errors = [3, -5]
print(sum(abs(e) for e in errors) / len(errors))

import pandas as pd
df = pd.DataFrame({"condition": ["a", "a", "b"], "error": [2, 4, 9]})
print(float(df.groupby("condition")["error"].mean()["a"]))

waits = [1, 1, 7]
print(max(waits) - min(waits))

Build your version

error_summary(target_cm, observed_cm) returns count, mean signed error, mean absolute error and range of signed errors. The observations are complete, valid numbers. An empty list returns count 0 and None for the three statistics. Then inspect the full grouped CSV and plot from analyze_trials.py.

def error_summary(target_cm, observed_cm):
    return {"n": 0, "bias_cm": None, "mae_cm": None, "range_cm": None}

print(error_summary(30, [29, 31]))

assert error_summary(30, [29, 31]) == {"n": 2, "bias_cm": 0, "mae_cm": 1, "range_cm": 2}
assert error_summary(30, []) == {"n": 0, "bias_cm": None, "mae_cm": None, "range_cm": None}
assert error_summary(30, [34])["mae_cm"] == 4

• Explain this goal with a concrete input and state trace: Compare repeated, paired settings within one robot using counts, absolute error, spread and outcome rate without claiming more than the sample supports.
• Modify the starter, pass the public tests, and add one meaningful new case with predicted and observed results.
• Present a labelled artifact from the robot experiment or a declared simulation, with a limitation and an independent changed-context explanation.

Explain and transfer

Why must a report show trial counts and unsuccessful runs alongside mean error?

Compare two queue policies with repeated waits, documenting the workload and order rather than showing only the best wait.

Save your code, prediction, actual result and one limitation. Label a command-log demonstration as simulated. Ask your tutor for a fresh review around day 2 and day 7, adjusted to your needs.

Start with a problem

Give a client request: inspect four marked stations and explain whether a revised setting improved reliability. Students choose the code structures before seeing a solution.

Real tasks combine planning, execution and evidence. Each structure should solve a named problem: lists order stations, dictionaries label readings, loops repeat or wait, and functions isolate reusable decisions.

A moving robot is not proof that every station was inspected. A passing public test is not proof of reasoning or physical reliability. A graph of synthetic data is not a hardware result.

Read, predict, trace

Separate mission data from control logic and recorded evidence. Validate the complete route before executing any leg. Test a normal case, an empty route and a refused value. Use a fixed patrol for known stations and a bounded wait only when completion depends on evidence.

• requirement: an observable success condition
• integration: parts working together
• reproducibility: another person can rerun the analysis

route_cm = [20, 30]
records = []
for station, distance_cm in enumerate(route_cm):
    records.append({"station": station, "target_cm": distance_cm})
print(len(records), records[1]["target_cm"])

2 30

Practice before you run

These are formative practice prompts. A revealed or assisted answer stays practice; it is not a completed LMS lesson.

route = [20, 30, 40]
print(len(route))

rows = []
for station in range(2):
    rows.append({"station": station})
print(rows[-1]["station"])

route = [20, 0, 30]
print(all(20 <= x <= 80 for x in route))

queue = ["A", "B"]
receipts = []
for job in queue:
    receipts.append({"job": job, "done": False})
print(receipts[1]["done"])

Build your version

mission_plan(route_cm) validates the entire route before building any records. Accept only exact int values 20-80 cm (not booleans), at most four legs and at most 200 cm total; otherwise raise ValueError. Return one {station, target_cm} dictionary per leg. Then demonstrate a reviewed fixed-route program using the supplied robot runner, record every trial and write a claim supported by its evidence.

def mission_plan(route_cm):
    return []

print(mission_plan([20, 30]))

assert mission_plan([20, 30]) == [{"station": 0, "target_cm": 20}, {"station": 1, "target_cm": 30}]
assert mission_plan([]) == []
for route in ([0], [81], [True], [20.5], ["30"], [80, 80, 80], [20] * 5):
    try:
        mission_plan(route)
    except ValueError:
        pass
    else:
        raise AssertionError("invalid route accepted: " + repr(route))

• Explain this goal with a concrete input and state trace: Choose and justify each structure, demonstrate bounded behaviour and present reproducible evidence with limitations.
• Modify the starter, pass the public tests, and add one meaningful new case with predicted and observed results.
• Present a labelled artifact from the robot experiment or a declared simulation, with a limitation and an independent changed-context explanation.

Explain and transfer

Choose one loop, one collection and one function. Explain the requirement each solves, an alternative, and a case where you would choose differently.

Apply the plan-execute-record separation to a photo-processing queue. State which claims transfer and which require new evidence.

Save your code, prediction, actual result and one limitation. Label a command-log demonstration as simulated. Ask your tutor for a fresh review around day 2 and day 7, adjusted to your needs.