RoadSimulator3

Nos produits : RoadSimulator3 et ReadyData

Étiquette : IMU

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

  • Telemachus standard télématique : un format ouvert pour les données véhicules

    Telemachus standard télématique : un format ouvert pour les données véhicules

    Telemachus standard télématique : un format ouvert pour unifier les données véhicules. Inspiré de GTFS, il améliore la recherche, l’assurance et la mobilité intelligente.

    Introduction : pourquoi un nouveau standard télématique est nécessaire

    Les véhicules connectés génèrent une masse croissante de données : GPS, vitesse, freinages, consommation, diagnostics embarqués… Pourtant, la télématique reste fragmentée. Chaque fournisseur propose ses propres formats, ses API, ses conventions de nommage.

    👉 Conséquence :

    • Les chercheurs peinent à comparer les résultats, faute de reproductibilité.
    • Les data scientists passent plus de temps à nettoyer les données qu’à les analyser.
    • Les industriels restent enfermés dans des solutions propriétaires coûteuses et difficiles à interconnecter.

    Par conséquent, une évidence s’impose : il faut un langage commun de la télématique.

    C’est la mission de Telemachus standard télématique, une spécification ouverte qui vise à devenir pour la télématique ce que
    GTFS a été pour les transports publics.

    Telemachus format ouvert – pivot de la télématique et de la mobilité

    État de l’art : formats existants et leurs limites

    1. Les formats propriétaires des plateformes télématiques

    Chaque acteur définit son propre format. On retrouve des exports en CSV, JSON ou XML, mais toujours différents dans leur structure, leurs unités, leurs fréquences.

    Ainsi :

    • La vitesse peut être exprimée en km/h, m/s ou mph, sans métadonnée claire.
    • Les événements (freinage, accélération) sont codés de manière hétérogène.
    • La fréquence d’échantillonnage varie de 1 Hz à 10 secondes, rendant toute comparaison difficile.

    2. Les formats de référence en mobilité

    De plus, plusieurs formats sont utilisés en mobilité :

    3. Les approches académiques

    En effet, les chercheurs publient leurs données en CSV ou Parquet, mais chaque dataset est structuré différemment. Impossible de bâtir un corpus commun reproductible.

    👉 En résumé : beaucoup de formats, aucun pivot.

    Panorama des sources actuelles : une dispersion problématique

    Au-delà des formats de référence (GTFS, MDS, NDS), il existe aujourd’hui une grande diversité de sources télématiques, chacune avec ses contraintes et formats. Cette dispersion rend l’intégration complexe et justifie la nécessité d’un pivot comme Telemachus standard télématique.

    1. Les plateformes SaaS B2B

    Des acteurs comme Geotab, Verizon Connect, Samsara ou Fleet Complete proposent des solutions complètes de gestion de flotte.

    Les données sont accessibles via des API JSON/REST propriétaires, avec des schémas spécifiques à chaque fournisseur.

    Les informations sont souvent limitées à des événements (démarrage, arrêt, freinage brusque), avec peu ou pas de granularité inertielle.

    👉 Problème : l’interopérabilité entre fournisseurs est quasi inexistante.

    2. Les OEM (constructeurs automobiles)

    Les constructeurs (BMW, Stellantis, Mercedes, etc.) proposent leurs propres portails connectés.

    Chaque marque définit ses variables (vitesse, consommation, diagnostic OBD-II) et son format.

    L’accès est généralement restreint et soumis à certification.

    👉 Problème : une absence d’harmonisation entre marques et un verrouillage fournisseur.

    3. Les boîtiers télématiques “bruts” (Teltonika, Queclink…)

    De nombreux opérateurs déploient des boîtiers OBD-II ou AVL comme Teltonika ou Queclink.

    Ces équipements génèrent des trames binaires riches (GNSS, parfois IMU intégrée), mais au format propriétaire.

    👉 Problème : un travail d’ingénierie lourd est nécessaire pour parser, interpréter et normaliser les données.

    4. Les plateformes cloud

    Des solutions comme AWS IoT FleetWise, Azure IoT Hub ou Google Cloud Mobility offrent des pipelines de collecte et d’analyse.

    Cependant, elles laissent les clients définir leurs propres schémas JSON, sans standard global.

    👉 Problème : une hétérogénéité persistante, simplement déplacée dans le cloud.

    En résumé, la dispersion des sources SaaS B2B, OEM et boîtiers bruts démontre qu’il est urgent de converger vers un
    standard unique et extensible : c’est précisément la vocation de Telemachus standard télématique.

    Telemachus : la philosophie d’un format pivot

    Telemachus s’inspire du succès du GTFS : créer une spécification ouverte, simple mais extensible, adoptable par tous.

    Principes fondamentaux

    1. Un format standardisé : une base commune décrivant trajectoire et contexte.
    2. Extensible : modules complémentaires (ex. Fleet Premium pour les flottes).
    3. Interopérable : facilite le passage d’un fournisseur à l’autre.
    4. Ouvert et documenté : hébergé publiquement, versionné, utilisable par chercheurs et industriels.

    Structure des données

    Le cœur de Telemachus repose sur :

    • Un fichier dataset.yaml décrivant le jeu de données (métadonnées, fréquence, capteurs).
    • Des tables normalisées : trajectory, imu, events, context.
    • Un modèle clair de timestamps unifiés, pour fusionner GNSS, IMU, météo, typologie routière.

    L’importance de l’IMU

    L’une des grandes innovations de Telemachus est de placer l’IMU (accéléromètres, gyroscopes) au cœur de la spécification.

    Pourquoi ?

    • Les capteurs GNSS seuls ne disent rien de l’inertie réelle du véhicule.
    • L’IMU capture les micro-événements : freinage brusque, dos d’âne, virage serré.
    • Couplée au GPS, elle permet une reconstruction fine et exploitable des trajets.

    👉 Telemachus considère donc l’IMU comme pilier fondateur du format.

    La continuité avec RoadSimulator3

    RoadSimulator3 (RS3) avait pour ambition de simuler des trajets véhicules réalistes :

    • Trajectoires GPS à 10 Hz
    • Inertie (accélérations, freinages)
    • Topographie et météo
    • Gyroscope et bruit stochastique

    Avec RS3, il est devenu possible de produire des jeux de données synthétiques complets.

    Mais restait une question : comment les stocker et les partager dans un format exploitable universellement ?

    👉 Telemachus est la réponse naturelle.

    Il fournit le conteneur standard qui permet de diffuser, comparer et réutiliser les données RS3 — mais aussi les données réelles issues de flottes.

    En clair :

    • RS3 = laboratoire de génération et validation.
    • Telemachus = standard d’échange et d’exploitation.

    Bénéfices pour les data scientists

    Avec Telemachus, un data scientist peut :

    • Charger un dataset dans pandas ou Spark sans passer des heures à mapper les colonnes.
    • Comparer des trajets de différentes sources car le schéma est homogène.
    • Fusionner simulation (RS3) et réel (flotte) dans un même pipeline.
    • Appliquer directement ses modèles de ML/IA sans réécriture fastidieuse.

    👉 Résultat : plus de temps pour la science, moins pour le nettoyage.

    Cas d’usage

    • Assurance : détection de comportements à risque calibrée par inertie + météo.
    • Smart city : référentiels de virages dangereux, zones de surconsommation énergétique.
    • Constructeurs automobiles : validation d’ADAS et conduite autonome sur datasets reproductibles.
    • Chercheurs : publications comparables et réplicables grâce à un format ouvert.

    Conclusion

    En combinant GNSS, IMU et événements de conduite, Telemachus devient la pierre angulaire de la télématique ouverte. Ce format pivot rapproche recherche, industrie et mobilité durable, tout en assurant transparence et interopérabilité.

    Références

    Illustration du Telemachus standard télématique pour les données véhicules

    👉 À lire aussi :
    – RoadSimulator3 : simulateur inertiel 10 Hz
    – Telemachus v0.2 – Structurer le standard ouvert de la donnée mobilité
    – Détection d’événements de conduite par IMU embarquée

  • 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

  • Fusion GNSS LIDAR inertielle véhicule : vers une localisation plus robuste

    Fusion GNSS LIDAR inertielle véhicule : vers une localisation plus robuste

    La fusion GNSS LIDAR inertielle véhicule devient essentielle dans les systèmes de navigation de véhicules autonomes. Dans cet article, nous explorons une nouvelle méthode proposée par Cheng et al. (2025) combinant odométrie LIDAR, pré-intégration IMU et positionnement GNSS dans un cadre unifié, afin d’obtenir une localisation robuste même en milieu urbain dense ou à haute vitesse.

    Pourquoi fusionner GNSS, IMU et LIDAR ?

    Les approches LIDAR ou visuelles seules souffrent de dérives cumulées lors de longues trajectoires ou de pertes de signal. Le GNSS, bien qu’imparfait en ville, apporte une référence globale utile pour corriger ces dérives. En couplant les trois sources, on obtient une estimation de pose plus fiable et continue.

    Une architecture modulaire efficace

    • Odométrie GNSS : utilisée pour initialiser ou relocaliser rapidement le système.
    • Pré-intégration IMU : fournit une estimation rapide de mouvement entre deux mesures.
    • Odométrie LIDAR avec Dynamic-ICP : méthode de recalage pointcloud plus rapide et robuste.
    • Filtrage IKF contraint : améliore l’estimation des angles d’attitude avec les vitesses GNSS.

    Résultats expérimentaux

    Testée sur les jeux de données KITTI et HK UrbanNav, la méthode réduit l’erreur RMSE de plus de 50 % par rapport à LOAM ou NDT. La fusion adaptative (équation 18 du papier) ajuste dynamiquement la pondération GNSS selon la fiabilité estimée.

    Intégration dans RoadSimulator3

    Cette approche de fusion GNSS LIDAR inertielle véhicule peut enrichir RoadSimulator3, en simulant des conditions de relocalisation, de cartes préalables, ou des environnements dégradés. Une implémentation réaliste du Dynamic-ICP serait un excellent test pour valider des stratégies de fusion multi-capteurs.

    🔗 Lire l’article complet sur arXiv
    🔗 Voir la thèse RoadSimulator3

    fusion GNSS LIDAR inertielle véhicule – schéma du système de localisation
    Figure – Schéma de la fusion GNSS-LIDAR-IMU (source : Cheng et al., 2025)

  • Auto-calibration inertielle sur smartphone : vers une fusion IMU-GPS fiable

    📱 Auto-calibration smartphone véhicule : une approche robuste sans magnétomètre

    La auto-calibration smartphone véhicule est un défi fondamental pour garantir la qualité des mesures
    inertielle embarquées. L’étude de Almazan et al. (2013) propose une solution ingénieuse, sans recours
    au magnétomètre, pour estimer automatiquement l’orientation du smartphone dans un véhicule en mouvement.

    🔍 Objectif : orienter le smartphone sans capteur magnétique

    Contrairement aux méthodes classiques dépendant du compas magnétique (souvent perturbé dans les habitacles),
    cette méthode exploite les signaux GPS et IMU (accéléromètre, gyroscope) intégrés au smartphone pour estimer
    dynamiquement l’orientation inertielle du téléphone, y compris le cap (lacet).

    ⚙️ Méthode de calibration inertielle embarquée

    Le cœur de l’approche repose sur une modélisation statistique avancée :

    • 📈 Suivi de l’accélération longitudinale du véhicule pour estimer l’axe principal
    • 🔄 Estimation de l’angle de lacet par ajustement d’un modèle de Gaussiennes mixtes
    • 🎯 Filtrage de Kalman pour combiner inertie et mouvement GPS, même sur routes inclinées

    🧪 Résultats : précision et robustesse en conditions réelles

    Les tests, réalisés sur route avec des iPhones non modifiés, montrent une précision élevée, même sans
    calibration manuelle ni accessoire externe. L’algorithme est robuste aux variations de pente, aux perturbations internes
    du véhicule et aux erreurs GPS classiques.

    🚗 Intégration dans RoadSimulator3

    Dans RoadSimulator3, cette technique permet de simuler des scénarios
    de mauvaise orientation ou de calibration dynamique. Cela renforce le réalisme des données simulées et permet de
    tester la résilience d’algorithmes de détection à des signaux faiblement calibrés.

    🔗 Article original

    Almazan et al., 2013 –

    doi.org/10.1109/IVS.2013.6629502

    auto-calibration smartphone véhicule

  • 📡 Fusion GNSS IMU autonome : une méthode fiable en 2024

    📡 Fusion GNSS IMU autonome : une méthode fiable en 2024

    La fusion GNSS IMU autonome est aujourd’hui une solution centrale pour améliorer la robustesse des systèmes de navigation embarqués. Dans leur publication “A Robust GNSS/IMU Fusion Approach Based on Vehicle Kinematics”, Alaba et al. (2024) démontrent comment combiner efficacement les données issues du GNSS et de l’IMU pour maintenir un positionnement précis dans les environnements urbains denses.

    🚗 Pourquoi la fusion GNSS IMU autonome est-elle cruciale ?

    Les zones dégradées, comme les canyons urbains ou les tunnels, perturbent souvent les signaux GNSS. La méthode proposée par Alaba repose sur un modèle cinématique du véhicule, intégrant les vitesses, accélérations et directions mesurées par les capteurs inertiels. Ce couplage renforce la continuité et la fiabilité de la localisation.

    🔍 Intégration dans RoadSimulator3

    Dans RoadSimulator3, intégrer une telle approche de fusion GNSS IMU autonome permettrait de simuler des pertes GNSS temporaires tout en maintenant une trajectoire réaliste. Cette avancée est essentielle pour évaluer la robustesse des algorithmes de navigation dans des conditions difficiles.

    🔗 Étude originale : Alaba et al., 2024 – arxiv.org/abs/2405.08119

    fusion GNSS IMU autonome

  • Détection d’Événements de Conduite par IMU : Vers une Intelligence Embarquée Fiable

    Introduction

    La détection d’événements de conduite par IMU est devenue un enjeu majeur pour les véhicules intelligents et la gestion des flottes. En effet, les capteurs inertiels embarqués, tels que les accéléromètres et gyroscopes, permettent d’identifier des événements clés comme les freinages brusques, virages agressifs ou accélérations soudaines.

    Ainsi, cette approche offre une solution pratique pour mesurer le risque conducteur directement via smartphone. De plus, elle ne nécessite ni connexion au cloud ni accès aux données CAN du véhicule. Par conséquent, elle favorise une intelligence embarquée autonome et fiable.

    Détection d'événements de conduite IMU – freinage, virage, accélération

    Pourquoi utiliser l’IMU

    L’unité de mesure inertielle (IMU) fonctionne indépendamment du GPS. Ainsi, elle reste opérationnelle même dans des environnements où le GPS est inopérant, comme les tunnels ou zones urbaines denses. Elle fournit des mesures précises et continues de l’accélération et de la rotation du véhicule.

    Cette autonomie permet de détecter les comportements dynamiques du conducteur sans dépendre d’une connexion externe. C’est un atout majeur pour les systèmes embarqués. En effet, cela est particulièrement utile dans le cadre de la prévention des risques et l’évaluation du style de conduite.

    Méthodologie Guo et al.

    L’étude de Guo et al. (“Driving Event Detection Using IMU Data”, 2021) illustre bien cette approche. Ils montrent que les données IMU — notamment acc_x, acc_y et acc_z — peuvent être analysées pour identifier précisément les événements de conduite.

    De plus, cette méthode permet de détecter des comportements spécifiques en temps réel. Elle utilise une fréquence d’échantillonnage adaptée aux besoins des applications embarquées.

    Applications pratiques

    Des outils comme RoadSimulator3 exploitent ces principes pour générer des événements de conduite réalistes à 10 Hz. En effet, cela fonctionne même dans des environnements simulés. Cela facilite le test et la validation des algorithmes sans risque sur route.

    👉 Découvrez aussi le simulateur inertiel RoadSimulator3 et la détection d’événements de conduite par deep learning.

    Liens et ressources

    Pour approfondir, consultez notre article sur la détection par deep learning. La page Wikipédia sur les IMU offre également un bon point de départ pour comprendre les bases techniques.

    Conclusion

    La détection d’événements de conduite via IMU embarquée ouvre de nombreuses perspectives pour les assureurs et la prévention routière. En effet, elle permet de suivre le style de conduite, promouvoir l’éco-conduite et détecter les risques en temps réel.

    Enfin, grâce à une intégration possible directement sur smartphone, cette technologie embarquée offre une solution accessible et efficace. Par conséquent, elle contribue à améliorer la sécurité des conducteurs et optimiser la gestion des flottes.