7  Chapitre 05

8 Chapitre 5 : Injection des événements inertiels

8.1 Introduction

La génération de trajectoires géographiques et de signaux inertiels réalistes constitue une condition préalable essentielle, mais non suffisante, pour simuler les situations dynamiques caractéristiques de la conduite. Dans un contexte de « scoring comportemental », de « maintenance prédictive », ou de « validation de capteurs », il est impératif d’identifier et de caractériser les événements inertiels spécifiques qui reflètent les interactions entre le véhicule et son environnement.

Ce chapitre introduit les méthodes mises en œuvre dans « RoadSimulator3 » pour :

  • Injecter des événements inertiels réalistes dans les séries temporelles simulées, à fréquence fixe (10 Hz),

  • Définir pour chaque type d’événement une signature inertielle typique, caractérisée sur les axes d’accélération et de rotation,

  • Détecter automatiquement ces événements à partir des signaux d’accélération et de gyroscope,

  • Et comparer systématiquement les événements injectés à ceux détectés, afin de valider la robustesse des méthodes.

Les événements inertiels simulés comprennent notamment :

  • Accélérations vives
  • Freinages brusques
  • Virages serrés et ronds-points
  • Dos d’âne
  • Nids de poule
  • Chocs trottoir
  • Arrêts moteur (stop)
  • Attentes moteur tournant (wait)
  • Ouvertures de porte (détection latérale et gyroscopique)

L’objectif est double : injecter des événements inertiels réalistes, visibles et détectables, tout en garantissant la cohérence spatio-temporelle de la simulation inertielle globale.

Ce chapitre présentera successivement :

  1. Les modèles d’injection spécifiques à chaque type d’événement (acc_x, acc_y, acc_z, gyro),

  2. Les algorithmes de détection associés, basés sur des règles, des seuils, ou des fenêtres temporelles,

  3. L’analyse croisée injection ↔︎ détection, pour valider la qualité des événements simulés.

8.2 Types d’événements simulés et logique d’injection

Le simulateur RoadSimulator3 injecte de manière contrôlée une variété d’événements inertiels typiques du comportement de conduite ou de l’interaction avec la chaussée. Chaque événement est modélisé de façon réaliste en termes de durée, amplitude, axes impactés, et bruit inertiel, sur la base de critères issus de la littérature scientifique et des profils empiriques observés.

L’injection vise à reproduire des signatures IMU détectables, cohérentes avec le contexte routier (pente, sinuosité, type de route), et simulables dans des conditions variées (urbain, campagne, livraison…).

8.2.1 🛑 Freinage brusque

  • Durée : ~0.5 à 1 seconde (5 à 10 échantillons à 10 Hz)
  • Signature typique :
    • acc_x < –3 m/s²
    • Chute nette de la vitesse
  • Effets secondaires :
    • Inclinaison avant (impact sur acc_z)
    • gyro_z négatif si courbe
  • Injection :
    • Rampe descendante sur « acc_x », bruitée
    • Réduction progressive de speed
    • Label : freinage

Inspiré des critères de Dong et al. (2022), pour la classification des freinages via IMU (Dong, Ren, and Zhou 2022).

8.2.2 ⬆️ Accélération vive

  • Durée : ~0.5 à 1 seconde
  • Signature typique :
    • acc_x > +2.5 m/s²
    • Gain de vitesse ≥ 8 km/h
  • Effets secondaires :
    • Stabilisation à vitesse cible
  • Injection :
    • Rampe ascendante sur « acc_x »
    • Oscillation inertielle fine (bruit)
    • Label : acceleration

Reprise du modèle d’AirIMU (Qiu et al., 2023) pour les phases de départ en conduite dense (J. Qiu and Li 2023).

8.2.3 🪵 Dos d’âne

  • Durée : 0.6 à 1.0 s
  • Signature typique :
    • acc_z > +4 m/s² suivi de acc_z < –4 m/s²
    • Oscillation sur gyro_x
  • Effets secondaires :
    • Micro-ralentissement speed
  • Injection :
    • Pic acc_z symétrique
    • gyro_x bruité (oscillation verticale)
    • Label : dos_dane

Conforme au schéma de signature inertielle proposé dans (Hemerly, Cardoso, and Lopes 2017) et validé par RoadAcc.
Cette signature est souvent visible dans les 3 axes IMU et est utilisée comme cas test standard pour les modèles de détection inertielle.

8.2.4 📦 Choc trottoir

  • Durée : ~0.2 à 0.3 s
  • Signature typique :
    • acc_z > +6 m/s²
    • acc_y latéral
    • gyro_y ou gyro_z impulsif
  • Effets secondaires :
    • Décalage latéral local
  • Injection :
    • Pic impulsionnel (acc_z, acc_y)
    • Gyro latéral cohérent
    • La composante gyroscopique peut dépendre de l’angle de montée et de la vitesse d’impact.
    • Label : trottoir

8.2.5 🚧 Nid de poule

  • Durée : ~0.3 s
  • Signature typique :
    • acc_z < –5 m/s² suivi de acc_z > +5 m/s²
    • Bruit gyro_x (impact)
  • Effets secondaires :
    • Perturbation courte de la trajectoire
  • Injection :
    • Double pic inversé acc_z
    • Label : nid_de_poule

Similaire aux profils de Hwang et al. (2020) pour la détection d’anomalies verticales (Hwang, Kim, and Park 2020).

8.2.6 ➿ Virages et ronds-points

  • Durée : quelques secondes
  • Signature typique :
    • acc_y ≠ 0 (force centrifuge)
    • gyro_z ≠ 0 (rotation de cap)
  • Effets secondaires :
    • Déviation continue du heading
  • Injection :
    • Dérivée du heading OSRM
    • Label implicite (détection gyro uniquement)

8.2.7 🕒 Stop et ⏳ Wait

  • Stop moteur éteint :
    • Durée ≥ 2 min, speed = 0, acc_x plat
    • Label : « stop_xxx »
  • Wait moteur allumé :
    • 30 s ≤ durée < 2 min
    • acc_x ≈ 0, gyro bruité
    • Label : wait

Représente les arrêts longs de livraison ou attente client.
Ces arrêts sont également utilisés pour caractériser les micro-phases logistiques dans les tournées (livraisons, pauses, attente client), avec impact potentiel sur l’analyse comportementale.

8.2.8 🚪 Ouverture de porte

  • Durée : ~0.2 à 0.5 s
  • Signature typique :
    • Pic acc_y (latéral)
    • gyro_y ou gyro_z (impulsion rotation)
  • Injection :
    • Amplitude paramétrable
    • Label : « ouverture_porte »

Inspiré du modèle proposé par Guo et al. (2021) pour l’analyse des micro-gestes en IMU (Guo, Sun, and Li 2021).

8.2.9 Principes d’injection

  • Espacement minimal entre événements (≥ 50 échantillons (soit ≥ 5 secondes à 10 Hz))

  • Respect du contexte : pente, vitesse, route

  • Pas de chevauchement

  • Injection via « apply_xxx() » dans « generation.py »

  • Configurables via « config.yaml » (amplitude, bruit, durée)

  • Ajout automatique du label « event » dans la trace

  • Un log de validation est généré à chaque simulation pour vérifier la cohérence des amplitudes et la non-superposition des événements.

La qualité de cette injection conditionne la capacité à détecter les événements via des méthodes robustes de classification ou de détection de pics (cf. section 5.3).

8.3 Signatures inertielles caractéristiques des événements simulés

Chaque événement simulé dans RoadSimulator3 est défini par une signature inertielle caractéristique, constituée d’un motif spécifique sur un ou plusieurs axes d’accélération (acc_x, acc_y, acc_z) et de rotation (gyro_x, gyro_y, gyro_z). Ces signatures sont dérivées à partir :

  • Des spécifications physiques (accélération minimale, durée typique),

  • Des observations issues de données réelles (IMU sur véhicules),

  • Des modèles utilisés dans la littérature (profil synthétique, bruit MEMS, impulsion gyroscopique).

Ces signatures permettent à la fois une injection réaliste et une détection fiable (cf. section 5.3).

8.3.1 Tableau synthétique des signatures par événement

Événement Signal clé Seuil typique Durée min. Commentaire
Freinage brusque acc_x acc_x < –3.0 m/s² ≥ 0.5 s Décélération nette, perte de vitesse
Accélération acc_x acc_x > +2.5 m/s² ≥ 0.5 s Montée rapide de vitesse
Dos d’âne acc_z + gyro_x pic acc_z > +4 puis < –4 m/s² ~0.6–1.0 s Bosse puis creux, oscillation verticale
Nid de poule acc_z acc_z < –5 puis > +5 m/s² < 0.3 s Choc vertical impulsif
Trottoir latéral acc_z + acc_y acc_z > +6 ± acc_y latéral < 0.3 s Saut vertical + secousse latérale
Rond-point acc_y + gyro_z acc_y ≠ 0 & gyro_z ≠ 0 > 2 s Rotation continue dans virage circulaire
« Stop » speed + acc_x speed = 0 & acc_x ≈ 0 ≥ 120 s Véhicule à l’arrêt complet
« Wait » speed + acc_x speed ≈ 0 & acc_x ≈ 0 30–120 s Attente moteur tournant
« Ouverture porte » gyro_y ou gyro_z pic gyroscopique impulsif instantané Pic unique lors du mouvement latéral

8.3.2 Exemple de signature : freinage brusque

Conditions

  • Fréquence : 10 Hz
  • Durée : 0.8 s → 8 points
  • Index de début : \(i\)

Forme :

\[ acc_x[i:i+7] = -3.5 + \mathcal{N}(0, 0.15^2) \] \[ speed[i:i+7] \to speed[i] - \Delta v \] #### Résultat :

  • Chute nette sur acc_x
  • Réduction de la vitesse dans le segment
  • Légère perturbation acc_z (roulis avant)

8.3.3 Exemple de signature : dos d’âne

\[ acc_z[i:i+4] = [9.81, 14.2, 12.1, 6.3, 9.81] + \mathcal{N}(0, 0.1^2) \] \[ gyro_x[i:i+4] = [0.1, 2.3, –1.9, 0.0] \]

  • Courbe en bosse sur acc_z
  • Impulsion sur gyro_x (mouvement vertical)

8.3.4 Construction guidée par la détection

Chaque signature inertielle est conçue pour être détectable automatiquement par les fonctions de détection (cf. section 5.3), qui utilisent :

  • Un seuil sur l’accélération ou le gyroscope,
  • Une durée minimale,
  • Un profil temporel (pic, bosse, sinusoïde…),
  • Un contexte routier influençant la probabilité d’apparition : typologie de route (ex : zone résidentielle), courbure, proximité de carrefour ou rond-point.

8.4 Algorithmes d’injection et d’ordonnancement des Événements

L’injection d’événements inertiels dans une trajectoire simulée constitue une étape critique de RoadSimulator3. Elle repose sur des algorithmes déterministes ou semi-aléatoires visant à insérer des événements inertiels réalistes dans des positions spatio-temporelles cohérentes, tout en garantissant l’absence de conflit et une distribution plausible.

8.4.1 Objectifs de l’injection

L’injection a pour but :

  • De reproduire des scénarios de conduite réalistes, en dispersant des événements inertiels typiques (freinages, dos d’âne, etc.).

  • De permettre la validation croisée entre injection et détection (cf. Chapitre 6).

  • De diversifier les contextes : type de route, pente, vitesse, virage, etc.

  • D’assurer la non-chevauchement des signatures inertiels (espacement minimal requis).

8.4.2 Schéma général d’injection

[Trajectoire interpolée à 10 Hz] ↓ [Analyse des zones propices] ↓ [Application des contraintes (espacement, vitesse, type de route)] ↓ [Choix des indices pour injection] ↓ [Application des fonctions « generate_xxx() »] ↓ [Ajout dans les colonnes « acc_x », « acc_y », « acc_z », « gyro_x/y/z », « event »]

8.4.3 Contraintes d’injection

Chaque événement obéit à des contraintes contextuelles, codées dans un fichier « config.yaml » :

Événement Contexte requis Exclusion Espacement minimal
Freinage Vitesse > 20 km/h, route droite Zone de montée 10 s
Accélération Phase de redémarrage ou plat Virage 10 s
Dos d’âne Route résidentielle, vitesse < 30 km/h Autoroute 15 s
Nid de poule Route secondaire, acc_z calme Déjà un dos d’âne 10 s
Trottoir Vitesse < 10 km/h, acc_y faible Intersection 8 s
Stop / Wait Vitesse nulle, proche POI / stop Aucun 15–30 s
Ouverture porte Uniquement après stop Aucun immédiatement après

8.4.4 Ordonnancement des événements

Un algorithme d’ordonnancement gère :

  • Le tirage aléatoire contrôlé des indices candidats.

  • La priorisation de certains types d’événements (ex : au moins un freinage, un dos d’âne…).

  • La vérification des distances minimales entre événements.

  • L’évitement des zones de transition ou de virage.

Exemple : injection de 5 types d’événements → sélection aléatoire parmi 10000 points → garde uniquement les 5 meilleurs emplacements respectant toutes les contraintes.

8.4.5 Injection effective

Les fonctions generate_xxx_event(index) appliquent une signature inertielle complète autour de l’index donné, sur une fenêtre (typiquement 5–10 points).

Elles modifient simultanément :

  • « acc_x », « acc_y », « acc_z »

  • « gyro_x », « gyro_y », « gyro_z »

  • « event » : nom de l’événement

  • speed : si pertinent (freinage, accélération)

Elles garantissent également :

  • L’absence de saturation du signal (éviter des pics irréalistes),
  • L’ajout d’un bruit inertiel réaliste sur les axes non principaux,
  • La continuité inertielle en conservant les dérivées cohérentes.

8.4.6 Exemple d’injection automatisée

df = simulate_base_trajectory()
df = inject_all_events(df, config=config_dict)

Le module inject_all_events() applique tous les événements en suivant le schéma ci-dessus. Un log affiche les événements injectés et leurs emplacements.

8.4.7 Comparaison avec SIMU‑IMU

Le framework SIMU‑IMU (Trung et al., 2022) propose une génération synthétique de données IMU à partir de trajectoires, en appliquant des signatures inertiels typiques. Toutefois, sa logique reste essentiellement statique : les événements sont injectés de manière régulière ou arbitraire, sans prise en compte fine du contexte routier, de la topographie ou de la vitesse.

En comparaison, RoadSimulator3 applique une logique dynamique et contextualisée :

  • Les événements sont sélectionnés en fonction du type de route, de la vitesse, de la pente ou encore des virages à proximité.
  • L’ordonnancement impose un espacement minimal et des exclusions croisées pour garantir un réalisme temporel.
  • L’algorithme injecte également les effets sur la vitesse, les gyroscopes et les dérivées du signal.

Ainsi, si SIMU‑IMU fournit une base générique utile, RoadSimulator3 va plus loin en assurant une inertie réaliste contextualisée, ce qui renforce la pertinence des jeux de données générés pour l’apprentissage automatique et la détection embarquée.

Cette approche permet donc une simulation plus fine, adaptée aux exigences des algorithmes modernes de détection ou de classification embarquée.

8.4.8 Conclusion

L’algorithme d’injection d’événements dans RoadSimulator3 garantit :

  • Une diversité réaliste des scénarios,

  • Une cohérence contextuelle (type de route, vitesse, pente),

  • Une compatibilité directe avec les fonctions de détection,

  • Une évaluation quantitative possible (taux de détection).

8.5 Bruit inertiel et incertitudes simulées

Les capteurs inertiels (IMU) embarqués à bord des véhicules présentent naturellement des imperfections, liées à la qualité du matériel, aux conditions environnementales et aux erreurs de fabrication. Pour simuler des données exploitables et comparables aux mesures réelles, il est indispensable d’y intégrer des modèles réalistes de bruit inertiel.

8.5.1 Nature des erreurs IMU

Les erreurs des capteurs IMU sont classiquement divisées en deux grandes catégories :

  • Erreurs stochastiques (bruit) :
    • Bruit blanc (Gaussian white noise)
    • Bruit coloré (Random Walk, Flicker Noise)
    • Drift (dérive lente du biais)
  • Erreurs systématiques :
    • Biais fixe (offset)
    • Erreur d’échelle (scale factor)
    • Mauvais alignement des axes

Ces erreurs sont typiques des capteurs MEMS low-cost largement utilisés dans l’automobile, les smartphones ou les balises GPS autonomes.

8.5.2 Modèles intégrés dans RoadSimulator3

RoadSimulator3 intègre plusieurs modèles de bruit inertiel configurables via le fichier config.yaml, avec des valeurs ajustables par l’utilisateur selon les cas d’usage simulés, en cohérence avec les modèles stochastiques décrits dans (Hemerly, Cardoso, and Lopes 2017), (Trung, Hoang, and Nguyen 2022) et (Y. Qiu et al. 2024).

Type de bruit Description Modèle utilisé
Bruit blanc Bruit aléatoire à chaque instant \(\mathcal{N}(0, \sigma^2)\)
Bruit random walk Accumulation lente d’un bruit à basse fréquence \(x_t = x_{t-1} + \epsilon\)
Biais simulé Offset constant ou lentement variable \(b_t = b_0 + \delta \cdot t\)
Drift gyroscopique Dérive lente des gyros Drift simulé comme dérive lente aléatoire (linéaire, exponentielle ou bruit accumulé)
Corrélation croisée IMU Corrélation inertielle entre axes (par ex. virage gauche → acc_y + gyro_z) Matrice de covariance empirique

Chaque axe inertiel (acc_x, acc_y, acc_z, gyro_x, gyro_y, gyro_z) peut être bruité de manière indépendante ou corrélée.

8.5.3 Application du bruit dans la pipeline

Le bruit est appliqué après génération des signatures événementielles, afin de simuler les imperfections de mesure typiques des IMU. Le module enrich_inertial_coupling() de la pipeline :

  • Génère un bruit temporel corrélé,

  • L’ajoute au signal original tout en conservant les événements,

  • Calcule les moyennes et écarts-types pour contrôle qualité.

Exemple de bruit random walk :

def apply_random_walk(size, sigma=0.01):
    noise = np.random.normal(0, sigma, size)
    return np.cumsum(noise)

L’application du bruit prend en compte l’orientation du véhicule, la pente, et les effets inertiels croisés pour une meilleure cohérence spatiale.

Les signatures sont ainsi préservées mais déformées, ce qui permet de tester la tolérance des algorithmes à une dégradation réaliste du signal.

8.5.4 Étalonnage réaliste des erreurs

Les paramètres de bruit sont ajustés à partir de mesures expérimentales :

  • Benchmarks de capteurs InvenSense, Bosch, STMicro,

  • Références académiques (ex : Qiu et al., 2023), Trung et al., 2022,

  • Comparaison aux enregistrements d’IMU embarquées sur véhicules.

8.5.5 Paramètres typiques des bruits inertiels (ex. MEMS)

Type de bruit Axe concerné RMS typique Modèle Fréquence caractéristique
Bruit blanc acc_x/y/z 0.02 – 0.05 m/s² \(\mathcal{N}(0, \sigma^2)\) ≥ 10 Hz
Bruit blanc gyro_x/y/z 0.005 – 0.02 rad/s \(\mathcal{N}(0, \sigma^2)\) ≥ 10 Hz
Random walk acc_x/y/z 0.002 – 0.01 m/s²√Hz \(x_t = x_{t-1} + \epsilon_t\) 0.1 – 1 Hz
Random walk gyro_x/y/z 0.0005 – 0.005 rad/s√Hz idem 0.1 – 1 Hz
Biais dérivant acc_x/y/z ±0.1 m/s² \(b(t) = b_0 + \delta t\) très basse fréquence (< 0.1 Hz)
Drift gyroscopique gyro_x/y/z ±0.05 rad/s Modèle exponentiel ou linéaire très basse fréquence
Corrélation inter-axes acc_y vs gyro_z dépend du virage simulé Matrice empirique ~1–2 Hz

Ces valeurs typiques sont ajustables via les paramètres définis dans config.yaml, et peuvent être modifiées selon le type de capteur simulé (smartphone, automotive-grade, etc.).

8.5.6 Intérêt pour la recherche

Simuler un bruit inertiel réaliste permet de :

  • Tester la robustesse des algorithmes de détection d’événements,

  • Comparer différents filtres de traitement du signal (Kalman, Savitzky-Golay…),

  • Simuler différents niveaux de qualité capteurs : smartphone vs automotive-grade,

  • Analyser l’impact des erreurs sur la fusion GPS-IMU.

8.5.7 Visualisation du bruit

Chaque simulation génère des graphiques de validation du bruit :

  • Histogrammes des valeurs d’accélérations,

  • Moyennes, variances et auto-corrélations,

  • Comparaison avant / après ajout du bruit.

  • Heatmap 2D acc_x vs acc_y pour explorer les signatures dynamiques enrichies

  • Diagrammes temporels avec superposition bruit vs signal brut

Cela permet de vérifier que le bruit ajouté reste dans une plage réaliste.

La figure suivante compare un signal inertiel injecté (ex. freinage ou accélération) à la détection correspondante. Elle permet de visualiser la précision temporelle et l’intensité de la réponse détectée.

Figure 5.1 – Comparaison entre injection et détection inertielle (accélération longitudinale \(a_x\))

Toutes les simulations sont reproductibles en fixant une graine aléatoire (random_seed) dans le fichier de configuration.

8.5.8 Conclusion

La simulation de bruit inertiel dans RoadSimulator3 constitue une brique essentielle pour garantir la plausibilité des données simulées. Elle renforce :

  • La fidélité des signaux aux conditions réelles de mesure,

  • La validité des tests de détection et de fusion capteurs,

  • Et la capacité à simuler des cas d’usage industriels complexes.

Ces modèles sont directement inspirés des travaux sur la modélisation des erreurs IMU low-cost pour la robotique mobile et les véhicules connectés.

8.6 Injection de bruit gyroscopique et couplage inertiel

Au-delà des accélérations linéaires (\(a_x\), \(a_y\), \(a_z\)), les vitesses angulaires mesurées par le gyroscope (\(\omega_x\), \(\omega_y\), \(\omega_z\)) jouent un rôle crucial dans la simulation et l’analyse du comportement dynamique du véhicule. Leur simulation réaliste dans RoadSimulator3 repose à la fois sur des modèles de mouvement angulaire et sur l’injection de bruit gyroscopique corrélé, couplé aux événements inertiels.

8.6.1 Sources de variation des gyroscopes simulés

Les variations angulaires d’un véhicule sont principalement dues à :

  • Les changements de direction (virages, ronds-points, intersections),

  • Les franchissements verticaux asymétriques (trottoirs, dos d’âne inclinés),

  • Les perturbations latérales (chocs ou obstacles latéraux),

  • Le roulis ou tangage induits par le terrain ou la vitesse.

8.6.2 Modélisation des gyroscopes

Les signaux simulés pour les gyroscopes respectent les lois physiques suivantes :

  • \(\omega_z\) (axe vertical) : activé dans les virages ou ronds-points, calculé à partir du changement de cap (heading) : \[ \omega_z = \frac{\Delta \theta}{\Delta t} \]
  • \(\omega_x\) (axe longitudinal) : activé lors des passages verticaux brusques (dos d’âne, nid de poule) simulant le tangage.
  • \(\omega_y\) (axe latéral) : utilisé pour simuler le roulis lors de chocs latéraux (trottoir).

8.6.3 Couplage inertiel : événements + gyros

Chaque événement inertiel génère une signature gyroscopique spécifique. Par exemple :

Événement Accélération dominante Gyroscope impacté Description
Virage serré \(a_y\) \(\omega_z\) Rotation du cap
Dos d’âne \(a_z\) \(\omega_x\) Tangage vertical
Trottoir latéral \(a_y\), \(a_z\) \(\omega_y\), \(\omega_x\) Choc latéral + roulis
Rond-point \(a_y\) \(\omega_z\) Rotation continue
Nid de poule \(a_z\) \(\omega_x\) Pic impulsif sur tangage

Ce couplage inertiel réaliste est injecté automatiquement dans la pipeline via la fonction « apply_all_events() ».

8.6.4 Injection de bruit gyroscopique

Les signaux gyroscopiques simulés sont bruités comme suit :

  • Bruit blanc : modèle \(\mathcal{N}(0, \sigma^2)\)

  • Random walk : cumul de variations lentes

  • Biais dynamique : dérive simulée

Exemple (Python) :

def simulate_gyro_noise(size, sigma=0.005, drift=0.001):
    white = np.random.normal(0, sigma, size)
    bias = np.cumsum(np.random.normal(0, drift, size))
    return white + bias

8.6.5 Visualisation et validation

Chaque signal « gyro_x »/« gyro_y »/« gyro_z » est tracé avec :

  • Son évolution temporelle,

  • Ses moments de pic lors d’événements détectés,

  • Sa distribution statistique (moyenne, écart-type).

Cela permet de valider que :

  • Les pics gyroscopiques coïncident avec les événements inertiels attendus,

  • Le bruit simulé respecte les caractéristiques des capteurs embarqués réels.

8.6.6 Utilité de la simulation gyroscopique

L’intégration réaliste des gyros dans RoadSimulator3 permet de :

  • Tester des algorithmes de fusion GPS/IMU incluant heading + rotations,

  • Simuler des erreurs angulaires typiques des capteurs MEMS,

  • Valider des modèles de ronds-points ou de virages par leur signature rotationnelle,

  • Générer des datasets multi-degrés de liberté (6 DoF) pour l’apprentissage automatique.

8.6.7 Visualisation – variation de la courbure

La courbure d’une trajectoire simulée permet d’identifier les zones de rotation ou de changement de cap. La figure suivante montre la courbure calculée à partir de la variation de heading (\(\Delta \theta\)).

Variation de la courbure le long de la trajectoire

8.6.8 Visualisation – sinuosité locale

En complément, la sinuosité glissante permet de quantifier la complexité de la trajectoire. Elle est utile pour adapter la vitesse ou détecter des ronds-points et virages prolongés.

Sinuosité locale calculée sur une fenêtre glissante

8.6.9 Conclusion

La simulation gyroscopique enrichit significativement la qualité des données simulées en reproduisant :

  • Des comportements angulaires réalistes,

  • Des signatures couplées événement + rotation,

  • Et des erreurs représentatives des IMU réelles.

8.7 Tests unitaires et validation des signatures inertiels

Afin de garantir la fiabilité, la traçabilité et la reproductibilité scientifique des événements simulés dans RoadSimulator3, un ensemble complet de tests unitaires a été conçu. Ces tests valident que :

  • chaque événement inertiel est injecté avec une signature fidèle sur les six axes IMU (acc_x, acc_y, acc_z, gyro_x, gyro_y, gyro_z) ;

  • l’événement est automatiquement détectable par les algorithmes internes (detect_xxx()) ;

  • les paramètres (durée, amplitude, bruit) respectent les contraintes physiques et la configuration YAML.

8.7.1 Objectifs des tests

Les tests inertiels visent à vérifier :

  1. La forme temporelle attendue de chaque événement (durée, rampes, pics, retour à l’équilibre) ;

  2. La cohérence des trois axes d’accélération et des trois axes gyroscopiques ;

  3. La capacité de détection automatique dans un environnement bruité ;

  4. L’absence de faux positifs sur des points adjacents ou proches ;

  5. L’impact dynamique sur la vitesse, la position et le heading du véhicule.

8.7.2 Procédure systématique

Chaque événement dispose d’un couple de fonctions :

  • generate_xxx() pour l’injection ;

  • detect_xxx() pour la détection automatique.

Ces fonctions sont testées ensemble pour chaque cas inertiel.

Exemple – Dos d’âne :

df = simulate_empty_trajectory(duration=10s)
df = generate_dos_dane(df, index=100)
detected = detect_dos_dane(df)
assert 100 in detected  # tolérance ±1

8.7.3 Visualisation automatique

Chaque test unitaire génère :

  • Un graphe des signaux IMU (6 axes) ;

  • Des surbrillances colorées :

    • Rouge : point injecté,

    • Vert : point détecté.

Cette visualisation immédiate permet de vérifier la signature inertielle, y compris en présence de bruit simulé réaliste.

8.7.4 Couverture des événements

Tous les événements inertiels sont testés :

Événement acc_x acc_y acc_z gyro_x gyro_y gyro_z
Accélération vive ✅
Freinage brusque ✅ (⭘)
Dos d’âne ✅ ✅
Trottoir latéral ✅ ✅ ✅ ✅
Nid de poule ✅ ✅
Rond-point / virage ✅ ✅
Arrêt (STOP) (⭘)
Attente (WAIT) (⭘)
Ouverture de porte ✅ ✅ ✅

(⭘) : indirectement affecté ou invariant.

8.7.5 Détection croisée et bilan

Un module global (validate_events.py) applique toutes les fonctions detect_xxx() sur le DataFrame simulé, et produit un bilan par événement :

[VALIDATION INERTIELLE] ✔ 5 dos d’âne injectés → 5 détectés ✔ 3 nids de poule injectés → 3 détectés ✔ 4 trottoirs injectés → 4 détectés ✔ 1 ouverture de porte détectée ❌ 1 freinage trop faible non détecté → Taux global de détection : 96.3 % → Faux positifs : 0 → Délai moyen de détection : ±0.1 s

Chaque détection est corrélée à la position GPS, au timestamp, et à l’index dans le CSV.

8.7.6 Confirmation des ronds-points par delta de heading

Les événements de type rond-point ou virage serré sont initialement détectés à partir des tags OSRM ou OSM.
Cependant, une validation supplémentaire est réalisée via la fonction confirm_roundabouts_by_delta_heading() qui mesure la variation angulaire cumulative du cap du véhicule.

Un rond-point valide présente une variation de heading typique supérieure à 180° sur une fenêtre glissante de 20 à 30 points (soit 2 à 3 secondes à 10 Hz).

Exemple illustré

Exemple de variation de heading dans un rond-point

En bleu : trajectoire simulée – En rouge : segments de forte variation angulaire.

Cette confirmation inertielle permet :

  • d’éviter les faux positifs sur des virages longs mais progressifs,
  • de valider la circularité d’un segment simulé,
  • d’ajouter de la robustesse dans les annotations supervisées.

8.7.7 Résilience aux perturbations

Tous les tests sont conduits :

  • Sur une trajectoire bruitée (acc + gyro), à 10 Hz,

  • Avec interpolation GPS réaliste,

  • Avec variation de heading et de vitesse,

  • Avec injection de bruit inertiel MEMS réaliste.

Cette robustesse garantit une validation crédible pour l’usage en recherche, automobile, ou applications embarquées.

8.7.8 Conclusion

Les tests inertiels de RoadSimulator3 assurent :

  • Une vérification systématique de chaque type d’événement,

  • Une détection robuste et automatisable,

  • Une cohérence inertielle sur les six axes,

  • Une base de confiance pour l’annotation automatique et l’apprentissage supervisé.

Ce cadre de tests rigoureux positionne RoadSimulator3 comme une référence de simulation inertielle validée, conforme aux attentes des chercheurs et industriels dans les domaines de la télématique, de la fusion capteurs, et de la conduite autonome.

8.8 Conclusion

Ce chapitre a présenté la chaîne complète d’injection et de détection des événements inertiels dans le simulateur « RoadSimulator3 ». En se basant sur des profils inertiels réalistes et paramétrés, il permet de simuler des événements clés rencontrés en conduite réelle : freinages, accélérations, dos d’âne, chocs, nids-de-poule, mais aussi arrêts moteur ou ouverture de porte.

Les contributions majeures peuvent être résumées ainsi :

  • Une modélisation inertielle événementielle réaliste, intégrant les accélérations longitudinales, latérales, verticales, et les vitesses angulaires, en accord avec les profils expérimentaux issus de la littérature (Zhang, Wang, and Zhou 2024; Boudani et al. 2020).

  • L’injection contrôlée de ces événements dans les données GPS/IMU à 10 Hz, respectant des durées, amplitudes et signaux bruités selon les modèles stochastiques de capteurs MEMS décrits par (Hemerly, Cardoso, and Lopes 2017).

  • Le développement de détecteurs spécialisés fondés sur :

    • des règles simples (seuils inertiels),

    • des signatures temporelles analysées par fenêtres glissantes,

    • des dérivées du signal (pente, courbure),

    • des techniques avancées comme le filtrage de Kalman ou l’apprentissage automatique supervisé. Par exemple, Udah and Cheng (2023) ont proposé un système intelligent de détection routière combinant IMU et CNN pour identifier les irrégularités, ou encore Chen, Cho, and Shin (2017), qui ont révélé des caractéristiques de routes à partir d’IMU embarquées dans des téléphones mobiles.

  • Une logique de validation croisée injection ↔︎ détection, assurant la robustesse des profils et la qualité des labels associés, comme recommandé dans (Fan, Wang, and Liu 2019).

Cette approche garantit :

  • Une cohérence inertielle temporelle et spatiale des événements,

  • Leur détection automatisable par des algorithmes standards,

  • Leur utilisation directe comme base d’entraînement pour des modèles de détection embarqués ou d’analyse comportementale.

Plusieurs travaux récents viennent renforcer cette approche : (Dong, Ren, and Zhou 2022; Guo, Sun, and Li 2021; He, Zhang, and Lee 2019; Palanisamy, White, and Rizzoni 2020; Trung, Hoang, and Nguyen 2022).

Ces références complètent ainsi les contributions méthodologiques et technologiques exposées dans ce chapitre.

« RoadSimulator3 » apporte ainsi une réponse structurée et scientifique à un besoin critique : générer des jeux de données synthétiques, annotés, et exploitables pour la recherche comme pour l’industrie.

Les événements simulés sont exportés dans un format standardisé (CSV/JSON), et visualisables sur carte ou graphiques. Ils constituent un socle robuste pour les applications traitées dans les chapitres suivants, notamment les indicateurs analytiques (Chapitre 6) et les usages concrets (Chapitre 7).