Mobile Particle Forensics Robot

The problem

A wafer inspector is the tool a fab trusts to tell it whether its process is clean. When the inspector itself starts shedding particles, that trust inverts: the instrument becomes the contaminant, and every measurement it produces is suspect until someone finds the source.

Finding it is hard. The contamination is sub-micron, the interior is a tight, partially enclosed volume full of expensive optics, and diagnosis today depends on an experienced engineer with a flashlight, a swab and a hypothesis. That is slow, hard to repeat, and the knowledge stays in individual heads.

What I’m building

A collaborative arm on a rail base carrying a custom inspection head, which reaches into the equipment, images fine particle distributions under UV, and maps them back onto a reference frame.

Two perception jobs run at once, and separating them is the core architectural decision:

• Inspection eyes: high-magnification UV and 2D imaging feeding particle detection, size distribution and spatial mapping.
• Guiding eyes: a wrist-mounted depth camera building a voxel map for collision-aware motion planning into tight spaces.

Conflating the two is the obvious mistake: the optics that resolve a sub-micron particle are useless for knowing whether the elbow is about to hit a bracket.

How the agent fits in

An engineer describes a symptom in plain language. The agent proposes an inspection sequence, executes it behind confirm-gates, presents the image evidence it gathered, and iterates with the human on what to look at next.

A bounded action executor with human gates is the only responsible way to let an LLM drive real actuators near expensive hardware. It is the same pattern behind the action layer in Nexop.

The simulation runs on the real controller

The design review is complete and audited, and the motion stack now runs.

Universal Robots ships URSim as a container running the PolyScope controller itself: the same interpreter as a physical UR5e, not a mock. URScript sent to it over TCP executes for real. Alongside it, Gazebo carries the full cell: the UR5e on a carriage riding a 3 m oval rail, with the rail declared as a seventh joint in the same kinematic chain as the arm.

That detail carries the design. The rail is not a second robot choreographed against the first: MoveIt plans one trajectory across all seven joints and a single controller executes it. Ask for a point the arm alone cannot reach, and the carriage slides while the arm articulates, as one motion.

A companion node exports MoveIt’s planned path as a standalone URScript file that replays directly on the UR controller, keeping MoveIt’s per-segment timing rather than flattening it to a constant speed. The planner is a development convenience; the exported script is what would travel to real hardware.

Three ways to reach the same point

• Arm only. A path constraint pins the rail where it is. If the target is out of reach, planning fails rather than sliding the base to compensate. This is the “rail locked out for maintenance” mode, and a clean failure is the reason it exists. With the rail held this way, carriage drift stays within 5 mm.
• Arm and rail together. The planner is free to use both and decides for itself whether the rail is needed.
• Stow, traverse, deploy. The arm folds into a vertical column above the carriage, the rail traverses to the position that puts the target at a comfortable reach, and only then does the arm extend. Nothing should cross a floor with its arm out.

Building the third turned up a problem you only find by running it. The obvious transit pose, arm fully extended along the rail, sits at a kinematic singularity. The IK solver could not iterate away from it and the deploy stage aborted every time. Stowing vertically fixed that, and sweeps a smaller volume as well. The reasoning sits in the code next to the constant, because the next person to “simplify” that pose would otherwise put the bug straight back.

What does not work yet

The carriage traverses the straight section of the oval. It cannot go around the curved ends.

That is a scoping decision. URDF has no joint type for “position is arc length along a closed curve”; every joint it offers is linear in its variable along a fixed axis. Doing it properly means a custom MoveIt kinematics plugin that owns the ellipse math: arc-length parameterisation through an elliptic integral, carriage yaw along the tangent, and a hand-derived Jacobian column for the rail. I specced it fully, estimated 5–12 weeks, and stopped there. The payoff is almost entirely visual, and it would only transfer to a real cell if the procured rail were itself a closed loop with a vendor controller using the same parameterisation.

So the loop is presentational for now: the silhouette shows how a rail would wrap a tool, while the motion is what a straight rail does. The spec for the harder version is written down and waiting for a reason to build it.

Perception, the inspection-tool mockup, and the agent driving motion end to end come after this, and none of them are built.