You are here

Projet NAO - Détecter et suivre une balle

Les progrès de la robotique font qu’il est possible, aujourd’hui, d’avoir des robots humanoïdes, qui intègrent de nombreuses fonctions interactives : reconnaissance et synthèse vocale, yeux lumineux, capteurs "tactiles", infrarouges... Il est alors intéressant d’imaginer, dans un dispositif d’aide aux personnes, que l’on puisse demander à ce "compagnon" d’aller chercher un objet et de l’apporter quelque part.

Le problème posé au départ, et auquel, avec trois de mes camarades, nous nous sommes consacrés au cours de ce projet, était le suivant : écrire un programme qui permette à Nao de repérer un objet d’une certaine couleur dans une pièce, se diriger vers lui, et le ramasser. Les opérations de détection et de déplacement doivent pouvoir s’exécuter simultanément, pour pouvoir ajuster la direction du robot au fur et à mesure de son déplacement. Pour cela, il faut prendre en compte le fait que le robot oscille fortement lors de la marche, afin de ne pas lui donner des informations erronées, et ne pas le faire changer de direction inutilement.

NAO, le robot humanoïde intéractif. Photo fournie par Aldebaran Robotics.

L’environnement de travail fixé est le suivant : développement en langage C++ sous Linux.

Déroulement du projet

La réalisation de ce projet a nécessité de passer par différentes phases :

  • installation des librairies,
  • découverte du robot NAO,
  • conception de l'application,
  • développement et test du programme.

Installation des librairies

Les différentes librairies que nous avons utilisées dans le cadre de ce projet sont :

  • la librairie Mirage développée par l'équipe IMS du campus metzin de Supélec. Il s'agit d'une librairie de traitement d'image. Elle utilise la librairie jpeg-c++.
  • la librairie NaoQi fournit par Aldebaran qui permet d'utiliser le robot avec un haut niveau d'abstraction.

Découverte du robot Nao

Lors de la phase de découverte du robot NAO, nous avons testé les différentes fonctions de l'API fournit par Aldebaran afin de se familiariser avec son fonctionnement. Ces quelques tests nous ont permis d'apprécier la richesse des fonctionnalités de ce robot tant pour ses mouvements que pour son intéraction avec son environnement et tout particulièrement ses intéractions avec les êtres humains.

Cette phase du projet a également été l'occasion pour nous de nous familiariser avec la documentation fournie par Aldebaran.

Conception de l'application

Nous avons, ensuite, passé un peu de temps sur la conception de l'application. Nous avons ici consacré du temps à une réflexion sur l'architecture de l'application.

Développement et tests

Nous avons ensuite procédé au codage du programme en C++ et à des tests selon un modèle itératif : écriture d'un peu de code qui est ensuite validé par des tests. Une nouvelle fonctionnalité est ajoutée après que la précédente ait été jugée pleinement satisfaisante.

Architecture du programme

Nous avons choisis de découper le système en deux sous-systèmes fonctionnant selon le même principe. D’un côté nous récupérons des données envoyées par le système de vision vers la tête qui les traite afin de suivre l’objet. De l’autre la tête fournit des données, lesquels après traitement, permettent de déduire les ordres de déplacement du robot.

Schéma représentant la division en deux sous-système de l'application. D'un côté, des données en provenance de la vision sont traitées avant de permettre le mouvement de la tête. De l'autre, la position de la tête est traitée avant de permettre au NAO de marcher.

Dans chaque cas, un "capteur" est relié à un "actionneur" en passant par une interface. L'implémentation de ces interfaces utilise des templates. Les données circulant entre les différents ensembles sont des doublets, nous avons pour cela écrit une structure correspondante. Les trois parties du robot (système de vision, tête, jambes) sont représentés par trois classes dans le programme. Une fonction main vient chapeauter le tout.

Afin de minimiser le nombre de threads dans l'application et de garantir une certaine cohérence de le cheminement des données, nous avons décidé que seules les interfaces seraient des threads.

Au final, le code se compose d'environ six classes.

De la vision au mouvement de la tête

A l’aide des caméras situées dans la tête, on enregistre une image de ce que "voit" Nao. Via des traitements basés sur la couleur de l’objet à chercher, on traite l’image afin d’en déduire la présence ou non de l’objet.

A partir d'une image en couleur issue d'une caméra du NAO, on réalise une comparaison par rapport à une couleur de référence. On obtient une image booléene de l'environnement indiquant la position de la balle.

Si l’objet est présent, sa position dans l’image est récupérée puis convertie en coordonnées angulaires qui sont envoyées à la tête. Celle-ci tourne alors de façon à centrer l’objet sur les images récupérées par la vision. Les instabilités, dues au mouvement de balancier de Nao lorsqu’il se déplace, sont atténuées par des contraintes en terme de vitesse et d’accélération sur les mouvements de la tête.

Si l’objet n’a pas été détecté sur l’image issue de la caméra, Nao se place en mode "recherche de l’objet" et
parcourt un certain nombre de positions avec sa tête afin de trouver celui-ci.

De la postition de la tête au déplacement

L’ensemble Vision/Tête permet au programme de fonctionner dans deux modes : "recherche de l’objet" et "suivre l’objet".

Si le programme est dans le mode "recherche de l’objet", Nao reste immobile sur ses jambes tant que la tête n’a pas parcouru l’ensemble des positions définies ou que l’objet n’a pas été détecté. Si toutes les positions définies pour la recherche de l’objet ont été parcourues sans succès alors Nao tourne d’un quart de tour et reprend la recherche de l’objet.

Lorsque l’objet a été détecté, la tête, par l’intermédiaire de l’interface, transmet ses coordonnées angulaires de position au système de déplacement qui en déduit les ordres de marche à transmettre à Nao.

Schéma permettant le calcul des paramètres de déplacement de NAO.

Interaction entre les deux sous-systèmes

Comme nous venons de le voir, le sous-système Tête/Jambes est relativement dépendant de celui formé par la Vision et la Tête. En outre, ces deux systèmes ont des temps de cycle différents du fait de la mécanique interne au robot : les consignes de marche n’ont pas besoin d’être actualisées aussi souvent que celles gérant la
position de la tête.

Validation du projet

A la fin de ce projet, nous avons remis au professeur encadrant :

  • le code commenté composant notre projet,
  • un rapport d'une cinquantaine de page résumant la démarche que nous a guidé durant ce projet ainsi qu'une documentation complète du programme.

Pour valider ce projet, nous avons présenté notre travail dans le cadre d'une soutenance devant le professeur encadrant ce projet ainsi que l'ingénieur responsable de la smart-room de Supélec. Cette présentation a été suivie d'une démonstration.

Le programme conçu lors de ce projet, après quelques ajouts apportés par les enseignants-chercheurs de l'école, est aujourd'hui utilisé lors de démonstration (fête de la science, notamment).