RobotnixAcademy

Unit 05 · lesson

Simulate, Deploy, Observe, Debug

Robot programming is not complete when the code builds.

You need evidence that the behavior you intended is the behavior the system produced.

Three environments

An FRC workflow commonly moves through three environments:

Static reasoning
Read code, inspect types, review logic, and check configuration.

Simulation
Run supported behavior without the physical robot and inspect state transitions.

Hardware test
Run a controlled physical test with the actual electronics and mechanism.

Each environment can reveal different failure modes.

Simulation may catch scheduler logic while missing a loose connector. Hardware may expose sensor noise that a simple model never produced.

Log the decision, not only the result

Suppose an elevator stops early.

A useful log should help answer:

  • What setpoint was requested?
  • What sensor value was measured?
  • What command was active?
  • What output was requested?
  • What fault or limit condition was present?

A dashboard that says Elevator: ON is not enough.

Debugging trace

Use this sequence:

expected behavior
      ↓
observed behavior
      ↓
first divergence
      ↓
nearest available evidence
      ↓
one hypothesis
      ↓
one test
      ↓
result

The first divergence is powerful. If the controller input is correct but the command never starts, you do not need to inspect motor gearing yet.

Code-change exercise

Use a WPILib example, simulator project, or team codebase you are authorized to modify.

Make one bounded change such as:

  • adjust a safe simulated speed;
  • change a controller binding;
  • add a telemetry value;
  • add a command end condition;
  • add a simulated sensor threshold.

Before running, write your prediction.

After running, capture:

  1. code change;
  2. expected result;
  3. observed result;
  4. one log/simulation screenshot or text record;
  5. whether the evidence supports your prediction.

If you have physical hardware, do the same process under team safety procedures. Do not jump directly from edit to full-speed robot testing.

Failure case: the fix that proves nothing

You change motor inversion, device ID, command binding, and sensor threshold at once. The mechanism starts working.

What did you learn?

Almost nothing.

You do not know which change fixed it, whether another change created a hidden error, or whether the system will remain stable.

One controlled change is slower for thirty seconds and faster for the next two hours.

2026 tool awareness

Use the current WPILib documentation for the season you are programming. FRC tooling changes. Projects from older seasons may require migration, and deprecated tools should not become the foundation of a new workflow.

For this course, the durable skills are:

  • project structure;
  • command ownership;
  • simulation;
  • logging;
  • configuration discipline;
  • evidence-driven debugging.

Those survive tool changes better than memorizing which menu item was in one year's IDE.

Add your software map and tested change record to the Unit 5 evidence package.