Robot Centaure 2013
Présentation
Cahier des charges
Le robot de grande taille ou robot centaure est un projet qui a été reprit l'an dernier après plusieurs années d'abandon, à l'heure actuelle il est dans un état de fonctionnement correct mais des améliorations doivent lui être apportées afin qu'il puisse remplir sa tache de manière sure et autonome: à savoir se déplacer dans le hall sans danger pour le matériel et les personnes présentes dans celui-ci.
Objectifs principaux
- Permettre au robot de se déplacer de manière autonome dans le hall de l'école (ou ailleurs) de manière autonome et "fluide".
- Assurer la fiabilité de fonctionnement du robot d'un point de vue électrique.
Travail à réaliser
Partie Kinect:
- Améliorer le système de détection des distances à l'aide de la Kinect: Meilleur gestion des "zones d'ombres", augmentation du champ de vision (si possible).
- Création d'une application afin de faciliter le dépannage du robot en cas de problème.
- Affichage de messages sur l'écran du robot afin de le rendre plus "sympathique" pour le grand public. (ex: smiley, photo, ...)
Partie Robot:
- Optimiser le calcul de trajectoire afin que le robot se déplace de manière plus fluide.
- Optimiser la gestion des capteurs afin que ceux ci soit plus fiable (problème dut a la lumière du jour sur les capteurs infrarouges).
- Réglage du problème lié à la présence d'une roue folle à l'avant du robot qui entraîne des déviations de trajectoire lors de la remise en marche de celui-ci.
Avancement du projet
Semaine 1
Lors de cette première semaine, nous avons effectué des recherches sur le Robot Centaure en étudiant le rapport édité précédemment, afin de mieux comprendre son fonctionnement:
- Installation de tous les outils nécessaires pour executer le programme. ex. IDE, GTK 2++, Video.h etc.
- Lien pour télécharger la bonne version des libraries et le logiciel IDE:
> IDE : http://arduino.cc/en/main/software ou utilisez sudo apt-get install arduino > GTK 2++ : sudo apt-get install gtk2
Sachant que l'on a besoin de créer et réparer l'application GUI, il faut écrire un programme ainsi qu'un makefile en dehors des répertoires existants pour tester. Pour compiler executer le code qui utilise la package GTK2++, voir lien :
> http://gtk.developpez.com/cours/gtk2/
Prise en main du logiciel IDE:
Pendant la première semaine, nous avons trouvé que les codes sont étroitement liés, et que la compréhension des codes est très importante pour démarrer le robot. Pour la semaine 2, nous allons étudier le code Arduino ainsi que le code pour la partie Informatique.
Afin de comprendre le fonctionnement du robot et de pouvoir mener a bien le projet une longue phase d'analyse du robot a été nécessaire. Pour cela l'aide des IMA5 ayant travailler sur ce projet l'an dernier c'est révélé très utile.
Le robot est composé de nombreuse partie reliées électriquement entre elle: Batterie, Moteur et roue, Arduino, PC, Capteur IR, Boite à fusible, Kinect. Apres une rapide phase de vérification tous les parties semble correctement branchées et reliées entre elles.
Semaine 2
Pendant cette semaine, nous avons étudié le fonctionnement du Robot Centaure. Nous avons compris que : Pour lancer la fenêtre de kinect, il faut ajouter
> make -video
pour la compilation.
Pour arrêter le Robot dans le cas d'urgence, il faut appuyer sur le bouton rouge
Pour alimenter le Robot il faut brancher la pince rouge a droite et la pince noire a gauche, une inversion des deux pinces peut endommager les batteries
Limite: Sachant que la carte mère de l'ordinateur de ce robot a été cassé le semestre précédent, nous travaillons sur notre PC pour tester le code. Mais notre PC n'est pas assez puissant pour lancer le Kinect, c'est à dire que le programme s'arrête brutalement quelque fois, nous devons attendre l'arrivée d'une nouvelle carte mère pour tester la partie Kinect. Le robot prend 36 heures pour etre chargé totalement, nous avons donc décidé de travailler sur le code avant de tester le Robot, pendant chaque séance le robot est mis en charge jusqu'à ce que les batteries soient totalement pleines.
Semaine 3
Pendant cette semaine, nous avons travaillé sur le fonctionnement du robot par télécommande. Après avoir effectué plusieurs tests , nous avons trouvé que:
- La communication entre la carte Arduino et le Robot
> PROBLÈME DE TIMEOUT
- La communication entre la télécommande et le PC :
La communication entre la télécommande et le PC se divise en deux parties: Dans le fichier gestionIrc.c : Cette partie de code sert à récupérer les commandes envoyés par la télécommande. Le problème est que le programme n'affiche pas les commandes qu'il a reçu, cela veut dire que les commandes ne sont pas prises en compte.
switch(commande){
case 9 : printf("\ngestionIrc : stop");write(tubeSIHM[1],ARRET,ARRET_SIZE);strcpy(cmdPipe, CMD_PIPE_STOP); break;
case 201 : printf("\ngestionIrc : avance"); write(tubeSIHM[1],AVANCER,AVANCER_SIZE);strcpy(cmdPipe, CMD_PIPE_AVANCER);break;
case 73 : printf("\ngestionIrc : reculer"); write(tubeSIHM[1],RECULER,RECULER_SIZE);strcpy(cmdPipe, CMD_PIPE_RECULER);break;
case 169 : printf("\ngestionIrc : droite 45"); strcpy(cmdPipe, CMD_PIPE_DROITE_45);break;
case 41 : printf("\ngestionIrc : gauche 45"); strcpy(cmdPipe, CMD_PIPE_GAUCHE_45);break;
...
Dans le fichier gestionSerie.c : Cette partie de code sert à récupérer les commande envoyés par l'un des quatre tubes, et puis les envoi vers la carte Arduino. Le problème est que, quand on lance le programme, il ne recoit rien.
Objectif de semaine 4: Résoudre les problèmes trouvé pendant la troisième semaine. Essayer de contrôler le Robot avec le télécommande.
Semaine 4
Pendant cette semaine, nous avons travaillé sur les probmèmes que l'on a trouvé pendant la semaine précédente.
D'abord, nous avons trouvé que les ports définis ne correspondent pas à notre PC, nous avons changé le port de télécommande , et puis le programme a pu recevoir les commandes envoyés par le télécommande.
#define PORTCOMM1 "dev/ttyUSB0"
Dans le fichier gestionIrc.c
Ensuite, nous avons changé le port de Arduino:
#define PORTCOMM2 "dev/ttyACM0"
Il n'y a plus de problème de TIMEOUT. Nous avons essayé d'envoyer des commandes directement en utilisant le minicom, et nous avons trouvé que le Robot reçoit les commandes mais son comportement ne correspond pas aux touches de la télécommande tel qu'elles sont définies dans le rapport précédent.
En effet les commandes envoyées par le PC jusqu'à l'arduino ne sont pas les même que celles définies dans le programme arduino. Il a donc été nécessaire de modifier le programme arduino pour obtenir le comportement voulu. De plus le code Arduino contient des fonctions liées à l'utilisation d'une boussole pour corriger la trajectoire du robot. Hors cette boussole n'est plus présente sur le robot. Certaine partie du programme tel "avancer" ou "tourner de 90 degré" ne sont donc plus fonctionnelles. Nous avons supprimer les partie de code en question et les avons réécrites, certaines autres partie du code ont été simplifiées au passage
Cependant le programme gestionSerie.c ne reçoit toujours rien, cela veut dire que il n'y a toujours rien dans le tube.
'Le programme n'execute pas cette partie de code'
Après avoir étudié l'ensemble de codes, nous avons trouvé que les commandes ne sont pas écrites dans le tube tubeIS[0]. Pour résoudre ce problème, nous avons modifié le code dans le fichier gestionIrc.c pour que les commandes soient écrites dans le tube:
Nous avons aussi modifié le fichier gesitonSerie.c , pour que le programme puisse choisir entres les quatre tubes correctement:
Il y a trois façons de communiquer avec le robot:
1) Par la tube Kinect 2) Par la tube Télécommande 3) Par la tube WS,en utilisant une application Android
Après les modifications, nous avons réussit à contrôler le Robot en utilisant la télécommande.
Nous avons effectué des tests sur le robot, le comportement global du robot est satisfaisant, cependant les problèmes d'adhérences des roues sur le sol de l'école et la présence de la roue folle à l'avant l’empêche de se déplacer de façon totalement rectiligne ou entraîne une légère déviation au départ. Une solution doit être trouvée pour régler ce défaut.
Semaine 5
Pendant cette semaine, nous avons travaillé sur la partie IHM du code, pour que le robot puisse afficher les images correspondantes quand il avance, tourne à droite, à gauche...
Nous avons travaillé principalement sur deux fichiers, gestionIhm.c et gestionEcouteIhm.c . Les codes sont déjà écrit mais ils ne fonctionnent pas correctement, le programme ne charge pas d'image. Pour résoudre ce problème, nous avons pris connaissance de l'utilisation de l'outil GTK 2++. Voir lien pour le tuto:
> http://gtk.developpez.com/cours/gtk2/
En gros , GTK est un outil pour créer des interfaces graphiques. Après les modifications, le programme charge une image lors du lancement du robot par l'utilisateur.
Nous avons aussi étudié plusieurs solution pour régler les problemes de déplacement du robot. Plusieurs solutions ont été envisagé mais la seule réalisable est l'utilisation d'une boussole dans le robot qui détecte les modifications de trajectoire du robot lors d'un déplacement en ligne droite. Le programme arduino va ensuite modifier la vitesse de rotation des roues pour corriger cette erreur de trajectoire. La boussole utilisée l'an dernier n'est pas assez précise il faut donc en chercher une nouvelle.
Objectif de Semaine 6 : Ecrire des codes pour qu'il puisse charger plusieurs images, trouver une boussole assez précise.
Semaine 6
Pendant cette semaine, nous avons travaillé sur la partie GTK.
Nous avons créer une image de dépannage pour que l'utilisateur puisse facilement résoudre les problèmes rencontrés.
Dans le programme gestionEcouteIhm, le programme 'Ecoute' les commandes venant de la télécommande, et charge les images correpondantes. Touts les images sont chargées dans le vecteur images au début du programme principale. Voir fichier centaure.c
'Une partie du code dans le fichier gestionEcouteIhm.c'
Nous avons voulu charger l'image de dépannage quand il y a un appui sur le clé D, mais l'image de dépannage est décalée et nous sommes en train de résoudre ce problème.
Nous avons aussi décidé d'utiliser le modèle de boussole HMC6352 pour ce projet, sa résolution est d’environ 1 degré ce qui est largement suffisant pour ce projet (la résolution de l'ancienne boussole était de 3 degrés). Maintenant que la boussole est choisie il faut s'occuper de la régulation de la trajectoire du robot a l'aide de celle-ci.Il a été décidé que l'utilisation d'une commande floue serait le meilleur moyen d'assurer la précision des trajectoires du robot.
Semaine 7
Pendant cette semaine, nous nous sommes occupé de l'installation de l'ordinateur définitif pour le projet. L'espace dans le robot étant très limité et deja bien occupé nous avons récupéré la carte mère de l'ordinateur de l'an dernier et l'avons installé dans un nouveau boitier plus petit. L'alimentation en 12V du PC a aussi était refaites car l'ancienne carte n'était plus en état de fonctionnement. Une fois le PC testé nous l'avons installé sur le robot pour la fin du projet.
(l'intérieur de l'ordinateur)
Nous avons installé tous les outils pour exécuter le programme sur ce nouvel ordinateur. Le robot gagne grandement en autonomie et la partie Kinect peut enfin être testé. Il a aussi fallu changer un fusible du robot car l'alimentation du PC consomme 5A et le fusible ne pouvait en supporter que 3. Lors du test de la partie Kinect on s'est aperçu que l'écran du robot centaure s'éteignait aléatoirement, après remplacement du câble de l'écran ce problème est en grande partie résolu.
La commande floue pour la gestion de la trajectoire a aussi été réalisé, l'absence de boussole ne nous permet pas de la tester.
Semaine 8
La dernière semaine de projet à été consacré a la réalisation de nombreux tests sur le robot afin de s'assurer de son bon fonctionnement. Le comportement global du robot est satisfaisant, mais certains détails sont encore à améliorer.
Résultat
Compte Rendu
Rapport Robot Centaure: Fichier:Rapport Robot Centaure.pdf
Video
Code de la partie Logiciel
Code Source Partie Communiquante:
> Fichier:Partie Communiquante
