Mauvaise journée en perspective car les dialogues entre un humain et un ordinateur ne sont jamais très faciles à établir. Aussi, quand sur le planning de la journée nous constatons qu’il va falloir établir des communications entre la sonde et le pupitre de maîtrise local, nous ne nous sentons pas très à l’aise. Le pire, c’est que pour des raisons budgétaires le Terminal de dialogue sera le Moniteur de l’IDE. Aucune dépense particulière pour piloter à distance JEKERT, en contrepartie il va falloir gérer la ligne série, avec toutes ces complications de conversions de chaînes de caractères en nombres. Heureusement qu’à la RMSI nous avons été sérieusement formés à la programmation des puissants petits ordinateurs Arduino. Sans plus tarder on pénètre dans la salle informatique S4. Gentiment, un technicien nous désigne un grand bureau libre sur lequel nous allons établir les protocoles d’échanges entre la machine électronique embarquée et le Terminal de dialogue.
Notions rudimentaires de dialogue Homme / Machine.
Prétendre en un chapitre couvrir intégralement le sujet relève d’une utopie totale, car un livre gros comme une bible n’y suffirait pas. Dans ces lignes, nous allons ne faire qu’effleurer le sujet. Le juste ce qu’il faut pour comprendre comment vont se dérouler les bavardages entre le bel insecte et la console de maîtrise. Pour commencer, on va considérer que la sonde est notre esclave, et nous les maîtres. Dans un tel cas de figure, l’esclave se place à l’écoute et attend une consigne. Dès qu’un message arrive par l’entremise d’un canal filaire ou hertzien, l’esclave l’enregistre. Puis, il en analyse le contenu. Soit il comprend tout, soit dans le texte reçu, un petit chmolductruc n’est pas prévu dans le langage qu’il connaît. Dans les deux cas il accuse réception en parlant à son tour. Généralement si l’ordre reçu n’est pas cohérent, l’esclave se remet à l’écoute après avoir prévenu le maître. Si la consigne est conforme au langage convenu, l’esclave va alors exécuter les actions qui découlent de la tâche imposée.
Notez au passage que ce type d’échanges est dit en « Mode Alternat » par opposition au « Duplex » pour lequel les deux entités peuvent parler et écouter simultanément. En Alternat un seul canal suffit, alors qu’en Duplex il en faut deux.
RESUMÉ d’un dialogue Homme/Machine de type Maître/Esclave :
Comme pour tout échange d’informations entre deux entités, un langage précis a été développé. Ce langage inclus des mots, de la syntaxe, de la ponctuation etc. Généralement élémentaire dans le monde de la technique, il porte souvent le nom de « Protocole conversationnel ».
• L’esclave est à l’écoute permanente sur le canal de dialogue.
• Le maître parle et transmet une consigne puis repasse immédiatement à l’écoute.
• L’esclave réceptionne l’ordre et en analyse la syntaxe.
• Syntaxe correcte ou polluée, l’esclave Accuse Réception.
• Si la consigne est cohérente, l’esclave réalise les actions associées et repasse à l’écoute. (1)
• Si la consigne n’est pas intégralement correcte, l’esclave ne fait rien et repasse à l’écoute.
(1) : Éventuellement un deuxième accusé de réception peut être envisagé, message dans lequel l’esclave précise s’il a été en mesure de s’acquitter de la tâche ou si un aléa à empêché son déroulement. C’est le protocole envisagé qui peut imposer cette deuxième transmission.
La Fig.28 résume ce que sera la boucle de base qui animera le gros insecte artificiel. On constate qu’elle ne contient que peu de chose, et codé en C++ ne consommera que quelques lignes de programme. Tout le travail sera effectué dans des subroutines diverses se chargeant des traitements particulier dont l’Analyseur Syntaxixe entre autres. Les actions effectuées dans les deux premiers tests en bleu et le travail du pavé rose sont incluses dans la procédure Attendre_une_chaîne(). Cette dernière utilise les routines du langage C++ d’Arduino qui imposent pour stocker le texte reçu dans une String de définir une sentinelle qui indique au processus que le message textuel est complet.
Les protocoles de dialogue avec la sonde JEKERT.
Établir un protocole de dialogue entre l’humain et une quelconque machine informatique consiste à construire une grammaire stricte aussi simple que possible. Ce que nous devrons frapper au clavier ne devra pas nous imposer de constants appels au manuel. Il importe donc de définir des messages aussi « naturels » que possible. Par ailleurs plus ces textes seront courts, moins l’encombrement logiciel sera important. Enfin, les textes choisis pour donner des consignes à la machine devront éliminer toute ambiguïté à l’Analyseur Syntaxique, c’est à dire la séquence de programme qui sur la machine qui « écoute » balayera intégralement les informations reçues pour vérifier qu’elles respectent aveuglément et totalement les conventions retenues.
réliminaires à ce projet, des études initiales semblent démontrer que nous aurons besoin d’envoyer deux types de consignes à notre lointaine voyageuse. En exploitation sur site, globalement on lui demandera d’exécuter l’un des programmes préenregistrés. Toutefois, pour des applications particulières il sera commode de pouvoir imposer une orientation spécifique à un moteur individuel. Bien que sur Mars piloter un seul moteur manuellement sera relativement peu fréquent, pour le développement du logiciel il sera indispensable de pouvoir faire bouger chaque élément individuellement, et tout particulièrement pour les études morphologiques ou des configurations spécifiques. Par ailleurs, pour simplifier le matériel on va instaurer un dialogue de type Alternat.
Voie montante, voie descendante : Avant de poursuivre cette étude, vous trouverez un résumé du Protocole Conversationnel retenu dans la Fiche n°5 Protocoles de dialogues avec la sonde. Il y est fait mention de « voie montante ». De quoi s’agit-il ?
Considérons la Fig.29 sur laquelle S représente un satellite de télécommunication en orbite terrestre, ou une sonde posée sur Mars par exemple. Au sol une station radio de poursuite peut envoyer des signaux ou en recevoir par son antenne A. Par définition les ondes qui partent du sol vers S constituent la voie montante M quel que soit le nombre de canaux de communication ou leur bande passante. Les ondes qui partent de S et qui reviennent vers le sol constituent par définition la voie descendante.
Dans notre cas, les signaux de contrôle sont issus du P.C. Quand la ligne USB transmet vers Arduino, c’est donc la voie montante, alors que les Accusés de réception représentent la voie descendante.
La voie montante.
Prépondérante en termes de convivialité il faut penser « SIMPLE » car c’est elle qui conditionne les ordres envoyés par le terminal informatique. Les messages doivent être les plus élémentaires possibles et immédiats à coder. Aussi, ils commenceront par « m » pour une consigne moteur, et par « p » pour invoquer un programme. On se cantonne volontairement sur des caractères minuscules évitant ainsi d’avoir à mobiliser la main gauche pour appuyer sur SHIFT. Elle peut alors servir à tenir un moteur dans la main etc. Incontournable pour pouvoir exploiter les chaînes de caractères de type String arrivant sur la ligne USB, tous nos ordres devront s’achever par une « sentinelle ». C’est un caractère que l’on peut choisir librement et qui indique la fin d’un « bloc » de caractères à réceptionner par le programme. Ce caractère étant arbitraire, j’ai choisi « * » qui sera facile à vérifier sur les ACR et se trouve sur le pavé numérique. (ACR : ACcusés de Réception.)
Pour invoquer un programme il suffira d’indiquer son numéro obligatoirement sur deux chiffres.
Exemple : p08*  ou encore p12* etc. Imposer un caractère « 0 » pas vraiment utile en tête peut sembler un arbitraire pas très dégourdi. Ce choix s’impose toutefois car le développement du logiciel a montré qu’il permet de simplifier grandement le codage de l’analyseur syntaxique.
Piloter manuellement un moteur exige d’indiquer lequel et la position qu’il doit adopter. La consigne sera de la forme : « mN±PP*« . Le caractère « m » précise qu’il s’agit d’une consigne de motorisation. Le paramètre N désigne le numéro du moteur et sera compris entre [1 et 12]. Attention, ne pas mettre un zéro en tête. Le numéro de moteur sera obligatoirement suivi du signe « – » ou « + » pour la position, y compris pour le neutre opérationnel zéro. Enfin PP précise la position angulaire à atteindre codé sur un ou deux chiffres la valeur étant comprise entre [0 et 90].
Exemple : « m2+45* » placera le moteur n°2 à la position +45°.
               « m11-23* » orientera le moteur n°11 à la position +23°.
L’analyseur syntaxique.
Primordial si l’on désire éviter que la motorisation ne se comporte de façon complètement inattendue, l’esclave qui réceptionne un ordre doit le comprendre intégralement. Si une seule « virgule » n’est pas prévue dans les Protocoles Conversationnels, il ne doit surtout pas « prendre des initiatives ». Aussi, si l’humain qui a envoyé un ordre par le clavier s’est trompé, la sonde ne doit strictement rien faire, et se contenter d’accuser réception en précisant qu’elle ne comprend pas ce qu’on lui demande. Pour rendre compte de sa perplexité, JEKERT se contentera de signaler une erreur suivie de sa classification. La Fiche n°5 Protocoles de dialogues avec la sonde donne la liste des erreurs qui seront détectées par l’analyseur syntaxique. Concrètement, c’est une procédure qui balaye caractère par caractère l’ordre réceptionné et en décortique le contenu. Si ce dernier est conforme au langage défini pour le protocole, elle en extrait les divers éléments pertinents. (N° de programme à invoquer, n° de moteur concerné, l’angle à balayer et le sens de rotation.) Dès qu’une incohérence est rencontrée, l’analyse classifie l’erreur détectée, le processus s’arrête et la sonde accuse alors réception en indiquant ce qui ne va pas.
C’est le programme P03_Envoyer_des_consignes.ino qui a été utilisé pour développer le dialogue Homme/Machine et nous octroie la facilité de bavarder avec JEKERT. Fiche de protocole en main, on peut envoyer des messages corrects, des consignes volontairement erronées et observer ce que répond la sonde. Par exemple testez des messages trop longs qui dépassent 15 caractères, des n° de moteur anormaux, oubliez le « m » ou le « p » etc. Tentez d’expérimenter toutes les erreurs répertoriées par l’analyseur syntaxique. Le petit programme démonstrateur fonctionne intégralement sur la ligne USB et avec le Moniteur de l’IDE. Rien n’est obligatoire sur Arduino, mais vous pouvez laisser branchée l’interface et la motorisation. Un petit bruiteur est ajouté et piloté par la sortie binaire D2. Il est clair que sur Mars il n’y aura pas grand monde pour l’écouter. Par contre, quand on développe les programmes, chaque erreur s’accompagne d’un petit BIP d’alerte qui attire l’attention du programmeur. Nous savons alors que l’ordre envoyé n’est pas correct, ce qui incite à regarder l’écran. Vous allez vous rendre compte que focalisant sur le fatras mécanique et électrique, on finit par oublier l’écran de l’ordinateur. Aussi, si un moteur ne fait pas ce qui est attendu, le BIP nous évite de rester dubitatifs en supposant que le programme testé n’est pas correct. On regarde alors l’écran et l’erreur de frappe étant prise en compte on peut réitérer la consigne prévue lors du test actuellement en cours. Notons au passage que c’est le test A qui sur une longueur d’exactement quatre caractères en déduit qu’en principe il s’agit d’une consigne relative à l’appel d’un programme. Enfin, on observe que la détection d’une erreur n’écourte pas l’analyse syntaxique. Ainsi la procédure est plus simple et consomme moins d’octets car on va constater assez rapidement que l’espace mémoire pour loger notre programme risque d’être un peu léger, il se trouve que le cahier des charges est assez ambitieux !
NOTE : Ce que ne montre pas l’organigramme de la Fig.28 c’est que l’accusé de réception de type ERREUR engendre également le BIP sonore d’avertissement pour l’opérateur.
Maintenant que les protocoles de dialogue du Maître vers l’Esclave sont convenus des deux cotés de la ligne de transmission, il reste à établir les conventions pour la réponse. (C’est à dire l’ACR)
La voie descendante.
Quand c’est au tour de la sonde à bavarder pour rendre compte par un accusé de réception, la ligne USB vers l’ordinateur et l’écran du Moniteur de l’IDE constitue techniquement la voie descendante. Nous sommes en mode alternat. Systématiquement les ACR seront encadrés par un caractère « ! » pour en délimiter le début et la fin. Dans le cas d’une consigne « polluée » le programme se contente de retourner un compte rendu de la forme :
m25+45* > Sortie 24 Angle 45 !ERR 7!
Dans tous les cas il y a recopie du message mémorisé dont la longueur sera tronquée à sept caractères si on en a frappé plus au clavier avant de valider. (Sept étant l’espace réservé pour la chaîne de réception.) Puis, suivi de « > » la consigne interprétée. Enfin !OK! si l’ordre est cohérent, soit le texte laconique !ERR 7! qui précise la classification de l’erreur. Le message d’alerte s’accompagne comme déjà précisé d’un BIP sonore. Notez que le n° d’erreur correspondra au dernier problème
rencontré puisque l’analyse s’effectue intégralement quoi qu’il arrive.
La suite est ici.
