Construir un volante de datos de robots: desde la primera demostración hasta la mejora continua
Cómo los equipos de robótica líderes construyen volantes de datos <unk> recoger, entrenar, implementar, identificar fallos, recoger más. Una guía práctica para el aprendizaje continuo de robots.
[← Guías]
Los equipos que ganan en el aprendizaje robótico no son los que tienen más datos
¿Qué es un robot de datos Flywheel?
Una rueda de vuelo de datos es un bucle auto-refuerzado en el que el despliegue de su robot genera los datos que necesita para mejorarlo, lo que hace que el robot sea más capaz, lo que genera más oportunidades de despliegue, lo que produce más datos.
El concepto se toma prestado de las compañías de software
Las empresas que construyen los robots más capaces en 2026
Por qué la mayoría de los laboratorios fallan en el volante
La mayoría de los laboratorios de robótica recopilan datos en una sola explosión, entrenan una política, la evalúan y luego o declaran éxito o recopilan otro lote de demostraciones. La diferencia crítica es la orientación: un volante se dirige específicamente a los modos de falla revelados por la implementación, en lugar de recopilar más datos para las condiciones que la política ya maneja bien.
El circuito de las ruedas de vuelo
El volante de datos del robot se compone de seis etapas que forman un ciclo continuo:
1. Recoger
¿Qué es esto?
2. Tren
¿Qué es esto?
3. Despliegue
¿Qué es esto?
4. Monitoreo
¿Qué es esto?
5. Detección de fallas
¿Qué es esto?
6. Recolectar más
↑ Vuelve a la etapa 2: Tren
Las etapas 1
Fase 1: Datos de semillas (50200 demostraciones)
El conjunto de datos de semillas establece su política de base. El objetivo no es una política lista para la producción
Cómo es "lo suficientemente bueno para la primera formación"
- Capacidad de tarea: Comience con la versión más sencilla y significativa de su tarea objetivo. Si el objetivo final es "ordenar elementos mixtos en contenedores", comience con "pick one known object and place in one bin". Elimine la variabilidad: posiciones fijas, iluminación controlada, tipo de objeto único.
- Conte de demos por algoritmo: ACT: 50
200 demos. Política de difusión: 100 300. VLA fine-tune (OpenVLA/Octo): 50 100 con base pre-entrenada. Recoge hasta que su tasa de éxito de validación sea plateaux, no hasta que alcance un número redondo. - Consistencia de los operadores: Utilice 1
3 operadores capacitados, no operadores multitudinarios diversos. La diversidad ayuda más tarde. - ** Puerta de calidad:** Revise cada episodio antes de añadir a la formación. Rechace los episodios con: vacilación del operador > 2 segundos, no captura recuperada por reaproche (a menos que se recopilen específicamente datos de recuperación), oclusión de la cámara del punto de manipulación o ejecución de tareas incompletas. Consulte nuestro [guía de recopilación de datos]
T2 ) para el protocolo de calificación completo.
Seed Dataset Timeline
Con un operador experimentado y validado [configuración de la teleoperación] (T3
Fase 2: Primera implementación y seguimiento
Después de entrenar en el conjunto de datos de semillas, despliegue la política en su entorno de prueba.
Modo de sombra teleoperado
Antes de la implementación totalmente autónoma, ejecuta la política en modo sombra: la política predice acciones, pero el operador mantiene una anulación de teleoperación. Si la política está a punto de fallar, el operador se hace cargo y completa la tarea. Registra tanto las acciones previstas de la política como las acciones correctivas del operador.
El modo sombra tiene dos propósitos: genera datos de capacitación de la distribución real del estado de la política (los estados donde la política se mete en problemas), y proporciona una evaluación segura del comportamiento de la política antes de eliminar la red de seguridad humana.
Monitoreo de rendimiento
Durante el despliegue, registre lo siguiente para cada episodio:
- ** Grabación completa de episodios:** Posiciones conjuntas, imágenes de cámara, acciones y timestamps
formato idéntico a los datos de formación. - Etiqueta de resultado: Étiqueta de éxito, falla o intervención del operador. Etiqueta automáticamente cuando sea posible (por ejemplo, éxito = objeto detectado en la zona objetivo por cámara aérea). Etiqueta manual para casos ambiguos.
- ** Categoría de fallas:** Si el episodio falló, clasifique la falla. Categorías: falla de captura, error de colocación, colisión, tiempo de espera, falla de recuperación, estado fuera de distribución. Estas categorías conducen la fase 3.
- Versión de política: Etiquetar cada episodio con el punto de control del modelo que lo generó. Es esencial para rastrear la mejora en las rotaciones de los volantes.
Infraestructura de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación de explotación
El sistema mínimo viable de registro de fallas es un archivo CSV con columnas: episodio_id, timestamp, política_versión, resultado, falla_categoría, notas. La [Plataforma de Datos RCSV]
Fase 3: La explotación minera fallida
La minería de fallas es la innovación principal que hace que el volante funcione. En lugar de recopilar más demostraciones en general, se identifican los modos de fallas específicos que limitan el rendimiento y se recopilan datos que se dirigen directamente a esos modos.
Identificar cuáles no son las prioridades
Después de 50
- ** Frecuencia:** ¿Qué modo de falla ocurre con mayor frecuencia?
- Fixiabilidad: Algunas fallas se pueden abordar con datos (la política nunca ha visto ese estado). Otras requieren cambios de hardware (el robot no puede alcanzar físicamente el objetivo).
- Impacto: Un modo de falla que bloquea el 100% de los intentos de una variante de objeto específico tiene mayor prioridad que uno que causa fallos intermitentes en todas las variantes.
Estrategias de anotación
- Anotado de timestamp: Para cada episodio de falla, marque el timestamp donde comenzó el fallo.
- Anotación de estado: Describa el estado en el punto de falla: "el objeto se giró 45 grados, el agarre se acercó desde el ángulo equivocado".
- Análisis de grupos: Episodios de falla de grupo por similitud visual en el punto de falla. Si 20 fallos muestran que el robot carece del objeto de la misma manera, ese grupo representa una única brecha en la distribución de entrenamiento.
Fase 4: Recopilación de datos dirigida
En lugar de recoger 200 demostraciones genéricas más (que proporciona retornos decrecientes), recoge 30
Recopilación de modos de falla específicos
- ** Fallas de agarre:** Configurar la escena en configuraciones donde la política falló. Teleoperar demostraciones exitosas desde estos estados específicos. Varia el ángulo de aproximación y el tiempo de agarre para cubrir la región de fallas.
- Erros de colocación: Iniciar la demostración desde un estado en el que el objeto ya está agarrado (salte la fase de agarramiento).
- Demonstrativas de recuperación: Ejecutar la política hasta que alcance un estado de casi falla (por ejemplo, objeto ligeramente mal cogido). Asumir a través de la teleoperación y demostrar la recuperación. Estos "demos de recuperación" son los datos de mayor valor por episodio
una política entrenada con 50 demos de recuperación más 150 demos limpios supera a una entrenada con 500 demos limpios en métricas de robustez. - Cobreza de la zona de borde: Si los fallos se agrupan en posiciones o orientaciones de objetos específicos, recoge demostraciones que cubran específicamente esas posiciones. Utilice una plantilla física o una cuadrícula para garantizar una cobertura consistente de la región de fallos.
Recopilación dirigida frente a mejora general
Un error común es recoger "más de todo" en lugar de apuntar a los fracasos. Las matemáticas son claras: sumar 100 demostraciones de forma uniforme en todas las condiciones que la política ya maneja proporciona una mejora insignificante. Agregar 30 demostraciones en la región específica donde la política falla puede aumentar la tasa de éxito en un 15
Requisitos de infraestructura
Un volante funcional requiere infraestructura más allá de la recopilación de datos básicos.
Pipeline de datos
- ** Almacenamiento de episodios:** Todos los episodios de implementación (no solo datos de entrenamiento) deben almacenarse con grabaciones y metadatos completos. Presupuesto de 500 MB
2 GB por episodio dependiendo del número y resolución de las cámaras. - ** Etiquetado de episodios:** Etiquetar los episodios por tipo: "semilla", "recuperación dirigida", "éxito de despliegue", "fallo de despliegue", "recolectado automáticamente".
- ** Ingestión automática:** Los nuevos episodios deben fluir desde la máquina de recopilación o implementación al conjunto de datos de entrenamiento sin copiar archivos manualmente.
Modelo de versión
- Etiquetar cada punto de control de políticas entrenados con: versión del conjunto de datos, hiperparámetros, fecha de entrenamiento y métricas de validación.
- Registre qué versión de política generó cada episodio de implementación. Esta cadena es esencial para desactivar las regresiones de rendimiento ("¿Qué cambió la política v3 que la v2?").
- Mantenga al menos los últimos 5 puntos de control de política disponibles para el retorno.
Reentrenamiento automático
- Configure un guión que monitoree el directorio de su conjunto de datos para nuevos episodios y inicie una carrera de entrenamiento cuando haya un nuevo lote de N episodios (normalmente 25
50). - Utilice un cronista de trabajo (cron, Ray o Modal) para ejecutar la reeducación durante la noche para que las nuevas políticas estén listas para la sesión de despliegue de la mañana siguiente.
- Después de cada carrera de entrenamiento, ejecuta automáticamente una evaluación estandarizada (20 implementaciones en simulación o repetición) y registre los resultados junto al punto de control.
Tabla de control de monitoreo
Como mínimo, sigue estas métricas a lo largo del tiempo:
- Taxa de éxito por versión de la política (¿se está mejorando realmente el volante?)
- Distribución de modos de falla por versión de la política (¿funciona la solución dirigida?)
- Episodios recogidos por rotación de volante (¿se está disminuyendo el esfuerzo de recogida?)
- Tiempo desde la identificación de fallas hasta la política de formación (tiempo de ciclo)
Metricas para seguir
| Metric | What It Measures | Target | Red Flag |
|---|---|---|---|
| Success rate | % of deployment episodes that succeed | Increasing each rotation | Flat or decreasing after new data |
| Generalización score | Success rate on unseen conditions vs. seen conditions | >0.7 ratio | <0.5 (severe overfitting) |
| Data efficiency curve | Success rate improvement per N new episodes | Diminishing returns curve visible | No improvement despite more data |
| Cost per successful episode | Total collection cost / number of new successes | Decreasing each rotation | Increasing (flywheel is stalling) |
| Cycle time | Days from failure detection to retrained policy | <1 week | >2 weeks (pipeline bottleneck) |
| Failure mode coverage | % of identified failure modes with targeted data | >80% by rotation 3 | Same failure mode persists after 2 targeted collections |
Trampas comunes en el volante
1. acumulación de cambios de distribución
** Lo que sucede:** Cada rotación de volante añade datos específicos para modos de falla específicos. Con el tiempo, la distribución de la formación se ve muy inclinada hacia los casos de borde y los escenarios de recuperación. La política comienza a fallar en los casos "fácil" que solía manejar bien.
Fix: Mantenga una relación de 60
2. Inconsistencia de la anotación
** Lo que sucede:** Los miembros del equipo clasifican los fracasos de manera diferente. Una persona etiqueta un apretamiento casi perdido como "éxito", otro lo etiqueta como "fallo de apretamiento".
Fix: Escriba directrices de anotación explícitas con imágenes de ejemplo para cada categoría de fallas. Utilice el éxito/fallo binario como etiqueta principal (más difícil de estar de acuerdo), con las subcategorías de fallas como etiquetas secundarias. Realice verificaciones de acuerdo entre los anotadores mensualmente. Requiere un acuerdo de más del 90% sobre las etiquetas de éxito/fallo.
3. Drift de hardware
Qué sucede: Durante semanas de operación, las articulaciones del robot desarrollan una reacción negativa, el caucho de agarre se degrada, las montajes de la cámara se aflojan ligeramente.
Fix: Realice una verificación de calibración al comienzo de cada semana de despliegue: ordene al robot a 5 configuraciones conocidas y verifique que las posiciones de las articulaciones coincidan dentro de los 0,5 grados. Verifique la fuerza del agarre con un medidor de fuerza. Verifique las partes extrínsecas de la cámara con una tabla ArUco. Registre los resultados de la calibración junto con los datos de los episodios. Cuando se produzca el mantenimiento del hardware, recoge 20
4. Recopilar más datos para tareas resueltas
** Lo que sucede:** El error más común de volante. El equipo reúne otras 200 demostraciones para condiciones que la política ya maneja con una tasa de éxito superior al 90%, porque esas demostraciones son fáciles de recoger. Mientras tanto, los 3 modos de falla que limitan el rendimiento en el mundo real permanecen sin abordar.
Fix: Antes de cada sesión de recogida, responda: "¿Qué modo de falla específico estoy apuntando?" Si no puedes nombrar uno, ejecuta primero 10 implementaciones de políticas e identifica el fracaso más común. Esta disciplina
Estudio de caso: Una iniciación de manipulación de 0 a 10.000 episodios
Este caso hipotético ilustra una progresión realista de la rueda de vuelo para una startup construyendo un sistema de recogida de basura:
Mes 1: Datos de semillas
El equipo utiliza un solo ViperX-300 S2 con teleoperación líder-seguidor. Un operador experimentado recoge 200 demostraciones limpias de recoger un solo objeto conocido de un contenedor y colocarlo en un transportador. tarea: iluminación controlada, tipo de objeto único, posición fija de contenedor. Entrenan una política ACT. Resultado: ** 55% tasa de éxito** en la configuración controlada.
Mes 2: Primera rotación de la minería
Se aplica la política de 100 episodios de evaluación y fallas de registro. Distribución de fallas: 45% de fallas de captura (la orientación del objeto varía más que los datos de formación cubiertos), 30% de errores de colocación (tolerancia demasiado apretada de la posición de la cinta transportadora), 25% de tiempo de espera (la política se queda atascada en el enfoque). Recolectan 60 demostraciones dirigidas: 30 para orientaciones de objetos variadas, 20 para ubicación precisa, 10 para recuperación de enfoques. Reentrenamiento. Resultado: 72% tasa de éxito.
Mes 3: Expansión de la generalización
Introducen 5 tipos de objetos adicionales (diferentes formas, tamaños, pesos). La tasa de éxito inicial cae al 35% en los nuevos objetos. Recogen 150 demos en los 6 objetos con variación de posición/orientación. Cambian de ACT a Política de difusión para manejar la distribución de múltiples objetos. Resultado: 68% tasa de éxito en todos los objetos.
Mes 4: Aprendizaje activo
Implementan la estimación de incertidumbre (un conjunto de 3 políticas). Implementan con registro de incertidumbre. Cuando la incertidumbre exceda el umbral, señalen el estado para la demostración humana. Recogen 80 demos dirigidos a la incertidumbre
Mes 56: Escalado y recogida automática
La política ahora tiene éxito lo suficiente para la colección autónoma. Ellos ejecutan el robot 8 horas durante la noche con detección automática de éxito (camera superior verifica la colocación de objetos). Resultado: 91% de éxito en objetos conocidos, 78% en objetos nuevos.
Mes 712: Producción de la rueda de vuelo
Dos estaciones robóticas realizan una recopilación continua durante las horas de descanso. Reentrenamiento semanal con datos dirigidos de los fallos de esa semana. Expansión mensual a nuevas categorías de objetos.
Cuándo utilizar RCSV vs. Construir en casa
| Scenario | RCSV | In-House |
|---|---|---|
| Seed dataset (first 200 demos) | Faster — our operators are trained, hardware is calibrated | Good if your team needs to learn the data collection process |
| Targeted failure-mode data | Strong — we specialize in collecting edge-case data efficiently | Requires operator training for each failure mode |
| Scaling to 1,000+ episodes | Cost-effective — we provide shifts, QA, and infrastructure | Good if you have dedicated operators and hardware |
| Hardware you don't own yet | Lease from RCSV — try before buying | Requires capital outlay upfront |
| Bimanual or dexterous data | Specialized — we operate ALOHA and glove systems | Significant hardware and operator investment |
| Continuous flywheel operation | Hybrid: RCSV handles collection, you handle training/deployment | Best if you have a dedicated data ops team |
Línea de tiempo: desde Bootstrap hasta volante autosostenible
| Month | Phase | Activity | Expected Outcome |
|---|---|---|---|
| Month 1 | Seed | 200 clean demos, 3 training runs | 40–60% success on controlled setup |
| Month 2 | Failure mining | 100 deployment episodes, 60 targeted demos | 65–80% success, failure modes identified |
| Month 3 | Generalización | 150 demos with object/position variation | 70–80% success across 3x variation range |
| Month 4 | Active learning | 80 uncertainty-guided demos | >80% success, equivalent to 300 random demos |
| Month 5 | Auto-collection pilot | Autonomous collection, 20% human review | Validated auto-labeling; 200 episodes/day |
| Month 6+ | Self-sustaining | Continuous auto-collection + weekly retraining | 90%+ success; continuous improvement |
Acelerar su volante de datos con RCSV
RCSV proporciona recopilación de datos dirigida, demostraciones de recuperación de fallos, evaluación de episodios y entrega de tuberías para equipos que ejecutan programas de volante de datos. Recopilamos las demostraciones que necesitas
[Servicios de recogida de datos] [