A course for competition robotics programmers

Programming a real robot

Commands, subsystems, and the code already on the robot. Everything here is taught from a real competition codebase, and you build your own copy to break, so what you read is what you push.

Start Unit 1Your account

Curriculum

Units

01lockedThe Command PatternBy the end of this unit you can say why a robot that waits in a loop can do nothing else, turn that loop into a command, and say what a command owns that the rest of the robot does not.Inside · 10 min read
  1. A robot that can only do one thing
  2. Ask again instead of waiting
  3. What a command owns
  4. One file per behavior
  5. Practice in a simulator
5 quick checkscode exercises02lockedWriting a CommandBy the end of this unit you can write each part of a command, say why each line lives where it does, and commit a movement command that gives up safely when it gets stuck.Inside · 17 min read
  1. One real command, all the way through
  2. Somewhere to put your own code
  3. Getting code onto the actual robot
  4. The constructor: what never changes
  5. initialize(): what depends on the moment
  6. execute(): a little work, then return
  7. isFinished(): arrived, or out of patience
  8. end(): leave it safe, and say how it went
  9. Why Artemis wraps the library’s turn
  10. Your first real command
8 quick checkssteppercode exercises03lockedSubsystems and HardwareBy the end of this unit you can write a subsystem that claims its own hardware and says what it can do, read a sensor into something a command can act on, and put every number in the one home its lifetime calls for.Inside · 11 min read
  1. The part of the robot that stays
  2. One motor, one owner
  3. Name it once
  4. Where a number lives
  5. The dial that did nothing
  6. Reading a sensor
  7. A reading is not a decision
  8. State inside a subsystem
  9. When a command is one line
10 quick checkscode exercises04lockedRunning the RobotBy the end of this unit you can start the robot from either door, give a subsystem a command that always owns it, bind a button to the behavior it actually means, and compose an autonomous out of the commands you already wrote.Inside · 12 min read
  1. Nothing has started yet
  2. Two doors, one robot
  3. The command that never finishes
  4. The panic button
  5. One flush, one loop
  6. Three ways to mean “the button”
  7. Reading a binding block
  8. An autonomous is a list
  9. Together, when together is worth it
  10. The trade you are making
10 quick checkscode exercises05lockedAutonomous Navigation with PedroBy the end of this unit you can say where the robot thinks it is and in which units, prove the field frame is right before you write a single coordinate, write a command that drives a path and hands control back cleanly, and carry out the follower's tuning sequence without measuring one stage against another that is lying.Inside · 18 min read
  1. Where the robot thinks it is
  2. Radians, always
  3. Which way is zero
  4. Two maps of the same field
  5. The check that needs no robot
  6. Convert once, at the edge
  7. The conversion that looked reasonable
  8. The same command, from the other side
  9. Build the path from where you are
  10. Three wrong ways to know you arrived
  11. Why execute() is empty
  12. Handing back
  13. Four tests, four questions
  14. Once per loop, for the third time
  15. In order, because each stage stands on the last
  16. Paste, then redeploy
  17. The paste that reverts your work
16 quick checkscode exercises06lockedVision: Where Is That?By the end of this unit you can read a target from the subsystem that owns the camera and aim a mechanism at it without ever blocking the loop, say why a sighting is kept in field coordinates and how exact a merged one is, work out how far a stale frame throws a tag during a turn, and defend leaving vision corrections switched off until the tags have proved they stay put.Inside · 18 min read
  1. Two jobs, one camera
  2. One subsystem owns the camera
  3. What a sighting tells you
  4. null means three different things, on purpose
  5. Do not wait for a good reading
  6. Why a sighting is kept on the field
  7. What makes a stored sighting wrong
  8. How exact is a target?
  9. The arm does not pivot where the robot does
  10. Subtract the pivot first
  11. Where the pivot’s numbers live, and how often you read them
  12. The frame is already old
  13. How wrong, exactly
  14. Keeping the poses you will need
  15. The same detections, the other direction
  16. A tag that moved reads exactly as confidently
  17. Off until proven
  18. A policy that says why it refused
  19. One more conversion, at one more edge
21 quick checkscode exercises07lockedReading the Library You Depend OnBy the end of this unit you can trace one iteration of a scheduler you did not write and use it to explain something the robot actually did, say which classes on your robot arrived by Gradle and which your team owns, read a method's source against its own documentation and name the consequence when they disagree, and put a hook that must run where the base class guarantees it will.Inside · 11 min read
  1. You have been taking its word for it
  2. Whose code is this, actually
  3. One iteration, in the order it really happens
  4. periodic() is not interrupted, because it was never scheduled
  5. A docstring is a claim; the source is the evidence
  6. Which method does what the sentence says
  7. The biggest version number is not the newest release
  8. Where the base class guarantees your hook will run
  9. Why it cannot live at the end of the last command
12 quick checkscode exercises08lockedProcess, the Team, and the SeasonBy the end of this unit you can leave a shared laptop in a state the next person can pick up, get a library to do something its documentation never demonstrates, judge borrowed or generated code against the requirement it was meant to meet and say where it came from, put a number on a mechanism before it gets built, isolate a fault one layer at a time and write down what it turned out to be, and move a dependency without breaking the merge.Inside · 24 min read
  1. The person who sits down next
  2. What a commit message is actually for
  3. Pull before you start
  4. The docs never show your exact case
  5. Reading toward a goal, not reading through
  6. Extending what last season left you
  7. Code that looks right
  8. Check it against the requirement, not against your taste
  9. Say where it came from
  10. A number before a mechanism
  11. Two designs, one set of constraints
  12. Four layers, one symptom
  13. The ladder, and why the order is not optional
  14. The tool that touches nothing
  15. A control is a fact about a date
  16. Retracting a lead, in writing
  17. A checker has three verdicts, not two
  18. Write the hour down
  19. Two directions, two mechanisms
  20. One at a time, and build in between
  21. A bump can break what no compiler sees
  22. Keep the merge boring
31 quick checkscode exercises