Introduction
Le défi SAE AutoDrive est un concours de design collégial de 4 ans, auquel participent 8 équipes des États-Unis et du Canada. L'objectif technique de haut niveau pour la troisième année de cette compétition est de suivre un cours de conduite urbaine dans un mode de conduite automatisé tel que décrit par SAE niveau 3.
MathWorks met les équipes au défi d'utiliser la simulation
La simulation est un outil très utile pour le développement de véhicules autonomes. Les tests basés sur des modèles peuvent faciliter le développement d'algorithmes, les tests au niveau des unités et du système et les tests de scénarios de cas de pointe. Monde réel capteur les données peuvent être enregistrées et lues dans le système pour régler les algorithmes de fusion. Un environnement de simulation peut être créé pour modéliser des environnements réels et peut être utilisé pour tester divers algorithmes et positions de capteurs. Les meilleurs algorithmes et positions de capteur qui répondent aux exigences de l'équipe peuvent être choisis en fonction des résultats de performance.
Chaque année, MathWorks met les équipes au défi d'utiliser la simulation via un défi de simulation. Ce blog couvrira brièvement les lauréats des 1e et 2e places du Challenge 2020 (Université de Toronto et Université Kettering), leur conception de système et la façon dont ils ont utilisé les outils MathWorks pour aider à atteindre les objectifs généraux du concours. Les équipes ont été jugées en fonction de la façon dont elles ont utilisé les outils pour effectuer:
- Test de perception en boucle ouverte - synthèse de données pour des tests en boucle ouverte, évaluation de l'exactitude des algorithmes
- Test des contrôles en boucle fermée - synthèse de scénarios en boucle fermée, évaluation des performances des algorithmes de contrôle
- Génération de code d'algorithmes de contrôle - génération de code pour les algorithmes, intégration du code généré dans le véhicule
- Innover à l'aide des outils MathWorks – une technique/sans souci nettement différent des 3 catégories ci-dessus
Université de Toronto
L'équipe étudiante de l'Université de Toronto, aUToronto, a remporté la première place du défi.
Test de perception en boucle ouverte
La première étape de cette équipe a été de synthétiser les données pour les tests de perception en boucle ouverte. Ils ont choisi de tester leur algorithme de fusion de capteurs. Pour synthétiser des données synthétiques à des fins de test, ils ont utilisé le (DSD). Cette application vous permet de concevoir des scénarios de conduite synthétiques pour tester votre conduite autonome. L'équipe a utilisé un radar et 3 caméras dans les algorithmes de fusion de capteurs, qui sont configurés comme illustré à la figure 1.
Figure 1: Emplacements des capteurs d'équipe (© aUToronto)
Ils ont modélisé les capteurs de la caméra - ainsi que leurs positions, orientations et configurations - dans l'application DSD afin de synthétiser les données des capteurs pour les alimenter dans leurs algorithmes de fusion de capteurs. Le DSD simule la sortie de la caméra après les algorithmes de traitement d'image et de vision par ordinateur de l'équipe, et ajoute du bruit et des valeurs aberrantes aux données.
Le bloc Lecteur de scénario a été utilisé pour lire les informations de scénario créées à l'aide de DSD. Les poses de l'acteur ont été envoyées en entrée aux multiples générateurs de détection. Les détections pour ces différents capteurs ont ensuite été conditionnées sous forme de tableaux de messages ROS (Robot Operating System) de taille variable et envoyées sous forme de messages ROS personnalisés à des sujets ROS spécifiques (Figure 2).
Figure 2: Modèle Simulink pour les tests en boucle ouverte (© aUToronto)
L'équipe a comparé la sortie de son outil de suivi d'objets aux valeurs de vérité terrain des véhicules. La métrique RMSE (Root Mean Square Error) a été utilisée pour l'évaluation des performances.
Test des contrôles en boucle fermée
L'objectif principal de l'équipe était de tester leur planificateur modifié pour de nouvelles capacités telles que le réacheminement pour les zones de construction et le contournement des obstacles. Le planificateur a été repensé pour utiliser une structure en treillis où les bords sont élagués de la carte pour trouver des chemins autour des objets si nécessaire (Figure 3). DSD a de nouveau été utilisé pour créer des scénarios. Des barrières et des feux de signalisation ont également été ajoutés aux scénarios.
Figure 3: Structure en treillis pour la recherche de chemin (© aUToronto)
L'équipe a modélisé un éditeur de feux de signalisation à l'aide de Stateflow (Figure 4). Lorsque le véhicule de l'ego est hors de portée (> 50 m) du feu de signalisation, un état inconnu est publié. Lorsque l'ego est à portée, un message de lumière rouge est publié. Le message passe au feu vert après que l'ego s'est arrêté pendant 5 secondes.
Figure 4: Stateflow vers le contrôleur de modèle (© aUToronto)
Les nœuds ROS du contrôleur, du planificateur et du modèle de véhicule ont été lancés. Si l'obstacle était à moins de 50 m du véhicule de l'ego, sa position était envoyée sous forme de message ROS au modèle Simulink (Figure 5).
Figure 5: Logique d'envoi du message de position (© aUToronto)
Génération de code d'algorithmes de contrôles
L’équipe a généré du code pour l’algorithme de gestion des panneaux d’arrêt (Figure 6). Simulink Coder a été utilisé pour convertir le Stateflow en code C++. Un autonome module a été généré à l’aide de la fonction d’empaquetage de code. Le module généré a ensuite été fusionné dans la base de code de l'équipe.
Figure 6: Logique de commande des feux stop Stateflow (© aUToronto)
Innovation utilisant les outils MathWorks - Calibrage de la caméra Lidar
Pour interpréter avec précision les objets dans une scène avec les entrées d'un lidar et d'un capteur de caméra, il est nécessaire de fusionner les sorties de capteur ensemble. Par conséquent, l'équipe a effectué une transformation entre le Lidar et la caméra de l'équipe pour projeter des points Lidar sur une image ou vice versa pour la fusion de capteurs. Au lieu d'utiliser des mesures manuelles et des caméras rotatives jusqu'à ce que les projections soient bonnes, l'équipe a utilisé le nouvel outil de calibrage Lidar Camera de la boîte à outils de traitement Lidar. Cet outil estime une matrice de transformation rigide qui établit les correspondances entre les points dans le plan lidar 3D et les pixels dans le plan image
Ils ont construit une carte d'étalonnage plus grande car la carte actuelle était trop petite pour l'outil. L'outil d'étalonnage de la caméra a été utilisé pour obtenir la matrice intrinsèque de leur caméra. Les coins du damier ont été trouvés dans chaque image, ainsi que les données Lidar. La matrice de transformation rigide entre le Lidar et la caméra a été trouvée. Ce processus produit une transformation qui peut être utilisée pour projeter les données du nuage de points sur des images ou vice versa. Ces étapes sont illustrées à la figure 7.
Figure 7: (a) Matrice intrinsèque de la caméra (b) Coins du damier (c) Matrice de transformation du lidar à la caméra (© aUToronto)
Université de Kettering
La équipe étudiante de l'Université de Kettering, a remporté la 2e place du défi.
Test de perception en boucle ouverte
L'équipe a utilisé Unreal Engine pour créer divers scénarios. Une caméra a été ajoutée au véhicule de l'ego dans Unreal à l'aide du bloc de caméra de simulation 3D. Un modèle Simulink a été utilisé pour effectuer la détection de voie en utilisant les images irréelles (Figure 8). Les carrés bleus indiquent les fonctions de détection de voie et le jaune indique les sorties à chaque étape. Ces chiffres de sortie sont illustrés à la figure 9.
Figure 8: Modèle Simulink pour les tests en boucle ouverte (© Kettering University)
Figure 9: Sorties de détection de voie (© Kettering University)
Test des contrôles en boucle fermée
La conception du système de l'équipe se composait de 2 machines à états - longitudinale et latérale. Ces machines à états, illustrées sur la figure, ont été utilisées pour modéliser la logique de sélection du contrôleur basée sur des données de capteur et de prise de décision. Ils étaient interconnectés et utilisés pour activer et initialiser les sous-systèmes du contrôleur.
Figure 10: Machines d'État (© Université Kettering)
Des simulations de contrôleurs combinées, avec le modèle Simulink de la figure 11, ont été effectuées pour vérifier le fonctionnement de tous les contrôleurs d'équipe. Les entrées de ces contrôleurs ont été fournies à l'aide de curseurs et de jauges.
Figure 11: Modèle Simulink pour les tests en boucle fermée (© Kettering University)
Les sous-systèmes de commande de la machine à états longitudinaux comprennent le contrôleur de vitesse longitudinal et le freinage d'urgence automatique (AEB). Les états ont été déterminés par la dynamique longitudinale du véhicule comme l'accélération, la croisière, la décélération, l'arrêt et le stationnement.
Les sous-systèmes de commande de l'automate à états latéraux comprennent les contrôleurs de maintien de voie (LKA), de changement de voie et de virage. Les états ont été déterminés en fonction de la dynamique latérale des véhicules (figure 12). La vitesse longitudinale, le changement de voie et les contrôleurs LKA sont décrits ci-dessous.
Figure 12: États du contrôleur latéral (© Kettering University)
Contrôleur longitudinal
La figure 13 montre le modèle Simulink utilisé pour modéliser le contrôleur longitudinal. Il se composait d'un PID basé sur la vitesse. Les taux de couple de référence et de sortie étaient limités pour rester dans les limites d'accélération et de jerk de compétition. Les entrées du système ont été initialisées et modifiées avec des curseurs et une portée a été utilisée pour afficher les données. La figure 14 montre les sorties de vitesse longitudinale cible et réelle.
Figure 13: Modèle Simulink du contrôleur longitudinal (© Kettering University)
Figure 14: Comparaisons de vitesses longitudinales (© Université Kettering)
Contrôleur de changement de voie
Le contrôleur de changement de voie de l'équipe a utilisé le MPC adaptatif (Model Predictive Control). Un chemin de référence a été généré à l'aide de fonctions paramétriques, avec des entrées de changement de voie telles que la vitesse du véhicule et la largeur de voie. Les sorties vers le contrôleur étaient la position latérale de référence et le lacet. Un modèle 3DOF (degré de liberté) a été utilisé pour simuler la carrosserie du véhicule. La figure 15 montre le modèle Simulink utilisé pour la simulation. La figure 16 montre les sorties de la simulation avec des trajectoires de changement de voie de référence et simulées, ainsi que les trajectoires obtenues après un test embarqué.
Figure 15: Modèle Simulink du contrôleur de changement de voie (© Kettering University)
Figure 16: Comparaisons des chemins de changement de voie (© Kettering University)
Modèle de véhicule
L'équipe a développé et validé un modèle de véhicule à une et deux voies 3DOF. La validation initiale a été effectuée à l'aide d'un modèle de bicyclette linéaire. La validation finale a été effectuée avec des données de test physique. La figure montre la sortie de comparaison d'accélération latérale avec les validations initiales et finales, sans et avec les données de test.
Figure 17: (a) Comparaisons d'accélération latérale (b) Comparaisons avec les données de test (© Kettering University)
Innovation à l'aide des outils MathWorks - Unreal City
L'équipe a utilisé Unreal pour tester en boucle fermée tous ses contrôleurs. Ils ont créé une ville irréelle avec des mouvements de piétons et des feux de signalisation contrôlables. Des acteurs personnalisables ont été créés et leurs informations telles que le nom de l'acteur, le type d'acteur, les détails de l'acteur, les détails de l'animation et les balises ont été stockées pour un accès rapide. Une carte des feux de circulation a également été créée avec l'emplacement des feux étiqueté Figure 18.
Figure 18: Carte des feux de signalisation irréels (© Université Kettering)
La Figure 19 montre la structure de communication du système Simulink-Unreal. La prise de décision pour la scène Unreal, comprenant la position du véhicule, le mouvement des piétons, l'état des feux de signalisation, etc. a été effectuée à l'aide de Stateflow et envoyée en tant qu'entrée aux contrôleurs (Figure 20).
Figure 19: Structure de communication du système Simulink Unreal (© Université Kettering)
Figure 20: Stateflow pour la prise de décision de scène Unreal (© Université Kettering)
En conclusion, les équipes d'étudiants de l'Université de Toronto et de l'Université Kettering ont pu tirer parti de MATLAB et Simulink pour concevoir, construire, tester et évaluer des algorithmes de fusion, de suivi et de navigation afin de se rapprocher de la construction d'un véhicule autonome de niveau 4 SAE en simulation. Ils ont créé des scénarios complexes avec des feux de signalisation et de multiples acteurs dans différents environnements de simulation, intégré les environnements avec Simulink, et déployé et testé les algorithmes de leur choix sur ces scénarios. Des algorithmes de perception en boucle ouverte et en boucle fermée ont été modélisés et testés à l'aide de Simulink, et du code a été généré pour ces systèmes. Les équipes ont également conçu et testé divers algorithmes de contrôleur à l'aide de Simulink et Stateflow. Les outils MathWorks ont été utilisés de manière innovante et intensive par ces deux équipes de championnat.