Case study

Autonomous Transit

Our own flagship simulation — built to validate the platform's dispatch, parking, and mesh logic before we put it in front of a single customer network.

~70Mesh nodes
3Vessel types
15HzServer tick
1Shared world
Autonomous Transit simulation view showing a road mesh with a highlighted dispatch path in green (retrieval), yellow (trip with rider), and red (return to parking)
Live view of the simulation: green marks a vessel retrieving a rider, yellow marks a trip in progress, red marks a return to parking.
The approach

Summon-and-dispatch, not continuous circulation

Most fleet simulations assume vehicles are always moving. We built Autonomous Transit around a different premise: vehicles sit parked until summoned, then the system finds the best one for the job. A Python backend owns the mesh, the fleet, and the parking inventory, and runs the whole simulation itself — every connected viewer just watches the same authoritative world update by update, rather than each running their own copy.

Fleet composition

Three vessel types, two lifecycles

Round trip

Individual mover

Picks up a single rider, delivers them, then returns to the nearest open parking lot to wait for the next call.

Round trip

Group mover

Same lifecycle as an individual mover, sized for multiple riders per trip.

Single trip

Static vessel

Delivers its rider, then stays parked at the destination in active use for a while — think a mobile unit making camp — before becoming summonable again from wherever it stopped.

Dispatch & parking

ETA-first assignment, contention-free parking

When a rider summons a vessel, the system filters to eligible, idle vessels and picks whichever has the shortest calculated travel time to the pickup point — not simply the nearest by distance, since routes cross both fast and slow roads. The same logic runs in reverse for parking: a vessel claims its parking spot the instant a return trip begins, so two vehicles finishing around the same time never contend for the same space. Concurrent requests from many riders at once are resolved without any risk of double-booking a vessel.

Hover tooltip on an in-use static vessel showing the assigned rider, trip duration, distance travelled, and time spent stationary
Hovering any vessel shows live telemetry — who's using it, for how long, and how far it's travelled.
Multi-client architecture

One world, unlimited viewers

The simulation runs on a fixed server tick, independent of any browser tab. Every connected client — an operator, a stakeholder reviewing a scenario, a teammate on another floor — sees an identical, live view of the same fleet, because there is exactly one simulation, not one per viewer. On the client, motion is smoothed to 60 frames per second between server updates, so the shared world still feels immediate even though the authoritative tick runs slower.

This is what a simulation-first fleet looks like

We can build the same kind of environment around your network, your vehicles, and your demand pattern.

Talk to us