Week 15 Coding Lab: A Robotics Club's Batteries

Part 1 — The Big Picture

This week you learned that a class is a blueprint and each object built from it keeps its own state, that the setup method runs by itself when the class is called, that every value an object should remember is stored on self, and that a method which only prints hands back None. In this lab you put those ideas to work on the programs of an illustrative robotics club. You predict what six short programs print, run them, and study every gap between your prediction and the run. Then you read three broken classes, fix each with the smallest change that works, write a short class of your own, and test a chatbot's answers about the same programs by running the code, because a chatbot predicts likely text and does not run your program.

Time budget: Plan for about 90 minutes.

Part 2 — The Task

Guiding question: For the robotics club's classes, which of these six predictions about which object a method changes, what a method hands back, or how many objects exist will you get wrong, and how will each run show you where a value really lives?

Workshop data: Robotics club programs: six short class programs and three broken programs

Source: Six short Python programs and three broken programs about an illustrative robotics club's batteries, robots, and toolboxes, written for this lab and described in full in Part 4; the club and its robots are invented and describe no real group or person.

• Rows: 9 short programs in all: 6 programs to trace in the first table and 3 broken programs in the second table
• Language: Python 3, run in a free browser runner; no file to download and nothing to install
• Context: an illustrative robotics club with rechargeable batteries, named robots, and shared toolboxes

Part 3 — Materials & Procedure

Tools and materials

• A free browser-based Python runner (an online editor that runs Python 3 with no account and nothing to install), Python Tutor at pythontutor.com for step-by-step visualization, the official Python documentation at docs.python.org, and one approved chatbot used as a pair-programmer whose code the student runs before trusting

Ways of working

• write-run-and-verify
• trace-and-predict-output
• find-and-fix-the-bug

Procedure

1. Open a free browser Python runner in one tab and Python Tutor at pythontutor.com in another. In the runner, delete any sample code so the editor is blank. Tool: A free browser-based Python runner (an online editor that runs Python 3 with no account and nothing to install), Python Tutor at pythontutor.com for step-by-step visualization, the official Python documentation at docs.python.org, and one approved chatbot used as a pair-programmer whose code the student runs before trusting. Check: An empty editor with a Run button and a separate output panel.
2. In the first table in Part 4, write your prediction for each of the six programs before you run anything. Then type the Battery class from the critique prompt in Part 6, and each program as described, into the runner with four spaces in front of every method line and eight in front of every line inside a method, press Run, and copy the output into the Actual output column, one line at a time. Tool: A free browser-based Python runner (an online editor that runs Python 3 with no account and nothing to install), Python Tutor at pythontutor.com for step-by-step visualization, the official Python documentation at docs.python.org, and one approved chatbot used as a pair-programmer whose code the student runs before trusting. Check: Six actual outputs, one per row, each copied line for line from the output panel; at least one is likely to differ from your prediction.
3. Type each broken program from the second table into the runner and press Run. For an error, scroll to the bottom of the error message and copy the error type from its last line. For a program that runs, compare what it printed with what its description says it should print. Tool: A free browser-based Python runner (an online editor that runs Python 3 with no account and nothing to install), Python Tutor at pythontutor.com for step-by-step visualization, the official Python documentation at docs.python.org, and one approved chatbot used as a pair-programmer whose code the student runs before trusting. Check: The second table shows what each broken program printed, or the error type on its last line; one of the three runs without any error but prints the wrong value.
4. Fix each broken program with the smallest change that makes it do what its description in Part 4 says, run the fixed version, and record the new output. Tool: A free browser-based Python runner (an online editor that runs Python 3 with no account and nothing to install), Python Tutor at pythontutor.com for step-by-step visualization, the official Python documentation at docs.python.org, and one approved chatbot used as a pair-programmer whose code the student runs before trusting. Check: Each fixed program runs without an error and prints the charge its description asks for.
5. Paste the alias program from the third row of the first table into Python Tutor, click the button to visualize it, and step forward one line at a time. Count the object boxes and the arrows that point at them. Tool: A free browser-based Python runner (an online editor that runs Python 3 with no account and nothing to install), Python Tutor at pythontutor.com for step-by-step visualization, the official Python documentation at docs.python.org, and one approved chatbot used as a pair-programmer whose code the student runs before trusting. Check: One Battery box appears, and after spare = a two arrows, one from a and one from spare, point at that same box.
6. Write your own short class: a class named Shelf whose setup method stores a count of books starting at 0, an add method that adds a number of books, and a total method that returns the count. Build two shelves, add 3 and then 4 books to the first and 5 to the second, and print both totals and their sum. Predict the output, run the program, and fill in the third table. Tool: A free browser-based Python runner (an online editor that runs Python 3 with no account and nothing to install), Python Tutor at pythontutor.com for step-by-step visualization, the official Python documentation at docs.python.org, and one approved chatbot used as a pair-programmer whose code the student runs before trusting. Check: A short program that runs without an error, with your predicted and actual outputs side by side and the two shelves keeping separate counts.
7. Open your approved chatbot, paste the critique prompt from Part 6 as one message, then check each of its claims by running the code it talks about. If you are using the equivalent route, mark up the printed flawed analysis in the same way. Tool: A free browser-based Python runner (an online editor that runs Python 3 with no account and nothing to install), Python Tutor at pythontutor.com for step-by-step visualization, the official Python documentation at docs.python.org, and one approved chatbot used as a pair-programmer whose code the student runs before trusting. Check: The fourth table lists each chatbot claim, what your run showed, and a correction wherever the two disagree.

Fallback route

When to use it: Use this route if your browser Python runner will not open or will not run code.

Run every program in Python Tutor instead, which also runs Python 3 in the browser: paste each program, click the button to visualize it, and step to the end to read its output or its error. Complete every table, analysis question, and the critique step, and submit the same items for equal credit.

This route earns the same credit as the primary route.

Part 4 — The Scaffold

Predict first and run second, so the gap between the two columns is your own evidence of which object each method changed and what it handed back.

Student scaffold table 1

Program	Your prediction	Actual output from the run	Same or different?
Row 1: a = Battery(80) and b = Battery(50), then a.use(30) and b.use(10), then print(a.charge, b.charge)
Row 2: a class Robot whose setup method prints built and the name before storing self.name = name, then r1 = Robot("Zip"), r2 = Robot("Bolt"), and print(r2.name)
Row 3: a = Battery(80), then spare = a and spare.use(20), then print(a.charge, spare is a)
Row 4: a = Battery(80), then x = a.show() and print(x)
Row 5: a = Battery(15), then print(a.use(10), a.use(10), a.charge)
Row 6: a class Toolbox whose setup method stores self.tools = [] and whose add method appends a tool, then red and blue toolboxes, two tools added to red, and print(len(red.tools), len(blue.tools))

Read each broken program from its run before you change a single character.

Student scaffold table 2

Broken program and what it should do	What printed, or the error type on the last line	Your one-change fix	Output after the fix
Bug 1, should print 50, the charge left after using 30 of 80: Battery with the line charge = charge in its setup method, then a = Battery(80), a.use(30), and print(a.charge)
Bug 2, should print 100 after a recharge: Battery with recharge written as def recharge(): and no parameters, then a.recharge() and print(a.charge)
Bug 3, should print 50: Battery whose use method writes charge = self.charge - amount, then a = Battery(80), a.use(30), and print(a.charge)

Write your own small class, then let the run confirm or correct what you expected it to print.

Student scaffold table 3

Line you wrote	Output you expected	Output of the run
Line 1
Line 2
Line 3
Line 4
Line 5
Line 6
Line 7
Line 8
Line 9
Line 10

Check every chatbot claim against a run so the run, not the chatbot, has the last word.

Student scaffold table 4

Chatbot claim, quoted	What your run showed	Correct as stated, or your correction

Part 5 — Analysis Questions

1. Which of your six predictions in the first table differed from the run? For each one, write the step-by-step trace that reaches the actual output, one line per statement, naming the object each method call changed, and name the rule that explains the gap, such as each instance keeping its own state, an alias naming one object, or a method that only prints handing back None.
2. In step 5, how many object boxes did Python Tutor show, and how many arrows pointed at the battery after spare = a? Explain what that tells you about why spare.use(20) changed a.
3. Bug 3 runs without any error message but prints the wrong value, while Bugs 1 and 2 stop with errors. Explain why Bug 3 is a logic error, and name the error type each of Bugs 1 and 2 raised and why the program raised it.
4. Choose one: (a) describe how you would decide whether to trust a chatbot's claim about what a class prints, using one claim from your critique as the example; or (b) describe how predicting before running changed what you noticed about which object a method changes, using one row of your first table as the example.
5. Your Shelf class was tested on one short sequence of additions. Name one input it was never tested on, such as adding 0 books or a negative number of books, and say how you would check what it does by running more cases.

Part 6 — AI-Critique Moment

Choose one equal-credit critique route. Route A: ask an approved AI tool to critique your completed work, then check its response against your own evidence. Route B is the no-AI equivalent printed below.

Approved tools: Claude, Gemini, ChatGPT, Grok, Microsoft Copilot.

Prompt to paste:

I'm doing a beginner Python lab about classes, using an illustrative robotics club's battery program written for a class activity. The class Battery has a setup method that stores self.charge = charge; a use(self, amount) method that subtracts amount and hands back True when self.charge >= amount, and otherwise hands back False; a recharge(self) method that sets self.charge = 100; a level(self) method that returns self.charge; and a show(self) method that prints charge: and the charge. Please do seven things, and keep each answer short. First, predict exactly what this prints: a = Battery(80), b = Battery(50), a.use(30), b.use(10), print(a.charge, b.charge). Second, say what x = a.show() followed by print(x) prints for a = Battery(80), and explain why. Third, write a loop that calls a.use(10) three times. Fourth, Bug 1 is Battery with the line charge = charge in its setup method, and it stops with an error; fix it. Fifth, Bug 2 is a recharge method written def recharge(): with no parameters, and it stops with an error; fix it. Sixth, how do I make a separate copy of a battery object? Seventh, would writing the test in use as self.charge > amount change anything?

Test the response for these likely failures:

• Chatbots often assume two Battery objects share one charge and predict that row 1 prints 40 40, as if both uses came out of the same battery.
• A chatbot may give the right two lines for row 4, charge: 80 and then None, and then explain that show returns the text charge: 80 to x.
• Asked for a loop that uses 10 from the battery three times, a chatbot may write for i in range(1, 3): a.use(10) and say the charge ends at 50.
• A chatbot may fix the AttributeError in Bug 1 by writing self.charge = 0 in the setup method, which runs without an error.
• A chatbot may fix Bug 2 by calling Battery.recharge() with no object and call the program working without running it.
• A chatbot may claim that every object has a built-in copy method, so spare = a.copy() makes a second, separate battery.
• A chatbot may say that rewriting the test in use as self.charge > amount behaves the same as self.charge >= amount.

Write 2-3 sentences that name one thing the chatbot got right and at least one claim you corrected, and for each correction give the output or error type your own run showed.

Equivalent route (no AI required)

No AI account is required for this lab. Instead of the chatbot, critique this flawed analysis, printed here in full: “Row 1 prints 40 40, because a and b share one charge. For row 4, show returns the text charge: 80, so x holds that text. A loop that uses the battery three times is for i in range(1, 3): a.use(10), and the charge ends at 50. To fix Bug 1, write self.charge = 0 in the setup method; the program now runs without an error. To fix Bug 2, call Battery.recharge() instead of a.recharge(); this version is working. Every object has a built-in copy method, so spare = a.copy() makes a separate battery. Writing self.charge > amount in use changes nothing.” Mark it up: quote each flawed sentence, run the code it describes in your browser Python runner, and write the corrected claim beside it with the run's output or error type as evidence. This route assesses the same objectives as the chatbot critique, namely building objects from a class, storing attributes on self, telling a method that returns from one that prints, and checking every claim about a class by running it (Objective 8 and Objective 5), and it takes comparable effort, about 20 minutes of the lab. It is scored by the same rubric for the same credit, and its marked-up analysis replaces the chatbot report and share link in your submission. You do not need to say which route you chose.

Part 7 — What to Submit

• All four completed scaffold tables
• Written answers to all five analysis questions
• Your Shelf class with its run output
• The chatbot critique report with its share link, or the equivalent route's marked-up flawed analysis

Deliverable:

A short Coding Lab report on an illustrative robotics club's classes: four completed tables (six predictions beside their runs, three broken programs read and fixed, your own Shelf class with its run, and the checked chatbot claims), written answers to five analysis questions, and a critique of a chatbot's answers to the same questions, or, on the equivalent route, a marked-up correction of the printed flawed analysis. Submit in any accessible file type or as a link; a recorded response may be submitted as audio or video with a transcript, or as text. Choose a written, recorded, or visual form for your answers, such as screen captures of your runs with a short note for each; every form is graded by the same rubric.

Rubric

The rubric below shows how each submitted part is evaluated; bands are full, partial, or none.

Workshop evaluation criteria

Criterion	Full	Partial	None
Predicting and running the six programs	All six predictions are recorded before the runs, and all six actual outputs match what the programs print, copied line for line and in the order the lines appeared.	The table is mostly complete, but an actual output is missing, out of order, or miscopied, or predictions appear to have been filled in after running.	No predictions or runs are recorded, or the outputs are invented rather than run.
Explaining the gaps between prediction and run	Every prediction that differed from its run is traced statement by statement to the actual output, naming the object each call changed and the governing rule, such as separate state for each instance, an alias, or a printing method handing back None.	The gaps are listed, but a statement-by-statement trace is missing or the rule behind a gap is not named.	No gap is explained, or the response blames the runner instead of the rule.
Finding and fixing the three bugs	Each bug is read correctly from its run: what printed or the error type, a one-change fix, and the fixed program's output, with Bug 3 identified as a logic error, Bugs 1 and 2 named by their error types, and each fix storing the value on self or giving the method its self parameter.	Two of the three bugs are read and fixed correctly, or all three are fixed but an error type or the run evidence is missing.	The bugs are not attempted, or errors are named without running the programs.
Writing, running, and verifying a class	The Shelf class runs without an error, stores its count on self in the setup method, has a method that changes the count and one that returns it, and its two shelves are run, with expected and actual outputs recorded side by side.	The class runs but misses one requirement, such as a total method that prints instead of returning, or an unrecorded expected or actual output.	No class is submitted, or it was not run.
Critiquing the AI analysis or the printed flawed analysis	The chatbot's answers, or on the equivalent route the printed flawed analysis, are quoted and at least two claims are corrected with evidence from the student's own runs.	The critique names errors but corrects only one, or corrects without run evidence, on either route.	No critique is submitted on either route, or chatbot or flawed text is pasted without any checking.
Reflection and limitation	The chosen reflection option is answered with a specific example from this lab, and the limitation answer names an untested input and a sensible way to check it by running more cases.	The reflection or the limitation is general, without an example from this lab or a way to check it.	The reflection and limitation questions are not answered.

Quality Gate

• Every prediction in the first table was written before its program was run.
• Every actual output and error type is copied from your own run, never from memory or a chatbot.
• Each error is named by its type from the last line of the error message, not by the wording after the colon.
• Each fix changes as little as possible and its fixed program was run.
• No output, count, or claim is invented anywhere in the submission.
• The critique quotes the chatbot or the flawed analysis and corrects at least two claims with evidence from your runs.