My World

Why I built it

I'm a marathon runner with a history of recurring injuries, and I've learned firsthand that subtle differences in mechanics, like overstriding, heavy heel striking, or poor trunk lean, are major contributors to injury risk. Most runners have no easy way to get objective feedback on their form. I wanted a tool where anyone could point a camera at themselves and get an honest read on what their body is actually doing.

How it works

The system is a full pipeline from raw webcam video to a trained classifier:

• Pose estimation. MediaPipe's pose landmarker pulls 33 body keypoints from each frame of side-view video.
• Feature engineering. Four form-relevant features are computed per frame: knee angle, trunk lean, foot offset, and cadence (steps per minute).
• Confidence gating. Per-landmark visibility is checked before any metric is trusted. A green/red border tells you at a glance whether the current frame is usable.
• Labeled data collection. Bulk CSV recording stamps a form label (good, overstride, or excessive lean) onto every row, optionally baking an overlay MP4 alongside it.
• Classification. A random-forest classifier trains on the labeled frames and reports per-class precision, recall, F1, a confusion matrix, and feature importances.

The interesting part: how I evaluated it

The first model looked incredible: a stratified 80/20 split over all rows hit 99.7% accuracy. That number is a trap. With only a handful of recording sessions per label, a random row split leaks session identity into the test set, so the model quietly learns "which video is this" rather than "what form is this."

Re-running with leave-one-session-out cross-validation (holding out an entire session at a time) told the real story: accuracy fell to ~44%. excessive lean stayed cleanly separable because trunk posture is a stable, robust signal, but good and overstride were nearly indistinguishable.

I diagnosed the failure: the foot_offset feature was averaged across the whole gait cycle, but the foot swings forward and backward every stride, so its per-session mean sits near zero regardless of overstriding. The real overstride signal lives at the instant of foot contact, and averaging erased it.

What I took away

• Session-level cross-validation is non-negotiable with few sessions: a row-level split overstated true accuracy by 50+ points.
• Aggregating across a signal cycle can destroy the very phase-specific information that separates the classes you care about.
• Data quality beats feature engineering at this scale: the cleanest dataset outperformed every model and feature change layered on top of it.
• "Combine everything" isn't free. Correlated features increased a small-data random forest's variance without adding information. The bias-variance tradeoff, observed in the wild.

Where it's headed

Next steps are more sessions per class to stabilize the cross-validation variance, a proper streaming foot-strike detector for genuine real-time feedback, and a comparison against a small neural network. The end goal is unchanged: point a camera at any runner and hand them feedback worth acting on.

Overview

OmniFlow simulates a busy downtown intersection in real time: vehicles obeying signals, buses dwelling at stops, pedestrians crossing in phases, and emergency vehicles cutting through it all. It was the final project for CU Boulder's Object-Oriented Analysis & Design course, built with a teammate (Evan Mohan).

The point was never hyper-realistic traffic modeling. It was to demonstrate clean object orientation: polymorphism, dependency injection, design patterns, a responsive JavaFX UI, and basic persistence, all structured so the architecture is easy to reason about and explain. We deliberately narrowed an early, broader idea down to a single polished scene because it was easier to finish well and defend.

One interface, five behaviors

Every moving thing on the map (car, bus, emergency vehicle, bike, pedestrian) is updated through a single shared Agent interface. The simulation engine stores and steps agents polymorphically, so each type varies its own behavior through small override hooks rather than sprawling if/else trees or switch statements. Adding a new agent type means writing a class, not editing the engine.

Simulation behaviors

• Emergency preemption. A spawned emergency vehicle triggers a temporary all-red and clears the lane ahead, then despawns once it has cleared the scene.
• Bus-stop dwell. Buses pause at stops while trailing vehicles queue up behind them rather than clipping through.
• Phased pedestrian crossings. Directional walk signals with separate crossing phases, flashing countdowns, and longer walk windows so pedestrians finish crossing safely.
• Lane-aware bikes. Bikes stay on sidewalk routes and stop short of pedestrian crosswalks.
• Clean exits. Pedestrians and bikes leave the map at its edges instead of looping or teleporting back through the scene.

The UI exposes start / pause / single-step controls, a speed slider, agent-type filtering, click-to-select agent details, manual emergency-vehicle spawning, and save/load of the layout state.

Design patterns

Testing

Coverage focuses where it matters most, the model and simulation logic rather than exhaustive UI testing, across five JUnit 5 suites:

• AgentFactoryTest: agents are created correctly from type names.
• SimulationEngineTest: the engine steps the world and its injected dependencies as expected.
• LayoutBehaviorTest: signal timing, queueing, and crossing rules behave correctly.
• LayoutStoreTest: layout state survives a save/load round-trip.
• Camera2DTest: the 2D camera transforms world and screen coordinates correctly.

How it's built

The project is structured as four layers, each independently testable:

• Game engine. A Mancala board with move legality, stone capture, end-of-game detection, and turn alternation, built from scratch so every search agent talks to the same rules.
• Random baseline. Picks any legal move uniformly: the floor every smarter agent has to beat by a wide margin to count.
• Minimax + alpha-beta search. Identical move choices to plain minimax with a fraction of the node visits, making deeper plies practical.
• Custom heuristic evaluation. A linear combination of side-store difference and end-of-game stone-sweep credit, tuned through tournament play.

The interesting part: pruning vs. heuristic

Plain minimax at depth 10 was projected to take roughly two hours per game, clearly not playable. Alpha-beta pruning kept the same move choices but cut node visits by enough to make depth-10 search feasible in seconds, a ~3.9× speedup.

Even with deeper search, win rate against the baseline plateaued around 96%. The last gains didn't come from more depth. They came from teaching the heuristic to value end-of-game stone sweeps, which are decisive late in a game but invisible to a naive score-difference function. That single change pushed win rate to 99% at depth 5.

What I took away

• Alpha-beta isn't just a speedup. It's what makes deeper, otherwise-impractical search affordable in the first place.
• Heuristic design eventually dominates search depth. A small domain-aware tweak beat several plies of additional lookahead.
• Tournament play is the honest benchmark. Single games hide variance; 100-game tournaments make small heuristic edges visible.