Robots humanoïdes 2013 groupe II

Projet de Coopération Nao N2N: Partie Communication/Réseau

Présentation du projet

Le projet global a pour but de réaliser une coopération entre deux robots NAO; cette coopération nécessite la synchronisation des deux humanoïdes à l’aide d’un serveur de données. Les NAO doivent donc utiliser des données communes pour se synchroniser, par exemple: déplacement d’un carton “volumineux” à deux. Ceci induit que les NAO vont devoir synchroniser leurs positions, ainsi que leurs déplacements, afin de pouvoir réaliser correctement l’action.

Cahier des charges

- Communication entre deux robots NAO à l’aide d’un serveur de données, afin de pouvoir réaliser une coopération synchronisée entre ceux-ci.

> Pour cela, nous allons donc utiliser une mémoire partagée afin de communiquer les différents états possibles dans lesquels seront les NAO (attente, prêt, etc.), ainsi que les positions des NAO afin d’effectuer une bonne synchronisation lors des mouvements.

- Communication entre les NAO et le routeur réalisée par WiFi: réception et envoi de données entre les NAO et le routeur.

> Programmation en C++ (a priori) dans les NAO.

Étapes importantes (prévisionnel)

1. Étude approfondie de la communication NAO vers PC et PC vers NAO;
2. Création d'une zone de mémoire partagée;
3. Détermination des échanges à effectuer pour accomplir la tâche définie auparavant.

Avancement du projet

Semaine 1

Lors de cette première semaine, nous avons effectué des recherches sur le NAO afin de mieux comprendre son fonctionnement:

> prise de connaissance des bibliothèques spécifiques au NAO, ainsi que des variables qui sont indispensables à son bon fonctionnement;

> prise en main des logiciels utiles et nécessaires à la programmation sur PC du NAO;

> réalisation de tests avec le NAO: programmes en C++ de base pour contrôler le NAO (nous avons réussi à faire parler le NAO à l'aide d'un PC lié par câble ethernet au routeur et une connexion Wifi établie entre le routeur et le NAO).

Objectifs pour la semaine 2: écrire des programmes de test qui agissent sur les actionneurs et qui récupèrent des données du NAO.

Semaine 2

Nous avons essayé de compiler plusieurs autres programmes proposés par Aldebaran:

> problèmes liés à la compilation en début de semaine, désormais réglés;

> tests en compilation simple qui agissent sur les actionneurs du NAO (sa tête, par exemple);

> problèmes de cross-compilation: impossibilité de tester des programmes qui nécessitent d'être dans le NAO.

Objectifs pour la semaine 3: réaliser une cross-compilation afin d'agir sur les actionneurs, suivant les actions réalisées sur les capteurs du NAO et récupérer des données du NAO.

Semaine 3

Après des réapparitions de problèmes liés à la compilation, nous avons décidé d'enquêter sur notre compilateur (qibuild) distribué par Aldebaran. Il est apparu que ce compilateur n'était pas à jour et ne convenait pas à notre version du NAO. Il nous empêchait notamment d'utiliser les commandes de déploiement du programme directement dans le NAO (deploy...). Désormais: Utilisation de qibuild2.

Nous avons alors repris le travail précédent (compilation et test des exemples) avec ce nouveau compilateur légèrement différent mais plus fonctionnel. Ensuite nous avons constitué notre architecture de travail afin de commencer à créer nos propres programmes en s'inspirant des exemples testés auparavant.

Premier test avec qibuild2: récupération des données de la centrale inertielle du NAO.

> dans un premier temps, en lançant le programme à partir du PC: Succès de la récupération des valeurs sur le terminal en temps réel;

> dans un deuxième temps, le but était d'écrire ces valeurs dans un fichier .txt afin d'en garder une trace. Nous avons pu implémenter l’exécutable de ce code directement dans le NAO grâce aux nouvelles commandes de qibuild2.

Nous avons alors utilisé la cross-compilation, c'est-à-dire compiler un code afin de créer un exécutable compréhensible par différentes plate-formes (ici le NAO et le PC). Ensuite, l'exécution du binaire peut se faire simplement en passant par ssh dans le NAO. Après lancement, on récupère ainsi dans un fichier .txt des valeurs de la centrale inertielle le temps de l'exécution du programme.

Objectifs pour la semaine 4: déployer un code dans le NAO permettant de tester certains capteurs afin de le faire réagir selon leurs états.

Semaine 4

Nous avons essayé de modifier un code d'exemple fourni par Adebaran afin d'agir sur le NAO. Cependant, nous nous sommes aperçu que beaucoup de paramètres concernant les degrés de liberté du NAO devaient être modifiés afin de réaliser un simple mouvement de bras. Nous avons décidé de ne pas nous y pencher, car ce genre de mouvements est facilement réalisable via Chorégraphe...

Nous avons ensuite réfléchi à une manière simple de synchroniser le NAO (sans passer par la mémoire partagée pour le moment):

> nous avons vu que le NAO pouvait attendre la fin d'un événement réalisé par lui-même avant de réaliser une nouvelle action (par exemple, après avoir parlé);

> nous avons alors réalisé la suite d'événements suivants:

> abaissement de la tête du NAO (récupération des valeurs liées à l'axe de la tête du NAO)

> réaction du NAO par la parole (après avoir dépassé un certain seuil lors de son mouvement de tête)

> mouvement quelconque du NAO (après l'événement de parole)

Objectifs pour la semaine 5: réaliser une synchronisation simple entre deux NAO, à l'aide des modules de détection de sons ou de parole.

Semaine 5

Nous avons commencé par tester des exemples de détection de sons et de détection de langage:

> la détection de sons tourne autour d'une détection de seuils: le problème rencontré est que le NAO s'entend marcher et bouger, ce qui rend impossible la synchronisation grâce à ce moyen;

> la détection de parole consiste à pré-saisir une liste de mots que le NAO pourra reconnaître: après avoir effectué des tests, nous avons remarqué que le NAO détectait très bien les mots prononcés par le second NAO, mais moins bien ceux prononcés par nous.

Cette seconde solution nous permettrait alors de réaliser une synchronisation de manière facile; toutefois, nous pensons que réaliser un système client-serveur nous permettra d'avoir une marche de manœuvre plus grande pour la communication entre NAO (par exemple, si l'on fait interagir plus de deux NAO).

C'est pour cela que nous avons commencé à réaliser un système client-serveur, avec pour clients les NAO et pour serveur un PC. Le système actuellement réalisé permet les échanges client-serveur entre deux PC. Nous allons devoir intégrer à ce programme le code nécessaire au NAO pour exécuter un programme local (donc dans le NAO).

Par ailleurs, nous avons réfléchi à l'algorithme simple de synchronisation que nous allons utiliser pour synchroniser les deux NAO avant qu'ils ne réalisent l'action de soulever ensemble un objet.

Objectifs pour la semaine 6: intégrer l'algorithme de synchronisation et le code requis pour l'exécution du programme sur le système du NAO.