lerobot-jetson

KO | EN

gitlite — search

#graphql #chatbot #video #macos #docker #php #pytorch #openai #csharp #rust

(★ 9)

Docker image for running LeRobot on NVIDIA Jetson (Orin, JetPack 6.2)

File Explorer

ZIP Download

- - build.yml
.gitignore
Dockerfile
Dockerfile.fast
Dockerfile.multistage
LICENSE
README.md

# Use via CDN

jsDelivr

jsDelivr serves any public GitHub repository as a CDN with zero setup. Pick a version and a file to get a ready-to-paste link and snippet.

Version

File

Link

Example

# Project Badges

License Visit
Platform
JetPack

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

A Docker image for running [LeRobot](https://github.com/huggingface/lerobot) on NVIDIA Jetson boards.

The usual way to get an ML container on Jetson is [`jetson-containers`](https://github.com/dusty-nv/jetson-containers), but that project has been effectively unmaintained since its original maintainer stepped away in 2025 ([issue #1270](https://github.com/dusty-nv/jetson-containers/issues/1270)), and its `lerobot` package hasn't kept up — missing `torchcodec`, an extra that got renamed upstream, and a CLI script that doesn't exist anymore. Rather than wait for that to get fixed, this repo just ships a working image directly.

## Status

Both `Dockerfile` (builds torch/torchcodec/torchvision from source) and `Dockerfile.fast` (reuses artifacts already built bare-metal on this board) confirmed working end-to-end on a real Jetson Orin as of 2026-08-26: torch sees the GPU, torchvision's compiled ops load correctly, torchcodec decodes video on CUDA (a real `.cuda()` tensor comes out, not just a clean import), and `import lerobot` plus a policy import (SmolVLA) succeed.

That last part — `import lerobot` actually succeeding — took a second pass to get right: an earlier verification only checked torch/torchcodec imports, not lerobot itself. lerobot pulls in torchvision, and the generic PyPI wheel for it silently fails at runtime against a from-source torch build (`RuntimeError: operator torchvision::nms does not exist`) despite installing and importing cleanly — pip has no way to know it's the wrong build. Both Dockerfiles now build torchvision from source too, the same way they already did for torch/torchcodec.

**2026-08-31 — full from-scratch rebuild, `USE_DISTRIBUTED=1`/`USE_GLOO=1` and `USE_MEM_EFF_ATTENTION=1` confirmed working, not just staged.** Verified live in the built image: `torch.distributed.is_available()`/`is_gloo_available()` both `True`, `lerobot.distributed.utils.is_main_process()` no longer needs the sed-patched stub guard (still applied, now a harmless no-op), `torch.backends.cuda.mem_efficient_sdp_enabled()` is `True`. Total build time 5h 33m, of which PyTorch compilation alone is 92% (~5h 6m) — everything else (ffmpeg, torchcodec, torchvision, lerobot install) finishes in under 15 minutes combined.

Only Orin / JetPack 6.2 (L4T R36.4.x) / CUDA 12.6 has been tried. Other boards or JetPack versions: unknown, PRs welcome.

**2026-09-07 — image published to GHCR**: `ghcr.io/ravediamond/lerobot-jetson:public` / `:latest` (same image, both tags), built from the 2026-08-31 rebuild above. Pull instead of building from scratch unless you need to change something.

## Requirements

- A Jetson Orin on JetPack 6.2
- Docker with the NVIDIA container runtime set as default (this is standard on JetPack images)

## Usage

Pull the prebuilt image:

```bash
docker pull ghcr.io/ravediamond/lerobot-jetson:latest
docker run --runtime nvidia -it -e HF_TOKEN=<your-hf-token> ghcr.io/ravediamond/lerobot-jetson:latest
```

Or build it yourself:

```bash
git clone https://github.com/ravediamond/lerobot-jetson.git
cd lerobot-jetson
docker build -t lerobot-jetson .
docker run --runtime nvidia -it -e HF_TOKEN=<your-hf-token> lerobot-jetson
```

Budget a few hours for the first build. No prebuilt cp312 wheel for torch or torchcodec exists anywhere for this platform yet — checked both NVIDIA's own redist and the jetson-ai-lab community index, which only goes up to cp310 — so both get compiled from source. Once built, Docker's layer caching makes rebuilds fast unless you bump a version.

`HF_TOKEN` is optional but recommended: without it, every pull from the Hub (datasets, pretrained policies) hits the unauthenticated rate limit, which is fine for a one-off test but bites fast on repeated runs.

## What's different from jetson-containers' `lerobot` package

- `torchcodec` and `torchvision` are both built from source and installed explicitly. `torchcodec` is missing entirely from the upstream package; `torchvision` is present but as a generic PyPI wheel that's silently ABI-incompatible with a from-source torch build here.
- The `pi0` extra was renamed to `pi` upstream a while back; this Dockerfile uses the current name and adds `smolvla` too.
- PyTorch is built from source for cp312, with a handful of flags that turned out to matter a lot on this hardware — flash-attention and NVSHMEM are disabled, distributed (Gloo backend) and memory-efficient attention are enabled. More on why below.

## Where these build steps came from

Every non-obvious line in the `Dockerfile` — the disabled PyTorch features, the pinned ffnvcodec headers, dav1d built from source instead of using apt's too-old version, the extra `libopenblas0`/`libcusparselt0` runtime packages, the `ensurepip` step right after creating the venv — exists because something broke without it, on this actual hardware, not because it seemed like a good idea in the abstract. A few examples:

- `USE_NVSHMEM=0`: PyTorch's CMake auto-enables NVSHMEM (a multi-node feature, meaningless on a single-board device) whenever it spots the `nvidia-nvshmem` pip package, then fails to link it at the very end of an hours-long compile.
- `libcusparselt0`: torch needs it at runtime, but the base image doesn't have the NVIDIA CUDA apt repo configured at all, let alone the package — just installing the package isn't enough, the repo has to be added first.
- The venv from `uv venv` doesn't ship `pip`. Easy to miss, breaks the very next line.

None of this is written up in full yet — if something breaks and you want the reasoning behind a specific line, open an issue here.

## Building on Jetson

The image builds natively on the board itself — no cross-compilation, no QEMU. If you want to wire this repo up to GitHub Actions, point the workflow at a self-hosted runner registered on an actual Jetson. GitHub's hosted runners are x86_64, and emulating an aarch64 CUDA build on one of those would be painfully slow, if it worked at all.

## License

Apache 2.0, matching LeRobot.

lerobot-jetson

Owner Repos

File Explorer

# Use via CDN

# Project Badges

Was this content helpful?

Recent Feedback

lerobot-jetson

Owner Repos

File Explorer

# Use via CDN

# Project Badges

Was this content helpful?

Recent Feedback

Download README