Catégorie : RoadSimulator3

  • 🚗 OSM vs IGN : et si nous repensions la manière de mesurer les virages ?

    Sur le papier, un virage routier OSM ou IGN, c’est juste “la route qui tourne”. Dans la réalité métier, c’est un indicateur critique. C’est là que les conducteurs freinent tard, que la voiture prend du roulis, que la consommation explose, que les sinistres arrivent. Aujourd’hui, on s’en remet à des cartes qui décrivent ces virages de façon plus ou moins fidèle. Problème : si la géométrie est approximative, tout ce qu’on calcule derrière est faux — évaluation du risque conducteur, scoring d’éco-conduite, calibration ADAS, simulation inertielle. Dans ce billet, on montre pourquoi deux sources pourtant « sérieuses » (OpenStreetMap et l’IGN) ne racontent pas exactement la même route, et pourquoi ça compte pour l’industrie, pas juste pour les géomaticiens.

    Pour plus d’informations, consultez la base OpenStreetMap ou la BD TOPO® de l’IGN.
    Retrouvez également notre article sur la simulation inertielle 10 Hz avec RoadSimulator3.

    Comparaison OSM vs IGN des virages routiers

    Pourquoi comparer OSM et IGN ?

    Les virages sont bien plus que de simples courbes sur une carte. Ils influencent directement la sécurité routière, le confort des passagers, la consommation énergétique. Ils ont aussi un impact sur l’efficacité des systèmes d’aide à la conduite ou des simulateurs. Pourtant, une question simple reste ouverte : quelle est la vraie géométrie d’un virage ?

    Une même route, deux géométries différentes

    Dans notre étude, nous avons comparé deux grandes sources de données cartographiques :
    • OpenStreetMap (OSM) : une base mondiale, collaborative et ouverte.
    • BD TOPO® de l’IGN : une base nationale française, construite par des géomaticiens professionnels.

    Premiers résultats : les deux sources ne décrivent pas les virages de la même manière. OSM tend à simplifier les géométries (les virages apparaissent plus « anguleux »), tandis que l’IGN conserve une description plus fine. Ces différences sont invisibles à l’œil nu sur une carte. Elles ont un impact direct sur le calcul du rayon de courbure, et donc sur tout ce qui en dépend (sécurité, simulation, éco-conduite).

    Ces différences de courbure routière OSM influencent directement la perception du virage et les modèles de simulation.

    Vers un référentiel géométrique des virages

    🎯 Notre ambition : construire un référentiel des virages
    Nous ne voulons pas seulement comparer des chiffres. Notre ambition est plus large : créer un véritable référentiel des virages. Ce sera un cadre géométrique robuste qui s’appuie sur les principes de l’ingénierie routière (clothoïdes, arcs, lignes droites).

    Pourquoi ?
    • Pour mieux évaluer la qualité des données cartographiques.
    • Pour fournir une base de travail cohérente et exploitable par les chercheurs, les industriels et les collectivités.
    • Pour améliorer les simulations inertielles de RS3, en les rapprochant de la réalité physique des routes.

    Impacts pour la simulation inertielle et la sécurité flotte

    🚀 Une étude structurante
    Ce travail est structurant pour le projet RoadSimulator3 : il ne s’agit pas d’un simple module technique, mais d’un socle commun qui permettra d’évaluer, comparer et exploiter différentes sources de données routières.

    En résumé, une meilleure compréhension de la courbure routière OSM ouvre la voie à des modèles plus robustes et à une analyse fine du comportement conducteur.

    Conclusion

    Notre conviction : en construisant un référentiel de virages robuste, nous poserons les bases d’une meilleure compréhension des routes. Nous ouvrirons la voie à des applications concrètes — de la sécurité routière à l’éco-conduite, en passant par la simulation et la mobilité intelligente.

    👉 Vous pouvez retrouver notre premier post sur le sujet ici : OSM vs IGN : tous les virages ne se ressemblent pas.

  • Construire un service robuste de pente et d’altitude à 10 Hz pour la simulation de flottes de véhicules

    Résumé
    La pente de la route influence fortement la dynamique des véhicules. Elle impacte aussi la consommation énergétique et la sécurité. Pourtant, dans la plupart des simulateurs ou outils de mobilité, ce facteur est ignoré ou trop simplifié.

    Dans le cadre du projet RoadSimulator3 (RS3), nous avons construit une chaîne complète d’analyse altimétrique. En effet, cette chaîne permet d’évaluer, comparer et servir différentes sources de données d’altitude à haute fréquence.

    Cet article raconte la démarche. Nous partons de la comparaison des modèles numériques de terrain (MNT). Puis nous allons jusqu’à un micro-service Docker capable de répondre à des milliers de requêtes par seconde, en 10 Hz.

    Introduction : pourquoi la pente est critique

    Un conducteur le ressent immédiatement. Rouler à 80 km/h en côte ou en descente n’a rien à voir. L’effort moteur n’est pas le même. Le freinage non plus.

    La pente modifie la charge mécanique, la dépense d’énergie et le risque en cas d’urgence. De plus, une descente longue peut chauffer les freins. À l’inverse, une côte raide fait grimper la consommation.

    Pour un simulateur, ignorer la pente revient à tronquer une partie de la physique du véhicule. Par conséquent, on perd une part essentielle du réalisme.

    👉 Exemple concret :
    • Assurance : estimer la sévérité potentielle d’un freinage brusque en descente.
    • Smart city : estimer finement les émissions de CO₂ le long d’un itinéraire vallonné.
    • Flottes de livraison : prévoir le surcoût énergétique des tournées en côte.

    La simulation haute fréquence (10 Hz, soit une mesure tous les 0,1 s) impose donc des données précises, rapides et stables. C’est précisément ce que nous avons voulu démontrer avec RS3.

    Service altitude 10 Hz – Simulation énergétique RoadSimulator3

    Sources altimétriques et précision

    Pour modéliser correctement la pente, il faut des données d’altitude fiables. Nous avons retenu quatre bases principales :

    IGN RGE ALTI® 1 m : la référence en précision (jusqu’au décimètre). Cependant, ce jeu de données est très lourd à manipuler.
    IGN RGE ALTI® 5 m : un compromis intéressant entre taille et qualité.
    SRTM 30 m : modèle global produit par la NASA. Il est plus léger, mais moins précis.
    SRTM 90 m : couverture mondiale, mais résolution faible.

    Ainsi, toutes ces données ont été converties en Cloud Optimized GeoTIFF (COG).

    De plus, ce format offre plusieurs avantages :
    • accès rapide par tuiles,
    • compatibilité directe avec Rasterio / GDAL,
    • format ouvert pensé pour une exécution dans le cloud.

    En pratique, nous pouvons interroger une tuile altimétrique à partir de coordonnées GPS ponctuelles. Nous n’avons pas besoin de charger des gigaoctets en mémoire.

    Calcul de la pente réaliste

    Calculer la pente à partir d’altitudes brutes semble simple. Cependant, la réalité est plus complexe. Le bruit GPS, les imprécisions de mesure et les discontinuités du MNT peuvent s’additionner. Ils créent alors des valeurs aberrantes.

    Nous avons donc adopté une méthodologie pragmatique :

    Fenêtrage distance (20 à 30 m) : nous calculons la pente moyenne sur un segment, et non point par point.
    Lissage EMA (Exponential Moving Average) : ce lissage supprime le bruit sans perdre la réactivité.
    Clipping à ±30 % : toute pente au-delà de ±30 % est considérée comme aberrante. Elle est tronquée.

    En effet, cette combinaison donne des pentes réalistes et stables. Elle reste exploitable pour une simulation dynamique à 10 Hz.

    Architecture technique RS3

    Le projet RS3 repose sur une architecture modulaire. De plus, chaque brique est clairement isolée en termes de licence et de rôle :

    Core RS3 (AGPL) : moteur de pipeline inertiel.
    Contracts (MIT) : interfaces neutres et réutilisables.
    Plugin Altitude (AGPL) : accès aux MNT et génération altitude/pente.
    Plugin Fleet (MIT) : simulation multi-véhicules.

    Nous avons ensuite industrialisé cette brique sous la forme d’un service Flask. Le service est packagé avec Docker Compose.

    Ce service expose deux endpoints principaux :
    /health → vérification des providers disponibles.
    /sample?lat=..&lon=..&provider=.. → retourne l’altitude pour un point donné.

    Enfin, nous avons mesuré les performances avec un script bench_curl.sh.

    • Latence moyenne ≈ 54 ms sur 500 requêtes concurrentes (16 threads).
    • Débit ≈ 300 requêtes/s, extensible via scaling horizontal.

    Ces résultats sont suffisants pour alimenter une flotte de plusieurs dizaines de véhicules en temps réel. Par conséquent, la mise à l’échelle ne dépend plus d’un fournisseur externe. Elle reste sous ton contrôle.

    Résultats : précision et performance

    Voici un exemple observé près de Rouen (49.45, 1.1) :

    • RGE 1 m : 55.28 m
    • RGE 5 m : 55.27 m
    • SRTM 30 m : 56.0 m
    • SRTM 90 m : 56.0 m

    👉 L’écart IGN–SRTM reste modeste (environ 1 m). En effet, l’IGN offre surtout une bien meilleure granularité dans les variations locales.

    Nous avons enrichi un trajet GPS map-matché (≈ 567k points). Chaque point a reçu l’altitude issue de chaque provider. Puis nous avons calculé la pente.

    Les résultats sont les suivants :
    • L’écart relatif IGN RGE1 vs IGN RGE5 est inférieur à 2 %.
    • L’écart avec SRTM peut dépasser 10 % dans les zones vallonnées.

    De plus, aucun timeout n’a été observé sur 500 requêtes concurrentes. Le temps de réponse reste stable (moins de 100 ms). Enfin, la consommation CPU est d’environ 20 % sur un Beelink N100 (quad‑core).

    Applications métier

    Assurance. Estimer la sévérité potentielle d’un accident en fonction de la pente au moment du freinage. Par conséquent, on peut mieux catégoriser le risque.

    Smart city. Cartographier les émissions de CO₂ le long d’un itinéraire. De plus, la pente permet d’isoler les zones où un véhicule consomme anormalement.

    Flottes de livraison. Optimiser la consommation énergétique et les temps de parcours. En effet, une tournée avec fortes côtes n’a pas le même coût qu’une tournée plate.

    Recherche académique. Valider des modèles inertiels (IMU) avec un “ground truth” altimétrique fiable. Cela permet de rapprocher simulation et mesure terrain.

    Conclusion : énergie, usure et sécurité

    En combinant la pente, l’altitude et les signaux inertiels à 10 Hz, nous pouvons mieux comprendre la dépense énergétique. Nous pouvons aussi anticiper l’usure mécanique et évaluer le risque de conduite.

    Cette brique RS3 ouvre la voie à un pilotage énergétique intelligent pour les flottes, pour la recherche et pour la sécurité routière.

    👉 À lire aussi :
    Simulation inertielle 10 Hz – RoadSimulator3
    Virtual sensing consommation flotte sans CAN
    Détection d’événements de conduite par IMU embarquée

  • Plateformes open-source pour la conduite autonome : où se positionne RoadSimulator3 ?

    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.

    RoadSimulator3 face aux stacks open-source de conduite autonome

    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