Auteur/autrice : Seb

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 + β · v² + γ · v³ )

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.

2025-12-04

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.

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 :

Approches analytiques classiques
Intégration des accélérations longitudinales après filtrage du biais gravitationnel.
Nécessite une calibration fine et un repérage stable du véhicule.
Sensible au drift cumulatif.
Approches basées apprentissage
Réseaux neuronaux (LSTM, CNN) entraînés sur des segments GNSS + IMU synchronisés.
Ainsi, ils sont capables de compenser le drift sur des courtes durées, mais nécessitent un jeu de données massif.
En revanche, ils sont peu généralisables entre véhicules et smartphones.
Méthodes hybrides
Utilisation de contraintes cinématiques (vitesse > 0, non-holonomie).
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.

2025-10-31

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.

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.

2025-10-31

Fusion GNSS/IMU robuste : le filtre à consensus MMKF

Illustration de la fusion GNSS/IMU via le filtre à consensus MMKF

Schéma de fusion GNSS/IMU avec le filtre à consensus MMKF

La fusion GNSS/IMU robuste est essentielle pour les véhicules autonomes et les systèmes de navigation avancés, qui nécessitent une estimation d’état fiable — position, vitesse, orientation — malgré la présence de bruit, de coupures GNSS ou d’environnements urbains complexes. La fusion GNSS/IMU permet ainsi d’obtenir des trajectoires précises et fiables.
Dans ce contexte, le Consensus Multi-Model Kalman Filter (MMKF) propose une approche hybride, à mi-chemin entre le modèle physique et les modèles data-driven.

1. Pourquoi un consensus multi-modèles ?

Les filtres de Kalman traditionnels (EKF, UKF) supposent une relation linéaire et des modèles de bruit stationnaires.
Or, dans la réalité :
– les conditions routières changent (revêtement, vibrations, braquage) ;
– les capteurs IMU et GNSS présentent des erreurs variables ;
– les dynamiques du véhicule ne sont pas toujours modélisables simplement.

Le MMKF propose de faire coopérer plusieurs modèles de filtrage, chacun optimisé pour un scénario (lignes droites, virages, pertes GNSS, accélérations brusques…), en établissant un consensus sur l’estimation finale.

2. Principe du filtre à consensus

Le filtre combine plusieurs sous-modèles :
1. Filtres spécialisés — chaque filtre représente une dynamique ou une hypothèse différente (par exemple, mouvement constant, virage, perte GNSS).
2. Mécanisme de consensus — les sorties des sous-filtres sont pondérées selon leur cohérence mutuelle et la qualité locale du signal.
3. Itération adaptative — les poids sont recalibrés à chaque pas de temps selon la divergence entre filtres (mesurée par la distance de Mahalanobis).

Formellement, le consensus combine les estimations partielles selon :
(\hat{x} = \sum_i w_i \hat{x}_i)
où (w_i) représentent les poids adaptatifs issus de la cohérence inter-modèles.

Ce consensus permet d’obtenir une estimation plus robuste sans nécessiter un seul modèle parfait.
C’est une approche multi-modèle coopérative, plus stable que les méthodes basées sur un filtre unique.

3. Comparaison avec les approches classiques

Approche	Hypothèse principale	Robustesse GNSS	Adaptation dynamique	Complexité
EKF classique	Modèle linéaire, bruit gaussien	Faible	Faible	Faible
UKF / RKF	Modèle non-linéaire	Moyenne	Moyenne	Moyenne
MMKF (Consensus)	Multi-modèles pondérés	Élevée	Forte	Modérée
DVSE (Deep Learning)	Apprentissage séquentiel	Très élevée	Très forte	Élevée

Le MMKF se situe ainsi entre la rigueur mathématique du Kalman et la souplesse des modèles d’apprentissage profond.
Il offre un compromis idéal pour les systèmes embarqués ou les pipelines hybrides RS3/Telemachus.

4. Implémentation dans RS3 / Telemachus

Dans le pipeline RS3 → Telemachus, le MMKF est intégré comme module de fusion inertielle :
– Entrées : GNSS, IMU, événements RS3, données simulées.
– Sorties : trajectoire estimée (position, vitesse, orientation) dans le format pivot Telemachus.
– Évaluation : RMSE, cohérence inertielle et dérive temporelle.

Les modules RS3 permettent de générer des séquences contrôlées de pertes GNSS (RFC-0009), tandis que Telemachus formalise les sorties au format JSON-Schema (RFC-0007).
Cette intégration garantit la reproductibilité et la comparabilité des filtres de fusion dans un cadre ouvert et documenté.

5. Liens avec les autres travaux

Liu et al. (2023) ont synthétisé les approches GNSS/INS, montrant que les modèles de fusion classique atteignent leurs limites dans les environnements dégradés.
Xiao et al. (2025) proposent DVSE, un réseau d’apprentissage profond qui vise à remplacer le filtre de Kalman.
Mafi et al. (2025) introduisent le consensus MMKF comme une solution intermédiaire, plus interprétable et calculable en temps réel.
Pour approfondir, voir également Données brutes 10 Hz et inertie véhicule.
Un article scientifique pertinent : https://arxiv.org/abs/2501.01234.

Dans ce cadre, RS3 et Telemachus constituent une plateforme d’expérimentation intégrée pour tester, comparer et documenter ces approches.

6. En résumé

Le Consensus MMKF marque une évolution majeure de la fusion multi-capteurs :
– combine le meilleur du monde physique et du monde data-driven ;
– s’intègre naturellement dans les pipelines RS3/Telemachus ;
– ouvre la voie à des validations reproductibles pour la mobilité intelligente.

Le consensus MMKF illustre la convergence entre méthodes analytiques et approches apprenantes.
Intégré dans RS3 et Telemachus, il constitue une base expérimentale solide pour la validation ouverte de filtres de fusion — un jalon vers une mobilité plus interprétable, robuste et transparente.

✳️ Références :
– Mafi, S. et al. (2025) — Consensus Multi-Model Kalman Filter for Robust Vehicle State Estimation.
– Liu, H. et al. (2023) — A Comprehensive Review of GNSS/INS Integration.
– Xiao, L. et al. (2025) — Deep learning-based Vehicle Speed Estimation via Smartphone IMU.
– RFC-0009 — Integration RS3 → Telemachus.

2025-10-31

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

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

2025-10-27

Telemachus v0.2 – Structurer le standard ouvert de la donnée mobilité en France 🚀

Telemachus standard mobilité (v0.2) marque une nouvelle étape dans la gouvernance ouverte de la donnée mobilité en France. Ce format pivot garantit transparence, interopérabilité et évolution communautaire.
Ce projet vise à harmoniser l’échange des données de mobilité à travers un système collaboratif de RFCs (Request for Comments). Ainsi, il garantit une évolution transparente et communautaire du standard.

Telemachus standard mobilité v0.2 – gouvernance ouverte du format Telemachus

🚀 Pourquoi un système de RFCs ?

Un standard vivant doit s’appuyer sur une gouvernance claire et un processus transparent.
De plus, le système de RFCs permet de :

Documenter précisément chaque évolution du format ;
Ouvrir la discussion à la communauté ;
Assurer la traçabilité des décisions ;
Structurer l’évolution du standard avec rigueur.

En effet, cette approche s’inspire des meilleures pratiques de l’IETF, d’OpenTelemetry ou encore de l’OGC.

📦 Les RFCs de la version 0.2

La version 0.2 introduit plusieurs RFCs fondamentaux :

RFC	Titre	Statut	Lien
0001	Telemachus Core 0.2	Accepté	Lien
0003	Dataset Specification 0.2	Accepté	Lien
0004	Extended FieldGroups Schema	Accepté	Lien
0005	Adapter Architecture	Accepté	Lien
0007	Validation Framework & CLI Rules	Accepté	Lien
0009	RS3 Integration Pipeline	Accepté	Lien
0011	Versioning & Governance Policy	Accepté	Lien

🗂️ Retrouvez l’ensemble des documents sur GitHub :
telemachus3/telemachus-spec

🔧 Un standard modulaire, compatible et validable

RS3 génère les données brutes (IMU, GPS, vitesse…).
Adapters traduisent les données industrielles (Webfleet, Samsara, Teltonika…).
Schemas garantissent la cohérence entre jeux de données.
Validator contrôle les alignements temporels, unités et complétude.

Par conséquent, cette approche transforme Telemachus en un véritable langage pivot entre simulation, télématique industrielle et recherche scientifique.

🧠 Un projet de standard, pas une simple bibliothèque

Avec le système de RFCs, Telemachus change d’échelle. Ce n’est plus seulement une librairie Python ou un dataset. En effet, c’est une spécification documentée et gouvernée.

Le processus se déroule ainsi :
1. Proposée — la RFC est en Draft.
2. Discutée — une issue publique est ouverte sur GitHub.
3. Implémentée — dans le code ou les schémas.
4. Publiée — dans une version officielle du standard.

Ce processus garantit la pérennité, la traçabilité et la crédibilité du format dans l’écosystème mobilité.

🗓 Et maintenant ?

Renforcement de la validation sémantique (RFC-0007).
Génération automatique des schémas JSON à partir des RFCs.
Gouvernance ouverte (RFC-0011) et participation communautaire.
Extension vers les données temps réel et les futures APIs constructeurs.

📘 Une nouvelle release Telemachus Spec v0.3 regroupera ces évolutions au premier semestre 2026.

💬 Rejoignez la discussion

💬 Discussions publiques sur GitHub :
RFC Discussions – telemachus3/telemachus-spec

🌍 Documentation officielle :
telemachus3.github.io/telemachus-spec

🔗 Articles internes :
RoadSimulator3.fr |
Référentiel virages OSM vs IGN

En s’appuyant sur un système de RFCs transparent et communautaire, Telemachus établit une gouvernance solide pour la donnée mobilité. Ce modèle collaboratif garantit la compatibilité, la traçabilité et la continuité du standard dans le temps.

✍️ Auteur

Sébastien Edet — Créateur du simulateur RoadSimulator3 (RS3) et du standard Telemachus

2025-10-13

🧩 Telemachus RFC-0001 : les 10 axes d’évolution du format vers la v0.2
🧩 Telemachus RFC-0001 — Les 10 axes d’évolution du format vers la v0.2

En septembre, nous avons publié le premier jeu de données Telemachus, aligné sur la spécification v0.1-alpha.
Cette version posait les bases du format : GNSS, mouvement, IMU, moteur, qualité et contexte — pour relier les données issues de la simulation (RS3) et celles collectées sur le terrain.

Aujourd’hui, nous franchissons une nouvelle étape : la normalisation ouverte du format lui-même.
C’est tout l’objet de la RFC-0001 – Telemachus Core v0.2, désormais ouverte à commentaires sur GitHub.

🧭 Pourquoi une RFC ?

Telemachus n’est pas qu’un format de fichier : c’est un langage commun pour la donnée de mobilité haute fréquence.

Afin d’en faire évoluer la structure de façon transparente, nous adoptons un processus inspiré du web ouvert : la RFC (Request for Comments).
L’objectif :

Faire de Telemachus v0.2 un format modulaire, interopérable et analytique, capable d’unifier des données issues de simulateurs, de flottes réelles et de sources contextuelles.

⚙️ Les 10 axes d’évolution

1️⃣ Modularisation & Profils

Découper le schéma en blocs réutilisables (Position, Motion, IMU, Engine, etc.) et introduire la notion de profil :
core, fleet, simulated, contextual.
👉 Chaque fournisseur pourra ainsi ne valider que les champs pertinents à son cas d’usage.

2️⃣ Temps & Fréquence
- Support des horodatages haute précision (timestamp_ns)
- Synchronisation multi-capteurs (GNSS, IMU, CAN)
- Gestion d’un sample_idx pour les séries haute fréquence
🎯 Objectif : une cohérence temporelle robuste entre les signaux.

3️⃣ Véhicule & Chaîne de traction
```
"powertrain": {
  "engine": {"rpm": 2500, "load_pct": 70},
  "ev": {"soc_pct": 82.5, "power_kw": 45.2},
  "hybrid_mode": "charge-sustain"
}
```
🔋 Compatible thermique, électrique et hybride – pour des analyses multi-flottes.

4️⃣ Trajectoire & Géométrie

Nouveau bloc trajectory :
curvature_radm, radius_m, road_class, segment_id, lane_count…
→ un lien direct avec les travaux Road Genome sur la géométrie routière.

5️⃣ Contexte enrichi

Évolution du bloc context en enrichments :
- weather : température, vent, précipitations, visibilité
- road : surface, friction, vitesse limite
- environment : altitude, type de zone, densité urbaine
Chaque source inclut un niveau de confiance.

6️⃣ Provenance & Confiance

Renommer source → provenance et ajouter :
provider, firmware, sampling_strategy, fusion_level, confidence.
🔗 Chaque donnée devient traçable de bout en bout.

7️⃣ Données dérivées & Labels
```
"derived": {
  "jerk_ms3": "number",
  "yaw_rate_rads": "number",
  "curvature_rate": "number"
},
"labels": {
  "road_type": "string",
  "maneuver": "string",
  "driver_behavior": "string",
  "event_type": "string"
}
```
Le premier regroupe les variables calculées automatiquement,
le second les annotations sémantiques (type de route, comportement, manœuvre).
🧠 Ensemble, ils créent le lien entre physique et interprétation — indispensables pour l’IA et les analyses comportementales.

8️⃣ Métadonnées de simulation
```
"simulator": {
  "name": "RS3",
  "version": "3.2",
  "seed": 1234,
  "noise_model": "gaussian"
}
```
🎮 Permet de documenter la génération synthétique et la traçabilité scientifique.

9️⃣ Validation & Conformité
- validation_flags : indicateurs de cohérence (gps_fix_ok, imu_dropout…)
- privacy : anonymisation / hachage des identifiants
- license : obligatoire pour tout dataset public (CC-BY-4.0, ODbL…)
🔟 Interopérabilité & Manifest

Fichier compagnon manifest.json décrivant :
version du schéma, fréquence, couverture spatio-temporelle, sources et licence.
🧩 Compatible avec OGC SensorThings, OpenTelemetry et ISO 39030.

🧠 Un format pivot, entre science et industrie

Telemachus v0.2 comble le vide entre :
- les données simulées (RS3, Road Genome, études d’inertie),
- les données réelles issues de flottes connectées.
En introduisant une sémantique commune et une traçabilité claire, Telemachus vise à devenir un standard pivot pour la mobility data européenne, ouverte et vérifiable.

🤝 Appel à contribution

La RFC-0001 est ouverte à discussion publique sur GitHub 👇

➡️ Participer à la discussion officielle

Prochaines étapes
1. Validation collective des 10 axes
2. Publication du schéma telemachus-core-0.2-draft.json
3. Tests sur de nouveaux jeux de données (RS3 + réels)
4. Mise à jour du validateur Python telemachus-py
📎 Ressources
- 📘 RFC-0001 – Discussion GitHub
- 📄 Spécification Telemachus v0.1-alpha
- 📊 Jeu de données Telemachus v1.0
- 🚗 Projet RoadSimulator3
- 🧮 Article : Référentiel des virages OSM vs IGN
✍️ En résumé

Telemachus RFC-0001 marque le passage d’un format expérimental à une spécification ouverte et contributive.
C’est une étape clé pour structurer, partager et valoriser les données de mobilité à haute fréquence — au service de la recherche, de la simulation et des écosystèmes industriels.
2025-10-10
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.

É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é :
- GTFS : a révolutionné le transport public, mais ne couvre pas la télématique véhicule individuelle.
- MDS (Mobility Data Specification) : orienté micro-mobilité (trottinettes, vélos), mais limité.
- NDS (Navigation Data Standard) : centré sur la cartographie, sans granularité inertielle.
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
👉 À 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
2025-09-30
🚗 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.

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.

2025-09-23
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.

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

2025-09-17

Auteur/autrice : Seb

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

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

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

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

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

3.2. Modèle Physics-Based (PB)

3.3. Neural Network (NN)

📊 4. Résultats : qui gagne ?

Synthèse

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

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

🧭 6. Discussion critique

✔️ Forces de l’article

⚠️ Limites

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

1. Fréquences minimales des capteurs

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

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

4. Importance de la qualité GNSS

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

🔬 7. Perspectives RS3 × Telemachus

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

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

3. Standardisation : Telemachus T002 “Energy Events”

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

🚀 8. Que faire maintenant ?

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

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

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

D. Construire un dataset public “Telemachus Energy Benchmark”

❓ 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 ?

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

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

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

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

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

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

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

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

🧾 9. Conclusion

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

Objectif

Contexte

Méthodes étudiées

Approche DVSE (SmartphoneIMUSpeed2025)

Données et simulation RS3

Limites observées

Perspectives

Liens avec RS3 et Telemachus

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

1. IMUSim et la simulation inertielle GNSS/IMU

2. Architecture et fonctionnement

3. Liens avec RS3 et Telemachus

4. Pourquoi c’est encore pertinent ?

5. En résumé

Fusion GNSS/IMU robuste : le filtre à consensus MMKF

1. Pourquoi un consensus multi-modèles ?

2. Principe du filtre à consensus

3. Comparaison avec les approches classiques

4. Implémentation dans RS3 / Telemachus

5. Liens avec les autres travaux

6. En résumé

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

De quoi parle le papier original ?

Schéma conceptuel du filtrage invariant GNSS IMU

Application du filtrage invariant GNSS IMU à RS3 et Telemachus

Perspectives

Complément scientifique

🚀 Pourquoi un système de RFCs ?

📦 Les RFCs de la version 0.2

🔧 Un standard modulaire, compatible et validable

🧠 Un projet de standard, pas une simple bibliothèque

🗓 Et maintenant ?

💬 Rejoignez la discussion

🧩 Telemachus RFC-0001 — Les 10 axes d’évolution du format vers la v0.2

🧭 Pourquoi une RFC ?

⚙️ Les 10 axes d’évolution

1️⃣ Modularisation & Profils