RoboNode

Gallery

gallery/03-real-ur10e.png — The same contract driving a real UR10e. The simulator is the safe half of the loop, not the whole of it.

The story

Testing a robotics algorithm usually means building everything around it first. A simulator, a robot model, a scene, a controller, a way to see what happened — days of setup before the idea you actually wanted to try gets to run once. So most algorithms are evaluated in a notebook, on a chart, or in a simulation gentle enough that they pass.

That is the part worth removing. Not the physics, and not the robot — the setup.

A simulator that lets your algorithm succeed is worse than no simulator, because you believe it.

The product

One command brings up a cell in the browser: a UR10e on a rail, a conveyor, a bin, a pallet, and a running application you can watch. The physics is real. The arm is stopped by whatever is in its way, a grasp is a constraint on the part it actually caught, and the conveyor moves the workpiece by friction.

Four things in that cell are nodes: what sees, what tracks, what plans the path, and what controls the arm. Each is one typed interface with several implementations and an empty slot for yours. Open the editor, write a grasp offset, and it compiles into a sandbox and becomes another selectable version. Then run the same application against both and compare.

Breaking it is the demonstration. Switch tracking to the snapshot version and run the moving-bin application: the arm aims where the part was and misses, in the same way it would miss on a real line. Nothing about that failure needs a rig, a safety fence, or a technician.

The engines underneath are borrowed on purpose: MuJoCo, OpenCV, Ruckig, Pinocchio. What I built is the boundary around them, the sandbox that lets a stranger’s code run beside mine, and the one wire contract that the browser, the CLI and anything else all speak.

What it taught me

The scenario has to be unfair or the result means nothing. An easy cell makes every algorithm look competent. The default scene moves the target, delays the sensor, and puts a decoy in the bin that is the same colour as the part — so a tracker that assumes a stationary world misses visibly, and the log names what it hit rather than reporting a lower score.

One interface per capability, and the seam is the product. Vision, tracking, trajectory and control are four typed slots with interchangeable versions and a bring-your-own option. Because the seam is owned, swapping a planner touches neither the UI, nor the CLI, nor the real-time loop — and that is the entire reason a stranger’s algorithm can be dropped into a running cell at all.

Reuse the mature engines; the platform is the glue. MuJoCo for physics, Ruckig for trajectories, OpenCV for vision, Pinocchio for kinematics. None of them is reimplemented. What is actually hard, and what I built, is the clean modular boundary and the swap-and-compare experience around them.

Third-party code runs in a sandbox, not in my process. User algorithms compile into a fuel-bounded VM with no host surface, so a runaway loop stops instead of taking the cell with it. The moment a platform invites strangers to write control code, that stops being optional.

Every UI action has a CLI verb, and that was not free. One contract, three surfaces — web, CLI, and other clients — with the wire format defined once. It costs discipline on every feature, and it is why the thing can be driven by a script, a person, or an agent without three implementations drifting apart.

Gallery

The story#

The product#

What it taught me

The story

The product