The Class and the Team

This program runs two things that look similar from the outside and are not the same thing. One is a class you enroll in and get a grade for. The other is a competitive team you try out for and volunteer your afternoons to. They overlap heavily. This page explains the difference so nobody is surprised in September.

The short version

The class: ROV / ROV2

The class is where you learn to build underwater robots. You do not need robotics experience and you do not need to be planning a career in ocean engineering. You do need to have finished Exploring Computer Science, and you need a teacher recommendation. Those are real prerequisites, not paperwork.

The class runs on three-week sprints. Each sprint ends at a pool day, and “done” means it worked in the water, not that you said it was finished. Inside a sprint you get roughly one lesson per week and the rest of the block is studio time for design, fabrication, and testing.

Two things structure your grade:

1. Lesson cards. There is a published card list covering the engineering process, water physics, electricity and fabrication, control and actuation, and software. You clear cards by demonstrating them, usually with your own measured numbers, a physical part you made, or code you can modify on the spot while I watch. Redos on cards are always open.
2. Status reports and a one-on-one. Every three weeks, at the end of the sprint, you turn in a status report covering what you did, what you decided, and roughly how many hours you put in. Track your hours as you go so you are not inventing them later. Then we sit down for a few minutes and talk through it. The report is what you wrote; the one-on-one is where you explain it. Status reports are not redoable. Late or missing is missing.

Your grade starts high and stays high by keeping your cards cleared, your reports in on time, and your contributions visible. Nothing here is a trap. It is also not a free A, which is the change from previous years.

The Robotics Team

The team is the group that competes. For 2026-27 that means MATE ROV, at the Monterey Bay regional in the spring, in the RANGER class. Other competitions may come later, FIRST among them, but nothing beyond MATE is on the calendar this year. The team owns the competition: registration, the technical documentation, the engineering presentation, mission runs on deck, and the outside pool days that no class period is long enough to hold.

The team is not a single company. It currently looks like four MATE companies under one roof, each with its own roster, its own leadership, and its own entry. Companies share the studio, share knowledge, and sometimes share code. They do not share a scoresheet.

The team runs on the same three-week sprint rhythm as the class, which is deliberate. Sprint deadlines land in the same place for everyone, so a company can plan around a pool day without translating between two calendars.

The team is entirely volunteer supported. I am a volunteer when I coach it, and so are the other mentors. That is the honest reason it works differently from the class. There is no attendance sheet and no grade protecting you. Attendance is technically voluntary, but staying on a roster is not. If you are not there, the work does not happen and your company notices. Being on the team is a privilege that depends on doing the work and following the studio norms, which are our version of Tom Sachs’ Ten Bullets. Show up on time. Write things down. Do the work.

Prerequisites

To be considered for the team, you must hold the standard athletic eligibility mark, a 2.0 GPA, and meet one of the following:

Option A, prior experience. One full season completed in the middle or high school robotics program, plus prior or concurrent enrollment in High School Programming with Robotics (commonly called ROV). Full season means active roster status maintained all the way through the final competition phase, not just signing up in the fall.

Option B, technical placement. Advanced placement by technical portfolio and a practical safety evaluation. Subject to space and my evaluation of demonstrated skill and safety competency.

The class is the front door. Everyone on the team comes through it or is in it right now.

How the two fit together

The class builds capability. The team converts it into a competition result. Most of the design, fabrication, and testing work happens in the class block, on the vehicles the companies are fielding, including Godzillah, our RANGER ROV, and Ebirah, our vertical profiling float. The team carries the leadership layer on top of that work, holding the named company roles, running the deliverable schedule, and answering for what shows up on deck in May.

Practically, the pipeline runs one direction. You come through the class, you build a record of cleared cards, honest hours, and status reports that show real decisions, and that record is what you are evaluated on when you try out for the team. The class is not a consolation prize for people who did not make the team. It is where the team comes from.

What Is a Lesson Card?

Every card you see in this pathway, Card 0.2, Card 3.5, Card 5.7, follows the same shape. Once you know the shape, you can walk into any of them cold.

The shape

A lesson card is one page. Not a chapter, not a unit, one page. It has four parts:

1. A short resource. A reading, a video, an activity description. Ten minutes, rarely more.
2. One activity. Something you do, not just read.
3. One artifact. Something you produce: a written record, a measurement, a piece of code, a part you built.
4. A ninety second oral check. How you clear the card. You show your artifact (unless there really isn’t one), explain what you did to a peer and/or your teacher, they ask a question or two, and if you can answer, the card is cleared.

Cards are numbered by unit and sequence, like 0.2 or 3.5. The number is a label for finding and referencing the card, not a countdown. Cards do not have to be cleared in strict numeric order within a unit unless a card says it depends on an earlier one.

Clearing a card

Cards clear out loud, not on paper. Whoever runs your check signs your signoff sheet for it, and any student who can run the check can sign it, your teacher does not have to be the one asking. A few cards are marked teacher-only, because a wrong answer near water or live wiring is dangerous. The card tells you when that applies.

If a check does not go well, that is not a failure, it is a redo. Redos are always open. Come back when you are ready.

Why this format

Half a page fits in your head. A card you can hold in your head is a card you can actually get to in a busy studio, between sprint work, pool day prep, and everything else going on. The format is small on purpose, so the system keeps running instead of quietly stalling out.

For the full system these cards sit inside, sprints, pool days, status reports, DDRs, see How the Studio Works.

Sprint Rhythm

Twelve sprints this year, numbered 1 through 12. Three weeks each, six sessions. Every sprint has the same shape.

See also: Daily Rhythm · Sprint Calendar · Why This Class Runs This Way

Cards

Three cards clear each sprint through Sprint 6, then two as competition work takes over.

A card is a piece of skill or knowledge with something to show at the end. Most run 45 to 60 minutes. A few are 15, a few are 90.

Pick your cards with other people. At Week 1 Tuesday planning, cards get called out and you group up with whoever else is taking them. Three or four people on a card means you work it together, teach each other, and can verify each other. Working a card alone by accident is the failure mode.

Two of your three get taught on Thursdays. The third is on you and your cohort. Be honest about the arithmetic: three cards at an hour each is more than the seated block holds, so some card work happens in the build block and some happens at home.

Some cards need a bench, not a table, because they involve fabrication or soldering. Marked on the card list. Schedule them on purpose instead of discovering it at 3:15.

Clearing a card

Two ways. The card list says which.

Peer verified. Somebody who has already cleared that card watches you do it, asks you about it, and signs your signoff sheet. That signature means something: if a card you signed turns out to be hollow, that is on you too. Two of those and you do not verify cards again this semester.

Verified by me. Safety cards, anything on the critical path, all of Unit 4 software. Oral, and I will ask you to change something while I watch.

Either way, every card produces something you can show. A measurement, a working circuit, code you modify on the spot, a part you made. Not a claim. The thing itself.

At every 1-on-1 I pick one of your peer-verified cards at random and ask you about it for sixty seconds. Not to catch anybody out. It just means you cannot afford to have any of them be hollow, since you do not know which one I will pick.

Week 1 Tuesday: Retro and Planning

Retro on the sprint that just ended. What did we say we would do, what happened, why the gap. Not a blame session and not a victory lap.

Your team writes down at most three changes, each with a name on it. Three weeks from now your status report asks whether they happened.

Planning for the sprint starting now:

• One sentence on what you intend to demonstrate at water day
• Three to five deliverables, each with an owner and a date
• Parts you will need
• What you are waiting on from another team
• Two rough lines on the sprint after this one, because of the BOM deadline

Both live in one document in 01 Company/Sprint Records/. If you missed this session, that is where you read what happened.

Week 2 Tuesday: BOM Due, 5:00 pm

Parts for the next sprint get requested in the middle of this sprint.

School purchasing is slow, slower than is reasonable, and urgency does not change it. Miss the deadline and the part does not exist next sprint. Not a punishment. That is how long ordering takes.

A complete row is six fields plus one sentence: part name, exact link or part number, quantity as a number, unit cost, total cost, need-by date, and what it is for.

Rejected every year for the same four reasons:

• A link to a search page or a category instead of the actual item
• Quantity given as “some” or “a few”
• No need-by date, which makes your row lowest priority by definition
• A part that breaks a MATE rule. Check voltage, materials, and size first.

Before you submit: read the DDR for your subsystem, and search the tracker to see whether another team already ordered it.

Week 3 Tuesday: Water Day

The robot gets wet. Some cards only clear here.

Water day is not a demo for an audience. It is a test, and things will not work. That is what a test is for. Write down actual numbers, because a measurement from the water is worth more than anything you can guess at a bench.

If we do not have water that sprint, it becomes a dry integration test: assembled, powered, tethered, running on the bench. The sprint still ends with something demonstrated.

Week 3: 1-on-1s

The graded checkpoint. The one you cannot skip.

Very little in this class is graded directly. This is. Making it happen is your job, not mine.

Thursday of Week 3 is when I am set aside for 1-on-1s, since it is also the day I am not teaching a card. Sign up for a slot. Slots are limited per session and go first come. If a game is going to eat that Thursday, book earlier in the week instead, or catch me another day. Thursday is just the easiest day to find me, not the only one. Getting a time that works is on you.

If the whole week gets away from you, email me before the sprint ends and ask for an emergency review at the start of the next sprint. I would rather do that than have it just not happen. What actually costs you the grade is silence: a 1-on-1 that never happened and was never asked about.

While I am meeting people one at a time I am unavailable for two hours. Week 3 Thursday is a self-directed session and a bad day for anything that wants me watching. No soldering, no first-time tool use, no fabrication you have not done before.

Good for: status report and folder, documentation, DDRs, reading for the next unit, seated card work. Come in with a plan.

Water day and 1-on-1 conflicts

If you own a card that only clears in water and you are not there, it does not clear. A teammate cannot clear it for you, because then it is their card. If you know you will miss water days regularly, do not take critical-path cards. Real constraint, and I would rather tell you in September than in May.

What You Bring to a 1-on-1

A status report and your folder.

The status report

Submit as a Google Doc before we meet. Template in 00 Program/Templates/.

Header: name, team, date, cards cleared, cards planned next sprint, total hours.

Then:

• Important. Optional. Anything I need to know about or help with.
• New goals and progress against prior goals. A table. Status code and projected completion date on every row. N new, D done, L late (which is fine), C changed, R reassigned. Asterisk any date that moved.
• Photo or screenshot. Required. Show something you did.
• Concerns. Optional.
• Work log. Dates, hours, a few words. More for you than for me.
• Retro, copied from your team’s, plus your own reflection if you want.
• Retro follow-through. What did your team decide to change, and did it happen?

A goal with a date is an estimate, and an estimate that moves is useful information. L is safe to report. One late item is nothing. The same item late three sprints running is a conversation, and I would much rather have that conversation than read three sprints of invented progress.

Hours

Log outside-class hours. Every entry should name something that exists: a document, a commit, a part. Not because I doubt you, but because hours with an artifact attached are verifiable in ten seconds and hours without one are unverifiable, which is unfair to whoever is being honest.

Outside hours count toward meeting the bar, not beating it. They are how you make up what you missed. Make every session, log zero outside hours, and you are in good standing.

Athletes: you do not need to make up every hour of class time. You do need to do some work every week.

The folder

Bring it. No folder, no meeting. I am not collecting it and not grading it. We open it on the table and you take it home.

Your folder is about you:

• Signoff sheet. Every card, the date, who verified it. First page.
• Printed status reports
• 1-on-1 sheets, signed by both of us
• Whatever your cleared cards produced
• Front matter: safety agreement, syllabus, Ten Bullets, procurement rule, card list

Your team binder is about the robot. It lives on a shelf and holds BOMs, DDRs, retro records, weekly logs, test data, spec sheets, calculations.

If it is about you, it goes in your folder. If it is about the robot, it goes in the team binder.

The binder is also what a safety inspector asks for at competition. Real companies keep it for that reason. Ours is on a shelf.

Start with a folder. When the folder stops working, and it will, come get a binder.

What the 1-on-1 sounds like

Five minutes, roughly the same questions:

• What did you clear this sprint? Show me what each one produced.
• Let me ask you about this one. (picks a peer-verified card at random)
• Which cards next sprint, and why those?
• Show me your hours. You logged three on a Saturday, what came out of it?
• Show me a part you specified that is now on the vehicle. What does it do?
• Anything you ordered that came late or wrong? What did the team do instead?
• Your team decided to change something at the retro. Did it happen?
• What is the one thing you got stuck on, and what did you do about it?

None of these are trick questions. All of them are easy if you have been doing the work and impossible to fake if you have not.

The Weekly Log

Each team keeps a log, one entry a week, written by a rotating scribe. Four or five short documents a week for the whole studio.

Lives in 02 Teams/<your team>/Logs/. Not graded. I read it.

Two reasons it exists. Parallel standups mean I only hear one corner at a time, and the log is how I find out what happened in the others. And the retro reads from the log, so a team that did not keep one shows up Week 1 Tuesday with nothing to look at.

Rotating job, like facilitating standup. Everyone does it.

Sprint Calendar 2026-27

Twelve sprints, three weeks each. Print this. Put it in your folder.

See also: Daily Rhythm · Sprint Rhythm · Why This Class Runs This Way

All Twelve Sprints

After Sprint 12: May 25, May 27, Jun 1, Jun 3. Not yet assigned.

1-on-1s are usually quick, five minutes or so. You drive them, not me. Submit your status report beforehand and we work off that.

Grading Closes

BOM Deadlines, 5:00 pm

Always a Tuesday. Parts are for the next sprint.

Dec 8 orders across the holiday break. Mar 23 orders across spring break. A part you forget on those two is gone for three weeks.

Water Days

Always a Tuesday. Subject to pool access. If one falls through, that sprint ends with a dry integration test instead.

1-on-1s

The default is the Thursday that ends the sprint, since that’s when I’m set aside for them. Usually about five minutes each, driven by the status report you submitted beforehand. Getting a slot that works is on you: book earlier in the week if Thursday won’t work, or email for an emergency review at the start of the next sprint if the whole week got away from you.

Breaks

Daily Rhythm

We meet Tuesday and Thursday, 3:00 to 5:00.

See also: Sprint Rhythm · Sprint Calendar · Why This Class Runs This Way

Punch in, 3:00

You are on the clock when you punch in, not when you feel ready. Punching in is how your hours get counted, and your hours are part of your grade. Nobody will remind you.

Eat now. Food does not come to the bench, ever. Not a drink, not a snack, not “I’m almost done.” At 3:30 it is over. Electronics benches and pool gear are the two places in this room where a spill costs real money and creates a hazard.

Standup, 3:10

Three questions, one sentence each:

1. What moved since last session?
2. What am I doing today?
3. What is blocking me?

Blockers get named, not solved

This is the rule that keeps standup alive. Somebody says the thruster won’t spin up, four people start debugging, eleven people stand there watching, twenty minutes gone.

When a blocker comes up, try to brainstorm some help or a solution or repioritiation, etc.

Standup is not a report to me

You are telling your team. I will be at the back, and some days I will be listening to a different corner than yours.

A room where everyone reports to the teacher is a roll call. A room where people report to each other is a studio.

Who runs it

Rotating facilitator. Not the team lead, not permanently anybody.

Running a standup is mechanical: call the order, hold people to one sentence, park the blockers, carry one sentence to studio sync. It takes no authority and it is not a promotion. Everybody does it, and by spring everybody here has run a meeting.

Facilitating cleanly twice is Card 0.6.

Scrambled standup, second Thursday of each sprint

Mixed groups of four or five, drawn on the spot. Same three questions.

Nobody in your group knows your team’s issues, so you cannot say “I fixed the thing” and have everyone nod. You have to explain it. That is harder than it sounds and it is exactly what the engineering presentation judges are testing in May.

Tuesday is for students. Thursday’s is a bit of teaching.

Tuesday is the event day. Whatever the sprint needs happens Tuesday: retro and planning, the BOM deadline, water day.

Thursday is the reliable day. Nothing is externally scheduled, so Thursday is when there might be some teaching. On the first and second Thursday of every sprint I teach one card properly, to everybody, whether or not you picked it. Fifteen minutes.

Week 3 Thursday is the exception. No teaching, because I am running 1-on-1s.

If you miss Thursdays, this matters to you. Athletes especially. If your cohort was there for a card you missed, they teach you. That is not a favor, it is what a cohort is for, and it is why cards get picked in small groups instead of alone.

We will adjust as needed.

Benches open, 3:30

The build block. Biggest part of the day, and it belongs to you and your team.

This is also when you come find me to clear a card, or find a teammate to verify one. Cards clear continuously. Do not save them for the end of the sprint, because when eight people want to clear cards on the same afternoon, the last three are not getting cleared.

Clean up, 4:50

Everything goes back. Tools to the board, parts to their bins, benches wiped, floor clear.

Take a picture for your status report if appropriate. Consider updating your sprint’s status report. It will make it easier to turn in on week 3.

If you measured something today, write the number down before you leave. Not because I am collecting it. Because in three weeks somebody will ask what the number was, and “I think it was around eleven degrees” is not an answer an engineer gives.

Put designs, etc. into the team binder.

Then punch out.

Missing a Session

You will miss sessions. Sports, illness, life. I am not going to fight you about it.

Missing a Tuesday or Thursday is not a grade event. Nobody takes attendance points. But hours you did not work are hours you did not log.

Catching up is on you, and everything is in Drive. Retro and plan in 01 Company/Sprint Records/. Your team’s log and DDRs in 02 Teams/. Read it Tuesday night, not Thursday at 3:15.

If you missed a taught card, find your cohort.

Missing a 1-on-1 is a grade event. See Sprint Rhythm.

The Two Habits

TBD - it might be 3 or 4.

Your Three-Week Status Report

Once per sprint, you sit down and take stock of your own work. What got done, what is next, what is in your way. That is the status report. It is due before your three-week 1-on-1, and it is the document we both look at while we talk.

It is not a big assignment. It is your reflection on your own work, and it should leave you with a clearer idea of what to do next. Twenty minutes. If it is taking an hour, you are writing an essay instead of a report.

• Status report template
• Filled-in example

Open the example first. It is one page, and it will tell you more than this page will.

How to make one

Copy the template into your own student folder in Drive at the start of the sprint. Name it to match its title:

Status Sprint 3 Casey Rivera

If the document name and the heading inside do not match, it will get lost. This happens every year.

Then add to it as you go, a couple of lines at a time. The report is not a thing you write the night before. It is a thing you keep. If you get in the habit of jotting a couple of lines in your notebook at the end of a session, most of the raw material is already sitting there waiting for you to collect, not invent. If you have not been doing that, this is your cue to start.

Print it at the printing session near the end of the sprint and bring the paper to your 1-on-1.

The goals table

Most of the report is one table, one row per goal, with a status code:

• N = New
• D = Done
• L = Late, which is fine
• C = Changed, new date or description
• R = Reassigned

Rows carry forward. Last sprint’s goals show up again with updated codes, which is the point: across three or four reports you can see your own pattern in a way you cannot see inside a single week.

Put an asterisk next to any date you changed. Late is fine. Quietly moving a date and hoping nobody remembers the old one is not.

The rest of the template is short. A photo of something you did, an optional list of concerns, your work log, and your retro.

Goals and retro are not the same thing

This is the distinction that collapses if nobody names it.

The goals table is about outcomes. Did the claw close on the sample. Did the float hold depth. Results.

The retro is about process. Not “I did not finish the claw” but “I started the claw in week three, both sprints in a row, and here is what I am changing.” Causes.

If your retro is a list of things you did not finish, you wrote the goals table twice and skipped the retro. You can either paste in your team’s retro from the retro template or write your own reflection.

Your hours

The work log is your timecard, and that record belongs to you. Date, hours, a few words. “W2, 2 hours, class, wired the ESC harness” is a complete entry.

The rule that keeps it honest: hours should attach to something in the goals table. Two hours with nothing to show for it happens to everyone sometimes. A whole sprint of it is a conversation, not a number.

If you play a sport, you do not need to make up every hour of missed class time, but you do need to do some work every week, and it needs to show up here.

What “not yet” looks like

Three problems in one row. “Soon” is not a date. “Made good progress” is not a quantity, so there is nothing here anyone can check. “Finish it” is not a state anyone can point at and say yes or no.

And a retro that says everything went fine, three sprints running, means either a miracle happened or you stopped looking.

What clears

Concerns are not only engineering problems. If something with your team, or between people, is getting in your way and you are comfortable putting it in writing, it belongs here too. Concerns for that same report:

• The 2 mm tooth change may not clear the frame rail. Need ten minutes with the frame team Tuesday.
• M3 standoffs ordered 9/22 have not arrived. If they miss next week the mount slips a sprint.

Every Done row names a thing that now exists, plus a number or an observation. Every open row has a date and a state someone can check. Every concern names a person to talk to or a date at risk.

Notice that every row here is a fair question for a 90 second oral check. That is the actual test of whether a row was worth writing.

How this gets checked

Filed or not filed is what gets tracked. Nobody is scoring your rows line by line.

At your 1-on-1, expect me to pick one row from your own report and ask you one live question about it. I may also spot-check one card on your signoff sheet the same way. Same rule as everything else on this site: written work is preparation, the live question is the check.

At the team retro on the first Tuesday of the next sprint, your team compares its sprint commitment against what its members actually reported. That comparison is the real audit, and your team runs it, not me. Everyone walks in having already written their individual retro, so that meeting starts with material instead of silence.

About AI

Use whatever tools you use to write this. Your teacher uses AI for status reports sometimes too. The bar is not where the words came from, it is whether the rows are true, because you will be asked about one of them out loud.

About Your Lesson Card Signoff Sheet

Cards clear out loud, not on paper. But something has to remember that they cleared, and that something is one sheet in your folder. Forty rows, one per card, and by June it is the most complete record of what you learned this year that exists anywhere.

The signoff sheet template

What a row looks like

You fill in the first four. The person who ran your check fills in the last two they own: printed name and signature. Print the name, because six months from now a signature is a squiggle and nobody can tell whose squiggle it was.

Sprint is the first column on purpose. Roughly three cards a sprint keeps you where you need to be, and three rows with the same number in front of them is something you can see without counting. So is a sprint with one row.

Who can sign

Any student who can run the check can sign it. That is the whole point of a card ending in a ninety second oral question: the question is short, the answer is either fluent or it is not, and you do not need a credential to hear the difference.

Three guidelines.

Only sign if you believe the teacher would agree this person knows the content. The point is for somebody to let you know if you learned a topic or if you still need some help. The teacher is busy. The check is about your learning.

Signing means you watched the check happen. Not that you heard it went fine. Not that you saw the artifact afterward and it looked right. You were there, you asked a few questions, you believe your peer understands the topic.

Cards marked teacher-only clear with the teacher. Anything where a wrong answer near water or wiring is dangerous, and anything where the check is watching you modify live code. The card tells you which ones those are.

Why we do it this way

The honest reason is arithmetic. One teacher cannot personally run four hundred oral checks in a year, so a system that requires it is a system that quietly stops happening in November. You have seen that happen in classes before.

The better reason is that running the check teaches you more than taking it. You cannot ask a good follow-up question about buoyancy without understanding buoyancy, and you find out fast which one you are doing. Half of what a senior engineer does is review other people’s work, and this is where that starts.

What happens at the 1-on-1

Bring the sheet. The teacher reviews it at most 1-on-1s, which means reading your rows, counting them, and sometimes asking you a question from one of them. If a card comes back not yet, it comes back with a redo, same as everything else here. Redos are always open.

Where it lives

Your folder, in the room.

Student Per-Sprint Deliverables Expectations

Three things, every sprint, no exceptions. This page is the checklist version. Each item links to the page that explains it in full.

1. Your status report

One report, once per sprint, due before your 1-on-1 in Week 3.

• Goals table with status codes, carried forward from last sprint
• A photo or screenshot of something you did
• Concerns, if you have any
• Your hours, logged as you go
• Your retro

Start it early and add to it a couple of lines at a time. Print it at the end-of-sprint printing session and bring the paper to your 1-on-1.

Full page: Your Three-Week Status Report

2. Your 1-on-1

Finding time with me is your job, not mine. Sign up for a slot on the sign-up sheet on the whiteboard for Week 3 Thursday, the day I set aside for 1-on-1s. If that day doesn’t work for you, book earlier in the week instead, or catch me another day. Thursday is just the easiest day to find me, not the only one.

Bring your printed status report and your folder. No folder, no meeting.

Expect one question about a peer-verified card picked at random, and a question or two from your own status report.

If the whole week is slipping away from you, email me before the sprint ends and ask for an emergency review. I would rather do that than have it just not happen. Silence is what costs you the grade, not a late request.

Full page: Sprint Rhythm

3. About three cleared cards, signed off

Roughly three lesson cards a sprint, each cleared out loud and recorded as a row on your signoff sheet.

• Peer-verified cards: signed by any student who watched your check
• Teacher-only cards (safety, critical path, live code): signed by the teacher
• Every card produces something you can show, not just a claim

Full page: About Your Lesson Card Signoff Sheet · Full page: What Is a Lesson Card?

What else your team might owe

These aren’t yours alone, but they land inside your sprint too:

• A BOM, due Week 2 Tuesday at 5:00, if you own a part that needs ordering
• The weekly log, if you’re this week’s rotating scribe

The whole list, at a glance

• Status report, printed, in hand at your 1-on-1
• 1-on-1 slot found and booked by you, then attended
• Folder brought, signoff sheet current
• About three cards cleared and signed this sprint

How the Studio Works

The classroom is a studio, and we run it like an engineering company. This page is the short version of how a year in that company works.

Sprints

The season is built on three week sprints. At sprint planning your team publicly commits to a short list of deliverables. Each sprint ends at a pool day, where “done” means it works in the water, not that it looks done on the bench. If the pool falls through, the sprint still ends with a bench demo. Teams are three to seven people, and every deliverable has one owner. The sprints themselves sit inside a semester plan we write in Sprint 0 from last season’s evidence; see Waterfall and Agile for why we run it this way.

Lessons and cards

Once a week there is a short lesson, usually twenty to forty minutes, often a discussion seminar rather than a lecture. Every lesson is a one page lesson card: a core question, a short resource, an activity, and one artifact. You clear a card with a ninety second oral check or by teaching it back to your team.

If you miss a class, the card works the same way when you return. There is no separate makeup track, because there is only one system.

Your grade

Work is complete or not yet, and redos are always open. Your grade starts the year on this basis: you keep your A by keeping your cards cleared and your contributions real and visible. Contributions become visible through your sprint status report, which also carries your hours. That record belongs to you.

Two habits

Our working code is adapted from Tom Sachs’ Ten Bullets, and two of those habits show up everywhere.

The first is being on the clock. Studio time is work time, and your weekly status report is that habit made visible.

The second is writing things down. Whoever makes a design decision writes a short Design Decision Record: the decision, what forced it, the options, the reasoning, and what it costs. Later in the year we add design specs, which describe what a thing must do before anyone builds it. None of this is paperwork about engineering. It is engineering, and it is how any one of us can answer when a judge points at the robot in May and asks why.

What this protects

Most of your time is still designing and building robots. The structure exists to protect that time, not to replace it. This year we build in a way we can finish, defend, and be proud of.

Where things live

• How the class relates to the competitive team: The Class and the Team
• The daily schedule, in full: Daily Rhythm
• The sprint schedule, in full: Sprint Rhythm
• Every date for the year: Sprint Calendar
• The reasoning behind all of it: Why This Class Runs This Way
• How we plan the season and the sprints: Waterfall and Agile
• What you owe every sprint: Your Three-Week Status Report
• How decisions get written down: Card 0.2, Writing a Design Decision Record
• A different contract with the same standards: Independent Contractors
• The season-long coding track: The Python Ladder

Waterfall and Agile: Why We Use Both

Sooner or later someone in this room notices something odd. We write a semester plan in August that runs to December, and we also run three week sprints where the plan can change every time. Which one is it?

Both, on purpose. Here is the defense.

Two ways to run a project

Waterfall means you decide the whole plan up front, then build it in order. You do requirements, then design, then build, then test, mostly in that order, mostly without going back. Changing the plan late is expensive, because everything after the change point has to be redone.

Agile means you work in short cycles. At the end of each cycle you have shown something working, and you use what you just learned to adjust the plan for the next cycle. Nothing far in the future is locked in stone.

Neither is right or wrong. Each fits a different kind of problem.

What we actually do

The season plan is waterfall. It got written in Sprint 0, from the score autopsy, and it points all the way to the regional competition in May. That plan names what we build, roughly when, and why, based on evidence from last season.

The sprints inside that plan are agile. Every three weeks, your team publicly commits a short list of deliverables, builds toward a pool day, and reviews what happened. The next sprint’s plan responds to what the pool actually told you.

Why the season is waterfall

Three real reasons, not tradition.

MATE sets the deadlines, not us. The manual, the documentation due dates, and the regional date do not move for anyone. A plan with a fixed end point wants a plan built backward from that point, which is exactly what waterfall is for.

Parts have lead time. School purchasing takes weeks, so BOMs for a sprint have to be requested during the sprint before it (Card 0.5). That only works if you can see far enough ahead to know what you will need.

You had evidence up front, for once. Most waterfall plans fail because someone guessed at requirements before building anything. Our plan is built from last season’s actual scoresheets (Card 0.4), which is the one condition under which planning far ahead actually works: you are not guessing, you are extrapolating from a real result.

Why the sprints are agile

The water tells you things the bench cannot. A claw that works on the table can fail at depth, in current, gripping a real task prop. You cannot design that away on paper; you have to test it and adjust.

Three week cycles make lateness visible early. A deliverable that is “20% done” or “80% done” looks the same on the bench for weeks. A cycle that ends in a demo cannot hide that. Card 0.3 covers why this fixes the planning fallacy, where everyone underestimates how long things take.

Where waterfall fails

A plan is a prediction, and predictions rot as the season goes on. The specific failure this program has actually lived through: staying committed to a design after the evidence said it was wrong, because it was on the plan. “The plan said so” is not a reason to keep building something that is not working. Big plans also hide their errors until late, which is the most expensive time to find them.

Where agile fails

Iterating with no finish line. A team can feel productive every single sprint while the thing that actually gets scored quietly slips. Agile normally assumes you can cut scope when you are behind, and we mostly cannot: the mission tasks are given by MATE, not chosen by us. Retros that name the same problem three sprints running and change nothing are agile in name only. And documentation is the first thing that dies under “we will get to it next sprint,” which is why DDRs get written same-sprint instead of saved for later.

How to tell which one you are in

If the thing you want to change is on the semester plan, it needs a DDR and a conversation with the whole company. If it is inside this sprint, your team decides it at planning or at the retro.

That is the whole rule. Most disagreements about “why can’t we just change this” are really disagreements about which of those two you are standing in.

When the semester plan does change

The plan is allowed to change. It changes at a sprint boundary, not mid-sprint. It changes because of evidence: a pool day result, a new score autopsy insight, a part that turned out not to work. And the change gets written down as a DDR, same as any other decision, so the reasoning survives past whoever made the call.

Why this matters for competition

Judges ask about your process, and “we use agile” is a buzzword answer they have heard a hundred times. Naming your actual hybrid, and being honest about where each half of it fails, is what a real answer sounds like. Most engineering organizations run some hybrid of planned and iterative work. Few of them can describe theirs out loud. You can.

Going further

A video your teacher recommends on the difference between these two approaches, if you want to go deeper than this page.

Independent Contractors

Most of the company works in teams of 3 to 7. A small number of students may instead work as independent contractors: a company of one, doing a project the studio actually needs.

What a contractor is

A contractor is not a punishment and not an escape. It is a different contract with the same standards. Contractors:

• Commit deliverables at sprint planning like every team, and demo at every pool day or sprint review
• Clear the same lesson cards, write the same DDRs, and file the same status report
• Own every deliverable personally. There is no teammate to point at, and no teammate to hide behind
• Build things the company will use. Contractor projects sell their product back to the teams

How you become one

Contractor status is granted by the teacher, not chosen, and slots are limited (2 to 3 at a time). It happens one of two ways:

1. By proposal. You pitch a project the studio needs and you are the right person to build it.
2. By reassignment. If working on a team is not working, after a documented probation sprint with clear written expectations, the teacher may move you to contractor status.

Either way, the gate is the same: a written project proposal before any build time. One page: objective, what you will produce, materials and estimated cost, timeline by sprint, what you expect to be hard, and what “done” looks like. The proposal is reviewed like a design review; expect questions.

Example contractor projects

• A claw test fixture teams use to benchmark grip designs
• A camera comparison (latency, low light, fogging) with data teams can cite in DDRs
• Driver practice props built to mission task dimensions
• A battery charging and tracking station
• Studio tooling: label systems, cable testers, a tether management reel

Notice the pattern: every project has a customer inside the company.

The path back

Contractor status is reviewed each sprint. Contractors in good standing can propose joining or rejoining a team at any sprint boundary, and teams can recruit contractors whose work they respect. Delivering as a contractor is the strongest possible argument that you are ready for a team again.

The fine print

A contractor who stops delivering does not get a quieter version of the class; they get the same “not yet” everyone gets, the same redo path, and a conversation about scope. The water and the sprint record judge contractors exactly as they judge teams.

Why This Class Runs This Way

Daily Rhythm, Sprint Rhythm, and Sprint Calendar tell you what happens. This one tells you why, including the places where I am not sure yet and the places where previous versions of this class failed.

I am publishing this because a rule that only works when you do not know the reason is a bad rule. If something here does not survive you reading it, it was going to break by April anyway, and I would rather find out in August.

The thing that has killed every system I have tried

Exit tickets. Personal todo lists. Weekly status threads. Comment threads on assignments. All of these worked for about three weeks and then died.

They did not die because they were bad ideas. They died because every one of them depended on me noticing that you had not done it and then chasing you about it. Twenty students times one small thing per week is a hundred small acts of chasing per month, and I cannot sustain that. So it decays, and once a system decays visibly, the students who were doing it stop, because why would you keep doing something that clearly does not matter.

So this year everything is built on one principle: I will not chase you.

Not because I do not care. Because chasing feels like caring and it is actually the thing that guarantees the system collapses, which does not help you at all.

What that means in practice:

• If you do not submit a status report, nothing gets printed and your folder has a gap in it. I will not email you about it.
• If you do not book a 1-on-1, you do not have one, and your grade reflects that. I will not remind you the day before.
• If you miss the BOM deadline, the part does not arrive. I will not put in a rush order.
• If you do not come clear a card, it stays uncleared.

Every one of those is visible to you before it becomes a problem. None of them are surprises. That is the trade: you get a system that will still be running in April, and in exchange the tracking is yours.

Why the deadlines do not move

The BOM deadline is the clearest case, so let me be direct about it.

School purchasing genuinely takes weeks. That is not me being strict, it is a district process I do not control. So the one-sprint-ahead rule is not a rule I invented to teach you a lesson. It is roughly how long ordering actually takes, written down.

Here is the part worth saying out loud: I am going to hold that deadline the first time one of my best students misses it. Not because I want to, and not because the work you were doing instead was unimportant. Because an exception in September means there is no deadline in April, and April is when it matters. If I bend it for the person who deserves it most, I have to bend it for everyone, and then we are back to me tracking purchase requests in my head at 11pm.

Same logic on cleanup, on the 3:30 bench rule, on the 1-on-1 window. These are load-bearing.

Why cards are demonstrated, not turned in

You can ask an AI to write you a lab report. You cannot ask it for the number you measured on the bench, or to modify your own code while I watch, or to hand me the part you made.

That is the whole reason cards clear by demonstration. It is not distrust. It is that a written artifact no longer proves what it used to prove, and I would rather build verification that still works than pretend nothing changed. This is also true outside of school now, and it will be true in whatever you do next.

Practical consequence: for a lot of cards I will ask you to change something on the spot. Not to catch you out. Because being able to change a thing is the difference between understanding it and having read about it, and that difference is what I am actually assessing.

The arithmetic that does not quite work

Sprint Rhythm says three cards per sprint fit in the 3:00 to 3:30 seated block. Let me show you the actual math, because it is close but it does not close.

Three cards at 45 to 60 minutes each is 135 to 180 minutes per sprint.

The seated block is 30 minutes times six sessions, which is 180 minutes. That looks fine until you subtract punch-in and standup, which is about thirteen minutes. Real seated time is more like 17 minutes per session, or about 100 minutes per sprint.

So the card load exceeds the seated block by roughly a third.

Three ways to fix that, and I have not picked one:

1. Move standup to 3:00 and eat during it. Buys back ten minutes, loses the clean transition that punching in and sitting down gives us.
2. Accept that about a third of card work is homework or happens during the build block.
3. Drop the quota to two cards per sprint and take longer to get through the library.

I am telling you this instead of quietly hoping you do not notice, for two reasons. One, you would notice. Two, this is what engineering estimation actually looks like: you do the arithmetic, it does not close, and you choose which constraint to relax on purpose rather than discovering the problem in week four.

We will settle it by early October, and if you have an opinion I want it at a retro.

Why we start with folders and not binders

A folder costs a dollar and requires nothing of you. A binder with dividers is a system, and systems that arrive before you need them get abandoned.

So here is the plan, stated plainly rather than sprung on you: we start with folders, and sometime around January the folders will stop working. Pages will fall out. Somebody will not be able to find their DDR from Sprint 2. When that happens, tell me and we will get binders and dividers.

I could hand you a binder in August. But then you would have a binder and no idea why the dividers are where they are. In January you will know exactly why, because you will have just spent twenty minutes looking for a piece of paper.

Why the food rule is a time and not a judgment

Food off the benches at 3:30, and I am not going to argue about whether your specific snack is fine.

Two real reasons. Electronics benches and pool gear are the two places in this room where a spill costs money and creates a hazard, and that is a genuine safety line, not a preference. And a fixed window beats me making twenty individual judgment calls about grazing over the course of a two hour block.

When Card 5.1 runs, you write the JSA for this room, and that line goes in it in your words. At that point it stops being my rule.

What I am watching for

Not a secret, so you might as well know.

Blockers that show up for the first time at a 1-on-1. If a problem existed on day three and I hear about it on day eighteen, that is not a problem with the problem, that is a problem with the standup. When I see it, I will spend the next couple of sessions in that team’s corner.

Three cards cleared and nothing built. It is technically possible to hit the card quota, write clean status reports, and never touch the vehicle. The card system by itself would not catch that. Your hours log and your team’s sprint commitment do. Cards are the floor, not the job.

Status reports that describe activity instead of results. “Worked on the claw” for three sprints in a row is a real thing that happens and it is what the goals section exists to prevent.

The parts that depend on people who are not me

Water access is not confirmed for all twelve sprints. The Sprint Calendar lists a water day for every sprint, but each one is subject to pool access, on purpose. Pool scheduling involves a facility I do not control, and I would rather hedge in August and exceed it than promise twelve water days and cancel four.

If a water day falls through, the sprint still ends with a demonstration: assembled, powered, tethered, running dry on the bench. A sprint that ends with nothing demonstrated is a sprint whose deadline was fiction, and we are not doing that.

Week 3 Thursday, and what you should be doing

While I am running 1-on-1s, I am effectively unavailable for two hours. Twenty people at five minutes each fills the block.

That means Week 3 Thursday is a self-directed session, and it is not a good day for anything that wants me watching. No soldering, no first-time tool use, no fabrication you have not done before.

It is a good day for: notebook catch-up, reading for the next unit, documentation, seated card work, writing DDRs, getting your status report and folder in order. Come in with a plan for it. If you show up to Week 3 Thursday with nothing to do, you will have wasted the two hours and I will not have noticed in time to help.

If something here is wrong

Bring it to a retro. That is what the retro is for, and “this part of the system is not working” is exactly the kind of thing it is supposed to surface.

I have taught this class before without most of this structure and it did not go as well as it should have. That was my fault, not the previous students’. This is my attempt to fix it, and some of it will be wrong.

The Python Ladder

How the ladder works (from Card 4.2): read the chapter, practice in the Colab notebook (never collected, never graded), then build the rung’s transfer task, a small program in robot context. Clear the rung with a 90-second live demo: run it, then modify it on request. Live modification is the whole check.

Pace: about one rung per week. Ahead is fine. Behind just means climb. Rungs clear during studio time whenever you are ready.

Rung 1: Numbers That Matter (Ch. 1, Programming as a Way of Thinking)

Core question: Python is a calculator that never makes arithmetic mistakes. Can you make it compute mission numbers?

Transfer task: In the Python interpreter or a script, compute and print, with labels:

• Pressure in kPa at 2.5 m and at 4 m (from Card 1.2: depth times 9.81, plus 101 for absolute)
• Power in watts of one thruster at 12 V drawing 15 A
• Total power of six of them

Live demo modifications to expect: “Change it to salt water, about 10.06 per meter.” “What is the pressure at the bottom of Monterey Canyon, 3600 m?”

Rung 2: The Mission Config (Ch. 2, Variables and Statements)

Core question: Numbers with names beat numbers alone. Can you build a script where changing one line changes everything downstream?

Transfer task: A script with variables at the top: team_number, tether_length_m, supply_voltage, target_depth_m. Below, compute and print at least two derived values (example: absolute pressure at target depth; total tether copper length, which is round trip, so times 2). Changing a top variable must correctly change the output.

Live demo modifications: “Set the tether to 25 m and tell me what changed.” “Add a variable for water type and use it in a printed sentence.”

Rung 3: The Dive Report (Ch. 3, Functions)

Core question: A function is a machine you build once and run forever. Can you build one?

Transfer task: Define print_dive_report(pilot, depth_m, duration_s) that prints a formatted three-line report. Call it three times with different arguments in the same script.

Live demo modifications: “Add a fourth parameter for the date.” “Make it print duration in minutes and seconds instead of raw seconds.”

Rung 4: Draw the Mission (Ch. 4, Functions and Interfaces)

Core question: The turtle module turns function calls into drawings. Can you design functions whose names and parameters make sense to someone else?

Transfer task: Using turtle, write a function square(size) and a function grid(rows, cols, size) that uses it, then draw the pool mission grid. Stretch: a function that draws a descending spiral, which is roughly what a survey pattern looks like from above.

Live demo modifications: “Make the grid 3 by 5.” “Add a gap between squares using one new parameter.”

Rung 5: GO / NO-GO (Ch. 5, Conditionals and Recursion)

Core question: Programs that decide are more useful than programs that compute. Can you write launch logic?

Transfer task: A script that takes a battery voltage (input() or a variable) and prints a launch decision: below 11.1 V prints NO-GO, 11.1 to 11.8 prints GO WITH CAUTION, above prints GO. Then add a second check (example: tether_connected as True or False) that can veto everything.

Live demo modifications: “Add a third condition: NO-GO if voltage is above 13, that means a wrong battery.” “Swap the order of your checks; does behavior change and why?”

Rung 6: The Conversion Function (Ch. 6, Return Values)

Core question: Printing shows a human; returning hands a value to the next piece of code. Can you write functions the rest of the program can build on?

Transfer task: Write kpa_to_depth(kpa_absolute) that returns depth in meters (subtract surface pressure first, from Card 3.7), and fuse_margin(fuse_rating, measured_current) that returns the percentage of headroom left. Include two hand-computed test cases for each, as comments, and show the function passing them.

Live demo modifications: “Make kpa_to_depth take an optional salt water flag.” “What does your function return at the surface, and is that right?”

Rung 7: The Descent Loop (Ch. 7, Iteration and Search)

Core question: Loops let five lines of code do a thousand seconds of work. Can you simulate a dive?

Transfer task: A while loop simulating descent: depth starts at 0, increases by 0.1 m per step, prints time and depth each step, and stops when it reaches target_depth_m from your Rung 2 config. Then print the total steps taken. Stretch: make the descent rate slow down as it approaches the target, which is your first taste of Card 3.5’s problem.

Live demo modifications: “Change the rate to 0.25 m per step; how many steps now?” “Make it stop early if depth ever exceeds 4 m and print a warning.”

Rung 8: Parse the Packet (Ch. 8, Strings and Regular Expressions)

Core question: The float transmits its data as text. Can you take a packet apart?

Transfer task: Given the string packet = “RN34 12:01:33 2.47” (team, time, depth), use string methods to split it and print each field with a label, converting depth to a float and proving it with arithmetic (print the depth doubled). Then handle a second packet with different values using the same code.

Live demo modifications: “The packet now has a fourth field, pressure. Adapt.” “What does your code do with a malformed packet, and what should it do?”

Rung 9: The Dive Log (Ch. 9, Lists)

Core question: A dive is not one depth; it is hundreds. Can you compute with all of them at once?

Transfer task: Given a list of depth readings (provided on the class page, or invent 20 values), compute and print: maximum depth, average depth, and hold quality, the count of readings within 0.2 m of the 2.5 m target. That last number is literally how we will judge the float’s PID tuning.

Live demo modifications: “Tighten the tolerance to 0.1 and rerun.” “Add the reading 9.9 to the list; which of your three numbers should make you suspicious and why?”

Rung 10: The Parts Tracker (Ch. 10, Dictionaries)

Core question: Lists find things by position; dictionaries find things by name. Can you build the tiny database the supply chain runs on?

Transfer task: A dictionary mapping part names to a price, like {“thruster”: 89.00, “esc”: 24.50, “penetrator”: 6.00}. Write code that: looks up one part’s price, adds a new part, and computes total cost of an order given a second dictionary of quantities, like {“thruster”: 2, “penetrator”: 8}. Print an order summary with a line per part and a total.

Live demo modifications: “Order a part that is not in the price list; make your code survive it with a useful message.” “Add a 10% shipping estimate to the total.”

After Rung 10

You can now read most of the float’s codebase for real. The ladder continues into applied cards: 4.3 Data Logging (files come a few chapters later in the book, but the rungs carry you), 4.4 Plotting, and 4.5 State Machines, where your Rung 10 dictionaries come back as the machine’s transition table. Software-track students continue into classes and the repository itself.

Card 0.1: How a Socratic Seminar Works

Before Class Reading: Arguing Like an Engineer

In 1910, engineers argued about whether the Titanic needed more lifeboats. The ones who lost that argument were not wrong; they lost because the room ran on authority instead of reasons. A century later, accident reports from aviation, medicine, and engineering keep finding the same failure: someone in the room knew, and the room had no way to hear them.

A Socratic seminar is a room designed to hear them. The name comes from Socrates, who taught by asking questions instead of announcing answers, but the format matters more than the history. In a seminar, participants sit where everyone can see everyone, speak to each other instead of to the teacher, and follow one rule that changes everything: claims travel with reasons. “The claw failed because we started too late” is a move in the game. “The claw failed” alone is not, and neither is “Jake messed it up.”

This is not a debate. In a debate you defend a side and winning means the other side loses. In a seminar the group is trying to get somewhere together, and changing your mind in public is a respected move, not a defeat. Some of the best contributions are questions. Some are five words long: “What is your evidence for that?”

There are moves you will use constantly. Building: “Adding to what she said…” Challenging the idea, never the person: “I see it differently, because…” Asking for evidence. Naming a pattern: “Three people have now said versions of the same thing.” And the most underrated move in any technical discussion: silence while you actually think.

Why does an engineering class train this? Because every design review, every sprint retro, and the MATE engineering presentation itself runs on exactly this skill. Judges will probe your reasoning in real time, in a room, out loud. Teams that have argued well all year are relaxed in that room. Teams that have not are reciting.

One more thing: the seminar only works if people arrive loaded. A seminar where nobody prepared is just a slow conversation about vibes. That is what prep notes are for, and it is why they are the artifact for every seminar card this year.

Prep prompt (bring in writing): Our first practice seminar topic is “Our claws keep failing. Why?” Write (1) one claim about why, with your reasoning, (2) one piece of evidence from something you personally saw or did on this team, and (3) one question you honestly want the group to take up. Your evidence must be something that happened in our studio or at our pool days; nobody outside this room can write it for you.

Unit: 0, Engineering Process Format: Short instruction, then a live practice seminar Time: 40 minutes (10 minutes on the format, 25 on the practice seminar, 5 debrief) Prerequisites: None. This is one of the first cards of the year.

Core Question

Engineers argue for a living: about designs, tradeoffs, and evidence. How do you have a real discussion where ideas get tested instead of people getting defended, and where the quiet people talk and the loud people listen?

Resource (~10 minutes, in class)

The teacher explains the format, which has only a few rules:

• We sit where everyone can see everyone.
• You speak to each other, not to the teacher. The teacher asks questions and otherwise stays out.
• Claims need reasons or evidence. “I think X because Y” is the unit of speech.
• Build on or push against what was just said. “Adding to what she said” and “I see it differently because” are both good moves.
• Disagree with the idea, never the person.
• Silence is allowed. Thinking pauses are not failures.

Practice Seminar Topic

“Our claws keep failing. Why?” Everyone here has watched or lived at least one claw project run out of time. Bring your honest theory. Possible directions the teacher may probe: Is the problem ambition, planning, skills, or something else? What would a claw project that finishes on time look like from week one? What should this team refuse to attempt this year?

Prep Notes (your artifact, written before the seminar)

1. One claim about why claw projects overrun, with your reasoning. 2 to 4 sentences.
2. One piece of evidence from something you actually saw or did on this team.
3. One honest question you want the group to take up.

Clearing This Card

Participate in the practice seminar with at least one contribution that uses the “claim plus reason” form, and turn in your prep notes. The bar is genuine engagement, not brilliance. Students who find speaking in groups hard can clear by submitting prep notes plus a written response to two things other people said during the seminar.

If You Miss This Class

Seminars cannot be done alone. Write the prep notes for the topic, then join the next scheduled seminar on any topic and clear there. Prep notes for both topics are due.

Why This Matters for Competition

The MATE engineering presentation IS a seminar: judges probe your reasoning and you defend design decisions in real time. Every seminar this year is a rep for that room. It is also how our design reviews will run, so this format is not a school exercise; it is how the company makes decisions.

Card 0.2: Writing a Design Decision Record

Before Class Reading: Where Decisions Go to Die

Here is a scene from every engineering team ever. March. Someone asks, “Why is the claw geared this way?” Silence. The student who made that choice graduated, or forgot, or is absent today. The team rebuilds the reasoning from scratch, or worse, changes the design without knowing what the original reasoning was protecting against. The decision was made; the reasons evaporated.

Software companies got tired of this and invented the Architecture Decision Record, or ADR: a short document, written at the moment of decision, by the person who made it. Not a report. Not documentation-as-punishment. Half a page, decision first. Thousands of engineering teams now write these constantly, and the ADR repository on GitHub collects the real formats they use. Engineers discovered something surprising along the way: the writing is not a record of the thinking. The writing IS the thinking. Forcing yourself to name two real options and defend the pick catches bad decisions before they get built.

Mr. B used the equivalent of ADRs in making teaching decisions. He called them TDRs. You can see how he used these the first year he was teaching here.

We are adopting the same tool under a broader name, the Design Decision Record, because our decisions are mechanical and electrical, not just software. The rule is the one that fixes the March scene: whoever makes the decision writes the record, in the same sprint. The documentation lead’s job changes accordingly. They do not invent the team’s reasoning; they assemble the technical documentation from records the whole team authored. The words and the ideas travel together, written by the same hands.

There is a competitive edge hiding in this. At the engineering presentation, judges deliberately question different team members, and a team where only one person can explain the claw bleeds points in front of everyone. A team that writes DDRs has rehearsed the answer all year, because at every sprint review a randomly chosen member defends a randomly chosen record. That is not a classroom exercise wearing an engineering costume. It is the actual job, practiced early.

Here is our template.

Here’s what you’ll do (details below): Pick one real design decision from LAST season that you were close enough to see, from any subsystem. Ask others or your teacher if you’re struggling to find a decision. Write the decision in one sentence, two options that were actually on the table (or should have been), and one piece of evidence, from our classroom, our pool days, or our competition, that influenced or should have influenced the choice. Then turn this into a full DDR. Choose a decision you can speak about from firsthand memory, because the oral check will ask what YOU saw.

Resource (~10 min)

1. Watch Architecture Decision Records: The Basics. This is industry talking to industry, not a school video. Listen for two things: that the record is written by the decider, and that it is short on purpose.
2. Open the DDR template and read it top to bottom, including the checklist at the end.
3. Read a few of our DDRs. Notice that the Why section is the longest and that the whole thing fits on half a page.

The Template

Do not retype it. Open the DDR List and claim the next DDR number. Then open the DDR template, which drops you straight into a copy, then rename the copy DDR-## Short title and put it in the DDRs folder.

The six sections, in order:

Most DDRs take ten minutes to write. Plain language beats fancy language. (They can take longer to think about, research, and discuss.)

When to Write a DDR

Write one when your team:

• Chooses between two or more real approaches (claw geometry, thruster layout, sensor placement, code structure)
• Abandons or reverses an earlier approach
• Accepts a tradeoff (heavier but stronger, slower but more reliable)
• Makes a call that costs money or pool time

Do NOT write one for routine tasks with no real alternatives, like charging batteries or printing a part you already designed.

When a Decision Changes

You never rewrite Decision, The Problem, Options, or Why. Those sections record what you knew at the time you decided, and that is the whole point: a record you edit later is not a record. Reflection is the one section you come back and add, and adding it closes the loop instead of editing history.

If the decision itself changes, that is not an edit. Write a new DDR and set the old one’s Status to “Superseded by DDR-##” with the new record’s number.

Big Decisions: ADRs

When the software team makes an architecture-level choice, such as a framework, a communication protocol, or the structure of the control system, use this exact same template and label it ADR instead of DDR. Same thinking, bigger blast radius. The GitHub repository linked in the reading has thousands of real ones.

Activity: Write One (your artifact)

Write one complete DDR about a real decision from LAST season. You were there for some of them: claw design choices, thruster placement, camera selection, the tether, the float mechanism, software choices. Pick one you know something about. It does not matter that the decision is old. What matters is practicing the form on a decision with no pressure attached.

Requirements:

• All six sections filled in
• At least two real options
• The Why section references at least one piece of evidence: a test result, a rule from the manual, a budget number, or something that happened at the pool
• Reflection filled in, not left blank. This is the one DDR all year where you can do that immediately, because the decision is already old enough to judge. Every DDR you write after today ships with Reflection blank until its own decision gets tested.

Clearing This Card

Discuss your DDR with some peers and then briefly with your teacher. Take feedback if given and edit or augment. If possible, ask your teacher to print it for your folder/binder.

If You Miss This Class

Identical. Watch the video, read the template and examples, write the DDR, discuss with at least one peer and your teacher at your 1-on-1.

Why This Matters for Competition

DDRs are the raw material of our technical documentation, which is a scored deliverable. This year the documentation lead assembles the tech doc FROM the team’s DDRs instead of inventing it alone, so every DDR you write during the season is documentation work already done. And at sprint reviews, a randomly chosen team member defends a randomly chosen DDR, exactly like judging. This card is your first rep.

Card 0.3: Sprint Planning and Estimation

Before Class Reading: Why Everything Takes Twice as Long

In 1979, psychologists Daniel Kahneman and Amos Tversky named a bug in human thinking: the planning fallacy. People predicting how long their own work will take are reliably, sometimes spectacularly, optimistic, even when they know that similar work has always run late before. The Sydney Opera House was estimated at 4 years and took 14. Your homework was estimated at 30 minutes and took the evening. Same bug.

The bug has a structure. When you estimate, you imagine the task going well: the parts arrive, the code compiles, nobody is absent, the epoxy cures on schedule. You are estimating the best case and calling it the plan. Reality is not the best case; it is the best case plus every interruption you failed to imagine, and you cannot imagine them all, by definition.

Engineers cannot remove the bug, so they route around it. Three techniques:

First, the doubling rule. Take your honest estimate and multiply by two. This feels insulting and works remarkably well. (Programmers joke about Hofstadter’s Law: it always takes longer than you expect, even when you take into account Hofstadter’s Law.)

Second, use the outside view. Instead of imagining your task, ask what happened to similar tasks. Not “how long will OUR claw take,” but “how long did claws take the last three times this team built one?” The past is a better forecaster than your imagination, precisely because it already includes the interruptions.

Third, shrink the unit. Big deliverables hide their lateness; “working claw” can be 20% done or 80% done and look identical for weeks. Small demonstrable deliverables cannot hide: “jaw prototype closes on a PVC pipe at the bench” is either shown at the sprint review or it is not. If a deliverable cannot fit in one 3-week sprint, it must be split until it can.

Our sprint system is built from these three techniques. Public commitments, doubled estimates, demonstrable units, and a pool day that does not negotiate. The water is the least sympathetic project manager you will ever have, which is exactly what the planning fallacy deserves.

Prep prompt (bring in writing): Pick one task YOU personally worked on last season (or in any project, if you are new). Write: what you originally thought it would take, what it actually took, and one specific interruption or complication you failed to imagine at the start. Then apply the outside view to this year: name one thing our team plans to build this season, and what the historical record of this team says about it. Your answer must contain details only someone who was there would know.

Unit: 0, Engineering Process Format: Short instruction + team planning workshop Time: 40 minutes Prerequisites: None, but this card lands right before Sprint 1 planning.

Core Question

Our sprints are 3 weeks: roughly 6 class sessions ending at a pool day. Teams that overcommit finish nothing; teams that undercommit hide. How do you promise an amount of work you will actually deliver?

Resource (~10 minutes)

The teacher walks through the sprint system:

• A sprint commitment is a short public list of deliverables your team promises for this sprint.
• A deliverable is done when it can be demonstrated, ideally in the water at pool day. “Mostly done” is not a state. Bench-demo fallbacks count when the pool is not required or not available.
• Estimation rule of thumb: take your honest guess of how long a task takes and multiply by 2. You are not slow; everyone estimates this badly, including professionals. Last year’s claws are the proof.
• Deliverables bigger than one sprint must be split. “Working claw” is not a Sprint 1 deliverable. “Claw jaw prototype closes on a PVC pipe at the bench” might be.

Activity: Draft Your Team’s Sprint 1 Commitment (team artifact)

As a team, draft 3 to 5 deliverables for Sprint 1. For each one write:

1. The deliverable, phrased as something demonstrable (“X does Y at pool day / at the bench”)
2. Who owns it (one name; owners can have helpers, but one person answers for it)
3. Your doubled time estimate in class sessions
4. What parts it needs, if any (this feeds the BOM card, 0.5)

Sanity check before submitting: add up the session estimates per person. If anyone is over 6, you have overcommitted and must cut or split.

Your Status Report

Once each sprint, due before your 1-on-1 in Week 3, you write a status report: goals and progress against them, a photo or screenshot, concerns, your hours, and your retro. It is how the teacher and your team track a commitment like the one you just made without anyone chasing anyone down. See Your Three-Week Status Report for the format and where it goes. Start it now and add to it as you go, so every deliverable you just committed to shows up in a Progress row by the time you print it.

Clearing This Card

Your team’s commitment is accepted at sprint planning after teacher review, AND you individually pass a 90-second oral check: pick one deliverable you own or help with, and explain what “done” looks like for it and what could make it slip. Complete or Not Yet.

If You Miss This Class

Read the resource, then write a personal sprint commitment for your own work that meets the same four requirements, and take the same oral check. Your items get merged into your team’s plan when you return.

Why This Matters for Competition

MATE scores detailed project planning directly in the technical documentation, and the season has hard deadlines that do not move. But the deeper reason is the one you already know: every claw that failed, failed at estimation before it failed at engineering. This card is where we stop letting that happen by accident.

Card 0.4: Score Autopsy, Reading a MATE Scoresheet

Before Class Reading: Where the Points Actually Are

Every team believes it knows how MATE scoring works: robot does tasks in the pool, tasks earn points, best robot wins. Every team is about one-third right.

MATE Ranger scoring rests on three pillars, and the pool is only one of them. The product demonstration, your mission runs, is the pillar everyone sees. But the engineering and communication pillar, your technical documentation, your engineering presentation, and related deliverables, is worth roughly as much as the flying, and the safety pillar runs through everything: inspections, deductions, and points awarded for protocol you either perform or forfeit. Teams routinely lose more points on land than in the water, while spending nearly all their season preparing for the water.

Think about what that means strategically. Pool points are the most expensive points available: they require a finished, working, practiced robot, and they can evaporate in one bad run, one blown fuse, one flooded connector. Documentation and presentation points are cheaper: they reward work that cannot break on competition day, that accumulates all season, and that a disciplined team banks in advance. Safety points are the cheapest of all: they are lost, not won, by teams that treated protocol as a formality.

None of this means the pool does not matter. It means a team’s plan should be built from the actual price list, and the only honest price list is last year’s scoresheets. Not memory. Not vibes. The sheets. Where did our points come from? Where did the available points go unclaimed? Was the cause skill, time, planning, practice, or a rule we did not know existed? “We ran out of time” is almost never a root cause; it is a symptom with a history, and the history is usually visible in the sheets.

This is called an autopsy for a reason. It is unsentimental, it works from evidence, and its purpose is not blame; it is that next year’s body stays alive. Everything this class chooses to build, practice, and study this season should be able to point at a line in the autopsy and say: that is why.

Prep prompt (bring in writing, BEFORE seeing the scoresheets): Predict our autopsy. Write down where you believe this team lost the most points last season, your rough guess of how many, and what you believe the root cause was. Be specific and be honest. In class you will compare your prediction against the actual sheets, and the gap between what we believe and what the record shows is the whole lesson. Written after seeing the sheets, this prompt is worthless, so date your notes.

Unit: 0, Engineering Process Format: Team analysis workshop + short presentations Time: Two sessions: one to analyze, one to present findings Prerequisites: None. This is the anchor of Sprint 0.

Core Question

Last season is data. Where did our points actually come from, where did they leak, and what does that evidence say we should build and practice this year?

Resource (~10 minutes)

1. The teacher hands out last season’s actual scoresheets and the scoring rubrics: mission runs, engineering presentation, technical documentation, and safety.
2. Key structure to notice: MATE scores three roughly equal pillars. Product demonstration (the pool runs), engineering and communication (presentation plus documentation), and safety. Teams routinely lose more points on land than in the water.

Activity: The Autopsy (team artifact)

Each team takes one scoring area and answers, in writing, with numbers from the sheets:

1. What was the maximum available and what did we earn?
2. Where were the three biggest point losses, specifically?
3. For each loss: was the cause skills, time, planning, practice, or something we did not know about? Be honest; “we ran out of time” usually traces back to something earlier.
4. What ONE change this season most cheaply recovers the most points?

Then present findings to the class in 5 minutes, seminar rules in effect: claims need the numbers behind them.

Clearing This Card

Contribute to your team’s written autopsy and presentation, and pass a 90-second oral check on someone ELSE’s area: after the presentations, explain one finding another team made and whether you buy their proposed fix. This forces the whole picture, not just your slice.

If You Miss This Class

Read all teams’ written autopsies, then take an extended oral check (3 minutes) covering two areas.

Why This Matters for Competition

Everything we choose to build, practice, and study this year should trace back to this evidence. When the semester plan says “design first” or “simpler claw” or “more driver practice,” the autopsy is the receipt. It also answers the fair question “why are we not building yet?” The autopsy IS robot work: it is requirements analysis, and skipping it is how last year happened.

Card 0.5: BOMs and Purchase Requests

Before Class Reading: The Part Is Not Coming

Here is a chain that runs through every school in America. A student needs a part. The student tells a teammate, who tells the teacher, verbally, in a hallway, without a link. The teacher, who is also teaching five classes, later tries to reconstruct which servo, from which vendor, in which quantity. The order goes into a district purchasing system, is approved by someone who has never heard of a thruster, gets processed in a weekly batch, ships, and arrives. Elapsed time: two to five weeks. The student, meanwhile, has been “blocked” for a month and the sprint is dead.

Professional engineering ran into this problem a century ago and invented the Bill of Materials, the BOM: a structured list where every needed part is one row, and every row is complete. Complete means someone who knows nothing about your project could place the order without asking you a single question: exact part name, exact link or part number, quantity, unit cost, total cost, need-by date, and one sentence saying what it is for. A BOM row with “some servos” in it is not a request; it is a future delay wearing a request’s clothing.

The second invention was lead time: the honest accounting of how long the chain takes. If school purchasing takes three weeks and your sprint is three weeks, then parts for a sprint must be requested BEFORE that sprint begins, which means during the previous sprint. This is not bureaucracy; it is causality. Our rule follows directly: requests for next sprint’s parts are due by the middle of the current sprint. Miss the window and the part does not exist next sprint, and no amount of needing it changes the arithmetic.

This season the intake runs through a supply chain manager who logs every request into a tracker anyone can read. The teacher still presses the actual purchase button, but “I asked for that weeks ago” stops being a memory dispute and becomes a checkable row with a date on it. Vague requests get bounced back the same day, which is a kindness: a bounced request costs you one day, and a vague one that enters the system costs you a month.

Prep prompt (bring in writing): Recall one time last season (or in any project you have done) when missing material stalled the work. Trace its chain in writing: who knew the part was needed, when, who was told, what was actually communicated, and where the request died. Then write the complete BOM row that would have prevented it, all six fields. The trace must be a real event you witnessed, with the details memory actually holds, gaps included; the gaps are evidence too.

Unit: 0, Engineering Process Format: Short instruction + hands-on request writing Time: 30 minutes Prerequisites: Card 0.3 helps, since sprint deliverables generate parts needs.

Core Question

“We need servos” is not information anyone can act on. School purchasing is slow and unforgiving: a vague request means the part does not arrive, and the sprint dies waiting. What does a request look like that turns into a part on the bench?

Resource (~10 minutes)

1. A BOM (bill of materials) is engineering’s shopping list. One row per part. A complete row has six fields: part name, exact link or part number, quantity, unit cost, total cost, need-by date, plus one sentence of what it is for.
2. The procurement rule this season: parts for the NEXT sprint must be requested by the middle of the CURRENT sprint. School ordering takes that long. Miss the window and the part does not exist next sprint; plan accordingly.
3. Requests go to the supply chain manager, who logs them and tracks status. The teacher submits all actual purchases. You can always see where your request is in the tracker; “I asked for it weeks ago” is checkable.

Activity: Write a Real Request (your artifact)

Take one deliverable from your team’s Sprint 1 commitment that needs a part. Write the complete BOM row for it. If your deliverable truly needs nothing, write the row for a real consumable the studio will need (heat shrink, solder, PVC fittings, zip… no, not zip ties near water; pick something legal).

Common failure modes to avoid, all real examples from last year:

• A link to a product category page instead of the exact item
• No quantity (“some”)
• No need-by date, which makes your request lowest priority automatically
• A part that violates a MATE rule (check voltage, materials, and size limits before requesting)

Clearing This Card

Your BOM row is accepted into the tracker with zero corrections needed, and you pass a 90-second oral check: “Your part arrives and it is wrong. Walk me back through your request row and tell me where the error could have entered.”

If You Miss This Class

Identical. Read the resource, write the row for a real need, submit to the tracker, take the oral check.

Why This Matters for Competition

Every stalled sprint last year had a missing part somewhere in its history. The BOM is also a scored artifact: MATE requires cost accounting in the technical documentation and the company spec sheet, and a tracker maintained all season makes that deliverable nearly free in May instead of a painful reconstruction.

Card 0.6: Running a Standup

Unit: 0, Engineering Process Format: Short instruction + do the job twice Time: 15 minutes of instruction, then two real standups Prerequisites: None. Take this one early.

Core Question

Every engineering organization on earth runs some version of this meeting, and almost all of them run it badly. A meeting that should take five minutes takes twenty-five, everyone leaves annoyed, and nothing was coordinated. What makes the difference between the five-minute version and the twenty-five-minute version, and can you be the person who produces the five-minute version?

Resource (about 10 minutes)

A standup answers three questions per person, one sentence each: what moved, what I am doing today, what is blocking me.

Your job as facilitator is four things and none of them involve having answers.

Call the order. Same order every time, or go around the circle. Do not ask “who wants to go next,” because that costs three seconds of silence per person and it lets the quiet people disappear.

Hold the sentence limit. When somebody starts explaining, cut in. “Give me the one sentence version.” This feels rude the first time and it is not rude, it is the job. Everybody’s time is on the line.

Park the blockers. This is the whole skill. Somebody names a problem, and the room’s instinct is to solve it. Yours is to say who can help with that, talk at 3:30, and go to the next person. The problem still gets solved. It gets solved by two people at a bench instead of seven people standing around.

Carry one sentence to studio sync. After team standups, each facilitator gives the room a single sentence: what your team is doing this session and what you are blocked on. Not a summary of the standup. One sentence.

What you are not doing: answering questions, assigning work, evaluating anybody, or reporting to Mr. B.

Two failure modes to watch for in yourself:

• The facilitator who talks the most. You are running the meeting, not being interviewed at it. Give your own update like everyone else and then get out of the way.
• The facilitator who lets it slide because cutting a friend off is uncomfortable. Five minutes times twelve sprints is an hour of your life. Cut them off.

Activity: Do the Job

Facilitate your team’s standup twice, on two different sessions. Not back to back if you can avoid it, because the second one should benefit from the first.

Both times, keep a note afterward, three lines in your notebook:

• How long did it run?
• How many blockers came up, and did you park them or did the room start solving?
• One thing you would do differently.

Clearing This Card

Two things.

Mr. B watched at least one of them. He floats between corners, so tell him which session you are facilitating so he is in your corner that day.

A 90-second oral check. The questions come from your own two standups, not from this page. Expect something like:

• Your second standup, somebody named a blocker. What was it and what did you actually say?
• Who talked the longest, and what did you do about it?
• One of your teammates gave a useless update, something like “worked on the claw.” What is the follow-up question that makes it useful?

You cannot pass this by having read the card. You pass it by having run the meeting.

Why This Matters for Competition

Two reasons, one obvious and one less so.

The obvious one: the engineering presentation is twenty minutes with a hard cutoff and four judges who have seen a lot of teams ramble. Somebody has to run that rehearsal and hold people to time. That person will have practiced.

The less obvious one: judges ask about project management, and they ask because it is a real predictor of whether a team ships. “We ran standups” is a weak answer. “We ran two-level standups with a rotating facilitator, and here is the rule we used to keep blockers out of the meeting” is a company that knows why it does what it does. Judges want the why.

Card 0.7: Reading a SID

Before Class Reading: The Map of the Machine

Before a MATE safety inspector lets our robot near the water, they read a single page: the SID, the System Integration Diagram. One page showing every electrical and every connected part of the vehicle: where power enters, where the fuse sits, what voltage runs where, which signals go to which components. Then they look at the actual robot and check whether the machine matches the map. If it does not, we fix it on the pool deck while our competition clock runs.

A SID is a schematic’s older, calmer sibling. A full schematic shows every resistor; a SID shows the SYSTEM: sources, protection, distribution, loads, and communication, at the level where you can reason about the whole vehicle at once. Reading one is a skill, and it has a grammar. Lines are wires or connections. Symbols mark fuses, converters, controllers, motors. Labels carry the numbers that matter: voltages, current ratings, wire gauges. The single most important convention: protection sits close to the source. A fuse guards everything downstream of it, so a fuse far from the battery leaves unprotected wire between them, which is exactly the wire that starts fires.

Why should every member of a team read the SID, not just the electrical crew? Three reasons. First, the inspector or a judge can ask anyone, and “that is not my subsystem” is an answer that costs points and respect. Second, the SID is where mismatches get caught: the student who traces the map in March finds the discrepancy that would have burned deck time in May. Third, and most practically, the SID is how you debug. When something dies at the pool, the question is always “what is upstream of the dead thing,” and the SID is the only place that answer lives.

There is also a quieter lesson in the document itself. A SID is the team’s electrical thinking made visible on one page, exactly like a DDR is one decision made visible. Machines whose reasoning is written down survive their builders. Machines whose reasoning lives in one student’s head graduate with that student.

Prep prompt (bring in writing): From memory, without looking anything up, sketch the power path of last year’s robot from the surface supply to one thruster: every component the electricity passes through, in order, with your best guess at the voltage at each stage and where the fuse sits. Wrong guesses are expected and useful. In class you will trace the real SID and grade your own sketch against it; the differences between your mental map and the actual machine are precisely what this card exists to fix.

Unit: 0, Engineering Process Format: Guided trace + individual exercise Time: 30 to 40 minutes Prerequisites: None required; pairs well with Ohm’s law and fuse cards later.

Core Question

The SID (system integration diagram) is the one-page map of everything electrical and everything connected on the vehicle. Safety inspectors read it before they let us in the water, and judges expect any team member to navigate it. Can you follow the electrons from the surface to a spinning thruster without getting lost?

Resource (~10 minutes)

1. Last season’s actual SIDs for Godzillah and for the float, printed large.
2. The legend: how the diagram shows power lines, signal lines, fuses, connectors, and voltage levels. The teacher traces ONE path aloud as a model: surface supply, through the fuse, down the tether, into the enclosure, through the ESC, to a thruster. Notice the fuse is as close to the source as the diagram (and the rules) demand.

Activity: Trace and Annotate (your artifact)

On your own printed copy:

1. Highlight the full power path from surface to one component the teacher assigns you (a thruster, a camera, the claw actuator, or a float component).
2. Label the voltage at three points along your path.
3. Mark where the protecting fuse for your path is, and write its rating.
4. Write one sentence: what physically happens on your path if that component shorts?
5. Circle one thing on the SID you cannot explain, and write the question. Unanswerable circles are the point; they become seminar and lesson material.

Clearing This Card

Turn in your annotated SID, then a 90-second oral check: trace a DIFFERENT path than the one you annotated, live, with the teacher pointing at the destination. Fluency with the map, not memorization of one route.

If You Miss This Class

Identical, done during build time. The printed SIDs live in the studio.

Why This Matters for Competition

The SID is a required scored submission, and safety inspection at the venue works directly from it: if the vehicle does not match the SID, we fix it on the deck while the clock runs. A team where everyone reads the SID catches those mismatches in the studio in March instead of poolside in May. This card is also the foundation for the fuse sizing and voltage drop cards later, where you will do the math on the paths you traced today.

Card 1.1: Archimedes and Buoyancy

Before Class Reading: The Two-Thousand-Year-Old Cheat Code

A steel ship floats. A steel bolt sinks. Same steel. If floating were about material or weight, the ship, weighing millions of times more, should plummet. It does not, and the reason was worked out in a bathtub twenty-two centuries ago.

Archimedes’ principle, one sentence: water pushes up on a submerged object with a force equal to the weight of the water that object displaces. Read it carefully, because the principle is about the WATER’s weight, not the object’s. Push a basketball underwater and the upward shove you feel is the weight of a basketball’s worth of water, roughly 7 kilograms of force, trying to reclaim its space. The ocean does not know or care what the object is made of; it only knows how much room the object takes up.

So floating is a contest between two numbers: the object’s weight pulling down, and the displaced water’s weight pushing up. The ship wins because its hull is mostly enclosed air; it displaces an enormous volume of water while weighing less than that volume of water weighs. The bolt loses because solid steel weighs about eight times more than the water it displaces. Shape the same steel into a hollow hull and the contest flips.

Between sinking and floating lies the state this class cares about most: neutral buoyancy, where the two numbers exactly tie and the object hovers, weightless, at whatever depth you put it. Divers chase this state. Submarines engineer it. Every ROV wants it, because a robot that naturally hovers spends its thruster power on the mission instead of on fighting its own weight.

The working tool falls straight out of the numbers. Fresh water weighs one gram per cubic centimeter. Therefore every cubic centimeter of displacement buys exactly one gram of upward force. A 5,000 cm³ robot hovers at 5,000 grams, floats below that, sinks above it. Trimming a robot stops being mystical: measure the volume, do the subtraction, add foam or lead until the ledger balances. You will do this arithmetic for real, first on a film canister, eventually on a 15-kilogram robot where guessing wrong costs a pool day.

Prep prompt (bring in writing): Commit to a prediction before class: a sealed object hovers, neutrally buoyant, at 1 meter deep. We move it to 3 meters and release it. Does it stay, rise, or sink? Write your answer AND your reasoning using the two-number contest above, then a second prediction: does your answer change if the object is a sealed rigid box versus a soft air-filled bag? You will test both in the tub, and defending or revising your written prediction is part of the oral check.

Unit: 1, Water Physics Format: Socratic opener + bench challenge Time: 40 minutes Prerequisites: None. First science card of the year.

Core Question

A steel ship floats. A steel bolt sinks. Same material, opposite fates. What actually decides whether something floats, sinks, or hovers, and how do we make a robot do the third one on purpose?

Resource (~10 minutes)

1. Archimedes’ principle, one sentence: the water pushes up on an object with a force equal to the WEIGHT OF THE WATER the object displaces. Not the object’s weight; the displaced water’s weight.
2. So the contest is: object’s weight (down) versus displaced water’s weight (up). Heavier than the water it displaces, it sinks. Lighter, it floats. Exactly equal, it hovers: neutral buoyancy, the state every ROV wants.
3. Freshwater weighs about 1000 kg per cubic meter, or 1 gram per cubic centimeter. That number is your tool: 1 cm³ of displacement buys you 1 gram of lift in the pool.

Bench Challenge (team, ~20 minutes)

Each team gets a film canister (or small capsule), washers, and a water tub. Make the canister hover: fully submerged, neither rising nor sinking, for 5 seconds.

Then the real exercise: BEFORE adjusting further, measure your canister’s volume (the teacher shows displacement measurement with a graduated cylinder), calculate what it should weigh to be neutral, weigh your ballasted canister, and compare. How close was your trial-and-error to the math? Which was faster? Which would you trust for a 15 kg robot where trial-and-error means draining a pool day?

Prep Notes / Written Artifact

1. Your measured volume, calculated neutral weight, and actual final weight, with the arithmetic shown.
2. Two sentences: why does a steel ship float? Use the word “displaces.”
3. One sentence: our float (Ebirah) changes its buoyancy without adding or removing any weight. Based on today, what MUST it be changing instead?

Clearing This Card

Turn in the written artifact, plus a 90-second oral check: the teacher hands you an object and its weight; estimate what volume it needs to displace to hover, and say what you would add (foam? weight?) if it currently sinks.

If You Miss This Class

The tub, canisters, and scale stay available for two weeks. Run the challenge solo or with any cleared student, then same artifact and oral check.

Why This Matters for Competition

Buoyancy and ballast is a named section of the MATE technical documentation, and neutral trim is the difference between a robot that flies and one that fights you through every mission task. The 1 gram per cm³ tool from today is the same math the team uses to trim Godzillah, and question 3 is the entire operating principle of the float you will tune this season.

Card 1.2: Pressure vs. Depth

Before Class Reading: The Patient Squeeze

Hold your hand out. Right now, a column of air reaching to the edge of space is pressing on it with about one kilogram of force per square centimeter. You do not notice because you have never felt anything else, and because you are pressurized from the inside to match. That everywhere-pushing force is one atmosphere, about 101 kilopascals, and it is the baseline every diver, submarine, and ROV starts from before touching the water.

Water is roughly 800 times denser than air, so the pressure column grows 800 times faster as you descend. The working rule: every 10 meters of fresh water adds another full atmosphere. At 10 meters you carry double the surface pressure. At 2.5 meters, our float’s target depth, the water alone adds about 25 kilopascals, a quarter of an atmosphere, on top of the air’s 101. Note the bookkeeping trap hiding in that sentence: GAUGE pressure counts only the water; ABSOLUTE pressure includes the atmosphere too. Sensors report one or the other, and a program that confuses them believes the surface is 10 meters underwater. That exact bug has shipped on real vehicles.

What does the squeeze actually do? To rigid, sealed things, mostly nothing, until it finds a weakness: a flat panel that can bow, an O-ring seated wrong, a bubble in potting compound. Pressure is patient and probes everything equally from all directions. To compressible things, air pockets, foam, syringes, it does something more interesting: it shrinks them. A trapped air volume at 10 meters occupies half its surface size. This is why cheap foam gets crushed at depth, why a “sealed” bag behaves differently from a rigid box, and, as you will see in the next reading, why shrinking volume is the secret behind how floats fly.

The numbers stay friendly at our scale: a pool is 1.4 atmospheres absolute at the bottom, gentle. But the same arithmetic runs all the way down. The bottom of Monterey Canyon, in our regional’s backyard, sits under more than 350 atmospheres, where every unprotected air space in a machine simply ceases to exist. The vehicles that work there are ours, scaled up, engineered against the identical rule you can verify this week with a syringe and a tape measure.

Prep prompt (bring in writing): Before class, seal a plastic syringe at exactly half its volume (or imagine doing so) and commit to two written predictions: where will the plunger sit at 2.5 meters, and at 10 meters? Show the arithmetic behind each prediction, not just the answer. You will test at whatever depth our column allows and defend or revise your numbers against your own measurement; the oral check starts from the gap between your prediction and what you observed.

Core Question

Every 10 meters of water adds another full atmosphere of squeeze. What does that do to our enclosures, our syringes, and our float at 2.5 meters?

Resource (~10 min)

1. The rule: pressure increases about 1 atmosphere (101 kPa) per 10 m of fresh water, on top of the atmosphere already pressing down at the surface.
2. Demo: a water bottle with three holes at different heights. Watch which stream shoots farthest and explain why before anyone says it aloud.

Activity

1. Seal a syringe at half volume. Predict, in writing, its plunger position at 2.5 m and at 10 m. Then test at whatever depth the tub or a dive weight line allows and compare.
2. Calculate absolute pressure at: the pool bottom (4 m), the float’s target depth (2.5 m), and the deepest point of Monterey Canyon (about 3,600 m). Show work.

Clearing This Card

Turn in predictions and calculations, plus a 90-second oral check: “Our enclosure is rated to 2 atmospheres absolute. How deep can it go, and what safety margin would you want before trusting it?”

If You Miss This Class

Same activity solo during studio time; the tub and syringes stay out for two weeks. Same oral check.

Why This Matters

Pressure ratings drive enclosure and penetrator design, and the pressure-to-depth conversion is the exact math the float’s sensor code performs every cycle. You will meet this equation again in Card 3.7 as running code.

Card 1.3: Buoyancy Control and the Argo Mechanism

Before Class Reading: The Machine That Swallows the Ocean

Somewhere in the Pacific right now, a torpedo-shaped robot with no propeller is rising from a kilometer down. Nothing pushes it. It burned almost no energy to start the trip. It will surface, phone home through a satellite, and sink again, and it has been repeating this cycle for years on a battery that would barely run a laptop. Around four thousand of these Argo floats are doing this as you read, and the trick that moves them is the one your float uses in our pool.

Recall the two-number contest from Reading 1.1: weight down versus displaced water’s weight up. To make a vehicle rise or sink on command you must change one of those numbers. Changing weight is the obvious move, and it is terrible: dropping ballast is one-way, and taking on water invites the ocean into your electronics. The elegant move is the other number. Keep the mass exactly the same and change the VOLUME. A piston extends and the vehicle occupies more space, displacing more water, and the up-force grows: it rises. The piston retracts, the vehicle shrinks, displaces less, and it sinks. Nothing was added or removed. The machine swallows a little of its own volume and the ocean does the rest.

Argo floats pump oil between an internal reservoir and an external bladder, inflating themselves slightly to rise. Our float drives a piston with a motor. Same physics, different plumbing. And notice how absurdly efficient this is: energy is spent only during the volume CHANGE, seconds of motor time, while the rising and sinking themselves are free, powered by the imbalance. This is why an Argo float lives for years and why our float needs no thruster at all.

You will build the two-dollar version this week: the Cartesian diver, a toy that is genuinely the same machine. A flexible bottle, water, and a barely-floating dropper with an air pocket. Squeeze the bottle and pressure rises everywhere inside (Reading 1.2), compressing the dropper’s air pocket, shrinking its displaced volume, and down it goes. Release, the pocket re-expands, and it rises. Every arrow in that chain, pressure to volume to displacement to force, is the arrow your float’s piston pulls on purpose.

Prep prompt (bring in writing): Before class, write the complete cause-and-effect chain for the Cartesian diver sinking, as numbered steps from “hand squeezes bottle” to “diver sinks,” with no skipped links. Then one prediction: our float’s piston motor draws current when changing depth. Does it also draw meaningful current while HOLDING a depth? Commit to yes or no and your reasoning; you will check your answer against the real float’s behavior, and the oral check will ask you to map each step of your diver chain onto the corresponding part of Ebirah.

Core Question

Our float dives and surfaces on command without any thruster and without dropping any weight. Real Argo floats have done this in the open ocean for 20 years. What is the trick?

Resource (~10 min)

1. Recall from 1.1: hover means weight equals displaced water’s weight. You can change weight, or you can change displacement. Argo floats, and ours, change displacement: a piston or bladder changes the vehicle’s VOLUME while its mass stays constant.
2. Look at the actual buoyancy engine on our float (or photos of it). Find the part that changes volume.

Activity: Cartesian Diver

Build one: a flexible bottle, water, and a dropper or packet ballasted to barely float. Squeeze and it sinks; release and it rises. Then write the explanation chain: squeezing raises pressure, which compresses the air pocket, which shrinks displaced volume, which reduces buoyant force below weight, so it sinks. Every arrow in that chain must be in your write-up.

Clearing This Card

The diver works, the explanation chain is complete, and a 90-second oral check: “Point at the part of your diver that corresponds to the piston on our float. What is different about how each changes volume?”

If You Miss This Class

Build the diver during studio time (10 minutes, materials in the bin), same write-up and check.

Why This Matters

This is the operating principle of a scored competition vehicle. A student who can walk a judge from the Cartesian diver to the float’s piston has answered the WHY question that wins engineering presentation points.

Card 1.4: Drag, Thrust, and Hull Shape

Before Class Reading: What the Water Charges You

Stick your flat hand out a car window at highway speed and tilt it. You just measured drag with your arm: the force a fluid charges for the crime of moving through it. Now do the thought experiment underwater, in a fluid 800 times denser, and you have the tax code our robot lives under.

Drag has a rate schedule, and its cruelest line is this: the force grows with the SQUARE of speed. Double your speed and the water charges quadruple the force, which requires quadruple the thrust, which, since power is force times speed, demands roughly EIGHT times the power. This single fact explains half of underwater vehicle design. It is why “just add bigger thrusters” is the most expensive sentence in robotics, why our robot cruises rather than races, and why a pilot who approaches a task slowly is not being timid; they are refusing an exponential bill.

What sets the base rate? Two things the designer controls. First, frontal area: how much silhouette the vehicle shows the water in its direction of travel. Every camera housing, every bracket, every accessory bolted to the front buys its capability with permanent drag. Second, shape. A flat plate and a smooth fairing with the same silhouette pay wildly different rates, because drag is partly about how violently the water has to get out of the way and how messily it closes up behind. Blunt shapes tear the water and leave a churning, low-pressure wake that literally sucks the vehicle backward. Streamlined shapes part the water and let it close politely. The difference is not subtle; it can be several-fold.

There is a tradeoff hiding here, and it is worth saying honestly: MATE robots are boxy frames, not torpedoes, and that is often correct. An open frame is easy to build, easy to modify, easy to service at a pool day, and mission tasks reward a stable working platform more than a fast one. Our vehicle mostly moves slowly and precisely, where drag matters less, then occasionally must hold position against its own tether’s pull, where it matters a lot. The point of this card is not that you must streamline everything. It is that shape and area are DECISIONS with a price, and a team should know the bill before, not after, bolting one more thing to the bow.

Prep prompt (bring in writing): Before class, commit to a written ranking: a sphere, a flat disk, and a streamlined teardrop, all of equal mass, are dropped through a tall water column. Predict their finishing order and, for the shape you rank slowest, explain in two sentences WHERE the water is charging it most (front, behind, or both). You will time all three yourself; the oral check compares your predicted ranking and reasoning against your own stopwatch data, and asks what your result implies about one specific object currently bolted to Godzillah.

Core Question

Two objects with the same weight and volume can need wildly different force to move through water. What does shape cost us, and how much thrust does our robot actually need?

Resource (~10 min)

1. Drag grows with the square of speed: double your speed, quadruple the drag. This is why “just add bigger thrusters” is an expensive answer.
2. Frontal area and shape both matter. A flat plate and a fairing of the same frontal area have drastically different drag.

Activity

1. Drop race: three objects of equal mass but different shapes (sphere, flat disk, streamlined form) fall through a tall water column. Time them over a marked distance, three trials each, record and rank.
2. Estimate: using thruster datasheet curves, how fast can the ROV realistically cruise, and what happens to station-keeping when a mission requires pushing against a current or dragging a payload?

Clearing This Card

Turn in the timed data table and the estimate, plus a 90-second oral check: “The team wants to bolt one more camera housing on the front. What questions do you ask before saying yes?”

If You Miss This Class

The drop column and shapes stay available; run the trials solo, same artifact and check.

Why This Matters

Frame geometry decisions get made early and are painful to reverse. This card gives you the vocabulary to argue about them in DDRs with numbers instead of vibes.

Card 2.1: Ohm's Law

Core Question

Voltage, current, resistance: three numbers locked together by V = IR. If you can measure any two, you know the third. Can you prove the law is real at the bench?

Resource (~10 min)

Multimeter basics demo: measuring voltage (across), current (through, meter in series), and resistance (component isolated). The three most common meter mistakes, shown live: wrong port, wrong mode, measuring resistance in a live circuit.

Activity

1. Build the simplest circuit: battery pack, resistor, jumpers. For three different resistors: measure R directly, measure V across it, measure I through it, and check whether V = IR holds within reason. Record all nine numbers in a table.
2. One prediction round: given the battery voltage and a fourth resistor’s band code, predict the current BEFORE wiring it. Then wire and measure. Circle your error percentage.

Clearing This Card

The data table with the prediction round, plus a 90-second oral check: “A thruster draws 10 A at 12 V. What is its effective resistance, and what happens to current if a corroded connector adds 1 ohm in series?”

If You Miss This Class

Bench kit stays in the bin for two weeks; same activity and check during studio time.

Why This Matters

Every fuse choice, tether calculation, and burned component conversation this season stands on this card. It is the prerequisite for 2.2 and 2.5.

Card 2.2: Power, Fuse Sizing, and Electrical Safety

Core Question

The fuse is the one component we install hoping it dies. How do you size a fuse so it ignores normal operation but sacrifices itself before the wiring does?

Resource (~10 min)

1. Power: P = VI. A thruster pulling 15 A at 12 V is a 180 W machine; six of them is why our fuse math matters.
2. The MATE rule: read the fuse and overcurrent protection requirements in the manual, including where the fuse must sit and how its rating relates to measured full-load current.
3. The stall story: what a jammed thruster draws versus a free-spinning one, and why last season’s fuse events happened.

Activity

Size our actual main fuse: using thruster datasheet currents plus every other load on the SID, compute worst-case realistic draw, apply the manual’s sizing rule, and pick a real fuse value. Then annotate a copy of the SID with your calculation. Compare your answer to what the robot actually ran last year and explain any difference.

Clearing This Card

The annotated SID with shown work, plus a 90-second oral check: “The fuse blows during a mission run. Walk me through what you check, in order, before installing a new one.”

If You Miss This Class

Datasheets and SID copies are in the folder; same artifact and check during studio time.

Why This Matters

The fuse calculation is literally inspected at competition safety review, and the annotated SID becomes real documentation. This card produces a competition artifact, not homework.

Card 2.3: Wire Prep, Splicing, and Waterproofing

Unit: Electricity Format: Bench demo + hands-on practice (this is a studio skill card, not a seminar card) Time: 30 to 40 minutes plus practice Prerequisites: None. Pairs well with Card 2.7 (Connection Autopsy), taught later, once you have splices of your own to inspect.

Core Question

Salt water is conductive, corrosive, and patient. Every splice on the ROV is a place it can win. How do you make a connection that carries current, survives strain, and keeps water out for an entire season?

Resource (~10 minutes)

1. Teacher bench demo: strip, splice, solder, adhesive-lined heat shrink. Watch for the three failure points called out: nicked strands, cold joints, heat shrink that is not adhesive-lined.
2. Read the “Cabling and Connectors” portion of the MATE safety inspection requirements in the 2026 manual. Note what inspectors reject on the spot.

The Skill Ladder (each step checked before you move on)

1. Strip 5 wires of two different gauges with zero nicked or cut strands. Nicked strands fail inspection: a nick is a future break.
2. Splice two wires using a lineman or Western Union splice. It should hold your full pull strength BEFORE solder.
3. Solder the splice. Shiny, wetted, no blobs. A cold joint is gray and dull.
4. Seal with adhesive-lined heat shrink, sized so the adhesive squeezes out slightly at both ends.

Clearing This Card

Your artifact is a finished splice sample tagged with your name. It clears when it passes all three tests:

• Pull test: teacher pulls hard on it. It holds.
• Dunk test: 24 hours submerged, then multimeter continuity check and visual inspection for water intrusion under the shrink.
• 90-second oral check: name the three failure points from the demo and explain which test would catch each one.

Passing samples go on the studio wall as the reference standard. Future students judge their work against the wall.

If You Miss This Class

Watch any reputable soldering and splicing tutorial (search “lineman splice heat shrink”), then complete the same skill ladder during build time and clear with the same three tests. The tests do not care when you learned it.

Why This Matters for Competition

Safety inspectors physically examine your wiring and can fail connections on the spot, which costs you pool time to fix at the venue. And in the water, one flooded splice can end a run. This card is also a gate: students who have cleared it are the ones authorized to make permanent electrical connections on Godzillah. Everyone else breadboards.

Card 2.4: Penetrators and Enclosure Sealing

Core Question

Every wire that enters the hull is a hole in the boat. A penetrator is how we make that hole a promise instead of a leak. What makes one trustworthy?

Resource (~10 min)

1. Teardown: pass around a disassembled commercial penetrator. Identify the sealing surfaces, the O-ring, and the potted volume. Where would water try first?
2. The three sealing strategies: O-ring compression, potting compound, and cable glands. Where each is used on our vehicles and why.

Activity

Pot a practice penetrator: a wire through a fitting, filled with epoxy or potting compound, with proper wire prep (a cleared 2.3 splice sample makes a good insert). Label with your name and the date. After cure, it goes in the dunk tank with a vacuum or pressure assist if available, then gets continuity-checked and inspected.

Clearing This Card

Your potted sample passes the dunk and continuity test, plus a 90-second oral check: “Rank the three sealing strategies by how gracefully they fail, and tell me which failure you would rather have at 4 meters.”

If You Miss This Class

Potting station stays set up for two weeks; cure time means plan ahead. Same tests and check.

Why This Matters

Enclosure floods end seasons. The students cleared on 2.3 and 2.4 are the ones authorized to make and service hull passthroughs on Godzillah and the float.

Card 2.5: Series, Parallel, and Tether Voltage Drop

Core Question

The power supply says 12 volts. The thrusters at the end of our tether disagree. Where did the missing volts go, and how much tether can we afford?

Resource (~10 min)

1. Series resistances add; the tether’s copper is a resistor in series with everything on the robot. Parallel loads share current; every load added raises total current, which raises the tether’s toll.
2. Wire gauge chart: resistance per meter for the gauges in our tether.

Activity

1. Measure the actual round-trip resistance of a spare tether length with the meter, and compare against the gauge chart’s prediction.
2. Calculate voltage at the robot for our real tether length at 10 A, 20 A, and worst-case draw from your 2.2 work. Graph volts-at-robot versus current (three points, hand-drawn is fine).
3. One design question in writing: how does running higher voltage down the tether with conversion at the robot change this picture? (This is why real ROVs do it.)

Clearing This Card

Measurements, the graph, and the design paragraph, plus a 90-second oral check: “The robot browns out when all thrusters fire. Give me two fixes that do not involve buying a new tether, and their costs.”

If You Miss This Class

Spare tether and meter in the studio; same artifact and check.

Why This Matters

Voltage drop explains a whole family of mysterious pool failures: cameras rebooting, ESCs cutting out, sluggish thrust under load. After this card, those stop being mysteries.

Card 2.6: Conductivity and Corrosion

Core Question

Pool water is gentle. Seawater is a conductive, corrosive electrolyte that attacks every exposed joint. What does it actually do to our electricity and our metal?

Resource (~10 min)

1. Measure resistance between two probes in distilled water, tap water, and salt water. Watch conductivity climb with dissolved ions.
2. Two corrosion modes we care about: plain rust over time, and galvanic or electrolytic corrosion, which is rust with a battery behind it, shockingly fast.

Activity

Corrosion race: three jars of salt water. Jar A, a bare steel fastener. Jar B, two dissimilar metals touching (steel and copper). Jar C, two fasteners wired to a low-voltage supply. Photograph on day 0, then check and photograph at each class for a week. Write three observations and rank the jars by damage.

Clearing This Card

The photo log with observations, plus a 90-second oral check: “Why does a powered, exposed joint corrode fastest, and what two practices from Card 2.3 prevent it on our robot?”

If You Miss This Class

The jars run on their own schedule; photograph them during studio time and write the same log.

Why This Matters

This is the WHY behind every waterproofing rule in Unit 2, and conductivity itself shows up in mission sensor tasks. Corrosion is also the slow killer of vehicles that survive the season: this card is why we rinse.

Card 2.7: Connection Autopsy (Failure Modes)

Core Question

The studio keeps a box of dead things: flooded splices, corroded connectors, stripped servos, cracked potting. Every one failed for a reason. Can you read the reason out of the corpse?

Resource (~10 min)

Failure vocabulary: water intrusion, corrosion, fatigue, strain failure, cold joint, insulation damage, wrong-part-for-the-job. One worked example: the teacher autopsies one failed part aloud, evidence first, conclusion last.

Activity

In pairs, draw a failed part from the box. Produce a one-page failure report: photos or sketch, observed evidence, most likely failure mode, the chain of events that got there, and one specific change to design or process that would have prevented it. Evidence before conclusion; “it broke” is not a finding.

Clearing This Card

The failure report, plus a 90-second oral check where you defend your prevention recommendation against one challenge (“would that survive the pull test? the budget?”).

If You Miss This Class

The box is always there. Draw a part during studio time, same report and check.

Why This Matters

Failure analysis is the highest-value habit in engineering and the natural follow-up to any bad pool day. These reports feed DDRs directly: “we chose X because the autopsy of last year’s Y showed Z” is a judge-ready sentence.

Card 3.1: PWM

Core Question

Our controllers cannot output “62% power.” They can only switch fully on and fully off, very fast. How does flickering become throttle?

Resource (~10 min)

1. Duty cycle demo: an LED driven by PWM from a Pi or Arduino, swept from 5% to 95%. If a scope or logic analyzer is available, watch the square wave change while the brightness follows.
2. The two numbers that define a PWM signal: frequency (how fast it repeats) and duty cycle (what fraction is on). Servos and ESCs care about pulse WIDTH in microseconds; motors and LEDs care about duty percentage. Same idea, different dialects.

Activity

1. Wire the LED and write (or modify the provided) code to set duty cycle from keyboard input. Find the duty cycle where the LED first looks “half bright” and compare with a neighbor; discuss why eyes disagree with the math.
2. On paper, sketch the waveform for 25%, 50%, and 75% duty at the same frequency, labeled with on-time and period.

Clearing This Card

Working demo plus labeled sketches, and a 90-second oral check: “A servo expects pulses between 1000 and 2000 microseconds. What is the pulse width for center, and what happens if we send it a motor-style 50% duty at 1 kHz instead?”

If You Miss This Class

Bench kit and starter code stay available; same demo, sketches, and check during studio time.

Why This Matters

PWM is the shared language beneath thrusters, servos, and the claw. Cards 3.2, 3.3, and 3.5 all assume you speak it.

Card 3.2: ESCs and Brushless Motors

Core Question

A brushless thruster has three wires and no idea what to do with plain DC. The ESC between the controller and the motor is doing something clever thousands of times per second. What?

Resource (~10 min)

1. Brushed vs. brushless in one minute: brushed motors commutate mechanically (and wear out); brushless motors need electronics to energize three coil phases in sequence. The ESC is that electronics.
2. The interface: the ESC listens for servo-style pulses (from 3.1) and translates them into three-phase power. Arming sequences, calibration, and the beep codes, demonstrated live.

Activity

Bench-spin station, safety first: thruster clamped, props guarded or removed, current-limited supply. In pairs: wire controller to ESC to thruster, perform the arming sequence, and sweep from stop to low throttle. Watch the ammeter as you load the prop wash with a paddle: connect what you see to the stall discussion from 2.2. Log idle current and your maximum tested current.

Clearing This Card

The current log, plus a 90-second oral check: “The thruster twitches but will not spin. Give three plausible causes across signal, ESC, and motor, and the test for each.”

If You Miss This Class

The bench-spin station requires a cleared partner or the teacher present (spinning things); schedule 15 minutes during studio time.

Why This Matters

Six of these chains drive Godzillah. A student who can arm, calibrate, and diagnose an ESC chain at the bench is the student who fixes it on the pool deck with the clock running.

Card 3.3: Servos and Steppers (Choosing an Actuator)

Unit: Control & Actuation Format: Bench stations + short Socratic close Time: 40 minutes Prerequisites: Card 3.1 (PWM)

Core Question

The claw needs to move to a position and hold it. A servo, a stepper, and a plain DC motor can all move things. They fail differently, cost differently, and are controlled differently. How do you pick, and how do you defend the pick?

Resource (~10 minutes)

Two bench stations, 5 minutes each:

1. Servo station: hobby servo on a signal generator or Pi. Sweep the PWM pulse width from 1.0 to 2.0 ms and watch position follow. Grab the horn gently and feel it fight back. That fight is closed-loop feedback: the servo knows where it is.
2. Stepper station: stepper on a driver. Step it, count steps, then stall it by hand and step again. Notice it is now WRONG about where it is and has no idea. Open loop: it counts, it does not know.

Concept Core

• Servo: position feedback built in, PWM pulse width commands an angle, limited rotation range, holds position under load. Cheap hobby servos are not waterproof and their gears strip.
• Stepper: precise repeatable steps, full continuous rotation, but loses position silently when stalled and draws holding current constantly.
• DC motor + limit switches: dumbest and often most reliable. Two states, two switches, done.
• The engineering question is never “which is best.” It is “which failure can this mission tolerate.”

Socratic Close (10 minutes)

Last season’s claws aimed for complexity and ran out of time. Given what you just felt at the two stations: what is the simplest actuator that meets a claw’s real requirements? What requirement would have to exist before a stepper earns its complexity? Would you rather a claw that grips weakly or one that lies about its position?

Clearing This Card

• Oral check (90 seconds): you are handed a mission task description from the manual. Pick an actuator for it and defend the pick, including the failure mode you are accepting. There is no single right answer; there are defensible and undefensible ones.
• Teach-back alternative: run both bench stations for a teammate who has not cleared the card, and field their questions.

If You Miss This Class

The stations stay set up for two weeks. Run them solo during build time (10 minutes), then take the oral check. The feel of the servo fighting back and the stepper losing count is the lesson; a video is a weak substitute, so hands on the hardware is required for this card.

Why This Matters for Competition

This card feeds directly into the claw DDR your team will write this season. “We chose a servo because it holds position under load and the mission never needs more than 180 degrees, and we accepted the waterproofing burden” is a judge-ready sentence. Actuator choice is also exactly the kind of decision where teams historically overreach; this card exists so simplicity is a choice you can defend, not a compromise you apologize for.

Card 3.4: Ethernet and ROV Networking

Unit: Control & Actuation Format: Hands-on (crimping) + short concept discussion Time: 40 minutes Prerequisites: None, but Card 2.5 (Tether Voltage Drop) pairs well

Core Question

When you push a joystick topside, that command travels down a tether as network traffic and a computer underwater obeys it. What is actually moving through that cable, and how do the two ends find each other?

Resource (~10 minutes)

1. Look at a cut-open ethernet cable: 4 twisted pairs, 8 conductors. Why twisted? (Noise rejection. Untwist a pair and you have built an antenna.)
2. Read the network section of the team float repository README (github.com/slvusd/float): the float serves on port 5000, the controller on port 5001. Find the IP addresses in config.py.

Concept Core (discussion, not lecture)

• An IP address is a street address; a port is an apartment number. One device, many services.
• Topside laptop and the Pi must be on the same subnet to talk. What happens when they are not? (This is the most common “it worked yesterday” failure at the pool.)
• Ping is your first diagnostic. If ping fails, nothing above it can work. Debug from the bottom of the stack up: link light, ping, then application.

Hands-On

Crimp an RJ45 connector to T568B using the wiring chart at the bench. Test it with the cable tester: all 8 lights, in order.

Clearing This Card

Two parts:

• Artifact: your tested cable, tagged with your name. All 8 conductors pass.
• Oral check (90 seconds): the ROV is unresponsive at the pool. The teacher plays the ROV and answers your diagnostic questions. Walk the stack: what do you check first, second, third, and what does each result tell you? Clearing requires reaching the fault in a sensible order, not guessing the fault itself.

Teach-back alternative: run a 5-minute “pool day network triage” walkthrough for your team using a real failure from a past pool day.

If You Miss This Class

Same resource, same crimp, same oral check during build time. If you cannot attend a bench session, schedule 10 minutes at the start of any class.

Why This Matters for Competition

Network failures are the classic pool-day time killer, and pool minutes are the scarcest resource we have. A team where every member can triage link light, ping, and application in order recovers in two minutes instead of twenty. Judges also routinely ask how topside talks to the vehicle; this card is that answer.

Card 3.5: Feedback Control and PID

Unit: Control & Actuation Format: Socratic seminar (or self-study path below) Time: 30 to 40 minutes Prerequisites: Card 3.1 (PWM), Card 3.7 helps but is not required

Core Question

Our float needs to stop AT 2.5 meters, not blow past it and bounce. A human can do this by feel. How does a machine do it with only a pressure sensor and a piston?

Resource (read/watch before seminar, ~10 minutes)

1. Read TUNING.md from the team float repository (github.com/slvusd/float). Focus on what kp, ki, and kd each do.
2. Watch: any short “PID explained” video of your choice (search “PID controller explained simply”, pick one under 8 minutes). Note one thing that made sense and one thing that did not.

Prep Notes (bring to seminar, this is your artifact)

Answer in writing, a few sentences each:

1. In your own words: what is “error” in a control system? What is the error if the float is at 1.9 m and the target is 2.5 m?
2. The P term pushes harder when error is bigger. Why is P alone not enough? What goes wrong?
3. Our float’s actual starting gains are kp = 40.0, ki = 8.0, kd = 15.0. Pick ONE of these and predict: what would happen at the pool if we doubled it?
4. Write one honest question you still have. (Real questions score; fake questions are obvious.)

Seminar Questions (teacher facilitates, students carry it)

• Why does the float overshoot at all? Where does the momentum come from?
• What does the D term “know” that the P term does not?
• Why does the code cap the integral term (imax = 0.5)? What disaster is that preventing?
• Is there a version of this problem in the ROV, not just the float? Where?
• Cars, thermostats, drones: where else is PID hiding in your life?

Clearing This Card

Choose one:

• Oral check (90 seconds, during build time): Explain to the teacher what happens to the float if kd = 0, and why. Then: your team doubles kp and the float oscillates violently. What do you adjust and why?
• Teach-back (5 minutes at sprint standup): Teach your team the three terms using the float as the example. Your team asks one question; you field it.

If You Miss This Class

Do the resource, write the prep notes, then clear via oral check or teach-back as above. Same standard, same artifact. Nothing extra, nothing less.

Why This Matters for Competition

The float’s depth hold is worth real points, and judges will ask WHY your control approach works, not just what it does. A student who owns this card can defend the PID choice at the engineering presentation. Pool tuning of these exact gains is a sprint task, so this lesson feeds directly into build work.

Card 3.6: Joystick Mapping

Core Question

A joystick reports numbers; a thruster wants pulses. The function between them decides whether the robot feels surgical or drunk. What should that function be?

Resource (~10 min)

1. Read raw axis values from our controller live on screen. Notice it never quite rests at zero: sensor noise and spring slop. This is why deadzones exist.
2. Three mapping ideas on the whiteboard: straight linear, deadzone plus linear, and an expo curve that softens the center and keeps full authority at the edges.

Activity

Using the provided starter script, implement a deadzone and one nonlinear mapping. Test each mapping on the bench-spin station or LED rig and have a partner do a blind “feel test”: which mapping makes it easiest to hold 10% output steadily? Record which mapping won and why.

Clearing This Card

Your mapping code plus the feel-test result, and a 90-second oral check: “The pilot says fine positioning during the coral task is impossible. Which part of the mapping do you change, and what is the tradeoff at full speed?”

If You Miss This Class

Starter script and controller in the bin; recruit any student for the blind feel test during studio time.

Why This Matters

Mission points come from precise manipulation, and precision lives in this function. This card also produces a DDR candidate: the pilot’s mapping is a real design decision the team should be able to defend.

Card 3.7: Sensors and Unit Conversion

Core Question

The pressure sensor speaks kilopascals. The judges, the mission, and the required data plot all speak meters. Somebody has to do the conversion, and that somebody must be provably right.

Resource (~10 min)

1. Derive it together from Card 1.2’s rule: depth in meters equals gauge pressure in kPa divided by 9.81 (fresh water). Note the trap: ABSOLUTE pressure includes the atmosphere; subtract surface pressure first or your robot thinks air is 10 meters deep.
2. Find the actual conversion line in the float’s code and check whether it handles that trap.

Activity

1. Write the conversion as a small function with two test cases you compute by hand first: surface, and 2.5 m.
2. Verify physically: sensor at a measured depth in the test column (even 0.5 m works), read the kPa, run your function, compare against the tape measure. Record the error.

Clearing This Card

Function plus verification numbers, and a 90-second oral check: “Competition is in salt water. What changes in your function and roughly by how much?”

If You Miss This Class

Test column and sensor rig stay available; same artifact and check.

Why This Matters

This exact function decides whether the float holds 2.5 m or holds 2.5-ish. It also feeds the required depth-vs-time plot, so your test cases here are literally pre-competition quality control.

Card 3.8: Cameras, Analog vs. USB

Core Question

An old-school analog camera and a modern USB camera can watch the same claw. One is blurry and instant; one is sharp and late. Which does a pilot actually want?

Resource (~10 min)

1. Both camera chains set up side by side: analog camera to a small screen, USB camera through the Pi to the topside display. Same scene.
2. The tradeoff vocabulary: resolution, latency, bandwidth down the tether, failure complexity (how many things must work for the picture to exist).

Activity

Measure latency for real: point each camera at a running stopwatch (phone timer with milliseconds) and photograph the camera’s display and the stopwatch in the same frame. The difference between the two readings is that chain’s latency. Three trials each, record the table. Then a two-minute manipulation test: a partner moves a target while you guide them using only each camera’s view.

Clearing This Card

The latency table plus a written recommendation: which camera goes on the claw and which surveys the scene, justified with your numbers. 90-second oral check: one challenge to your recommendation.

If You Miss This Class

Both chains stay assembled for two weeks; the stopwatch method works solo.

Why This Matters

Camera placement and selection is a classic DDR, and latency is the invisible variable teams forget until the pilot cannot grab anything. You now own the numbers.

Card 4.1: The Terminal and SSH

Core Question

The robot’s computer has no screen, no mouse, and lives inside a sealed tube underwater. The terminal is how we reach it. Can you get in, look around, and run something?

Resource (~10 min)

Live demo of the eight commands that cover 90% of robot work: ssh, ls, cd, pwd, cat, cp, mkdir, python3. Plus the two lifesavers: tab completion and up-arrow history. Watch once; then it is your turn.

Activity: Scavenger Hunt

SSH into the studio Pi (address and credentials on the board). A trail of clues is hidden in the filesystem: a README points to a directory, which contains a file whose contents name another path, ending at a script. Run the script; it prints a code phrase. Write the code phrase and the full path where you found it. Rules: no GUI, no file manager, terminal only.

Clearing This Card

The code phrase plus a 90-second live check: the teacher names a file somewhere on the Pi; navigate to it and display its contents, narrating each command as you go. Fluency, not memorization; tab completion is encouraged, not cheating.

If You Miss This Class

The hunt stays live on the Pi all season. Do it during studio time; same live check.

Why This Matters

Every pool day involves someone SSHing into a vehicle to check, fix, or launch code. After this card, that someone can be you. This is also rung one of the Python ladder; nothing above it works without it.

Card 4.3: Data Logging

Core Question

At competition, the float must come back from its dive carrying proof: timestamped depth data in a specified format. What makes a log trustworthy, and what makes it garbage?

Resource (~10 min)

1. Read the float data requirements in the manual: what fields, what the packet must contain (team number, time, depth), and what the judges receive.
2. The three sins of logging, with real examples: no timestamps (data with no when), clock drift or wrong timezone, and buffering loss (the program died and took the last minute of data with it; this is why we flush or write line by line).

Activity

Write a logger: a script that, every second, records a timestamp and a value (use the real pressure sensor if the rig is free, otherwise the provided simulator function) into a CSV. Run it for two minutes, kill the process mid-run on purpose, and check: did your file keep everything up to the kill? Fix it if not. Then format one line of your data as a competition packet per the manual’s spec.

Clearing This Card

Your CSV, your kill-test result, and the formatted packet line, plus a 90-second oral check: “The judges say your timestamps are 8 minutes off from official time. What happened and what is your pre-dive checklist item that prevents it?”

If You Miss This Class

Simulator function and spec sheet on the class page; same artifact and check.

Why This Matters

This is not practice shaped like the competition; it IS the competition deliverable, built early enough to be boring by May. Boring is the goal.

Card 4.4: Plotting with matplotlib

Core Question

MATE wants a depth-versus-time graph as an image file, produced from your float’s data, fast, at the competition. Can your team generate it in one command?

Resource (~10 min)

The five lines that make a plot: import, read the CSV, plot x vs. y, label, save as JPG. Shown live, then dissected: which line controls what.

Activity

Using your Card 4.3 log (or the provided sample dive), produce the competition plot: depth on the y-axis (inverted, so down is down), time on x, title with team number and date, axes labeled with units, saved as a JPG, not screenshotted. Then break it on purpose: feed it a CSV with a missing line and see what happens; add the one fix that keeps it alive.

Clearing This Card

The JPG plus your script, and a 90-second live check: “Change the plot to show only the first 60 seconds” or a similar live modification.

If You Miss This Class

Sample data and the five-line skeleton are on the class page; same artifact and live check.

Why This Matters

This JPG is a scored deliverable. The team that has generated it fifty times in the studio does not sweat it on the deck. Also: this plot is how you SEE your PID tuning from Card 3.5; overshoot has a shape, and now you can look at it.

Card 4.5: State Machines

Core Question

The float’s mission is a sequence: wait, descend, hold, ascend, surface, transmit, repeat. Code that handles this as one long tangle of ifs becomes unfixable. What is the disciplined shape?

Resource (~10 min)

1. A state machine in plain terms: the system is always in exactly one named state; events or conditions cause transitions; each state has its own simple job. Whiteboard example: a traffic light, then a microwave (door open beats everything, which introduces guard conditions).
2. Look at the float mission description in the manual and list every distinct phase you can find.

Activity

1. Human state machine warm-up (5 min): three volunteers are states, the class calls out events, volunteers point to who becomes active. Fast, silly, and it works.
2. Real artifact: draw the complete state diagram for the float’s mission on paper: named states in circles, labeled transitions with their triggering conditions (“depth within 0.2 m of target for 5 s” beats “when it gets there”), including at least one failure path (what state do you enter if the target depth is never reached?).

Clearing This Card

The state diagram, plus a 90-second oral check: the teacher names a weird moment (“the float is ascending and the pressure sensor starts returning garbage”) and you trace what your machine does and whether that is acceptable.

If You Miss This Class

Mission description and a traffic-light example diagram are on the class page; same artifact and check.

Why This Matters

The float code’s structure is this diagram, and the diagram belongs in the technical documentation, where a clean state machine figure impresses judges far beyond its effort. Software team members will implement it; every team member should be able to read it.

Card 5.1: Safety Culture and the JSA

Core Question

Professional dive and marine operations write a Job Safety Analysis before work begins: what are we doing, what could hurt someone, and what do we do about it, in advance and on paper. Can you do that for your own bench?

Resource (~10 min)

1. The JSA anatomy: task steps in order, hazards per step, controls per hazard. A control is specific (“safety glasses at the soldering station”) not vibes (“be careful”).
2. Read one strong JSA from a past MATE submission and one weak one. Name three differences.

Activity

Write a real JSA for a task you will actually perform this season: soldering, bench-spinning a thruster, potting, lifting the ROV, pool deck operations. Minimum three steps, each with at least one hazard and one concrete control. Trade with a partner and try to find a hazard they missed; revise.

Clearing This Card

Your revised JSA, plus a 90-second oral check: “Which control on your sheet is most likely to be skipped when people are rushed, and how do we make it skip-proof?”

If You Miss This Class

Examples and the template are in the folder; write, get a peer review from any cleared student, same check.

Why This Matters

The company safety review is a scored submission built from exactly these, so every cleared card contributes real lines to it. More honestly: the studio runs power tools, soldering irons, and 12-volt systems next to water, and the culture where students write the hazards is the culture where students catch them.

Card 5.2: Pool Deck Protocol and the Launch Checklist

Core Question

Pool minutes are the scarcest resource we have, and the deck is where they evaporate: forgotten fuses, unsealed vents, dead batteries, missing tools. Pilots and surgeons use checklists for exactly this reason. What is ours?

Resource (~10 min)

1. Why checklists work when memory fails: they are for things experts forget BECAUSE they are experts (too routine to think about). Short excerpts and stories from aviation and surgery checklists.
2. The MATE deck reality: safety inspection, size and weight checks, tether handling rules, and the launch procedure judges expect to see performed with discipline.

Activity

Teams draft their launch checklist: pre-travel (leaving the studio), pre-dive (on the deck), and recovery (out of the water). Then tabletop-test it: the teacher walks through the list playing saboteur (“the vent plug is missing, which line catches it?”). Every failure the tabletop finds gets a line. The surviving checklist gets printed and laminated.

Clearing This Card

Contribute to your team’s checklist and pass a 90-second oral check: pick any line and explain the failure it exists to prevent, ideally from team history.

If You Miss This Class

Review your team’s checklist, then propose one addition or improvement with its rationale; same check.

Why This Matters

This checklist runs at every pool day, so it gets a full rehearsal monthly before it runs at the regional. Deck discipline is also scored, watched, and remembered by safety judges.

Card 5.3: Seabed 2030, Why Map the Ocean

Core Question

We have better maps of Mars than of Earth’s seafloor, and a global project called Seabed 2030 is racing to fix that. Why does a map of the bottom matter enough for that effort, and what does it have to do with a robot in a high school pool?

Resource (before seminar, ~10 min)

Read the provided one-page excerpt on Seabed 2030 and ocean mapping coverage. Note the current mapped percentage and one consequence of an unmapped seafloor (tsunami modeling, cable routing, habitat protection, navigation).

Prep Notes (your artifact)

1. One claim about who benefits most from seafloor mapping, with reasoning.
2. One cost or risk of mapping everything (there are real ones).
3. One honest question.

Seminar Threads

Who should pay for mapping international waters? Does mapping enable protection or exploitation, or both? Where do autonomous vehicles like Argo floats and ROVs fit where ships cannot?

Clearing This Card

Prep notes plus genuine seminar participation (or the written-response alternative from Card 0.1).

If You Miss This Class

Prep notes plus a one-page written response to two claims made in the seminar (posted summary on the class page); or bring the topic back at the next seminar slot.

Why This Matters

Judges score whether the team understands the real-world context of its missions. “Our tasks simulate survey work that Seabed 2030 needs done at scale” is context; this seminar is where you earn the right to say it.

Card 5.4: The Argo Program

Core Question

Around four thousand robotic floats are drifting through the world’s oceans right now, diving and surfacing on a schedule, and they have quietly become one of the most important climate instruments humanity owns. Our float is a working model of one. What do they measure and why does it matter?

Resource (before seminar, ~10 min)

Read the provided Argo program overview. Note: the dive cycle (drift deep, profile up, transmit at surface), what is measured (temperature, salinity, pressure), and one finding Argo data made possible (ocean heat content trends).

Activity (in class, 10 min)

Real data touch: open the provided CSV of one real Argo float profile and plot temperature versus depth using your Card 4.4 skills (or read the pre-made plot if you have not cleared 4.4). Write one sentence about what the thermocline looks like in the data.

Prep Notes (your artifact)

1. The dive cycle in your own words, mapped step by step onto what Ebirah does.
2. One claim: what is the most important thing Argo tells us, and why do you say so?
3. One honest question.

Clearing This Card

Prep notes plus the data sentence plus seminar participation.

If You Miss This Class

All materials on the class page; prep notes, data sentence, and the written seminar response.

Why This Matters

This is the float’s WHY, and the engineering presentation scores WHY heavily. A student who can go from a real Argo profile to Ebirah’s dive cycle to the piston mechanism owns the full story judges want.

Card 5.5: Monterey Bay, Our Sanctuary

Core Question

Our regional competition happens beside a national marine sanctuary with a submarine canyon deeper than the Grand Canyon and a world-famous research institution on its shore. What makes this bay worth protecting, and what does “protected” actually permit and forbid?

Resource (before seminar, ~10 min)

Read the provided sanctuary overview. Note the canyon, the kelp forest ecosystem, one protected activity conflict (fishing, cables, discharge), and what MBARI does there with vehicles related to ours.

Prep Notes (your artifact)

1. One claim about the hardest tradeoff a sanctuary must manage, with reasoning.
2. One connection between something our robot does and work actually done in the bay.
3. One honest question.

Seminar Threads

Who gets a say in what happens in a sanctuary: fishers, scientists, tourists, the Navy? Does research technology belong in protected water? If our team could run one real mission in the bay, what should it be?

Clearing This Card

Prep notes plus participation, as in Card 0.1.

If You Miss This Class

Materials on the class page; prep notes plus written seminar response.

Why This Matters

This is local knowledge about the water our regional lives beside, and it converts directly into presentation context: teams that connect their vehicle to their own coastline stand out from teams reciting generic ocean facts.

Card 5.6: Coral Restoration (2026 Mission Context)

Core Question

Competition tasks simulate real coral restoration work: surveying reefs, placing fragments, monitoring recovery. In the real ocean, why do humans replant coral by hand, and does it work?

Resource (before seminar, ~10 min)

Read the provided excerpt on coral bleaching and restoration methods (fragment nurseries, outplanting, substrate work). Note what causes bleaching and one honest limitation of restoration.

Prep Notes (your artifact)

1. One claim: is restoration a solution, a stopgap, or a distraction? Reasoning required.
2. One specific way an ROV or diver-replacement robot changes the economics or safety of this work.
3. One honest question.

Clearing This Card

Prep notes plus participation, or the written alternative.

If You Miss This Class

Materials on the class page; prep notes plus written seminar response.

Why This Matters

Every mission task on our score sheet is a simulation of this work. Judges ask what the task represents; this card is that answer, and it retires honorably when next year’s theme replaces it.

Card 5.7: The Deep-Sea Mining Debate

Core Question

The deep seafloor holds metals the battery economy wants, in nodules that took millions of years to form, in ecosystems we have barely met. Mine them or leave them? This one is genuinely unsettled, and smart people disagree.

Resource (before class, ~10 min)

Read the provided two-sided brief: the case for (battery metals, land mining’s real damage, poorer nations’ seabed claims) and the case against (irreversibility, unknown ecosystems, sediment plumes, weak governance).

Activity: Sides You Do Not Choose

You draw your side at random and argue it regardless of your view; the ability to state the other side’s best case is the skill. Format: two prep minutes with your side, alternating two-minute openings, open cross-talk under seminar rules, then everyone drops roles and says what they actually think and whether anything moved them.

Prep Notes (your artifact)

The strongest argument FOR each side, one paragraph each, written before you know which side you will draw.

Clearing This Card

Prep notes with both sides genuinely steel-manned, plus participation.

If You Miss This Class

Prep notes plus a one-page position memo that presents both sides before taking one.

Why This Matters

Marine technology, including everything we build, lives inside this tension: the same ROV skills survey a sanctuary or prospect a mine. Engineers who have practiced holding both sides argue better in every design review, and in every DDR.

Card 5.8: Ocean Acidification

Core Question

A third of the carbon dioxide we emit dissolves into the sea, and dissolved carbon dioxide is a weak acid. What does slowly acidifying an ocean do, and how would you even measure it?

Resource (~10 min)

1. The chemistry in three steps: carbon dioxide plus water makes carbonic acid; acid lowers pH; lower pH steals the carbonate that shells and corals are built from.
2. The measurement connection: pH sensing platforms include, yes, Argo-family floats.

Activity: The Shell Race

Three cups: plain water, vinegar solution (exaggerated acid), and carbonated water (the honest analog: acidified by dissolved carbon dioxide alone). A piece of chalk or shell fragment in each. Observe over the class period and again next class; record what each looks like and any bubbling. Write the caveat sentence yourself: how is the vinegar cup misleading about the real ocean, and why is the carbonated cup the fairer comparison?

Clearing This Card

Observation log with the caveat sentence, plus a 90-second oral check: “Walk me from a car’s tailpipe to a thinner oyster shell, step by step.”

If You Miss This Class

Cups are trivially reproducible during studio time; same log and check.

Why This Matters

Acidification is the kind of ocean-change story behind mission themes year after year, and it connects the float’s sensor payload to a global measurement problem. Also, the caveat sentence is real science practice: knowing what your demo exaggerates is knowing what your data means.

Card 5.9: Ghost Gear and Ocean Plastics

Core Question

Lost fishing gear keeps fishing forever: nets and traps that catch and kill with no one collecting. Recovering it is dangerous diver work. What makes ghost gear such a stubborn problem, and what would a robot need to help?

Resource (before class, ~10 min)

Read the provided ghost gear overview. Note the scale estimate, why gear gets lost, why recovery is hazardous, and one existing recovery program.

Activity: Requirements, Not Solutions

In teams, write the REQUIREMENTS for a ghost-gear recovery ROV mission: what it must find, cut, grab, lift, and avoid (entanglement is the vehicle-killer; your tether is a liability here). Output is a requirements list, not a design; ranking which three requirements are hardest is the point. Compare lists across teams.

Prep Notes (your artifact)

One claim about why this problem persists despite everyone agreeing it is bad, plus one honest question.

Clearing This Card

Prep notes plus your team’s ranked requirements list with your name on the parts you argued for.

If You Miss This Class

Write your own ranked requirements list solo; same prep notes.

Why This Matters

Manipulation tasks in competition frequently simulate exactly this work, and the requirements exercise is a dress rehearsal for design specs, which the company is adopting this year. Notice this card made you write requirements before solutions; hold onto how that felt.

Card 5.10: The Blue Economy, Who Does This for a Living

Core Question

Everything we do in this studio is a paid profession somewhere: ROV pilots, marine technicians, ocean engineers, hydrographers, aquaculture operators, cable-route surveyors. What does that world actually look like, and what does it pay?

Resource (~10 min)

The blue economy in one slide: shipping, energy, food, science, defense, tourism, and the technicians underneath all of it. Note that MATE itself began as a workforce pipeline; the competition is a simulated company because the industry hires from it.

Activity: Find a Real Job

Solo or pairs, 20 minutes: find one real, current job posting a person could hold in the blue economy (ROV technician, survey tech, marine electronics, research vessel crew). Record the title, employer, location, requirements, and pay if listed. Then map it: which three lesson cards from this year are the beginning of that job’s requirements? Share out, one minute each; the class builds a wall of postings.

Clearing This Card

Your posting card for the wall with the three-card mapping.

If You Miss This Class

Same research during studio time; add your posting to the wall.

Why This Matters

The company framing is not pretend. The skills on your competency ladder have market names and salaries, and seeing the posting with your own three cards mapped onto it is the most honest answer to “when will I use this” that school can offer.