RoadSimulator3

Nos produits : RoadSimulator3 et ReadyData

Catégorie : Simulation inertielle

  • Estimation vitesse véhicule IMU smartphone : état de l’art & limites

    Estimation vitesse véhicule IMU smartphone : état de l’art & limites

    Objectif

    L’objectif de cet article est clair : expliquer l’estimation vitesse véhicule IMU smartphone. Autrement dit, comment estimer la vitesse d’un véhicule uniquement à partir des capteurs inertiels (IMU) d’un smartphone, sans dépendre du GPS. Cette problématique d’estimation vitesse véhicule IMU smartphone est au cœur des recherches actuelles en mobilité numérique. Nous présentons donc l’état de l’art, les limites physiques (dérive, biais capteurs), et le rôle essentiel de RS3 / Telemachus pour tester et valider ces méthodes d’estimation vitesse véhicule IMU smartphone avant déploiement réel.

    estimation vitesse véhicule IMU smartphone
    Estimation de la vitesse véhicule via IMU smartphone (accéléromètres + gyroscopes).

    Contexte

    La mesure de vitesse est un élément fondamental des applications de mobilité : navigation, détection d’événements, consommation énergétique ou encore scoring de conduite.
    Sur smartphone, cette mesure repose souvent sur les signaux GNSS — mais lorsque ceux-ci sont indisponibles (tunnel, environnement urbain dense), la fusion inertielle devient une alternative.

    L’enjeu : déterminer si une IMU seule (accéléromètres + gyroscopes du smartphone) suffit à estimer correctement la vitesse.

    Méthodes étudiées

    Trois familles d’approches ressortent dans la littérature récente :

    1. Approches analytiques classiques
    2. Intégration des accélérations longitudinales après filtrage du biais gravitationnel.
    3. Nécessite une calibration fine et un repérage stable du véhicule.

    4. Sensible au drift cumulatif.

    5. Approches basées apprentissage

    6. Réseaux neuronaux (LSTM, CNN) entraînés sur des segments GNSS + IMU synchronisés.
    7. Ainsi, ils sont capables de compenser le drift sur des courtes durées, mais nécessitent un jeu de données massif.

    8. En revanche, ils sont peu généralisables entre véhicules et smartphones.

    9. Méthodes hybrides

    10. Utilisation de contraintes cinématiques (vitesse > 0, non-holonomie).
    11. Combinaison apprentissage + modèle physique.

    Ces approches cherchent à tirer parti des contraintes physiques (non-holonomie, vitesse positive) pour stabiliser l’estimation.
    Formellement, la vitesse longitudinale peut être estimée par :
    [
    v_t = \int (a_x – g \sin\theta)\,dt
    ]
    où (a_x) est l’accélération longitudinale mesurée, (g) la gravité et (\theta) l’inclinaison estimée.

    Approche DVSE (SmartphoneIMUSpeed2025)

    L’article DVSE – Deep learning-based Vehicle Speed Estimation (Xiao et al., 2025) propose un cadre d’apprentissage séquentiel supervisé par GNSS pour estimer la vitesse véhicule à partir de l’IMU d’un smartphone.
    Le cadre repose sur deux modules principaux :
    – Noise Compensation Network (NCN) : un GRU corrige les composantes déterministes et stochastiques du bruit inertiel.
    – Motion Transformation Network (MTN) : un réseau convolutionnel temporel aligne le repère du smartphone avec celui du véhicule.

    Le modèle est entraîné sur données réelles avec supervision GNSS et atteint une précision de MAE ≈ 2.35 m/s sur 60 secondes d’intégration.
    De plus, les auteurs démontrent une robustesse supérieure aux architectures LSTM classiques, notamment grâce à l’augmentation de données (poses aléatoires de smartphone) et à une fonction de perte spécifique compensant les décalages GNSS–IMU.

    Données et simulation RS3

    Pour comparer ces approches, le simulateur RS3 permet de :
    – générer des signaux IMU synthétiques à 10 Hz ;
    – introduire des biais réalistes de capteurs ;
    – simuler des scénarios urbains avec arrêts, freinages et accélérations.

    Les scénarios générés par RS3 permettent une validation systématique des modèles : dérive cumulée, influence des biais capteurs, et sensibilité aux postures de smartphone.
    Ainsi, cette approche favorise la reproductibilité scientifique et la calibration inter-modèles dans un cadre ouvert.

    Limites observées

    Type de méthode Dérive après 60 s Sensibilité capteur Portabilité
    Intégration brute > 20 % Très élevée Faible
    LSTM (données locales) ≈ 8 % Moyenne Moyenne
    Hybride contrainte + LSTM < 5 % Moyenne Bonne

    Aucune méthode n’élimine totalement la dérive : la fusion GNSS + IMU reste incontournable pour des durées supérieures à 1 min.

    Voir les travaux récents sur l’estimation de vitesse véhicule par IMU seule (DVSE, 2025), qui combinent réseau neuronal séquentiel et contraintes physiques pour corriger la dérive sans GNSS.
    Pour plus de détails sur le simulateur, consultez la page RS3, simulateur inertiel 10 Hz.

    Perspectives

    • Constituer un dataset IMU-only standardisé par type de smartphone avec RS3.
    • Normaliser ces données via le format pivot Telemachus.
    • Explorer la calibration adaptative des capteurs embarqués (apprentissage en ligne).

    Liens avec RS3 et Telemachus

    Les travaux DVSE ouvrent des perspectives directes pour RS3 et Telemachus :
    – RS3 peut générer des jeux de données synthétiques IMU-only pour tester la robustesse du modèle DVSE.
    – Telemachus fournit un format pivot pour normaliser ces données et publier les résultats d’entraînement sous forme ouverte.
    – RS3 + Telemachus peuvent produire un dataset public pour benchmarker l’« estimation vitesse véhicule IMU smartphone ».
    – Ce dataset pourra ensuite servir dans les papiers P004 (GNSS/INS robuste) et P005 (Qualité des données véhicules connectés).

    En conclusion, l’estimation vitesse véhicule IMU smartphone représente un défi technique majeur, mais les avancées récentes et les outils comme RS3 et Telemachus ouvrent la voie à des solutions robustes et reproductibles.

  • IMUSim : simuler les capteurs inertiels pour mieux comprendre la fusion GNSS/IMU

    IMUSim : simuler les capteurs inertiels pour mieux comprendre la fusion GNSS/IMU

    L’expression IMUSim simulation inertielle GNSS/IMU désigne un environnement de simulation open-source. Il permet de comprendre la fusion capteurs et de valider les algorithmes RS3 et Telemachus. Ainsi, il constitue un outil clé dans ce domaine.

    IMUSim simulation inertielle GNSS IMU
    Schéma simplifié d’une simulation inertielle IMUSim (accéléromètres et gyroscopes virtuels).

    Pour valider un algorithme de fusion GNSS/IMU, il faut d’abord disposer de signaux réalistes.
    En effet, c’est précisément le rôle d’IMUSim, un environnement de simulation open-source. Il permet de générer des mesures d’accéléromètres et de gyroscopes virtuels.
    De plus, c’est une brique essentielle pour comprendre les fondations physiques et statistiques de la fusion inertielle. Elle est utile avant d’aller vers les approches hybrides (MMKF, DVSE) utilisées dans RS3 et Telemachus.

    Voir le projet IMUSim sur GitHub

    1. IMUSim et la simulation inertielle GNSS/IMU

    Développé par Young et al. (2011), IMUSim est un simulateur Python conçu pour la recherche et l’enseignement en traitement de signaux inertiels.
    Il permet de :
    – modéliser la cinématique d’un objet en 3D (trajectoires, vitesses angulaires) ;
    – générer les lectures correspondantes d’un capteur IMU (accéléromètres, gyroscopes, magnétomètres) ;
    – injecter des modèles de bruit réalistes, basés sur la variance d’Allan ou des paramètres physiques connus ;
    – tester des filtres de Kalman ou des algorithmes d’estimation d’attitude (AHRS).

    L’objectif est d’offrir une base cohérente et reproductible pour expérimenter. Ainsi, on peut travailler sans dépendre du matériel physique.

    2. Architecture et fonctionnement

    IMUSim repose sur une approche orientée simulation. Ainsi, il comprend plusieurs modules :
    – un module cinématique gère la dynamique de mouvement (position, vitesse, rotation) ;
    – un module de capteur applique un modèle d’erreur IMU, comprenant biais, dérive, marche aléatoire et cross-axis ;
    – un moteur de génération temporelle produit des signaux échantillonnés à fréquence configurable (jusqu’à plusieurs centaines de Hz).

    Le modèle de bruit IMU repose sur les paramètres caractéristiques (biais, dérive, marche aléatoire angulaire). Ces paramètres sont ajustables via les coefficients Allan.
    Formellement, le bruit peut être modélisé comme :
    (\omega_m = \omega_t + b + \eta),
    où (\omega_m) est la mesure, (b) le biais lentement variable, et (\eta) le bruit blanc gaussien.

    Les sorties sont exportables sous forme de fichiers CSV ou Python. En somme, elles sont prêtes à être intégrées dans d’autres environnements (MATLAB, ROS, RS3).

    3. Liens avec RS3 et Telemachus

    Dans le cadre de RS3 (RoadSimulator3), IMUSim constitue une référence historique. En effet, il a inspiré la logique de simulation inertielle (génération des signaux à 10 Hz, bruit inertiel, topographie).

    Les principes d’IMUSim se retrouvent dans plusieurs aspects :
    – la chaîne RS3 → Telemachus, où les signaux IMU simulés sont convertis au format pivot ;
    – le pipeline de validation Telemachus (RFC-0007, RFC-0009) pour tester les algorithmes de fusion GNSS/IMU ;
    – les études sur les erreurs stochastiques et la reproductibilité (C4 VAE).

    IMUSim reste un outil de référence pour l’enseignement et la recherche. Il illustre la propagation des erreurs inertiales et leur correction par filtrage. De plus, il s’intègre naturellement dans les workflows modernes RS3 et Telemachus.

    Lire aussi : RS3, simulateur inertiel 10 Hz

    4. Pourquoi c’est encore pertinent ?

    Même si de nouveaux frameworks (DVSE, MMKF) utilisent l’apprentissage profond, la simulation inertielle reste indispensable.
    Elle sert à générer des cas extrêmes de mouvement (accélération, virages serrés, vibrations).
    De plus, elle permet de valider des algorithmes en conditions contrôlées.
    Par ailleurs, elle aide à quantifier la dérive et à calibrer les modèles de bruit.

    Les travaux récents de Liu (2023) et Mafi (2025) prolongent cette logique. En effet, ils s’appuient sur les principes de modélisation inertielle d’IMUSim. Toutefois, ils les étendent à des contextes GNSS/IMU hybrides ou appris.

    5. En résumé

    IMUSim reste un pilier conceptuel dans la recherche en fusion inertielle.
    Il est simple, open-source et rigoureusement documenté.
    De plus, il est parfait pour comprendre la propagation des erreurs IMU.
    C’est un lien direct entre physique, mathématiques et simulation numérique.

    IMUSim est plus qu’un simulateur. En effet, c’est la base conceptuelle de la recherche en fusion inertielle. Il lie physique, mathématiques et simulation numérique.
    Son héritage perdure dans RS3 et Telemachus. Ces derniers poursuivent cette mission de validation ouverte et reproductible.

    En conclusion, IMUSim simulation inertielle GNSS/IMU reste un pilier de la recherche moderne sur la fusion inertielle.

    ✳️ Références :
    – Young, P. et al. (2011) — IMUSim: A Simulation Environment for Inertial Sensing Algorithm Design and Evaluation.
    – Liu, H. et al. (2023) — A Comprehensive Review of GNSS/INS Integration.
    – Mafi, S. et al. (2025) — Consensus Multi-Model Kalman Filter for Robust Vehicle State Estimation.

  • Filtrage invariant GNSS IMU : approche robuste de localisation RS3

    Filtrage invariant GNSS IMU : une approche géométrique pour la robustesse

    Le filtrage invariant GNSS IMU révolutionne la fusion de capteurs pour la localisation des véhicules. Contrairement aux méthodes classiques, ce filtrage invariant s’appuie sur la géométrie des groupes de Lie, garantissant stabilité et précision dans les pipelines RS3 et Telemachus.

    filtrage invariant GNSS IMU localisation RS3
    Le filtrage invariant (IEKF) applique la géométrie des groupes de Lie à la localisation véhicule.

    De quoi parle le papier original ?

    L’article “Invariant Filtering on the Two-Frame Group for Vehicle Localization with Unknown Parameters” (Chauchat et al., 2024) étend le cadre du Groupe à Deux Cadres (TFG) pour estimer non seulement la position et l’attitude d’un véhicule, mais aussi des paramètres inconnus comme le bras de levier GNSS et le facteur d’échelle (lié au rayon des roues ou à la pression des pneus).

    Grâce à un changement de variables astucieux (X' = X / s), le système peut être reformulé sur le groupe de Similitude (Sim(2)), permettant d’obtenir des équations d’erreur autonomes — cœur de la robustesse du IEKF.

    Les résultats montrent un taux de convergence supérieur à 98 %, même avec des erreurs initiales d’attitude supérieures à 200°, là où l’EKF standard échoue presque toujours.

    Schéma conceptuel du filtrage invariant GNSS IMU

    schéma filtrage invariant GNSS IMU RS3
    Schéma conceptuel du filtrage invariant sur groupe de Lie.

    Dans ce schéma, la géométrie du mouvement est directement intégrée dans le filtre.
    L’erreur évolue sur le groupe lui-même (et non dans un espace linéaire arbitraire), garantissant des propriétés de stabilité fortes.

    Application du filtrage invariant GNSS IMU à RS3 et Telemachus

    Ce cadre n’est pas purement théorique : il inspire directement la conception de pipelines de simulation et de validation inertielle dans RS3 et Telemachus, en offrant une base mathématique rigoureuse pour évaluer la cohérence physique des modèles.

    Problème traité Approche RS3 / Telemachus Lien avec IEKF
    Estimation de vitesse sans GNSS Modèles inertiels simulés + apprentissage supervisé L’IEKF fournit une référence physique stable
    Gestion des erreurs de capteurs Modélisation paramétrique RS3 + profils de bruit Telemachus Même logique de propagation autonome
    Bras de levier et échelle véhicule Simulation topologique et inertielle Reprend les notions de Sim(2) et d’échelle dynamique

    Perspectives

    L’extension du filtrage invariant vers des modèles multi-capteurs (GNSS, IMU, roues, caméras) ouvre la voie à des pipelines hybrides où la géométrie des groupes de Lie sert de colonne vertébrale pour intégrer l’apprentissage automatique.
    Les travaux récents sur les Kalman invariants multi-modèles (MMKF) (Mafi et al., 2025) prolongent cette direction, et RS3 pourrait jouer un rôle clé comme banc de test ouvert pour ces architectures.

    Ces approches posent les bases d’un paradigme où la géométrie remplace la linéarisation approximative du monde inertiel.
    En d’autres termes, les systèmes deviennent géométriquement cohérents avant même d’être corrigés par les données.

    Complément scientifique

    Le filtrage invariant repose sur la définition d’un espace d’erreur autonome :

    Ẋ = f(X, u)
    où X désigne l’état estimé et E = χ⁻¹·ĥχ l’erreur sur le groupe de Lie.

    Contrairement au filtre de Kalman étendu, la dynamique de l’erreur ne dépend plus de l’état estimé, garantissant stabilité et convergence.

    Lire l’article original sur HAL

    Lire aussi : RS3, simulateur inertiel 10 Hz

    📚 Références
    – Chauchat, A., Barrau, A., Bonnabel, S. (2024). Invariant Filtering on the Two-Frame Group for Vehicle Localization with Unknown Parameters.
    – Boguspayev et al. (2023). A Comprehensive Review of GNSS/INS Integration.
    – Mafi, F. et al. (2025). Consensus Multi-Model Kalman Filter.
    – Young, A.D. et al. (2011). IMUSim: A Simulation Environment for Inertial Sensing Algorithm Design and Evaluation.

  • 🚗 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