Source : Proceedings of RoCHI 2022, p. 108-114 · DOI 10.37789/rochi.2022.1.1.18 · University of Craiova (Roumanie) · accès OPEN · PDF Cojocaru2022-SmartphoneTelematicsPartII.pdf, sha256 e10b11762ee8e9889da9…, 7 pages Lu le : 2026-11-02. LECTURE COMPLÈTE (texte, tableaux 1 à 6 et figures 5 à 7 relus sur les pages 5 et 6 du PDF ; références parcourues, non vérifiées). Statut summarized. Thème : detection · classification du style de conduite par smartphone Métadonnées vérifiées dans le PDF : le titre imprimé est « Driver Behaviour Analysis based on Deep Learning Algorithms », pas « In-Vehicle Smartphone Sensing for Driving Behaviour Analysis (Part II) » (titre du corpus, sans équivalent dans le PDF). Trois auteurs (le corpus n’en cite qu’un, « Cojocaru, I. et al. »). Année 2022 conforme, DOI imprimé. Le PDF est distinct de celui du citekey voisin Cojocaru2022-SmartphoneTelematics (sha256 8f31466b…, « Building a Driving Behaviour Dataset », DOI …1.17) : même session RoCHI 2022, même équipe, deux papiers différents (le premier présente le jeu de données, celui-ci le module d’estimation).

Contexte et question

Les auteurs décrivent le module d’estimation du style de conduite d’une application de covoiturage (deux applications Android, client et conducteur, plus un serveur). Ils motivent le besoin par le repérage de conducteurs agressifs et par le choix du client, qui peut préférer un conducteur rapide ou lent. La question : quelle architecture de réseau récurrent classe le mieux un style de conduite à partir du seul accéléromètre et gyroscope d’un téléphone ?

Méthode

• Capteurs : accéléromètre et gyroscope du téléphone uniquement. La vitesse GPS est écartée volontairement : « Aggressive driving can be performed at different speeds » (p. 109), et la limite de vitesse varie selon les pays.
• Le téléphone doit être fixe dans le véhicule (support de pare-brise admis) ; un téléphone posé sur la planche de bord ou un siège peut fausser les mesures (p. 108-109).
• Trois modèles TensorFlow comparés : LSTM, ConvLSTM, CNN-LSTM, exportés en tflite pour une estimation hors ligne dans l’application conducteur (Java).
• Motif du choix de LSTM : un événement isolé (freinage fort, nid-de-poule) ne dit rien du style, il faut une séquence (p. 110).
• Fenêtres de 6 à 18 instances ; à 2 échantillons par seconde, une fenêtre couvre la moitié de son nombre d’instances en secondes (en-tête des tableaux : « ½ * window size »).
• Deux configurations d’étiquettes : 3 classes (SLOW, NORMAL, AGGRESSIVE) puis 2 classes (SLOW et NORMAL fusionnées).
• Évaluation sur un second jeu collecté sur un autre trajet (p. 110).
• Paramètres déclarés : LSTM à 3 classes, 2 389 891 paramètres (Fig. 5) ; ConvLSTM, 12 611 (Fig. 6) ; CNN-LSTM, 2 026 755 (Fig. 7).

Données

• 8 attributs : accélération X, Y, Z (m/s²), rotation X, Y, Z (°/s), étiquette, horodatage (p. 111).
• Échantillonnage : « 2 samples per second » ; la gravité est retirée (p. 111).
• Deux jeux publics sur Kaggle (entraînement et test), collectés sur des trajets différents ; les combiner peut biaiser les résultats (p. 111).
• Le PDF ne donne ni le nombre de conducteurs, ni le nombre d’échantillons, ni la durée totale, ni le véhicule, ni la méthode d’étiquetage.

Résultats chiffrés

Exactitude (accuracy) ; la durée est la moitié du nombre d’instances.

(n/d : non évalué dans l’article. Fenêtres évaluées : 16, 12, 8, 6 pour les tableaux 1, 3, 4, 6 ; 18, 16, 8, 6 pour le tableau 5 ; 18, 16, 8 pour le tableau 2.)

Chiffres principaux, avec ancre :

• CNN-LSTM, 2 classes, 12 instances : 91,94 % — « 12 instances 6 sec 91.94% » (Tab. 6, p. 113).
• LSTM simple, 3 classes, meilleure fenêtre : 54,88 % — « the optimum timeframe for computing the driving style is 6 sec, which offers 54.88% accuracy » (Tab. 1, p. 112).
• ConvLSTM, 3 classes, 18 instances : 59,26 % — « 18 instances 9 sec 59.26% » (Tab. 2, p. 112).
• CNN-LSTM, 3 classes, 6 instances : 51,22 % — « 6 instances 3 sec 51.22% » (Tab. 3, p. 113).
• LSTM simple, 2 classes, 12 instances : 82,15 % — « 12 instances 6 sec 82.15% » (Tab. 4, p. 113).
• ConvLSTM, 2 classes, 16 instances : 85,37 % — « 16 instances 8 sec 85.37% » (Tab. 5, p. 113).

Observations des auteurs : fusionner slow et normal améliore l’exactitude pour chaque modèle ; à 3 classes, ConvLSTM est le meilleur, à 2 classes CNN-LSTM ; les deux variantes (Conv et CNN) dépassent le LSTM simple (Conclusion, p. 113). Le résumé affirme qu’il suffit de conduire « more than 10 seconds » pour obtenir une estimation (p. 108), alors que les tableaux n’évaluent que des fenêtres de 3 à 9 s.

Limites déclarées par les auteurs

• Pas d’évaluation sur des fenêtres plus longues, à cause de la taille du jeu (p. 112).
• Résultats à 3 classes « average » (résumé) : de 40 à 59 %.
• Le style d’un conducteur peut changer dans le temps (p. 109) ; un obstacle ou un embouteillage fait varier le style pour un temps court (p. 110).
• Combiner les deux jeux de données peut fausser les résultats (p. 111).
• Le téléphone doit être fixé dans le véhicule.

Ce que ça change pour Teleforge (interprétation, hors de l’article)

• Papier d’ingénierie d’application, pas une référence de détection d’événements inertiels : le jeu est petit, non décrit en volume, et les étiquettes (slow, normal, aggressive) sont celles de l’étiquetage des auteurs, sans critère publié.
• Les 91,94 % ne valent que pour la tâche à 2 classes sur un seul trajet de test ; à 3 classes, les résultats sont proches du hasard pour CNN-LSTM (48 à 51 %). À ne pas citer comme performance générale.
• Utile comme exemple de classification de séquence sur accéléromètre et gyroscope bruts à 2 Hz ; la cadence est très inférieure à celle d’un boîtier télématique.
• L’argument contre la vitesse GPS comme attribut (le style ne dépend pas de la vitesse absolue) est à garder en tête pour toute définition de « conduite agressive ».
• L’ancienne fiche attribuait à ce papier des SVM, forêts aléatoires et CNN 1D, une exactitude supérieure à 90 % toutes classes confondues et des recommandations de métadonnées : rien de cela n’est dans le PDF.