Run my robots

The whole stack, live

Chase

Your cursor is the goal. astar_planner.py plans to it, and dwa_controller.py tracks that plan — sampling a velocity window, rolling every candidate forward, scoring them on heading, clearance and speed, and committing to one, ten times a second at the node's own dt. Both files are the ones fetched above, running unmodified.

Click anywhere to drop an obstacle. The costmap is re-inflated, the global plan is thrown away and re-run, and the controller keeps tracking whatever comes back — which is the entire point of the repository.

Swap the controller and chase again. Same planner, same costmap, same cursor — only the thing following the plan changes, and they follow it differently enough to feel it. Each one draws what it is actually looking at: the point Pure Pursuit steers at, the point on the path nearest Stanley’s front axle — not its centre, which is the whole idea of the law — and the band TEB is deforming. Only DWA has a rollout fan, because only DWA scores a window of trajectories. MPPI is here too, but it runs in a worker: a tick costs about 580 ms and that is one indivisible call, so on the main thread it would freeze the cursor instead of chasing it. Off the main thread the page stays at 60 fps and the robot does what a real base does when its controller is slow — keeps moving on the last command until a new one arrives. Pick it and watch the lag in the readout; that number is the honest cost of 1000 samples a tick.

The last one is not from the repository — it was trained here. Clone is a small network fitted to DWA's own output: tools/train_clone.py drives the real dwa_controller.py across generated maps, records what it saw and what twist it committed to, and fits an MLP to that. Driving with it, the fan you see is the observation the network actually got — range along a spread of bearings, plus the goal in the robot's frame and its current speed. No velocity window, no rollouts: one forward pass. The section below has the numbers, including the ones that are not flattering.

Controller DWA Pure Pursuit Stanley TEB MPPI Clone Clear the field

global plan rejected rollouts committed trajectory what the controller is looking at inflation layer

Five controllers, one plan

Race

The package ships five local controllers. They all take the same job — here is a path, follow it — and they disagree about how. So: one A* plan, one costmap, five identical robots, and each controller running its own _control_loop at its own dt, on the tuning the repo ships. Nothing is normalised.

Fairness is in simulated time. Every frame advances each controller by however many of its own ticks add up to the same simulated interval, which is why MPPI takes two where the rest take one. Watch the two turns: a straight run would tie, and it is coming off the end of one wall and then the other that separates a controller which cuts the corner from one that holds the line.

MPPI is off by default, and not because it loses — it lands third of four on both maps of the package’s own controller suite, ahead of TEB and behind Pure Pursuit and Stanley. It draws 1000 samples a tick and spends real time doing it: about 470 ms a tick in this tab against roughly 2 ms for DWA, which is 18 seconds of driving that takes three minutes to watch. The profile puts that cost in _sample_controls and _path_angle_cost, not in marker building, so there is nothing to trim without running something other than what the repo ships. A robot with a real CPU makes its 20 Hz. Turn it on if you want to see it; the ms/tick column is why it is off.

Run the race

Different repo, same idea

Reach in

This is the UR12e cell from reactive-replanning-ur12e, seen down the RealSense. The arm runs the node's own cycle — open, PICK, close, PLACE, open, then park while the baseline rebuilds — and its joints are solved each frame rather than played back. The pick and place are not coordinates I picked: _build_poses() offsets the home pose by pick_z_offset and place_y_offset, and those two numbers are read out of the fetched source, so retuning the node retunes this. _cloud_cb runs on every frame of it: the depth gate, the workspace box, the colour mask that drops robot-coloured points, and the geometric self-filter that erases the arm from its own view. Every count on the right is read off the node's own filter calls.

Move your cursor to put a hand in the workspace. Put it on the dashed line the tool is following and the node does what it does on the robot: injects a collision sphere at SPHERE_RADIUS, notices a planned waypoint is inside SPHERE_RADIUS + PATH_CLEARANCE, cancels the motion, waits DECEL_WAIT for the arm to actually stop, and replans — lifting by DETOUR_HEIGHT and going over, or stepping aside, whichever plan_arc_detour picks for the direction it was travelling. Every threshold in that sentence is read off the node.

The interesting part is where it stops seeing you. Walk the hand onto a link and it vanishes into the self-filter — the repo's own test puts that edge at 11 cm, and you can find it yourself. Chase the tool and the dashed circle turns: that is PREEMPT_DIST, the radius inside which the node cancels the motion it is executing and replans. Both are the cost of never reporting the robot as an obstacle.

A copy, not a fetch — vendor/qlc/

Cross the ice

Click anywhere on the course. Four cost functions for a Unitree Go2 plan and drive to the point you pick — default Nav2 inflation, a hand-tuned legged costmap, a supervised learned cost, and maximum-entropy IRL — over the same terrain, with the same A* and the same DWA. The only thing that differs between the four routes is the cost function. The dashed line is a privileged oracle handed the exact cost the simulator charges: a ceiling, not a competitor.

Course ice_shortcut mud_field stair_bench rubble_slalom mixed

Physics after the MuJoCo calibration as first written Run the course

Plate ground truth nav2_inflation reactive learned irl

nav2_inflation reactive learned irl oracle (ceiling)

A copy, not a fetch — vendor/oba/

Seat a connector

Two UR5s on a NIST Assembly Task Board. An eight-phase insertion controller picks up a D-sub connector and presses it into a socket; a five-phase bimanual one threads a wire through three clips, letting go and taking hold further along each time. Both are oba.sim.expert, scored by the same detectors the simulator arm uses. Watch the force bar: a connector resting on a socket and one seated in it are millimetres apart in position and an order of magnitude apart in newtons.

Task connector insertion wire routing Run the episode