//Follow one shirt

Laundry folding robot

A folding cell in a commercial laundry. Two small arms on a table take garments from a bin, lay them flat, and fold them. Cameras above and beside the table watch the cloth, and a policy learned from demonstrations decides where to grasp and how to fold.

Step 01 of 08, on the machine

See

The overhead camera takes a colour image and a depth image of the bin. The shirt this cycle follows is on top of the pile, tangled with the garments under it. The policy, running on the computer in the cabinet, reads both images.

What it costs

A new colour frame every 25 ms, because the listed colour camera runs at 40 frames a second.

Derived from the Basler ace acA1920-40gc catalogue row

Why it is hard, and what is at work

Cloth has no fixed shape, so there is no pose to plan to. Where this shirt ends and the next garment begins is often not visible at all.

Parts working at this step

Overhead depth and colour camera
A camera on the frame above the table looks down on the bin and the table, and gives the policy a colour image and a depth image of the cloth.
Compute cabinet
A cabinet outside the guarding holds the computer that runs the policy on the camera images, the controllers for the servo bus, and a network switch to the laundry's wired network.

Step 02 of 08, on the machine

Grasp

The policy picks a point on the shirt, an edge it can pinch, and the left arm reaches into the bin. The soft fingertips close on the cloth, and the arm lifts the shirt clear of the pile.

What it costs

About 1 to 3 s for a grasp, and a missed or doubled grasp costs another try.

Estimate

Why it is hard, and what is at work

The fingers have to take one layer and not two. A pinch that catches the garment underneath lifts both, and a pinch through two layers of the same shirt folds it into itself later. The policy learned where to grasp from demonstrations, so it grasps only as well as they covered this kind of pile.

Parts working at this step

Two small arms
An arm at each end of the table. One arm picks a garment from the bin; together they shake it out, lay it flat, and fold it. Each joint is a servo with its own motor, gearbox, and position sensor, on a shared serial bus.
Soft grippers
A gripper on each arm pinches cloth between two thin, soft fingertips that slide under an edge lying on the table or on the pile.

Step 03 of 08, on the machine

Fold

The arms shake the shirt out and lay it flat on the table. Each gripper pinches one corner of the hem, and the two arms lift the hem together and carry it over to the collar, folding the shirt in half.

What it costs

At least half a second for a 90-degree turn of one joint: the listed servo turns at 30 rpm with no load at 12 V, half a turn a second, and slower under load.

Derived from the ROBOTIS Dynamixel XM540-W270-T catalogue row

Why it is hard, and what is at work

The arms hold the same cloth, so neither can move alone: one arm moving early drags the shirt across the table. The cloth slides and settles differently every time, so the policy corrects from the camera images as it goes instead of replaying a fixed path.

Parts working at this step

Two small arms
An arm at each end of the table. One arm picks a garment from the bin; together they shake it out, lay it flat, and fold it. Each joint is a servo with its own motor, gearbox, and position sensor, on a shared serial bus.
Soft grippers
A gripper on each arm pinches cloth between two thin, soft fingertips that slide under an edge lying on the table or on the pile.

Step 04 of 08, on the machine

Check

The side camera looks at the folded shirt edge-on, and the overhead camera from above. A model on the computer decides whether the fold is good. If it is, an arm puts the shirt on the stack; if not, the cell opens it out and tries again.

What it costs

The listed compute module draws between 15 and 60 W, set by its power mode, and the policy and the check share it.

Derived from the NVIDIA Jetson AGX Orin 64GB catalogue row

Why it is hard, and what is at work

Checking a fold is a vision problem of its own, with its own model and its own mistakes. Failures are common: a sleeve left out, a corner folded under, two garments folded as one. Each failure is also the most useful record the cell makes.

Parts working at this step

Side camera
A second camera on a drop bar at the front looks across the table at a low angle, so it sees the folded shirt edge-on: its height, its edges, and anything left hanging out.
Compute cabinet
A cabinet outside the guarding holds the computer that runs the policy on the camera images, the controllers for the servo bus, and a network switch to the laundry's wired network.

Step 05 of 08, across the fleet

Log

The cell's own software records each fold as an episode: the camera frames, the joint positions the policy asked for, and whether the check passed, and keeps it on the cell's disk. Device to Cloud Flywheel can also record camera video as short compressed segments; each one waits on the cell's disk until its upload succeeds. Across 1,000 cells, failed folds pile up by the thousand every day.

What it costs

About 92 MB a second of raw video from each camera: 1,920 by 1,200 pixels at one byte each before colour processing, 40 times a second. The joint positions are small beside it.

Derived from the Basler ace acA1920-40gc catalogue row

Device to Cloud Flywheel solution: Training a policy and shipping it to the fleet

The fleet view shows 1,000 cells to show the problem at that size; Device to Cloud Flywheel has been run on fleets of single digits to low tens of devices.

Why it is hard, and what is at work

Every failure is training data, but only when it is kept together with what the policy saw and did. An episode missing its frames, or tagged with the wrong policy version, teaches the next policy the wrong thing.

Parts working at this step

Compute cabinet
A cabinet outside the guarding holds the computer that runs the policy on the camera images, the controllers for the servo bus, and a network switch to the laundry's wired network.

Where Device to Cloud Flywheel fits: Training a policy and shipping it to the fleet

Field data coming back from machines, and a model you want to improve and redeploy without a bespoke pipeline each time. It runs across the other solutions rather than describing one kind of device.

Demo

embodiments/train/demo.sh

Needs a running stack, uv.

The demo trains a small policy for a simulated excavator. It does not train a folding policy. The loop is the same: files back, a training job you start, a checked file out to the machine.

The repository is private while the first release lands, so this demo cannot be run from this page. Write to hello@devicetocloud.ai and we will tell you when it opens.

From the solution page, wording adjusted.

Step 06 of 08, across the fleet

Return

When the cell is online, you ask it for its episodes. Your code on the cell packs the chosen ones into a file; the agent uploads it and hands back a reference with a checksum, so what reaches the server is the file itself instead of a path on the cell's disk. Video segments that Device to Cloud Flywheel records wait on the cell's disk and upload when the link comes back.

What it costs

At most 100 Mbit/s, about 12 MB a second, on each port of the listed network switch: about a seventh of what one camera records raw. The laundry's own internet connection is usually slower still.

Derived from the Moxa EDS-205 catalogue row

Device to Cloud Flywheel solution: Training a policy and shipping it to the fleet

The fleet view shows 1,000 cells to show the problem at that size; Device to Cloud Flywheel has been run on fleets of single digits to low tens of devices.

Why it is hard, and what is at work

Two cameras recording raw make far more data than a laundry's connection carries, so the cell has to choose: every failure, and a sample of the successes. With 1,000 cells in 100 laundries, some are offline at any hour, and the server has to tell a quiet cell that is fine from one that has stopped.

Parts working at this step

Compute cabinet
A cabinet outside the guarding holds the computer that runs the policy on the camera images, the controllers for the servo bus, and a network switch to the laundry's wired network.

Where Device to Cloud Flywheel fits: Training a policy and shipping it to the fleet

Field data coming back from machines, and a model you want to improve and redeploy without a bespoke pipeline each time. It runs across the other solutions rather than describing one kind of device.

Demo

embodiments/train/demo.sh

Needs a running stack, uv.

The demo trains a small policy for a simulated excavator. It does not train a folding policy. The loop is the same: files back, a training job you start, a checked file out to the machine.

The repository is private while the first release lands, so this demo cannot be run from this page. Write to hello@devicetocloud.ai and we will tell you when it opens.

From the solution page, wording adjusted.

Step 07 of 08, across the fleet

Learn

This shirt's episode is one of thousands. People pick the episodes worth training on, often add fresh demonstrations, and send the set to a trainer. Device to Cloud Flywheel moves the files by checksum and hands each training job to the trainer, a machine you enroll like a cell, when you start it. It doesn't choose the episodes and it doesn't start training on its own.

What it costs

About 20,000 episodes a day to sort, if each of 1,000 cells logs 20 failed folds.

Estimate

Device to Cloud Flywheel solution: Training a policy and shipping it to the fleet

A second product, Device to Cloud Engineer, is an engineer agent that writes the device code a machine like this runs. It is in development, and there is nothing to try yet.

The fleet view shows 1,000 cells to show the problem at that size; Device to Cloud Flywheel has been run on fleets of single digits to low tens of devices.

Why it is hard, and what is at work

Demonstrations are expensive: a person folds shirts through the arms, one at a time. Failures are common, but the ones worth training on are rare in kind: a new garment, a new fabric, a customer with their own folding rule. At 1,000 cells the work is finding them, and knowing which cell, laundry, and policy version each came from.

Where Device to Cloud Flywheel fits: Training a policy and shipping it to the fleet

Field data coming back from machines, and a model you want to improve and redeploy without a bespoke pipeline each time. It runs across the other solutions rather than describing one kind of device.

Demo

embodiments/train/demo.sh

Needs a running stack, uv.

The demo trains a small policy for a simulated excavator. It does not train a folding policy. The loop is the same: files back, a training job you start, a checked file out to the machine.

The repository is private while the first release lands, so this demo cannot be run from this page. Write to hello@devicetocloud.ai and we will tell you when it opens.

From the solution page, wording adjusted.

Step 08 of 08, across the fleet

Ship

The new policy goes out as a checkpoint file, declared as what each cell should run. Each cell pulls it, checks it against its checksum, loads it, and reports which checkpoint it loaded. At 1,000 cells, a team gives a new policy to a few laundries first, compares their fold success and rework with the rest, and then widens the rollout or pauses it and rolls back. On this cell, the next garment from the bin is folded by the new policy.

What it costs

About 200 GB of downloads for one release, if the checkpoint is about 200 MB and goes to 1,000 cells.

Estimate

Device to Cloud Flywheel solution: A robot arm running a learned policy

The fleet view shows 1,000 cells to show the problem at that size; Device to Cloud Flywheel has been run on fleets of single digits to low tens of devices.

Why it is hard, and what is at work

A policy that folds better on average can be worse on one laundry's uniforms. The rollout has to pause on a regression, go back cleanly, and show which cells run which checkpoint, including the ones that were off when it started. Deciding what counts as a regression is the team's call: fold success comes from the cell's own check, which Device to Cloud Flywheel does not measure.

Parts working at this step

Compute cabinet
A cabinet outside the guarding holds the computer that runs the policy on the camera images, the controllers for the servo bus, and a network switch to the laundry's wired network.
Two small arms
An arm at each end of the table. One arm picks a garment from the bin; together they shake it out, lay it flat, and fold it. Each joint is a servo with its own motor, gearbox, and position sensor, on a shared serial bus.

Where Device to Cloud Flywheel fits: A robot arm running a learned policy

An arm, a LeRobot SO-101 or similar, and a policy you retrain as you collect more demonstrations.

Demo

embodiments/lerobot/demo.sh

Needs a running stack, uv, jq, curl, go. Drives a simulated SO-101 in MuJoCo, with no physical arm.

The demo drives one simulated SO-101 arm in MuJoCo, reaching for a target. It does not fold cloth, and it drives one arm where a folding cell has two. On a real machine the plugin loads the checkpoint and your own control loop commands the joints. Its path for a physical arm refuses to run and names the servo-bus driver it needs.

The repository is private while the first release lands, so this demo cannot be run from this page. Write to hello@devicetocloud.ai and we will tell you when it opens.

From the solution page, punctuation adjusted.

And back

Back to 01 See, with the new model

The next garment from the bin goes through the same steps. This time the new policy chooses the grasp and the fold, and what the cell records about it feeds the policy after that.

On the machine

Across the fleet

And back

//Every part in the cycle

Each subsystem has its own way to fail.

The catalogue examples are representative parts taken from vendor datasheets and product pages, each linked to its source. They show the kind of component each subsystem uses and the numbers that matter for it. They are not a bill of materials, and nobody has checked that they work together.

Part	What it does	Why it is hard	Catalogue examples
Table and strut frame	What it does. A work table and an aluminium strut frame carry the cell: the arms on the table, the cameras on the frame above and in front of it, and the guarding round the outside.	Why it is hard. The cameras and the arms have to agree on where the table is to within a few millimetres. A frame that flexes when an arm swings, or that a cart knocks on a busy laundry floor, moves every camera against the arms, and the grasps land beside the cloth.	Catalogue examples Bosch Rexroth 45x45L strut profile profile width 45 mm · slot width 10 mm · mass per metre 1.6 kg
Two small armsWorking at 02 grasp, 03 fold, 08 ship	What it does. An arm at each end of the table. One arm picks a garment from the bin; together they shake it out, lay it flat, and fold it. Each joint is a servo with its own motor, gearbox, and position sensor, on a shared serial bus.	Why it is hard. Cloth has no fixed shape, so there is no pose to plan to: a learned policy sends new joint targets many times a second. Small servos heat up and wear under a full shift of that. Two arms holding the same shirt pull on each other through the cloth, so they have to move as one.	Catalogue examples ROBOTIS Dynamixel XM540-W270-T input voltage 12 V · stall torque 10.6 Nm · stall current 4.4 A ams-OSRAM AS5048A resolution 14 bit · resolution 0.0219 ° · fov 360 ° The servo and the magnetic angle sensor are examples of what small arms are built from. The SO-101 arm in the robot arm solution below uses a smaller hobby servo; a production cell may use a light industrial arm instead.
Soft grippersWorking at 02 grasp, 03 fold	What it does. A gripper on each arm pinches cloth between two thin, soft fingertips that slide under an edge lying on the table or on the pile.	Why it is hard. Taking one layer and not two is the whole problem. A pinch that also catches the layer underneath folds the shirt into itself, and neither the fingers nor the cameras can always tell until the fold goes wrong. A wrist force sensor feels a second garment come up with the first, but not a second layer of the same shirt.	Catalogue examples Robotiq 2F-85 adaptive gripper stroke 85 mm · grip force 20 to 235 N · payload 5 kg OnRobot RG6 two-finger gripper payload force fit 6 kg · payload form fit 10 kg · stroke 160 mm Robotiq FT 300 force torque sensor force range 300 N · torque range 30 Nm · noise force 0.1 N The two grippers listed are rigid two-finger grippers for industrial arms, shown only as examples of an electric parallel gripper. They are too heavy for the arms drawn here: the RG6 alone weighs 1.25 kg, and at 0.7 m reach that puts about 8.6 Nm on the shoulder, four times the listed servo's continuous torque. Cloth grippers use small, thin, compliant fingertips, and the catalogue has no such row. The force sensor is an example of what can sit at the wrist.
Overhead depth and colour cameraWorking at 01 see	What it does. A camera on the frame above the table looks down on the bin and the table, and gives the policy a colour image and a depth image of the cloth.	Why it is hard. Folds, wrinkles, and layers of the same fabric look alike from above, and white cotton on a pale table almost disappears. Depth finds a raised edge, but one layer of cotton is a millimetre thick or less, far finer than a depth camera resolves from more than a metre up.	Catalogue examples Basler ace acA1920-40gc resolution 1,920 × 1,200 · frame rate 40 Hz · sensor size 1/1.2 in The colour camera listed is an example of a machine-vision camera. The catalogue has no depth camera row.
Side cameraWorking at 04 check	What it does. A second camera on a drop bar at the front looks across the table at a low angle, so it sees the folded shirt edge-on: its height, its edges, and anything left hanging out.	Why it is hard. Checking a fold is a vision problem of its own. A sleeve tucked under looks right from above, and a fold a centimetre off square passes for one customer and fails for another. The check needs its own labelled examples, and they change when the laundry takes on a new customer.	Catalogue examples Basler ace acA1920-40gc resolution 1,920 × 1,200 · frame rate 40 Hz · sensor size 1/1.2 in
Compute cabinetWorking at 01 see, 04 check, 05 log, 06 return, 08 ship	What it does. A cabinet outside the guarding holds the computer that runs the policy on the camera images, the controllers for the servo bus, and a network switch to the laundry's wired network.	Why it is hard. The policy has to answer many times a second for as long as the arms move, or an arm stops mid-fold holding the cloth. The cell also records every fold for training, and the recording can't take time away from the policy.	Catalogue examples NVIDIA Jetson AGX Orin 64GB AI throughput 275 trillion operations/s · memory 64 GB · memory bandwidth 204.8 GB/s OnLogic Karbon 700-SE length 242 mm · width 240 mm · height 82 mm Moxa EDS-205 ports 5 · data rate max 100 Mbit/s · operating temp −10 to 60 °C The two computers are examples: an embedded module that can run a policy on a GPU, and a fanless industrial computer. The switch listed carries only the uplink to the laundry: at 100 Mbit/s and without Power over Ethernet, it cannot carry the two gigabit cameras, which need their own gigabit ports.
Bin in and stack out	What it does. Clean garments arrive tangled in a wheeled bin at one end of the table. Folded ones leave on a stack at the other end, where a person carries them away.	Why it is hard. Garments arrive tangled, inside out, and in a different mix every load. The stack has to stay square as it grows, or the next shirt slides off, and a fallen shirt means a person stepping into the cell.	Catalogue examples Colson Performa 8 inch swivel caster, 4080SA1PFP wheel diameter 8 in · wheel width 2 in · load capacity 272 kg The caster listed is an example of what a laundry cart rolls on.
Light curtain and guarding	What it does. Fence panels close the back and sides of the cell. A light curtain across the open front stops the arms when a person reaches in to change the bin or clear a jam.	Why it is hard. People work beside the cell all shift. The arms are small, but a fast arm with a pinching gripper still hurts, so a broken beam has to cut the servo power in hardware, and the cell has to resume cleanly with a half-folded shirt still on the table.	Catalogue examples The catalogue has no safety-rated part. A real cell uses a certified light curtain wired to a safety relay that cuts the servo power.

The drawing is illustrative, not a validated design. Costs marked estimate are estimates; the others are worked out from the catalogue part named under them.

//Where to start

The fleet half of this machine, as Device to Cloud Flywheel solutions.

Training a policy and shipping it to the fleet
Field data coming back from machines, and a model you want to improve and redeploy without a bespoke pipeline each time. It runs across the other solutions rather than describing one kind of device.
docs/solutions/train-and-deploy.md (opens when the code is published)
In the cycle at 05 log, 06 return, 07 learn. Quoted from the solution page, wording adjusted.
A robot arm running a learned policy
An arm, a LeRobot SO-101 or similar, and a policy you retrain as you collect more demonstrations.
docs/solutions/robot-arm.md (opens when the code is published)
In the cycle at 08 ship. Quoted from the solution page, punctuation adjusted.

Neither of the two solution pages has a section that separates measured results from claims, so nothing on this page is quoted as measured.

These pages live in the Device to Cloud Flywheel repository, which is private while the first release lands. Write to hello@devicetocloud.ai for access, and we will tell you when it opens.

//Where we help

Building one? Device to Cloud Flywheel is the software for the fleet half of this loop, from the first cell on.

Log, Return, Learn, and Ship: the steps after the machine works. The flywheel moves the data and the releases for every machine you have; what to train on and when to ship stay your team's call.

Request early access See the flywheel