Running LeRobot on Jetson still means wrestling the entire AI stack

Getting LeRobot running on an NVIDIA Jetson Orin is less a pip install than a small expedition through Python versions, CUDA libraries and C++ ABI compatibility. A new Hugging Face Community Article lays out the author's route to a working container, including the traps that turned a supposedly routine setup into a 50-plus-hour build wall.

Hugging Face Watch analysis

What happened

The author says LeRobot's Python 3.12 requirement and its dependency on torchcodec 0.11.0 leave the described Jetson environment without a suitable pre-built CUDA-enabled PyTorch wheel. The remedy was to compile PyTorch 2.11 for the Orin's aarch64 platform, then build FFmpeg, torchcodec and torchvision locally around it.

The report describes a completed stack for JetPack 6.2 and CUDA 12.6, with a pre-built container published through GitHub Container Registry. Its headline lesson is wonderfully unglamorous: on edge robotics hardware, the model is only one piece of the product. The compiler, video decoder and ABI all get a vote.

Key findings

• The Python gap
  The article says available Jetson wheels target older Python versions, while LeRobot requires Python 3.12 or newer.
• The five-hour bottleneck
  In the author's build, compiling PyTorch took 5 hours 6 minutes, or 92% of the reported 5 hours 33 minutes.
• The silent NVSHMEM trap
  Leaving distributed support enabled can trigger an irrelevant NVSHMEM dependency and fail at the final link stage, according to the report.
• The stale CMake trap
  Disabling flash attention may not take effect if an earlier CMake cache survives, so the build directory must be cleared or reconfigured directly.
• The ABI trap
  A torchvision wheel can install and import successfully, then fail when a compiled operator runs because it was built against a different PyTorch ABI.
• The video stack
  The described setup compiles FFmpeg with NVDEC support and links torchcodec against that local build for GPU video decoding.

Why it matters

This is useful for anyone trying to move vision-language-action experiments from a desktop demo to a small robot. The practical consequence is not merely a longer installation: the hardware-specific build determines whether the system can decode video on the GPU, load the model and avoid runtime crashes that basic import checks miss.

The guide also explains why a green Docker build is not proof of a working robotics stack. A shell script that swallows a failed fallback can produce a perfectly packaged broken image, which is a particularly efficient way to lose an afternoon.

Our read

This is a strong field note, not a universal installation promise. The most valuable contribution is its map of failure modes: build the versions that actually match, clear cached configuration, test compiled operators at runtime and make failures fail loudly.

Readers with the same Jetson, JetPack and LeRobot constraints should start from the author's container and build logs rather than improvising a fresh toolchain. Everyone else should treat the timings and exact compatibility boundaries as a platform-specific reference, not a law of embedded AI physics.

What to watch

• Whether LeRobot and Jetson vendors publish current Python 3.12-compatible CUDA wheels.
• Whether the reported container remains compatible as PyTorch, torchcodec and JetPack move on.
• Whether independent users reproduce the runtime validation on other Orin configurations.
• Whether future edge-robotics stacks make hardware video decoding and ABI matching less bespoke.

Discussion spark: Should edge-robotics projects prioritise officially maintained, slightly older wheels over newer features that require multi-hour source builds?

not affiliated with or endorsed by Hugging Face