Skip to content
Early access openRev 0.1Robots in the lab 0001Local --:--:--
//Physical AI infrastructure

Software for teams building autonomous robots, from the first prototype to a working fleet.

Pick a robot. Scroll to follow it from a set of parts to one that works, then out to a fleet of thousands, and back again with a better model.

AlphaDevice to Cloud Flywheel: hosted by waitlist, or open source on your own machines.Get started
Follow
0 · What it takes

A laser weeder is 9 parts and 5 steps.

A young weed can look almost the same as the crop, and the machine has to find it and hit a growing point a few millimetres across while it keeps moving.

  • Gantry frame and wheel drives
  • Light-sealed hood
  • Laser modules
  • Weed cameras and lighting
  • Compute and uplink
  • Generator and power distribution
  • Chiller and radiator
  • Row guidance
  • Safety chain
0 → 1 · Building the first one

Every step is a part doing its job, and each one can fail on its own.

Follow one piece of work through the machine. Device to Cloud Flywheel connects the robot from its first field run: one command registers it, and its heartbeats, logs and recordings come home from then on.

01

Light

Inside the closed hood, LED bars light the bed the same way at noon and at dusk.

02

See

The downward camera beside one laser takes a frame of the bed.

03

Decide

The computer on the deck runs the weed model on the frame, marks the weed, and finds its growing point, the few millimetres where a shot kills the plant.

04

Aim

The computer predicts where the weed will be when it reaches the laser row and turns the steering mirror in one laser module to that spot.

05

Fire

With the hood interlock showing the hood closed, the laser fires and the mirror puts the beam on the growing point.

1 → 1000+ · Scaling a fleet

The robot works. Running thousands of them is the unknown.

Thousands of laser weeders record more than any team can watch. What they see in the field is also what makes the next model better, if it comes home.

06

Log

The machine records video of the bed in short segments, whether or not anyone is watching.

Device to Cloud Flywheel: Cameras and vision devices

07

Return

When the link allows, the machine uploads its recorded segments.

Device to Cloud Flywheel: A ROS 2 robot

08

Learn

The fleet's records, this weed among them, are the raw material for the next model.

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

09

Ship

The new model goes out as a declaration of what each machine should run.

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

shelldcfctl
$ dcfctl device list | head -7
ID             NAME       STATUS  DEVICE-TYPE  AGENT-VERSION
gh2-weeder-01  bed-row-a  active  weeder       v1.4.2
gh2-weeder-02  bed-row-b  active  weeder       v1.4.2
gh2-weeder-03  bed-row-c  active  weeder       v1.4.2
gh2-weeder-04  bed-row-d  active  weeder       v1.4.2
gh2-weeder-05  bed-row-e  active  weeder       v1.4.1
gh2-weeder-06  bed-row-f  active  weeder       v1.4.2

$ dcfctl device telemetry gh2-weeder-05 | jq '{gpu_percent, temp_c}'
{
  "gpu_percent": 71,
  "temp_c": 57
}

$ dcfctl device run gh2-weeder-05 'systemctl is-active weed-detector'
active

A made-up fleet of laser weeders, printed the way dcfctl prints it.

↺ · And back

Back to 01 light, with the new model.

That loop is the product. Device to Cloud Flywheel brings the recordings home, hands the ones your team picks to your trainer, and ships the new model out in stages with pause and rollback. What to train on and when to ship stay your team's call.

Get startedLearn how the laser weeder is built, part by part

//Device to Cloud Flywheel · Alpha

Run the flywheel for your robots, hosted or open source.

Device to Cloud Flywheel is in alpha. The hosted version runs the control plane for you, with access by waitlist. The open-source version runs the same control plane on machines you control.

Hosted

Alpha · waitlist

We run and update the control plane. Your robots run only the device agent.

  1. 01
    Join the waitlist. We onboard teams in small groups.
  2. 02
    We set up your control plane and send your sign-in.
  3. 03
    Enroll your first robot. dcfctl enroll robot-01 --emit shell prints the command to run on it.
  4. 04
    See it live: dcfctl device list

Join the hosted waitlist

Open source

Self-hosted

The same control plane on infrastructure you control. Nothing leaves your network unless you send it.

  1. 01
    Download dcfctl for your platform from the releases page (opens when the code is published).
  2. 02
    Bring the control plane up: dcfctl setup local --from release
  3. 03
    Enroll your first robot. dcfctl enroll robot-01 --emit shell prints the command to run on it.
  4. 04
    See it live: dcfctl device list
//What teams ask

What robotics teams ask when they get stuck.

How do I deploy, monitor, troubleshoot and update robots once they’re out there?
Eng lead, scaling fleet1 → 1000+
I’m a hardware guy who put together a robot. What next?
Founder, first robot0 → 1
Should I use Isaac Sim? I’m not sure real2sim2real works for us.
Robotics engineer0 → 1
We need to test small ideas, but with our team size everything gets done one at a time.
CTO, early-stage agtech0 → 1
I’d buy first, then fine-tune as we grow.
CTO, funded agtech1 → 1000+

Paraphrased from conversations with founders, CTOs and robotics communities.

//Early access

We’re onboarding a small group of teams in agtech, healthcare and industrial automation.