Gestion du détecteur d’obstacle à ultrason « ping »

Cela fait un moment que je n’ai rien publié pour mon robot. Pourtant, j’ai quand même travaillé sur celui-ci. Mais le temps est de plus en plus difficile à trouver quand on travaille et qu’on a une famille.

Aujourd’hui j’ai décidé de parler du détecteur d’obstacle « ping ». Je vais commencer par présenter le produit, et expliquer comment je l’implémente sur mon robot et dans mes programmes.

Qu’est-ce que c’est ?

Quand on fabrique un robot qui a besoin de se déplacer par ses propres moyens, celui-ci devra savoir éviter les obstacles qui se trouveront devant lui. Pour cela, plusieurs composants électroniques existent, qui sont plus ou moins efficaces. Le détecteur « ping » est un module qui permet de savoir si un obstacle se trouve devant votre robot et surtout à quelle distance.

J’utilise le même terme qu’utilise la société Parallax qui a fabriqué les modèles que j’utilise mais en fait, il s’agit d’un détecteur à ultrasons. Ceux que j’utilise me permettent d’aller jusqu’à 3m. Au delà, il ne faut pas considérer l’information comme correcte.

Le module est composé d’un émetteur qui envoie un signal ultrason et d’un récepteur capable de lire le signal envoyé par celui-ci.

Fonctionnement.

Ce module fonctionne exactement comme un radar. L’émetteur envoie un signal. Celui-ci rebondit sur l’obstacle. Le récepteur détecte alors le signal car celui-ci revient en face de lui (écho).

Le module calcule le temps entre le moment de l’émission et celui de la réception du fameux signal. Ainsi, comme la vitesse du son est connu (il me semble que c’est 340.29 mètres par seconde), il devient aisé de calculer une distance et donc de savoir où se trouve un obstacle.

En termes de connectique, le module est composé de trois pattes :

– une patte à brancher sur le « + » de l’alimentation (5v dans mon cas Vdd sur le schémas ci-dessus)

– une patte à brancher sur le « – » de l’alimentation (Vss sur le schémas ci-dessus)

– une troisième patte permettant de donner l’information qui peut être lue par un micro-contrôleur. Pour moi, il s’agit de ma carte activityBot. Je dois cependant utiliser une résistance de 2.2 KH entre cette patte et ma carte. En effet, le module fonctionne en 5v et les entrées de ma carte fonctionnent en 3.3v maxi.

Inconvénients

La détection ne peut pas se faire dans les cas suivants :

a. La distance est supérieur à 3.3 m (personnellement, je me baserai sur 3m)

b. l’angle entre la direction en face du module et l’obstacle à détecter est inférieur à 45°. Exemple : on se dirige vers un mur, mais pas en face, un peu en biais. Ce problème je pense le résoudre en installant deux détecteurs à infrarouge (qui seront à découvrir dans un prochain article).

c. L’objet est trop petit pour être détecté

Implémentation sur le PLR1

Je suis parti du tutoriel de parallax pour le branchement (schéma ci-dessus). La différence, est que le module n’est pas directement sur la plaque sans soudure de l’activityBot. Comme je l’avais déjà indiqué, j’ai deux modules à ultrasons sur mon robot :

– Le premier est installé en dessous de l’écran sur la caisse, à l’avant du robot. Il me permettra de détecter les obstacles qui se trouvent devant.

– Le deuxième est placé au dessus de la caméra (il servira à détecter des obstacles dans la direction de la caméra). Il me permettra aussi par exemple de savoir à quelle distance se trouve un visage détecté par la caméra.

J’ai donc ajouté des fils entre les deux modules et la plaque sans soudure sur laquelle j’ai disposé mes deux résistances et fait les branchements à la carte elle-même.

En terme de programmation, cela est assez simple dans mon cas. Sur l’activityBot, il me suffit d’appeler une fonction de la façon suivante :

distance = ping_cm(8) ;
// distance étant la variable récupérant l'information 
// 8 le numéro du port sur lequel est branché le signal du module
// ping_cm le nom de la fonction qui me renvoie une distance en centimètres.

J’ai donc implémenté dans la réception d’instructions que l’on reçoit du raspberry-pi par l’intermédiaire du port série (voir article précédent) l’appel à cette fonction. Cependant, le numéro du port est passé en paramètre par le raspberry-pi car j’ai deux détecteurs et je pourrais en installer d’autres plus tard. Cette fonction renvoie ensuite le résultat au raspberry-pi.

Côté Raspberry-pi, il fallait aussi que je modifie mon programme. J’ai donc créé une fonction qu’il me suffit d’appeler de la façon suivante :

distance = lecture_ping(numport) ;  
// distance étant la variable récupérant l'information
// lecture_ping le nom de ma fonction
// numport le numéro du port sur l'activityBot

Cette fonction appelle la fonction de transmission d’information à l’activityBot (port série). L’information transmise sera codifiée de la façon suivante : PGXX (PG pour « ping » et XX le numéro du port sur lequel est branché le détecteur pour lequel je souhaite lire l’information). Exemple : PG08 pour le ping branché sur le port 8.

Problème rencontré avec la caméra et solution.

Pour faire mes tests, j’ai désactivé la partie du programme qui gérait la caméra et dans ma boucle principale. J’affiche à chaque tour de boucle la distance détectée par chaque détecteur ping de mon robot. Jusqu’ici, tout était parfait.

En voulant en même temps gérer le détecteur ping et la caméra (pour en même temps suivre un visage et déterminer la distance à laquelle se trouve ce visage), j’ai été confronté au problème suivant : quand le programme lit les informations du ping, il ne peut pas gérer la caméra et quand il gère la caméra, il ne peut pas détecter les obstacles. Cela avait donc pour conséquence de ralentir la vitesse de déplacement des moteurs de la caméra et du coup, le suivi de visage était beaucoup moins fluide. Autre inconvénient : lorsque mon robot se déplacera, il n’aura pas le temps de détecter certains obstacles (vu qu’il va être occupé à détecter les visages par exemple), et ne pourra pas les éviter.

La solution à ce problème a été d’utiliser ce que l’on appelle en programmation les « threads ». En gros, il s’agit d’exécuter des fonctions dans des processus indépendants. Du coup, les processus sont gérés simultanément (comme si on avait plusieurs programmes qui s’exécutent en même temps). J’ai donc fait une fonction pour la caméra que j’ai appelée « Detecte_Et_Suit_Visage() » qui est appelée dans un thread indépendant et laissé l’appel aux pings dans la boucle principale.

 Résumé.

Encore une chose de faite et de fonctionnel. mon robot est capable de détecter et de suivre les visages via sa caméra, et maintenant de détecter les obstacles en face de lui) ainsi que ceux en face de la caméra. J’essaierais de publier des vidéos de démonstration de tout cela plus tard afin que vous puissiez voire ce que cela donne réellement. Il est vrai que les photos et images ne font pas tout.

Mais avant cela, j’ai encore quelques articles à rédiger vu tout ce que j’ai déjà réalisé sur mon robot mais je n’ai pas encore eu le temps d’écrire. J’espère donc que tout cela sera pour bientôt.