Contexte : pourquoi comparer les plateformes open-source de conduite autonome ?
Le paysage open-source de la conduite autonome évolue vite : de nouveaux simulateurs apparaissent, les besoins se diversifient, et les plateformes se spécialisent.
Dans cet écosystème dense, RoadSimulator3 (RS3) occupe une place unique : ce n’est pas un simulateur 3D, ni une pile autonome complète, mais un simulateur inertiel haute fidélité à 10 Hz, pensé pour la télématique, la fusion capteurs et la mobilité connectée.
Là où CARLA, Autoware ou Apollo se concentrent sur la perception, le véhicule autonome ou la planification, RS3 génère des séries temporelles réalistes (GPS, IMU, pente, météo, contexte routier, micro-événements).
C’est la brique manquante entre la donnée terrain et les algorithmes.
Qui fait quoi ? (vue rapide)
CARLA → perception 3D photoréaliste
Autoware → pile autonome ROS2
Apollo → pile ADS industrielle
NAVSIM → navigation GNSS/INS
RS3 → inertie / cinématique / télématique 10 Hz
RS3 + NAVSIM : une combinaison gagnante
RS3 et NAVSIM couvrent deux volets complémentaires :
- RS3 : génère des trajectoires routières réalistes (pente, courbure, événements, adhérence, météo).
- NAVSIM : applique un modèle réaliste GNSS/INS sur ces trajectoires (bruits MEMS, erreurs GNSS, masques urbains).
Ainsi, un labo ou une flotte peut valider un algorithme de localisation robuste sans véhicule réel, avec un pipeline complet :
RS3 → NAVSIM → algorithme INS/GNSS → analyse d’erreur.
👉 Objectif de cet article : expliquer clairement le rôle exact de RS3, sans opposer inutilement les plateformes — chacune excelle dans son domaine.
NAVSIM : une montée en gamme des simulateurs GNSS/IMU académiques
NAVSIM apporte une architecture moderne pensée pour la recherche GNSS/INS : simulation réaliste des constellations satellites, gestion du multipath, masques urbains, modèles d’IMU, et une boucle inertielle-gnss complète en temps réel. Contrairement aux simulateurs 3D, NAVSIM vise la navigation plutôt que la perception.
Points clés :
– simulation GNSS multi-constellation ;
– modèles d’erreurs IMU (biais, random walk, bruit) ;
– scénarios satellites complets (éclipses, masques, multipath urbain) ;
– chaînage IMU→INS→GNSS en temps réel.
NAVSIM se rapproche du besoin RS3, mais ne le remplace pas : là où NAVSIM simule la physique GNSS/INS, RS3 simule la cinématique routière (pente, curvature, évènements). Les deux sont complémentaires.
Ce que dit l’état de l’art
Une revue récente, « A Survey of Open-Source Autonomous Driving Software » (Zhang et al., 2025, Sensors), propose une cartographie claire des écosystèmes open-source pour la conduite autonome. Elle analyse notamment CARLA, Autoware et Apollo.
Les critères étudiés incluent :
– les capteurs simulés ;
– la capacité temps réel ;
– la licence ;
– le besoin en GPU ;
– le positionnement visé (recherche académique, démo industrielle, ou pile quasi-produite).
Ainsi, cette revue sert de référence pour comprendre où RS3 s’insère.
Pour aller plus loin, consultez l’étude complète : Yueyuan Li et al., Choose Your Simulator Wisely: A Review on Open-Source Simulators for Autonomous Driving (arXiv:2311.11056v2, 2023).
Limites des plateformes existantes
Chaque plateforme excelle dans son domaine, mais présente aussi des limites lorsqu’on cherche à simuler la dynamique inertielle :
- CARLA : parfait pour la perception, mais surdimensionné pour l’analyse inertielle ou la télématique (dépendances GPU lourdes).
- Autoware : excellent pour l’AD, mais dépend fortement d’un environnement ROS2 et d’une pile perception.
- Apollo : robuste mais industriel ; difficile à intégrer dans un pipeline data science classique.
- NAVSIM : très fort sur GNSS/INS, mais ne modélise pas la vie réelle d’un conducteur (pente, virages, micro-événements, conditions routières).
RS3 se place précisément là où ces outils ne vont pas :
→ génération inertielle, cinématique véhicule, contexte routier, micro-événements.
RoadSimulator3 est pensé comme un simulateur inertiel haute fréquence. De plus, il se concentre sur la génération de séries temporelles réalistes, plutôt que sur la synthèse d’images caméra.
En pratique :
-
Production de signaux GPS + IMU à 10 Hz. RS3 génère accélérations, rotations gyroscopiques et trajectoires GNSS enrichies (pente, météo, typologie routière). C’est la matière première pour entraîner et valider des algos d’estimation de mouvement ou de détection d’événements agressifs.
-
Aucune dépendance GPU. Contrairement à CARLA, RS3 tourne sur une machine légère. Il ne nécessite pas d’Unreal Engine et peut être exécuté dans un pipeline data classique (Python, CSV, Pandas). Par conséquent, il est déployable chez un assureur, une flotte ou un labo sans workstation graphique.
-
Indépendant du CAN. RS3 permet de tester des scénarios d’éco-conduite, de risque conducteur, ou d’usure mécanique sans avoir besoin d’un accès direct au bus CAN du véhicule. En effet, l’accent est mis sur l’interprétation inertielle embarquée.
-
Pensé pour la fusion capteurs. Le but n’est pas de faire rouler une voiture autonome en simulation 3D temps réel, mais de fournir une vérité terrain cohérente entre GNSS, IMU et contexte routier.
Tableau comparatif des plateformes open-source de conduite autonome
Le tableau suivant illustre les différences d’intention et d’usage entre RS3 et les grandes stacks connues.
| Critère | RoadSimulator3 | CARLA | NAVSIM | Autoware | Apollo |
|---|---|---|---|---|---|
| Objectif principal | Simulation IMU / GPS réaliste à 10 Hz | Simulation 3D haute fidélité | Simulation GNSS/IMU académique (temps réel, recherche localisation) | Pile logicielle conduite autonome temps réel | Pile ADS industrielle complète |
| Capteurs simulés | GPS, IMU (acc, gyro), terrain, météo | Caméra, LIDAR, radar, IMU | GNSS multi-constellations, IMU, scénarios satellites | Caméra, LIDAR, GPS | Caméra, LIDAR, radar |
| Résolution temporelle | 10 Hz (inertie fine) | Variable (jusqu’à 30 FPS) | Temps réel (simulation navigation) | Temps réel (selon hardware) | Temps réel optimisé GPU |
| Représentation 3D | Non (cartographie OSM enrichie) | Oui (Unreal Engine) | Non (focus navigation, pas de scènes 3D) | Partielle (intégration externe) | Partielle (intégration externe) |
| GNSS dégradé | Oui (coupures GNSS simulables) | Partiel (scripts spécifiques) | Oui (masques satellites, multipath, coupures) | Oui via fusions (EKF / UKF) | Oui via fusions (EKF / MSF) |
| Météo / relief / typologie | Oui (OSM + SRTM + météo + pente) | Oui (scripts météo / éclairage) | Partiel (selon modèles GNSS/IMU intégrés) | Non natif | Non natif |
| Interface | Python / JSON / CSV | API Python | C++, Python (selon build), fichiers scénario | ROS2 | ROS / CyberRT |
| Spécialisation | Analyse style de conduite, inertie, éco-conduite | Perception visuelle | Recherche navigation, fusion GNSS/IMU, robustesse | Pile véhicule autonome complète | Plateforme industrielle |
| Poids / déploiement | Léger (pas de GPU) | Lourd (GPU requis) | Léger (orienté algorithmes navigation) | Moyen (ROS2 + drivers) | Lourd (dépendances industrielles) |
| Licence | MIT / AGPL pour certains plugins | LGPL v3.0 | Open-source académique (selon dépôt) | Apache 2.0 | Apollo License v2.0 |
Quel outil pour quel besoin ?
Voici comment choisir la bonne plateforme selon votre besoin, de manière simple et pragmatique.
| Use case | Outil recommandé | Pourquoi |
|---|---|---|
| Calibration GNSS/IMU | NAVSIM | Simulation fine des constellations + modèle IMU réaliste |
| Détection agressivité / éco-conduite | RS3 | Simulation inertielle + pente + GNSS dégradé en 10 Hz |
| Recherche perception IA | CARLA | Photorealistic + LIDAR + caméra 3D |
| Expérimentation pile autonome | Autoware | ROS2 + pipeline perception complète |
| Benchmark ADS industriel | Apollo | Stack robuste typée OEM |
| Simulation massive (100k trajets/jour) | RS3 | Léger, scalable, compatible pipeline data |
Comment RS3 génère la vérité terrain inertielle ?
Trajectoire simulée
→ Cinématique (a, v, ω)
→ Modèle véhicule
→ Ajout bruit MEMS
→ GNSS synthétique cohérent
→ Micro-événements (freinage, virage, accélérations)
RS3 fournit une vérité terrain exploitable directement dans un pipeline data science (Python / CSV / JSON), ce qui le rend unique dans l’écosystème open-source.
À retenir pour un assureur, une flotte, un labo
RS3 n’essaie pas de simuler des caméras ou un LIDAR dans une scène 3D photoréaliste. Ce n’est pas son rôle. En effet, CARLA fait déjà ça très bien.
En revanche, RS3 simule finement l’inertie, la cinématique véhicule, la pente, les coupures GNSS et les micro-événements de conduite (freinage fort, virage serré, accélération agressive). De plus, ces signaux sont fournis en 10 Hz exploitable directement dans un pipeline data science.
Par conséquent :
– un assureur peut estimer le risque conducteur sans CAN,
– une flotte peut estimer l’usure mécanique et la dépense énergétique,
– un labo peut valider des algorithmes de fusion inertielle et de localisation robuste.
Enfin, RS3 reste léger à déployer. Pas de GPU, pas d’Unreal Engine, pas d’infrastructure ROS lourde. C’est une brique qu’on peut intégrer très tôt dans une démarche télématique, sécurité flotte, ou mobilité durable.
Conclusion
Les simulateurs open‑source ne cherchent pas à résoudre les mêmes problèmes.
RS3 se positionne comme la brique manquante entre la donnée terrain, la télématique et la fusion capteurs.
Il complète — plutôt qu’il ne remplace — CARLA, NAVSIM, Autoware et Apollo.
En résumé :
– Vous travaillez sur la perception : → CARLA
– Vous avez besoin d’une pile véhicule autonome : → Autoware / Apollo
– Vous travaillez sur la navigation GNSS/INS : → NAVSIM
– Vous travaillez sur inertie, cinématique, télématique, style de conduite, énergie : → RS3
👉 À lire aussi :
– Simulation inertielle 10 Hz – RoadSimulator3
– Détection d’événements de conduite par IMU embarquée
– Pente et altitude à 10 Hz : énergie et sécurité flotte
Laisser un commentaire