Statuette et échantillons

Modélisation avec Inskape

Nous nous servons d'Inkscape pour réaliser grossièrement des parties de notre robot. Ceci nous permet de visualiser les mouvements des actionneurs mais aussi la faisabilité de l'actionneur. Nous détectons ainsi que le servomoteur ne peut pas se mettre dans un sens car il se retrouve sur le passage d'une poutre de notre robot.

Pour concevoir l'actionneur de la statuette, nous nous sommes aidés de ce dessin :

D'un coup d'œil,nous voyons à quel hauteur doit être fixé le "crochet" de la statuette et l'actionneur sur le robot.

Partant de cette idée, nous greffons dessus l'actionneur qui fera tomber les échantillons.

Réalisation mécanique

Une fois ce second actionneur terminé, nous lui rajoutons un "grip" découpé dans une chambre à air qui avait eu le mauvais goût de nous laisser tomber récemment.


Actionneur statuette et grip pour échantillons

Nous avons aussi peigné notre robot. Le travail n'est pas fini mais les câbles des servomoteurs sont attachés et laissent apparaître la carte électronique. Merci les petits colliers "Colson". Blanc transparent, ils ne se remarquent pas - trop - sur le bois. Saurez-vous les voir ?

Les essais

Pas de gros soucis au niveau de la programmation, mais nous nous contentons que d'un code réduit, permettant de valider le fonctionnement de ces deux actionneurs.


La vidéo est disponible en 720p ici (mp4 - 20 Mo)

Roues codeuses magnétiques à très faible encombrement et haute résolution

Christophe Chaudelet
, 29/12/2021 | Source : PM-Robotix

Roues codeuses magnétiques pour base roulante robotique – compatible EV3 Mindstorm et ev3dev.

L’idée

Créer une paire de codeurs avec roues (communément appelé roues codeuses) qui génèrent le moins de frottement possible, à haute résolution, à un coût faible, qui ne craint pas la poussière et qui soit le moins large possible pour être placé dans une base roulante de robot de petite taille, compatible Lego Mindstorm/ev3dev.

Le problème

Un codeur professionnel du commerce, à haute résolution et étanche, est toujours d’une grande largeur, de plusieurs centimètres, auquel il faut ajouter un moyeu et une roue. Le tout s’avère toujours trop large (minimum 5cm par unité).

Il faut savoir qu’en robotique, sur une base roulante, il faut mettre les 2 roues codeuses et les 2 roues motrices, ainsi que les 2 moteurs d’entrainement de celles-ci sur le même axe afin de créer un asservissement fiable et relativement simple.

Le problème est donc que le matériel abordable, codeurs, roues motrices, moteurs, implique la plupart des cas une grande largeur de robot par défaut. Pour les petits robots, il faut aller chercher la miniaturisation avec l’augmentation du coût qui va avec.

Or l’objectif ici est de réduire cette taille en gardant une qualité et une fiabilité semi professionnelle afin de pouvoir facilement les utiliser dans une base roulante de petit robot, et également sur une base de robot en Lego Mindstorm. Les codeurs compatibles Lego (NXT Angle Sensor) ne possèdent que 360 pas par tour, ce qui n’est pas suffisant pour créer un asservissement efficace et fiable, il y a trop d’imprécision même avec une petite roue de 2cm de diamètre par exemple.

La largeur de cette nouvelle roue codeuse magnétique devra être équivalente à celle de 2 barres de Lego Mindstorm, roue incluse, soit 16mm. En contrepartie, la hauteur pourra être augmentée.

En diminuant cette largeur de chaque codeur, on obtient tout de suite un gain de place de plusieurs centimètres de chaque côté. Ce gain de place pourra être utilisé pour garder des grands moteurs à un prix acceptable, et des roues larges permettant une bonne adhérence. Ce sera donc une économie pour ceux qui veulent miniaturiser et fiabiliser leur base roulante de robot.

L’histoire

Avec l’aide de Nicolas, membre de l’association, nous avions ce besoin de réduire la largeur de la base roulante sur nos 2 robots de la coupe de France de robotique et de maximiser la largeur des roues motrices (surtout sur la version Lego). Juste avant cette situation de covid, nous avons eu l’idée d’inventer cette roue codeuse magnétique après différents brainstormings pour obtenir les avantages cités ci-dessous.

Nous avons pu faire les premiers tests en Juillet 2021 lors de la coupe de France de robotique et validé le fonctionnement.

Auparavant, nous avions testé les NXT Angle Sensor, et la mécanique Lego pour obtenir une pression suffisante au sol demandait une hauteur d’au moins 17 à 20 cm. Il s’est donc avéré que cette nouvelle roue codeuse magnétique ne faisant que 12cm de haut, permet vraiment un gain de place pour tout ce qu’on doit mettre d’autre dans un robot 😉 (autres mécanismes, cartes électroniques, capteurs, etc.).

Fonctionnement

En utilisant un simple aimant bipolaire, le composant AS5048B est capable d’échantillonner le champ magnétique pour créer les pas d’un codeur. Le champ magnétique n’étant pas parfaitement concentrique, une fonction de correction est proposée. En mode X4 (comptage de tous les fronts montants et descendants), il est possible d’atteindre 16384 pas par tour, ce qui est extrêmement précis.

En interrogeant en I2C le composant AMS, on obtient la position exacte de l’aimant, et donc de la roue attachée, dans le champ magnétique. A partir de là, il suffit de faire les calculs de trigonométrie pour obtenir le déplacement effectué entre 2 points. Ce dispositif est donc compatible avec du Lego Mindstorm ou une Raspberry Pi ou toute autre carte électronique qui possède un port I2C.

Le coût d’une roue codeuse magnétique est estimé à un peu plus de 200€.

Les bénéfices et les avantages

  • Carter créé en impression 3D.
  • Résolution de 14-bit (16384 positions/révolution).
  • Interface I2C directement accessible (3.3V ou 5V).
  • Un simple aimant basique 2 pôles est nécessaire.
  • Aucun contact de frottement entre la roue et le codeur qui pourrait freiner le robot.
  • Compensation automatique de l’échantillonnage du champ magnétique qui n’est pas sphérique.
  • Immunisé contre les champs magnétiques extérieurs.
  • Compatible Lego Mindstorm et ev3dev.
  • Roue plaquée au sol par ressort et éviter l’effet rebond et perdre l’odométrie.

Résultats

Photos

Design 3D de l’encodeur magnétique
Prototype d’encodeur magnétique à très faible épaisseur

Démonstration du concept

Magnetic encoder – Demo 1
  • High Resolution Position Sensor : AS5048B
  • Rail linéraire (CPC MR7MN)
  • Aimant 6×2.5mm axial (469-1075-ND)
  • Roulement 6704ZZ
  • Joint Torique 35 x 2mm NBR (JT101703502)
  • Visses, écrous, rondelles, ressort, fils
  • PCB Mag sensor
  • PCB Connecteur
  • DIP switch 2 positions
  • Carter en impression 3D PLA

Composition

Futures améliorations et upgrades

Tester l’impression en résine et un type de résine ABS pour vérifier que le carter ne bouge plus.

Maintenir plus fermement la roue qui coulisse, surtout si elle est peu appuyée au sol.

Balise LIDAR 3D TimeOfFlight (ToF)

Christophe Chaudelet
, 28/12/2021 | Source : PM-Robotix

L’idée

Détecter en 3D, la position à 360° et la hauteur de ce qui entoure un robot, sur une portée de moins de 3 mètres sans avoir à faire aucun réglage compliqué. L’objectif est de fiabiliser la détection des robots avec une installation simplifiée pour tout le monde et de le rendre compatible Lego Mindstorm (ev3dev).

Le problème

Recevoir les positions détectées tout autour d’un robot (x,y) ou (angle, distance) avec une période de rafraichissement de moins de 250 ms est un défi. Il est facile d’avoir la distance ou l’angle de l’objet détecté, mais les 2 en même temps sont plus difficiles à obtenir et aussi à miniaturiser, encore plus si on rajoute une dimension de hauteur (3D).

L’installation dans le robot ne doit pas être compliquée et ainsi que le réglage du dispositif. Les systèmes embarquant un moteur, un miroir, un laser professionnel, sont aussi très encombrants et difficile à fabriquer, surtout en DIY (Do It Yourself).

L’objectif est de détecter, soit ce qui s’approche du robot, soit un objet particulier, tel qu’une balise posée sur un autre robot. On doit savoir si ca marche bien ou non très facilement via un retour d’information instantanée (et non pas uniquement du log en mode développeur).

L’histoire

Il existe quelques solutions sur le marché, et la plupart utilise des Lidars. Seulement l’utilisation d’un LiDAR possède certes des avantages de précision mais aussi pas mal d’inconvénients tels que:

  • Le prix, un lidar professionnel est un budget important (généralement >2000€)
  • L’angle mort, et donc on ne peut voir qu’une partie (généralement devant le robot)
  • Les réglages d’assiette nécessaires
  • Il y a toujours qu’une seule assiette de detection
  • La mécanique utilisée avec un moteur et un laser qui tourne

Ces Lidars n’étant pas très accessibles pour des jeunes équipes de robotique, j’ai donc cherché une solution pour pallier aux inconvénients d’un LIDAR professionnel et rendre plus accessible ce type de détection.

J’ai créé un premier concept avec un moteur de CDROM et un simple laser classe 1 (laser IFM) qui permettait de détecter une balise catadioptre 3M. Les calculs étaient effectués avec une Arduino Micro, peu puissante, mais on avait prouvé que c’était suffisant. Cela fonctionnait bien en terme de détection d’angle (à l’aide d’un capteur infra rouge donnant le départ du tour du moteur). La technique pour calculer la distance fût de connaitre la largeur de la balise et d’en déduire les timing de détection. Cependant le réglage d’assiette afin de respecter les alignements horizontaux demandait trop de temps, mais étaient indispensables pour détecter de façon fiable à moins d’un mètre.

Voir la vidéo tout en base de cette page

En résumé, c’était extrêmement difficile et pénible de maintenir cette fiabilité, surtout en mode “Rush”. Dès que le robot était en maintenance entre les matchs, il fallait tout régler une nouvelle fois, et vous pouvez imaginer la galère.

Ensuite, nous avons découvert les détecteurs ToF (Time Of Flight), qui sont utilisé dans les téléphones portables pour le focus des appareils photos.

J’ai testé les différentes versions de détecteurs ToF. Après une multitudes de tests et d’idées, j’en ai trouvé une qui fonctionne finalement correctement, avec le bon modèle de ToF qui convient le mieux. La disposition associée a dû être extrêmement optimisée afin d’atteindre nos principaux objectifs et hypothèses, à savoir:

  • Une vue à 360° sur une distance maximum de 3m,
  • une actualisation rapide des données, inférieure à une période de 200 ms si possible,
  • un réglage simple et unique lors de la programmation, mais automatique pendant les préparations des matchs de la coupe de robotique,
  • Détecter sur plusieurs zones en hauteur, ou connaitre la hauteur de détection,
  • sur cette position, on n’est pas au millimètre, une résolution de 3 ou 4 centimètres par pallier n’est pas trop grave.
  • un mode de debug et une visualisation instantanée.

Fonctionnement

La première version (version actuelle) permet déjà de détecter 2 types de chose:

  • N’importe quel objet sur un rayon de 80cm (du blanc ou du noir),
  • une ou plusieurs balises créées en film réfléchissant micro-prismatique (permet de faire une balise cylindrique, tout en gardant une très bonne distance de détection).

La particularité intéressante est la zone de détection en hauteur. Actuellement, pour respecter la fréquence de rafraichissement imposée, il n’y a que 2 zones de hauteur, la partie inférieure au capteur, et la partie supérieure. Il sera possible dans une prochaine version de connaitre plus précisément ce nouveau paramètre de hauteur de ce qui est détecté (16 zones possibles en contre partie de la diminution de la fréquence de rafraichissement).

L’affichage sur les panneaux de LED affiche soit un point vert par zone, pour les objets détectés, soit le logo PM-ROBOTIX pour chaque balise catadioptre détectées.

Un mode permet de détecter si on veut toucher la balise avec 2 mains, et permet d’afficher un texte pour le moment. D’autres options sont en cours de test.

Ce module communique en I2C et est donc compatible avec du Lego Mindstorm ou un Raspberry Pi ou toute autre carte électronique qui possède un port I2C.

Les bénéfices et les avantages

  • Fiabilité de détection sur une distance d’1,20 mètres avec perturbation lumineuse et IR.
  • Détection sur 360° sans angle mort mécanique.
  • Rapidité de traitement: Acquisition des données toutes les 200ms, soit 5Hz, avec calculs, mise à jour de l’affichage, et transmission incluses.
  • Compatible avec EV3dev.org (Lego Mindstorm).
  • Affichage sur bandes de LED ou panneaux de LED en option (module interchangeable à l’avenir).
  • Installation facile sans réglage d’assiette important.
  • Résolution de 1 cm sur moins d’un 1 m et de 2,5 cm sur 2 m.
  • Laser classe 1, sans danger, à condition de les utiliser dans leurs conditions raisonnables prévisibles.
  • Visualisation instantanée avec LED/Panneaux de LED.
  • Taille réduite à un cylindre de 10 cm de diamètre (10 cm de hauteur avec panneaux de LED ou 4 cm de hauteur minimum avec une bande de LED).
  • Socle imprimable en impression 3D.
  • Réception des données avec une interface I2C (3V3,ou 5V)(commandes et données filtrées et calculées) ou SERIE (données brutes).
  • Composants facilement remplaçables.
  • Ajout d’un paramètre de hauteur; actuellement 2 zones de hauteur de détection sont configurées, et l’objectif est de connaître la hauteur précise.
  • Coût moins onéreux qu’un Lidar professionnel.
  • Le coût matériel du premier prototype ci-dessous est estimé à 360€ (ToF) + 40€ (Teensy 4.1) + 20€ (connecteurs électroniques) + 15€ (3D filaments) = 435€ (+180€ de panneaux de Leds en option).

Résultats

Photos

Balise LIDAR 3D TimeOfFlight (ToF)

Démonstration du concept

Composition

Une Teensy 4.1 pour avoir assez d’entrées/sorties, facilement remplaçable en cas de problème.

Beaucoup de ToF vl53l1x (Pololu) sur une connexion à 5 fils chacun.

Carter en impression 3D PLA.

Beaucoup de fils et encore des fils 😉

Un programme en C++ qui gère la configuration spécifique de chaque ToF, la synchronisation des données, le traitement de calcul ainsi que l’affichage du résultat sur les LEDs. Tout est sur Github au fur et à mesure des développements.

Une architecture de connexion et de placement optimisée (diffusion ultérieure des explications techniques détaillées).

Beaucoup de conception 2D et 3D sur Fusion 360 (diffusion ultérieure des explications techniques détaillées).

Futures améliorations et upgrades

Je travaille actuellement sur la 2ème version pour créer un module PlugAndPlay le plus simple possible. L’objectif est de permettre d’être utilisé très facilement par d’autres avec plusieurs options d’affichage LED suivant le budget, ainsi que la compatibilité avec ev3dev, peut-être avec ces options en DIY.

Le bloc sera par défaut sans LED, et il sera possible de plugger le module led souhaité.

Effectuer des tests plus poussés afin de qualifier les perturbations éventuelles et augmenter la fiabilité si plusieurs balises sont utilisées au même endroit.

Une autre amélioration sera de donner plus précisément la hauteur de détection de l’objet pour avoir pleinement cette nouvelle dimension dans les données et donc ce que l’on peut appeler la 3D.

Ancienne version de la balise laser motorisée + miroir

Ancienne version de la balise laser motorisée avec un miroir à 45° et une Arduino pour les calculs.

Le poussoir !

Voici le résultat du travail du week-end dernier : un peu de mécanique et un peu de programmation.

La dépose de la réplique a été accélérée et mérite encore un peu d'affinage.

Pour pousser les carrés de fouille, le robot doit longer le bord du terrain. Notre capteur infrarouge rempli pour l'instant parfaitement son rôle. Notre mécanique, sommaire et élégante, semble fonctionnelle. Nous avions un doute quant à la force nécessaire pour faire basculer le carré. Nos essais ont validé le système !

Voici le poussoir rentré :


Poussoir rentré

Et voici le poussoir sorti :


Poussoir sorti

Et pour finir une petite vidéo :


La vidéo est disponible en 720p ici (mp4 - 50 Mo)

Avancement début décembre 2021

Quoi de neuf après ce week-end ?

Principalement les capteurs infrarouge. Comme capteurs de détection de l'opposant, nous utilisons des SFR04, un devant, un derrière, qui nous ont fidèlement servis durant des années.

Cette année, nous allons vouloir longer la bordure et nous savons que notre odométrie n'est pas précise au millimètre après plusieurs déplacements. Nous installons donc des capteurs Sharp de type GP2Y0A41Y2 sur les côtés de notre robot.


Capteur IR à côté de la roue

Après avoir testé les capteurs sur notre petite carte de développement, nous rallongeons les câbles et les raccordons sur la carte du robot.

Nous adaptons le code de la carte pour renvoyer les valeurs des capteurs infrarouge à l'interface de supervision puis adaptons le code de l'interface de supervision.

Ça marche bien... pour le capteur branché en IR_1. IR_2 refuse de donner des valeurs cohérentes. Les mesures de tension sont 10 fois plus faibles qu'attendues. Est-ce que la broche du PIC est grillée ?

Non ! Après une heure de recherche, il s'avère que le problème était logiciel. Le code des servomoteurs tentait de piloter un servomoteur branché sur IR_2. Ceci car nous avions eu un soucis avec U3, le régulateur de tension 7805 des servomoteurs 1, 2 et 3. Nous avions réaffecté IR_2 (dont nous ne nous servions pas) à Servo3. Le prix à payer pour réutiliser une carte et un code vieux de 5 ans...

(Pour visualiser ça, utilisez le plan interactif de notre carte.)

Après réaffectation des broches comme initialement prévu, les valeurs retournées sont parfaitement cohérentes.

Un dernier doute m'habite, ces capteurs ne riquent-ils pas d'être aveuglés par l'éclairage de la Coupe ?

Premiers points !

Voilà nous sommes fin novembre et nous avons le plaisir de réaliser nos premiers points !

Ce samedi a été consacré à l'achat de planches pour la table et ses bordures. Bien que nous ayons de quoi faire une table complète, nous n'avons fait qu'une demi table primitive, composée de deux planches légèrement bombées...

Ce soir, nous avons passé un peu de temps à initier le code pour la stratégie 2022, puis dessiné nos deux premières trajectoires. Nous mettons le plan du règlement à l'échelle 1mm : 1 px, dessinons les trajectoires et recopions les coordonnées des points des courbes de Bézier dans notre code.


2022 - premières trajectoires

C'est fait à la Rache, les contacteurs pour s'assurer que le robot est en position ne sont pas utilisés mais ça marche, au mois 3 fois sur 4 !


La vidéo est disponible en 720p ici (Ogg - 10 Mo)

Les travaux de cet été 2021 (1/2) - La supervision

Le contexte

Quand j'ai choisi de re-participer à Eurobot, nous étions à quelques jours des finales. Alors j'ai choisi de re-travailler sur notre robot précédent. Deux points me chagrinaient, le premier étant les capacités de supervision du robot.

La supervision

Ce qu'on peut faire avec une liaison série, un peu de python et de Qt.

Les servomoteurs

Chaque année, le réglage des positions des servomoteurs se fait en entrant une valeur au hasard, compilant le code et testant. Il faut une petite quinzaine d'itérations pour affiner chaque position. Alors qu'il suffit de pas grand chose pour lier une commande de la liaison série à la commande d'un servomoteur.

Donc voilà, nous définissons une trame simple, qui permet de forcer la position d'une servomoteur. La trame est la suivante :
"Sxpppp"

  • S pour Servo
  • x pour le numéro du servomoteur à pilote
  • pppp pour la position à atteindre, en hexadécimal.

Sur l'interface graphique, 6 boutons, 3 pour avancer d'un petit pas, d'un pas moyen ou d'un grand pas, 3 pour reculer. Ces boutons sont un peu rigides, alors je rajoute un curseur horizontal (QSlider) qui permet d'atteindre une position approximative très rapidement. Enfin, un champ texte affiche la position actuelle.

Un dernier bouton permet de récupérer la position actuelle de tous les servomoteurs.


Supervision - servomoteurs

La surveillance

Vient ensuite le problème du robot, très fréquent, du "mais qu'est-ce qu'il lui a pris de faire ça ?". Vous avez généralement le choix, pour comprendre ce qu'il se passe.

Soit vous banchez un débogueur sur votre robot, mais chez nous, ça ne marche pas génial. Les broches de debug sont utilisées pour autre chose, le débogueur Microchip n'aime pas trop les interruptions et rapidement, nous n'arrivons même pas à reproduire le bug avec le débogueur branché (alors que sans, c'était 100% reproductible).

Soit vous émettez un signal en fonction des états de votre programme (comme allumer une LED). C'est une solution simple, qui a le mérite de bien marcher dans des cas simples.

Avec la surveillance, le robot émet sur la liaison série toute une série de valeurs correspondant aux états du robot (position, orientation, distances des obstacles, etc...) à intervalles réguliers. Comme le robot émet un entête descriptif de ce qu'il va envoyer, nous pouvons modifier l'ordre des valeurs, en enlever ou en rajouter sans toucher au code de la supervision.

L'interface n'est pas très soignée, mais nous avons quand même deux panneaux.

Le premier affiche les valeurs actuelles :


Supervision - état actuel

Le second un graphique pour la valeur sélectionnée. Généralement en fonction du temps, mais afficher la position Y en fonction de la position X est tellement parlant que nous ne nous en sommes pas privé :


Supervision - graphique

La communication

Enfin, toujours pour aider au debug, nous renvoyons sur la liaison série ce qui transite sur la liaison I2C. Soyons clair, ce ne serait pas adapté à de gros débit de communication. Mais dans notre cas ça marche !


Supervision - communication

Les bonus

La sauvegarde

Analyser à chaud, c'est bien. Pouvoir reprendre les logs précédents pour revoir un détail qui nous aurait échapper, c'est mieux. Chaque acquisition est enregistrée et peut être rechargée.

Le Python

Le programme est développé en Python, avec PyCharm. PyCharm est puissant mais parfois un peu lent à lancer. Alors lorsque nous avons voulu lancer notre programme sans ouvrir PyCharm, nous avons rencontré deux erreurs :

$ python Supervision.py ... SyntaxError: invalid syntax

Sous Debian, notre Python est Python 2.7. Essayons avec Python3 :

$ python3 Supervision.py ... ModuleNotFoundError: No module named 'PyQt5'

Et pourtant, ça marche avec PyCharm.

Le secret réside dans les environnement virtuels. PyCharm utilise venv.

Activation $ source venv/bin/activate

Et là, un simple :
$ python3 Supervision.py
lance l'application.

Pour quitter l'environnement virtuel, utilisez la commande suivante :

Désactivation $ desactivate

Plus de détail sur les environnements virtuels pour le Python, je vous conseille cet article de Linuxfr.

Avancement mi-novembre 2021

Quoi de neuf ?

La reproduction du terrain

Nous ne ferons pas un terrain complet. Pas avant plusieurs mois en tout cas. Mais nous réalisons l'angle qui accueille la statuette ainsi que les échantillons qui se trouvent dessus.


Angle du terrain 2022

Le robot

Nous avons dépouillé notre ancien robot, il ne lui restait que la planche de base, les moteurs, le gyroscope et la carte électronique.


Robot tout nu

Nous nous faisons un petit plaisir, nous construisons un support mobile pour la carte électronique. La carte sera en position verticale pour un match, mais son support peut se mettre en position horizontale pour faciliter les branchements et les mesures.


Robot 2022 - carte électronique pliée

Robot 2022 - carte électronique dépliée

L'inconvénient, c'est que nous devons refaire tous nos câbles en plus longs. Et ça, ça va nous occuper un petit moment.


Robot 2022 - support carte électronique

Côté actionneurs, nous en avons commencés deux. Le premier pour attraper la statuette, le second pour déposer la réplique.

Actionneur de la statuette

Nous comptons sur du velcro pour attraper la statuette. Notre bras n'utilisera qu'un servomoteur pour attraper et déposer la statuette. Le bras est construit, mais il faut encore le fixer sur le robot.


Actionneur de la statuette

Actionneur de la réplique

Pour l'instant, nous n'avons mis en place que les deux contacteurs qui nous indiqueront le bon positionnement du robot. Avec deux contacteurs, si le robot n'est pas bien positionné, il est possible de savoir de quel côté il doit se décaler. Nous avions utilisé un système similaire en 2012 pour accoster les totems qui contenaient les lingots.

Et la suite ?

Tout d'abord, nous devons finir nos câbles puis l'actionneur de la réplique. Ce sera probablement l'occasion pour le robot de faire quelques tours de roues, pour s'assurer que nous arrivons à déposer la réplique.

Ensuite, il faudra positionner l'actionneur de la statuette.

Ce qu'on se garde pour plus tard

Et oui, nous sommes loin d'avoir fini. Voici, en vrac, ce qu'il nous faudra réaliser :

  • Le positionnement des capteurs d'évitement.
  • la réalisation de la vitrine
  • le mat balise
  • le bras latéral pour retourner les carrés de fouille
  • tester, tester, et ... tester !

Bref, ce n'est pas fini, loin de là !

Eurobot 2022

Règlement officiel

Ça y est, le règlement officiel est sorti ! Vous pouvez le trouver sur le site de coupederobotique.fr, plus précisément ici.

Le forum pour discuter du règlement, voir les questions posées sur la version bêta est là.

Enfin, le forum pour discuter de la compétitions, présenter l'avancement des robots et autres se trouve ici.

Portail des équipes

Nous relançons le portail des équipes, disponible ici : http://poivron-robotique.fr/planet. Vous souhaitez apparaitre sur le portail, envoyez-nous un message !

Notre participation

De notre côte, même si tout n'est pas réglé, nous devrions participer à l'édition de cette année.

Nous avons reproduit quelques éléments de jeux et un petit bout de terrain.

Nous avons défini notre stratégie, avec un seul robot pour l'instant. Nous nous concentrons sur les actions simples et ferons un second robot si c'est trop facile (mais nous en doutons fortement).

Pour l'instant, notre stratégie est la suivante :

  1. Faire tomber les deux échantillons de l'abri de chantier et les pousser sous l'abri
  2. Prendre la statuette
  3. Déposer la réplique
  4. Déposer la statuette dans la vitrine
  5. Découvrir les carrés de fouille
  6. Rentrer dans la zone de départ

Si nous tenons notre contrat, nous devrions faire un bon paquet de point, mais clairement sans viser les premières places.

Le Wiki

Enfin, Planète Sciences/Eurobot a tenté de mettre un wiki à disposition des équipes. Nous avons apporté notre part et continuerons probablement d'y contribuer un peu au cours de l'année. Vous le trouverez à cette adresse : https://www.eurobot.org/wiki/fr/home. N'hésitez pas à le compléter !

How we reached our current architecture

Antoine
, 20/10/2021 | Source : CVRA

Background & History

In order to understand the current design, I think one must understand where we are coming from. The club experimented with different platforms over the years, and every time outgrew those. Every time we switch to a new platform, we must throw out everything and start again from scratch. To avoid this waste, the “obvious” solution is to design a system that we will never outgrow, but such a design is unlikely to succeed as technology and requirements always evolve.

When I joined the club (2008) it was using a board with a single microcontroller, a fixed number of I/Os and channels for 3 motors with position feedback and PID control. The architecture was quite rigid, but the motherboard allowed a bit of customization of the input/output, and when we needed functionality that could not be implemented on this platform, we built dedicated boards with small microcontrollers on them, communicating via ad-hoc protocols, generally over UART or GPIOs. This approach served us well for several years, but started to show its age (the PID controllers were 20 year old when we moved away!).

In 2010, we decided to switch to another system. In particular, we wanted to do polar control of the wheelbase (rather than per-wheel), which the existing system could not do as it relied on dedicated hardware for PID control. We also wanted to experiment with onboarding a computer in the robot for computer vision. The result was made of two parts: a custom board and a Linux computer. The board had an ATMega as its core. It could control three motors like the old board, but the PID was done in software, meaning we could do polar control. The Linux computer was communicating with the board over USB, sending it orders such as “go to this point”. The system worked well enough, but was not very modular: adding functionality for additional actuators required a lot of code changes. We were also not too convinced by the platform the computer was using (URBI, a now-dead programming language for robots).

In 2011, we built our first Debra, the name of our robots with SCARA arms. This was a massive increase in the number of motors we had to control: we went from 2 PIDs to 12, and they needed coordination. It was clear that our current approach did not scale to those requirements. The ATmega had to go, and was only used for one year. Realizing this was wasteful, we committed to a more modular solution, which we could adapt to each year’s requirements. We turned to FPGAs, as they provide the ultimate modularity: you can change what the hardware is doing simply by reflashing the FPGA! We still had a computer onboard for tasks like computer vision, but it never really got used.

The FPGA setup served us well, but it was a nightmare to develop for. FPGAs are programmed very differently from conventional platforms. To make things worse, we have to use tools provided by the FPGA vendors, which are pretty bad, non standard and had some bugs. We stuck with it for a few years, fixing bugs and in 2014, this platform had us win the Swiss championships! However, we needed a change for several reasons:

  • The FPGAs were too complicated to program1,
  • The platform was pretty expensive, meaning we only had three setups (two in robots, and one redundant). Developing outside of the robots was impossible.
  • The bugs of the platform made it challenging for reliability,
  • The boards were quite big, which made it mechanically challenging to integrate.

We started brainstorming for a new solution in 2015, and this document presents the current architecture, which is what we have running for now.

Objective

Provide a platform that can be extended indefinitely to match the requirements of the robot. Give developers flexibility in choosing the best platform for the subsystem they are working on.

Requirements

  • Can drive more than 12 DC motors, since this is what we are replacing
  • Compact
  • Real time requirements
  • Can be used for “10 years” because rebuilding PCBs cost time and money.

Overview

Unlike previous systems, which were relatively centralized, the new architecture is made of many systems collaborating to control the robots. While in the past our robot typically had 2-3 microcontrollers, the new design has ~15!

Linking each microcontroller to each other via a dedicated UART link like we used to do in the past would be infeasible just by the number of wires and UART interfaces required. Instead, this design uses a field bus shared by all the nodes: a single physical interface is enough for each node to talk to every other node.

Each microcontroller exposes a very high interface to the rest of the robot. This is very important to make the system easy to test and reason about: compare telling a board “turn on pump #3” to “please set register #4 to 0xfe”.

Detailed design

The robot’s network is based on the CAN (Controller Area Network) protocol. CAN was originally designed for the automotive industry, where it is used to communicate between different parts of an engine and/or a car’s interior. It was designed for robustness (safety critical systems depend on it), electrical resilience (a car emits a lot of electrical noise) as well as wiring simplicity (wires weigh a lot). CAN transmit data over a differential pair, with the two signals named CANH and CANL.

By itself, CAN is a very simple protocol: it can transmit messages up to 8 bytes, which are tagged with a 29-bit identifier. Any node on the bus can send and all the nodes will receive all the messages. Therefore, it is common to add higher level protocols on top of CAN, which provide longer messages, addressing and message serialization2. We chose UAVCAN for this, which is an emerging standard aimed at small drones and robots, an application close to ours. It proposes a nice set of features, and has a good quality reference implementation. Note that UAVCAN has two versions: the one we use, v0, is deprecated, and v1, currently in development.

CAN, like most low-level protocols, does not guarantee delivery of messages: messages can be lost, for example if two different nodes send a message at the same time. This lead to the introduction of two different message types in UAVCAN: broadcast and service calls. The first one is simply a node sending a message to everyone on the network, without expecting a response or a way to find if a message was dropped. It is well suited for things like sensors or a motor’s current position, where it does not matter if we drop a single message. The second one is used when we want to have a response, or we want to know if the message was dropped. We use it mostly for setting parameters on board (PID gains, board modes and so on). This mode does not guarantee message delivery, but triggers an error if a response was not received in a given time.

To simplify development, UAVCAN can automatically generate code to switch between human-readable formats and representation on the CAN bus. Messages are described in a special language (example), and C++ or Python code is generated from that.

When working with a large number of devices, software update becomes a challenge. We used to do that by connecting a JTAG probe to the target microcontroller, but this would become intractable with so many microcontrollers, some of which were not reachable without disassembly. We decided to develop an in-band method of programming, which uses the same CAN network that we used in normal operation to download updates. When powering up the robot, boards wait for software update messages for 10 seconds before proceeding to normal operations. The detailed design can be found in cvra/can-bootloader.

Available modules

The first type of board we designed, and still the most commonly used one is the motor control board (2015). It allows the control of a single DC motor, with control loops for controlling in torque, speed or position. It has inputs for two different quadrature encoders for position sensing. Originally we wanted to be able to use it as an alternative means of controlling RC servos, but this turned out to be unnecessary. It was also re-used with a different firmware for our opponent detection beacon. The API of the board is simple: you send it a position (or speed, or torque), and it will go there.

The sensor board (2016) contains three optical sensors: a laser range finder (10 cm range), a color sensor and an ambient light sensor. It can be used for object detection around the robot, for example to check that a game object was correctly handled. It simply publishes periodic readings on the CAN bus, for anyone interested.

The IO board (2016) has no definite purpose: by default it is simply 4 digital input / output + 4 PWMs. The original goal was to control a few industrial sensors or custom electronics. We used it for many different tasks over the years by reprogramming them to add features. Two generations of this board exist, with the only difference being the size of the module.

The UWB beacon (2017) is still a work in progress. The long term goal is to provide a system to find the position of all robots on the playing field by measuring distances with radio (similar to how GPS receivers work). Antoine is working on them at the moment.

The actuator board (2020) is the latest addition to the list (2020). Its goal is to be able to control a small actuator made with RC servos, vacuum pumps and valves. It has vacuum sensors to check if an object was picked, and has a digital input.

Our Pi shield (2020) allows one to connect a Raspberry Pi to the bus and to send and receive UAVCAN messages from Linux. It also allows us to connect a touchscreen placed on the front of the robot.

We have a custom USB to CAN adapter (2015), which has the correct connectors for our robot. It can also optionally power on the bus (only for a few devices). It is automatically recognized, and can be set up to be used as a native CAN interface on Linux. Two generations exist: micro-USB and USB-C. If you are working on the club’s projects, you should probably ask to have one.

Alternatives considered

When we started looking for what was used as a field bus, we identified big contenders based on the bandwidth and general availability: I2C3, CAN, and Ethernet-based platforms (IP, ModBus, Ethercat). We removed I2C as it operates in a master-slave configuration: we wanted the ability for any board to send messages on the bus. Ethernet-based solutions were the most advanced ones, but required a lot of circuitry while CAN only required compact single-chip transceivers.

Originally we had a split master design, where the realtime parts of the master firmware would be running on a large STM32, while the non-realtime parts would be written in Python on a PC. The two parts would communicate over Ethernet. This was extremely complicated and unreliable, so in 2016 we switched to an architecture with only one master firmware running on STM32. It served us well, but we were spending a lot of time dealing with low level work, as well as optimizing to not use too much RAM. This led us to switching back the code to run on Linux again, but this time including the realtime part as well, with everything written in C++. You can read more about this switch there.

We experimented with ROS for one year in 2016, using an architecture pretty similar to the one presented here. The biggest downside of this approach is that the build tools for ROS are not very nice to use and don’t support cross compilation, which makes building software really slow. The ROS navigation stack was very CPU hungry, which did not help with our limited CPU resources. It could certainly be interesting to come back to it now that ROS2 is available. You can read more about this approach here.

Future work

Communication between robots

The work presented in this article solves the issue of communicating inside the robot pretty well. However, the rules are moving more and more in the direction of requiring collaboration between the two robots. In order to do that in an efficient and safe manner, the two robots need to be able to communicate with each other.

Several technologies can be used here. Since the two master firmwares are running on Linux, we can use the normal networking stack to communicate between the two, either using Wifi, or by reprogramming the UWB boards. Theoretically, we could even use the two transports in order to provide a redundant link, however further study is needed.

The higher level protocol is also still an open question. Should we use UDP, in order to have real time behavior, or TCP to have reliable transmission? Do we handle errors at the application layer? Do we have something in-between for reliable ordering of messages (à la Paxos)?

  1. The software landscape for FPGA has since changed, and it might be easier now thanks to projects like Yosys and Chisel

  2. Serialization is the process of taking a high level structure and translating it to bits on the wire. 

  3. I2C is typically not considered a fieldbus and was never designed for inter-board communication. However it is commonly used in Eurobot due to its relative simplicity.