5  Chapitre 03

6 Chapitre 3 : Simulation inertielle avancée

6.1 Introduction

Le chapitre précédent a présenté les fondements théoriques nécessaires à la modélisation inertielle réaliste d’un véhicule en mouvement. Nous y avons établi les bases dynamiques et physiques qui régissent les déplacements terrestres, en tenant compte des effets de la pente, de la sinuosité, et des accélérations dans les trois axes (longitudinal, latéral, vertical), ainsi que des vitesses angulaires issues du gyroscope.

Dans ce troisième chapitre, nous entrons dans la mise en œuvre concrète de la simulation inertielle au sein du simulateur RoadSimulator3. L’objectif est de générer un jeu de données complet à haute fréquence (10 Hz), reproduisant de manière crédible le comportement d’un véhicule soumis à des contraintes routières réalistes et à des événements dynamiques.

Plus précisément, ce chapitre décrit :

  • La génération des signaux IMU réalistes à partir de la trajectoire interpolée ;
  • L’injection contrôlée d’événements caractéristiques (freinage, dos d’âne, etc.) dans le signal inertiel ;
  • La modélisation des effets stochastiques liés aux erreurs des capteurs MEMS (bruit, biais, incertitude) ;
  • L’implémentation de la phase d’accélération initiale, de croisière, puis de décélération ;
  • L’intégration des signatures gyroscopiques cohérentes dans les virages, ronds-points ou chocs verticaux ;
  • Et la synchronisation temporelle et spatiale complète du signal simulé (acc, gyro, GPS, timestamps).

Ces différents modules sont abordés successivement dans les sections qui suivent.

Ce chapitre constitue le noyau fonctionnel de RoadSimulator3, là où la trajectoire géographique s’enrichit d’une dynamique inertielle crédible. Chaque point GPS est désormais associé à une signature inertielle réaliste, permettant des usages avancés en détection d’événements, fusion multi-capteurs ou analyse comportementale.

6.2 Structure du simulateur et architecture modulaire

Le simulateur RoadSimulator3 repose sur une architecture modulaire permettant de simuler des trajectoires véhicules enrichies, incluant les dimensions géographiques, inertielle (accéléromètre et gyroscope), événementielle et temporelle. Chaque composant du simulateur est conçu comme une brique indépendante mais interopérable, facilitant la maintenance, l’extension et la validation scientifique du pipeline.

Le présent chapitre expose en détail l’organisation interne du simulateur RoadSimulator3. L’objectif est de mettre en lumière la logique d’articulation entre les modules, leur rôle dans le pipeline de simulation, ainsi que les choix d’architecture ayant guidé le développement.

6.2.1 Architecture générale

L’architecture logicielle suit une chaîne de traitement structurée autour des étapes suivantes :

  1. Génération du trajet géographique brut via OSRM (points GPS, vitesse, durée, heading).

  2. Interpolation spatio-temporelle à fréquence fixe (10 Hz), avec un pas spatial cohérent.

  3. Enrichissement topographique et typologique via OSM/SRTM :

    • Altitude et pente locale issues du MNT (SRTM ou API IGN).
    • Type de route (highway=*), sinuosité, courbure.
    • Détection automatique des virages, ronds-points, intersections.

  4. Simulation des dynamiques inertielle réalistes :

    • Accélérations acc_x, acc_y, acc_z corrigées de la pente locale.
    • Profils gyroscopiques gyro_x/y/z dans les virages, événements et ronds-points.

  5. Insertion des événements inertiels simulés (freinage, dos d’âne, etc.).

  6. Ajout de bruit inertiel stochastique pour simuler les erreurs des IMU MEMS.

  7. Export final au format CSV/JSON, accompagné de la carte HTML et de graphiques analytiques.

Chaque étape est implémentée dans un module Python indépendant, organisé de façon claire dans l’arborescence du projet.

6.2.2 Organisation modulaire du code

Module Rôle principal
osrm/ Appels à l’API OSRM, interpolation, simulation du trajet
osmnx/ Extraction du type de route, pente (MNT), sinuosité, courbure locale
events/generation.py Génération des événements inertiels (acc, gyro, bruit)
events/detection.py Détection des événements injectés (seuils, signature, delta heading)
events/pipeline.py Application séquentielle de tous les événements inertiels
gyro/simulation.py Génération des gyro_x/y/z en cohérence avec la courbure
noise/models.py Modèles de bruit inertiel (Hemerly, Tedaldi, AirIMU)
pipeline_utils.py Orchestration du pipeline global, horodatage, synchronisation finale
visualization/ Génération des cartes interactives, graphiques, heatmaps
runner/ Scripts exécutables (simulate_and_check.py, simulate_normandy.py, etc.)

6.2.3 Paramétrage via YAML

Le simulateur est entièrement paramétrable via un fichier YAML centralisé, qui contrôle :

  • Les amplitudes et durées des événements inertiels.
  • La fréquence de simulation (par défaut 10 Hz).
  • Les seuils de détection (acc, gyro, angle).
  • Les types de bruit appliqués (biais, white noise, drift).
  • Le niveau de détails de la carte (HTML, PNG, légende…).
  • La configuration des heuristiques de détection inertielle (ronds-points, virages, stops)

Ce système garantit une reproductibilité des expériences et facilite l’analyse de sensibilité.

6.2.4 Intégration des données et synchronisation

Chaque point simulé est exporté avec les colonnes suivantes :

Colonne Description
timestamp Temps ISO à 10 Hz
lat, lon Coordonnées géographiques
speed Vitesse instantanée (km/h)
acc_x/y/z Accélérations inertielle (m/s²)
gyro_x/y/z Vitesses angulaires (°/s)
event Label de l’événement détecté ou injecté
road_type Type de route selon OSM
altitude Altitude interpolée via MNT

6.2.5 Visualisation et validation

À la fin de chaque simulation, le simulateur génère :

  • Une carte HTML interactive (tracé, événements, livraisons).
  • Deux graphes temporels (vitesse, événements).
  • Un récapitulatif des événements injectés/détectés.
  • Un fichier PNG statique de la carte pour usage scientifique ou publication.
  • Une heatmap inertielle (acc_x vs acc_y) pour analyse du comportement dynamique.

6.2.6 Conclusion

Cette architecture modulaire permet à RoadSimulator3 de servir à la fois de simulateur inertiel avancé, de générateur de jeux de données annotés, et de banc d’essai pour les algorithmes de détection, de fusion, ou de classification comportementale. Elle constitue le socle technique sur lequel reposent les contributions scientifiques développées dans les chapitres suivants.
Cette structure modulaire ouvre également la voie à l’intégration future de nouveaux capteurs (LIDAR, caméra) ou de scénarios simulés complexes (interactions multi-véhicules, conditions météorologiques).

6.3 Injection d’événements inertiels réalistes

L’un des apports majeurs de RoadSimulator3 réside dans sa capacité à injecter des événements inertiels réalistes dans une trajectoire simulée. Ces événements reproduisent des situations typiques de la conduite, telles que les freinages brusques, les accélérations vives ou le franchissement d’obstacles. L’objectif est de générer des signatures IMU crédibles et détectables, compatibles avec les lois physiques, les contraintes environnementales et le comportement attendu du véhicule.

6.3.1 Typologie des événements simulés

Les événements inertiels sont classés selon leur nature dynamique et leur impact sur les mesures IMU :

Événement Axe principal Signature caractéristique
Accélération vive acc_x Montée > +2.5 m/s² sur ≥ 0.5 s
Freinage brusque acc_x Descente < –3.0 m/s² sur ≥ 0.5 s
Dos d’âne acc_z Pic acc_z > +4 suivi de creux < –4 m/s²
Choc trottoir acc_z / acc_y Impulsion verticale (+6~8 m/s²) + latérale
Nid de poule acc_z Pic acc_z < –5 puis > +5 m/s² en < 0.3 s
Virage serré acc_y / gyro_z Courbure soutenue + dérivée de heading
Rond-point gyro_z Oscillation gyroscopique continue
Arrêt moteur (stop) acc_x = 0, v = 0 Immobile ≥ 2 min
Attente moteur on acc_x = 0 Immobile 30s–2 min
Ouverture de porte gyro_y Pic d’oscillation localisée

6.3.2 Méthode d’injection

La méthode décrite ici est généralisée à tous les types d’événements inertiels, assurant une cohérence et une reproductibilité dans la simulation.

Chaque événement est injecté en suivant un pipeline standardisé :

  1. Sélection d’un emplacement compatible :
    • On exclut la phase d’accélération initiale ou d’arrivée.
    • On vérifie la distance et le contexte (route secondaire, vitesse basse).
  2. Réservation d’un créneau temporel :
    • La simulation tourne à 10 Hz (100 ms), donc l’événement dure entre 0.3 et 1.5 s.
    • Les points du DataFrame sont réservés pour modifier acc_x/y/z et gyro.
  3. Application de la signature inertielle :
    • Une forme d’onde réaliste est appliquée (sinusoïde, impulsion, plateau bruité).
    • Du bruit inertiel est ajouté (biais, dérive, bruit blanc) selon un modèle MEMS.
  4. Mise à jour de la vitesse / position :
    • Pour les freinages et accélérations, la vitesse est recalculée par intégration.
    • Pour les chocs verticaux, les positions sont ajustées si besoin.
  5. Annotation dans la colonne event :
    • Le type exact est inscrit (ex: freinage, trottoir, dos_dane).
    • Cela permet une validation automatique en fin de simulation.

6.3.3 Exemple : Injection d’un dos d’âne

from simulator.events.generation import generate_dos_dane
df = generate_dos_dane(df, index=5203)

Cette fonction injecte un profil inertiel sur une durée d’environ 0.8 seconde autour du point 5203. Elle génère un pic positif suivi d’un creux marqué sur acc_z, tout en ajoutant un bruit inertiel réaliste selon le modèle Hemerly. Enfin, la ligne correspondante est annotée avec event = "dos_dane" pour faciliter la traçabilité.

6.3.4 Contrôle de densité et diversité

La densité et la variété des événements sont contrôlées pour préserver la crédibilité des simulations.

Afin de maintenir le réalisme du trajet :

  • Un maximum de 5 événements par type est autorisé par simulation.
  • Au moins un événement de chaque type majeur est garanti.
  • Une distance minimale est imposée entre événements (ex: >200 m).

6.3.5 Génération automatisée

Le fichier events/pipeline.py contient la fonction :

def apply_all_events(df, config):
    ...

Elle applique toutes les règles d’injection selon :

  • La configuration YAML (durées, amplitudes, priorités).
  • Les points disponibles compatibles.
  • La logique d’espacement et d’alternance entre les types.

6.3.6 Intégration gyroscopique

Chaque événement modifie également les colonnes gyro_x/y/z :

  • Par exemple, un virage serré produit un gyro_z positif ou négatif.
  • Un choc trottoir peut introduire un pic sur gyro_y.

Ces profils gyroscopiques modélés selon des standards MEMS (±1 à 15 °/s) permettent également d’étudier la réponse des gyroscopes MEMS dans des conditions réalistes.

La figure suivante illustre l’impact du bruit inertiel ajouté au signal longitudinal \(acc_x\). On observe comment une signature nette peut être rendue difficilement détectable si le bruit n’est pas correctement modélisé.

Effet du bruit inertiel sur le signal acc_x

6.3.7 Conclusion

L’injection réaliste d’événements inertiels constitue le cœur de la simulation dynamique proposée par RoadSimulator3. Elle permet de générer des données cohérentes, annotées et reproductibles, prêtes pour :

  • La détection automatique (cf. section suivante),
  • L’entraînement de modèles de machine learning,
  • L’analyse de robustesse d’algorithmes embarqués.

6.4 Détection automatique et validation des événements inertiels

Une fois les événements inertiels injectés dans les trajectoires simulées, il est fondamental de pouvoir les détecter automatiquement à partir des données brutes IMU. Cette étape de validation croisée permet non seulement de vérifier la conformité des signatures générées, mais également de tester la robustesse des algorithmes de détection en conditions simulées mais réalistes.

6.4.1 Objectifs de la détection

  • Valider la qualité des événements injectés (correspondance forme / durée / amplitude).

  • Tester les algorithmes de détection sur des données bruitées réalistes.

  • Construire des pipelines de scoring comportemental ou d’analyse embarquée.

6.4.2 Pipeline de détection inertielle

Le pipeline de détection repose sur des fonctions spécifiques à chaque type d’événement, codées dans simulator/events/detection.py. Pour chaque série temporelle inertielle, la détection procède en :

  1. Application d’un filtre (optionnel : médian ou passe-bas),

  2. Analyse par fenêtre glissante (taille et saut ajustables),

  3. Vérification de la signature caractéristique,

  4. Annotation si condition détectée.

Exemple :

from simulator.events.detection import detect_dos_dane
events = detect_dos_dane(df)

6.4.3 Détecteurs par type d’événement

Type d’événement Fonction de détection Signature détectée
Accélération detect_acceleration() \(acc_x > 2.5, m/s^2\) sur ≥ 0.5 s
Freinage detect_freinage() \(acc_x < -3.0, m/s^2\) sur ≥ 0.5 s
Dos d’âne detect_dos_dane() \(acc_z\) pic > +4 puis < –4 m/s² sur 0.5–1 s
Nid de poule detect_nid_de_poule() \(acc_z\) pic < –5 puis > +5 m/s² en < 0.3 s
Trottoir detect_trottoir() \(acc_z\) ∈ [6,8] + pic \(acc_y\) latéral
Rond-point / virage detect_rond_point() Oscillation de \(gyro_z\), variation de heading
Arrêt moteur (stop) detect_stop() \(v \approx 0\) sur > 2 min + \(acc \approx 0\)

Chaque détecteur retourne une liste d’index ou un DataFrame annoté avec les événements détectés.

6.4.4 Validation croisée : injection vs détection

Le script simulate_and_check.py permet d’exécuter un scénario complet :

  1. Simulation d’un trajet avec injection.

  2. Application de tous les détecteurs.

  3. Comparaison entre la colonne event et les détections.

Exemple de validation :

python simulate_and_check.py

Le résultat donne un tableau de validation :

Événement Injectés Détectés Détection correcte (%)
freinage 5 5 100 %
dos d’âne 5 5 100 %
trottoir 5 4 80 %
accélération 5 5 100 %
nid de poule 5 5 100 %

6.4.5 Visualisation

Le fichier events.py inclut un test visuel interactif pour chaque détection :

if __name__ == "__main__":
    test_dos_dane_detection()

Ce script affiche les courbes IMU (acc_x, acc_y, acc_z) avec les points d’injection et de détection surlignés, permettant une vérification manuelle.

6.4.6 Limites et robustesse

  • Des événements proches dans le temps peuvent provoquer des détections multiples ambiguës.

  • Le bruit inertiel simulé (aléatoire) peut générer de faux positifs si les seuils sont trop bas.

  • Certains profils (trottoir) sont sensibles à la présence d’un pic latéral (\(acc_y\)), ce qui peut être masqué selon le niveau de bruit ou la vitesse.

6.4.7 Conclusion

La détection automatique dans RoadSimulator3 permet une validation rigoureuse de la simulation. Elle ouvre également la voie à l’évaluation :

  • Des algorithmes de machine learning sur données annotées,

  • De la robustesse des capteurs dans des scénarios dégradés,

  • De la performance des systèmes embarqués à reconnaître des signatures critiques.

6.4.8 Perspectives d’amélioration

  • Détection par apprentissage automatique : intégrer des modèles supervisés (Random Forest, CNN) pour surpasser les seuils fixes.
  • Fusion multi-capteurs : combiner accéléromètre, gyroscope et GNSS pour augmenter la robustesse.
  • Tolérance aux erreurs temporelles : introduire un relâchement temporel dans la correspondance injection/détection.

6.5 Génération des signaux gyroscopiques et validation croisée

Outre les accélérations linéaires (\(a_x\), \(a_y\), \(a_z\)), un véhicule en mouvement est soumis à des rotations mesurables par les gyroscopes. Ces signaux (\(\omega_x\), \(\omega_y\), \(\omega_z\)) sont essentiels pour détecter :

  • Les virages et ronds-points,

  • Les oscillations et déséquilibres dynamiques,

  • Les micro-rotations dues à des franchissements verticaux ou latéraux (ex. trottoir).

6.5.1 Objectifs de la simulation gyroscopique

  • Générer des profils de vitesse angulaire réalistes pour chaque événement dynamique simulé.

  • Reproduire les rotations du véhicule dans l’espace, en cohérence avec sa trajectoire et sa dynamique inertielle.

  • Faciliter la détection inertielle combinée (accéléromètre + gyroscope).

6.5.2 Méthode de génération des signaux gyroscopiques

Les signaux gyroscopiques sont simulés via la fonction :

from simulator.events.generation import generate_gyro_from_heading

Ils dépendent principalement de deux composantes :

  1. La variation de heading (\(\Delta \theta\)) calculée entre les points GPS interpolés.

  2. L’ampleur et la vitesse de changement de direction.

L’axe gyroscopique simulé est typiquement \(\omega_z\) (rotation autour de l’axe vertical), calculé à partir de la dérivée temporelle du heading :

\[ \omega_z(t) = \frac{\Delta \theta(t)}{\Delta t} \]

Les événements particuliers (ronds-points, virages serrés, obstacles latéraux) reçoivent des signatures gyroscopiques supplémentaires simulées de manière empirique, par exemple :

  • Pic de \(\omega_z\) lors d’un rond-point ou virage,

  • Oscillation \(\omega_y\) ou \(\omega_x\) pour des effets verticaux (nid de poule, trottoir, etc.).

6.5.3 Profils gyroscopiques injectés par type d’événement

Événement inertiel Profil gyroscopique simulé
Virage \(\omega_z\) sinusoïdal croissant puis décroissant
Rond-point Séquence de \(\omega_z\) + variation heading
Dos d’âne Pic \(\omega_x\) associé à acc_z
Trottoir Impulsion \(\omega_y\) ou \(\omega_x\) latérale
Nid de poule Double pic impulsif \(\omega_x\), rapide

6.5.4 Bruit gyroscopique

Des bruits inertiels réalistes sont ajoutés à chaque axe simulé :

  • Bruit blanc gaussien,

  • Composantes aléatoires lentes (biais),

  • Amplitude variable selon le type d’IMU simulé (low-cost, automotive-grade).

6.5.5 Validation croisée

Pour valider la qualité de la simulation gyroscopique :

  • Un comparatif visuel est effectué entre heading, \(\omega_z\) simulé, et \(\Delta \theta\) calculé.

  • Des détecteurs spécifiques sont appliqués sur \(\omega_z\) pour retrouver :

    • Les virages,

    • Les changements de direction brutaux,

    • Les oscillations propres aux anomalies de la route.

La fonction check_realism.py vérifie notamment la cohérence inertielle entre acc_y et \(\omega_z\) lors des virages simulés.

6.5.6 Exemple visuel

Un graphe superpose :

  • La trajectoire GPS (vue 2D),

  • La variation du heading,

  • La courbe de \(\omega_z\) sur le temps.

Cela permet de valider que chaque virage génère un pic de rotation conforme à la réalité physique.

6.5.7 Perspectives d’amélioration

  • La vitesse angulaire simulée reste parfois sous-estimée sur les virages courts ; une modulation plus fine de la dérivée du heading pourrait améliorer la fidélité inertielle.
  • Les événements latéraux (trottoirs, nid de poule) gagneraient à inclure une synchronisation plus stricte entre acc_y, acc_z, et \(\omega_y\) ou \(\omega_x\).
  • Une évaluation systématique des erreurs de gyro par type de trajectoire (ligne droite, virage, rond-point) pourrait compléter la validation actuelle.
  • Enfin, une comparaison avec des mesures réelles issues de capteurs IMU de véhicules tests (par exemple via base d’essai GNSS/IMU) renforcerait la validité externe de la simulation.

6.5.8 Conclusion

La simulation gyroscopique dans RoadSimulator3 :

  • Renforce la réalisme inertiel total (6 DOF),

  • Permet de tester des algorithmes de fusion GPS/IMU avancés,

  • Facilite la détection d’événements complexes, en combinant accéléromètre et gyroscope.

6.6 Gestion des arrêts moteur, pauses et livraisons

Les arrêts temporaires du véhicule constituent une composante essentielle de toute trajectoire réaliste. Ils peuvent correspondre à :

  • Une livraison (arrêt prolongé moteur coupé),

  • Une pause moteur allumé (ex. : attente à un feu rouge ou à un carrefour),

  • Un ralentissement passager (ralenti technique, ralentissement avant un dos d’âne ou un virage).

Dans RoadSimulator3, ces arrêts sont modélisés sous forme d’événements stop et wait, enrichissant la structure temporelle et comportementale du trajet.

6.6.1 Types d’arrêts simulés

Type Durée typique Condition Étiquette dans la colonne event
stop ≥ 2 minutes moteur coupé, livraison stop_001, stop_002, …
wait 30 s à 2 minutes moteur allumé, pause courte wait
Ralentissement < 30 s non marqué explicitement intégré via acc_x, acc_y

6.6.2 Génération des arrêts dans le simulateur

  1. Placement spatial :

    • Proche de points d’intérêt (POI),

    • Sur des routes secondaires ou résidentielles détectées via OSM,

    • Avec une légère déviation orthogonale simulant le stationnement sur le côté.

  2. Profil inertiel associé :

    • Vitesse nulle pendant la durée de l’arrêt,

    • Accélération à zéro ou bruit inertiel réaliste (bruit de fond MEMS),

    • Pas de variation de heading sauf pour des manœuvres de parcage simulées.

  3. Injection temporelle :

    • Les timestamps sont maintenus à 10 Hz,

    • La position GPS reste figée durant l’arrêt.

6.6.3 Exemple de simulation d’une livraison

Un stop typique est injecté comme suit :

  • Index initial : vitesse = 0,

  • Durée : 120 s (1200 points à 10 Hz),

  • Position GPS stable,

  • Étiquette event = stop_003,

  • Aucun changement d’orientation (heading constant).

Un graphique de vitesse vs temps montre un plateau à zéro sur cette période, confirmant l’arrêt complet.

6.6.4 Visualisation dans les cartes et exports

Les événements stop et wait sont représentés dans :

  • La carte HTML : marqueur numéroté (🛑 ou 🅿️),

  • La ligne de temps inertielle : encarts plats en vitesse / inertie,

  • Le CSV exporté : étiquette claire dans la colonne event,

  • Le JSON exporté : encodage structuré de type et durée.

6.6.5 Détection des arrêts

Les pauses peuvent être automatiquement détectées par post-traitement :

  • stop : vitesse ≈ 0 sur plus de 2 minutes,

  • wait : vitesse ≈ 0 entre 30 s et 2 min,

  • Exclusion des cas dus à embouteillages (via le contexte topologique ou IMU).

6.6.6 Corrélation avec le type de route et la densité urbaine

Les événements stop et wait sont plus fréquents dans les zones urbaines denses ou résidentielles. L’enrichissement par typologie de route (via le champ road_type) permet d’analyser finement la distribution spatiale des arrêts, par exemple :

  • Fréquence des stops sur les routes de type residential ou service,
  • Moins de pauses sur les primary ou trunk.

Un histogramme croisé peut être utilisé pour explorer cette répartition.

6.6.7 Conclusion

L’ajout des arrêts dans RoadSimulator3 permet :

  • De simuler des scénarios réalistes de tournée de livraison,

  • D’analyser les temps d’arrêt cumulés,

  • De valider des algorithmes de reconnaissance de phases moteur ou de stationnement.

Cette modélisation peut aussi servir à alimenter des modèles prédictifs de consommation énergétique, ou à optimiser des stratégies d’arrêt (freinage anticipé, écoconduite). Elle constitue enfin un levier d’évaluation de la performance logistique, notamment via le ratio temps d’arrêt / temps de trajet.

6.7 Injection d’événements inertiels typiques et gestion des conflits

L’une des forces de RoadSimulator3 réside dans sa capacité à injecter des événements inertiels réalistes dans une trajectoire simulée. Ces événements reproduisent des dynamiques caractéristiques de la conduite, telles que le freinage brusque, le franchissement de dos d’âne ou les accélérations vives.

Pour garantir la cohérence physique et spatio-temporelle du signal inertiel, la génération suit un ensemble de règles strictes, inspirées à la fois de la littérature scientifique et d’observations empiriques.

6.7.1 Types d’événements inertiels injectés

Événement Signature principale Durée typique Fréquence max
Accélération vive \(a_x > +2.5\) m/s² ≥ 0.5 s 5
Freinage brusque \(a_x < -3.0\) m/s² ≥ 0.5 s 5
Dos d’âne \(a_z\) pic puis creux (\(\pm\) 4+) 0.5 à 1 s 5
Nid de poule \(a_z < -5\) suivi \(a_z > +5\) < 0.3 s 5
Trottoir \(a_z \in [6,8]\) + \(a_y\) latéral < 0.5 s 5

Chaque type est injecté exactement une fois au minimum, avec un maximum de 5 occurrences pour ne pas surcharger la simulation.

6.7.2 Conditions d’injection

  • Fenêtres de sécurité : aucune injection n’est permise dans les premières secondes (accélération initiale) ou autour des arrêts (stop).

  • Évitement des chevauchements : un buffer de sécurité est maintenu (ex. : 10 s minimum entre deux événements).

  • Vitesse compatible : certains événements (trottoir, freinage) nécessitent une plage de vitesse réaliste pour être crédibles.

6.7.3 Méthode d’injection

  1. Sélection d’un index candidat (position le long de la trajectoire).

  2. Vérification du contexte local :

    • Vitesse du véhicule,

    • Type de route,

    • Proximité d’autres événements ou arrêts.

  3. Génération de la signature inertielle :

    • Injection directe sur acc_x, acc_y, acc_z,

    • Ajout d’un bruit inertiel réaliste (modèle MEMS),

    • Mise à jour éventuelle des gyro_x/y/z.

  4. Annotation de l’événement dans la colonne event (e.g. “freinage”).

En outre, le choix des zones d’injection peut être modulé selon des critères contextuels : par exemple, certains événements sont davantage injectés sur des routes secondaires ou en zone urbaine, afin de refléter une distribution réaliste. La corrélation avec le type de route permet de moduler la fréquence et la nature des événements simulés.

6.7.4 Gestion des conflits et cohérence

Lorsqu’un conflit survient (événement trop proche d’un autre, ou dans une zone inadaptée) :

  • L’injection est annulée ou reprogrammée plus loin,

  • Un log d’injection est conservé pour audit et vérification,

  • Une priorité est donnée à certains événements (accélération / freinage) en cas de saturation.

Exemple : un dos d’âne ne sera jamais injecté dans une descente raide.

6.7.5 Validation et visualisation

Chaque événement injecté est :

  • Visualisé dans la carte interactive (icône et infobulle),

  • Représenté dans les courbes inertielle (profil caractéristique),

  • Répertorié dans le CSV / JSON final.

Une fonction de détection automatique permet de valider a posteriori la présence effective de chaque signature dans les données.

6.7.6 Conclusion

L’injection d’événements inertiels typiques dans RoadSimulator3 constitue une brique centrale pour :

  • Tester la robustesse de la détection automatique,

  • Générer des trajectoires réalistes enrichies,

  • Servir de base d’entraînement ou de validation pour des modèles comportementaux, des systèmes embarqués ou des analyses logistiques (ex. : impact des ralentissements sur les arrêts, surconsommation).

6.8 Modulation de la vitesse selon le type de route et la sinuosité

La vitesse du véhicule simulé est un paramètre central de la cohérence dynamique d’une trajectoire. Elle conditionne les accélérations, la fréquence des événements inertiels, et la vraisemblance globale du mouvement. Dans RoadSimulator3, la vitesse cible est modulée en fonction de plusieurs facteurs :

6.8.1 Critères de modulation

  1. Type de route (road_type) :

    • Extrait via les attributs highway=* d’OSM enrichis dans la trajectoire.

    • Exemple :

Type OSM Vitesse cible (km/h)
motorway 110 – 130
primary 70 – 90
secondary 50 – 70
residential 30 – 50
unclassified 20 – 40

  1. Niveau de sinuosité :

    • Calculé localement par une fenêtre glissante sur les variations de heading.

    • Un indice de courbure est dérivé et traduit en réduction progressive de la vitesse cible.

  2. Présence d’événements ou d’obstacles :

    • Ralentissements forcés autour :

      • Des STOP simulés (arrêts),

      • Des virages serrés (acc_y élevé),

      • Des anomalies comme dos d’âne, trottoirs.

      • Des ralentissements urbains liés à la densité de croisement ou de feux (ex : proximité de carrefours).

6.8.2 Fonction de modulation continue

Une fonction d’interpolation lissée ajuste la vitesse actuelle \(v\) vers la vitesse cible \(v^*\) selon : \[ v(t+1) = v(t) + \alpha \cdot (v^* - v(t)) \] Cette formule garantit un comportement fluide, tout en conservant une capacité de réponse réaliste aux variations contextuelles comme les freinages anticipés.

où \(\alpha\) est un facteur d’ajustement progressif (ex. : \(\alpha = 0.05\) à \(0.2\)) pour éviter des changements brusques non réalistes.

Cette interpolation est :

  • Asymptotique (approche l’objectif),

  • Adaptée à la fréquence 10 Hz,

  • Compatible avec les contraintes d’accélération (±3 m/s²).

6.8.3 Illustration – effet de la sinuosité

Sinuosité locale Réduction appliquée
Faible (< seuil) Aucune
Moyenne –10 à –20%
Forte –30 à –50%

Le simulateur applique dynamiquement ces réductions lors de la phase de croisière, ce qui génère :

  • Des variations réalistes dans speed,

  • Des pics en acc_y cohérents,

  • Une trajectoire plus fidèle aux comportements humains.

6.8.4 Cas particuliers

  • Montée ou descente forte (cf. section sur la pente) :

    • Ajustement de la vitesse cible selon la gravité et le frein moteur simulé.

  • Contexte urbain / zone 30 :

    • Vitesse plafonnée selon les attributs OSM (ex. maxspeed=30).

  • Transitions de route (ex : secondary → residential) :

    • Changement progressif de la vitesse cible via amortissement inertiel.

6.8.5 Intégration dans RoadSimulator3

La modulation de vitesse est appliquée avant l’injection des événements inertiels, garantissant que :

  • Le contexte dynamique est adapté à chaque événement,

  • Les valeurs de acc_x et acc_y simulées sont physiquement cohérentes,

  • La vitesse reste dans des plages crédibles selon l’environnement.

Elle constitue également une base essentielle pour des extensions futures, comme la prise en compte des limitations de vitesse dynamiques ou des prévisions de trafic.

6.8.6 Conclusion

La modulation dynamique de la vitesse en fonction de la route et de la sinuosité constitue un pilier de réalisme pour RoadSimulator3. Elle permet :

  • Une simulation fluide et cohérente à 10 Hz,

  • Une intégration crédible des événements inertiels,

  • Une génération de trajectoires adaptées à des usages industriels (ADAS, télématique) ou scientifiques (modélisation comportementale).

  • Une base évolutive pour intégrer des logiques avancées de régulation contextuelle (ex. anticipation de ralentissements).

6.9 Export, visualisation et génération de livrables

Une simulation inertielle ne prend tout son sens que si ses résultats peuvent être exploités facilement à travers des exports normalisés, des visualisations interactives, et des documents synthétiques exploitables par les chercheurs, ingénieurs ou industriels. Le simulateur RoadSimulator3 intègre un pipeline complet de génération de livrables associés à chaque trajectoire simulée.

6.9.1 Formats d’export

Les données simulées sont exportées dans plusieurs formats standards :

  • CSV :

    • Format principal pour l’analyse,
    • Contient les colonnes :
    timestamp, lat, lon, speed, acc_x, acc_y, acc_z, gyro_x, gyro_y, gyro_z, event

    Fréquence temporelle : 10 Hz (1 ligne tous les 100 ms),
    Compatible avec les outils de traitement (Pandas, Excel, etc.).

  • JSON nettoyé :

    • Adapté à l’intégration dans des outils web,
    • Structure arborescente avec unités, métadonnées et types d’événements.

  • HTML :

    • Page de carte interactive avec :
      • Tracé GPS coloré (selon la vitesse),
      • Marqueurs pour les événements inertiels,
      • Pastilles de livraison (arrêts STOP),
      • Légende dynamique.

  • PNG :

    • Export image statique de la carte (via headless Chrome),
    • Infographie vectorielle (optionnelle) de type “carte métro” ou “trajet enrichi”.

6.9.2 Visualisation cartographique

Chaque simulation génère une carte centrée sur la zone de trajet, affichant :

Cette carte peut représenter des trajets en milieu urbain, rural ou mixte, et s’adapte dynamiquement à l’échelle géographique simulée.

  • Le tracé interpolé,

  • Les événements via des icônes SVG/PNG spécifiques :

    • 🛑 freinage, 🪵 dos d’âne, 📦 trottoir, ⬆️ accélération, 🚧 nid de poule, 🕰️ attente,

  • Les arrêts/livraisons numérotés,

  • Une légende dynamique permettant de filtrer les événements,

  • Une interface interactive en Leaflet.js (zoom, clic, détails…).

6.9.3 Génération automatique de livrables

Chaque simulation est exportée dans un dossier daté, contenant :

  • trace.csv : données principales à 10 Hz,

  • trace_cleaned.json : version allégée pour visualisation web,

  • map.html : carte interactive autonome,

  • map.png : carte statique exportée,

  • speed_plot.png : graphe vitesse temporelle,

  • stops_plot.png : graphe des arrêts/livraisons,

  • events_report.txt : résumé du nombre d’événements par type,

  • indicators_summary.png : graphe radar des indicateurs inertiels globaux.

  • curvature_plot.png / sinuosity_plot.png : courbes de courbure et sinuosité du trajet.

6.9.4 Intégration dans des workflows de validation

Ces livrables sont conçus pour faciliter :

  • La vérification manuelle des événements (grâce aux cartes interactives et figures d’accélération),

  • La validation de la cohérence inertielle,

  • La comparaison avec des algorithmes de détection,

  • L’alimentation de jeux de données publics ou privés.

6.9.5 Exemple d’usage

Un utilisateur peut simuler un trajet de 100 km, visualiser les freinages, générer le CSV, et :

  • Entraîner un modèle de détection sur le CSV labellisé,

  • Créer une infographie pour une publication scientifique,

  • Visualiser dynamiquement les événements via la carte HTML,

  • Archiver les résultats pour comparaison future.

6.9.6 Conclusion

La richesse des livrables produits par RoadSimulator3 fait de l’outil un véritable simulateur prêt-à-l’usage. Il combine :

  • Une chaîne de simulation complète et configurable,

  • Une génération automatique des sorties pertinentes,

  • Une interopérabilité avec les outils de data science, de recherche et de visualisation.

Ces livrables forment un socle précieux pour documenter, partager et évaluer des simulations à haute fréquence dans des contextes variés.

6.10 Conclusion du Chapitre 3

Ce chapitre a détaillé les fondements géographiques, topologiques et inertiels nécessaires à la simulation de trajectoires réalistes dans le cadre de RoadSimulator3. L’intégration conjointe des outils OSM (OpenStreetMap) et OSRM (Open Source Routing Machine) permet de générer des itinéraires routiers cohérents, ancrés dans la réalité géographique, tout en respectant les contraintes de navigation et la diversité des réseaux de transport.

Les méthodes présentées ont permis :

  • La génération d’itinéraires continus et détaillés sur la base du graphe OSM ;
  • L’interpolation spatiale et temporelle à pas constant pour produire des données à 10 Hz, adaptées aux capteurs inertiels ;
  • L’enrichissement contextuel via la typologie des routes, la sinuosité, les changements de direction, les ronds-points et la pente locale ;
  • La correction inertielle gravitationnelle, tenant compte des variations d’altitude ;
  • La synchronisation inertie/GNSS, ouvrant la voie à des approches de fusion plus avancées (IMU, odométrie, GNSS).

L’export automatique sous différents formats (CSV, JSON, HTML, PNG) ainsi que la génération de visualisations et de cartes interactives permettent de diffuser et valider les trajectoires simulées auprès de divers publics : chercheurs, industriels, développeurs.

Toutefois, certaines limites subsistent dans cette première phase : l’absence de trafic en temps réel, la simplification des limitations de vitesse, ou encore l’absence de données météorologiques peuvent nuire à une simulation totalement réaliste. Ces éléments seront envisagés dans les futures versions de la chaîne de traitement.

Ce socle géographique et inertiel constitue une base solide pour la simulation dynamique complète, qui sera abordée dans le Chapitre 4. Nous y plongerons dans les modèles cinématiques et dynamiques, la simulation de comportements conduits (freinages, accélérations, anomalies de la chaussée), ainsi que les mécanismes de détection automatique à partir des données inertielle générées. Cette transition permettra de relier finement les modèles de trajectoire aux signatures inertielle caractéristiques des événements de conduite, ouvrant ainsi la voie à une simulation plus riche et réaliste.