Solutions · Industrial automation

Validate the cell before it is built

Rebuild a workstation or conveyor cell from photographs, drawings and CAD. Place the robot where it will stand, write the task in a sentence and run it in simulation, with every attempt recorded.

Start with the factory starter Talk to us

Every trial on the floor costs line time. Move the trial into software and keep the floor running.

A robot arm beside a conveyor carrying parts toward an inspection tray, with two camera frustums — Conveyor cellillustration

twins

Cells from photographs and drawings

Bring the photographs from the site visit, the PDF layout and any CAD you have as GLB, OBJ, STL or PLY. Atom rebuilds the cell as separate, editable geometry with recovered materials, places the robot where you say and lists every estimate it made about scale, mass and friction so you can correct them before a run.

Photographs, video, PDF and Word documents, drawings, tables and 3D assets.
Every fixture, part and tray is its own object. Move it, resize it, fix it in place.
Export the editable Blender scene and GLB into your own tools at any time.

factory · task specfrom a recorded configuration

source       factory
robot        franka-panda · Robotiq 2F85
conveyor     0.02 m/s
task         "Let the conveyor run for two simulated seconds, stop it,
              then inspect the parts. Describe what you see in your
              finish note. Do not pick anything up."
limits       20 s sim · 180 s wall · 3 decisions · 4096 tokens
grading      human review   # open-ended inspection

scenarios

Write the task, set the budget

Tasks are written in plain language. The factory starter ships with a moving conveyor whose speed is a parameter, loose parts and an inspection tray. Set the simulated and wall-clock budgets, the decision limit and the final settling time before the run starts. Lift tasks are graded by the simulator. Open-ended inspection tasks can be marked for human review.

Conveyor speed, budgets and layout are declared per run and shown with the result.
Rigid lift tasks are graded by height and fingertip-pad contact. Inspection tasks are graded by you.
Original and shifted layouts, so a run cannot rely on remembered positions.

evaluation.zipone archive per run

evaluation.zip
├─ manifest.json      robot, scene, budgets, source hashes
├─ metrics.json       success, termination reason, steps, seconds
├─ observations/      the exact images and state the policy received
├─ commands.jsonl     every command, its receipt and revision
├─ trajectory.npz     recorded state at 20 Hz
└─ replay.py          recorded-state replay helper

evidence

Every attempt, receipted

A run finishes by writing one archive: the frozen manifest, the exact images the policy received, every command with its receipt and revision, the trajectory at 20 Hz and the grade. The reason the run ended is recorded separately from whether it succeeded, and failed attempts stay in the history where your team can read them.

Command receipts carry identifiers and revisions, so a replay can show it ran the same actions.
Time exhausted, decisions exhausted, cancelled and infrastructure error are separate outcomes.
Environments and runs are private to the workspace owner.

Scene assumptionsshown on every custom scene

Scale and geometry inferred from references.
Loose props move by default. Authored assemblies and estimated object groups keep their parts together.
Mass and convex contact geometry are estimated unless authored.
Mass, friction and robot placement require calibration for hardware transfer.

limits

What we do not claim

A run in the twin is a single recorded trial. Mass, friction and robot placement are estimates until you calibrate them against the real cell, and the scene says so. We do not publish throughput figures or success rates, and we would rather you did not either. What you get is a place to find the problems that are cheap to find in software and expensive to find on the floor.