Runtime · v0.1.2

FlowEdge

You train the policy in PyTorch. FlowEdge runs it on the robot’s clock.

A C++ runtime for flow-matching and LeRobot Diffusion Policy. Convert the checkpoint once, load it into a fixed arena, and every control tick you get an action — or a defined miss: hold, drop, or raise. Not a trainer. Not a safety controller. Cameras and e-stop stay in LeRobot.

How to use it Docs GitHub

FlowEdge penguin — surfing the control loop

How the system fits together

Sensors and the RGB encoder stay outside. Core only samples the policy head, then either ships an action chunk or applies the miss policy.

How to use it

1

Install

Grab a v0.1.2 CPU wheel from the GitHub release (not on PyPI yet), or build the C++ tree. CUDA is a source build with nvcc — those wheels are CPU-only.

python -m pip install flowedge-0.1.2-*.whl

2

Convert the checkpoint once

Map a pinned Hugging Face / LeRobot checkpoint into layouts the engine already knows (backbone.*, flow.*, dp.*). After that, Core never talks to the training graph.

Converter in the docs

3

Sample

Run one trajectory against the converted file. Python and the CLI call the same engine.

python examples/core/flow_sample.py models/mamba_flow.safetensors euler 10
# or
./build/flow_sample models/mamba_flow.safetensors euler 10

4

Put it on the robot clock

Each tick: observation in, action out. If this sample is late, say what the motors get. Limits and e-stop are still yours / LeRobot’s.

--period-ms 10 --on-miss hold   # or drop | raise

Performance

Matched Diffusion Policy PushT replay vs LeRobot / PyTorch on the same observation file. Same load → warmup (malloc 0) → DDIM. First bar to 100% in each pair is faster. Not a 10 ms loop — that is the robot’s tick, not this checkpoint’s p50.

CUDA · GTX 1650

FlowEdge

131 ms

PyTorch

345 ms

0.38× the PyTorch CUDA p50. Encoder still in LeRobot. Not TensorRT, not Jetson.

CPU · threads=1

FlowEdge

851 ms

PyTorch

1409 ms

0.60× the LeRobot / PyTorch p50. The fair compare. At 4 threads: 633 vs 819 ms.

How it compares to other tools

From the README: PyTorch, LeRobot, TensorRT, and generic model servers are good at training or at running arbitrary graphs. They are a weak fit as the thing inside the robot loop.

PyTorch / LeRobot

They train. FlowEdge runs the tick.

Cameras, normalization, joint limits, and e-stop stay in LeRobot. The published numbers are a matched Diffusion Policy replay against that stack on the same file — not a generated-token speedup.

TensorRT / ONNX

Graph compilers. FlowEdge is not one.

Each head is hand-assembled into a sized arena. There is no graph interpreter (ADR 0005). The 131 vs 345 ms CUDA figure is vs PyTorch CUDA on a GTX 1650, not TensorRT or Jetson/ARM.

Model servers

Throughput and a growing KV cache.

A 100 Hz loop wants malloc 0 after load and a defined miss: hold, drop, or raise. A p50 is not a miss count. Optional Relay is local IPC around Core, not the default DP path.

Python-in-the-loop DDIM

More NFE than a short flow ODE.

Diffusion Policy is first-class when that is the trained checkpoint. Flow matching is the default head — Euler / Heun / RK4, gated by ULP vs the same PyTorch reference (~1e-6 rel). No published flow p50 yet.

Evidence and how to regenerate: performance docs.