Voilà comme promis la suite du guide pour créer votre propre robot Arduino ! J’ai rencontré un certain nombre de problèmes que je vais vous présenter et qui ont été difficiles à identifier. Ça m’a également donné l’occasion de mieux comprendre le fonctionnement de la carte Arduino.
Les robots ont la même problématique que les humains pour se déplacer : ils doivent utiliser au choix l’un des cinq sens connus, mais de préférence le plus pertinent ! Le type et le nombre de capteurs va leur donner un certain comportement.
Par exemple, Discovery a deux capteurs télémètres infrarouges, c’est à dire deux rayons lumineux afin de mesurer les reflets sur les obstacles qu’il rencontre. La position des capteurs en « V » l’empêche de voir ce qui se situe juste en face de lui, un algorithme pourrait alors palier ce problème en slalomant doucement afin que chaque capteur croise la trajectoire empruntée. D’autres robots n’ont qu’un seul capteur et le montent sur une tête qu’ils orientent tour à tour de droite à gauche. D’autres ont trois capteurs.
Les robots n’ont pas besoin de nous comprendre ou de penser pour avoir l’air intelligents, il leur suffit de réagir à notre présence. C’est ce que font tous les robots actuels, même professionnels. C’est ce que j’ai voulu expérimenter en donnant la parole et un comportement basique à Discovery : il salue en s’allumant, puis attend que quelqu’un choisisse le capteur droit (idle) ou le capteur gauche (rouler) et s’exclame lorsqu’un choix est fait. Puis il se déplace en lançant des petites phrases de temps à autre, mais se plaint vigoureusement si quelque chose lui barre la route.
Pour y parvenir, j’ai placé sur la carte SD des dossiers contenant des profils de sons qui sont joués à des moments-clés du programme. Lorsqu’une action a lieu, un son est choisi au hasard dans le dossier correspondant. Le son précédemment joué est alors retiré du random, et l’opération recommence de manière aléatoire dans le temps (sous dix secondes).
Je vous disais qu’il fallait se méfier d’éventuelles incompatibilités entre le WaveShield (la carte son) et le Rotoshield (la carte de commande des moteurs). Je pensais échapper à la moindre soudure mais il en faut bien une. Et un cutter.
J’ai listé les pins qui sont utilisés par mon montage, ça donne :
D0 : vide, RX Ne pas utiliser
D1 : vide, TX Ne pas utiliser
D2 : Wave Shield déplaçable
D3 : Rotoshield « M1 » inamovible + Wave Shield amovible, timer 2
D4 : Wave Shield déplaçable
D5 : Rotoshield « M3 » inamovible + Wave Shield amovible, timer 0
D6 : Rotoshield « M4 » inamovible, timer 0
D7 : [Wave Shield du pin D3 à déplacer ici pour pouvoir utiliser M1]
D8 : [Wave Shield du pin D5 déplacé ici pour pouvoir utiliser M3]
D9 : vide, timer 1
D10: Wave Shield déplaçable, timer 1
D11: Wave Shield inamovible (Rotoshield « M2 » à sacrifier), timer 2
D12: Wave Shield inamovible
D13: Wave Shield inamovible
A0 : Capteur IR
A1 : Capteur IR
A2 : vide
A3 : Générateur de RandomSeed() (pin libre générant du bruit)
A4 : Rotoshield inamovible
A5 : Rotoshield inamovible
Vous aurez remarqué trois choses :
– le bornier M2 du Rotoshield ne doit pas être utilisé pour que le Waveshield puisse fonctionner
– le bornier M4 est le seul à pouvoir fonctionner out-of-the-box, pour utiliser M3 sans créer d’interférence il faudra aller modifier son utilisation dans la bibliothèque du WaveShield (WavePinDefs.h) et effectuer la soudure correspondante sur la carte électronique (avec les schémas on s’en sort bien)
– j’ai ajouté les positions des Timers Arduino car le déplacement de M1 me parait plus risqué, étant placé sur le Timer2 que le Waveshield utilise en D11.
Voilà le topic Adafruit où on m’a aidé à déplacer un pin, ils ont été très compétents. J’ai réalisé un travail de boucher mais au moins ca marche 😀
Et comme promis les codes sources : je vous conseille de vous en inspirer mais d’écrire vos propres programmes, c’est plus sympa.
Et! mais c’est excellent les voix! Merci d’avoir partagé. 🙂
J’ai pensé à trois fonctionnalités que je n’ai pas pu mettre en œuvre, peut être que cela vous donnera des idées.
Cartographier l’environnement : cela n’est à mon avis possible qu’avec un capteur télémètre de type sonar, monté sur une tourelle rotative. C’est peut être un peu plus complexe à faire qu’il n’y parait, car il faut ensuite traiter les données pour afficher une carte (réflexion sur le format de sortie des données : ascii+txt ? OSM ?).
Générer une trace GPS des déplacements : le GPS est la plupart du temps inopérant en milieu fermé. Il faut donc trouver autre chose. Une boussole (compass en anglais) devrait faire l’affaire, à condition d’avoir la vitesse du robot. Hors, cette vitesse nécessite un capteur pour être mesurée, car elle peut varier en fonction de la charge des accus, de l’inclinaison du sol, du poids du robot. Et admettons, compiler toutes ces données pour écrire une trace au format GPS et les visionner plus tard dans OSM ? Ce que j’avais imaginé aurait donné quelque chose de trop approximatif.
Réaction en quittant le sol : un capteur placé à l’avant aurait eu beaucoup d’avantages. Arrêter les moteurs en cas d’absence « de sol » devant (un escalier), suivre une ligne au sol ou émettre un son type « Posez moi ! ». Ce dernier cas devrait aussi être faisable avec un gyroscope. Cela me faisait trop de frais à l’achat pour un résultat pas vraiment indispensable.
Le dernier problème est aussi le nombre d’entrées sorties de l’Arduino proche de la saturation avec ces deux shields : il n’en reste qu’une ou deux de libres. Bon courage à ceux qui se lancent 🙂
C’est déjà vraiment fun ce que tu a fait .
J’attend de voir ce que donnera ton prochain 🙂