| name | game-info |
| description | Season/field conventions this codebase enforces — the blue-origin field frame, how alliance flipping works (CTRE operator perspective), AprilTag/vision conventions, and the alliance-aware bits an agent must respect rather than re-derive. Read whenever a task involves field positions, alliance color, or game-piece scoring. Field-zone and game-piece specifics are TODO until a real game is wired. |
Game Info
What an agent needs to reason about robot behavior in match context: the field coordinate frame,
how alliance color changes things, and where game-specific constants will live. Anything purely
mechanical / software is in the robot-description skill instead.
Season & status
This is a WPILib 2027-alpha template (the 2026→2027 migration target). It ships as a starting
point, not a game-specific robot: the Arm,
Flywheel, and superstructure
poses (stow/intake/score) are
illustrative examples of intake-and-shoot mechanics, not the real season's mechanisms. There are
no field-dimension constants, no scoring-zone poses, and no AprilTagFieldLayout wired in yet.
When you implement the real game, fill in the TODO sections below and update this skill.
Field & alliance conventions this codebase enforces
Respect these as project conventions rather than re-deriving them:
- Field origin is blue alliance. Odometry pose (DriveMechanism.getPose)
is always in the blue-alliance-origin frame (the CTRE/Phoenix convention — the origin does
not move with alliance). Field poses you hand to DriveToPose
are blue-origin (see the comments in AutonomousOpMode.java:
"x forward from the blue wall, y left").
- Alliance affects the driver's perspective, not the field origin. The drivetrain applies an
operator perspective in CommandSwerveDrivetrain.applyOperatorPerspective:
blue sees forward as
0°, red sees forward as 180°. So "push the stick away from you" means
"downfield" for both drivers, even though the field frame is fixed. This is driven every loop from
DriveMechanism and only re-applies while
disabled (or once at startup), so it won't change behavior mid-enable.
- Read alliance via
MatchState, not DriverStation on the hot path. The perspective code uses
org.wpilib.driverstation.MatchState.getAlliance(). Follow that pattern; don't scatter alliance
reads through subsystem code.
- There is no automatic pose flipping for red-alliance autos yet.
DriveToPose drives to the
literal blue-origin pose you give it. A red-side autonomous that should mirror its blue counterpart
needs you to flip the goal poses yourself (rotate about field center: x → fieldLength - x,
y → fieldWidth - y, θ → θ + 180°, the ROTATE symmetry recent fields use). The field
dimensions to do that aren't in code yet — pull them from the game manual / AprilTagFieldLayout
when you add them. Don't copy MIRROR-symmetry flip code from older (2024/2025) projects.
AprilTags / vision
- The robot reads AprilTags only through Limelights (two cameras, NT names
"limelight-br" /
"limelight-bl", registered in Robot via Limelight.registerAll) using
LimelightHelpers.
Limelight.java fuses their AprilTag
pose estimates into the drivetrain's pose estimator.
DriveToTag works in the tag's frame
(getBotPose3d_TargetSpace) and drives to the Limelight's configured POI standoff — so it is
alliance-agnostic (it doesn't care about field origin at all).
- There is no vision in simulation (no PhotonVision sim), so tag-based behavior can only be
validated on real hardware. See the
run-sim skill.
- For canonical tag IDs / poses, use the season's WPILib
AprilTagFieldLayout (not yet loaded in
code) and the Limelight's field map. Don't assume a prior season's tag layout.
Field zones / scoring locations
Status: TODO. No named field positions exist in code yet. When autos are added, document the
scoring/staging/defensive locations here, keyed to the Pose2d constants (blue-origin) or named
waypoints, e.g.:
| Name | Blue pose (x, y, θ) | Defined in |
|---|
STATION_LEFT | … | … |
Until then, the official game manual and the season AprilTagFieldLayout are the source of
truth for dimensions and zone names. Don't invent coordinates from memory.
Game-piece handling
Status: TODO. The arm + flywheel are placeholder mechanisms. When real manipulators land,
document: what pieces the robot holds/scores, the named states (e.g. EMPTY/STAGED/SCORING),
which sensor/NT key indicates each, and what auto routines assume about the starting piece.
Authoritative references (when this skill is silent or stale)
- The current season's FRC game manual — rules, field dimensions, scoring. Source of truth over
anything here.
- The season
AprilTagFieldLayout — tag IDs/poses.
- The code itself — TunerConstants (robot
geometry), the OpModes (opmodes/) for what routines exist.
Anti-patterns
- Don't hardcode red-alliance poses. Author blue-origin; flip about field center when red autos are
added.
- Don't move the field origin with alliance — only the driver perspective flips.
- Don't read
DriverStation.getAlliance() directly in subsystem periodic/hot paths — go through
MatchState like CommandSwerveDrivetrain does.
- Don't assume a previous season's field/tag layout, and don't reuse MIRROR-symmetry flip math.
