IA robótica en embebidos: VLA, datasets y optimizaciones | Keryc
La evolución de los modelos de lenguaje hacia sistemas multimodales ya permite que la visión y la acción convivan en un mismo modelo. ¿El problema? Llevar esas VLA (Vision–Language–Action) a hardware embebido con limitaciones reales de CPU, memoria, NPU y tiempo real. Este artículo técnico resume las prácticas de NXP para grabar datasets fiables, fine‑tuning de políticas ACT y SmolVLA, y las optimizaciones on‑device que lograron ejecutar estas políticas en un i.MX95.
¿Por qué es difícil ejecutar VLA en plataformas embebidas?
Porque no es solo comprimir un modelo. Es ingeniería de sistemas: descomponer la arquitectura, programar con conciencia de latencia y alinear la ejecución al hardware disponible. En tiempo real, una inferencia lenta causa pausas del robot, que generan correcciones oscilantes y peor recuperación. ¿La regla práctica? Mantener la latencia de inferencia por debajo del horizonte de ejecución: T_inference < T_execution.
En pipelines sincrónicos, mientras el VLA infiere, el brazo está inactivo. La solución es la inferencia asincrónica: generar acciones en paralelo a la ejecución. Pero para que funcione debes garantizar que el tiempo de inferencia sea menor que la duración del chunk de acción. Eso pone un límite superior al throughput del modelo.
Dataset: calidad antes que cantidad
¿Quieres que tu política aprenda manipulaciones finas? No le des datos desordenados. Aquí las recomendaciones prácticas que usaron con la tarea poner la bolsita de té en la taza.
Montajes fijos de cámaras. Evita drift de pose por vibraciones o reajustes. Un cambio post grabación puede hundir la precisión.
Iluminación controlada. Mantén fuentes fijas y evita luz solar variable.
Alto contraste entre brazo, objeto y fondo. Evita el famoso white on white salvo que ese sea tu dominio.
Copias de seguridad de calibraciones del robot y del teleoperador.
No hacer trampa al grabar: solo registrar lo que la política verá en runtime, normalmente las entradas de cámara, no la observación directa del operador.
Sobre número y tipo de cámaras:
Mezclar vistas aumenta precisión, pero suma latencia. En su caso, el balance fue 3 cámaras: Top, Gripper y Left.
Top
Gripper
Left
Vista global
Vista cercana para agarres precisos
Complementa profundidad y altura
La cámara en el gripper mejora la tasa de éxito en manipulaciones finas y además fuerza buenas prácticas de grabación porque el operador debe confiar en la percepción del robot. Asegura el cable con velcro o guías de alivio de tensión para evitar obstrucciones.
Pequeños ajustes de hardware ayudan: termorretráctil en las garras aumenta fricción y reduce resbalones, lo que reduce episodios de casi éxito y estabiliza el aprendizaje.
Estrategia de grabación
Variar posiciones iniciales: particiona el workspace en clusters y graba 10+ episodios por cluster. En el ejemplo usaron 11 clusters de 10x10 cm.
Conjunto de validación separado: excluir un cluster entero del entrenamiento para medir generalización (ejemplo: cluster 6).
Incluir movimientos amplios y recuperación: alrededor del 20% de episodios deben ser recovery, donde la política debe volver al objeto.
En su práctica:
Tarea: agarrar la bolsita de té y ponerla en la taza
Checkpoint final: el de menor pérdida de validación tras 200k pasos (con matices de selección por éxito real)
Entrenamiento: acciones por chunk y selección de checkpoint
Encontraron que para ACT el mejor trade off fue 100 acciones por chunk con entrenamiento efectivo entre 100k y 160k pasos. Para SmolVLA (50 acciones por chunk) se requieren muchos más pasos. Una observación importante: a veces continuar un poco después del sobreajuste aparente mejora la precisión en la práctica.
Regla de oro: elegir el checkpoint final evaluando éxito en entrenamiento y validación, no solo pérdida de entrenamiento.
Arquitectura práctica: descomposición en bloques
Evita un grafo monolítico. Divide en bloques lógicos que puedas optimizar y desplegar por separado:
Vision encoder: procesa frames RGB y produce embeddings visuales.
LLM backbone: convierte embeddings visuales y textuales en tokens de acción.
Action expert: aplica flow matching y desnoising iterativo para producir comandos de control.
Esta separación permite cuantificar el impacto de la cuantización por bloque y ejecutar el action expert a menor frecuencia si conviene.
Cuantización y precisión: trade offs reales
No todas las partes toleran igual la cuantización. En su experiencia en i.MX95:
Vision encoder y prefill del LLM perdieron poca precisión con cuantización a 8b o incluso 4b en capas seleccionadas.
La parte de desnoising iterativo del action expert sufre gravemente al cuantizar. Los errores se acumulan en pasos iterativos y degradan la estabilidad.
Decisión práctica: mantener el action expert en mayor precisión y cuantizar selectivamente el resto. Además aplicaron optimizaciones específicas por bloque para exprimir el hardware.
Inferencia asincrónica y scheduling consciente de latencia
Comparativa conceptual:
Síncrona: captura, inferencia completa, ejecución. El robot está inactivo durante la inferencia.
Asíncrona: mientras se ejecuta el chunk actual, el siguiente chunk se genera en paralelo.
Beneficios de la asincronía: mayor frecuencia efectiva de control, menos observaciones obsoletas, mejor recuperación. Pero recuerda la ecuación: la asincronía solo ayuda si T_inference < T_execution.
En embebidos es clave diseñar un scheduler que:
Priorice latencia para bloques críticos
Aplique ejecución colocada en CPU/GPU/NPU según capacidad
Use colas de acciones con funciones de agregación (por ejemplo, weighted_average) para suavizar transiciones entre chunks
Resultados en i.MX95 (benchmarks)
i.MX95 integra 6x Cortex‑A55, Cortex‑M7/M33, una GPU Mali, nuevo ISP y NPU eIQ Neutron, pensado para inferencia eficiente con multi‑cámara.
Tabla de resultados reproducida del estudio (tiempos y tasas de éxito en la tarea bolsita de té a taza):
Plataforma
Política
Formato
Latencia inferencia
Precisión Test (20)
Precisión Val (10)
Precisión Global (30)
i.MX95
ACT
ONNX FP32
2.86 s
1.00
0.90
0.96
i.MX95
ACT
Optimized
0.32 s
1.00
0.60
0.89
i.MX95
SmolVLA
ONNX FP32
29.10 s
0.50
0.40
0.47
También reportaron una versión optimizada on‑board de SmolVLA con latencia de 6.15 s en fase de mejora.
Interpretación rápida: ACT puede ser viable en tiempo real con optimizaciones agresivas. SmolVLA requiere más trabajo en NPU y optimizaciones de flujo para reducir latencias sin perder precisión.
Hoja de ruta práctica para desplegar VLA en embebidos
Si quieres replicar esto en tu proyecto:
Preparación del dataset
Valida montajes, calibraciones y contraste
Incluye recovery episodes y clusters
Entrenamiento
Guarda checkpoints y parámetros cada 20k pasos
Evalúa por éxito en sets de validación separados
Despliegue en i.MX95 u otro embebido
Descompón tu modelo en bloques
Cuantiza selectivamente y mantén las partes sensibles en mayor precisión
Implementa inferencia asincrónica y un scheduler de latencia
Próximos pasos técnicos que proponen: simular para escalar datos y benchmarks, usar RL para refinar políticas, y aplicar sim‑to‑real para cerrar la brecha dominio.
Llevar VLA a embebidos no es magia: es compromiso entre datos limpios, diseño arquitectural y optimización hardware‑aware. Si lo haces bien, tu robot deja de esperar y empieza a actuar de forma más fluida.