Skip to content

Stage 5 — Software

Window: Week 0 (before hardware) through competition. Gate: Sim Autonomy Passing (interim), Field Readiness (final). Precondition: Strategy Approval passed. Software does not wait for hardware.

The single biggest mistake small teams make: programmers get the robot in Week 5 and nothing works at Event 1. This stage exists to prevent that.

Framework Choices

  • WPILib (Java or C++). Team convention: pick one and stick with it across seasons.
  • AdvantageKit (Team 6328) — strongly recommended. Provides:
  • IO abstraction — subsystems separate real hardware from control logic.
  • Deterministic input logging — every sensor value logged every loop.
  • Log replay — replay a match log through new code as if it ran on the robot. Critical for tuning without robot time.
  • Docs: https://docs.advantagekit.org/
  • PathPlanner or Choreo — autonomous trajectories.
  • AdvantageScope — log viewer, 3D robot visualization.

Core Principles

1. Simulation First

Subsystems are developed in simulation before hardware exists. The AdvantageKit IO pattern:

Subsystem ├── IO interface (abstract) ├── IOReal (Falcon/NEO/CANcoder etc.) └── IOSim (physics sim)

Same subsystem code runs against either IO. Programmers develop against IOSim from Day 1.

2. Log Everything

Every subsystem publishes its inputs (sensor values) and outputs (commands) to the log every 20 ms tick. After every practice session or match:

  • Download logs.
  • Open AdvantageScope with the drive team.
  • Review any anomaly. Discovery > blame.

Log review is a ritual. Skip it once and it never happens again.

3. Everything in Git

  • Repo per season on GitHub. Public if possible — recruiting tool and gives back to community.
  • Feature branches for every change. Never commit to main directly.
  • Pull requests reviewed by another student (or mentor for critical changes) before merge.
  • main is always deployable to robot.
  • CI runs on every push: Gradle build + spotless format check + unit tests.

4. Autos as Unit Tests

  • Every autonomous routine has a saved log replay that verifies it produces expected commands.
  • Auto is tuned in sim first, then trimmed on robot. Robot time is precious.

File Layout (typical)

src/main/java/frc/robot/ Robot.java RobotContainer.java Constants.java subsystems/ drive/ Drive.java DriveIO.java DriveIOReal.java DriveIOSim.java intake/ Intake.java IntakeIO.java IntakeIOReal.java IntakeIOSim.java … commands/ auto/

One directory per subsystem. IO interface + real + sim in every subsystem.

Development Workflow

Week 0–1 (before hardware)

  • Set up repo, CI, AdvantageKit skeleton, AdvantageScope.
  • Stub out every subsystem from the Priority List with IO interfaces.
  • Write kinematics for the drivetrain in sim.

Week 2–3 (prototypes exist)

  • Prototype electronics use dev laptops running the real subsystem code.
  • Software team owns one prototype board per active mechanism prototype.
  • Feed sensor data back to the log; iterate on control constants in sim before robot.

Week 3–4 (practice robot / real hardware coming online)

  • Swap IOSim → IOReal per subsystem as hardware becomes real.
  • Sanity check: same code, same commanded behavior, different IO.
  • Start driver testing. Log every session.

Week 5–6 (integration + tuning)

  • PID tuning per subsystem. Every tuning session logged.
  • Autonomous routines developed in sim first, then trimmed on hardware.
  • Reliability testing — code must not crash across 20 full-match cycles.

Sim Autonomy Passing Gate

Interim gate, typically end of Week 3. Requires:

  • Full simulated match runs without crashes.
  • At least one autonomous routine completes correctly in sim.
  • Log replay of that auto matches expected output.
  • Every priority-list subsystem has both IOReal and IOSim implementations.

Passing this gate confirms software will not be the bottleneck when the robot is assembled.

Deliverables (contributed to Field Readiness Gate in Stage 6)

  • All autonomous routines running.
  • Full match cycle without crash across 20+ runs.
  • Log-review process practiced every session.
  • Drive team comfortable with default controls; button mapping documented.
  • Emergency behaviors defined (brownout, motor stall, disconnect).

Common Failure Modes

  • Waiting for hardware. Programmers idle until Week 4. Hardest failure to recover from.
  • No log review. Bugs discovered at competition instead of practice.
  • Direct-to-main commits. Broken build blocks whole team.
  • No CI. "Works on my laptop." Broken deploy at event.
  • Autos tuned only on robot. Wastes practice hours.
  • Constants scattered. Motor CAN IDs, PID gains, and offsets in ten files. Put them in Constants.java (or a config directory).
  • Rewriting from scratch each year. Keep the framework, port subsystems. Reference last year's repo.

Roles

  • Software Lead (student, senior): owns architecture, code review, autos.
  • Subsystem Programmers (students): own one subsystem's IO + logic.
  • Simulation / Test Lead (student): owns sim scenarios, log-replay harness.
  • Software Mentor: teaches, reviews architecture, does not write production code.

Handoff to Stage 6 (Integration)

Passing Sim Autonomy Gate lets software join integration on real hardware. From this point, software works alongside mechanical/electrical in the field-testing loop.

Comments