Strands y LeRobot llevan datasets del Hub a robots reales | Keryc
Tener un robot, datos de demostración en el Hugging Face Hub y una nueva tarea solía significar cinco herramientas diferentes que no se hablaban entre sí. Strands Robots y LeRobot unen esas piezas: la grabación, el formato de dataset, la inferencia y el despliegue hardware quedan componibles desde un solo agente.
Qué anuncia esta integración
Strands Robots (SDK open source, Apache 2.0) expone la pila LeRobot como AgentTools que puedes componer en un solo agente Strands. La integración es deliberadamente delgada: LeRobot sigue manejando la grabación y calibración en hardware, y Strands aporta la orquestación, simulación y el mesh para flotas.
¿Qué significa eso para ti como desarrollador? Que el mismo código de agente puede:
Grabar demostraciones en simulación y escribir un LeRobotDataset idéntico al que produce hardware.
Ejecutar una política en simulación o con un servicio local/externo (GR00T, LerobotLocal, Cosmos3, etc.).
Desplegar sin cambios al SO-101 en modo real con un argumento.
Coordinar múltiples robots vía un peer mesh (Zenoh o Device Connect) sin tocar la lógica del agente.
Cómo funciona: el flujo práctico en 5 pasos
La demo empaqueta todo en un único agente. En alto nivel, los pasos son:
Construir el agente con los AgentTools de LeRobot.
Grabar una demostración en MuJoCo y escribir un LeRobotDataset.
Ejecutar una política sobre el mismo formato de dataset.
Cambiar mode="real" y correr el mismo agente contra el SO-101 físico.
Extender la orden a una flota usando el mesh de Zenoh.
La versión mínima en Python cabe en cinco líneas:
from strands_robots import Robot
from strands import Agent
arm = Robot("so100") # mode="sim" por defecto
agent = Agent(tools=[arm])
agent("Pick up the red cube")
Pero qué hace eso por debajo:
Robot("so100") devuelve simulación por defecto; mode="real" devuelve un robot hardware manejado por LeRobot.
DatasetRecorder usa el mismo formato parquet + MP4 tanto en sim como en hardware. No hay conversión de datos.
La inferencia puede venir vía contenedor GR00T (gr00t_inference) o en proceso con LerobotLocalPolicy (modelos Hub bajo lerobot/).
Requisitos y comandos útiles
Requisitos principales:
Python 3.12+ en Linux o macOS (Apple Silicon soportado para MuJoCo).
Un proveedor de modelos Strands compatible: Amazon Bedrock, Anthropic, OpenAI, Ollama, o un proveedor local.
Para seguir el ejemplo: Strands Robots con extras de simulación, LeRobot y mesh.
Instalación y ejemplo en tu laptop (ruta sim-only, sin GPU ni credenciales obligatorias):
El notebook recomendado es examples/lerobot/hub_to_hardware.ipynb. El script por defecto usa la política Mock para que todo funcione sin checkpoint ni GPU.
Para grabar en hardware usa las utilidades de LeRobot directamente:
lerobot-calibrate --robot.type=so101_follower --robot.id=my_follower
lerobot-calibrate --robot.type=so101_leader --robot.id=my_leader
lerobot-record \
--robot.type=so101_follower --robot.id=my_follower \
--teleop.type=so101_leader --teleop.id=my_leader \
--dataset.repo_id=my_user/cube_picking \
--dataset.single_task='Pick up the red cube and place it in the box' \
--dataset.num_episodes=25 \
--dataset.push_to_hub=true
Políticas, conteiners y rutas locales
GR00T: el agente puede lanzar el contenedor con gr00t_inference(action="lifecycle", lifecycle="full", ...), bajar el checkpoint del Hub y exponer el servicio para que la simulación consuma las acciones.
LerobotLocal: ideal si prefieres inferencia in-process. Resuelve modelos que siguen la convención config.json dentro de la organización lerobot/.
Atención: LerobotLocalPolicy carga checkpoints con trust_remote_code. Define STRANDS_TRUST_REMOTE_CODE=1 y solo carga checkpoints de organizaciones en las que confías.
Orquestación de flotas y seguridad
El mesh usa Zenoh por defecto. Cada Robot() y Simulation() se une automáticamente al peer mesh. Con robot_mesh puedes descubrir peers, enviar comandos estructurados, hacer broadcast y emitir emergency stop.
Por defecto, las acciones que afectan actuadores físicos (broadcast, emergency_stop, tell, send, stop) están bloqueadas tras un human-in-the-loop (HITL) approval en la terminal. Esto evita que un prompt malicioso autorice acciones críticas.
Para despliegues en redes no confiables, no uses STRANDS_MESH_LOCAL_DEV=1. En producción activa STRANDS_MESH_AUTH_MODE=mtls y considera Device Connect para discovery y routing más robusto.
Buenas prácticas y consideraciones de seguridad
No alimentes a los agentes con datos no confiables sin controles: la inyección de prompt o datos maliciosos puede conducir a órdenes inseguras en el mundo físico.
Mantén la aprobación humana para acciones físicas sensibles. Puedes ajustar qué acciones requieren HITL con STRANDS_MESH_HITL_ACTIONS.
En el camino de entrenamiento: datasets de sim y hardware comparten la misma forma. Esto facilita transfer learning, pero valida calidad de datos simulados antes de entrenar políticas para hardware.
Limpieza y vuelta al estado anterior
Después de una sesión de ejemplo:
Para parar GR00T:
agent.tool.gr00t_inference(action="stop", port=5555)
# o usar lifecycle="teardown" para remover el contenedor
Desconecta los puertos serie si usaste hardware.
Los datasets locales quedan en ~/.cache/huggingface/lerobot/<repo_id>; elimínalos si quieres limpiar disco. Los datasets que subiste al Hub no se tocan.
Por qué importa
La decisión de diseño clave es no reinventar LeRobot: Strands añade la capa de agente y orquestación en lenguaje natural, mientras que LeRobot mantiene la responsabilidad sobre la abstracción de hardware, la calibración y el formato de dataset. El resultado es práctico: cada dataset en el Hub se convierte en un activo reutilizable por agentes, y la línea entre sim y real pasa a ser un detalle de despliegue en lugar de un cambio arquitectural.
Si te interesa experimentar, el ejemplo funciona en tu laptop sin hardware, GPU ni credenciales del Hub, y puedes llevarlo a hardware con solo cambiar mode a real y apuntar a tus dispositivos calibrados.
