Dall'Hub di Hugging Face al hardware robotico con Strands Agent e LeRobot

Dall'Hub di Hugging Face al hardware robotico con Strands Agent e LeRobot

Se hai un robot, una cartella di dati di dimostrazione sull'Hub Hugging Face e un nuovo compito da insegnare, oggi ci vogliono cinque strumenti diversi: uno per registrare nuove dimostrazioni, un altro per l'addestramento, un terzo per i test in simulazione, del codice personalizzato per il deployment su hardware e un altro per coordinare più robot. Gli strumenti singoli funzionano bene, ma non comunicano tra loro.

Strands Robots è un SDK open-source di AWS (licenza Apache 2.0) che espone astrazioni robotiche, simulazione e lo stack LeRobot come AgentTools che si compongono in un singolo Strands agent. L'integrazione è deliberatamente sottile: i propri script di LeRobot gestiscono la registrazione e calibrazione del hardware, mentre gli Strands AgentTools intervengono per le parti che l'agente effettivamente orchestra.

L'attrezzo di simulazione registra i LeRobotDatasets nello stesso formato in cui LeRobot li scrive sui dispositivi fisici. GR00T e LerobotLocal forniscono l'inferenza delle policy dietro un'interfaccia comune, e i checkpoint MolmoAct2 scorrono lungo il percorso LerobotLocal. Una mesh peer estende l'agente ai robot remoti. Il formato del dataset rimane esattamente come scritto da LeRobot; il ciclo dell'agente è il collante.

Questo post ti accompagna attraverso cinque passaggi all'interno di un unico agente: costruisci l'agente su LeRobot AgentTools, registra una dimostrazione in simulazione come LeRobotDataset, esegui una policy sullo stesso robot, distribuisci lo stesso codice agente a un robot fisico con un solo cambio di argomento, e invia comandi a una flotta su una rete Zenoh. Alla fine, puoi clonare l'applicazione esempio da GitHub e avviarla sul tuo laptop in simulazione. Niente hardware, niente GPU, niente credenziali Hugging Face richieste per il percorso predefinito.

L'esempio agente in questo post esegue quattro funzioni: registra nuove dimostrazioni in simulazione, pubblica il risultato sull'Hub come LeRobotDataset, attua una policy in simulazione con lo stesso formato e distribuisce lo stesso codice agente a un robot fisico cambiando un solo argomento. Quando hai più di un robot, l'agente può coordinare l'intera flotta utilizzando una mesh peer integrata. Per registrare e calibrare il hardware, i propri CLI di LeRobot (lerobot-record, lerobot-calibrate) gestiscono l'inizializzazione; l'agente prende da lì.

Due scelte progettuali fanno funzionare questo sistema. Primo, Robot("so100") restituisce per default una simulazione (niente hardware, niente rischi) e con mode="real" ottieni un robot hardware gestito da LeRobot. Il codice dell'agente è uguale in entrambi i modelli. Secondo, il DatasetRecorder che scrive in un LeRobotDataset è lo stesso per il percorso di simulazione e per la registrazione hardware di LeRobot, quindi i dati raccolti con MuJoCo e da un SO-101 fisico sono nello stesso formato.

Di seguito sono descritte in maniera dettagliata le azioni dentro quella chiamata.

L'esempio di questo articolo si esegue interamente su un laptop con questi tre strumenti. Esporta il tuo token Hugging Face se volessi far caricare i dataset sull'Hub o recuperare policy. Questo è opzionale per il percorso di simulazione predefinito in questo post; l'esempio funziona in modo completo con la policy Mock e scrive il dataset nella cache locale senza bisogno dell'accesso all'Hub.

L'esempio eseguibile si trova in examples/lerobot/hubtohardware.py (script Python) e hubtohardware.ipynb (notebook), nel repository strands-labs/robots insieme con esempi di MuJoCo e LIBERO. Il notebook è il punto di partenza consigliato: aprilo in JupyterLab e esegui le celle da cima a fondo in modalità simulazione senza dispositivi collegati.

Lo strumento di simulazione registra LeRobotDatasets nello stesso formato che LeRobot utilizza per hardware. Non è necessario alcun hardware. L'azione start_recording della simulazione passa attraverso la stessa classe DatasetRecorder: stesso schema parquet per stati e azioni, stesso layout per video delle telecamere. Il prompt dell'agente è quasi identico:

La policy Mock è intenzionale: produce azioni fittizie per joint in modo che il workflow funzioni in modo completo senza un checkpoint addestrato. Il robot si muove con movimenti casuali invece di completare una presa, e la registrazione ha una struttura completa (stati validi di joint, fotogrammi validi delle telecamere, un episodio ben formato LeRobotDataset), ma la dimostrazione in sé non è utilizzabile per l'addestramento. A partire dal passo 3, sostituisce Mock con GR00T o LerobotLocal per ottenere comportamenti di presa reali.

A titolo di esempio, puoi eseguire --policy lerobotlocal --checkpoint allenai/MolmoAct2-SO100101 (un checkpoint MolmoAct2, rilevato automaticamente da config.json e instradato attraverso LerobotLocal); il prompt, il formato del dataset e il codice agente restano gli stessi.

Evidenza di cosa succede in seguito. Il proprio loader del dataset di LeRobot legge i dati registrati in simulazione senza alcun percorso specifico per Strands:

Questo dizionario funzioni ha la stessa forma di qualsiasi dataset LeRobot sull'Hub: stesso nome di colonne, stesso layout parquet+MP4, stesso percorso loader. Gli script di allenamento che consumano dataset hardware possono consumare i dati registrati in simulazione senza modifiche. I dataset pushati da simulazione si trovano accanto a registrazioni hardware nel medesimo repository Hub se lo desideri.

Un singolo episodio da un LeRobotDataset registrato, riletto dal video MP4 per ogni telecamera che la registratore ha scritto, identici a quelli video che legge uno script di addestramento.

Per registrare dimostrazioni su un SO-101 fisico invece di simulazione, utilizza il CLI per la registrazione di LeRobot direttamente. L'integrazione con Strands non avvolge quel comando come AgentTool poiché LeRobot già svolge il lavoro in modo pulito.

Il dataset che atterra sull'Hub da questo comando è nello stesso formato del dataset registrato in simulazione. Per sintonizzare una policy, esegui il CLI per l'addestramento di LeRobot (lerobot-train); l'addestramento non rientra nello scope di questo articolo e segue il workflow LeRobot standard. A partire dal Passo 3, l'agente sceglierebbe indifferentemente il checkpoint originale o sintonizzato. Per un setup hardware SO-101 completo, procedure di calibrazione e troubleshooting, vedi il README nella cartella di esempio.

Con il dataset sull'Hub, il passo successivo è eseguire una policy. L'esempio utilizza il costruttore Robot() in modalità simulazione predefinita, quindi allega la gr00t_inference in modo che l'agente possa gestire il contenitore di inferenza:

Viene creato un ambiente di lavoro in cui l'agente riesce a eseguire il download del contenitore GR00T, scaricare il checkpoint dal Hub, e avviare il servizio di inferenza. Dopo, esegue una run_policy sull’agente simulato con