Assembly
Screwing, seating, latching and insertion, where inspecting the finished part tells you least about whether it is right.
Language-driven manipulation for work that cannot be allowed to fail quietly. You describe the task, and the platform plans it, carries it out, and works out how to prove that each step actually happened.
Live in your browserRun the simulator
The physics, the sensors and every verification test run live in your browser. Type an instruction or pick an example, and watch PollenX plan it while the ledger fills in as each test is stated and then measured.
Traditional cells are reliable because they are rigid. One part, one program, one fixture, re-engineered by an integrator whenever anything changes. The moment task variety rises that model collapses, and the flexible alternatives on the market cannot tell you whether what they just did actually worked.
A camera can be fooled by an arm in the way. A load cell cannot be talked into believing a grasp that never happened.
Five capabilities, delivered as one system. Each is replaceable without disturbing the others, which is what lets the platform move between robots and between processes without a rewrite.
| Natural-language tasking | State the objective in plain English. The platform composes it from a governed vocabulary of verified operations and validates the result before anything moves. An invalid plan is rejected and rewritten, and never attempted. |
| Sensed execution | No motion ends at a computed depth and hopes for the best. A contact move terminates on measured force, and a grasp closes until the jaws report stall, so the robot reacts to the workspace it actually finds. |
| Designed verification | The system determines what evidence would settle each claim and goes and measures it: mass transfer for a grasp, reaction force for a seal, geometry for a placement. The prediction is recorded alongside the result. |
| Recovery and re-planning | A failed check tells the platform something useful. It restores the preconditions and retries, and where a retry cannot succeed it re-plans against the measured reality and carries on, escalating to a person only when that is the right answer. |
| Hardware portability | A robot is described by a single capability manifest covering kinematics, actuators, sensors, reach and what it can prove. Adding an arm is a configuration exercise. |
The clearest illustration of why verification has to be reasoned about on every action, instead of configured once and forgotten.
The robot drives the cap down and torque rises. Torque alone settles nothing. A cross-threaded cap resists. So does one jammed at an angle. All three produce a confident-looking number, and a torque threshold accepts every one of them.
So the platform specifies a test for this action. Lift the cap gently and measure the reaction force. A properly seated cap brings the bottle with it. One that is merely wedged lets go.
Where the camera cannot resolve the thread line well enough to judge, the robot repositions to a better vantage point and looks again before committing to an answer.
The test, its predicted result and the measurement are recorded together. Saying the bottle is sealed stops being an assertion and becomes a result with an experiment behind it.
Every run produces a ledger. Each line names the test specified for that action, the result predicted before the robot moved, and the quantity actually measured.
Tier A is a direct physical measurement, such as a load cell or a force sensor. Tier B is inferred from the robot’s own actuators. Tier C is the model’s judgement. Every line declares which grade of evidence produced it, and a run that can only achieve a weaker grade says so plainly.
The economics work wherever task variety is high enough that reprogramming cost dominates, and where the consequence of an unnoticed failure gets carried downstream.
Screwing, seating, latching and insertion, where inspecting the finished part tells you least about whether it is right.
Sample handling and preparation, where gravimetry is already accepted practice and an audit trail is a standing requirement.
Where the measurement is the deliverable, and the provenance of that measurement is what makes it worth anything.
High mix, low volume and changing constantly, which is the exact profile that defeats a fixed-program cell.
Where every step must be attributable, and a robot reporting its own success will not satisfy anyone.
If a step in it has to be shown to have worked before the next one starts, it belongs on this list.
Bring us the operation that keeps you awake, the one where a quiet failure travels downstream before anyone notices.