Définition des caractéristiques des données

La caractérisation des sources et des scènes d’intérêt, combinée au bilan des travaux de

l’état de l’art laisse imaginer les caractéristiques des données souhaitées. Nous les

formu-lons précisément dans cette section. Après cela, nous recherchons l’existence d’un corpus

de données correspondant et, à défaut, l’existence d’outils de collecte pertinents.

3.1.3.1 Caractéristiques des données

Nous souhaitons obtenir des données multimodales et synchronisées ; réelles et

anno-tées ; et collecanno-tées de manière continue. La synchronisation est justifiée par la présence de

plusieurs sources. Ensuite, nous souhaitons acquérir des données réelles, collectéesin vivo,

car les scènes d’intérêt représentent des situations quotidiennes, difficiles à reproduire en

laboratoire (c’est le cas des transports motorisés par exemple). En outre, l’appareil visé par

l’application industrielle est le smartphone. La collecte de données directement depuis

l’ap-pareil permet de travailler avec des données représentatives du contexte de fonctionnement

du système final de reconnaissance. En outre, l’usage du smartphone pour la collecte est

aussi opportun car l’appareil est emporté dans de nombreux endroits par son utilisateur.

L’annotation des données est nécessaire pour pouvoir analyser le corpus acquis et, par suite,

procéder à une phase d’apprentissage supervisé pour construire le système de

reconnais-sance de scène. Enfin, l’enregistrement continu des données est important pour la capture

des transitions entre les scènes.

1. La documentation en ligne des développeurs pour Android répertorie de nombreuses sources acces-sibles. L’adresse suivante permet d’accéder à la page d’entrée du sujethttp://developer.android. com/guide/topics/sensors/sensors_overview.html.

3.1.3.2 État de l’art des bases et outils de collecte de smartphone

Comme nous l’avons dit dans le chapitre de l’état de l’art, le smartphone a fait l’objet de

nombreuses recherches. Il existe ainsi un petit nombre de corpus accessibles. Parmi les

pre-mières bases collectées, les travaux de Pentland et coll. (2006), au milieu des années 2000, ont

lancé le projetReality Mining pour la collecte de données sur téléphones. Les smartphones

démarraient à peine, aussi les téléphones employés disposaient de peu de capteurs. Le

cor-pus collecté se compose des informations d’appels passés, des connexions d’appareils en

Bluetooth, des connexions aux antennes-relais, de l’usage des applications de l’appareil et

d’informations sur l’état de fonctionnement telles que le niveau de charge de la batterie. Les

annotations ont été effectuées semi-automatiquement : le système identifiait des

antennes-relais préalablement associées par l’utilisateur à des étiquettes de lieux sémantiques tels que

le domicile ou le lieu de travail. 90 volontaires ont participé à cette collecte. Les limites de

sources et de labels de cette base justifient que nous ne l’ayons pas exploité.

En 2010, Kiukkonen et coll. (2010) ont réalisé une collecte à grande échelle dans la région

de Lausanne, en partenariat avec Nokia et connue sous le nom deLausanne Data Collection

Campaign(abrégé par LDCC). La base de données se compose de coordonnées de

localisa-tion par GPS, d’informalocalisa-tions sur l’usage des applicalocalisa-tions (prise de photo ou vidéo, agenda,

répertoire téléphonique, communications par SMS et appels) et de données d’accélérations

et acoustiques. Près de 200 volontaires y ont participé. Cependant, nous n’avons pas utilisé

ce corpus pour plusieurs raisons : l’enregistrement des échantillons sonores ne convenait

pas (effectué par période de 30 secondes, espacées de plusieurs minutes) ; le corpus est

de-venu inaccessible après la période d’évaluation ; les annotations associées aux données ne

correspondent pas aux scènes que nous recherchons.

Récemment, Wagner et coll. (2014) de l’université de Cambridge ont rapporté la

réali-sation d’une collecte d’une très grande ampleur intitulée Device Analyzer. Les auteurs se

targuent de plus de 26000 téléchargements de leur application de collecte et rapportent

16000 participants volontaires (dont plus de 4700 auraient participé pendant plus d’un

mois). De nombreuses sources sont collectées, bénéficiant des divers capteurs embarqués

sur les smartphones employés et des possibilités d’accès à de nombreuses informations de

fonctionnement de l’appareil (dont nous citons quelques exemples : l’usage d’une carte

ex-terne de mémoire, le nombre de contacts dans le répertoire, la taille de l’espace mémoire

libre ou la version du système d’exploitation). Cependant, l’absence de données sonores et

d’annotations correspondant aux scènes recherchées ne nous ont pas incités à exploité ce

corpus.

Les caractéristiques des données que nous avons énoncées deviennent des contraintes

pour la sélection d’une base de données satisfaisante. Aussi, nous envisageons d’effectuer

notre propre collecte et, pour cela, nous rapportons les résultats d’une recherche d’outils

adaptés.

La recherche s’est principalement orientée vers les outils sur smartphones car ce

der-nier est l’appareil visé par l’application du partenaire industriel et il a été employé dans les

trois collectes rapportées. Il paraît également très adapté à l’enregistrement des données

suivant les caractéristiques énoncées. Ses nombreuses sources embarquées ont déjà été

évo-quées et l’accès aux indications d’horodatage fournies avec les données permet la

synchro-nisation. Il est idéal pour une collectein vivocar la plupart des personnes qui en possèdent

un l’emportent dans de nombreuses situations quotidiennes. Grâce à ses ressources, il est

envisageable d’effectuer des enregistrements continus sur plusieurs heures, garantissant la

capture de transitions entre des scènes. Cependant, le problème de l’annotation reste ouvert

pour le moment.

L’outil Open Data Kit (abrégé ODK) est conçu pour la collecte de données sur

smart-phone sans requérir des expérimentateurs des compétences en programmation

informa-tique. À son lancement en 2010, l’outil prévoit trois fonctions (Hartung et coll.2010) : une

in-terface graphique pour renseigner les caractéristiques de la collecte (par exemple les sources,

l’échantillonnage, ou la durée) ; la création automatique de l’application et l’installation sur

les appareils pour la collecte ; le transfert et le stockage des données sur des serveurs dédiés.

Au lancement, peu de sources de données étaient disponibles (appareil photo, GPS et usage

de l’écran tactile). Une mise à jour a été proposée en 2013 (Brunette et coll.2013) incluant

notamment la possibilité de gérer plus de sources de données (internes et externesviades

liaisons Bluetooth et USB). Cependant, nous n’avons pas pu déterminer précisément le

ni-veau de sécurité et d’anonymat des données prévu par l’outil. Pour cette raison, nous ne

l’avons pas utilisé pour notre collecte.

Le résultat le plus adapté au cours de nos recherches est le projet Funf

²

lancé en 2011

et publié par Aharony et coll. (2011) qui permet la collecte et la sauvegarde sur un serveur

de nombreuses sources du smartphone. Il se présente sous trois formes qui reposent sur le

même code : une application, un service et une bibliothèque de code libre d’accès.

L’applica-tion, appelée Funf Journal

3

et disponible sur la plateforme de téléchargement Google Play,

permet la collecte de nombreuses sources et le transfert vers un serveur. Mais la

configu-ration de ces sources est limitée et ne permet pas un enregistrement continu pendant une

longue période. Le service, appeléFunf in a Box, est destiné à des expérimentateurs qui

sou-haitent disposer d’un outil sans avoir à le développer. Il permet de créer et configurer

l’ap-plication à travers un formulaire, puis de la télécharger et, enfin, de disposer d’un compte

Dropbox pour sauvegarder les données des participants. L’inconvénient de cette solution

est la dépendance à un service de sauvegarde extérieur et les problèmes de respect de la vie

privée que cela pose. Enfin, la bibliothèque propose le code sous licence LGPL

⁴

. L’étude du

code confirme la présence de toutes les sources qui nous intéressent. Cependant, son usage

a semblé complexe et peu documenté et ne disposait pas d’exemples d’intégration à une

ap-plication Android. À l’inverse, la documentation en ligne d’Android présente de nombreux

2. http://www.funf.org/

3. https://play.google.com/store/apps/details?id=edu.mit.media.funf. journal

4. GNU Lesser General Publicou licence publique générale GNU est une licence pour gérer l’utilisation de logiciels. Elle est moins restrictive que la licence GNU GPL, dont elle découle, car elle permet de créer un outil ou une ressource ditepropriétairequi exploite des outils libres, eux-mêmes sous licence LGPL.

exemples sur l’usage des capteurs et les objets nécessaires à leur manipulation. C’est

pour-quoi nous n’avons pas choisi d’utiliser la bibliothèque du projet Funf mais avons décidé de

créer notre propre application pour la collecte.

Dans le document Reconnaissance de scènes multimodale embarquée (Page 64-67)