Robot autonome Wallace - Partie 4 - Ajouter des capteurs de distance IR et "Amp": 6 étapes

2024 Auteur: John Day | [email protected]. Dernière modifié: 2024-01-30 09:08

Bonjour, nous commençons aujourd'hui la prochaine phase d'amélioration des capacités de Wallace. Plus précisément, nous essayons d'améliorer sa capacité à détecter et à éviter les obstacles à l'aide de capteurs de distance infrarouges, et de tirer également parti de la capacité du contrôleur de moteur Roboclaw à surveiller le courant et à le transformer en un "capteur" virtuel (logiciel). Enfin, nous verrons comment naviguer sans SLAM (localisation et cartographie simultanées) (pour l'instant), puisque le robot ne dispose pas encore de capteurs IMU (unité de mesure d'inertie) ou ToF (temps de vol).

Par navigation, dans un premier temps ce sera juste deux objectifs principaux:

1. éviter les obstacles
2. reconnaître quand il est coincé quelque part et ne fait aucun progrès. (« progrès » signifie qu'il a avancé sur une distance significative)
3. un 3e objectif possible pourrait être qu'il essaie de s'aligner directement sur un mur.

Ce projet a commencé avec un kit de robot et la mise en œuvre des mouvements de base à l'aide d'un clavier et d'une connexion ssh.

La deuxième phase consistait à ajouter suffisamment de circuits de soutien pour préparer l'ajout de nombreux capteurs.

Dans le précédent Instructable, nous avons ajouté plusieurs capteurs acoustiques HCSR04 et le robot peut désormais éviter les obstacles lorsqu'il se déplace dans l'appartement.

Bien qu'il se débrouille bien dans la cuisine et le couloir avec de bonnes surfaces planes et solides, il est totalement aveugle à l'approche de la salle à manger. Il ne peut pas "voir" les pieds de la table et des chaises.

Une amélioration peut être de garder une trace des courants moteurs typiques, et si les valeurs sautent, alors le robot doit avoir heurté quelque chose. C'est un bon "plan B" ou même C. Mais cela ne l'aide pas vraiment à naviguer dans la salle à manger.

(Mise à jour: en fait, pour l'instant, la surveillance du courant est le plan A lors de la marche arrière car j'ai temporairement retiré les capteurs de l'arrière).

La vidéo de cette section constitue la phase finale des capteurs d'évitement d'obstacles.

Ce que vous voyez dans la vidéo, ce sont six capteurs acoustiques HCSR04 avant et deux capteurs IR Sharp. Les capteurs IR n'ont pas beaucoup joué dans la vidéo. Leur point fort est surtout lorsque le robot se retrouve dans la salle à manger face aux pieds de la table et des chaises.

En plus des capteurs, le moniteur de courant intervenait notamment en marche arrière, au cas où il heurterait quelque chose.

Enfin, il utilise l'historique des 100 derniers mouvements et une analyse de base pour répondre à une question:

« Y a-t-il eu récemment de réels progrès vers l'avant (ou est-ce coincé dans une danse répétée) ? »

Donc, dans la vidéo, lorsque vous voyez un avant-arrière répété, alors il tourne, cela signifie qu'il a reconnu le motif avant-arrière, essaie donc autre chose.

Le seul objectif programmé de cette version du logiciel était d'essayer de progresser en continu et d'essayer d'éviter les obstacles.

Étape 1: ajouter un circuit de support (MCP3008)

Avant de pouvoir ajouter les capteurs IR, nous aurons besoin du circuit d'interface entre eux et le Raspberry Pi.

Nous allons ajouter un convertisseur analogique-numérique MCP3008. Il existe de nombreuses ressources en ligne sur la façon de connecter cette puce au Raspberry Pi, je n'entrerai donc pas dans le détail ici.

Essentiellement, nous avons le choix. Si la version des capteurs IR fonctionne à 3V, le MCP3008 aussi, et nous pouvons alors nous connecter directement au Raspberry.

[Capteur IR 3V] - [MCP3008] -- [Raspberrry Pi]

Dans mon cas, cependant, je fonctionne principalement en 5V, ce qui signifie un décaleur de niveau bidirectionnel.

[Capteur IR 5V] -- [MCP3008] -- [Bus bidirectionnel 5V à 3V] -- [Raspberry Pi]

Remarque: il n'y a qu'un seul signal de sortie du capteur IR. Il va directement à l'une des lignes de signal analogique d'entrée du MCP3008. À partir du MCP3008, il y a 4 lignes de données que nous devons connecter (via le bus bidirectionnel) au Raspberry Pi.

Pour le moment, notre robot va fonctionner avec seulement deux capteurs IR, mais nous pourrions facilement en ajouter d'autres. Le MCP3008 huit canaux d'entrée analogique.

Étape 2: Monter les capteurs IR

Sharp fabrique plusieurs capteurs IR différents, et ils ont des portées et des zones de couverture différentes. J'ai commandé le modèle GP2Y0A60SZLF. Le modèle que vous choisissez affectera le placement et l'orientation du capteur. Malheureusement pour moi, je n'ai pas vraiment recherché exactement quels capteurs obtenir. Il s'agissait davantage d'une décision « lesquels puis-je obtenir à un moment et à un prix raisonnables auprès d'une source fiable, parmi ceux qu'ils proposent ».

(Mise à jour: Cependant, cela peut ne pas avoir d'importance, car ces capteurs semblent être confus par l'éclairage ambiant intérieur. J'explore toujours ce problème)

Il existe au moins trois façons de monter ces capteurs sur le robot.

1. Placez-les dans une position fixe, à l'avant, légèrement à l'opposé l'un de l'autre.
2. Placez-les sur un servo, à l'avant, légèrement à l'opposé l'un de l'autre.
3. Placez-les dans une position fixe, à l'avant, mais aux coins les plus à gauche et les plus à droite, inclinés l'un vers l'autre.

En comparant le choix #1 au choix #3, je pense que #3 couvrira une plus grande partie de la zone de collision. Si vous jetez un œil aux images, le choix n°3 peut être fait non seulement pour que les champs des capteurs se chevauchent, mais aussi qu'ils puissent couvrir le centre et au-delà de la largeur extérieure du robot.

Avec le choix 1, plus les capteurs sont éloignés les uns des autres, plus il y a d'angle mort au centre.

Nous pourrions faire #2, (j'ai ajouté quelques images avec servo comme possibilité) et leur faire faire un balayage, et évidemment cela peut couvrir la plus grande partie de la zone. Cependant, je souhaite retarder l'utilisation d'un servo le plus longtemps possible, pour au moins deux raisons:

• Nous utiliserons l'un des canaux de communication PWM sur le Raspberry Pi. (Il est possible d'améliorer cela mais quand même…)
• L'appel de courant avec le servo peut être important
• Il ajoute plus au matériel et aux logiciels

J'aimerais laisser l'option servo pour plus tard lors de l'ajout de capteurs plus importants, tels que le temps de vol (ToF), ou peut-être une caméra.

Il y a un autre avantage possible avec le choix #2 qui n'est pas disponible avec les deux autres choix. Ces capteurs IR peuvent devenir confus, selon l'éclairage. Il se peut que le robot reçoive une lecture d'un objet qui est très proche alors qu'en fait il n'y a pas d'objet à proximité. Avec le choix #3, puisque leurs champs peuvent se chevaucher, les deux capteurs peuvent enregistrer le même objet (sous des angles différents).

Nous allons donc avec le choix de placement #3.

Étape 3: Le temps de tester

Après avoir effectué toutes les connexions entre le Raspberry Pi, le MCP3008 ADC et les capteurs IR Sharp, il est temps de tester. Juste un simple test pour s'assurer que le système fonctionne avec les nouveaux capteurs.

Comme dans les précédents Instructables, j'utilise autant que possible la bibliothèque wirePi C. Facilite les choses. Quelque chose qui n'est pas très évident en examinant le site Web de câblagePi, c'est qu'il existe un support direct pour le MCP3004/3008.

Même sans cela, vous pouvez simplement utiliser l'extension SPI. Mais pas besoin. Si vous regardez de près le référentiel git de Gordon pour le câblagePi, vous rencontrerez une liste de puces prises en charge, dont l'une est pour MCP3004/3008.

J'ai décidé de joindre le code sous forme de fichier car je n'arrivais pas à l'afficher correctement sur cette page.

Étape 4: Un capteur virtuel - AmpSensor

Plus vous pouvez faire en sorte que le robot reçoive des informations sur le monde extérieur de différentes manières, mieux c'est.

Le robot dispose actuellement de huit capteurs sonar acoustiques HCSR04 (ils ne sont pas au centre de ce Instructable), et il dispose désormais de deux capteurs de distance IR Sharp. Comme indiqué précédemment, nous pouvons profiter d'autre chose: la fonction de détection des courants moteurs du Roboclaw.

Nous pouvons envelopper cet appel de requête au contrôleur de moteur dans une classe C++ et l'appeler un AmpSensor.

En ajoutant quelques « intelligents » au logiciel, nous pouvons surveiller et ajuster le courant typique pendant le mouvement rectiligne (avant, arrière), ainsi que les mouvements de rotation (gauche, droite). Une fois que nous connaissons ces plages d'ampères, nous pouvons sélectionner une valeur critique, de sorte que si l'AmpSensor obtient une lecture de courant du contrôleur de moteur qui dépasse cette valeur, nous savons que les moteurs ont probablement calé, et cela indique généralement que le robot a heurté dans quelque chose.

Si nous ajoutons une certaine flexibilité au logiciel (arguments de ligne de commande et/ou saisie au clavier pendant le fonctionnement), nous pouvons augmenter/diminuer le seuil des "ampères critiques" pendant que nous expérimentons en laissant simplement le robot se déplacer et heurter des objets, à la fois directement ou en tournant.

Étant donné que notre partie de navigation du logiciel connaît la direction du mouvement, nous pouvons utiliser toutes ces informations pour peut-être arrêter le mouvement et essayer d'inverser le mouvement pendant une courte période avant d'essayer autre chose.

Étape 5: Navigation

Le robot est actuellement limité dans la rétroaction du monde réel. Il dispose de quelques capteurs de distance rapprochée pour éviter les obstacles, et il dispose d'une technique de secours pour surveiller l'appel de courant si les capteurs de distance manquent un obstacle.

Il n'a pas de moteurs avec encodeurs, et il n'a pas d'IMU (unité de mesure inertielle), ce qui rend plus difficile de savoir s'il bouge ou tourne vraiment, et de combien.

Bien que l'on puisse obtenir une sorte d'indication de distance avec les capteurs actuellement sur le robot, leur champ de vision est large et il y a de l'imprévisibilité. Le sonar acoustique peut ne pas refléter correctement; l'infrarouge peut être confondu par d'autres éclairages, voire de multiples surfaces réfléchissantes. Je ne suis pas sûr que cela vaille la peine d'essayer de suivre le changement de distance comme technique pour savoir si le robot se déplace et de combien et dans quelle direction.

J'ai volontairement choisi de NE PAS utiliser un microcontrôleur tel qu'un Arduino car a) je n'aime pas son environnement pseudo-C++, b) et que trop de développement userait la mémoire en lecture-écriture (?), et que je aurait besoin d'un ordinateur hôte pour se développer (?). Ou peut-être que je suis juste comme le Raspberry Pi.

Le Pi exécutant Raspbian, cependant, n'est pas un système d'exploitation en temps réel, donc entre les instabilités de ces capteurs et le système d'exploitation ne lisant pas exactement à chaque fois, j'ai estimé que le but de ces capteurs était mieux adapté pour éviter les obstacles et non mesure de distance réelle.

Cette approche semblait compliquée et avec moins d'avantages, lorsque nous pouvons utiliser de meilleurs capteurs ToF (temps de vol) (plus tard) à cette fin (SLAM).

Une approche que nous pouvons utiliser est de garder une sorte de trace des commandes de mouvement qui ont été émises au cours des X dernières secondes ou commandes.

A titre d'exemple, disons que le robot est coincé face à un coin en diagonale. Un ensemble de capteurs lui dit qu'il est trop près d'un mur, donc il pivote, mais ensuite l'autre ensemble de capteurs lui dit qu'il est trop près de l'autre mur. Cela finit par répéter un motif côte à côte.

L'exemple ci-dessus n'est qu'un cas très simple. L'ajout d'intelligence peut simplement élever le motif répété à un nouveau niveau, mais le robot reste coincé dans le coin.

Exemple, au lieu de tourner d'avant en arrière sur place, il tourne dans un sens, fait un retour en arrière momentané (ce qui efface ensuite les indications de distance critique), et même s'il tourne dans l'autre sens, il avance toujours d'un certain angle dans le coin, en répétant un modèle plus compliqué essentiellement de la même chose.

Cela signifie que nous pourrions vraiment utiliser un historique des commandes et examiner comment exploiter et utiliser ces informations.

Je peux penser à deux manières très basiques (rudimentaires) d'utiliser l'histoire du mouvement.

• pour le dernier nombre X de coups, correspondent-ils au modèle Y. Un exemple simple pourrait être (et cela s'est produit) "AVANT, ARRIÈRE, AVANT, ARRIÈRE, …..". Il y a donc cette fonction de correspondance qui renvoie soit TRUE (motif trouvé) soit FALSE (non trouvé). Si VRAI, dans la partie navigation du programme, essayez d'autres séquences de mouvements.
• pour le dernier nombre X de coups, y a-t-il un mouvement vers l'avant général ou net. Comment déterminer ce qu'est un véritable mouvement vers l'avant ? Eh bien.. une comparaison facile est que pour les derniers X mouvements, "FORWARD" se produit plus que "REVERSE". Mais cela ne doit pas être le seul. Que diriez-vous de ceci: "DROITE, DROITE, GAUCHE, DROITE". Dans ce cas, le robot doit effectuer des virages à droite pour sortir d'un coin ou parce qu'il s'est approché du mur sous un angle, ce qui pourrait être considéré comme un réel progrès vers l'avant. D'un autre côté, « GAUCHE, DROITE, GAUCHE, DROITE… » pourrait ne pas être considéré comme un réel progrès vers l'avant. Ainsi, si « RIGHT » se produit plus que « LEFT » ou « LEFT se produit plus que « RIGHT », alors cela pourrait être un réel progrès.

Au début de ce Instructable, j'ai mentionné qu'un 3ème objectif possible pourrait être de s'aligner ou de s'aligner sur un mur. Pour cela, cependant, nous avons besoin de plus que "sommes-nous proches d'un objet". Par exemple, si nous pouvons obtenir deux capteurs acoustiques orientés vers l'avant (pas l'objet de cet article) pour donner des réponses raisonnablement bonnes et stables concernant la distance, évidemment si l'un rapporte une valeur très différente de l'autre, le robot s'est approché du mur à un angle, et pourrait tenter quelques manœuvres pour voir si ces valeurs se rapprochent (face au mur carrément).

Étape 6: Réflexions finales, phase suivante…

J'espère que ce Instructable a donné quelques idées.

L'ajout de capteurs supplémentaires présente certains avantages et défis.

Dans le cas ci-dessus, tous les capteurs acoustiques fonctionnaient bien ensemble et c'était plutôt simple avec le logiciel.

Une fois que les capteurs IR ont été introduits dans le mélange, cela est devenu un peu plus difficile. La raison en est que certains de leurs champs de vision se chevauchaient avec ceux des capteurs acoustiques. Les capteurs IR semblaient un peu sensibles et imprévisibles avec des conditions de lumière ambiante changeantes, alors que bien sûr les capteurs acoustiques ne sont pas affectés par l'éclairage.

Et donc le défi était de savoir quoi faire si un capteur acoustique nous dit qu'il n'y a pas d'obstacle, mais que le capteur IR l'est.

Pour l'instant, après essais et erreurs, les choses se sont retrouvées dans cette priorité:

1. ampérage
2. Détection infrarouge
3. détection acoustique

Et ce que j'ai fait, c'est simplement de réduire la sensibilité des capteurs infrarouges, afin qu'ils ne détectent que des objets très proches (tels que des pieds de chaise imminents)

Jusqu'à présent, il n'a pas été nécessaire de faire de logiciel multi-threading ou piloté par interruption, bien que je rencontre occasionnellement une perte de contrôle entre le Raspberry Pi et le contrôleur de moteur Roboclaw (perte de communications série).

C'est là que le circuit E-Stop (voir les précédents Instructables) entrerait normalement en service. Cependant, comme je ne veux pas (encore) avoir à réinitialiser le Roboclaw pendant le développement, et le robot ne va pas aussi vite, et je suis présent pour le surveiller et l'arrêter, je n'ai pas connecté l'arrêt d'urgence.

Finalement, le multi-threading sera très probablement nécessaire.

Prochaines étapes…

Merci d'être arrivé jusqu'ici.

J'ai obtenu des capteurs ToF (temps de vol) laser IR VL53L1X, c'est donc probablement le sujet du prochain Instructable, avec un servo.