I do not build robots. I build the layer around them: a simulator that answers “how many do we actually need” before a single one is bought, a controller that dispatches a real fleet from a box on the shelf, and a platform that keeps the safety rules honest once those robots are outdoors and out of sight.
Eleven seconds of the real build. A warehouse floor 75 by 42 metres, drawn cell by cell, with ten robots working goods-to-person cycles across it. Nothing here is a mock-up: the paths you see are the ones the engine planned this tick.
Paint the hall: floor, wall, rack, station, charger, parking — plus one-way lanes drawn straight onto the grid.
Blue dots are loaded robots, green rings are robots at a pick face or station. The thin lines are live A* routes.
Fleet size, cruise speed, pick and drop times, battery in watt-hours, drive and charge power, demand mode.
Rack face, pick 12 s, station, drop 8 s, repeat — and below 20 % battery, a detour to a charger.
An integrator walks a warehouse and is asked the same thing every time: how many robots, how many pick stations, and will the aisles jam at peak. Getting that wrong in either direction is expensive — too few robots and the customer misses the carrier cut-off, too many and the deal dies on price.
The tools that answer it properly are discrete-event simulation suites that cost thousands a seat and take a week of modelling. So most quotes are still built on a spreadsheet, a cycle-time estimate and experience. That works until the layout is unusual — and a narrow aisle is exactly the case a spreadsheet cannot see.
This simulator sits underneath those suites on purpose: open a browser, trace the hall over the customer’s own floor plan, run it, and leave the meeting with a printed study. Everything is client-side; the layout never leaves the laptop.
A throughput number is only worth quoting if it survives being re-run, and if the traffic model breaks in the same places a real fleet does.
Every run is driven by a seeded generator, so the same scenario always produces the same number. That is what makes a result defensible in front of a customer — and what lets a test suite catch a regression in the traffic rules.
One robot per cell. A robot waiting for the cell you occupy has to let you out; in a head-on meeting the lower-priority robot retreats fully off the other’s route instead of shuffling sideways for ever; stations admit a limited queue and hold the rest at the rack face.
The report computes what the fleet could do with clear aisles — robots multiplied by travel and handling time — and subtracts the simulated result. The gap is the cost of congestion, queueing and charging, itemised rather than hand-waved.
Reports average several independent seeds and print the weakest and strongest of them, so a quote rests on a range instead of a coincidence. Twenty-four robots in the medium hall: 1 101 tasks per hour, spread 1 096 to 1 105.
Four halls, five fleet sizes, two simulated hours each, all from the current engine build. The two small halls are identical — 32 by 20 metres, four pick stations, same racks — except that one has one-metre aisles and the other two-metre aisles.
In the narrow hall, twenty robots deliver 1 044 tasks an hour. Add ten more and it falls to 579 — robots spend 49 % of their time blocked, and the fleet is now slower than it was with two thirds of the hardware. In the identical hall with two-metre aisles, the same thirty robots reach 1 239. One metre of aisle width was worth more than fifteen robots, and no spreadsheet estimate would have shown it.
The features that exist are the ones a sales engineer needs between opening a floor plan and handing over a PDF.
Drop in a PNG of the hall, click two points a known distance apart to set the scale, then trace racks and stations straight over it.
Reads an ASCII DXF directly — lines and long outlines become walls, small closed shapes become racks, units taken from the drawing.
Runs the layout headless across fleet sizes and recommends the smallest fleet within five percent of the throughput plateau.
Save variants — wider aisles, two more stations, a bigger fleet — and put them side by side with the best value per row highlighted.
Feed a Poisson order stream shaped hour by hour: morning peak, two waves, carrier cut-off. The report shows offered, completed and backlog per hour.
One click renders KPIs, diagnosis, layout, blocking heatmap, sweep and assumptions with the client’s logo, from a fresh reproducible run.
The cells where robots actually lose time are ranked and drawn on the layout, so the fix is a place on the floor, not a guess.
Results, sweep and comparison tables leave as raw numbers for the engineering team’s own models.
Plan keys are signed and verified in the browser against a public key. No licence server, no phone-home, works on an air-gapped laptop.
Forty-five seconds of AMR Platform driving three robots through the centre of Amsterdam, on streets imported straight from OpenStreetMap. The robots are simulated — but they report telemetry through the same path a physical machine uses, and the same supervisor watches them at 10 Hz. There is no second, friendlier copy of the safety logic for the demo to run on.
Green is driving, blue is idle, amber is blocked — the colour is the safety state itself, and the arrow is the heading.
The planned route: footways, alleys and squares only. A carriageway is crossed solely where a crossing is mapped.
A blocked robot asking for a person: clear the obstacle, or set another goal. It has already tried to route around.
The imported area, cached to disk and served locally — the panel keeps working after the internet is gone.
The importer emits only what it can justify: corridors from mapped ways, fills from mapped areas, strokes from mapped linear obstacles. Everything else stays unknown — and unknown is not traversable. A closed shape becomes an area only when it is tagged as one; a fence stays a fence.
Pedestrian, service, road, expressway — four profiles, picked by the operator and shown in the top bar. Making a main road merely expensive means a planner will eventually send a robot down the middle of it once the detour is long enough. That is not a trade-off a machine should make on a public street.
Eight seconds first, because most things blocking a pavement are people. Then the obstacle joins a fleet-wide map of observed blockages and the rest of the route is replanned around it — up to three attempts. Then it stops and says so once. Observations expire after two minutes and are never written to disk.
A robot may only move into space the fleet has reserved for it, in four-metre tiles, and brakes at the edge of what it holds. Reservations are contiguous and priority is a total order, so a deadlock cannot form; every reservation has a lease, so a robot that loses power stops holding the corridor.
Central Warsaw, 400 m radius, imported from OpenStreetMap: 2 186 features classified into a costmap the planner can defend. A simulated robot then drove 623 m of it to completion and stopped 0.7 m from the goal; a pedestrian dropped four metres ahead brought it from 1.5 m/s to a standstill two metres short, and removing them resumed the drive.
Three robots sent to one destination behave like a convoy rather than a scrum: the leader holds a full grant, the second is granted only as far as the leader’s claim and reports that it is waiting for it, the third queues behind. Following distance comes from the reservation system, not from luck.
The stop button in the browser is a remote operational stop, not a safety function. There is no hardware safety controller behind this server, the API reports hardware_safety: false, and it will keep reporting that until the safety-controller stage is built and commissioned on a bench. Driving a mission on a physical robot needs ROS 2 on the robot itself — the Nav2 backend is implemented and refuses to start without it, rather than quietly pretending to drive.
They were built in this order for a reason: you plan a fleet, then you drive one, then you have to answer for it when it is out in the world. Each is a separate codebase with its own tests.
Plan the fleet
Draw or import a warehouse, set the robot parameters, and get throughput, cycle time, energy per task, charger and station utilisation, blocking hotspots and a fleet-size recommendation — with a printable study at the end. TypeScript and a plain 2D canvas, no framework, no server.
Drive the fleet
A single-file Python server with a touch-first operator panel, written to run headless on an NVIDIA Jetson and be driven from a browser over the LAN. Real robots register over HTTP, stream telemetry and pull their next waypoint; the engine plans around obstacles, other robots, no-go and slow zones. Vector basemaps work offline from a packed tile file, with WGS84, UTM and MGRS read-outs for field crews.
Answer for the fleet
The production-shaped version for outdoor fleets: FastAPI and SQLite, a validated safety state machine, tiered emergency stop, stuck detection with rerouting around blockages the fleet has actually observed, and a range-based battery policy that recalls a robot before it strands. Hardware integration lives behind explicit interfaces, so nothing pretends a physical safety layer exists when it does not.
Fleet software is easy to demo and hard to be honest about. These four rules are written into the codebases, and they are the reason some obvious-looking features are missing.
unknown != safeSpace the robot has not observed is treated as blocked, not as free floor. A map that has never been checked is data, not permission.
an e-stop is never cleared by codeSoftware can trigger a stop and can report one. Releasing it is a human action at the machine — there is no API call that resets it.
the server sends goalsReal-time motion safety belongs on the robot, close to its sensors. A fleet server over a network sends destinations and constraints, never the last-metre decision.
no software claims a machine is compliantSafety functions are stubbed behind explicit interfaces rather than faked. Where a certified component is required, the code says so instead of standing in for it.
These are personal projects, and nothing on this page is for sale. If something here is useful to you — or you think it is wrong — write to me. I read every message myself.
Figures on this page were measured on the builds as they stood on 6 September 2026: 4 hall layouts × 5 fleet sizes × 2 simulated hours, seed 42. Current statuses are on the projects page.