4  Chapitre 02

5 Chapitre 2 : Fondements théoriques

5.1 2.0 – Fondements scientifiques de la simulation de trajectoires

La simulation réaliste de trajectoires de véhicules à haute fréquence repose sur des fondements scientifiques solides en navigation, télématique, fusion de capteurs et traitement des données inertielle. Ce chapitre expose les fondements scientifiques indispensables à la compréhension du fonctionnement des capteurs embarqués, des méthodes de localisation, et des approches utilisées pour détecter et classer les événements dynamiques rencontrés lors des trajets routiers.

Dans le cadre du projet RoadSimulator3, ces fondements constituent l’assise théorique permettant de :

  • reconstruire des trajectoires spatio-temporelles réalistes en conditions simulées,
  • injecter et détecter des événements inertiels de manière reproductible,
  • simuler le comportement de différents capteurs (GPS, IMU) avec un bruit représentatif des dispositifs réels,
  • et garantir la cohérence physique, inertielle et contextuelle des données synthétiques produites.

Ce chapitre est structuré en plusieurs sections couvrant :

  • Les systèmes de navigation (GPS, GNSS, fusion IMU-GNSS) et leur application dans la télématique embarquée.
  • Les modèles de calibration, de bruit et d’erreurs systématiques et aléatoires liés aux capteurs inertiels (IMU), essentiels à une simulation crédible.
  • Les algorithmes de détection et de classification inertielle, utilisés pour identifier les événements caractéristiques (freinage, dos d’âne, etc.).
  • Les limites des approches classiques et les apports méthodologiques de RoadSimulator3, positionnés dans le paysage scientifique existant.

L’objectif est d’ancrer rigoureusement la démarche dans les courants scientifiques actuels, tout en justifiant les choix de conception opérés dans la suite de la thèse. Ces éléments constituent le socle théorique sur lequel s’appuient les modules de simulation et d’analyse développés dans les chapitres suivants.

5.2 Systèmes de navigation et télématique véhicules

5.2.1 2.1 – Systèmes de navigation et télématique

Les systèmes de navigation embarqués et les technologies télématiques constituent des composants essentiels de la mobilité intelligente. Ils permettent le suivi précis de la position, de la trajectoire et du comportement dynamique d’un véhicule à des fins de navigation autonome, de monitoring en temps réel, ou de maintenance prédictive. Leur compréhension constitue un prérequis essentiel à toute simulation réaliste, notamment dans le cadre du projet RoadSimulator3, qui repose sur une modélisation fine du comportement inertiel des véhicules.

5.2.2 Technologies GNSS et estimation de position

Les systèmes de positionnement reposent principalement sur le GNSS (Global Navigation Satellite System), englobant les constellations GPS (États-Unis), GLONASS (Russie), Galileo (UE) et Beidou (Chine). En condition nominale, ces systèmes offrent une précision de 3 à 10 mètres, mais cette précision demeure insuffisante pour les applications exigeant une reconstruction fine et continue de la dynamique du véhicule (ADAS, conduite autonome, scoring conducteur).

Les publications récentes insistent sur les limites du GNSS seul dans les environnements urbains denses ou souterrains, et soulignent l’intérêt d’une fusion robuste avec d’autres capteurs inertiels ou visuels.

Des techniques de rehaussement de la précision sont utilisées :

  • RTK (Real-Time Kinematic) : correction différentielle centimétrique.
  • Fusion avec capteurs inertiels : amélioration de la robustesse en environnements dégradés (tunnels, canyons urbains).
  • Cartographie HD et matching : alignement des positions avec un graphe routier précis.

Des approches récentes comme celle de Alaba et al. (2024) (Alaba, Zhang, and Yu 2023) ou Nagui et al. (2021) (Nagui and Farag 2021) exploitent des schémas de fusion GPS-IMU fondés sur des filtres de Kalman faiblement couplés pour améliorer la localisation dans des contextes GNSS dégradés.

Ces approches sont souvent combinées avec des algorithmes d’estimation améliorés, comme les filtres de Kalman étendus (EKF) ou les filtres particulaires (PF), voire des architectures hybrides mêlant deep learning et modèles bayésiens (Dong, Ren, and Zhou 2022; Kim, Lee, and Park 2021).

Ces méthodes trouvent une pertinence particulière dans le cas de trajets urbains ou semi-structurés, où les capteurs GNSS sont sujets à des obstructions fréquentes.

5.2.3 Rôle de la télématique embarquée

La télématique intègre des capteurs et des modules de communication embarqués pour :

  • Transmettre les données dynamiques du véhicule (lat, lon, vitesses, accélérations, événements, etc.).
  • Surveiller l’état mécanique et les événements de conduite.
  • Alimenter des bases de données pour la maintenance prédictive ou le profilage comportemental.

Les données sont transmises via des réseaux cellulaires (3G/4G/5G), V2X (Vehicle-to-Everything), ou par satellite, vers des plateformes cloud assurant le traitement en temps réel.

Les travaux comme Krol et al. (2021) et Fan et al. (2019) (Krol and De Weerdt 2021; Fan, Wang, and Liu 2019) montrent que l’analyse télématique est désormais incontournable pour :

  • le fleet management intelligent,

  • la prévention des risques,

  • ou la gestion énergétique dans les véhicules électriques.

Ces avancées renforcent la convergence entre les données embarquées et les systèmes d’aide à la décision distribués.

5.2.4 Données capteurs et typologie

Les signaux couramment exploités dans les plateformes télématiques sont :

Donnée Description
lat, lon Coordonnées GNSS
speed, heading Vitesse instantanée, cap
acc_x, acc_y, acc_z Accélérations sur les 3 axes de l’IMU
gyro_x, gyro_y, gyro_z Vitesses angulaires (gyroscope)
event Événements de conduite détectés

5.2.5 Enjeux pour la simulation

Dans le contexte de la simulation réaliste de trajectoires, plusieurs exigences s’imposent :

  • Synchronisation des données capteurs à une fréquence élevée (10 Hz),
  • Cohérence spatio-temporelle entre GPS et IMU,
  • Modélisation des incertitudes pour simuler des scénarios dégradés,
  • Injection d’événements inertiels caractéristiques (freinage, dos d’âne, virage).
  • Exploration de modèles de fusion adaptatifs pour reproduire les pertes de signal et les dérives réalistes observées sur les capteurs MEMS de faible coût.

Ces enjeux justifient l’approche adoptée dans RoadSimulator3, où les données GPS/IMU sont synthétisées et annotées, afin de :

  • Créer des jeux de données fidèles,
  • Tester la robustesse d’algorithmes embarqués (détection, fusion),
  • Offrir un environnement expérimental contrôlé pour le développement, le test et la validation d’algorithmes.

5.3 Génération de trajectoires via OSRM / OSM

La présente section prolonge la réflexion amorcée en 2.1 sur les systèmes de navigation embarqués, en se focalisant ici sur les aspects géographiques de la simulation de trajectoires. La génération de trajectoires réalistes constitue un préalable fondamental à toute simulation dynamique de véhicule. Elle conditionne la cohérence spatiale des déplacements simulés et leur adéquation aux réseaux routiers existants. Dans ce contexte, l’utilisation combinée d’OpenStreetMap (OSM) pour les données cartographiques et de l’Open Source Routing Machine (OSRM) pour le calcul d’itinéraires offre une solution libre, robuste et modulaire.

5.3.1 OpenStreetMap (OSM) : cartographie collaborative

OpenStreetMap est une base de données cartographique participative décrivant les infrastructures routières avec une granularité fine. Elle offre :

  • Une hiérarchie typologique des routes (highway=*), allant de motorway à residential.
  • Des attributs tels que la vitesse maximale (maxspeed), le nombre de voies, les limitations de poids ou la présence de feux, ronds-points, dos d’âne, etc.
  • Une mise à jour continue, assurant une meilleure fraîcheur que certains jeux de données propriétaires.

La richesse sémantique d’OSM permet de caractériser finement chaque segment routier, notamment via :

La figure suivante illustre la répartition typologique des routes détectées dans les trajets simulés. Elle est extraite des métadonnées OSM (tag highway=*) enrichies automatiquement via OSMnx.

Répartition des types de route dans la simulation
  • Le type de surface (asphalt, paved, gravel, etc.),
  • La topologie locale (intersections, ronds-points),
  • Des annotations spécifiques (zones 30, zones piétonnes, etc.).

Ces éléments sont essentiels pour :

  • Ajuster la vitesse simulée en fonction du contexte routier,
  • Injecter des événements inertiels cohérents (ex. dos d’âne dans zones résidentielles),
  • Simuler des arrêts plausibles à proximité de POI.

5.3.2 OSRM : moteur de routage rapide et modulaire

OSRM (Open Source Routing Machine) est un moteur de calcul d’itinéraires ultra-rapide basé sur des données OSM prétraitées. Il fonctionne sur la base d’un graphe routier compressé avec hiérarchie et contraction, ce qui permet :

  • Le calcul de trajets très rapide (en millisecondes),
  • La génération d’une polyline GPS avec distances, durées, vitesses,
  • L’accès à des informations intermédiaires comme les ronds-points, intersections, ou changements de type de route.

Dans le cadre de RoadSimulator3, OSRM est utilisé en mode serveur local Dockerisé, avec les options suivantes :

  • Calculs d’itinéraires car sur graphe pré-indexé (France ou Normandie).
  • Export des coordonnées géographiques à pas régulier (~1 point tous les 0.83 m).
  • Interpolation de la trajectoire à 10 Hz avec distances, vitesses et headings.

Ces trajectoires brutes constituent le point de départ d’un enrichissement topographique et sémantique indispensable à la cohérence inertielle de la simulation.

5.3.3 Interpolation spatiale et enrichissement sémantique

Le simple export des coordonnées ne suffit pas pour une simulation réaliste. Une interpolation à pas constant est nécessaire pour :

La prise en compte de la topographie est essentielle pour simuler des effets dynamiques réalistes. Le modèle numérique de terrain (SRTM ou IGN) permet de reconstituer les altitudes successives, à partir desquelles la pente locale est calculée. Ces pentes influencent directement l’accélération longitudinale simulée (\(acc_x\)) et peuvent induire des faux positifs si elles ne sont pas correctement modélisées. Une correction gravitationnelle est donc appliquée pour distinguer les efforts moteurs réels des effets liés à l’inclinaison du terrain.

  • Simuler un mouvement continu à fréquence fixe (10 Hz),
  • Maintenir une distance constante entre les points (ex : 0.83 m → 30 km/h),
  • Garantir la synchronisation des données IMU/GPS.

L’enrichissement via OSM permet ensuite d’ajouter :

  • La pente locale, via l’altitude et le modèle numérique de terrain (MNT IGN, SRTM).
  • Le type de route (road_type), via les tags OSM highway=*.
  • La sinuosité, calculée à partir de la courbure locale.

Ces enrichissements conditionnent les phases ultérieures :

  • Modulation de la vitesse cible selon la typologie routière.
  • Injection réaliste d’événements inertiels dans les zones propices.
  • Validation du comportement dynamique via la dérivée de heading (virages, ronds-points).

La sinuosité locale est évaluée par une analyse de la courbure à partir des variations de heading. Elle est utilisée pour moduler la vitesse cible du véhicule et enrichir la dynamique latérale (acc_y). Les routes très sinueuses entraînent une baisse anticipée de la vitesse de croisière simulée. Ces éléments topologiques sont extraits directement via OSRM et OSMnx.

5.3.4 Détection des structures caractéristiques : ronds-points, intersections

OSRM fournit également des métadonnées d’itinéraire (via l’option steps) qui permettent :

  • D’identifier les ronds-points traversés,
  • De localiser les changements de direction, les jonctions complexes ou les manœuvres critiques,
  • D’adapter la signature inertielle simulée (ex. virage ↔︎ accélération latérale).

Ces informations sont exploitées dans RoadSimulator3 pour :

  • Confirmer ou corriger les événements détectés inertiellement (ex. virage réel vs artefact),
  • Ajouter du réalisme gyroscopique (modulation de gyro_z),
  • Structurer les pauses et livraisons (choix de routes secondaires, proximité des POI).

5.3.5 Effets de la pente et de l’altitude sur la dynamique

💡 Résumé : Effets de la pente sur la dynamique

  • Une pente ascendante ↗️ réduit la vitesse et exige une plus grande force motrice.
  • Une pente descendante ↘️ induit une accélération apparente même sans action moteur.
  • La gravité agit sur l’axe longitudinal et perturbe l’interprétation des données IMU.
  • Une correction gravitationnelle (\(a_x^{corr} = a_x + g \cdot \sin(\theta)\)) est nécessaire.
  • Cette correction évite de fausses détections d’événements inertiels (ex. freinage).
  • La prise en compte de ces effets est cruciale pour éviter les artefacts de détection inertielle.

Les variations d’altitude et de pente ont un impact direct sur la dynamique longitudinale du véhicule. Une pente ascendante ou descendante modifie l’effort moteur requis et se traduit par une accélération apparente dans l’axe longitudinal (\(acc_x\)), même à vitesse constante.

Correction gravitationnelle

L’accélération mesurée par l’IMU dans l’axe \(x\) doit être corrigée de l’effet de la pente selon : \[ a_x^{corr} = a_x + g \cdot \sin(\theta) \] où :

  • \(g\) est l’accélération gravitationnelle (\(9.81, m/s^2\)),
  • \(\theta\) est l’angle de la pente locale (exprimé en radians),
  • \(a_x^{corr}\) est l’accélération réelle nette due au mouvement.

Intégration dans la simulation

Le simulateur RoadSimulator3 récupère les données d’altitude via un modèle numérique de terrain (SRTM ou autre) et calcule la pente entre deux points GPS successifs. Ces informations permettent de :

  • Adapter l’accélération simulée dans les montées ou descentes.
  • Corriger les événements inertiels détectés pour distinguer un freinage réel d’une simple descente.
  • Améliorer la cohérence physique des données IMU, en particulier sur les routes vallonnées ou montagneuses.

5.3.6 Conclusion

La combinaison OSRM + OSM fournit un socle cartographique cohérent, riche et performant pour la génération de trajectoires simulées. Elle permet de construire des scénarios :

  • Géographiquement crédibles (itinéraires valides, continus),
  • Typologiquement informés (vitesse, sinuosité, pente),
  • Riches en annotations comportementales (ronds-points, intersections, POI).

L’enrichissement topographique (pente, sinuosité, altitude) permet d’obtenir une simulation inertielle plus réaliste et cohérente, notamment en environnement vallonné.

Elle constitue ainsi le noyau géospatial du simulateur RoadSimulator3, garantissant une base solide pour l’injection d’événements inertiels, la validation dynamique et la production de jeux de données synthétiques pour la recherche et l’industrie. Ce socle géospatial, une fois enrichi, servira de base aux phases suivantes d’injection d’événements inertiels (chapitre 4) et d’analyse de détection (chapitre 5).

5.4 Modèles de dynamique et simulation inertielle

La génération d’une trajectoire géographique ne suffit pas à reproduire fidèlement les dynamiques véhiculaires. Pour simuler un comportement réaliste, il est nécessaire d’intégrer un modèle de dynamique du véhicule, capable de générer des accélérations linéaires et angulaires cohérentes avec le contexte routier, les lois physiques et le style de conduite simulé. Ce couplage assure une cohérence spatio-temporelle entre les mouvements du véhicule et les signaux IMU simulés.

5.4.1 Dynamique longitudinale (accélération et freinage)

La dynamique longitudinale est modélisée à partir de la vitesse cible définie par le contexte :

  • Type de route (extrait d’OSM),
  • Niveau de sinuosité,
  • Position relative à un événement (arrêt, virage, obstacle).

L’accélération longitudinale simulée suit une forme continue avec trois phases principales :

  1. Accélération initiale (démarrage du véhicule),
  2. Phase de croisière avec légères oscillations pour reproduire les ajustements du conducteur,
  3. Décélération progressive ou événementielle (ex. : freinage brusque, arrivée à un stop).

Chaque transition respecte une contrainte d’accélération maximale réaliste (typiquement ±3 m/s²) et un ajustement progressif de la vitesse selon une interpolation contrôlée. Ces profils sont décrits plus en détail dans la section 4 sur l’injection des événements inertiels.

5.4.2 Dynamique latérale (virages, ronds-points)

L’accélération latérale \(a_y\) est simulée à partir du rayon de courbure de la trajectoire. En utilisant la formule : \[ a_y = \frac{v^2}{R} \] où \(v\) est la vitesse instantanée et \(R\) le rayon du virage estimé, il est possible de reproduire les efforts latéraux exercés sur le véhicule.

Les virages, ronds-points et changements de direction détectés via OSRM sont enrichis par cette modélisation. Le simulateur applique des contraintes pour éviter des accélérations latérales irréalistes (> 3 m/s² à 50 km/h). Cette accélération latérale est également convertie en vitesse angulaire simulée sur l’axe vertical (gyro_z), ce qui permet de détecter les virages dans le signal gyroscopique.

5.4.3 Dynamique verticale (anomalies de la route)

L’accélération verticale \(a_z\) est simulée principalement dans les cas suivants :

  • Franchissements de dos d’âne (modèle impulsionnel haut puis creux),
  • Passage sur trottoir (choc vertical + latéral),
  • Nid de poule (impulsion verticale rapide).

Les signatures sont injectées sous forme de profils inertiels réalistes (0.3 à 1 s) et bruités par des modèles de capteurs MEMS (cf. section 1.2). Voir aussi les signatures typiques en acc_z dans la section 4.3.

5.4.4 Bruit inertiel et incertitude

Chaque signal inertiel simulé est bruité à l’aide de modèles stochastiques :

  • Bruit blanc (gaussien),
  • Bruit coloré (flicker, random walk),
  • Biais simulés (offset variable),
  • Modèles appris (AirIMU – Qiu et al., 2023).

Ces bruits permettent d’imiter le comportement des capteurs de différentes gammes (low-cost vs automotive-grade), et de tester la robustesse des algorithmes de détection.

5.4.5 Simulation gyroscopique

Les vitesses angulaires (gyro_x, gyro_y, gyro_z) sont simulées à partir :

  • Des changements de direction sur la trajectoire,
  • Des rotations du véhicule autour de son axe vertical,
  • Des mouvements liés aux virages ou obstacles verticaux.

La simulation respecte les contraintes d’amplitude (typiquement inférieures à 15 °/s) et introduit des variations nettes lors de manœuvres marquées comme les ronds-points ou les virages serrés.

5.4.6 Résumé des composantes dynamiques simulées

Signal Source / Modèle Exemple d’événement
acc_x Variation de vitesse / freinage / pente Freinage brusque
acc_y Courbure de trajectoire (R) Virage serré
acc_z Anomalies verticales / bruit inertiel Dos d’âne, nid de poule
gyro_x/y/z Dérivée de la direction / vibration Rond-point, obstacles

5.4.7 Conclusion

Cette modélisation dynamique complète permet de générer des jeux de données riches et cohérents, capables de reproduire fidèlement le comportement inertiel d’un véhicule. Les trajectoires générées sont ainsi utilisables pour :

  • La détection et classification d’événements,
  • La validation d’algorithmes de fusion GPS/IMU,
  • L’analyse comportementale et la maintenance prédictive.

5.5 Simulation gyroscopique et dynamique angulaire

La modélisation des vitesses de rotation autour des trois axes (\(\omega_x\), \(\omega_y\), \(\omega_z\)) est une composante essentielle de la simulation inertielle complète. Elle permet de reproduire fidèlement les effets dynamiques angulaires associés à la trajectoire du véhicule, en particulier dans les contextes de virage, de rond-point, de franchissement d’obstacles ou de manœuvres spécifiques (stationnement, demi-tour, changement de voie).

Cette section s’inscrit dans la continuité de la modélisation inertielle abordée précédemment, en étendant l’analyse aux composantes angulaires.

5.5.1 Rappel sur les composantes gyroscopiques

Une unité de mesure inertielle (IMU) complète mesure non seulement les accélérations linéaires (\(a_x\), \(a_y\), \(a_z\)), mais aussi les vitesses angulaires :

  • \(\omega_x\) : rotation autour de l’axe longitudinal (roulis),
  • \(\omega_y\) : rotation autour de l’axe latéral (tangage),
  • \(\omega_z\) : rotation autour de l’axe vertical (lacet, typique des virages).

La simulation de ces grandeurs est indispensable pour enrichir la trajectoire simulée de comportements angulaires réalistes, notamment lorsque l’IMU est utilisée pour des estimations d’attitude ou dans des systèmes embarqués de navigation inertielle autonome.

5.5.2 Génération des vitesses de rotation dans RoadSimulator3

Le simulateur RoadSimulator3 intègre une simulation gyroscopique complète, synchronisée avec les données GPS et les accélérations linéaires. Les principales sources de variations angulaires sont :

  • Les courbures de la route (virages, bifurcations, ronds-points), extraites du graphe OSM via OSRM.
  • Les événements dynamiques spécifiques comme :
    • Franchissement de dos d’âne ou de trottoir (impact en \(\omega_x\) et \(\omega_y\)),
    • Manœuvres de freinage/accélération (souvent corrélées à un tangage \(\omega_y\)),
    • Ouverture de porte (impulsion latérale sur \(\omega_z\) ou \(\omega_y\) selon l’axe).

La génération se fait à 10 Hz en cohérence avec les autres modalités (vitesse, position, acc_x/y/z).

5.5.3 Modélisation gyroscopique par signature événementielle

Chaque événement inertiel simulé s’accompagne d’une signature gyroscopique spécifique, injectée selon des règles cohérentes avec la dynamique du véhicule :

  • Un freinage brusque génère une pointe de tangage négatif (\(\omega_y < 0\)).
  • Un virage à droite produit une élévation de \(\omega_z < 0\), inversement à gauche.

Ces variations de \(\omega_z\) permettent ainsi de confirmer inertiellement les changements de cap observés dans la trajectoire GPS.

  • Un franchissement de dos d’âne combine un bump vertical en \(a_z\) et un pic de roulis (\(\omega_x\)).

Le bruit gyroscopique est modélisé selon les méthodes décrites au chapitre précédent, avec des variations pseudo-aléatoires réalistes (modèle de Hemerly + perturbations de Zhang 2024).

5.5.4 Implémentation logicielle dans RoadSimulator3

La génération des données gyroscopiques est centralisée dans le module events/generation.py, avec des fonctions telles que :

  • generate_gyroscope_from_curvature(df),
  • generate_gyro_signature_for_event(event_type).

Les signatures sont injectées au même pas temporel que les autres données (100 ms) et exportées dans le fichier .csv final avec les colonnes :

..., acc_x, acc_y, acc_z, gyro_x, gyro_y, gyro_z, ...

L’intégration logicielle garantit ainsi une cohérence spatio-temporelle entre les modalités linéaires et angulaires.

5.5.5 Avantages de la simulation gyroscopique

Avantage Description
Complémentarité inertielle Permet une reconstitution complète de l’attitude du véhicule.
Détection multimodale Permet de valider la présence de certains événements (ronds-points, virages) via \(\omega_z\).
Amélioration des modèles ML Les modèles de détection s’enrichissent de nouvelles modalités pour distinguer des événements ambigus.
Support à la fusion IMU/GNSS Améliore la robustesse des algorithmes de localisation autonome en conditions GNSS dégradées.

5.5.6 Perspectives

  • Intégration de profils gyroscopiques multi-sources pour simuler des environnements complexes (ex : virage avec ralentisseur).
  • Utilisation de modèles neuraux génératifs (ex. VAE ou GAN) pour produire des signatures gyroscopiques réalistes à partir d’exemples réels.
  • Validation croisée avec des jeux de données de référence, pour affiner les amplitudes et fréquences simulées.

5.6 Détection inertielle et validation des événements simulés

La qualité d’un simulateur inertiel ne réside pas uniquement dans sa capacité à injecter des événements dynamiques, mais aussi dans la capacité à les détecter a posteriori de manière fiable. La boucle injection → détection permet d’évaluer la pertinence des profils inertiels simulés et de garantir la réalisme des signatures produites. Cette étape est cruciale pour garantir que les signaux inertiels simulés restent exploitables par des algorithmes de détection automatique, tout en conservant une cohérence physique.

5.6.1 Objectifs de la détection

  • Vérifier que les événements injectés sont détectables par des méthodes standards (seuils, signatures, apprentissage).
  • Évaluer la fidélité des profils inertiels en comparant les caractéristiques simulées avec les critères scientifiques.
  • Constituer des jeux de données annotés pour entraîner ou tester des algorithmes de classification inertielle.

5.6.2 Méthodologie

Pour chaque type d’événement simulé (freinage, dos d’âne, accélération, etc.), une fonction de détection spécifique est définie dans events/detection.py, utilisant :

  • Une fenêtre glissante sur les signaux \(a_x\), \(a_y\), \(a_z\) et \(\omega_x\), \(\omega_y\), \(\omega_z\),
  • Des seuils et durées spécifiques selon les définitions scientifiques (cf. section 1.4),
  • Un filtrage spatio-temporel, basé sur une distance minimale entre événements similaires et un délai temporel de réinitialisation, pour éviter les doublons ou les faux positifs.

Ces détecteurs sont systématiquement appliqués à la sortie du simulateur (CSV 10 Hz) pour générer un tableau de comparaison détection/injection.

5.6.3 Exemples de détection intégrée

Événement simulé Détection utilisée Critère clé
Freinage brusque detect_freinage() \(a_x < -3\,\mathrm{m/s}^2\) sur ≥ 0.5 s
Accélération vive detect_acceleration() \(a_x > 2.5\,\mathrm{m/s}^2\) sur ≥ 0.5 s
Dos d’âne detect_dos_dane() \(a_z > 4\,\mathrm{m/s}^2\) suivi de \(a_z < -4\,\mathrm{m/s}^2\) en 1 s
Choc trottoir detect_trottoir() \(a_z > 6\,\mathrm{m/s}^2\) + variation \(a_y\)
Nid de poule detect_nid_de_poule() Pic \(a_z\) négatif + rebond rapide
Rond-point confirm_roundabouts_by_delta_heading() Δ heading ≥ 180° sur 10-20 échantillons
Ouverture porte detect_ouverture_porte() (via \(\omega_y\) impulsif) Pic \(\omega_y\) isolé + arrêt moteur

Chaque détection retourne un tableau contenant :

  • L’index de détection,
  • Le type d’événement,
  • L’amplitude maximale mesurée,
  • La durée détectée.

5.6.4 Validation croisée : injection vs détection

Un module de validation compare :

  • Les événements injectés (colonne event du CSV),
  • Les événements détectés automatiquement.

Il évalue pour chaque type :

  • Le taux de détection (True Positive Rate),
  • Le taux de faux positifs,
  • Les écarts temporels (délai entre injection et détection),
  • Les faux négatifs (événements non détectés malgré injection).

Cela permet d’ajuster les profils inertiels simulés pour maximiser leur détectabilité, sans les rendre artificiels (éviter des pics irréalistes). Cette évaluation est essentielle pour itérer sur les paramètres de génération, en affinant les seuils et durées selon les erreurs observées.

5.6.5 Exemple de rapport automatique

event_summary: freinage: injected: 5 detected: 5 true_positives: 5 false_positives: 0 false_negatives: 0 dos_dane: injected: 4 detected: 4 true_positives: 4 false_positives: 0 false_negatives: 0

5.6.6 Intérêt scientifique et applicatif

  • Validation interne de la simulation : chaque génération de trajectoire inertielle s’accompagne d’un audit automatique.
  • Création de benchmarks réalistes pour la détection d’événements dans les données réelles.
  • Support aux modèles ML : les sorties peuvent être utilisées pour entraîner des classifieurs supervisés ou semi-supervisés.

5.6.7 Perspectives

  • Implémentation d’un module de génération de faux positifs (simulateur de confusion) pour tester les limites des algorithmes de détection.
  • Application de méthodes auto-supervisées pour détecter des événements non injectés ou émergents (ex : nids de poule mal formés).
  • Évaluation comparative de différentes stratégies de détection sur les mêmes trajets simulés.

5.7 Analyse de la cohérence spatio-temporelle et inertielle

La génération de trajectoires synthétiques à haute fréquence impose de vérifier la cohérence globale des données simulées. Cette cohérence doit être assurée sur les plans spatial, temporel, cinématique, inertiel et perceptuel, afin de garantir la crédibilité des données utilisées pour la détection, la validation ou l’entraînement de modèles d’apprentissage.

5.7.1 Objectifs de la validation

L’analyse de cohérence vise à :

  • Identifier les incohérences physiques (ex. : changement de vitesse non justifié, accélération trop forte en virage).
  • Vérifier la continuité spatio-temporelle du mouvement (absence de saut GPS ou de trous dans la simulation).
  • S’assurer de la correspondance entre les événements injectés et détectés, y compris en présence de bruit inertiel.
  • Évaluer la cohérence perceptuelle pour garantir une vraisemblance visuelle et sensorielle lors de la visualisation ou de la reproduction du trajet.

5.7.2 Méthodes de validation proposées

Cohérence spatio-temporelle GPS

On vérifie :

  • La constance du pas spatial moyen (\(\Delta d \approx 0.83\) m à 30 km/h @ 10 Hz).
  • L’absence de sauts anormaux dans les coordonnées (écart GPS > 5 m entre deux points).
  • La régularité des timestamps (\(\Delta t = 0.1\) s constant), garantissant la synchronisation avec les signaux IMU.

Analyse vectorielle inertielle

On s’appuie sur :

  • La norme vectorielle globale : \[ | \vec{a} | = \sqrt{a_x^2 + a_y^2 + a_z^2} \] qui doit rester dans une fourchette réaliste pour un véhicule (autour de 9.81 m/s² à l’arrêt ou à vitesse constante).

  • La distribution des accélérations :

    • acc_x : asymétrique, centrée autour de 0, pics en cas de freinage/accélération.
    • acc_y : liée à la sinuosité.
    • acc_z : proche de 9.81 ± variations dues aux événements verticaux.

Validation inertielle événementielle

On croise les événements injectés (event=xxx) avec ceux détectés automatiquement à partir des séries temporelles (cf. detect_xxx() dans events.py). On mesure :

  • Le taux de détection effective par événement (TP / FN),
  • Le bruit inertiel résiduel (événements faussement détectés),
  • Les écarts temporels entre injection et détection.

Analyse spectrale / FFT

L’analyse fréquentielle (transformée de Fourier discrète, DFT) des signaux inertiels (FFT sur acc_x, acc_z, gyro_z) permet de :

  • Identifier des composantes anormales (aliasing, bruit mal modélisé),
  • Détecter des patterns cycliques (vibrations, oscillations non naturelles),
  • Valider les paramètres de bruit (cohérence avec bruit MEMS injecté).

5.7.3 Application dans RoadSimulator3

Le simulateur intègre plusieurs outils de validation :

  • Graphe d’analyse inertielle (courbes acc_x, acc_z, événements),
  • Tableaux comparatifs des événements injectés vs détectés,
  • Contrôle automatique de la fréquence, des distances et des amplitudes.

L’objectif est de garantir que :

  • Chaque événement possède une signature inertielle détectable.
  • Les courbes sont physiquement cohérentes (pas de saccade, pas d’accélération irréaliste).
  • Les signaux bruyés restent interprétables par les méthodes de détection (classiques ou par apprentissage), même dans des configurations bruitées proches des conditions réelles.

5.7.4 Perspectives avancées

Des travaux récents, notamment “Simulation-based validation for autonomous driving systems” (Ding et al., 2023), recommandent d’aller plus loin :

  • En validant les trajectoires via un simulateur physique embarqué (Digital Twin) (par exemple, Carla ou LGSVL synchronisés à des données inertielle simulées),
  • En intégrant des critères de cohérence contextuelle (type de route, météo, comportement attendu),
  • En mesurant la “congruence inertielle” entre différents capteurs simulés (GPS, IMU, radar, lidar).

5.7.5 Conclusion

L’analyse de la cohérence spatio-temporelle et inertielle est une étape critique du pipeline RoadSimulator3. Elle assure la fiabilité scientifique et industrielle des données générées, permettant de les exploiter pour des cas d’usage exigeants : détection d’événements, apprentissage automatique, télématique, ou validation ADAS.

5.8 Détection et gestion des zones ambiguës et événements manqués

Malgré l’utilisation de signatures inertielle précises et de profils de bruit réalistes, certaines zones du trajet simulé restent ambiguës ou difficiles à interpréter automatiquement. Ces zones posent des défis majeurs pour les algorithmes de détection d’événements inertiels, que ce soit par méthodes à seuils ou par apprentissage automatique.

5.8.1 Définition des zones ambiguës

On qualifie de zone ambiguë toute séquence du trajet pour laquelle :

  • Plusieurs types d’événements inertiels présentent des signatures similaires (ex. : freinage ↔︎ pente descendante).
  • L’intensité du signal est proche du seuil de détection, rendant la classification instable.
  • Le contexte topographique ou routier est complexe, perturbant l’interprétation inertielle (rond-point + dos d’âne, intersection avec ralentissement, etc.).
  • La durée de l’événement est trop courte pour être détectée (ex. : nid de poule à 50 km/h en 0.2s).

Cette distinction est essentielle dans les approches d’apprentissage automatique supervisé, afin d’éviter que des séquences mal labellisées n’introduisent du bruit ou des biais dans les modèles de détection.

5.8.2 Types d’ambiguïtés rencontrées

Ambiguïté Exemple Problème Conséquence Correction envisagée
Pente ↔︎ Freinage Descente à 8% vs freinage à 3 m/s² Acc_x similaire Faux positifs ou faux négatifs Analyse topographique + détection de variation de pente
Dos d’âne ↔︎ Trottoir Pic acc_z suivi de creux Signature très proche Mauvaise classification Utilisation du contexte (vitesse, environnement routier)
Nid de poule trop rapide Passage trop bref Non détecté Événement manqué Fenêtre d’observation adaptative ou ralentissement simulé
Zone à faible signal Accélération faible (acc_x ~1.5) Sous le seuil Ambiguïté ou silence inertiel Seuil dynamique basé sur le contexte
Conflit entre événements Nid de poule dans virage acc_z + acc_y modifiés Masquage d’événement Modèle multi-capteurs + analyse combinée acc et gyro

5.8.3 Méthodes proposées pour la détection

Analyse contextuelle multi-sources

  • Intégration de données topographiques (pente) et routières (OSM/OSRM) pour distinguer les causes d’accélération.
  • Utilisation de clusters d’événements proches pour détecter des regroupements incohérents ou trop denses.

Détection par incertitude (ML probabiliste)

  • Approches bayésiennes ou réseaux de neurones probabilistes (ex. AirIMU) permettant :
    • De quantifier le niveau de confiance de la détection.
    • D’isoler les segments à forte incertitude comme zones candidates à validation manuelle.
  • Utilisation de fenêtres temporelles adaptatives pour améliorer la capture des signatures faibles ou superposées.
  • Calibrage dynamique des seuils en fonction du type de route, de la vitesse ou du contexte inertiel.

Marquage automatique des zones à valider

  • Toute séquence présentant un signal ambigu, une signature partielle ou des conflits entre méthodes de détection est marquée :
    • ambiguous_zone=True
    • ou event=ambiguous_xxx dans la colonne event.

5.8.4 Intégration dans RoadSimulator3

Le pipeline de validation RoadSimulator3 intègre un module de :

  • Détection automatique des événements manqués par croisement entre events_injected et events_detected. Chaque événement détecté est associé à un score de confiance (entre 0.0 et 1.0) facilitant la validation ou le rejet.
  • Scorage de confiance pour chaque événement détecté, avec possibilité de rejet ou de reclassification.
  • Génération d’un rapport HTML / CSV listant :
    • Les zones ambigües,
    • Les événements manqués,
    • Les cas de doute nécessitant validation humaine ou amélioration du simulateur. Une heatmap temporelle des ambiguïtés peut être générée pour visualiser les segments du trajet présentant une faible robustesse inertielle.

5.8.5 Perspectives

La détection robuste des événements ambigus est un pré-requis clé pour l’automatisation de la labellisation inertielle. Les perspectives futures incluent :

  • L’apprentissage par renforcement supervisé : corriger les événements détectés à l’aide de validations humaines.
  • L’injection automatique de bruit contrôlé pour tester les limites de robustesse.
  • L’intégration de capteurs virtuels complémentaires (caméra simulée, lidar) pour lever les ambiguïtés multisensorielles.

Des méthodes semi-supervisées ou auto-supervisées, capables de tirer parti des ambiguïtés pour améliorer la robustesse globale, constituent également une piste prometteuse. Il reste néanmoins des limitations liées à la latence du traitement et aux zones persistantes d’ambiguïté non résolues.

5.8.6 Conclusion

La prise en compte des zones ambiguës et des événements manqués renforce la rigueur scientifique de la simulation. Elle garantit que les trajectoires générées par RoadSimulator3 sont :

  • Complètes,
  • Interprétables,
  • Exploitables pour l’entraînement d’algorithmes de détection réalistes et robustes.

5.9 Synthèse du pipeline de validation et limites actuelles

Le simulateur RoadSimulator3 repose sur un pipeline complet allant de la génération de trajectoires réalistes jusqu’à la validation fine des événements inertiels simulés. Ce pipeline vise à garantir la cohérence spatio-temporelle, la fidélité inertielle, ainsi que la détectabilité effective des événements injectés. Il constitue un cadre reproductible, modulaire et extensible.

5.9.1 Récapitulatif du pipeline de validation

Le processus de validation repose sur les étapes suivantes :

  1. Simulation initiale du trajet
    • Calcul OSRM des points GPS avec distances, vitesses, directions.
    • Interpolation à pas régulier (~0.83 m → 10 Hz).
  2. Injection d’événements inertiels
    • Application contrôlée des profils acc_x, acc_y, acc_z, gyro autour d’un index défini.
    • Application de bruit inertiel réaliste (MEMS).
  3. Détection automatique des événements
    • Application des algorithmes detect_xxx() (notamment avec gestion des faux positifs et négatifs) (freinage, trottoir, etc.).
    • Enregistrement des événements détectés.
  4. Croisement injection ↔︎ détection
    • Tableau de correspondance :
      • événements injectés mais non détectés (faux négatifs),
      • événements détectés mais non injectés (faux positifs),
      • détections multiples ou incomplètes.
  5. Analyse des zones ambiguës
    • Marquage automatique de segments où la signature est faible, confuse ou partiellement détectée.
    • Export CSV / HTML avec surlignage.
  6. Validation par inspection humaine ou re-simulation
    • Possibilité d’exporter les séquences ambiguës pour relecture ou recalibrage de l’injection.
    • Enrichissement progressif du simulateur via feedback.

5.9.2 Limites identifiées

Malgré la rigueur du pipeline, certaines limitations subsistent :

Limite Impact Perspective
Événements très courts Difficiles à détecter à 10 Hz Affinement temporel localisé ou enrichissement de signature
Bruit inertiel trop fort Masque les événements faibles Adaptation contextuelle du bruit en fonction de la topographie et du type de route
Surcharge d’événements Effets de bord entre signatures Ordonnancement contextuel tenant compte de la dynamique du véhicule
Conflits topographiques Descente ↔︎ freinage Modélisation conjointe inertie-topographie via pente et courbure
Seuils de détection fixes Peu adaptables Seuils dynamiques issus de modèles de détection entraînés (semi-supervisé ou supervisé)

5.9.3 Qualité de détection (exemple)

Type d’événement Injectés Détectés Manqués Ambigus
Freinage brusque 5 5 0 0
Trottoir 5 4 1 1
Dos d’âne 5 5 0 0
Nid de poule 5 3 2 2
Accélération vive 5 5 0 0

Ce tableau illustre l’efficacité globale de détection, tout en soulignant les cas problématiques liés à la brièveté ou à l’ambiguïté de certains événements.
Ce tableau sert également à ajuster automatiquement les seuils dans les futures versions via calibration croisée.

5.9.4 Synthèse

Le pipeline de validation de RoadSimulator3 constitue une référence robuste pour toute simulation inertielle appliquée à la télématique, aux ADAS ou à l’analyse comportementale. Il permet :

  • Une traçabilité complète des événements,
  • Une amélioration itérative des modèles d’injection,
  • Une base solide pour l’apprentissage supervisé,
  • Une détection explicable et visualisable, facilitant les diagnostics scientifiques.

5.10 Conclusion

Ce chapitre a établi les fondements théoriques essentiels à la simulation inertielle réaliste dans le cadre du projet RoadSimulator3. Il a permis de structurer une vision intégrée reliant données géographiques, lois physiques, comportements dynamiques et modèles d’erreurs capteurs.

5.10.1 Résumé des apports clés :

  • Une génération spatio-temporelle de trajectoires à haute fréquence (10 Hz) à partir de l’infrastructure OSM et du calcul OSRM, garantissant une cohérence géographique et temporelle.
  • Une modélisation dynamique complète :
    • Longitudinale (accélération, freinage),
    • Latérale (virages, ronds-points),
    • Verticale (obstacles, irrégularités de la chaussée).
  • L’introduction d’un modèle gyroscopique réaliste intégré aux données IMU, avec bruit inertiel simulé, enrichissant la simulation sur les 6 degrés de liberté (acc_x, acc_y, acc_z, gyro_x, gyro_y, gyro_z).
  • L’intégration des effets topographiques (pente, altitude) et leur influence sur les accélérations simulées.
  • Un pipeline de détection et validation des événements inertiels robustes, confrontant injection, détection automatique, et analyse des zones ambiguës.
  • Une structuration modulaire et traçable de la chaîne logicielle, avec des tests visuels, un format de données propre, et une capacité à réinjecter les caractéristiques du terrain réel dans les simulations de trajectoires.

Cette approche scientifique rigoureuse permet de simuler des trajectoires fidèles, riches et exploitables, y compris dans des contextes urbains complexes ou des scénarios critiques, à la croisée de la télématique, des ADAS, de l’analyse comportementale et de la simulation embarquée.

5.10.2 Transition vers la suite

S’inscrivant dans la continuité, le Chapitre 3 prolonge ces fondements en détaillant les algorithmes concrets d’injection et de détection inertielle, avec une attention particulière portée à :

  • La génération réaliste et contextualisée d’événements inertiels typiques (freinage, dos d’âne, etc.),
  • La modélisation probabiliste du bruit,
  • Les critères de validation,
  • L’architecture logicielle mise en place pour une simulation reproductible, explicable et extensible.

Ce chapitre marque donc la transition entre la modélisation théorique et la mise en œuvre logicielle opérationnelle.