Supplementary tutoring for the robotics team
Get in the game
This is extra help beside the team, not another class. It shows you what is going on inside the robot from the ground up: how its code is put together, why it is built that way, and how to change it without breaking it. The more of it you understand, the more you can do at meetings and on the field.
Curriculum
Units
- A problem with a name
- A robot that can only do one thing
- Ask again instead of waiting
- What a command owns
- One file per behavior
- Practice in a simulator
- Somewhere to put your own code
- Getting code onto the actual robot
- One real command, all the way through
- The constructor: what never changes
- initialize(): what depends on the moment
- execute(): a little work, then return
- and 4 more
- The part of the robot that stays
- One motor, one owner
- Name it once
- Where a number lives
- The dial that did nothing
- Reading a sensor
- and 3 more
- Two doors, one robot
- The command that never finishes
- Hands off, it holds
- The panic button
- One flush, one loop
- Three ways to mean “the button”
- and 4 more
- Where the robot thinks it is
- Radians, always
- Which way is zero
- Two maps of the same field
- The check that needs no robot
- Convert once, at the edge
- and 11 more
- One subsystem owns the camera
- Two jobs, one camera
- What a sighting tells you
- null means three different things, on purpose
- Do not wait for a good reading
- Why a sighting is kept on the field
- and 13 more
- You have been taking its word for it
- Whose code is this, actually
- One iteration, in the order it really happens
- periodic() is not interrupted, because it was never scheduled
- A docstring is a claim; the source is the evidence
- Which method does what the sentence says
- and 3 more
- The person who sits down next
- What a commit message is actually for
- Pull before you start
- When the build breaks right after a pull
- The docs never show your exact case
- When the documentation is wrong
- and 20 more