Le véhicule dans son état de base ne permettait aucun retour utilisateur. C’est-à-dire qu’au démarrage du véhicule, que ce soit en mode utilisation classique (pilotage simple avec la télécommande) ou avec l’activation des fonctions ADAS, aucune donnée n’est renvoyée par le véhicule que ce soit en temps réel ou sauvegardé en history logs. Cet aspect du projet présentait trois types d’inconvénients :

❖ Pour les développeurs :

Le suivi des erreurs lors du fonctionnement du véhicule ne pouvait être effectué qu’en se connectant à distance aux cartes électroniques embarquées sur le véhicule. C’est donc fastidieux pour les développeurs de se mettre en mode débogage sur le véhicule.

❖ Du côté d’un utilisateur lambda :

Outre les retours d’erreurs en cas de panne pour les développeurs, aucune information du véhicule n’est communiquée à l’utilisateur. Il s'agit d’informations comme le statut du véhicule, des métriques (vitesse, niveau de batterie, distance parcourue, etc.) par exemple. Nous étions donc loin de ce qui se passe à l’échelle réelle, où l’utilisateur dispose d’un tableau de bord pour interagir avec son véhicule.

❖ En termes d’optimisation ou d’amélioration du système :

Il n’était pas possible de recréer des cas particuliers de bugs du véhicule. C’est-à-dire que non seulement le véhicule ne transmettait aucune information, mais ce dernier n’en enregistrait pas non plus. Ce qui rendait difficile un replay de scénario.

L'enjeu est donc de concevoir une IHM pour assurer la supervision, le contrôle et l'acquisition des données d'une voiture radiocommandée.