Introducción
El desafío SAE AutoDrive es un concurso de diseño universitario de 4 años, con la participación de 8 equipos de EE. UU. Y Canadá. El objetivo técnico de alto nivel para el año 3 de esta competencia es navegar por un curso de conducción urbana en un modo de conducción automatizado como se describe en el nivel 4 de SAE.
MathWorks desafía a los equipos a utilizar la simulación
La simulación es una herramienta muy útil para el desarrollo de vehículos autónomos. Las pruebas basadas en modelos pueden ayudar en el desarrollo de algoritmos, pruebas a nivel de unidad y de sistema y pruebas de escenarios de casos extremos. Mundo real sensor Los datos se pueden grabar y reproducir en el sistema para ajustar los algoritmos de fusión. Se puede crear un entorno de simulación para modelar entornos del mundo real y se puede utilizar para probar varios algoritmos y posiciones de sensores. Se pueden elegir los mejores algoritmos y posiciones de sensores que cumplan con los requisitos del equipo en función de los resultados de rendimiento.
Cada año, MathWorks desafía a los equipos a usar la simulación a través de un desafío de simulación. Este blog cubrirá brevemente a los ganadores del primer y segundo lugar del Desafío 1 (Universidad de Toronto y Universidad de Kettering), el diseño de su sistema y cómo usaron las herramientas de MathWorks para ayudar a lograr los objetivos generales de la competencia. Los equipos fueron evaluados en función de cómo utilizaron las herramientas para desempeñarse:
- Pruebas de percepción de bucle abierto: sintetizar datos para pruebas de bucle abierto, evaluando la exactitud de los algoritmos.
- Prueba de controles de bucle cerrado: sintetizar escenarios de bucle cerrado, evaluar el rendimiento de los algoritmos de control
- Generación de código de algoritmos de control: generación de código para algoritmos, integración del código generado en el vehículo
- Innovación utilizando herramientas MathWorks – una técnica/la tecnología claramente diferente de las 3 categorías anteriores
Universidad de Toronto
El equipo de estudiantes de la Universidad de Toronto, aUToronto, ganó el 1er lugar en el desafío.
Prueba de percepción de bucle abierto
El primer paso de este equipo fue sintetizar datos para las pruebas de percepción de bucle abierto. Eligieron probar su algoritmo de fusión de sensores. Para sintetizar datos sintéticos para realizar pruebas, utilizaron el (DSD). Esta aplicación le permite diseñar escenarios de conducción sintéticos para probar su conducción autónoma. El equipo utilizó un radar y 3 cámaras en los algoritmos de fusión de sensores, que se configuran como se muestra en la Figura 1.
Figura 1: Ubicación de los sensores del equipo (© aUToronto)
Modelaron los sensores de la cámara, junto con sus posiciones, orientaciones y configuraciones, en la aplicación DSD para sintetizar los datos del sensor para alimentar sus algoritmos de fusión de sensores. El DSD simula la salida de la cámara después del procesamiento de imágenes del equipo y los algoritmos de visión por computadora, y agrega ruido y valores atípicos a los datos.
El bloque Lector de escenarios se utilizó para leer la información del escenario creada mediante DSD. Las poses de los actores se enviaron como entrada a los múltiples generadores de detección. Las detecciones para estos diversos sensores se empaquetaron luego como matrices de mensajes ROS (Robot Operating System) de tamaño variable y se enviaron como mensajes ROS personalizados a temas ROS específicos (Figura 2).
Figura 2: Modelo de Simulink para pruebas de bucle abierto (© aUToronto)
El equipo comparó la salida de su rastreador de objetos con los valores reales de los vehículos. La métrica RMSE (Root Mean Square Error) se utilizó para la evaluación del desempeño.
Prueba de controles de circuito cerrado
El enfoque principal del equipo fue probar su planificador modificado para nuevas capacidades como el cambio de ruta para las zonas de construcción y evitar obstáculos. El planificador fue rediseñado para usar una estructura de celosía donde los bordes se podan del mapa para encontrar caminos alrededor de los objetos según sea necesario (Figura 3). DSD se utilizó una vez más para crear escenarios. También se agregaron barreras y semáforos a los escenarios.
Figura 3: Estructura de celosía para la búsqueda de rutas (© aUToronto)
El equipo modeló un editor de semáforos utilizando Stateflow (Figura 4). Cuando el vehículo ego está fuera del alcance (> 50 m) del semáforo, se publica el estado desconocido. Cuando el ego se pone dentro del alcance, se publica un mensaje de luz roja. El mensaje cambia a luz verde después de que el ego se ha detenido durante 5 segundos.
Figura 4: Stateflow al controlador del modelo (© aUToronto)
Se lanzaron los nodos ROS de controlador, planificador y modelo de vehículo. Si el obstáculo estaba a 50 m del vehículo ego, su posición se envió como un mensaje ROS al modelo de Simulink (Figura 5).
Figura 5: Lógica para enviar mensaje de posición (© aUToronto)
Generación de código de algoritmos de control
El equipo generó código para el algoritmo de manejo de señales de alto (Figura 6). Se utilizó Simulink Coder para convertir Stateflow en código C++. Un independiente módulo se generó utilizando la función de empaquetado de código. Luego, el módulo generado se fusionó con el código base del equipo.
Figura 6: Lógica de control de luz de freno Stateflow (© aUToronto)
Innovación con las herramientas de MathWorks: calibración de la cámara Lidar
Para interpretar con precisión los objetos en una escena con entradas de un lidar y un sensor de cámara, es necesario fusionar las salidas del sensor. Por lo tanto, el equipo realizó una transformación entre Lidar y la cámara del equipo para proyectar puntos Lidar en una imagen o viceversa para la fusión de sensores. En lugar de utilizar medidas manuales y cámaras giratorias hasta que las proyecciones se veían bien, el equipo utilizó la herramienta de calibración de cámara Lidar recientemente desarrollada de la caja de herramientas de procesamiento Lidar. Esta herramienta estima una matriz de transformación rígida que establece las correspondencias entre los puntos en el plano lidar 3-D y los píxeles en el plano de la imagen.
Construyeron una placa de calibración más grande ya que la actual era demasiado pequeña para la herramienta. La herramienta de calibración de la cámara se utilizó para obtener la matriz intrínseca de su cámara. Las esquinas del tablero de ajedrez se encontraron en cada imagen y los datos Lidar. Se encontró la rígida matriz de transformación entre Lidar y cámara. Este proceso genera una transformación que podría usarse para proyectar los datos de la nube de puntos en imágenes o viceversa. Estos pasos se muestran en la Figura 7.
Figura 7: (a) Matriz intrínseca de la cámara (b) Esquinas de tablero de ajedrez (c) Lidar a matriz de transformación de la cámara (© aUToronto)
Universidad de Kettering
El equipo de estudiantes de la Universidad de Kettering, ganó el segundo lugar en el desafío.
Prueba de percepción de bucle abierto
El equipo utilizó Unreal Engine para crear varios escenarios. Se agregó una cámara al vehículo del ego en Unreal usando el bloque de cámara 3D de simulación. Se utilizó un modelo de Simulink para realizar la detección de carriles utilizando las imágenes irreales (Figura 8). Los cuadrados azules indican las funciones de detección de carril y los amarillos indican las salidas en cada paso. Estas cifras de salida se muestran en la Figura 9.
Figura 8: Modelo de Simulink para pruebas de bucle abierto (© Kettering University)
Figura 9: Salidas de detección de carril (© Kettering University)
Prueba de controles de circuito cerrado
El diseño del sistema del equipo consistió en 2 máquinas de estado: longitudinal y lateral. Estas máquinas de estado, que se muestran en la figura, se utilizaron para modelar la lógica de la selección del controlador en función de los datos del sensor y la toma de decisiones. Se interconectaron y se utilizaron para habilitar e inicializar los subsistemas del controlador.
Figura 10: Máquinas de estado (© Kettering University)
Se realizaron simulaciones de controlador combinadas, con el modelo de Simulink en la Figura 11, para verificar el funcionamiento de todos los controladores del equipo. Las entradas a estos controladores se proporcionaron mediante deslizadores y medidores.
Figura 11: Modelo de Simulink para pruebas de circuito cerrado (© Kettering University)
Los subsistemas del controlador de la máquina de estado longitudinal incluyen el controlador de velocidad longitudinal y el Frenado automático de emergencia (AEB). Los estados fueron determinados por la dinámica longitudinal del vehículo como acelerar, crucero, desacelerar, detener y estacionar.
Los subsistemas del controlador de la máquina de estado lateral incluyen los controladores Lane Keep Assist (LKA), Lane Change y Turn. Los estados se determinaron en función de la dinámica lateral del vehículo (Figura 12). Los controladores de velocidad longitudinal, cambio de carril y LKA se describen a continuación.
Figura 12: Estados del controlador lateral (© Kettering University)
Controlador longitudinal
La Figura 13 muestra el modelo de Simulink utilizado para modelar el controlador longitudinal. Consistía en un PID basado en la velocidad. Las tasas de par de salida y de referencia se limitaron para mantenerse dentro de los límites de aceleración y tirones de la competencia. Las entradas del sistema se inicializaron y editaron con controles deslizantes y se utilizó un alcance para ver los datos. La Figura 14 muestra las salidas de velocidad longitudinal objetivo y real.
Figura 13: Modelo de Simulink del controlador longitudinal (© Kettering University)
Figura 14: Comparaciones de velocidad longitudinal (© Kettering University)
Controlador de cambio de carril
El controlador de cambio de carril del equipo utilizó MPC adaptativo (modelo de control predictivo). Se generó una ruta de referencia utilizando funciones paramétricas, con entradas de cambio de carril, como la velocidad del vehículo y el ancho de carril. Las salidas al controlador fueron la posición lateral de referencia y la guiñada. Se utilizó un modelo 3DOF (grado de libertad) para simular la carrocería del vehículo. La Figura 15 muestra el modelo de Simulink utilizado para la simulación. La Figura 16 muestra los resultados de la simulación con rutas de cambio de carril simuladas y de referencia, junto con las rutas obtenidas después de las pruebas en el vehículo.
Figura 15: Modelo de Simulink del controlador de cambio de carril (© Kettering University)
Figura 16: Comparaciones de rutas de cambio de carril (© Kettering University)
Modelo de vehículo
El equipo desarrolló y validó un modelo de vehículo de vía única y doble 3DOF. La validación inicial se realizó utilizando un modelo de bicicleta lineal. La validación final se realizó con datos de prueba física. La figura muestra la salida de comparación de aceleración lateral con validaciones inicial y final, sin y con datos de prueba.
Figura 17: (a) Comparaciones de aceleración lateral (b) Comparaciones con datos de prueba (© Kettering University)
Innovación con herramientas de MathWorks - Unreal City
El equipo usó Unreal para pruebas de circuito cerrado de todos sus controladores. Crearon una ciudad irreal con movimientos de peatones y semáforos controlables. Se crearon actores personalizables y su información, como el nombre del actor, el tipo de actor, los detalles del actor, los detalles de la animación y las etiquetas, se almacenó para un acceso rápido. También se creó un mapa de semáforos junto con la ubicación de las luces etiquetada como Figura 18.
Figura 18: Mapa de semáforos irreales (© Kettering University)
La Figura 19 muestra la estructura de comunicación del sistema Simulink-Unreal. La toma de decisiones para la escena Unreal, que consiste en la posición del vehículo, el movimiento de peatones, el estado de los semáforos, etc., se realizó utilizando Stateflow y se envió como entrada a los controladores (Figura 20).
Figura 19: Estructura de comunicación del sistema Simulink Unreal (© Kettering University)
Figura 20: Flujo de estado para la toma de decisiones de escena irreal (© Kettering University)
En conclusión, los equipos de estudiantes de la Universidad de Toronto y la Universidad de Kettering pudieron aprovechar MATLAB y Simulink para diseñar, construir, probar y evaluar algoritmos de fusión, seguimiento y navegación para acercarse un paso más a la construcción de un vehículo autónomo de nivel 4 de SAE en simulación. Crearon escenarios intrincados con semáforos y múltiples actores en diferentes entornos de simulación, integraron los entornos con Simulink e implementaron y probaron los algoritmos elegidos en estos escenarios. Los algoritmos de percepción de bucle abierto y de bucle cerrado se modelaron y probaron utilizando Simulink, y se generó código para estos sistemas. Los equipos también diseñaron y probaron varios algoritmos de controlador utilizando Simulink y Stateflow. Las herramientas de MathWorks fueron utilizadas de manera innovadora y extensa por estos dos equipos de campeonato.