Lorsqu’on veut piloter un tel robot, une interface graphique est bien plus pratique qu’une interface en ligne de commande. Mais encore faut-il bien la concevoir.
Et pour ça, au lieu de foncer tête baissée dans le code, on s’interroge sur les besoins (ou "cahier des charges"). Ainsi on ne va pas penser à tout ce qu’on pourrait faire de joli et de clignotant, mais à ce que l’utilisateur (qui peut bien sûr être vous-même) a besoin.
Cahier des charges
Si on reprend le bipède de Easyrobotics, voici les 2 exigences formulées par Nicolas :
– un déplacement autonome : le robot avance en évitant les obstacles
– un déplacement contrôlé : on peut piloter le robot à distance en le faisant avancer, reculer, aller à droite ou à gauche.
Comme je suis aussi un futur utilisateur, je rajoute une exigence :
– un déplacement manuel de chaque mouvement
Interprétation
Il ne faut pas coller aveuglément aux mots qui formulent ces exigences, mais savoir les comprendre, et cela passe par une interprétation, qui donnera lieu à des questions précises qui éviteront toute mauvaise surprise.
Analyse
Ensuite on en déduit le fonctionnement de l’interface, en faisant des listes de spécifications :
– services réalisés par l’interface
– actions utilisateurs possibles
– informations concernées
Services de l’interface
L’interface doit principalement envoyer des commandes au robot. Il faut donc savoir gérer quelles commandes (la source : utilisateur en manuel ou stockage en automatique) et la fréquence (sur déclenchement utilisateur ou de manière régulière, voire paramétrable).
L’interface doit offrir plusieurs modes : il faut pouvoir passer de l’un à l’autre, mais que les commandes restent cohérentes. Ce sera un critère de qualité important qui entrainera des contraintes pour l’utilisateur, il faut donc les prévoir le plus tôt possible.
L’interface doit montrer l’état courant du robot.
Actions utilisateurs
L’utilisateur peut contrôler la position du robot. Il peut intervenir étape par étape dans une séquence de base (avancer/reculer/tourner à gauche/tourner à droite) et visualiser ou changer une position, et sauvegarder sa modification pour les prochaines exécutions.
L’utilisateur ne gère pas le passage en mode automatique, c’est le robot qui détecte une inactivité de 60 secondes et décide de passer en mode automatique. Dans ce cas il est indépendant de l’interface utilisateur (rupture de connexion).
Information utilisée
Cette partie se déduit des précédentes. Il suffit de parcourir les spécifications et de noter toute information entrant en jeu. Attention, cette étape ne considère pas l’implémentation : on peut parler de liste mais on préférera le terme "position courante" à "index courant".
Mais cette partie doit être complétée avec les types de données et les bornes (min/max) des valeurs prises.
Dans notre cas, on détecte :
– la commande envoyée au robot : 4 chiffres de 0 à 9, 1 par moteur, 0 = pas de modification de la consigne précédente
– la position (similaire à la commande, on va les confondre)
– la séquence, composée d’un nombre variable de commandes, commençant toujours par la même (pour la continuité)
– les séquences : il y en a 4, pour avancer/reculer/tourner à gauche/tourner à droite
– une séquence en cours
– une commande en cours
– le mode courant