Landing Page
Course setup
RV navigating

Inspiration

We started from the paper SafeFlowMatcher: Safe and Fast Planning using Flow Matching with Control Barrier Functions (Yang, Jang & Han, ICLR 2026). It combines flow matching, a fast generative planner, with control barrier functions, a tool from control theory for keeping systems out of unsafe states. We wanted to know whether that idea would hold up on a rover driving around a factory floor, with forklifts and obstacles moving around it. We wanted to build the whole loop ourselves, from the dataset and model to the controller and a 3D view.

What it does

Northstar is a simulated autonomous rover inside an industrial facility. Each planning cycle:

A flow-matching neural network we trained from scratch proposes 8 candidate trajectories, each 6.4 seconds long.
A ranking step throws out candidates that collide and picks the best of the rest.
A CBF-style safety filter checks the steering and acceleration command before it runs. It simulates the rover forward, including a full-braking backup, and changes the command if the rover could hit something.
A kinematic bicycle model moves the rover, and a React Three Fiber frontend renders it in 3D.

The demo lets you set a destination, drop obstacles and send forklifts across the rover's path.

How we built it

Data: We built a classical expert planner: Hybrid A* with smoothing and speed planning that accounts for curves and moving obstacles. We ran it over 1,663 procedurally generated scenarios, which gave 22,464 training windows. Train, validation and test are split by scenario, so no scenario appears in more than one split.
Model: PyTorch, about 1.06M parameters, trained on GPU with AdamW (about 35 s per epoch). On top of the flow-matching loss we added extra losses for heading, speed and keeping the sin/cos heading values valid.
Safety: A discrete-time CBF-style filter over acceleration and steering. Clearance has relative degree 2 (a steering or throttle command only changes the distance to an obstacle two steps later, through heading and speed), so the filter rolls the plant forward rather than just checking distance.
Stack: A FastAPI and WebSocket backend streams state frames to a React + TypeScript + Three.js frontend. Tests run on pytest and Vitest.

Challenges we ran into

Generating the right dataset. Our first dataset (v1) contained expert trajectories the rover physically can't drive. One turns 67° over 11 cm, when the bicycle model allows 3.9°. About a quarter of v1 training targets had a step like that. We rebuilt the dataset (v2) so every trajectory is drivable. We also found that one input feature (subgoal) leaked the answer, so we removed it and added tests to keep it out.
The rover behaving wrongly. A single model sample collides 47–61% of the time, and headings were off by more than 40° early on. The cause was a coordinate mismatch: the maps are aligned to world axes but the trajectories are in the rover's frame. Adding the rover's world heading as an input, plus 3.9× more data, cut heading error from 42.9° to 22.8°. Our ranking step also rejected too many candidates because it checked the model's raw speed and steering. That pushed the fallback rate from 24% to 76% until we changed it to reject on collisions only.

Accomplishments that we're proud of

0 collisions in 12 held-out scenarios with the safety filter on, compared with 9 of 12 with it off. The filter didn't cost a single goal arrival.
Ranking 8 candidates raised the share of planning windows with at least one collision-free option to 86%.
The full pipeline runs end to end: model, ranking, safety filter, physics and a 3D frontend.
All the numbers on this page come from runs we measured.

What we learned

A generative planner on its own isn't safe to drive, but sampling several candidates, ranking them and adding a safety filter makes it usable. That's the main argument of the paper, and we saw it in practice.
Data quality mattered more than model size. Smaller models underfit, and the bad v1 trajectories still look like the main cause of the remaining heading error.
The training loss doesn't tell you whether the rover drives well. We picked checkpoints by physical metrics like heading error and collision rate.
Getting CBFs right for real vehicle dynamics is hard. A rule like "brake if too close" isn't a CBF, and we don't claim a formal guarantee.

What's next for Northstar

Real-world use. We want to move toward real industrial robots such as warehouse and factory AGVs, and other settings where rovers share space with people and vehicles.