Véhicule autonome CoVAPSy

Étude de cas

CoVAPSy – véhicule autonome 1/10. CoVAPSy est une compétition d’équipe collaborative organisée par l’ENS Paris-Saclay ; cette étude de cas décrit la contribution de Mehdi Bouama au logiciel de navigation et de commande du véhicule de course 1/10 de l’équipe, construit sur un Raspberry Pi 4 avec un RPLidar A2M12.

Contexte et défi

CoVAPSy 2026 exigeait qu’un petit véhicule autonome navigue sur une piste de façon réactive à partir des seules données lidar, sans carte préconstruite, tout en restant assez réactif pour éviter de se coincer contre les bords de piste ou d’autres obstacles ; le véhicule est conçu pour s’arrêter de façon sûre lorsque les données lidar disparaissent ou deviennent obsolètes.

Périmètre et responsabilités

CoVAPSy est un projet d’équipe collaboratif ; le véhicule complet et l’engagement en compétition ne sont pas uniquement le travail de Mehdi Bouama. Cette étude de cas décrit le logiciel de navigation et de commande : la boucle de commande Python réactive, le pipeline d’acquisition et de consommation lidar, les lois de navigation et de vitesse, le watchdog lidar, et la logique de récupération en cas de blocage, tels que publiés dans le dépôt public.

Architecture / Conception du système

Un thread en arrière-plan effectue une acquisition lidar continue à 360 degrés ; la boucle de commande principale interroge le dernier scan via un consommateur non bloquant avec suivi de fraîcheur, en calcule une direction et une vitesse, et pilote un ESC et un servo via PWM matériel. Un thread sonar optionnel tourne en parallèle et n’est lu que pendant une manœuvre de marche arrière. La loi de direction est une différence normalisée entre secteurs lidar gauche/droite, limitée à un angle de braquage maximal fixe ; la loi de vitesse est exponentielle sur ce même déséquilibre gauche/droite et pondérée par un dégagement frontal minimal, si bien que le véhicule ralentit à la fois dans les virages serrés et lorsqu’un obstacle est proche devant.

Mise en œuvre

La boucle de commande est configurée pour tourner à une fréquence fixe ; voir Vérification et preuves pour la classification de ce chiffre. Un watchdog lidar suit la fraîcheur des scans et, dès qu’un scan devient obsolète au-delà de son délai configuré, force la direction et la propulsion à zéro plutôt que de continuer à agir sur des données périmées. Une routine de récupération en cas de blocage surveille la distance frontale minimale et, dès qu’elle reste trop faible pendant suffisamment de cycles consécutifs, déclenche une manœuvre de marche arrière bloquante – une séquence ESC en double impulsion avec un angle d’échappement choisi du côté du dégagement le plus large – que le thread sonar peut interrompre si un obstacle arrière est détecté. Chaque cycle est journalisé en télémétrie CSV pour inspection ultérieure.

Vérification et preuves

La boucle de commande tourne à une fréquence configurée de 50 Hz : il s’agit d’une constante au niveau du code, confirmée par revue statique du code publié, et non d’une mesure de timing prise sur le véhicule en fonctionnement ; elle n’établit pas à elle seule un comportement temps réel dur ni un délai garanti dans le pire cas. Les mécanismes de sécurité ci-dessus – validation des paramètres au démarrage, watchdog lidar, récupération en cas de blocage, et arrêt inconditionnel des actionneurs – sont de même vrai par revue de code, tout comme l’interfaçage matériel : vrai. Le workflow de lint du dépôt public : vrai, un contrôle de style, pas un test fonctionnel ou embarqué.

Résultats

Le code source publié établit une pile de navigation et de commande réactive avec une fréquence de boucle configurée à 50 Hz, des lois de direction et de vitesse basées sur le lidar, et des garde-fous en couches dans la boucle de commande (watchdog de fraîcheur lidar, récupération en cas de blocage, routine d’arrêt des actionneurs dans un bloc finally). Aucun temps au tour, benchmark, ou classement en compétition n’est revendiqué ici, et aucune propriété de temps réel dur ou de garantie de timing dans le pire cas n’est revendiquée pour la boucle de commande.

Limites

Cette étude de cas décrit uniquement le logiciel de navigation/commande tel que publié dans le dépôt, pas la conception électrique ou mécanique du véhicule, pas le reste de la contribution de l’équipe, et pas un rapport de test physique validé du système : la classification ci-dessus reflète une revue statique du code, pas une mesure sur le véhicule ni une validation de type ROS/HIL, dont aucune n’est établie ici. La logique de watchdog et d’arrêt s’exécute au sein de la même boucle de commande principale ; aucun processus watchdog indépendant ni watchdog matériel n’est établi, de sorte qu’un gel de cette boucle n’est pas couvert.

Points clés à retenir

Un contrôleur réactif sans carte n’est fiable qu’à hauteur de ses modes de défaillance : la logique de watchdog et de récupération en cas de blocage s’exécute dans la boucle de commande principale pour réagir aux données lidar perdues ou obsolètes tant que cette boucle continue de s’exécuter, mais n’établit aucune protection contre un blocage de la boucle elle-même. Rédiger cette étude de cas a aussi demandé de distinguer soigneusement une constante configurée d’une valeur mesurée – une fréquence de boucle de 50 Hz dans le code source n’est pas la même affirmation qu’un 50 Hz vérifié en timing sur le véhicule physique – et de bien cadrer le périmètre : décrire le travail logiciel d’un contributeur au sein d’une compétition d’équipe sans le présenter comme l’ensemble du véhicule.

Livrables / Références

Dépôt public : github.com/mahdidou711/mahdidou711-covapsy.