Team 3128 · Aluminum Narwhals

Controls

A finite-state-machine architecture built on a shared common library, field-relative swerve control, multi-camera vision, and a custom web dashboard — designed for reliability under match conditions.

State Machine Architecture

Software Design

Each subsystem is modelled as a finite state machine. Mechanisms hold distinct states and a transition map governs every valid move between them — making robot behaviour predictable, testable, and easy to debug mid-match.

NAR_Subsystem Interface

›Specifies the functionality and expectations every subsystem on the robot must satisfy

›Enforces a consistent API across all mechanisms

NAR_PIDSubsystem

›Custom PID subsystem class with quality-of-life additions over WPILib's base

›Shared across Position, Velocity, and Voltage subsystem types

Mechanism Types

›Position-based — elevator, pivot, climber

›Velocity-based — shooter drum

›Voltage-based — rollers, manipulator

Transitions & Transition Maps

›Maps a named "state" of the subsystem to a set of mechanism target states

›Default states are the entry point; exclusive states are only reachable from a specific default

›The default → exclusive pairing creates a clear visual model of robot intent

Superstructure

Superstructure state diagram — top-level coordination of all subsystems

Climber

Climber state diagram

Shooter

Shooter state diagrams

Vision & Odometry

Pose Estimation

Four cameras — two OV2311s and two Luma P1s — run off a Raspberry Pi with PhotonVision, maximising AprilTag visibility at all field positions. Gyro-stabilised inputs filter out unreliable estimates before they reach the pose estimator.

Vision Setup

›2× OV2311 + 2× Luma P1 cameras on a Raspberry Pi running PhotonVision

›Four cameras for maximum AprilTag coverage at all field positions

›PhotonVision settings tuned to maximise accuracy

Tag Filtering

›Ambiguity — reject any tag with pose ambiguity above 0.3

›Distance — filter tags beyond ~4.0 m

›ID filtering — reject tags identified through testing as detrimental to pose accuracy

Pose Utilisation

›Autonomous — pose estimates guarantee consistency regardless of field conditions

›Auto-align to hub for shooting from anywhere with a single button

›Auto-align to tower for climbing — reaches and climbs within 4 seconds

›Shooting interpolation — shooter voltage computed from distance to hub in real time

Autonomous Control

Auto

Pose-based auto routines execute scoring and alignment sequences without driver input. A system-check mode lets the team verify all subsystems between matches with a single button press.

Auto Movement

›Auto-alignment to hub with shooting interpolation — shoot from any field position

›Auto-alignment to nearest tower for climbing — full sequence in under 4 seconds

›Shooter voltage interpolated from hub distance for consistent scoring

System Check

›Single button press runs a check routine across all subsystems

›Used between matches to quickly confirm full robot functionality

System Check

System check readout — pass/fail per subsystem

Interpolation

Shooter interpolation — RPS vs. distance from hub

Common Repository

3128-Common

Code reused across seasons lives in a shared GitHub repository, distributed via JitPack the same way vendordep libraries like Phoenix and REVLib are consumed — one dependency update propagates to all users instantly.

Repositorygithub.com/Team3128/3128-common

DistributionJitPack (vendordep-style)

Access methodGit submodule within robot repo

Update modelSingle dependency bump — propagates to all users

Library Contents

›Swerve base — field-centric drive, module control, odometry

›Subsystem templates — NAR_PIDSubsystem, FSM base, Position / Velocity / Voltage bases

›Transitions and transition maps

›Control systems — PID, feed-forward, trapezoidal PID

›Motor wrappers, Shuffleboard interface, Narwhal Dashboard WebSocket

›Vision processing, SysID utilities

›Controller wrappers — Xbox, button boards

Narwhal Dashboard

Custom Dashboard

A custom React web dashboard that replaces WPILib's built-in dashboards with a faster, more flexible, and team-specific alternative — built to serve drivers during matches and programmers during testing.

Purpose

›Offloads data processing from the RoboRIO to the driver station computer

›Unified tool for drivers (match-day telemetry) and programmers (debugging and tuning)

Implementation

›Written in React JS (HTML / CSS / JS)

›Connects to the RoboRIO via a Java WebSocket server, receiving tagged JSON data

›Annotation processor on the Java side marks fields for automatic dashboard exposure

›Modular widget system — panels can be rearranged and toggled without code changes

Dashboard

Narwhal Dashboard — full match-day layout with swerve telemetry, subsystem states, auto selector, and vision overlay

Back to BinderTeam 3128 · Aluminum Narwhals