RoadSimulator3

Nos produits : RoadSimulator3 et ReadyData

Étiquette : Telemachus

  • Virtual sensing énergie : revue de Cellina et al. (2023) & perspectives RS3/Telemachus

    Virtual sensing énergie est une approche permettant d’estimer la consommation d’un véhicule à partir de signaux GNSS et IMU, sans accès direct au bus CAN. Cette page présente une revue détaillée de Cellina et al. (2023) et explique comment étendre cette méthode dans RoadSimulator3 et Telemachus.

    Virtual sensing GNSS/IMU : revue de Cellina et al. (2023) et perspectives industrielles

    Le virtual sensing énergie permet de mesurer la consommation sans accès CAN en utilisant uniquement vitesse et accélération issues du GNSS/IMU.

    Ressources associées :
    – Article RS3 sur la pente & énergie : https://roadsimulator3.fr/service-robuste-pente-altitude-10hz/
    – Documentation Telemachus : https://github.com/telemachus3/telemachus-spec
    – Publication originale (Cellina 2023) : https://arxiv.org/abs/2310.01230

    🎯 1. Contexte : mesurer la consommation… sans accéder au véhicule

    L’article part d’un constat clair :

    • Les véhicules thermiques resteront longtemps en circulation.
    • Les solutions embarquées (OBD, télématique constructeur) sont hétérogènes et non standardisées.
    • Un estimateur universel, basé sur des signaux GNSS + IMU, serait :
    • non intrusif,
    • compatible smartphone,
    • applicable à n’importe quel véhicule,
    • exploitable pour l’assurance, la mobilité, les inventaires carbone.

    Objectif : estimer la consommation instantanée et cumulée avec uniquement :
    – vitesse longitudinale v(t),
    – accélération longitudinale a(t).

    Ces signaux proviennent :
    – d’un GNSS 10 Hz,
    – d’une IMU 100 Hz (accélérations brutes).

    🚗 2. Protocole expérimental (véhicule réel + capteurs low-cost)

    Schéma du protocole expérimental GNSS/IMU utilisé pour le virtual sensing énergie

    L’article repose sur une expérimentation robuste :

    • Véhicule : Alfa Romeo Giulia diesel 2.2L, boîte auto 7 rapports.
    • Vérité terrain : fuel flow issu du CAN (20 Hz, résolution 0,001 L/h).
    • Capteurs externes :
    • Suchy XPro Nano 10,
    • GNSS 10 Hz + IMU 100 Hz montés rigidement sous le siège passager.

    Dataset :
    – 1493 km,
    – 20 h de conduite,
    – saisons été + hiver,
    – 1 à 4 passagers (tableau p.3 du PDF).

    Pré-traitements appliqués :
    – synchronisation à 10 Hz,
    – filtrage passe-bas à 3 Hz (zéro phase),
    – spline cubique pour recaler les signaux IMU/CAN sur l’horodatage GNSS.

    Modèles utilisés en virtual sensing énergie : PB, NN et VT-MICRO

    📦 3. Trois classes de modèles comparés

    3.1. VT-MICRO (référence historique, 32 paramètres)

    Modèle polynômial (3e ordre) séparé pour a≥0 et a<0.
    Limites connues :
    – comportement instable hors domaine d’entraînement,
    – ne supporte pas f=0 (ralenti, coupure d’injection),
    – forte sensibilité au bruit.

    3.2. Modèle Physics-Based (PB)

    Les auteurs dérivent une simplification du modèle longitudinal :

    f = k · ( m · a · v + α · v + β · v2 + γ · v3 )

    Le modèle final possède 4 paramètres seulement.
    Il force naturellement f≥0.

    Avantages :
    – interprétable,
    – robuste,
    – très bon sur les intégrales de consommation.

    3.3. Neural Network (NN)

    Architecture :
    – input : (v, a),
    – 1 couche cachée (9 neurones),
    – LBFGS + régularisation + multi-initialisations.

    C’est la méthode la plus performante sur l’instantané.

    📊 4. Résultats : qui gagne ?

    Modèle Testing Error (instantané) Integral Error (trajet) Error Over Tank (robustesse)
    VT-MICRO médiocre fort biais forte variance
    PB légèrement moins bon que NN ⭐ Meilleur (≈ 0 %) ⭐ Meilleur
    NN ⭐ Meilleur (écart-type −20 %) bonne performance mais léger biais négatif correct

    Synthèse

    • Instantané : NN > PB >> VT-MICRO
    • Cumulé : PB > NN > VT-MICRO
    • Robustesse “Error over Tank” : PB très largement en tête.

    Le modèle PB, pourtant simple, domine toutes les métriques cumulées, ce qui en fait un candidat idéal pour un système embarqué ou smartphone.

    🛑 5. Cas particulier : véhicule arrêté (“stopped car”)

    Problème :
    Lorsque v=0, le modèle statique ne peut pas distinguer :
    – moteur éteint → consommation nulle,
    – moteur allumé (ralenti) → consommation idle.

    L’article propose une solution innovante :

    🔍 Analyse fréquentielle du signal IMU (100 Hz)

    Observation (Figure 7 p.5) :
    – moteur au ralenti → pics à 13,3 Hz et 26,6 Hz,
    – moteur coupé → spectre beaucoup plus plat.

    Un simple classifieur sur le pic à 26,6 Hz donne :
    – 92 % TPR,
    – 92 % PPV.

    Limites :
    – dépend de la position de l’IMU,
    – dépend du véhicule → peu généralisable.

    🧭 6. Discussion critique

    ✔️ Forces de l’article

    • Méthodologie reproductible à partir de signaux simples.
    • Dataset riche (≈1500 km).
    • Comparaison honnête avec l’état de l’art.
    • Résultats solides : erreurs cumulées <1 %.
    • Orientation pratique : modèles embarquables.

    ⚠️ Limites

    • Un seul véhicule (diesel).
    • Entraînement effectué sur le même véhicule → pas de test “cross-vehicle”.
    • Pas de prise en compte explicite :
    • de la pente réelle (θ),
    • de la densité d’air (météo),
    • du style conducteur (agressivité inertielle),
    • des effets latéraux (virages / courbure).

    Or ces informations existent dans RS3 + Telemachus.

    ⚙️ 6.1. Conditions pratiques d’utilisation : ce qu’il faut (vraiment) pour appliquer le virtual sensing énergie

    L’article de Cellina et al. (2023) est particulièrement clair sur les prérequis indispensables pour obtenir une estimation énergétique fiable à partir des signaux GNSS/IMU.
    Ces éléments sont souvent implicites dans la littérature ; ils sont rappelés ici pour toute tentative de reproduction ou d’intégration dans un système réel.

    1. Fréquences minimales des capteurs

    • GNSS ≥ 5–10 Hz : nécessaire pour reconstruire correctement la vitesse v(t) sans dérive ni aliasing.
    • IMU ≥ 50–100 Hz : indispensable pour filtrer l’accélération longitudinale, détecter les vibrations moteur (13–26 Hz) et garantir la stabilité du modèle PB.

    En deçà :
    – GNSS 1 Hz → trop bruité pour dériver une énergie instantanée fiable.
    – IMU < 20–30 Hz → perte totale des signaux fréquentiels permettant la détection moteur ON/OFF.

    2. Pas besoin d’accès CAN ni d’abaque constructeur

    Le modèle PB ne nécessite ni couple moteur, ni débit d’injection, ni tables constructeur.
    Il repose uniquement sur :
    – v(t),
    – a(t),
    – m (masse du véhicule),
    – et 4 paramètres physiques (α, β, γ, k) calibrés sur quelques trajets.

    Cela rend l’approche :
    – non propriétaire,
    – compatible smartphone,
    – reproductible avec des capteurs low-cost.

    3. Un modèle spécifique au véhicule

    Le modèle PB doit être recalibré pour chaque véhicule.
    L’article ne traite pas encore la généralisation inter-véhicules :
    → une Giulia diesel et un SUV essence n’auraient pas les mêmes paramètres α, β, γ, k.

    4. Importance de la qualité GNSS

    Les auteurs filtrent v(t) via :
    – interpolation spline,
    – filtre passe-bas 3 Hz,
    – synchronisation stricte 10 Hz.

    Des coupures GNSS ou un bruit élevé dégradent fortement l’estimation énergétique instantanée.

    5. Limitations actuelles (hors périmètre de l’article)

    Le modèle ne prend pas encore en compte :
    – la pente réelle (θ),
    – la température / densité d’air,
    – la charge du véhicule,
    – le style conducteur,
    – la courbure routière,
    – les conditions GNSS dégradées.

    Ces dimensions sont critiques pour une industrialisation large, mais elles constituent précisément les axes où RS3 × Telemachus peuvent apporter une valeur unique.

    🔬 7. Perspectives RS3 × Telemachus

    1. Intégration dans RS3 : un banc d’essai idéal

    • Scénarios GNSS-denied,
    • Inerties contrôlées,
    • Pente + météo + masse variables.

    → possibilité de tester la robustesse hors distribution, ce que l’article ne couvre pas.

    2. Exploitation de la courbure routière (Heuts 2025)

    Les travaux récents (Heuts et al. 2025) montrent qu’un lien fort existe entre :
    – courbure κ,
    – énergie cinétique dissipée,
    – consommation.

    → RS3 permet de coupler v, a, κ → modèle hybride plus riche.

    3. Standardisation : Telemachus T002 “Energy Events”

    Les signaux nécessaires à la réplication du papier sont déjà standardisés :
    – speed
    – accel_longitudinal
    – engine_state (à enrichir via fréquence IMU)
    – energy_proxy (proposition)

    4. Possibilité d’un modèle unifié pour thermique + électrique

    Pour les VE :
    – puissance négative (régénération),
    – pas de ralenti,
    – relation non linéaire entre pédale et énergie.

    → PB et NN peuvent être adaptés.

    🚀 8. Que faire maintenant ?

    Voici les axes de développement immédiats pour RS3 :

    A. Implémenter le modèle PB dans RS3 / telemachus-py

    • 4 paramètres → calibration simple.
    • Benchmark sur scénarios RS3 générés automatiquement.

    B. Enrichir le modèle avec la pente réelle (IGN RGEALTI / SRTM)

    Cellina ignore θ, car absorbée dans le bruit de a.
    RS3 peut fournir θ exact → meilleure précision.

    C. Tester un réseau neuronal plus riche (MLP 2–3 couches)

    Avec :
    – normalisation temporelle,
    – features dérivées : jerk, power proxy, curvature.

    D. Construire un dataset public “Telemachus Energy Benchmark”

    • Données RS3 simulées (pente, météo, passagers),
    • Données smartphone (iPhone 4S du billet B012).
      → Permettra de tester la généralisation des modèles.

    ❓ 8.1. FAQ ingénieur — les questions clés pour reproduire le virtual sensing énergie

    1. Peut-on utiliser du GNSS 1 Hz comme dans la plupart des smartphones ?

    Non. À 1 Hz, la vitesse est trop bruitée et trop lente pour dériver correctement une énergie instantanée.
    → Minimum recommandé : 5–10 Hz.

    2. Une IMU 20–30 Hz suffit-elle ?

    Non pour la détection moteur ON/OFF (pics à 13–26 Hz).
    Partiellement oui pour la reconstruction de a(t).
    → Pour reproduire l’article : IMU ≥ 50–100 Hz.

    3. Faut-il connaître les paramètres moteur (couple, rendement, injection) ?

    Non. Le modèle PB utilise uniquement v(t), a(t), m et 4 paramètres calibrés.
    → Aucun accès CAN nécessaire.

    4. Le modèle PB est-il universel (un seul modèle pour toutes les voitures) ?

    Non. Il faut calibrer chaque véhicule.
    C’est une des limites majeures du papier.

    5. Comment traiter la pente si elle n’est pas fournie dans l’article ?

    Cellina absorbe la pente dans le bruit de a(t).
    Mais cela crée un biais dans les zones vallonnées.
    → RS3 + Telemachus peuvent fournir θ(t) pour améliorer fortement le modèle.

    6. Que se passe-t-il en cas de coupure GNSS ?

    Le modèle PB ne peut plus mettre à jour v(t).
    → Simulation RS3 recommandée pour tester robustesse GNSS-denied.

    7. Peut-on appliquer cette méthode aux véhicules électriques ?

    Partiellement.
    Le ralenti n’existe pas, et la régénération doit être modélisée.
    → Adaptation du modèle PB nécessaire.

    8. Comment vérifier si mon IMU capte bien les fréquences moteur ?

    Faire une FFT sur acc_x ou acc_y au ralenti.
    Si les pics à ~13 Hz et ~26 Hz n’apparaissent pas → mauvaise orientation, saturation, ou IMU trop lente.

    9. Quelles sont les extensions naturelles pour l’industrie ?

    • multi-véhicules
    • prise en compte pente / météo / charge
    • détection moteur robuste
    • standardisation des signaux (Telemachus)

    🧾 9. Conclusion

    L’article de Cellina et al. (2023) est une avancée majeure :
    il démontre qu’avec GNSS + IMU, on peut obtenir une estimation énergétique <1% d’erreur sans accès CAN.

    Cependant, de nombreuses pistes restent ouvertes :

    • généralisation multi-véhicules,
    • prise en compte de la pente,
    • meilleure détection moteur ON/OFF,
    • extension aux véhicules électriques,
    • standardisation des signaux (Telemachus).

    RS3 fournit déjà un environnement idéal pour pousser ces travaux plus loin — et ouvrir la voie à une mesure universelle de la consommation / énergie, à partir de données vraiment ouvertes, comparables et reproductibles.

    Si ce sujet vous intéresse, un article plus technique (P006) détaillera très prochainement l’intégration de ce modèle dans RS3 × Telemachus.

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