Software
We started in Java with a tick-based architecture and outgrew it. The rewrite into a command-based Kotlin codebase gave us modularity, parallel development, and autonomous interoperability — all of it version-controlled on a team GitHub with reviewed pull requests.
Drive the robot when there is no robot
We fully abstracted the robot's I/O so the same codebase runs on hardware and in simulation. It executes as a unit test — no Android dependencies — and renders in real time through a USD viewport on Storm and Metal, with CAD imported straight from STEP files. You can drive the simulated robot with a normal game controller.
Jolt + Three.js, runs in any browser
A second, browser-based simulator built on the Jolt physics engine and Three.js. It runs in real time on any browser with accurate physics, which lets us verify autonomous paths and give drivers practice time when the robot is in pieces on the bench.
Motor dynamics, kinematics, projectile motion
A useful simulator needs a model of the robot. Ours combines motor dynamics, mecanum kinematics, and projectile motion to approximate how the physical robot responds to control input and explore its limits before testing on hardware.
One button, the whole cycle
A finite state machine drives the multi-step sequences — intaking, indexing, shooting. Kotlin's async functions let us schedule hardware tasks concurrently and wait for them to finish before transitioning, so a driver triggers an entire cycle with one button instead of coordinating four inputs under pressure.
We built the path editor too
We pose trajectories between waypoints as an optimisation problem with modeled motor constraints, with shorter traversal time as a goal. Inspired by FRC's Choreo, we built a web interface for creating and editing those paths, so tuning an auto does not mean editing numbers in source.
Odometry + vision, continuously corrected
PedroPathing handles autonomous trajectories. In TeleOp we fuse Pinpoint odometry with Limelight vision through a Kalman filter that weights each sensor by confidence, rejecting noisy vision while still taking global pose corrections.
SAM-labelled data, trained on Duke's H200s
The Limelight reads AprilTags for localization and the motif pattern, and runs our own artifact classifier on its coprocessor. We label datasets with Meta's Segment Anything Model and train the lightweight competition model on Duke University's H200 GPU cluster.
The shooter calibrates itself
A global shutter camera indexes the ramp and locates artifacts on the field. Paired with an OAK stereo camera, it also maps shooter RPM and hood angle to real shot trajectories automatically — so the shooter calibrates itself from observed arcs instead of guesswork.
Measured, not assumed
Every optimised control loop is measured, not assumed. We compare current against previous and expected performance on each change, which is what makes it safe to keep rewriting the control stack mid-season.
For the post-States Worlds robot, we modeled its motion and mechanisms, then used those models to shape planning and feedback control. The simplified objective shown here is how a time-optimal trajectory can be written; it is an illustration, not a claim about the exact solver used on the robot.
Model-based trajectory planning
Uses a robot model to evaluate future motion and choose control inputs within modeled drivetrain limits. The trajectory objective favors shorter traversal time; the result depends on model accuracy and the chosen constraints.
Corrects accumulated odometry drift
A GTSAM factor graph combines odometry with Limelight AprilTag observations to update the robot's pose. Reliable tag observations can correct error accumulated by odometry.
Feedback along a reference path
We linearize the motion model around a reference path and use a Linear Time-Varying controller to update drive commands as the robot moves. Performance depends on how closely the model and reference match the robot's motion.
Chooses shot settings to separate landing points
With no mechanical sorter on the Worlds bot, the turret separates consecutive shots in flight. Given a Lipschitz bound on how launch settings change predicted landing position, the Shubert–Piyavskii method searches for settings that maximize the gap between landing points.
Balances speed error and control effort
A Linear-Quadratic Regulator balances flywheel speed error against voltage effort in its cost. Its settling time and overshoot depend on the model, tuned weights, and motor voltage limits, so they need to be measured on the robot.
How we write code
Git for version control with conventional commits, so the history reads cleanly. Every pull request needs at least two human reviewers before it merges. We use agentic AI to accelerate development, but we architect the key systems and write the hard parts ourselves.
How we use AI
We use AI for repetitive code that needs little critical thinking. Every AI-written line is reviewed by the programmer who prompted it, then again in a PR review — two cycles of human review. Advanced systems have their architecture planned before AI touches them.
