Mathias Petersen Let’s talk ↗
MATHIAS//PETERSEN
← Project index

Robotics framework / 2018 to present

FRC-Athena

Why it matters The valuable outcome is a team-owned architecture that carries engineering decisions between rotating students and yearly robot builds.

Athena turns recurring robot architecture into a maintained teaching and delivery platform.

Explore repository
StatusActive team framework
Role in the architectureRobot-side integration + team platform
My roleFounder & Lead Engineer
DisciplinesRobotics + embedded
01 / The work
Challenge

A competition robot is rebuilt each season by a changing group of students while WPILib and vendor APIs also change.

Registration, hardware polling, output conflicts, autonomous behavior, telemetry, and simulation can acquire different conventions until the architecture is hard to teach or reuse.

Approach

I made the robot a discoverable object graph and centralized its runtime cycle.

Hardware declarations stay stable above optional vendor adapters; mechanisms, behavior actions, localization, autonomous logic, and simulation share the graph; and distribution follows WPILib’s standard dependency workflow.

02 / Architecture model Team platform boundary

Season-specific hardware under stable robot concepts.

Robot code declares hardware and mechanisms against Athena. Optional vendor adapters bind those declarations to the installed ecosystem, while the same graph feeds simulation and WPILib lifecycle integration.

FRC-AthenaSystem boundary
  1. 01 Robot application

    Commands · autonomous · team-owned behavior

  2. 02 Mechanism layer

    Controls · drivetrain · vision · localization

  3. 03 Hardware graph

    Buses · devices · followers · limits · physical motor data

  4. 04 Optional adapters

    CTRE · REV · Studica · Limelight · PhotonVision

  5. 05 Execution targets

    WPILib robot lifecycle · desktop simulation · roboRIO

DistributionNative to the student workflow
  • Gradle modules
  • WPILib vendordep
  • Local Maven + examples
03 / Implementation

The decisions beneath the summary.

01

Robot as a discovered graph

Let students declare the robot structure once instead of maintaining registration and lifecycle wiring beside it.

Robot fields form one graph containing mechanisms, behavior tasks called Actions, hardware, controls, localization, autonomous routines, and simulation models. The runtime discovers that structure, validates relationships, and constructs the lifecycle around the declarations. Named CAN buses and device relationships preserve physical topology without forcing every mechanism to know vendor object construction.

  • Invalid bus and interface combinations fail against the declared hardware graph
  • Followers, limits, and physical motor identity stay available to both control code and simulation
  • Students extend the graph with fields rather than editing parallel registration tables
02

Deterministic runtime cycle

Snapshot inputs once, resolve behavior centrally, and arbitrate outputs before hardware writes.

RobotRuntime coordinates mechanisms, Actions, autonomous work, localization, and hardware refresh through one periodic model. Inputs are captured consistently for a cycle; Actions and mechanisms compute against that state; output arbitration makes simultaneous writers explicit rather than order-dependent. Safety constraints, motion profiles, PID and feedforward, telemetry, and trace behavior follow the same lifecycle.

  • Action resolution provides one composable behavior model for teleop and autonomous work
  • Hardware refresh and output application are separate phases rather than arbitrary vendor calls throughout the robot
  • Java microbenchmarks with allocation profiling cover scheduling, refresh, the full robot cycle, and simulation hot paths
03

Simulation as a backend swap

Run the same robot graph and Actions while replacing only physical I/O with simulation.

SimModel implementations attach to the same hardware declarations used on the robot. The simulation backend applies outputs to physics and returns sensor snapshots into the normal runtime cycle. Tests and desktop runs therefore exercise hardware identity, Actions, mechanisms, and arbitration rather than a simplified second application that can drift from competition code.

  • Physical motor constants in the graph inform the simulated plant
  • Sensor snapshots return through the same input surface used by real devices
  • Telemetry and runtime trace can compare the same lifecycle across desktop and roboRIO targets
04

Optional ecosystem and distribution

Integrate vendor libraries without making every team install every dependency.

CTRE, REV, Studica, Limelight, PhotonVision, PathPlanner, and Choreo adapters are separate modules. Service discovery activates an adapter only when its official dependency is present. Gradle modules publish through local Maven and WPILib’s standard dependency metadata, while standalone example robots consume the published artifacts to verify the workflow students actually use.

  • Absent vendor libraries cause their adapter to be skipped rather than accidentally linked
  • Annual vendor API churn stays behind independently replaceable integration modules
  • Standalone examples validate install and public API boundaries rather than importing workspace internals
04 / Tradeoffs + limits

What this work does not claim.

01

The 2027 branch is an active rebuild and does not promise a one-to-one port of older Athena internals.

02

Vendor adapters cannot prove device behavior when the matching official library or physical hardware is absent.

03

The abstraction has to remain teachable and observable by students; removing boilerplate is not permission to hide robot behavior.

05 / Engineering review

Architecture, evidence, and limits.

Explore repository ↗

Architecture

  1. 01
    Declared robot graph instead of registration tables

    fields become discoverable mechanisms, behavior actions, hardware, controls, localization, autonomous routines, and simulation models

  2. 02
    One deterministic runtime cycle

    sensors snapshot once, behavior resolves, mechanisms compute, and output arbitration prevents order-dependent hardware commands

  3. 03
    Optional adapters above stable hardware identity

    CTRE, REV, Studica, vision, and path integrations activate only when their official dependency is installed

  4. 04
    Simulation as a backend swap

    the same declarations, behavior, and hardware graph drive physics and sensor snapshots instead of a simplified parallel program

  5. 05
    WPILib-native distribution

    modular artifacts, standard dependency metadata, local publication, and standalone examples fit the tools students already use

Validation

  1. 01

    Standalone example robot projects compile against published artifacts, exercising the installation and public API that a team actually consumes

  2. 02

    Per-module and full-workspace builds guard dependency boundaries and the published integration surface

  3. 03

    Runtime benchmarks with allocation profiling cover scheduling, hardware refresh, the full robot cycle, and simulation without presenting a hardware-independent speed claim

  4. 04

    The same behavior actions and hardware identities are exercised through both real and simulation backends

06 / Project consequence

Why it matters in practice.

  • 01Students declare robot structure once instead of maintaining separate registration and lifecycle wiring
  • 02One input snapshot and output arbitration boundary prevents within-cycle inconsistencies and order-dependent motor commands
  • 03Real hardware and simulation share behavior, device identity, and sensor surfaces instead of drifting into separate programs
  • 04Optional adapters contain annual vendor API churn without forcing every team project to install every ecosystem dependency
My ownership
  • Framework architecture
  • Control layers
  • Autonomous tooling
  • Examples and mentoring
Built with
  • Java
  • WPILib
  • Controls
  • FRC
  • Documentation