La pila de tecnología de inicio de aprendizaje robótico: decisiones clave en 2025
Decisiones tecnológicas para startups de robótica <unk> ROS2 vs. middleware personalizado, elección de simulación, inferencia en la nube vs. borde y estrategia de plataforma de datos.
[← Blog]
Las cuatro decisiones de infraestructura que limitarán su arquitectura durante los próximos tres años y cómo hacerlas bien en cada etapa de financiación.
Decisión 1: ROS2 vs. Middleware personalizado
Esta es la pregunta que cada startup de robótica debate y la mayoría se equivoca por la sobreingeniería. ROS2 te da un robot que funciona más rápido, te da acceso a un gran ecosistema de controladores y herramientas, y te hace más fácil contratar - la mayoría de los ingenieros de robótica conocen ROS2. La arquitectura pub/sub maneja la complejidad de los sistemas multi-nodo, y paquetes como MoveIt2, Nav2 y ros2_control manejan problemas que tomaría meses implementar desde cero.
El middleware personalizado ofrece dos ventajas genuinas: latencia por debajo de 5 ms (la carga general DDS deROS2 hace que esto sea casi imposible) y libertad de preocupaciones de licencias si su modelo de implementación comercial implica redistribuir una capa de middleware modificada. También hay un argumento real de que el middleware personalizado es más fácil de deshacer cuando posees completamente la pila.
La regla práctica: usar ROS2 a menos que esté en Serie B o más tarde con un producto de envío que haya demostrado limitaciones reales de latencia. La optimización prematura del middleware es uno de los errores más caros en las startups de robótica. El costo de oportunidad de 6 meses de reconstruir DDS es enorme en las primeras etapas. Si la latencia se convierte en una verdadera restricción más tarde, siempre puede reemplazar la capa de transporte manteniendo las interfaces ROS2.
Selección de proveedor ROS2 DDS
Si eliges ROS2, el proveedor de DDS importa más de lo que la mayoría de los equipos se dan cuenta. El CycloneDDS predeterminado es una opción sólida para la mayoría de las aplicaciones. FastDDS (el predeterminado anterior) tiene mejor descubrimiento en configuraciones de múltiples máquinas grandes pero mayor memoria en alto costo. Para los bucles de control en tiempo real, CycloneDDS con el transporte de memoria compartida de iceoryx (copia cero) elimina la carga de serialización que hace que el DDS estándar sea demasiado lento para el control de bucle interno.
Un patrón común en las startups con soporte RCSV: ejecutar CycloneDDS para todos los nodos no en tiempo real (percepción, planificación, registro) y utilizar un transporte personalizado ligero (UDP crudo o memoria compartida) para el bucle de control interno de 500Hz + entre el nodo de inferencia de política y el controlador de motor. Este enfoque híbrido te da el 95% del ecosistema ROS2 con las características de latencia de los middleware personalizados donde importa.
# Example: ROS2 + zero-copy shared memory via iceoryx
# In your ros2 workspace, set the middleware:
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp
# cyclonedds.xml -- enable iceoryx shared memory transport
# <CycloneDDS>
# <Domain>
# <SharedMemory>
# <Enable>true</Enable>
# <LogLevel>warning</LogLevel>
# </SharedMemory>
# </Domain>
# </CycloneDDS>
export CYCLONEDDS_URI=file://$(pwd)/cyclonedds.xml
Decisión 2: Plataforma de simulación
La elección de simulación moldea tu ciclo de entrenamiento durante años. Cuatro plataformas dominan en 2026, cada una por diferentes razones:
| Simulator | Parallel Envs | Contact Physics | License | Best For | GPU Required |
|---|---|---|---|---|---|
| Isaac Lab | 4,096+ on A100 | Adequate | MIT (BSD-3 for Sim) | GPU-parallel RL, locomotion | Yes (RTX 3090+) |
| MuJoCo | ~1,000 (MJX on GPU) | Excellent | Apache 2.0 | Contact-rich manipulation, dexterous hands | No (CPU OK; GPU for MJX) |
| Genesis | 10,000+ on A100 | Good (MPM for soft body) | Apache 2.0 | Soft body, deformables, fluids | Yes |
| Gazebo (Ignition) | 1-10 (CPU only) | Adequate | Apache 2.0 | ROS2 integration testing, sensor sim | No |
NVIDIA Isaac Lab: La mejor opción si el entrenamiento RL acelerado por GPU es su caso de uso principal. 4.096+ entornos paralelos en un solo A100, integración estrecha de Isaac Sim, licencia MIT, modelo de zoológico en crecimiento incluyendo Unitree G1 y Franka. El backend de PhysX es rápido pero utiliza contacto basado en penalidades que puede permitir la penetración en grandes tamaños de paso de tiempo.
MuJoCo: Mejor física de contacto en cualquier simulador de uso general. Dinámica basada en restricciones con manejo de contacto estable en alta conformidad. Elige esto para la investigación manual hábil, la manipulación rica en contactos o cualquier tarea donde la precisión de contacto es más importante que la paralela. Ahora libre bajo Apache 2.0 desde la adquisición de Google. MuJoCo XLA (MJX) aporta aceleración de GPU a través de JAX, logrando alrededor de 1.000 entornos paralelos -- no tan rápido como Isaac Lab pero suficiente para la mayoría de las manipulaciones RL.
Genesis utiliza el Método de Punto Material (MPM) para la física de cuerpos blandos, que es superior a MuJoCo e Isaac Lab para simular tejido, alimentos y tejidos humanos. Si su startup trabaja en el manejo de alimentos, manipulación textil o robótica quirúrgica, Genesis merece una evaluación seria. La capacidad de trabajo en tareas de cuerpo rígido es superior a la de Isaac Lab.
Gazebo (Ignition): Elige sólo si la integración profunda de ROS2 es un requisito difícil - Gazebo es el simulador oficial de ROS2 y tiene la integración más apretada de la cadena de herramientas. La física es más débil que las alternativas aceleradas por GPU. Es aceptable para la navegación, la simulación de sensores y las pruebas de integración. No es viable para el entrenamiento RL debido a la ejecución solo en CPU.
Arquitectura de políticas: ACT vs Política de difusión vs OpenVLA
Su elección de arquitectura de políticas está estrechamente vinculada a su estrategia de simulación y datos.
| Architecture | Paradigm | Data Needed | Inference Speed | Best For |
|---|---|---|---|---|
| ACT | IL (CVAE + Transformer) | 50-200 demos/task | ~5ms (fast) | Precise bimanual manipulation |
| Diffusion Policy | IL (DDPM denoising) | 100-500 demos/task | ~100-200ms (slow) | Multi-modal tasks, diverse strategies |
| OpenVLA / RT-2 | VLA (vision-language-action) | Fine-tune: 20-100 demos + pre-trained backbone | ~200-500ms (very slow) | Language-conditioned, multi-task |
| PPO/SAC (RL) | RL (reward-driven) | 0 demos (sim only) | ~1-5ms (very fast) | Locomotion, tasks with clear rewards |
Guía práctica: Comience con ACT si está recopilando datos de teleoperación y necesita una iteración rápida. ACT se transmite en horas en una sola GPU y la inferencia es lo suficientemente rápida para el control en tiempo real. Cambiar a Política de difusión si encuentra que su tarea tiene múltiples estrategias válidas (por ejemplo, enfoque desde la izquierda o la derecha) - el CVAE unimodal de ACT lucha con demostraciones multimodal, mientras que la Política de difusión las maneja de forma natural. Use OpenVLA/RT-2 solo si necesita el acondicionamiento del lenguaje (execución de instrucciones de lenguaje natural) o está ajustando a partir de un modelo de base pre-entrenado. La velocidad de inferencia de los VLA (200-500 ms) los limita a tareas en las que el tiempo de reacción no es crítico.
Decisión 3: Nube vs. Inferencia del borde
La latencia de la inferencia determina dónde se ejecuta su modelo. El umbral es de aproximadamente 150 ms de ida y vuelta: por debajo de eso, la inferencia en la nube de un centro de datos ubicado en una misma ubicación es viable para la mayoría de las aplicaciones.
Computación de borde: paisaje de hardware actual
| Device | TOPS | Price | ACT Inference | Diffusion Policy | OpenVLA 7B |
|---|---|---|---|---|---|
| Jetson Orin Nano (8GB) | 40 | $249 | ~15ms | ~300ms | Not feasible |
| Jetson AGX Orin (64GB) | 275 | $1,999 | ~5ms | ~120ms | ~800ms (quantized) |
| Jetson Thor (expected 2025-26) | ~800 | ~$2,500 est. | ~2ms | ~40ms | ~200ms (feasible) |
La inferencia en la nube tiene sentido cuando: la conectividad del robot es confiable (laboratorio o planta de fábrica con fibra), la latencia > 150 ms es aceptable para la aplicación, y el tamaño del modelo excede lo que el hardware de borde puede servir. Un enfoque híbrido funciona bien - ejecutar controladores reactivos rápidos de baja latencia en el dispositivo, descargar la planificación lenta y la percepción a la nube.
Formación en la nube: índices de coste
Los costes de formación varían considerablemente según la arquitectura de las políticas y el tamaño de los conjuntos de datos.
- ** ACT (tarea única, 200 demostraciones): ** ~ 8 horas en 1x A100 (40 GB). Costo: ~ $ 16 en Lambda Cloud ($ 2 / hora). ~ $ 24 en instancias de AWS p4d.
- ** Política de difusión (tarea única, 500 demostraciones):** ~ 24 horas en 1x A100. Costo: ~ 48 dólares en Lambda. Observaciones de imágenes con 3 cámaras aproximadamente el triple tiempo de entrenamiento frente a las observaciones de bajo tamaño.
- ** OpenVLA de tono fino (7B, 100 demostraciones):** ~ 12 horas en 4x A100 (LoRA).
- ** Locomotora de la OPP (Isaac Lab, 4096 envs):** ~ 4 horas en 1x RTX 4090.
Decisión 4: Estrategia de la plataforma de datos
La decisión de construir contra comprar una infraestructura de datos es más simple de lo que parece. Construye su propia plataforma de datos solo si tiene un ingeniero de infraestructura de ML dedicado en el personal cuyo trabajo principal es la herramienta de datos, no un investigador que también mantiene herramientas, un ingeniero infra dedicado. De lo contrario, la carga de mantenimiento se suma a un impuesto continuo significativo en sus personas más caras.
Lo que debe hacer una plataforma de datos
Las capacidades básicas que necesita: almacenamiento de episodios con versiones, indexación de metadatos para recuperación rápida, visualización para la calificación, división de conjuntos de datos y exportación a formatos de entrenamiento (HDF5/Zarr/RLDS), y control de acceso para entornos multioperador.
Comparación de herramientas de gestión de conjuntos de datos
| Tool | Type | Robot-Specific | Collection Tools | Training Integration |
|---|---|---|---|---|
| RCSV Platform | Managed service | Yes (teleop, annotation, QA) | Full (hardware + software) | HDF5/RLDS/LeRobot export |
| HuggingFace LeRobot | Open-source lib | Yes (robot datasets) | Recording scripts | ACT, DP, TDMPC built-in |
| Weights & Biases | Managed service | No (general ML) | Experiment tracking only | Any framework |
| DVC + MinIO | Open-source stack | No (general ML) | Version control only | Any framework |
El principio que debe guiar cada decisión de pila: comprar infraestructura, construir diferenciación. Tu ventaja competitiva es tu hardware de robot, tu experiencia en tareas y tu arquitectura de políticas - no tu sistema de almacenamiento de episodios.
La plataforma [RCSV]
Recomendado en cada etapa
| Stage | Middleware | Sim | Policy | Inference | Data Platform |
|---|---|---|---|---|---|
| Pre-seed / Seed | ROS2 Humble | MuJoCo or Isaac Lab | ACT (fast iteration) | Edge (Orin Nano) | RCSV or LeRobot |
| Series A | ROS2 + custom control | Isaac Lab + MuJoCo | Diffusion Policy or VLA fine-tune | Hybrid edge+cloud | RCSV or build if infra hire |
| Series B+ | Custom if proven need | Custom + one of above | Custom architecture | Custom serving (TRT) | Build if 2+ infra eng |
Lectura relacionada
- [Construyendo una startup de robótica en 2026]
T5 ) -- el libro de jugadas del fundador - [Política de ACT explicada]
T6 ) -- sumergirse en el algoritmo de IL más popular - Modelado de Recompensas for Manipulación RL -- si elige el camino RL
- Plataforma de datos del RCSV -- Infraestructura de datos gestionada
- Glosario del RCSV -- definiciones de los términos utilizados en este artículo
¿Necesitas infraestructura de datos sin el costo de construcción?
La plataforma de RCSV maneja el almacenamiento de episodios, anotaciones, visualización y exportación de la línea de entrenamiento para que su equipo pueda centrarse en el robot.
[Vea la plataforma]