//Follow one tote

Warehouse AMR

A low robot that carries totes around a warehouse. It works out where it is against a map, plans a path down the aisles, drives there on two wheels, slows and stops for a person in its way, and rolls the tote onto a conveyor at the station. Its navigation software already runs on ROS 2.

Step 01 of 09, on the machine

Localise

The robot works out where it is. Between laser scans, the wheel encoders and the IMU say how far it has moved and turned. With each scan, the localisation program on the computer matches the rack uprights and walls it sees against the warehouse map and corrects that estimate.

What it costs

One count of the listed 14-bit encoder is about 0.04 mm of travel, if it reads a 200 mm wheel directly: 628 mm round, in 16,384 counts. The counting is precise; the drift comes from the wheel slipping and wearing, which the encoder cannot see.

Derived from the ams-OSRAM AS5048A catalogue row

Why it is hard, and what is at work

Every bay of a long aisle looks the same to a flat laser: uprights at the same spacing, on and on. The scans fix which way the robot faces and how far it is from the racks, but one bay looks like the next, so along the aisle the estimate rests on the wheels and its error grows until the robot reaches the aisle end. When stock changes the shelves, the scans stop matching the map it was built from.

Parts working at this step

Safety laser scanners, front and rear
A 2D laser scanner at each end sweeps a flat plane a little above the floor, many times a second. The same scans do two jobs: the navigation software matches them to its map, and the scanners check their own configured safety fields for anything inside them.
IMU and wheel encoders
An encoder on each drive unit counts how far its wheel turns. An inertial measurement unit (IMU) measures how fast the robot turns. Together they give the navigation software a smooth estimate of how the robot has moved between laser scans.
Onboard computer running ROS 2
A fanless industrial computer runs the customer's ROS 2 stack: the drivers for the scanners, camera, and wheels, localisation against the warehouse map, the path planner, and the controller that follows the path. It also runs the fleet software that gives it jobs.

Step 02 of 09, on the machine

Plan

The fleet software sends the robot its job over Wi-Fi: take this tote to the conveyor. The path planner on the computer finds a route through the map from where the robot is to the conveyor, down this aisle and past its end, keeping clear of the racks by a set margin.

What it costs

About 8 million cells in the map the planner searches, if the floor is 200 by 100 m and the map records it in 5 cm squares.

Estimate

Why it is hard, and what is at work

The planner works on the map it has. A pallet left in an aisle, or a map that is out of date, sends the robot into a blocked aisle to find a way round. Many robots planning in the same aisles have to be kept from meeting head on, which is the fleet software's job, beyond what one robot can see.

Parts working at this step

Onboard computer running ROS 2
A fanless industrial computer runs the customer's ROS 2 stack: the drivers for the scanners, camera, and wheels, localisation against the warehouse map, the path planner, and the controller that follows the path. It also runs the fleet software that gives it jobs.
Wi-Fi client
A Wi-Fi client with two antennas on the deck links the robot to the fleet software that gives it jobs, and to the servers that collect its reports and send it changes.

Step 03 of 09, on the machine

Drive

Many times a second, the controller on the computer compares where the robot is with the planned path and sets a speed for each wheel. The drive units turn the wheels, and the encoders count what they did.

What it costs

About 1.1 m/s at the listed drive's rated 107 rpm on its 200 mm wheel, which travels 0.63 m a turn, and about 1.5 m/s at its 143 rpm maximum.

Derived from the Nidec 200 mm AGV wheel drive unit catalogue row

Why it is hard, and what is at work

The robot has to follow the path closely in an aisle with centimetres to spare either side, and carry a tote that slides if it brakes or turns too sharply. Its speed limit is set by what it can stop from within its safety field. A heavier load or a worn wheel changes how it answers the same command.

Parts working at this step

Differential drive units
Two drive units, one each side, each a brushless motor, gearbox, brake, and wheel in one assembly. The robot steers by turning its two wheels at different speeds, and turns on the spot by turning them in opposite directions.
Onboard computer running ROS 2
A fanless industrial computer runs the customer's ROS 2 stack: the drivers for the scanners, camera, and wheels, localisation against the warehouse map, the path planner, and the controller that follows the path. It also runs the fleet software that gives it jobs.
Battery and charging contacts
A pack of lithium iron phosphate cells powers the drives and everything else. Two contacts low on the rear wall meet the plates of a charging dock when the robot backs onto it, so it charges between jobs without a person plugging it in.

Step 04 of 09, on the machine

Avoid

At the aisle end, a person steps out from behind the racking. They are inside the front scanner's warning field, so the navigation software slows the robot and the safety controller holds it under a lower speed limit. If they come inside the protective field, the safety controller brakes the robot to a stop and removes the drives' power. The navigation software sees the person too, and plans around them once they move.

What it costs

About 1 m to stop from 1.1 m/s: about 0.2 m while the scanner, the safety controller, and the brakes react, if that takes about 0.2 s, and about 0.8 m of braking at about 0.75 m/s². The protective field has to be longer than that.

Estimate

Why it is hard, and what is at work

The stop has to work even when the navigation software has frozen, so the scanner and the safety controller act on the drives by themselves. The fields have to grow with speed, because a faster robot needs further to stop, and shrink in narrow places, or the robot stops for every rack upright. A person who steps out from behind a rack end gives the robot the least warning.

Parts working at this step

Safety laser scanners, front and rear
A 2D laser scanner at each end sweeps a flat plane a little above the floor, many times a second. The same scans do two jobs: the navigation software matches them to its map, and the scanners check their own configured safety fields for anything inside them.
Safety controller, emergency stops, and status lights
A safety controller reads the scanners' field outputs, the emergency stop buttons, and each wheel's speed from its own encoder input. It picks the scanners' field set for the speed the robot is going and, when the protective field is entered or a button is pressed, brakes the drives to a stop and removes their power. Light strips at each end show whether the robot is moving, waiting, or stopped.
Differential drive units
Two drive units, one each side, each a brushless motor, gearbox, brake, and wheel in one assembly. The robot steers by turning its two wheels at different speeds, and turns on the spot by turning them in opposite directions.

Step 05 of 09, on the machine

Hand off

The robot stops in the box marked in front of the conveyor, lined up with its end. The rollers on its top turn, and the tote rolls off the robot onto the conveyor. The robot reports the job done and waits for the next.

What it costs

About 2 s to roll a 600 mm tote off, if the rollers carry it at about 0.3 m/s.

Estimate

Why it is hard, and what is at work

Lining up to within a few centimetres of a conveyor needs better than the map alone gives, so the robot finds the conveyor's end with its sensors on the last metre. If the conveyor is full or stopped, the tote has nowhere to go, and the robot has to tell that from a fault of its own.

Parts working at this step

Roller top and tote
A module on the deck with driven rollers carries a 600 by 400 mm tote at conveyor height and rolls it off onto a conveyor, or takes one on, without a person lifting it. Side guides keep the tote from sliding off while the robot moves.
Onboard computer running ROS 2
A fanless industrial computer runs the customer's ROS 2 stack: the drivers for the scanners, camera, and wheels, localisation against the warehouse map, the path planner, and the controller that follows the path. It also runs the fleet software that gives it jobs.

Step 06 of 09, across the fleet

Log

The robot's own ROS 2 stack records what happened around the slowdown: its scans, its path, and the moment the warning field was entered, on the robot's disk. Across 1,000 robots, those records pile up faster than a team can look at them. Device to Cloud Flywheel's device agent and its ROS 2 plugin join the stack's graph from outside it and leave its programs, launch files, and middleware as they are. On request, the plugin lists each topic it found when it started, with its rate and whether it has gone quiet, and returns up to the last 50 lines of its own record of the changes it made. They do not collect the stack's recordings.

What it costs

About 5 GB a shift for each robot, if it keeps a compressed recording of its scans and depth images at about 1.5 Mbit/s for 8 hours.

Estimate

Device to Cloud Flywheel solution: A ROS 2 robot

The fleet view shows 1,000 robots 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

What the robot records is only useful with the map, software version, and parameters it ran on at the time. Recording everything fills the disk; recording too little loses the moment that explains a near miss.

Parts working at this step

Onboard computer running ROS 2
A fanless industrial computer runs the customer's ROS 2 stack: the drivers for the scanners, camera, and wheels, localisation against the warehouse map, the path planner, and the controller that follows the path. It also runs the fleet software that gives it jobs.

Where Device to Cloud Flywheel fits: A ROS 2 robot

Robots already running ROS 2. You have a stack you are not going to replace, and you want fleet operations around it rather than instead of it.

Demo

embodiments/ros2-machine/demo.sh

Needs a running stack, Go, uv, jq, curl, Docker with the demo's ROS 2 image built, and ROS 2 with rclpy on the host.

The demo script in the repository starts a live ROS 2 graph in a container: turtlesim, a small ROS 2 simulator, and a talker node. The plugin joins that graph over DDS from the host, sets a parameter on the running turtlesim node, reads topic rates, and reports drift when the talker is stopped. Only its first step, a check of the plugin's contract, runs the ROS 2 mock. The solution catalogue still describes the demo as driving the mock; this page follows the script. No robot moves in it. The script also names a known defect: the plugin reads a fast topic's rate at about two thirds of its true value, so the demo checks only whether a topic is alive. To reach a real robot, start the agent on it with ROS2_BACKEND=real and ROS 2's own ROS_DOMAIN_ID set to the robot's domain. The catalogue names a DCF_ROS2_DOMAIN_ID setting, which the plugin does not read. The solution page also lists a count of errors from the diagnostics topic and the battery level. The plugin's live backend subscribes to neither, so this page does not claim them.

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. What the demo needs is read from its script.

Step 07 of 09, across the fleet

Return

Between jobs, the robot backs onto a charging dock. There, and whenever its Wi-Fi link holds, its device agent reports home. The agent dials out to the server, so the robot's network needs no inbound port. A topic that published and then went quiet shows on the server as drift for that robot; a robot with no quiet topic shows no drift.

What it costs

2.7 kWh in a pack of eight of the listed cells in series: 8 × 3.2 V × 105 Ah.

Derived from the EVE LF105 LiFePO4 cell catalogue row

Device to Cloud Flywheel solution: A ROS 2 robot

The fleet view shows 1,000 robots 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

With 1,000 robots on Wi-Fi, some are between access points at any moment. The server has to tell a robot that is quiet because it is fine from one that has stopped, and a report that arrives late from one that describes the robot now. At about 300 W on average, a pack like this lasts about 8 hours if the robot keeps about a tenth of its charge in reserve, so each robot spends part of every shift on a dock. The plugin watches the topics it found when it started and counts any that goes quiet for 3 seconds as stale. Velocity commands stop whenever the robot waits at the conveyor, so drift on a topic like that can mean the robot is waiting, with no program at fault. Start the agent after the navigation stack, or its topics go unwatched.

Parts working at this step

Battery and charging contacts
A pack of lithium iron phosphate cells powers the drives and everything else. Two contacts low on the rear wall meet the plates of a charging dock when the robot backs onto it, so it charges between jobs without a person plugging it in.
Wi-Fi client
A Wi-Fi client with two antennas on the deck links the robot to the fleet software that gives it jobs, and to the servers that collect its reports and send it changes.
Onboard computer running ROS 2
A fanless industrial computer runs the customer's ROS 2 stack: the drivers for the scanners, camera, and wheels, localisation against the warehouse map, the path planner, and the controller that follows the path. It also runs the fleet software that gives it jobs.

Where Device to Cloud Flywheel fits: A ROS 2 robot

Robots already running ROS 2. You have a stack you are not going to replace, and you want fleet operations around it rather than instead of it.

Demo

embodiments/ros2-machine/demo.sh

Needs a running stack, Go, uv, jq, curl, Docker with the demo's ROS 2 image built, and ROS 2 with rclpy on the host.

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. What the demo needs is read from its script.

Step 08 of 09, across the fleet

Learn

The team looks at where robots slowed or stopped. The same aisle end shows up shift after shift, in several warehouses. From the recordings they decide what to change: how far the planner keeps the robot from rack ends, so it swings wide and sees round the corner sooner, or a new map. In Device to Cloud Flywheel, a file comes back by checksum: the device agent can record a camera's video in short segments when it is started with capture on, and a recording your own code assembles comes back through an operation you add. Device to Cloud Flywheel chooses no recordings and schedules no training.

What it costs

About 30 GB of clips a day to review if each of 1,000 robots has three slowdowns worth a look and each clip is about 10 MB.

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 robots 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 change that helps at one aisle end can slow every robot elsewhere. The team has to know which map, parameters, and software each recording came from, or they compare runs that differ in more than the one thing they changed.

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, Go, uv, jq, and curl.

The demo collects data from a simulated excavator (a MuJoCo simulation), trains a policy on it, and ships it to a two-machine fleet. No warehouse robot is in it. The solution page says the same steps carry a configuration file as well as a model.

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. What the demo needs is read from its script.

Step 09 of 09, across the fleet

Ship

The new parameter goes out as desired state: a value declared for the robot's ROS 2 section, which the plugin sets on the running program with ROS 2's own parameter command. The ros2 command line still works. Declaring the value gives the team a spec version for each change, with who made it, and a version to roll back to. The plugin does not read the value back, so a change made by hand with the ros2 command line does not show as drift. A rollback sets a value again only if the earlier version declared it. A rollout sends it to one group first, here the 20 robots in one warehouse, then to the next group when someone advances it, with pause, resume, and rollback. The ROS 2 plugin has no map field: a new map is a file, and it travels the way a model does in the training solution, declared by checksum and loaded by the team's own code on the robot.

What it costs

A parameter change is a few hundred bytes for each robot, so well under 1 MB across 1,000 robots. A new map is about 8 MB for each robot if it holds 8 million cells at a byte each, so about 8 GB across 1,000.

Estimate

Device to Cloud Flywheel solution: A ROS 2 robot

The fleet view shows 1,000 robots 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 map or navigation change sent to 1,000 robots at once can stop a warehouse, or every warehouse. That is why it reaches one group first and runs there for a shift before it goes further. A rollout releases the next group only when the change is written into the desired state of every robot in the groups before it; whether each robot has taken it up shows in that robot's reconcile result. Whether the change made things worse, such as more stops, slower jobs, or missed handoffs, is the team's call from its own measures.

Parts working at this step

Onboard computer running ROS 2
A fanless industrial computer runs the customer's ROS 2 stack: the drivers for the scanners, camera, and wheels, localisation against the warehouse map, the path planner, and the controller that follows the path. It also runs the fleet software that gives it jobs.
Wi-Fi client
A Wi-Fi client with two antennas on the deck links the robot to the fleet software that gives it jobs, and to the servers that collect its reports and send it changes.

Where Device to Cloud Flywheel fits: A ROS 2 robot

Robots already running ROS 2. You have a stack you are not going to replace, and you want fleet operations around it rather than instead of it.

Demo

embodiments/ros2-machine/demo.sh

Needs a running stack, Go, uv, jq, curl, Docker with the demo's ROS 2 image built, and ROS 2 with rclpy on the host.

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. What the demo needs is read from its script.

And back

Back to 01 Localise, with the new parameters

The robot works out where it is for its next job and goes through the same steps, this time planning with the new parameters. The team's own records show whether it slows and stops less often at the aisle end.

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
Chassis and casters	What it does. A low steel body about 0.9 m long and 0.6 m wide holds the battery, the computers, and the drive units, and carries the roller top on its deck. Four swivel casters at the corners carry the weight the drive wheels do not.	Why it is hard. The two drive wheels have to stay pressed to the floor over bumps, joints, and dock plates while the casters carry the rest. A body this low clears little, so a lip in the floor or a dropped strap can stop it. The casters swing round when the robot turns, and a caster that sticks pulls it off its path.	Catalogue examples Colson Performa 8 inch swivel caster, 4080SA1PFP wheel diameter 8 in · wheel width 2 in · load capacity 272 kg The Colson caster listed is an 8 inch wheel that stands about 0.24 m tall and carries 272 kg. A robot this low uses a smaller caster of the same kind; the catalogue has only this one.
Differential drive unitsWorking at 03 drive, 04 avoid	What it does. Two drive units, one each side, each a brushless motor, gearbox, brake, and wheel in one assembly. The robot steers by turning its two wheels at different speeds, and turns on the spot by turning them in opposite directions.	Why it is hard. Every change of speed is a change of torque at the wheels, and a loaded robot that brakes hard slides its tote or skids its wheels. When a wheel slips, the robot has moved a different distance from the one its wheels counted. The brakes have to hold the robot on a slope when power is lost.	Catalogue examples Nidec Drive Technology Nidec 200 mm AGV wheel drive unit wheel diameter 200 mm · load capacity 800 kg · speed rated 107 rpm The Nidec unit is rated for 800 kg, more than a tote robot carries. It is listed because it is the catalogue's integrated wheel drive for automated vehicles, with the encoder and brake a unit like this carries.
Roller top and toteWorking at 05 hand off	What it does. A module on the deck with driven rollers carries a 600 by 400 mm tote at conveyor height and rolls it off onto a conveyor, or takes one on, without a person lifting it. Side guides keep the tote from sliding off while the robot moves.	Why it is hard. The robot has to stop within a few centimetres of the conveyor's end, lined up with it, or the tote catches on the edge. A full tote shifts when the robot brakes or turns, and the rollers must hold it still until the handoff starts.	Catalogue examples The catalogue has no roller conveyor module or tote row.
Safety laser scanners, front and rearWorking at 01 localise, 04 avoid	What it does. A 2D laser scanner at each end sweeps a flat plane a little above the floor, many times a second. The same scans do two jobs: the navigation software matches them to its map, and the scanners check their own configured safety fields for anything inside them.	Why it is hard. A laser at ankle height sees legs, pallets, and rack uprights. It misses a fork tip or a load hanging above its plane, and dark or shiny surfaces return little light. The safety fields have to be set for each speed and each turn the robot makes, and a field that is too long stops the robot for nothing all day.	Catalogue examples The catalogue has no safety-rated 2D laser scanner row. Its lidars, the Ouster OS1-64 and the Livox Mid-360, are 3D sensors that carry no safety rating.
Depth camera	What it does. A depth camera over the front scanner, tipped down, sees what the flat laser plane misses: a load hanging above it, a tote on the floor, a low obstacle. The navigation software adds what it sees to its map of obstacles around the robot.	Why it is hard. A depth camera sees a shorter distance than a laser, and bright light, dark floors, and shiny wrap confuse it. Its view is only useful when the software knows exactly where on the robot it is mounted and how it is tipped; a bumped bracket puts obstacles in the wrong place.	Catalogue examples The catalogue has no depth camera row. The Basler camera it lists is a colour machine-vision camera without depth.
IMU and wheel encodersWorking at 01 localise	What it does. An encoder on each drive unit counts how far its wheel turns. An inertial measurement unit (IMU) measures how fast the robot turns. Together they give the navigation software a smooth estimate of how the robot has moved between laser scans.	Why it is hard. This estimate drifts: a slipping wheel, a worn tyre, or a heavier load changes how far a turn of the wheel really moves the robot, and small errors in heading grow into large errors in position down a long aisle. The scans have to correct it, and in an aisle where every bay looks the same the scans have little to correct it with.	Catalogue examples ams-OSRAM AS5048A resolution 14 bit · resolution 0.0219 ° · fov 360 ° Bosch Sensortec BMI088 accel range max 24 g · gyro range max 2,000 °/s · supply voltage 2.4 to 3.6 V The AS5048A is a magnetic angle sensor of the kind used as a wheel encoder; the Nidec drive unit listed carries its own encoder. The BMI088 is an IMU built for drones and robots.
Onboard computer running ROS 2Working at 01 localise, 02 plan, 03 drive, 05 hand off, 06 log, 07 return, 09 ship	What it does. A fanless industrial computer runs the customer's ROS 2 stack: the drivers for the scanners, camera, and wheels, localisation against the warehouse map, the path planner, and the controller that follows the path. It also runs the fleet software that gives it jobs.	Why it is hard. The stack is many programs passing messages, and a program that stops publishing leaves the rest working on old data. It is the customer's software, tuned over months for this warehouse, and the team running the fleet is not going to replace it. Anything that manages the fleet has to work around it.	Catalogue examples OnLogic Karbon 700-SE length 242 mm · width 240 mm · height 82 mm The Karbon 700-SE takes 9 to 48 V directly, so it can run from the robot's battery without a separate supply.
Safety controller, emergency stops, and status lightsWorking at 04 avoid	What it does. A safety controller reads the scanners' field outputs, the emergency stop buttons, and each wheel's speed from its own encoder input. It picks the scanners' field set for the speed the robot is going and, when the protective field is entered or a button is pressed, brakes the drives to a stop and removes their power. Light strips at each end show whether the robot is moving, waiting, or stopped.	Why it is hard. The stop has to work whatever the navigation software is doing, even when it has crashed, so it runs on separate hardware wired to the scanners and the drives. That separation is what a safety assessment checks, and it means the ROS 2 stack can slow the robot but cannot switch the stop off.	Catalogue examples The catalogue has no safety controller, emergency stop, or light row.
Battery and charging contactsWorking at 03 drive, 07 return	What it does. A pack of lithium iron phosphate cells powers the drives and everything else. Two contacts low on the rear wall meet the plates of a charging dock when the robot backs onto it, so it charges between jobs without a person plugging it in.	Why it is hard. The robot has to go and charge before it runs low, which takes it out of service while jobs wait. Many short charges through the day suit these cells, but the fleet software has to spread them so that not every robot is on a dock at once. Contacts that wear or collect dust stop charging quietly.	Catalogue examples EVE Energy EVE LF105 LiFePO4 cell capacity 105 Ah · nominal voltage 3.2 V · charge voltage max 3.65 V The EVE LF105 is a 105 Ah lithium iron phosphate cell. A pack of eight in series gives about 25.6 V; many robots of this class carry a smaller pack.
Wi-Fi clientWorking at 02 plan, 07 return, 09 ship	What it does. A Wi-Fi client with two antennas on the deck links the robot to the fleet software that gives it jobs, and to the servers that collect its reports and send it changes.	Why it is hard. A robot moving down an aisle passes from one access point to the next many times an hour, and racking full of metal and stock blocks and reflects the signal. Each handover can drop the link for a moment, so the robot has to keep driving safely on the job it has, with no link at all.	Catalogue examples The catalogue's only Wi-Fi row is a 2.4 GHz module for small embedded devices, which its maker marks as not recommended for new designs, so none is listed.

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.

A ROS 2 robot
Robots already running ROS 2. You have a stack you are not going to replace, and you want fleet operations around it rather than instead of it.
docs/solutions/ros2-robot.md (opens when the code is published)
In the cycle at 06 log, 07 return, 09 ship.
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 08 learn. Quoted from the solution page, wording 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 robot 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