Source : Proceedings of RoCHI 2022, pp. 101-107 · DOI 10.37789/rochi.2022.1.1.17 · University of Craiova (Roumanie) · accès OPEN · PDF Cojocaru2022-SmartphoneTelematics.pdf, sha256 8f31466b174334ed…, 7 pages Lu le : 2026-11-02. LECTURE COMPLÈTE (texte et Tab. 1-2 relus sur la page image ; figures 1 à 11 non exploitées en valeurs, seulement leurs légendes et commentaires). Statut summarized. Thème : detection · jeu de données de comportement de conduite par smartphone Métadonnées vérifiées dans le PDF : auteurs, titre, année et DOI conformes au PDF. Le titre du corpus (« In-Vehicle Smartphone Sensing for Driving Behaviour Analysis (Part I) ») n’apparaît pas dans le PDF.

Contexte et question

Les auteurs cherchent à analyser le style de conduite (ride-sharing) à partir des seuls capteurs d’un smartphone Android, et n’ont pas trouvé de jeu de données répondant à deux exigences : être étiqueté, et être utilisable par un modèle destiné à une application mobile. Ils publient donc un jeu de données étiqueté en trois classes, « slow », « normal » et « aggressive », accompagné d’expériences censées renseigner sur sa qualité.

Méthode

• Capteurs : accéléromètre et gyroscope seulement, pour une approche générique applicable au plus grand nombre d’appareils. Le GPS est écarté : un conducteur lent peut rouler vite là où la route le permet sans faire de mouvements brusques (§Introduction, p. 101).
• Matériel : smartphone Samsung Galaxy S10, voiture Dacia Sandero 1.4 MPI de 75 chevaux, choisie comme véhicule courant des conducteurs de ride-sharing (p. 101-102). Les auteurs notent qu’une voiture plus puissante différencierait mieux les styles.
• Étiquetage : trois parcours sur le même tronçon, un par classe. « Aggressive » = virages gauche/droite brusques, accélérations et freinages ; « normal » = événements moyens ; « slow » = vitesse inférieure à la moyenne (p. 103).
• Expériences : Random Forest (scikit-learn), XGBoost et réseau dense (TensorFlow) sur une instance isolée (Tab. 1) ; LSTM, CNN LSTM et ConvLSTM sur une fenêtre d’instances (Tab. 2), hyperparamètres cherchés avec keras_tuner (p. 106).

Données

• Deux fichiers de même structure, entraînement et test, fusionnables. Le test suit un autre itinéraire, de sens différent mais de caractéristiques similaires, avec un moment de la journée et un climat similaires, pour mesurer la généricité (p. 102-104).
• Entraînement : 3644 enregistrements (1331 slow, 1113 aggressive, 1200 normal). Test : 3084 instances (1273 slow, 997 normal, 814 aggressive) (p. 103).
• Deux lectures par seconde ; le nombre d’instances varie selon la classe car la conduite agressive dure moins longtemps (p. 103).
• Le bruit du début et de la fin des enregistrements vient des manipulations du téléphone pour changer de style ou démarrer/arrêter l’application ; les auteurs ne le prennent pas en compte (p. 105).
• Disponibilité : jeu de données et notebooks sur Kaggle, code de collecte sur GitHub (notes 1, 2, 6, 7, p. 101-106).
• Analyse descriptive (Fig. 4 à 9, p. 104-105) : l’axe Z de l’accéléromètre est bruité par les défauts de la route ; la conduite agressive montre plus d’accélérations et de freinages (une valeur descend vers -6, p. 105) et plus de forces latérales ; la différence agressif/autres est plus nette qu’entre normal et slow. Les corrélations entre variables sont jugées cohérentes entre entraînement et test (Fig. 10-11, p. 105).

Résultats chiffrés

Exactitude (accuracy) rapportée, sans autre métrique ni intervalle.

Les expériences à 2 classes portent sur normal et aggressive ; celles à 3 ajoutent slow (p. 106). Ancres : jeu d’entraînement « The training file is composed of 3644 recordings; 1331 are classified as slow » (p. 103) ; jeu de test « 3084 divided into 1273 for slow, 997 for normal and 814 for aggressive » (p. 103) ; cadence « we selected two readings per second » (p. 103) ; valeurs des Tab. 1 et 2 : 0.461, 0.795, 0.637 (p. 106). Les auteurs écrivent que la fenêtre donne une exactitude « slightly better » que l’instance isolée (p. 106) ; comparé à l’instance isolée, le gain calculé par nous à partir des tableaux va d’environ 0,11 à 0,20 en valeur absolue (Tab. 1 et 2).

Limites déclarées par les auteurs

• Une instance isolée est une mauvaise unité : la conduite est « évolutive » et un nid-de-poule peut produire une valeur élevée et un faux « agressif » ; la fenêtre est plus tolérante au bruit (p. 106).
• Un conducteur n’est jamais dans une seule classe en ville, le style dépend de l’environnement et du trafic (p. 106).
• Le véhicule est peu puissant : sur une voiture plus lente le modèle peut être moins fiable (p. 102).
• Les résultats « can be further improved » ; le jeu de données demande plus de données quantitatives, d’autres voitures, d’autres conducteurs et d’autres itinéraires (p. 106-107).

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

• Référence utile de jeu de données smartphone IMU étiqueté en trois classes, mais volume modeste (un véhicule, un téléphone, un passage par classe et par itinéraire) : à citer comme point de comparaison, pas comme base de validation.
• Les exactitudes (autour de 0,45 à 0,64 à trois classes) montrent que l’étiquette par parcours reste bruyante ; le papier ne mesure pas la séparabilité par événement.
• Ne dit rien de l’orientation du téléphone dans l’habitacle ni de son redressement : l’hypothèse d’axes alignés sur le véhicule n’est pas discutée.
• Le papier s’appuie sur l’accéléromètre et le gyroscope ; ses résultats ne se transposent pas tels quels à un boîtier sans gyroscope.