Cómo escalar la recopilación de datos de robots a más de 10.000 demostraciones
Desafios y soluciones de ingeniería para escalar la recopilación de datos de la teleoperación de robots de cientos a decenas de miles de demostraciones.
[← Investigación]
Desde pilotos de una sola estación hasta flotas de varios laboratorios
Por qué es difícil escalar
Recoger 200 demostraciones es un proyecto de ingeniería. Recoger 10.000 es un problema de operación. Los cuellos de botella cambian por completo: a pequeña escala se está desactivando el hardware y la especificación de tareas; a gran escala se está gestionando el rendimiento del operador, la fiabilidad de la tubería de datos y la consistencia entre laboratorios.
La comunidad robótica aprendió esto a través de la construcción de conjuntos de datos como DROID (76.000 trayectorias, 22 robots, 13 laboratorios) y Open X-Embodiment (1M+ episodios, 22 tipos de robots).
Cuellos de botella de la capacidad de operador
La mayor limitación en la velocidad de recopilación de datos es el rendimiento del operador. Un operador calificado que ejecuta una tarea de complejidad moderada (L2
- A 50 demostraciones/operador/día: 5 operadores que se ejecutan simultáneamente durante 40 días
- En 30 demostraciones/operador/día (tarefa más difícil): 9 operadores durante 40 días
- Además, 20
30% de amortiguador para el rechazo de la calificación: añadir 1 2 operadores más
La búsqueda, la formación y el mantenimiento de 512 operadores simultáneos manteniendo la calidad alta es el reto principal. Los operadores no son fungibles
Arquitectura de la colección distribuida
Más allá de la escala de un solo laboratorio (~ 200 demostraciones / semana), se necesita una colección distribuida en varias estaciones o laboratorios.
- ** Lago de datos compartidos:** Todos los laboratorios escriben archivos de episodios en un cubo S3 común utilizando un esquema HDF5 estandarizado. Los metadatos de episodios (ID del operador, serie del robot, timestamp, ID de tarea, etiqueta de éxito) se escriben de forma atómica al final del episodio. Evite esquemas por laboratorio que requieren normalización post-hoc.
- ** Normalización de hardware:** Utilice modelos de cámaras idénticos, posiciones de montaje y configuraciones de robots en todos los sitios. Incluso diferencias menores de posición de la cámara (5
10 cm) degradan la formación de políticas transversales. Publique un documento de protocolo de calibración y ejecute sesiones de verificación remota. - ** Protocolo de instrucciones de tarea:** Tarjetas de tarea estandarizadas con fotos, plantillas de colocación de objetos (laser-cut acrílico bandejas funcionan bien), y ejemplos de video de ejecución correcta vs incorrecta. Sin esto, los operadores en diferentes sitios desarrollan interpretaciones sutilamente diferentes de la tarea.
- Tablero de monitoreo en tiempo real: Realice un seguimiento de las demostraciones/hora, la tasa de éxito y los operadores activos por sitio en un tablero compartido. Esto hace que aparezcan problemas a nivel de sitio (fallas de hardware, confusión del operador) antes de que consuman un presupuesto significativo.
Gestión de la calidad de los operadores a escala
La gestión de la calidad es la diferencia entre un conjunto de datos que forma una política de trabajo y uno que no lo hace.
- Demostraciones de la norma oro: Recoge 20
50 demos de "oro" por tarea de tu mejor operador. Usa estos como referencia de calidad. Computa automáticamente los puntajes de similitud (DTW en trayectorias conjuntas, correlación de tasa de éxito) entre las nuevas demos del operador y los estándares de oro. - ** Confiabilidad entre los índices:** Para las etiquetas de éxito subjetivas, tenga dos revisores que etiqueten de forma independiente el 10% de los episodios. Mide la kappa de Cohen. Meta κ > 0.8. Si la kappa es inferior a 0.7, sus criterios de éxito son ambigüos y necesitan refinamiento.
- Cartas de puntuación de los operadores: Seguir la tasa de éxito, la tasa de rechazo y el rendimiento por operador en una base semanal.
- Estructuras de incentivos: Las bonificaciones por calidad (no por volumen) impiden que los operadores se apresuren. Un bono de 0,10€ a 0,25€ por demostración aceptada (por encima de un umbral de calidad) supera la compensación por calidad de datos por hora.
Infraestructura de tuberías de datos
En 10.000 episodios, el manejo manual de datos no es factible. Necesitas una tubería automatizada desde la captura de episodios hasta los tensores preparados para el entrenamiento.
- Forma de episodio: HDF5 con esquema estandarizado (grupo de observaciones: imágenes de cámara, propriocepción; grupo de acciones: velocidades conjuntas o deltas de efecto final; grupo de metadatos: tarea, operador, timestamp).
- ** Validación automática:** Al ingerir, ejecuta: (1) validación de esquema, (2) verificación de duración (rechazar episodios <2s o >120s para la mayoría de las tareas), (3) verificación de violación de límites conjuntos, (4) detección de abandono de la cámara (marcos negros). Rechazar y marcar automáticamente.
- Versioning: Utilice DVC (Data Version Control) o un sistema manifiesto personalizado para etiquetar las versiones del conjunto de datos. Las carreras de entrenamiento deben referirse a una versión inmutable del conjunto de datos.
- Preprocesamiento: El recombinación, normalización y aumento de imágenes deben aplicarse en el momento de la formación a partir del HDF5 crudo, no incorporado a los datos almacenados.
Filtración de calidad a escala
Incluso con una buena gestión del operador, tendrá 20
- Clasificador de éxito: Entrenar un clasificador binario ligero (ResNet-18 o similar) en un subconjunto etiquetado manualmente de 500
1,000 episodios para predecir el éxito/fracasos desde el marco final. Aplicar a todos los episodios restantes. - Detección de anomalías de trayectoria: Computa estadísticas por episodio (velocidad conjunta máxima, longitud de trayectoria, entropía de acción).
- Muestreo de diversidad: Después de filtrar, compruebe si su conjunto de capacitación tiene cobertura en todas las variantes de tareas, posiciones de objetos y estilos de operador.
Números reales de la industria
| Dataset | Trajectories | Labs / Sites | Robot Types | Collection Period |
|---|---|---|---|---|
| DROID (Stanford) | 76,000 | 13 labs | 1 (Franka) | ~8 months |
| Open X-Embodiment | 1,000,000+ | 22 institutions | 22 types | Aggregated 2016–2023 |
| ALOHA-2 (Stanford) | 1,500 | 1 lab | 1 (ALOHA-2) | 3 months |
| BridgeData V2 | 60,000 | 4 lab configs | 1 (WidowX) | ~12 months |
| RoboSet (UT Austin) | 20,000 | 1 lab | 1 (Franka) | 4 months |
El conjunto de datos DROID es la referencia estándar de oro para la recopilación de datos distribuidos. Su [reporte técnico]
La plataforma de recopilación de datos de RCSV implementa la arquitectura descrita en este artículo
Escala su programa de recopilación de datos
RCSV opera una flota de recopilación de datos distribuida con más de 50 operadores capacitados, tuberías de calidad automatizadas e infraestructura gestionada.