Étant donné qu’il n’y a pas d’intermédiaire « intelligent » entre l’humain qui envoie des consignes et la machine qui les exécutera sans « discuter », il vaut mieux que cette dernière puisse vérifier en local que des mouvements ou des postures imposés ne soient pas potentiellement dangereuses pour l’ensemble de la mécanique. Pareillement pour les commandes d’apprentissage. Une commande erronée ne doit pas risquer de faire perdre des données laborieusement enregistrées en EEPROM. Aussi, que ce soit pour enregistrer une posture par écrasement de la dernière mémorisée, ou effacer une séquence de programme appris antérieurement, des sécurités logicielles sont prévues et testées. Ceci étant précisé, ce sont surtout les instructions de mouvement qui sur incident peuvent amener les moteurs en butées et forçages mécaniques. Avoir à recommencer une opération d’apprentissage n’est pas catastrophique, mais endommager un moteur quand la sonde sera sur Mars ruinerait définitivement la mission. Aussi, pour réduire ce risque certaines protections sont prévues :
1) Sécurité par vérification des programmes préalables. Réitérer un déplacement de base comme « p01* » à « p08* » inclus est possible, mais uniquement avec la sentinelle « * » seule ou par l’usage du caractère de répétition. Tenter deux fois de suite « p04* » par exemple générera « !ERR 21! ».
2) Anticollision avec le télémètre. Si on envoie l’ordre d’avancer, y compris avec un caractère de répétition, avant chaque pas le télémètre à ultrasons effectue une vérification de non présence d’obstacle devant la sonde. Si un écho est détecté à moins de 8cm la machine n’avance plus et retourne une alerte « !ERR 15! » complétée par une information du genre « Distance : 6cm ».
3) Sécurité pour parer une tension d’alimentation trop faible des moteurs. Nous savons que si la tension dédiée à la motorisation descend en dessous d’un certain seuil, brusquement les servomoteurs divergent et vont en rotation continue jusqu’à ce qu’ils se bloquent sur un obstacle. Si on ne réagit pas rapidement, ils sont alors en situation de court-circuit. Toute l’énergie absorbée est alors convertie en chaleur. Pour contourner une telle situation, le logiciel va suspendre les consignes moteur dès que U < 4.0Vcc. Les tests montrent que le fonctionnement des moteurs commence à diverger en dessous de 3,3Vcc. Il est limite à 3,5Vcc. Donc 4.0Vcc constitue un bon compromis.
Attention : Le multiplexeur continue à distribuer de l’énergie, donc le danger n’est pas totalement éliminé. Il importe à l’opérateur de couper physiquement la ligne d’alimentation dès qu’une tension trop faible est détectée. Autrement dit, il faut anticiper.
Si l’alimentation électrique est issue d’une alimentation stabilisée fonctionnant sur secteur, le risque n’est pas bien grand, car « Alimentation faible » ne se produira que si cette dernière n’est pas branchée. Les moteurs seront concrètement sans énergie, donc pas de danger pour la mécanique. Si vous envisagez une alimentation sur batterie, le problème est réel et devra sérieusement être analysé et pris en compte. Pour ma part j’ai opté par une alimentation secteur, ce choix sera justifié ultérieurement. La ligne filaire qui apporte l’énergie de puissance, liée au cordon ombilical qui transporte les consignes a été agencée relativement longues pour assurer une liberté de mouvement à l’insecte mécanique. Pour ne pas alourdir le bilan des masses déplacées par le robot, les fils électriques sont de sections relativement faibles. Ce choix est volontaire et a donné lieu à de complexes expérimentations de validation. Une diode pare les inversions de branchement toujours possibles, composant qui provoque une chute de tension. (Le schéma électrique sera entièrement analysé et détaillé dans le TOME 4 qui traitera de l’intégration des systèmes.) Aussi, c’est directement sur le condensateur réservoir de 470µF situé à bord qu’est mesurée la tension disponible. Ainsi la mesure tient compte des pertes en ligne et indique ce qui est effectivement présent sur les servomoteurs.
Dans le didacticiel du TOME 1 nous avons conduit les études primaires pour établir les caractéristiques du matériel et prospecté pour débroussailler les sentiers de la morphologie du robot et des techniques qui seraient envisageables pour le mouvoir. Ce TOME 2 a construit les fondements du logiciel et déterminé de façon viable l’architecture du programme final. JEKERT peut bouger dans toutes les directions, et les télémesures de base sont en place pour assurer à distance la maîtrise de la lointaine exploratrice. Un petit bilan me semble bienvenu :
Dans le chapitre La crise du logement nous avions vu que le programme ne comportant que quelques directives, affichant tout juste « Bonjour », la sonde étant encore incapable de lever le petit doigt, le code objet engloutissait déjà 5214 octets soit 16% de l’espace disponible avec 399 emplacements dans la PILE soit 19%. Expérience en programmation acquise au cours des années, je vous avais assuré qu’il n’y avait pas lieu de dramatiser, que statistiquement l’évolution serait à notre avantage. Avec le démonstrateur P13_Toutes_les_postures.ino JEKERT est autonome, elle peut se déplacer où on le désire, comme on le veut. Au point de vue mobilité, sécurité, télégestion, on peut considérer que tout est globalement en place. Le compilateur annonce :
L’expérience avait raison. Nous avons toutes les raisons de nous réjouir. Il reste encore presque la moitié de l’espace possible pour loger du programme, et la zone des données dynamique laisse encore disponible les deux tiers de la RAM dédiée. Aussi, on peut fêter ce constat, car il nous invite à transformer la lointaine visiteuse, c’est à dire une machine capable de se promener en une réelle exploratrice capable d’observer son environnement.
Légitimement, je comprendrais tout à fait une certaine nervosité : « Déjà deux TOMES » et il n’a toujours pas publié les schémas et les dessins des circuits imprimés ». Et pourtant, nous allons encore devoir attendre, car munir la sonde martienne d’expériences embarquées va consommer un tome de plus. Patience, endurez encore un peu de voir tous ces fatras de fils électriques sur des plaques à essai, vous allez constater que munir cette machine de quelques capteurs ouvre un éventail d’expérimentation absolument fabuleux. Malheureusement on ne peut pas réaliser la circuiterie
tant que le projet n’est pas arrivé à son terme au point de vue des systèmes qui équiperont JEKERT. Par contre, au point de vue programmation nous allons aborder la gestion des réseaux I2C, un bénéfice qui sera précieux quand vous envisagerez des robots plus « sérieux » car cette facette sera réellement incontournable.
C’est promis, votre patience sera largement récompensée …
P.S : Tout système décrit dans ce projet ludique dévoilant des secrets défense ultra absolus cachés dans les coffres les plus sécurisés de la Nation ne serait que la conséquence d’un pur hasard malencontreux et involontaire !!!
Fin du TOME 2.
Rassurez vous voici la suite avec le TOME 3: JEKERT les expériences scientifiques.
