Synchronisation Humain NAO : Différence entre versions

Version du 13 mai 2013 à 15:15

Introduction

Nous avons eu la chance de pouvoir réaliser notre projet de quatrième année sur le robot NAO. Il s'agit d'un robot humanoïde programmable. Ses usages potentiels sont très vastes, on peut l'utiliser par exemple comme robot de compagnie.

Présentation du projet

Encadrant

Rochdi Merzouki

Objectifs

Une collaboration existe avec l’école des sciences de l'art de Cambrais afin d'accompagner des danseurs professionnels en mouvements par des robots NAO.

Notre projet consistait à reproduire en temps réel certains mouvements articulaires humains par le robot NAO, ainsi on a dû trouver des solutions techniques pour que le NAO imite instantanément les mouvements d'un danseur.

Matériel à disposition

• un robot NAO
• logiciels nécessaires à la programmation du NAO (Choregraphe, python sdk, ...)
• une borne wifi
• une wimotte
• un récepteur Bluetooth

Bilan des séances

Séance 1 (4/2/2013):

- Découverte des robots.

- Prise en main du logiciel Chorégraphe.

Séance 2 (7/2/2013):

- Découverte des robots.

- Prise en main du logiciel Chorégraphe.

- Tests sur le Nao.

Séance 3 (11/2/2013):

- Rencontre avec Emmanuelle Grangier.

- Choix de capteurs pour acquérir les mouvements d'un bras.

- Constat que chorégraphe n'est pas adapté au temps réel.

- En conséquence, approfondissement de la programmation de Nao en Python.

- Contact de l'entreprise Interface-z, nous fournissant les capteurs et la carte d'acquisition.

Séance 4 (14/2/2013):

- Recherche de capteurs pour commencer à tester la fluidité des transferts de données ordinateur -> Nao.

Semaine 9 (25-29/2/2013):

- Récupération d'une wiimote.

- Récupération des valeurs des capteurs de la wiimote en temps réel sur l'ordinateur.

Semaine 10 (4-8/3/2013):

- Programmation d'un serveur en python.

- On utilise une socket python pour que l'ordinateur en tant que client du serveur nao envoie les données des capteurs en continu au Nao.

Semaine 11 (11-15/3/2013):

- Constat qu'un serveur n'est pas nécéssaire, en effet on peut directement envoyer les données au nao via la borne wifi en connaissant son adresse IP par un programme python.

- Réalisation d'un programme permettant d'envoyer des nombres via le terminal pour commander angulairement un moteur du nao.

Semaine 12, 13(18-29/3/2013):

- Difficultés dans la recherche de librairies permettant d'exploiter la wiimote sous windows.

- On a finalement décidé avec l'accord de M. Merzouki de passer sous linux pour faciliter le travail.

Semaine 14(1-12/4/2013):

- On a fait un programme fonctionnant sous linux avec CWIID et permettant de récupérer les angles pitch et roll.

- Sous windows, nous avons installé la librairie du nao (NAOqi) pour réutiliser le programme déjà fait pour le contrôle du nao. Nous avons eu de nouveaux problèmes de librairies.

fin du projet (15/4/2013 -> 3/5/2013):

- En raison du manque de temps restant, nous avons décidé pour avoir une solution présentable d'utiliser deux ordinateurs communicant par socket python, l'un sous windows commandant le Nao comme nous l'avions déjà fait, l'autre sous linux récupérant les données wiimote.

- Nous avons obtenu des résultats médiocres car la wiimote envoie trop de données, et le Nao ne peut les traiter en temps réel. On ne peut pas échantillonner l'envoi car la librairie CWIID ne le permet pas.

- Pour limiter les traitements, nous avons mis en place un traitement des données par paliers de 20 degrés.

- Le résultat est bien le respect du temps réel, mais il y a des perturbations à corriger.

Conclusion et améliorations

En conclusion, nous avons réussi à obtenir une solution quasi fonctionnelle, malgré le temps réduit du à de mauvais choix en début de projet. Cela était donc satisfaisant, en plus de l'apport personnel des découvertes du langage python et du robot Nao. Les nombreux problèmes que nous avons rencontré nous ont en outre fait progresser et nous ont demandé beaucoup de temps de travail et de recherches pour continuer de progresser.

Cependant, notre solution n'est pas optimale après ces trois mois de travail. En effet il faudrait améliorer le filtrage des données pour éviter des perturbations dans la réponse. Il faudrait aussi contacter aldebaran robotics pour obtenir une librairie fonctionnant avec linux 64bits, pour avoir un matériel moins imposant que celui de la solution sur laquelle nous nous sommes finalement tournés.