Physical AI, with a map underneath
The map layer your physical-AI city stack is missing.
Routing, a real road graph and left-hand UK data, self-hosted, wired into the perception, simulation and optimisation tools you already run. Five things we built, with the numbers.
A camera on the A406 sees a stalled car. A self-hosted vision model checks the clip. A second signal confirms it. Our router closes the carriageway and every route, fleet plan and navigation session reroutes.
What the public stack does not have
No routing in the smart-city reference stack.
The open smart-city blueprint builds its road graph with osmnx, geocodes with public Nominatim and shows the map in an iframe. A detected crash, stall or wrong-way vehicle never becomes a closure or a reroute.
Blueprint source, v3.2.1
No left-hand roads in the AV data.
The physical-AI AV dataset covers 25 countries and none of them drives on the left. The UK, Ireland, Japan and Australia are absent, while adopters of the same reference vehicle platform drive in London and Japan.
Dataset card, re-read 1 October 2026
No open matrix behind the GPU optimiser.
The only map partner named for the GPU route optimiser is a closed cloud service. There is no open, self-hostable, truck- and dangerous-goods-aware travel-time matrix for it to solve on.
Optimiser docs and partner page
Eyes on the Graph
A camera incident becomes a road closure in our router, and every route around it changes. Replayed on London's A406.1
OpenStreetMap contributors, OpenMapTiles. Powered by TfL Open Data
A traffic camera feed is checked by a self-hosted vision-language model, corroborated by a second independent signal, snapped to the directed road edge it is looking at, and written into the live routing graph as a timed closure or speed override. Routes, fleet plans, the MCP tools and the navigation app all see it within one traffic pass. Two new MCP tools let an agent read camera incidents and set a temporary closure, behind an admin token.
Runs on Cosmos 3 Nano on vLLM; VSS incident schema v3.2.1; MapMap live-traffic pass and MCP.
The reference smart-city stack detects the incident and stops there. This is the step after detection: the road network reacts.
Run the blueprint on a UK city with our router underneath it: incidents in, closures and reroutes out, with the clip attached to every diversion.
cuOpt on an open truck matrix
1,000-stop lorry days in London and Manchester, solved on cuOpt against our self-hosted truck matrix: 2.4 percent less driving at 180 s, 4.7 percent at 600 s, over the open-source baseline.2
OpenStreetMap contributors, OpenMapTiles. Contains OS data, Crown copyright and database right 2026
Our gateway can choose between the open-source VROOM solver and cuOpt behind one /optimise call (cuOpt on self-hosted deployments; the hosted API stays on VROOM), on the same travel-time matrix computed by our routing engine with 44 tonne truck restrictions in the costing. Six 1,000-stop instances, three in London and three in Manchester, built from open UK postcode data: 25 x 44 t trucks, 7 minutes of service per stop, 30 percent of stops with a 4 hour window. One shared checker replays every route from the matrix, and every plan from both solvers had zero violations.
Runs on cuOpt 26.08 server on one A40; VROOM 1.15 baseline; MapMap truck costing matrix.
The GPU optimiser has no open, self-hostable, truck-aware matrix partner. Ours is one container next to it, and it knows which roads a lorry cannot use.
Publish a joint benchmark at 3,000 to 5,000 stops with dangerous-goods profiles, on data anyone can reproduce, and ship the cuOpt backend to self-host customers.
A city as OpenUSD
A bounding box becomes a georeferenced OpenUSD stage: terrain, lidar-height buildings, roads that carry our routing engine's edge ids, places, and a slot for a Gaussian splat. It opens and path-traces in Kit.3
OpenStreetMap contributors. Contains Environment Agency information, OGL v3.0. Terrain: Mapzen terrain tiles
One command exports a city block as layered USD. Buildings take their heights from the Environment Agency's 1 m lidar, roads are BasisCurves tagged with the routing graph's edge ids in both directions so a route can be highlighted in the scene, and the stage carries its anchor three ways: the geospatial schema used by Omniverse, the Cesium for Omniverse georeference, and the draft CRS proposal. We checked all three in a headless Kit session.
Runs on OpenUSD 26.8 with the ParticleField splat schema; Omniverse Kit via Isaac Sim 6.1; Cesium for Omniverse 0.29.
Omniverse has raster tiles and elevation but no vector or road-network ingest, and no UK city twin among its showcases. This is the road graph, with ids a router understands.
A UK city block in your showcase with a live route drawn through it, and the exporter offered as an async job and an MCP tool anyone can call.
Drive it, splat it
One pass of our capture rig becomes a 4.6 million Gaussian OpenUSD splat of a real UK street, georeferenced to the centimetre, with a path-traced drive through it rendered in Kit.4
The rig's lidar, 360 cameras and GNSS go through our own pipeline into an NCore dataset, a trained splat and a two-prim ParticleField USD tile placed at a named anchor. The lidar rays in the dataset land a median 0.67 mm from our 3 cm map, so the splat sits where the road graph says the road is. Faces and plates are blurred and gated before any frame leaves our machines.
Runs on NCore 19.8; gsplat and 3DGRUT trainers; OpenUSD ParticleField, Kit path tracing.
The reconstruction and rendering stack is excellent. What it lacks is a UK street captured by someone who also runs the map and the router underneath it.
Rebuild your test routes in the UK as georeferenced splat tiles that sit on a routable graph, and compare trainers on one shared scorer.
Left-hand driving test
We ran the open 10B driving model on UK roads from our own rig and scored it against lidar ground truth. Its reasoning assumes right-hand traffic; its paths follow the road.5
Turn 04 of 20, in the car’s own frame, 6.4 s ahead
- What the driver did, from the lidar
- The path the model chose
- Its five other samples
The model’s reasoning for the path it chose
“Change lanes to the left to pass the parked car blocking the right lane after briefly slowing for the speed hump.”
Its words put the parked car in the right lane, which on a UK road is the oncoming side. Its chosen path went where the driver went.
01
02
03
04
05missed
06
07
08missed
09
10missed
11
12
13
14
15
16
17
18
19
20missed
Twenty junction turns from a UK drive, the seven-camera ring synthesised from our 360 rig at the model's own resolution, navigation text from our router, and the predicted paths scored against the lidar trajectory. The language head calls the oncoming side 'the right lane' and plans to pass a car parked there; the trajectory head follows the road. Not one of 240 reasoning strings mentions driving on the left.
Runs on Alpamayo 2 Super (OpenMDW) on one 96 GB GPU; MapMap routing for the navigation text; MapMap rig lidar as ground truth.
The AV dataset has no left-hand country in it, and it shows. We have the roads, the rig and the ground truth to measure the gap and to help close it.
A UK roundabout benchmark on our data, with navigation text from our router, as a poster and as an evaluation set you can run.
Third-party software used
Cosmos 3 Nano, self-hosted on vLLM
Build 01. Watches the camera clip and returns the incident verdict.
VSS incident schema v3.2.1
Build 01. The format our incident verdicts are written in.
cuOpt 26.08
Build 02. Solves the day's truck routes on our travel-time matrix.
OpenUSD 26.8 and the ParticleField schema
Builds 03 and 04. The exported city block and the splat street tile.
Omniverse Kit via Isaac Sim 6.1
Builds 03 and 04. Opens the stages headless and path-traces the films.
Cesium for Omniverse
Build 03. Places the exported stage on the globe.
NCore 19.8
Build 04. The dataset format our rig drive is packed into.
Alpamayo 2 Super
Build 05. The driving model we tested on UK left-hand turns.
Rented A40 and RTX PRO 6000 GPUs
All builds. Rented by the hour for training, rendering and model runs.
Product names belong to their owners. This page describes our own tests of publicly available software and data, and implies no partnership, endorsement or certification by anyone named.
Everything underneath is public and self-hostable.
Get an API key
Routing, truck and dangerous-goods costing, matrices, optimisation, geocoding and tiles behind one key, issued card-free.
Point an agent at our MCP
The hosted MCP endpoint needs no key to connect. Route, search along a route, plan an EV journey, verify places, read incidents.
Run it on your own GPUs' neighbours
The whole stack boots from one Compose file: gateway, routing engine, geocoder and MCP server. No call home.
Tell us which of these you want to run with your team.
We are a small UK team that owns the map, the router and the capture rig. One email reaches the people who built every section above.
hello@mapmap.ai
Caveats and sources
1. Build 01, Eyes on the Graph
Replay on a local engine with synthetic incidents placed at real A406 camera positions, not a live deployment. The vision model's verdicts were measured on five public night clips: four rejected at 0.998 to 1.000, one ordinary-traffic clip confirmed as a collision at 1.000 on both runs. That false positive is why a closure needs a second signal.
Run nvidia-eyes-on-graph, 1 to 2 October 2026; GPU time USD 0.68.
Read more: MCP tool reference, Incidents along a route, Agents guide
2. Build 02, cuOpt on an open truck matrix
Two cities (Greater London and Greater Manchester), three seeded instances each, 1,000 stops, one 44 t truck profile and free-flow travel times. VROOM ran on CPU at its highest exploration level and cuOpt on one A40 GPU, so the wall-time ratios compare two runs on different hardware, not two chips. cuOpt's time limit is a budget, not convergence, and its plans vary from run to run (the figures are medians of three repeats at 180 s). Uncapped, cuOpt can use more trucks than VROOM and wait longer at windows; the capped figure separates route quality from fleet use. Not yet a published benchmark.
Run nvidia-cuopt-matrix, 1 to 3 October 2026; GPU time USD 2.33; report in tools/cuopt-bench/report.md.
Read more: Route optimisation docs, ADR dangerous goods, Truck data audit
3. Build 03, A city as OpenUSD
Exports ran against a local engine on a Sussex extract. The draft CRS proposal is not registered by Kit and is ignored there. Cesium placed our anchor 0.15 m from exact WGS 84 north; we traced that to the geodetic normal used for the local frame at 45 m height, not to the stage.
Run nvidia-usd-export, 1 to 2 October 2026; GPU time USD 2.67.
Read more: Self-host guide, Self-hosting, Point clouds
4. Build 04, Drive it, splat it
The vehicle in the render is a licensed stock model with blank plates, not a SimReady asset, and the render is checked by a person for plates, faces and house numbers before it is published. The street is described no more precisely than a residential street in West Sussex.
Run nvidia-splat-street, 1 to 2 October 2026; GPU time USD 8.25 across render and bake-off.
Read more: Roadside capture, Point clouds, Lidar viewer
5. Build 05, Left-hand driving test
Twenty samples of junction turns, not roundabouts, from one drive: a demonstration, not a benchmark. The model's published 0.911 m figure is on its own data, rig and scenario mix and is not comparable. Two of the four turn-side misses came 3 s before a right turn with the reasoning fixed on a speed bump. The roundabout set is the next run.
Run nvidia-lefthand-bench, 2 October 2026; GPU time USD 0.43.
Read more: Roadside capture, Imagery policy, Truck and route data
Status on 3 October 2026: the code for all five builds is merged. The cuOpt backend can be selected on self-hosted deployments; the hosted api.mapmap.ai keeps VROOM behind /optimise. Camera incidents (Eyes on the Graph) are built and deployed switched off by default. The OpenUSD exporter is a tool in our repository; an API endpoint for it is pending. The splat pipeline and the left-hand driving bench live in our capture pipeline repository. The measured runs above used local engines and rented GPUs. Numbers are from single runs and are reported with their caveats; nothing here is a published benchmark.
Street imagery and splats from our capture rig are blurred and gated before any frame leaves our machines, every published render is checked by a person for number plates, faces and house numbers, and the street is described no more precisely than a residential street in West Sussex. If you recognise a property in anything on this page and want it removed, email hello@mapmap.ai and we will take it down.