Skip to content

Autonomous with BLine

Autonomous in this template is intentionally BLine-only. Paths are authored as JSON, committed with the robot project, loaded at startup, selected through an AdvantageKit-aware chooser, and followed by the shared drivetrain API.

Why BLine for autos

The goal is repeatable event workflow. A path should be a committed artifact that can be reviewed, tested, and deployed with the rest of the robot code.

PathPlanner remains in the project for teleop runtime pathfinding. It is not used to author or run autonomous routines here.

File layout

BLine deploy files live under:

src/main/deploy/autos/
src/main/deploy/autos/paths/

The path JSON files are deployed to the roboRIO with the rest of src/main/deploy. Commit them. If a path only exists on one laptop, it does not exist for the team.

Auto manager responsibilities

The auto manager owns:

  • chooser setup
  • routine registration
  • JSON path loading
  • path validity checks
  • odometry reset from the first path
  • alliance flipping
  • pre-match module orientation
  • event command lookup
  • optional endpoint settling through DriveToPose

Keep autonomous policy there. Do not scatter path-loading logic across commands and mechanisms.

Creating a new BLine auto

Normal flow:

  1. Author the path in the BLine GUI.
  2. Export JSON into src/main/deploy/autos/paths.
  3. Add or update the routine registration in the auto manager.
  4. Register any event keys used by the path.
  5. Run tests.
  6. Run desktop simulation.
  7. Test on blocks.
  8. Test on carpet at reduced speed.
  9. Raise constraints only after logs look good.

Event commands

Events connect path markers to mechanism commands. Keep them small and safe.

Example:

autoManager.registerEvent("intake", () -> intake.intakeUntilDetected().withTimeout(2.0));
autoManager.registerEvent("score", () -> scorer.scoreCommand().withTimeout(1.0));

Rules I expect event commands to follow:

  • include timeouts unless they are guaranteed to finish
  • do not depend on perfect sensor behavior
  • log important setpoints and states
  • avoid changing drivetrain configuration
  • compose commands with Commands.sequence, Commands.parallel, or Commands.deadline when needed

Odometry reset

The first path in a routine defines the starting pose. The auto manager resets odometry from that first path. Later paths continue from the current estimate.

Do not reset odometry in the middle of an autonomous routine unless there is a very deliberate reason and a test proving it is safe.

Alliance flipping

Paths are authored from the blue origin and flipped for red. Field target configuration follows the same idea. This keeps authoring consistent and avoids maintaining two copies of every routine.

When testing, verify both alliances. A routine that only works blue is not complete.

Endpoint settling

After a path, the routine may use DriveToPose for final alignment or hold. This is useful when the path gets the robot close and a tighter final pose matters.

Tune in this order:

  1. drivetrain calibration
  2. wheel radius
  3. BLine controller behavior
  4. BLine constraints
  5. DriveToPose final approach

Do not use DriveToPose to hide bad path tracking.

Failure behavior

An invalid selected auto should fail safe. It should report the problem, not drive a partial unknown routine.

Expected failure handling:

  • missing JSON is reported
  • invalid event keys are reported
  • selected auto validity is logged
  • disabled validation is visible to dashboards
  • no drivetrain movement occurs for invalid routines

What not to add

Do not add:

  • Choreo autos
  • PathPlanner-authored autos
  • game-specific state machines in the foundation
  • giant comment-heavy auto files
  • reflection or watchdog hacks

If the robot needs advanced autonomous behavior later, add it deliberately around the existing auto manager rather than mixing frameworks.