Robots mobiles 2012

De Wiki de Projets IMA

Présentation

Cette reprise de projet a pour but d'améliorer l'utilisation du capteur de couleurs sur le DFRobot Rover et d'enlever l'arduino présent sur le second châssis (il doit être capable de fonctionner sans). Bien sur, tout cela en gardant les fonctionnalités du projet de l'année passée.

Préparation du projet

Matériel requis

DFRobots Rover V1.5
  • Châssis DFRobots Rover V1.5
    • Arduino ATMega328P
    • Moteurs Tamiya L293
  • Servomoteur HS-422
  • Sonar SRF-05
  • Bus I2C (Inter Integrated Circuit)
  • Capteur de couleurs ADJD-S371
  • Foxboards
  • Second châssis fonctionnant par Phidgets
  • Câbles variés (série, rj45...)





Matériel à acheter

  • câbles de connexions pour l'adaptateur placé sur le cpu de la Foxboard pour faciliter l'implémentation des périphériques.
  • capteur de couleur ADJD S371 CR999.
  • boussole LSM303 Breakout Board - Tilt Compensated Compass sku: SEN-10703.

Avancement du projet

Objectifs suggérés par les encadrants

Réalisations concrètes

  • Confection de câbles d'alimentation à partir de câbles série pour pouvoir alimenter les foxboards
  • Entretiens mécanique du robot
=> rénovation partielle du robot (chenilles, moteurs)
=> réparation du port USB
=> amélioration de l'agencement du robot (câblage entièrement refait)
  • Larges modifications du code source arduino en ce qui concerne le capteur de couleur (principalement)
  • Amélioration du reste des fonctionnalités implémentées sur le robot
  • Création d'un fichier ReadMe pour faciliter la reprise du projet (tous les documents relatifs à ce projet seront également placés dans le dossier ou se trouve le readme dans la foxboard.

Séances

Première séance

  • Réparation d'un cable de multimètre.
  • Fabrication de deux alimentations USB pour les Foxboards.
  • Récupération des images systeme des deux Foxboards du projet de l'année passée.
  • Vérification de la communication via une clé Wifi entre la Foxboard et un ordinateur de TP.

Deuxième séance

  • Soudure du port usb situé à l'arrière du châssis n°1.
  • Tests pour vérifier que la soudure est correcte => le port usb est fragilisé (il peut y avoir un faux contact sur la branche 3), mais le port fonctionne.
  • Premier tests pour faire avancer le châssis n°1 => le robot avance, et peut être commandé au clavier par liaison série (sans soucis).
  • Remarques :
    • Le châssis n'avance pas sans alimentation usb => solution : changement de piles + léger étirement des chenilles (pour tenter de réduire le couple résistant).
    • Après le robot se déplace mais toujours avec difficulté => autre solution envisagée : graissage du mécanisme mais non réalisée.

Troisième séance

  • Récupération de la version finale de l'image système de la Foxboard. (notre version n'était pas la plus avancée).
  • Remise en fonctionnement du wifi de la foxboard => la foxboard arrive maintenant à se connecter au réseau de l'école.

Quatrième séance

  • Nous avons trouvé le nom du capteur de couleur utilisé (aucune trace de son achat ou son nom dans le projet précédent). => ADJD-s371
  • Chaîne de communication web => fox => arduino rétabli.
  • Test du mode manuel via interface web => le robot fonctionne normalement(après écriture du code arduino en fonction du code déjà existant).

Cinquième séance

  • récupération d'un exemple de code pour le capteur de couleur or Problème : cela ne fonctionne pas.
    • teste avec une LED 256 couleurs => pas de lumière.
  • Après une batterie de testes entre les deux arduinos et les deux capteurs de lumière (identiques) nous en déduisons qu'un des capteurs est mort.
  • Problème non réglé : avec le capteur de couleur opérationnel, il ne fonctionne pas avec le châssis n°1 => prochaine séance : vérification du câblage avec un ohmmètre.

Sixième séance

  • Nous avons vérifié tout le câblage pour trouver pourquoi la LED du capteur de couleur ne s'allumait pas :
    • Finalement, il semble que le bus gris (I2C) ne fonctionne pas : faux contact sur la branche 4.
    • Après avoir "gratté" un peu la broche le câble fonctionne.
    • Solution magique = solution provisoire. Donc nous ferons peut être un autre bus.
  • Projet à venir :
    • Construire une plaque pour la version définitive du hardware (plus solide).
    • Etablir un début de code pour faire fonctionner le capteur de couleur.

Septième séance

  • Nous avons scié la plaque pour avoir un circuit définitif. Or nous n'avions pas de fer à souder => prochaine séance.
  • Test du code du capteur de lumière avec la LED => cela fonctionne. (on a de la lumière : mais Maxime a la peau bleu...)
    • Donc On va chercher par la suite à comprendre le code pour avoir des couleurs cohérentes.

Huitième séance

  • Nous avons fait des tests pour calibrer le capteur de couleur : nous réussissons à avoir des couleurs dont les valeurs sont comprises entre entre 0 et 255.
    • Problème

=> la luminosité ambiante joue énormément sur les valeurs retournées par le capteur (puisque nous avons enlevé le cache qui entourait le capteur !
=> tentative d'harmonisation des couleurs.

CONSTATATION : en faisant varier les valeurs des gains associés à chaque couleur (sensibilité) , impossible d'arriver clairement à faire quelquechose de propre.
OR en diminuant la distance par rapport au sol du capteur, les différenciations sont un peu plus efficace.
=> Solution envisagée : diminuer la position du capteur de lumière pour réduire l'effet de la luminositée ambiante?

  • Nous avons besoin de 4 couleurs pour que le robot puisse suivre la ligne correctement.

- on définit le blanc comme >245 dans les trois couleurs. - création d'un fonction "getvalue" pour la couleur de la LED : nous abandonnerons la LED une fois que nous auront bien compris le code. Nous observons les données envoyées sur le port série. Nous arrivons à peu près a avoir des valeurs correctes (nous atténuons la valeurs des couleurs non dominantes).

PROBLÈME : On doit choisir 3 couleurs faciles à capter : rouge, blanc, et ??!
Impossible de trouver une configuration de couleur assez stable!

Neuvième séance

  • tableau récapitulatif de la correspondance des variables entre les programmes arduino et rfrobot.c et conduire.html
    • on s'est rendu compte que le programme que nous modifions n'était pas le bon. PRESENCE DE 3 FICHIERS RFROBOT.C !!! => suppressions des fichiers inutiles
donc le tableau récapitulatif est maintenant correct.
  • mode autonome anormalement lent... après inspection : un cable s'était débranché => dorénavant completement opérationnel

Dixième séance

  • proposition de solution pour le capteur de couleur :
il est évident que le code précédent ne fonctionne pas à la lumière ambiante, les conditions sur les valeurs sont éronnées.

On pense donc revoir les conditions et essayer de travailler en "rapports" ainsi peut importe les valeurs reçues par le capteur, il devrait fonctionner.
On veut également prendre en compte l'intensité lumineuse : on branche le signal sur une pin PWM pour pouvoir ensuite faire varier l'intensité lumineuse de la LED.

- on aimerait que la luminosité n'influt pas sur la valeur relevée.

=> on aimerait donc créée une sorte de fonction ou calcul :
clear 0V-----------255
nV?----------30

Prochaine séance, ça serait bien d'arriver à calibrer le capteur de couleurs.

Onzième séance

  • objectif :

- Faire varier intensité de la LED du capteur du couleur avec signal PWM. DONE !!! (reste à savoir où le placer dans le programme et comment la faire varier).
Pour l'instant c'est dans suivi sens 1 et la fonction "turn" !! - Réussir le calibrage du capteur (trouver une relation).
- On peut commander l'intensité lumineuse!! avec la pin digital 10 (PWM)

On calcule l'intensité avec la variable "ccValue" de manière à allumer la led avec une intensité différente !
On prospose "255-ccValue" mais cela ne fonctionne pas correctement (erreur digital/analog)

Problème la LED fonctionne avec le digitalwrtite mais pas avec l'analogWrite !!

=> SOLUTION CHANGER DE PIN -------> PIN 11 POUR LA LED

- Le signal PWM fonctionne mais que pendant 5s !!
Peut etre qu'il y a trop de données envoyées? solution : réduire la mise à jour de la LED ?
Ecrire moins souvent sur le port série?

Douzième séance

  • On a essayer de comprendre le problème. Il en résulte que on sait toujours pas MAIS

la pin 10 fonctionne indépendamment du programme - elle fonctionne avec une communication série et I2C après plusieurs tests - qu'un analogWrite 255 fonctionne - que la fonction getcolorvalue plante dès que l'on a un analogWrite dedans.

Test avec un autre arduino => le programme ne fonctionne pas non plus => pas un probleme hardware
Pas besoin non plus de reécrire la fonction analogWrite.

Treizième séance

- Tentative de solutions : résoudre le problème ou le contourner...?
-- fonction en plus avec seulement analogwrite...??
-- problème récupérer la valeur de ccValue? en passant par pointeur?
=> solution non trouvée.

Quatorzième séance

  • PROBLEME : appel de la fonction getcolourValue() avec un while => bug meme sans analog write... !!!

- solution ? reécrire une fonction spéciale pour le suivi de sens?
- nouveau capteur de couleurs : ADJD S371 CR999
- boussole : LSM303 Breakout Board - Tilt Compensated Compass sku: SEN-10703 Pour permettre de bien suivre une ligne droite et de corriger le cas échéant
- Problème du capteur de couleur introuvable => changement capteur de couleur

=> ÇA MARCHE !! Après quelques retouches, on arrive à faire varier l'intensité lumineuse de manière soft.

- Fabrication support pour le nouveau capteur (soudure + perçage).
-Prochains objectifs : étalonner les valeurs des couleurs RVB. Ainsi on pourra finaliser la fonction suivre_sens_1.

Quinzième séance

  • On a changé la manière de définir les couleurs. Nous travaillons maintenant avec des rapports! ainsi on peut trouver la couleur peut importe l'intensité lumineuse.

Enfin il nous reste à trouver une contrainte supplémentaire sur le BLANC..
On a actuellement :
RED = rouge
BLACK = vert
GREEN = bleu
Il faut donc changer les noms pour plus de cohérence dans le programme. Et définir le blanc. Après les fonctions "suivi_sens" pourront fonctionner normalement...

Rapport

media:rapport-robots-mobiles.pdf