Robotics · FRC 2024

Terry

A 2024 FRC robot with swerve drive, a pivoting shooter, vision-assisted aiming, reusable autonomous routines, and a simulator used during development. Terry was built to pick up and shoot orange donuts called notes in the 2024 FRC game, Crescendo.

Measured highlights

Fully synchronized digital twin: dual-purpose runtime for simulation or real deployment
±3 cm precision: required for precise autonomous navigation
92% shot accuracy: effective range: 4-20ft

Context

The 2024 game rewarded fast collection and shooting, so the robot needed to move accurately and spend as little time as possible lining up each shot.

Terry is a swerve-drive competition robot that picks up game pieces, aims, shoots, and runs autonomous routines using the same core logic in simulation and on the physical robot.

The software work

Simulation
The Java simulator supported autonomous and teleoperated operation while sharing core logic with the physical robot.
Motion
Swerve-drive kinematics, odometry work, and tuned acceleration curves supported autonomous positioning.
Scoring
Reusable path segments and shooting calculations let autonomous routines combine movement and game-piece handling.

Render of Terry — Terry's exported CAD assembly. Drag to inspect on desktop.

My role

Responsibility: Software Lead
Team: Software team of about 10
Tools: Java · WPILib · Swerve · Autonomy · CAD

I led a software team of about ten and wrote substantial parts of the Java robot code. I built the simulator, developed the shooting-while-driving math, tuned motor acceleration, worked on odometry, and built reusable autonomous path segments. I also wrote base-case unit tests and improved motor configuration reliability.

Paths and simulation

1 / 3

Modular autonomous trajectory drawn on the CRESCENDO field — Reusable path segments compose an autonomous route.

Terry simulation beside the speaker scoring target — The simulator includes the robot and field scoring geometry.

Terry simulation at the amp scoring structure — A second scoring position in the same simulation environment.

Process & decisions

Simulation was waiting on fake hardware.

Fake motors and other simulated devices still passed through configuration written for physical hardware. Some vendor configuration calls added waits even though there was nothing to configure.

Separate hardware setup from robot behavior: I identified which configuration work only mattered on the physical robot and kept it out of the simulated startup path.
Keep the shared logic intact: The simulator still ran the same autonomous and teleoperated code instead of becoming a separate simplified implementation.
Check the base cases: I added unit tests for basic behavior so the faster startup path did not quietly change how the robot code worked.

Shooting while moving

1 / 2

The simulator exercises shooting while driving from a third-person view.

The same behavior viewed from the robot in simulation.

Outcome

First simulation startup became about 13 seconds faster, an improvement of roughly 80%. That made the simulator easier to use while the physical robot was being built or repaired.

Before: Hardware-only waits in simulation
After: About 13 seconds removed

On the field

1 / 4

Terry at the speaker during a competition match

Terry launching a game piece during a match

Terry collecting a game piece autonomously on the competition field

Terry with its climbing mechanism extended