Skip to content

After week 8

Eight weeks is enough to contribute, not enough to be finished. Here is what happens between the last session and kickoff, and what you can do with the gap.

Catch-up sessions

Weeks 9 and 10 are optional and exist for one reason: some people missed a session, or a week did not land. They are not a remedial class. Roughly half the room usually turns up to one of them.

Bring the specific thing that is not working. “My capstone would not deploy” is a session. “I do not really get commands” is also a session, and a better one — say it out loud and somebody will draw it on a whiteboard.

What this course left out, on purpose

Eight hours in a room means choosing. None of this is beyond you; it was cut because it was not the fastest route to shipping a feature.

  • Loops and arrays

    Rookies almost never write one in command-based code.

    Self-paced. Worth doing before build season, because you will read them.

    CodingBat, Array-1

  • Inheritance and interfaces

    You only needed one line of it: extends SubsystemBase.

    Build season, when somebody writes a base class and you have to read it.

  • Hands-on PID tuning

    Needs a mechanism and more than an hour.

    Pre-kickoff or build season, on a real arm or elevator.

    WPILib: PID control in command-based

  • Mechanism2d and AdvantageScope

    Nice to have. You can ship a feature without either.

    Build season, once there is telemetry worth looking at.

    AdvantageScope docs

  • SendableChooser

    Easy once you have more than one auto to choose between.

    Build season, about a week after your first auto works.

    WPILib: choosing an autonomous

  • Git in depth

    Clone, branch, commit, push, pull request covers a rookie season.

    As it comes up. The next thing worth learning is how to fix a merge conflict.

    The git guide here

  • Wiring and pneumatics

    No room in a one-hour session, and it is not programming.

    A separate robotics clinic. Go to it anyway — knowing which wire is PWM 2 makes you faster.

The December mock kickoff

One weekend, in December

The team picks an old game, runs a fake kickoff, and builds something small for it in a weekend. Strategy argues, CAD sketches, and the programmers get a drivetrain driving and one mechanism moving.

It is the single most useful thing you can do before January, because the hard part of kickoff is not the code. It is working out what to do while eleven other people are also working it out. Doing that once, with no stakes, is worth more than another month of exercises.

Go even if you feel behind. Especially then.

Turning up to kickoff with a task

Every rookie should walk into kickoff with a named, scoped first task and somebody's name next to it as the person to ask. If nobody has given you one by the end of the first meeting, that is not a hint that you are not needed — it is a thing to ask for.

A good task says what should happen and how you will both know it works. A bad task sounds bigger and is actually just vaguer.

You can start this today

  • Add a slow mode to the drivetrain on the left bumper.
  • Put the elevator height on the dashboard so the drive team can see it.
  • Make the intake stop on its own when the beam break trips.
  • Move the shooter speeds out of ShooterSubsystem and into Constants.

Ask one question first

  • Write the autonomous.
  • Make the arm work.
  • Tune the PID.
  • Clean up the code.

The question that fixes a bad task

“What should happen, and how will we know it is working?” Ask it once and “make the arm work” turns into “when I hold Y the arm goes to the scoring position and stops there”, which you can actually finish.