AROLA: A Modular Layered Architecture for Scaled Autonomous Racing

Resumen Técnico: AROLA – Una Arquitectura de Capas Modulares para Carreras Autónomas Escaladas

Planteamiento del Problema
El campo de las carreras autónomas escaladas, particularmente en plataformas como RoboRacer (anteriormente F1Tenth), ha experimentado un rápido crecimiento. Sin embargo, los stacks de software desarrollados para estos sistemas suelen sufrir de fragmentación, diseños monolíticos y un acoplamiento estrecho con hardware específico o reglas de competición. Esta falta de modularidad dificulta la reutilización, complica la comparación justa entre grupos de investigación y dificulta la evaluación sistemática. Si bien los enfoques de aprendizaje de extremo a extremo (end-to-end) ofrecen alternativas, a menudo sacrifican la interpretabilidad y la mantenibilidad. Existe una necesidad crítica de un marco abierto y por capas que estandarice las interfaces, permita componentes intercambiables y soporte una evaluación reproducible sin depender de definiciones de mensajes personalizadas.

Metodología
Los autores proponen AROLA (Autonomous Racing Open Layered Architecture), una arquitectura de software modular y de capas abiertas diseñada para descomponer el flujo de datos de la conducción autónoma en ocho capas distintas e intercambiables, conectadas mediante interfaces estandarizadas de ROS 2. La arquitectura sigue un flujo de datos de arriba hacia abajo con interacciones conservadoras entre capas para preservar la modularidad:

1. Sensing (Detección): Adquisición de datos ambientales brutos a través de sensores a bordo.
2. Preprocessing (Preprocesamiento): Filtrado, limpieza y fusión de flujos de datos brutos para reducir el ruido y la carga computacional.
3. Perception (Percepción): Asignación de significado semántico a los datos (por ejemplo, identificación de límites de pista y obstáculos).
4. Localization and Mapping (Localización y Mapeo): Un proceso acoplado (SLAM) para determinar la pose del vehículo y construir mapas.
5. Planning (Planificación): Generación de trayectorias factibles basadas en los datos de percepción y del mapa.
6. Behavior (Comportamiento): Gobierno de la lógica de toma de decisiones (por ejemplo, mediante máquinas de estados o árboles de comportamiento) para determinar qué debe hacer el vehículo.
7. Control (Control): Ejecución de planes de movimiento y compensación de imperfecciones de actuación.
8. Actuation (Actuación): Ejecución física de comandos en el hardware.

Para apoyar la evaluación sistemática, los autores introducen Race Monitor, un marco de monitoreo ligero basado en ROS 2. Race Monitor registra telemetría en tiempo real (tiempos de vuelta, calidad de la trayectoria, carga computacional) y genera análisis post-carrera estandarizados utilizando el paquete evo. Publica datos en tópicos estándar de ROS 2, lo que permite que los controladores se suscriban sin introducir acoplamiento, y soporta varios formatos de trayectoria (CSV, TUM, KITTI).

Contribuciones Clave
El artículo presenta tres contribuciones principales:

1. AROLA: Una arquitectura de software modular y de capas abiertas que estandariza las interfaces (utilizando tipos de mensajes ROS 2 estándar como LaserScan, Odometry, OccupancyGrid y AckermannDriveStamped) para facilitar la intercambiabilidad de componentes y la sustitución rápida de módulos.
2. Race Monitor: Una suite integrada de monitoreo y benchmarking en tiempo real que permite la evaluación objetiva del rendimiento, la visualización del error de trayectoria y la comparación consistente de estrategias de control.
3. Validación: Validación experimental exhaustiva del marco tanto en entornos simulados como en hardware físico utilizando la plataforma RoboRacer.

Resultados Experimentales
El marco fue validado durante la preparación para la competencia RoboRacer IV25 2025 y en experimentos post-competencia:

• Comparación de Controladores: Se evaluaron tres controladores (Gap Follower, Pure Pursuit y MPC). Pure Pursuit logró los tiempos de vuelta más rápidos (mejor vuelta de 10.10 s) con una carga computacional moderada (28% de CPU) y una latencia de control de 18 ms, superando al MPC en velocidad a pesar de que el MPC presentaba un menor jerk. El Gap Follower fue el más lento pero el más reactivo.
• Desempeño en la Competencia: La configuración final de AROLA aseguró el tercer lugar en la competencia RoboRacer IV25 con un tiempo de vuelta de 10.1 s.
• Evaluación de LQR: Una evaluación post-competencia de un controlador LQR en un "Mapa Berlín" demostró la capacidad del sistema para registrar métricas detalladas. El controlador LQR completó siete vueltas con un mejor tiempo de 19.53 s y un puntaje de consistencia alto (0.99), donde Race Monitor identificó con éxito desviaciones de trayectoria y desalineaciones de escala.

Significancia y Reivindicaciones
Los autores afirman que AROLA y Race Monitor demuestran que la modularidad, las interfaces transparentes y la evaluación sistemática pueden acelerar el desarrollo y mejorar la reproducibilidad en las carreras autónomas escaladas. Al reorganizar los diseños fragmentados en capas estandarizadas, la arquitectura reduce la barrera de entrada preservando el poder expresivo necesario para la conducción avanzada. El marco permite a los equipos intercambiar componentes (por ejemplo, cambiar controladores o módulos de percepción) sin rediseñar todo el stack y permite una comparación imparcial de estrategias bajo condiciones idénticas. El artículo concluye que este enfoque proporciona una base práctica para la iteración rápida, la evaluación de desempeño justa y el escalado confiable en la investigación de carreras autónomas.

Limitaciones y Trabajo Futuro
Los autores reconocen que la evaluación actual es limitada en alcance, centrándose principalmente en un pequeño conjunto de controladores en lugar de toda la gama de módulos potenciales. El sistema sigue siendo susceptible a la propagación de errores a través de las etapas del pipeline, y la validación se centra actualmente en una plataforma de hardware específica. El trabajo futuro apunta a mejorar las herramientas para la alineación de marcos de coordenadas, extender la validación a diversos hardware y simuladores, desarrollar un sistema de vigilancia (watchdog) para la prevención de fallos y crear una interfaz web para Race Monitor. Además, los autores planean explorar la integración de componentes basados en aprendizaje o de extremo a extremo parcial dentro del marco modular manteniendo las interfaces estandarizadas.