Test de la carte de contrôle robot A-Star 32U4 de Pololu

Introduction

Les robots développés par 3Sigma combinent depuis toujours une carte compatible Arduino et une carte sous Linux permettant de gérer la communication Wifi (avec un ordinateur, un smartphone, une tablette,…) pour le pilotage à distance et, éventuellement, la transmission vidéo temps-réel depuis le robot.

Cette architecture est utilisée, par exemple, dans le robot Geeros « RPi »:

  • Une carte Romeo (compatible Arduino Uno) gère la totalité des asservissements et les ponts en H de pilotage des moteurs
  • Une Raspberry Pi (parfois abrégée en « RPi » dans la suite de cet article) communique en Wifi avec l’ordinateur (ou smartphone, tablette,…) de pilotage pour récupérer les consignes de ce dernier et lui retransmettre la vidéo prise par la webcam intégrée au robot et les informations de télémétrie
  • La RPi échange par ailleurs (via une liaison série) avec la carte Romeo pour lui retransmettre les consignes de pilotage et récupérer les mesures qui doivent être renvoyées par la télémétrie

Dans cette architecture, les asservissements sont écrits en C/C++ (dans l’environnement Arduino) et sont exécutés sur la carte Romeo. Cependant, il est apparu depuis quelques temps le besoin, dans certaines filières de l’Education Nationale, d’avoir des robots programmables en Python. Il paraissait donc assez naturel de transférer une partie (ou la totalité) des tâches d’asservissement vers un mini-ordinateur embarquable de type Raspberry Pi.

C’est ce que nous avons tout d’abord fait avec le robot gyropode Geeros « pcDuino ». La carte pcDuino est, au même titre que la Raspberry Pi, un mini-ordinateur facilement embarquable dans un robot. La pcDuino a par ailleurs le bon goût de proposer une connectique et des signaux compatibles avec ceux d’un Arduino classique: on peut ainsi (en faisant toutefois attention aux niveaux de tension, les signaux de la pcDuino étant en 3.3V) lui ajouter directement de nombreux shields du monde Arduino.

Nous avons également conçu un X-Bot « pcDuino » (robot mobile classique à 2 roues + une boule omnidirectionnelle). Ce robot est d’ailleurs celui qui est le plus abouti en terme de programmation en Python puisque tout est fait exclusivement en Python sur la carte pcDuino, alors que dans le cas du Geeros « pcDuino », la mesure de vitesse des moteurs électriques est gérée par un Arduino Pro Mini, tout le reste (y compris les asservissements) étant programmé en Python et exécuté par la pcDuino.

Pourquoi cette différence entre le Geeros « pcDuino » et le X-Bot « pcDuino » ? Tout simplement parce que la mesure de vitesse d’un moteur électrique (plus de détails en cliquant ici) nécessite de gérer des interruptions très fréquemment et rapidement. Or, un mini-ordinateur de type pcDuino ou Raspberry Pi (tout au moins avec leur distribution Linux « standard ») n’est pas fait pour ça. Dans le cas du X-Bot « pcDuino », ça fonctionne mais c’est limite. Dans le cas du Geeros « pcDuino », on est en présence d’un gyropode: les asservissements sont très « pointus » pour pouvoir le faire tenir en équilibre sur ses 2 roues et ils ajoutent trop de charge au système. Celui-ci ne peut pas gérer en plus les interruptions des codeurs incrémentaux des moteurs à courant continu.

Vous pourriez penser que je m’égare (en plus, nous sommes toujours dans la partie « Introduction » !). Mais en fait non: le sujet qui nous intéresse aujourd’hui est le suivant: nous voulons également avoir une version de nos robots dont les asservissements sont programmés en Python sur une Raspberry Pi (histoire de ne fâcher personne: nous n’allons pas obliger les fans de cette carte à utiliser des robots à base de pcDuino !). Mais il y a un problème: la RPi est moins bien fournie que la pcDuino en E/S (je ne parle pas en nombre, mais en type): pas d’entrées analogiques, gestion des interruptions pas suffisamment efficace, seulement deux PWM.

Et c’est là qu’intervient, brbrbrbrbrbrbr (roulements de tambour): l’A-Star 32U4 !
Nous allons maintenant présenter cette carte et voir quel avantage ont peut tirer de son association avec une Raspberry Pi. Nous verrons en particulier que nous pouvons programmer les asservissements en Python sur la RPi et sous-traiter à l’A-Star la gestion de toutes les E/S manquantes sur la Raspberry Pi.

 

L’A-Star 32U4 – Ce que nous aimons

Je suis tenté de dire « j’en ai rêvé, Pololu l’a fait », car cette carte apporte beaucoup de fonctionnalités très intéressantes, détaillées ci-dessous.
Vous pourrez trouver plus de détails dans la documentation officielle (en anglais, désolé).

 

Une carte réellement faite pour le contrôle moteur – Peut s’utiliser de façon autonome

Ce sous-titre peut sembler superflu, mais en fait non: il existe des cartes qui sont censées  être faites pour le contrôle moteur et qui sont en réalité particulièrement mal pensées. Un brillant exemple est l’Arduino Motor Shield.
Et oui, c’est le shield « officiel », mais quand on lit la description, on se rend compte qu’un des PWM utilise la broche numéro 3. Or, quand on fait du contrôle moteur, on a souvent envie de mesurer sa vitesse. Ca se fait en branchant au moins une des deux voies du codeur incrémental sur une entrée de type interruption (plus de détails en cliquant ici). Et bien devinez quoi, une des entrées « interruption » de la carte Arduino Uno est la broche 3. C’est donc impossible de faire l’asservissement de deux moteurs à courant continu en utilisant l’Arduino Motor Shield. Nous ne pouvons donc pas l’utiliser dans nos robots, puisque ceux-ci intègrent toujours la mesure de vitesse des moteurs.
On pourrait se dire « qu’à cela ne tienne, je vais utiliser un Arduino Leonardo ! ».  C’est vrai, c’est moins pire car l’Arduino Leonardo possède 5 entrées interruption. Manque de chance, la broche 3 est l’une des deux broches de l’i2c. Impossible dans ces conditions de brancher le moindre périphérique i2c comme le MPU6050 de nos Geeros. Bref, il y a des produits mieux conçus que l’Arduino Motor Shield (ce shield de contrôle moteur, par exemple, est très bien).

Revenons à nos moutons. L’A-Star 32U4 n’est pas un shield de contrôle moteur, c’est une carte complète intégrant un micro-contrôleur (l’Atmega32u4, le même que celui de l’Arduino Leonardo). Vu de loin c’est un produit analogue à la carte Romeo: une « mono-carte » intégrant micro-contrôleur et pont en H, permettant d’éviter un empilement Arduino + shield.
Et donc, Pololu n’a pas fait la même erreur que l’équipe Arduino: l’i2c et les interruptions restent disponibles.

Cette carte a donc tout pour fonctionner de façon autonome. Et comme nous le verrons par la suite, on peut aussi l’utiliser en conjonction avec une carte Raspberry Pi.

 

Compatible Arduino et bibliothèque logicielle dédiée

L’A-Star peut être programmée à partir de l’environnement Arduino. La procédure d’installation est bien détaillée dans le documentation. Par ailleurs, une bibliothèque logicielle apporte des facilités d’utilisation supplémentaires.
Par exemple, la fonction « setSpeeds » (dans la classe « AStar32U4Motors ») permet de donner une consigne de tension d’alimentation pour chacun des moteurs, sans avoir à gérer le PWM et la direction.

 

S’utilise aussi avec une Raspberry Pi

Un des gros intérêts de l’A-Star 32U4 est qu’elle peut se connecter sur le connecteur 40 broches des Raspberry Pi A+, B+, Pi 2 modèle B et supérieur. Elle est d’ailleurs livrée avec des entretoises permettant de sécuriser le lien entre les deux cartes. C’est très utile car la RPi ne possédant un connecteur que d’un seul côté, bien qu’il y ait deux rangées de broches, les add-ons ont tendance à s’incliner, ce qui pourrait causer des court-circuits.
Les entretoises fournies évitent ce problème. Et au passage ça vous évite de vous en procurer vous-même: les concepteurs de la RPi ayant eu l’idée saugrenue de faire des trous de fixation pour de la quincaillerie M2.5 (alors que le M3 est infiniment plus courant), ce type d’entretoise n’est pas toujours très facile à trouver.

Lorsque l’A-Star est branchée sur une RPi, elle décharge cette dernière de la gestion des E/S bas niveau, en particulier pour la mesure de la vitesse des moteurs. En effet, cette mesure de vitesse nécessite des lignes d’interruption qui puissent être gérées de façon efficace. Certes, la Raspberry Pi est capable de gérer des interruptions, mais il ne s’agit pas ici de réagir à de simples boutons poussoirs. Dans le cas des moteurs utilisés dans nos robots, il faut pouvoir gérer très vite jusqu’à 2500 interruptions par seconde, sur deux voies en parallèle…

La communication entre la partie Atmega32u4 et la Raspberry Pi se fait en i2c (les 2 bus sont connectés nativement). Il existe même une bibliothèque permettant de faire des échanges à haute fréquence malgré le bug de l’i2c sur la Raspberry Pi

L’A-Star apporte également les entrées analogiques qui manquent cruellement à la Raspberry Pi, des PWM supplémentaires (très utile pour des robots multi-axes) et bien sûr les ponts en H nécessaires à la commande de 2 moteurs à courant continu.

 

Une gestion (très) intelligente des alimentations et des niveaux de tension

Les produits du monde Arduino / Raspberry Pi sont rarement décevants en terme de fonctionnalités (ils font ce qu’ils sont censés faire) mais le côté pratique n’est souvent pas au rendez-vous.

Par exemple, si vous avez déjà travaillé sur un projet Arduino avec plus de 2 capteurs, vous avez sans doute utilisé une plaque d’essai ou fait un bricolage pour contourner le manque de broches de masse et d’alimentation (merci DFRobot pour avoir développé le shield E/S permettant de résoudre le problème). Vous avez peut-être également pesté contre l’absence de trous de fixation de certains modules.

Dans le cas de l’A-Star, tout (ou presque) ce qu’on peut rêver de pratique quand on conçoit un robot est présent:

  • il y a un interrupteur on/off. On peut également connecter sa propre solution matérielle d’allumage / extinction grâce à 3 broches dédiées
  • la carte intègre un régulateur de tension 5V, ce qui évite d’en ajouter un, comme dans beaucoup de nos robots (en l’occurrence le S7V7F5, idéal pour fournir 1A à partir de notre batterie LiPo 7.4V)
  • le régulateur de tension prend en entrée des tensions comprises entre 2.7 et 11V: on peut donc alimenter la carte avec un adaptateur secteur 9V, une batterie 3.7V, ou 7.4V,…
  • on peut « attaquer » l’entrée du régulateur de tension de deux façons: en connectant deux fils sur un bornier ou bien en utilisant un connecteur jack. Très intéressant: ces deux entrées sont reliées en amont de l’interrupteur (c’est-à-dire, même si l’interrupteur est sur off). C’est très utile pour recharger une batterie lorsque le robot est éteint:
    (attention, ce qui suit est valable uniquement si vous utilisez cette batterie, intégrant nativement un gestionnaire de charge. Ne jamais faire ce qui suit avec un autre type de batterie)
    la batterie étant branchée sur le bornier, elle peut être rechargée robot éteint par un adaptateur secteur branché sur la prise jack
  • un circuit de commutation permet de pouvoir brancher sans risque en parallèle le câble USB de programmation
  • le régulateur de tension alimente aussi la Raspberry Pi mais si vous souhaitez avoir une alimentation dédiée, c’est également possible. On peut donc avoir sans problème 3 alimentations en parallèle: câble USB, alimentation jack (ou bornier) et alimentation Raspberry Pi
  • le niveau de tension en amont du régulateur peut être connecté (via un cavalier) sur une entrée analogique: c’est donc très facile de surveiller la charge d’une batterie, d’autant plus que la librairie Arduino de l’A-Star fournit une fonction dédiée pour ça: readBatteryMillivoltsLV()
  • toutes les broches « Arduino » de l’Atmega32u4 sont accessibles via un triplé masse – alimentation – signal. Par ailleurs, l’alimentation de ces broches est séparée en 4 groupes. Il est donc possible (dans une certaine mesure) de mélanger des capteurs alimentés en 3.3V et en 5V
  • dans le cas ou une conversion de niveau est nécessaire, (3.3V vers 5V et inversement), 3 convertisseurs sont présents et utilisables

 

Des LEDs et des boutons poussoir

C’est toujours utile pour avoir un retour d’information rapide et donner des commandes simples sans avoir besoin de mettre en place une connectivité évoluée.

 

Un buzzer ?

Oui, il y a un buzzer. A priori ça fait gadget, mais quand on a exécuté le programme d’exemple fourni avec la librairie de l’A-Star, on se demande comment on va s’en passer 😉
En effet, il est désactivé sur nos robots car il partage le Timer 4 de l’Atmega32u4 avec la fonctionnalité d’exécution sur interruption hardware (cadence 10 ms) de certaines parties du programme.

 

(Petit) regret

Une connectique permettant de rajouter un shield ou tout au moins de connecter (par exemple) un module ESP8266 aurait été la cerise sur le gâteau. D’un autre côté, compte-tenu du facteur de forme choisi (contraint par la taille de la Raspberry Pi), on voit mal comment cela aurait pu être possible car la connectique potentielle est déjà très dense. D’autant plus que la RPi peut apporter ses propres atouts pour la connectivité Wifi de l’ensemble.

 

Conclusion

L’A-Star 32U4 est un produit très bien conçu qui est désormais présent dans notre nouvelle génération de robots à base de Raspberry Pi:

 

 

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Si vous êtes un humain, merci de répondre à la question suivante *