Étiquette : i2c

Tourelle Pan Tilt (SPT200) et contrôleur de servos Adafruit i2c

Aujourd’hui, on va regarder ce qui permettra de faire le « cou » de mon robot : une tourelle articulée qui permettra au robot de bouger sa tête de droite à gauche et de haut en bas.

L’ensemble est constitué :

  • d’une tourelle SPT200 de chez Servocity dans sa déclinaison pour servomoteurs Hitec (commandée chez Robotshop pour 53€, ce qui est très cher pour ce que c’est)
  • de 2 servomoteurs Hitec HS-645MG

Le tout sera piloté par un contrôleur de servomoteurs de chez Adafruit (i2c), capable de gérer 16 servomoteurs. Pour le moment on en utilisera que 2, mais j’en utiliserai davantage pour les bras.

J’ai réfléchis à différents systèmes que j’aurais pu fabriquer moi-même (j’avais pensé à des systèmes d’axes entraînés par des poulies/courroies etc.). Finalement, je n’aurai pas mieux fait que le SPT200, nous verrons pourquoi.

Il arrive en pièces détachées (le montage était déjà commencé sur cette photo) :

Alors honnêtement, la notice n’est pas des plus claire concernant les vis à utiliser. Toutes les dénominations de vis sont en anglais et en pouces, ça n’aide pas à s’y retrouver. Au final, en faisant preuve de logique et en lisant la notice entièrement avant de commencer, on s’en sort. Les vis noires (à part la très longue) servent à visser dans le plastique de la structure (celles à tête plate servent pour le plateau).

Attention également lors du montage des servomoteurs à s’assurer du bon positionnement de leurs axes avant de les fixer ! J’ai identifié la position correspondant au milieu de course de chaque axe pour l’orienter de la bonne façon.

Malgré son prix, que je trouve très élevé quand on voit la liste éléments qui compose ce kit, il est très bien pensé. La plupart des systèmes de tourelles que l’on trouve sur le marché à des prix raisonnables sont faits pour supporter des charges très faibles car ce sont les axes des moteurs qui supportent tous les efforts. Avec le SPT200, l’effort est porté sur les des roulements à billes intégrés à la structure et les moteurs ne font qu’entraîner les axes, sans subir de contraintes susceptibles d’abîmer les moteurs. Sur les photos précédentes, et les 2 suivantes, on voit où et comment sont placés ces roulements à billes.

Côté électronique, je ne souhaitais pas piloter directement les servos avec l’Arduino (qui aura déjà beaucoup d’autres choses à gérer), j’ai donc opté pour une carte contrôleur de chez Adafruit qui se connecte sur le bus i2c. Un tutorial est disponible ici et la librairie pour Arduino ici.

J’ai écris un programme de test, il est disponible ici et s’inspire des exemples livrés avec la librairie.

Une fois encore, attention ! Les positions MAX et MIN des servos correspondent à mon montage. Exécuter un programme dont les limites des servos n’ont pas été vérifiées avant peut provoquer de la casse : le servo utilisera tout son couple (et donc beaucoup de courant) pour atteindre la position qui lui a été assignée. Si celle-ci dépasse les limites physiques de déplacement (parce que le plateau est en butée sur la structure de la tourelle par exemple), alors les engrenages dans le servos pourraient casser, si ce n’est pas la structure ou même l’alimentation qui ne tient pas la forte demande en courant. Pour ce faire, il faut y aller pas à pas, en assignant une valeur fixe au servo pour déterminer son MAX et son MIN (350 correspond à peu près au milieu chez moi, c’est une valeur sûre je pense : pwm.setPWM(0, 0, 376)).

Cela étant dit, voici une démo :


Bon, là c’est facile, la charge ne pèse rien. Mais mon robot aura une tête bien remplie, probablement autour de 400g d’après mes estimations. On va donc lui coller une charge de 450g et voir ce que ça donne.

Nouvelle démo, plus chargée. Et ça marche très bien ! 🙂

PoC de l’étage électronique : Arduino Mega + 10 périphériques

J’ai prévu d’utiliser un Arduino Mega pour jouer le rôle de « moelle épinière » de mon prochain robot. C’est cette partie qui permettra l’acheminement des différents messages entre le cerveau (un mini-PC) et le corps (châssis, moteurs, capteurs) du robot.

Cette partie sera donc le carrefour de nombreux échanges entre différents types de périphériques, avec leurs contraintes (protocoles différents, performances, utilisation d’interrupts externes etc.).

Le but de ce PoC (Proof of Concept) est de démontrer que le Arduino Mega est bien capable d’assurer ce rôle. Plus précisément, il doit être capable de gérer en parallèle :

  • des périphériques sur bus SPI
  • des périphériques sur bus i2c
  • la communication série avec un PC
  • la communication avec un autre Arduino (Nano) sur le bus i2c
  • le pilotage de pins digitaux
  • la lecture de pins analogiques
  • des encodeurs très rapides avec des interrupts externes

Et tout ça pour une emprunte mémoire supportable.

Pour ce faire, j’ai fait un petit montage composé d’un Arduino Mega, d’une matrice de LEDs (SPI), d’un moteur CC et son encodeur (les 2 pins étant attachés à des interrupts externes), un tableau de 10 LEDs (je n’en utiliserai que 8, pilotés directement par des sorties digitales + une résistance de 150 Ohms), une photorésistance (sur pin analogique), un écran OLED (i2c), un capteur thermique IR de 8 cellules (i2c), un Arduino Nano (i2c) avec 2 capteurs ultrasons.

Le schéma suivant sera plus parlant :

PoC_mega

L’écran permettra d’afficher un certain nombre d’informations (température la plus élevée sur le capteur thermique, ticks moteurs, les distances relevées par les capteurs ultrasons), le tableau de 8 LEDs affichera la cellule la plus chaude détectée par le capteur thermique) et la matrice de LEDs dessinera une ampoule si une forte lumière est détectée ou un smiley si la température la plus élevée  relevée par le capteur est inférieure ou égale à 50°C et un cœur si elle les dépasse.

Pour mesurer l’intensité lumineuse, on utilisera une photorésistance  (1-10 KOhms) : sa résistance varie en fonction du niveau lumineux.  Un simple pont diviseur de tension (avec une résistance de 10 KOhms) nous permettra d’obtenir des variations de tension sur le port analogique que l’on pourra alors facilement mesurer. Un tuto ici.

L’Arduino Mega est le maître du bus i2c. Pour pouvoir communiquer avec un autre Arduino (Nano ici), ce dernier doit être utilisé en tant qu’esclave sur le bus i2c. Tout ce qu’il faut savoir est ici.

Les détails concernant le moteur (et son encodeur) utilisé est disponible ici. Et voici le détail des connexions :

Les librairies utilisées sont les suivantes :

Côté Arduino Mega, on est confortable, le programme occupe 7% du stockage et utilise 11% de la mémoire. Pour le Nano, la question ne se pose même pas : il ne fera que relever les mesures de capteurs ultrasons.

Lors des premiers essais, des problèmes de performances sont apparus et on pouvait observer une légère latence du système, de l’ordre des 200ms à vue de nez. En pratique, si j’allume la lumière sur la photorésistance, la matrice de LEDs affiche l’ampoule 200ms plus tard. Ce n’est pas énorme, mais ça se sent et ça pourrait poser des problèmes, pour la gestion des obstacles par exemple.

Je me suis vite aperçu que cela venait du rafraîchissement de l’écran OLED : à chaque tour de la boucle principale du programme, l’écran était entièrement redessiné. Je n’ai pas besoin de le mettre à jour si souvent, il suffirait de le faire une fois toutes les 200ms pour avoir un affichage assez fluide (sachant que pour mon utilisation, je pourrais même le rafraîchir toutes les secondes seulement).

Et c’est très facile à faire, grâce à la fonction millis(). Elle renvoie le nombre de millisecondes écoulées depuis que le Arduino est sous tension (le compteur revient à 0 après environ 50 jours de fonctionnement). A partir de là, il suffit de vérifier à chaque tour de la boucle principale qu’au moins 200ms se sont écoulées depuis le dernier rafraîchissement de l’écran. Si ce n’est pas le cas, on ne le redessine.

Cette petite astuce a réglé les problèmes de latence, l’Arduino Mega pilote le tout à merveille, la démo en vidéo :

Code source pour l’Arduino MEGA
Code source pour l’Arduino Nano