Construire un robot ROS 2 qui voit et roule vers un marqueur

Ce que vous construisez

Un robot déposé quelque part dans une pièce, qui tourne jusqu’à trouver un marqueur imprimé sur un mur, et s’en approche — en s’arrêtant à un demi-mètre, d’équerre à la face du marqueur plutôt que simplement près de lui.

Tous les autres montages de ce site exécutent un programme sur un microcontrôleur. Celui-ci est un ordinateur à roues, et cela change l’objet du projet. Les parties dures ne sont plus timing et câblage ; ce sont de savoir où sont les choses les unes par rapport aux autres, et de garder plusieurs logiciels honnêtes entre eux pendant qu’ils tournent tous à la fois.

Pourquoi ce robot a besoin d’un ordinateur

Un Arduino ne peut pas faire cela, et la raison mérite d’être précise. Ce n’est pas la vitesse brute — c’est qu’une image de caméra fait un quart de mégaoctet, la détection ArUco veut de l’algèbre linéaire en flottants, et le tout doit arriver pendant que les roues sont encore commandées à 50 Hz. C’est un travail pour un système d’exploitation avec vraie mémoire et vrai ordonnancement.

Ce que vous obtenez en échange de ce boîtier Linux est la capacité de regarder dans un robot en marche. Chaque message entre chaque partie est un topic auquel vous pouvez vous abonner depuis un portable. Quand le robot passe devant le marqueur au lieu d’aller vers lui, vous n’ajoutez pas d’affichages et ne reflashez pas — vous faites ros2 topic echo de la pose et la regardez être fausse en temps réel.

La forme du graphe de nœuds

Cinq responsabilités, un nœud chacune :

Les interfaces font l’intérêt de cette structure. Le contrôleur ne touche jamais une caméra ni un moteur — il consomme une transformée et produit un Twist. Cela signifie que vous pouvez conduire le même robot en téléop clavier, tester le contrôleur contre une transformée factice sans aucun matériel, et plus tard déposer une pile de navigation qui publie le topic identique.

Lisez nœuds, topics, services et actions avant de dessiner votre propre version de ce tableau. L’erreur la plus fréquente à ce stade est de faire du contrôleur d’accostage un service — c’est un objectif long qu’il faut pouvoir annuler, exactement ce à quoi sert une action.

Nomenclature

C’est le robot à deux cerveaux, et la liste de pièces le reflète : un ordinateur pour la perception et un microcontrôleur pour ce qu’un ordinateur ne fait pas fiablement.

Total : environ $145–175. C’est de loin le projet le plus cher du site, et l’essentiel est le Pi.

L’alimentation est là où ces robots échouent, et l’échec coûte cher. Une microcoupure pendant une écriture carte SD corrompt toute l’image système. Utilisez un régulateur à découpage bien au-dessus du tirage du Pi, ne partagez jamais le rail avec les moteurs, et vérifiez vcgencmd get_throttled — tout non-zéro signifie une alimentation insuffisante et une carte corrompue à venir.

Mesurez vos marqueurs imprimés. Une solution de pose ArUco est directement proportionnelle à la taille de marqueur déclarée. Un marqueur imprimé à 95 % par un « ajuster à la page » donne des poses fausses de 5 % à toute distance, et rien dans le pipeline ne vous le dira.

Ordre de montage

1 — Faites tourner ROS 2 et prouvez le réseau. Suivez installer ROS 2 sur un Raspberry Pi. Ne passez pas à la suite tant que ros2 topic echo sur votre portable ne montre pas un topic publié sur le robot. La découverte en Wi-Fi est la chose la plus susceptible de manger une soirée, et vous voulez la manger maintenant plutôt qu’en déboguant la vision.

2 — Faites obéir les roues à un Twist. Câblez l’Arduino, les codeurs et le TB6612FNG, et construisez le pont cmd_vel. Jalon : la téléop clavier depuis le portable conduit le vrai robot. Calibrez l’entraxe ici — tout l’aval en hérite.

3 — Calibrez la caméra. Correctement, avec une vraie mire, en suivant calibration de caméra et pose ArUco. Une caméra non calibrée produit des poses plausibles et fausses de dizaines de pourcents aux bords de l’image, ce qui est le pire mode de panne disponible.

4 — Publiez le marqueur comme une transformée. Pas comme un message personnalisé avec un x et un y dedans. Publier camera_link → marker_7 dans TF2 signifie que le contrôleur peut demander « où est le marqueur, en base_link ? » et la réponse tient compte exactement de comment votre caméra est montée — y compris qu’elle est inclinée, ce qu’elle est.

5 — Roulez vers le marqueur. Un contrôleur proportionnel sur le relèvement : tournez vers lui, roulez en avant, arrêtez à la distance de recul. Cela marche, et cela arrive en angle, ce qui est le propos de l’étape suivante.

6 — Approchez le long de la normale. Au lieu de diriger vers le marqueur, calculez un waypoint décollé de la face du marqueur le long de sa normale, roulez jusque-là, et seulement alors roulez droit dedans. C’est la différence entre atteindre le quai et accoster. C’est aussi là que l’orientation du marqueur — la partie de la pose inutile jusque-là — commence à compter, et où vous rencontrerez l’ambiguïté de pose.

7 — Enveloppez dans une machine à états. Recherche, approche, alignement, finale, terminé, plus les transitions hors de chacune quand le marqueur est perdu. Machines à états finis pour le comportement robotique couvre la structure ; le besoin spécifique de ce robot est un timeout de marqueur perdu qui revient en recherche plutôt que de continuer sur la dernière pose connue.

Notes matérielles importantes

Montez la caméra rigidement, et mesurez comment. Chaque pose calculée par le robot est relative à la caméra, et TF2 la transforme en pose relative au robot avec la transformée que vous déclarez de base_link à camera_link. Une caméra sur un support flexible rend cette transformée déclarée mensongère et variable avec l’accélération.

Inclinez la caméra vers le bas, et dites-le. Une caméra pointée à l’horizon perd le marqueur exactement quand le robot s’approche. Dix à quinze degrés vers le bas le gardent dans le cadre jusqu’à l’approche finale — et cette inclinaison va dans la transformée statique, pas dans un facteur arbitraire du contrôleur.

Mesurez le marqueur au pied à coulisse. L’échelle de pose est directement proportionnelle à la taille de marqueur dite au solveur. Imprimer à 96 % parce que l’imprimante a réduit pour ajuster rend chaque distance fausse de 4 %, silencieusement et systématiquement.

Alimentez le Pi séparément des moteurs. Un moteur qui cale fait chuter le rail, et là où un Arduino redémarrerait sans dommage, un Pi corrompt son système de fichiers. Soit un régulateur séparé soit un pack séparé — ce n’est pas l’endroit pour économiser un composant.

Tenez la nappe caméra loin des fils moteurs. C’est une liaison haute vitesse non blindée. Le bruit moteur couplé dedans apparaît comme des images corrompues, qui apparaissent comme des détections qui clignotent sans raison visible.

À quoi ressemble un bon résultat

Deux lignes portent la leçon de tout le projet.

La résolution n’est pas gratuite, et plus haute est souvent pire. Passer de 640×480 à 1080p coûte 4–6× le traitement pour environ 1,7× la portée de détection. Sauf besoin spécifique de voir un marqueur plus loin, la petite image donne une réponse plus rapide et plus fraîche — et la fraîcheur compte plus que la précision dans une boucle de commande.

La ligne de latence explique la découpe à deux cerveaux. À 0,3 m/s, 100 ms de latence vision font 3 cm de trajet ; en tournant à 90°/s cela fait 9° de rotation. Chaque mesure de vision décrit où le robot était. Boucler une boucle rapide directement dessus oscillera. La structure qui marche est celle qu’utilise ce robot : l’Arduino tient la boucle rapide sur codeurs, et la vision la corrige lentement — exactement la même forme que fusionner GPS avec odométrie sur le rover à waypoints, et exactement pour la même raison.

Obturateur déroulant, si le robot bouge en regardant

Les modules caméra Pi standard ont un obturateur déroulant : les lignes sont exposées l’une après l’autre, donc le haut d’une image est capturé quelques millisecondes avant le bas. À l’arrêt, c’est invisible. En tournant à 90°/s, les quatre coins d’un marqueur ArUco ont été capturés à quatre orientations différentes du robot — et la pose résolue est fausse d’une façon que la calibration ne corrige pas.

Si le robot doit voir en bougeant, c’est à cela que sert le module Global Shutter. S’il peut s’arrêter, regarder, puis bouger, le module moins cher convient entièrement — et s’arrêter pour regarder est un choix de conception légitime, pas un contournement.

Quand ça tourne mal

La distribution de ce tableau mérite d’être remarquée avant de commencer : presque rien n’est de la vision par ordinateur. C’est du réseau, des repères, des unités et de la commande — ce qu’enseigne vraiment la construction d’un robot ROS 2, et pourquoi le parcours fondations ROS 2 passe son temps sur les motifs de communication et les repères plutôt que sur OpenCV.

Si c’est un pas trop grand, la Micromouse enseigne cartographie et planification sur microcontrôleur sans Linux, et le robot piloté au téléphone couvre la moitié « les commandes arrivent par réseau » de ce problème pour une fraction des pièces.