Version actuelle datée du 20 mai 2016 à 16:18

Jour I - 18 Janvier 2016

Séance de présentation du projet global où nous avons :

• Découvert le projet
• Constitué les binômes : Ce groupe est composé de Kévin Descamps et d'Antoine Gosse
• Choisi de travailler sur : un robot joueur
• Établi le cahier des charges (à l'aide de : BE_2015-2016)
• Pris des photos des différents éléments du châssis en cas de casse

Choix d'une sous partie : robot joueur

Après avoir échangé nos opinions avec les autres membres du groupe, nous somme parvenu à distribuer les tâches de chacun : nous avons fait en sorte d'avoir suffisamment de personne par sous-parties afin d'augmenter les chances d'avoir un projet final fonctionnel. Nous avons choisi de travailler sur le robot joueur qui disposera de 2 roues motrices et d'une roue libre.

Cahier des charges

Établi à l'aide de l'énoncé BE_2015-2016 Le robot doit être capable :

• d'éviter les collisions
• de suivre les lignes au sol
• de repérer la balle infrarouge
• de capturer la balle
• d'expulser la balle
• de communiquer avec les autres éléments du projet

Matériel à disposition

• 1 Châssis : 2 roues motrice, 1 roue libre
• 1 Arduino Mega2560
• 1 contrôleur pour les 2 roues
• 1 détecteur d'ultrason
• 3 détecteurs de ligne
• (4) phototransistors infrarouges
• 1 système de pince basé sur un servo-moteur
• 1 système d'éjection de la balle
• 1 bouclier XBee

Photos des éléments du chassis

Jour II - 21 Janvier 2016

Première modélisation "mâchoire circulaire.

Suite de la modélisation.

Partie Logicielle : Découverte de l'IDE d'Arduino

Comme nous débutons la programmation avec Arduino, nous avons consacré la majeure partie de cette séance pour nous familiariser avec l'IDE.

Nous avons tenté d'utiliser Ardublock (programmation de l'Arduino par bloc) mais nous avons rencontré des difficultés et finalement nous avons convenu qu'il serait plus judicieux de programmer directement en C en s'aidant d'exemples.

Nous avons testé le capteur de distance à l'aide d'un exemple trouvé sur Internet. Ceci nous à permis de comprendre ce capteur, les différentes connexions : ECHO, TRIG, GND et la manière de les brancher sur l'Arduino (comprendre le principe d'entrées/sorties)

Partie Matérielle : Un faux départ

Nous avons commencé à monter le robot avant d'apprendre qu'il fallait au préalable souder des fils, perdant une bonne dizaine de minutes. Cependant cela n'empêchant pas le montage de notre robot a la fin de cette journée =D

Après avoir convenu d'un système de pince de type "mâchoire circulaire" nous nous sommes affairés à la modélisation 3D de cette pince à l'aide du logiciel FreeCAD.

Jour III - 25 Janvier 2016

Modélisation 3D.

Capteur de ligne.

Partie Logicielle : Des capteurs tu utiliseras

Nous avons continué de découvrir les différents capteurs et plus spécialement le capteur de ligne, nous prévoyons d'utiliser 3 capteurs de lignes afin de guider le robot. Nous avons commencé à nous occuper des moteurs, nous commencerons les tests à la prochaine séance.

Partie Matérielle  : Va y avoir d'la casse

Nous avons avancé sur la partie matérielle. La pince à finie d'être modélisé, elle est été imprimée en 3D. Malheureusement certaines pièces trop fines ont cassées, nous allons donc renforcer la solidité de ces pièces en augmentant raisonnablement leur épaisseur à la prochaine séance.

Nous avons soudé des "pins" au bout des fils éléctriques afin de faciliter le montage et les essais sur l'Arduino.

Jour IV - 28 Janvier 2016

Test du capteur IR.

Moteur branché au Robot.

Partie Logicielle : Un Dilemme Cornélien

Nous avons également testé le photorécepteur Infrarouge. Celui-ci n'a pas une porté suffisamment longue si on veut un maximum de précision. C'est pour cela que nous allons devoir augmenter la detection et prendre le risque de faire des erreurs de précision. Nous tenterons toutefois de les résorber en utilisant 3 photorécepteurs.

Partie Matérielle  : Une Impressionnante Impression

La pince est terminée, nous avons finalement réussi à imprimer toutes les pièces intactes. Dans la partie matérielle, nous avons aussi surélevé de quelque centimètres la plaque supérieure du chassis du robot afin de pouvoir insérer l'arduino entre les deux plaques sans que les fils ne gènent. Les moteurs sont opérationnels. Nous avons rencontré des difficultés lors des branchements mais nous y sommes a terme parvenu.

Jour V - 29 Janvier 2016

Programme moteur.

Deuxième modélisation.

Partie Logicielle : Les premiers "pas"

Nous avons fait nos premiers pas dans le codage de fonctions en réalisant 4 fonctions pour les moteurs : Avancer, Reculer, Tourner à gauche, Tourner à droite. Nous avons essayé d'intégrer les capteurs dans le programme principal mais c'est pour l'instant un échec. Nous devrons nous pencher sur ce problème à la prochaine séance.

Partie Matérielle  : Un nouveau départ

Nous avons rapidement monté le capteur ultrason a l'avant du robot afin d'éviter les collisions lors du match.

Jour VI - 1 Février 2016

Arrière de l'ultrason.

Pince fermée.

Partie Logicielle : Les caprices d'Ultrason

Aujourd'hui nous avons fait face à un problème avec le capteur d'ultrason, le capteur renvoi des valeurs étranges. Plusieurs hypothèse de résolution s'offre à nous, une tension trop faible surement dû à une surconsommation des moteurs.

Partie Matérielle : Propulso'pince

Après des heures de modélisations et une interminable attente devant l'imprimante 3D, la pince 2.0 est nait. Celle ci corrige certains problèmes de la premiere pince, notamment le manque de resistance de la piece servant de propulseur. Malheureusement, il lui manque toujours quelque chose... et la finition n'est pas a la auteur de mes espérances. Je tente néanmoins de me satisfaire en faisant fonctionner difficilement le mécanisme de propulsion. Fort heureusement celui ci fonctionne meme ci quelque mauvais jeu de rouages viennent gâcher. Bilan ? Mitigé

Jour VII - 5 Février 2016

Ultrason vu de coté.

Modélisation pince ; vue de dessus.

Partie Logicielle : Ultrason fait encore des siennes

Le capteur d'ultrason ne fonctionne toujours pas, nous en avons testé d'autres mais le résultat est le même.

Partie Matérielle  : L'élastico'pince

La pince à été repensé et un système d'élastique à été rajouté. En effet dans la première versions de la pince le tir n'était pas très puissant, j'ai donc repensé la pince de façon a y intégré par le dessous un élastique. Apres l'impression j'ai donc mis un élastique jouant de rôle de "chargeur", le principe est simple en se refermant la pince va tendre l'élastique relié au poussoir. En ouvrant la pince l'élastique se détend propulse le poussoir , qui combiné a l'ouverture de la pince, va donner une impulsion supplémentaire a la balle. Mais ca c'était la théorie, en réalité quand le moteur change de sens se désactive une fraction de seconde, l'énergie accumulé dans l'élastique se libérait pendant se laps de temps perdant tout son intérêt.

Jour VIII - 8 Février 2016

L'ultrason est au milieu

Pince 3.0.

Partie Logicielle : La fin d'Ultrason

Le problème du capteur ultrason à enfin été réglé ! C'était un effet de bord du à l'appel trop rapproché de la fonction de lecture de la valeur du capteur.

Partie Matérielle : Jamais deux sans trois

La pince à été imprimée, elle est opérationnelle ! Cette nouvelle et dernière pince ne contient plus l'élastique "chargeur" jugé inefficace certaines parties on étaient renforcées. Le poussoir a été légèrement agrandi pour mieux guidé la balle. Certaines liaisons ont été renforcées pour pouvoir mieux résister a l'ouverture brutal de la pince.

Jour IX - 11 Février 2016

Robot avec pince.

Pince 3.0.

Partie Logicielle : Collision detected !

Nous avons fini la fonction de détection d'obstacles à l'aide du capteur ultrason, après plusieurs séance de non fonctionnement ce problème est enfin résolu et nous servira de leçon pour les autres capteurs et pour nos futurs projets.

Partie Matérielle  : Moi je tourne en rond, je tourne en rond

Nous avons par ailleurs fixé un servomoteur à la pince. Nous avons eu un soucis avec le premier servomoteur, celui-ci tournait sans s'arrêter. Ce problème était matériel et une fois le cette pièce remplacée la pince pouvait s'ouvrir et se fermer. (Nous avons testé les valeurs correspondante à la pince ouverte puis fermée).

Jour X - 22 Février 2016

Sur votre gauche, le co... capteur de ligne

Capteur de ligne mal soudé.

Partie Logicielle : On rentre à la maison

Aujourd'hui, nous avons commencé l'étude des capteurs de lignes. En effet, étant nouveau dans le domaine, nous avions du mal à nous représenter le fonctionnement du suivi de ligne. Nous sommes donc partis sur l'utilisation de 4 capteurs.

Partie Matérielle  : "Sans dessus dessous..."

Premier problème : Nous avons soudés les capteurs à l'envers... Nous avons donc découvert la méthode pour désouder, mais nous avons réalisé qu'elle était compliquée et que le composant pouvais être sérieusement endommagé. Nous ferons en sorte d'être plus vigilant à l'avenir car ceci nous à fait perdre quasiment une séance et gâcher un composant.

Jour XI - 25 Février 2016

Modélisation pince ; vue de dessous.

2 capteurs de ligne .

Partie Logicielle : Trouver sa voie

Nous avons commencé le programme de suivi de lignes. Nous sommes finalement partis sur 2 capteurs de lignes uniquement. Le programme consiste à avancer tout droit jusqu’à la détection d'une ligne puis à s'aligner sur celle-ci pour enfin la suivre. Nous avons rencontré une difficulté de codage : en effet nous faisions une boucle "while" tant qu'un capteur détectait un ligne mais nous n'avions pas pensé qu'il fallait dans cette même boucle actualiser la valeur du capteur.

Partie Matérielle  : Suivre sa voie

Nous avons donc perdu du temps sur cette étape mais à force de persévérance et grâce aux précieux conseils d'un autre binôme, nous avons réussi à corriger notre programme et celui-ci à parfaitement fonctionné. Le robot était en mesure de suivre une ligne. Sur la photo si contre vous pouvez admiré la propreté apparente de la fixation des capteurs de ligne. Mais ne vous inquiétez pas nous avons pensé a le fixer solidement sur un PCB qui sera proche du sol.

Jour XII - 29 Février 2016

Modélisation pince ; vue de dessous.

3 capteurs de ligne.

Partie Logicielle : Toujours aller de l'avant

A la séance dernière nous avions réalisé un algorithme de suivi de ligne, seulement nous avons oublié un cas important : le virage ! En effet, avec uniquement 2 capteurs de lignes nous ne pouvions pas faire la différence entre le virage à 90° et une sortie de piste.

Partie Matérielle  : A tribord toute !

Nous avons donc décidé d'ajouter un troisième capteur à l'arrière de sorte à ce que dès que les 2 capteurs de l'avant seront sur du blanc mais que le capteur arrière est toujours sur du noir, le robot pivote. Cette solution à vite été abandonnée car le robot n'arrivait pas à se réaligner correctement.

Jour XIII - 3 Mars 2016

Fritzing

4 capteurs de lignes.

Partie Logicielle : Ultrason... je t'ai compris

Vers la fin de cette séance nous avons commencé à penser au PCB, nous avons donc installé Fritzing ainsi que les composants spécifique au projet.

Nous avons pris en main le logiciel, ceci nous à permis de réaliser que nous devrions bouger certains situés sur la double rangée de pins de l'Arduino car il sera difficile voire impossible relier électriquement ces pins au reste du circuit.

Partie Matérielle  : Et de 4 !

Aujourd'hui nous avons rajouté un 4ème capteur de sorte à en avoir 2 à l'avant et 2 à l'arrière, ceci nous permet de détecter les virages à 90° mais l'éloignement des capteurs pose un sérieux problème : le robot part trop loin de la ligne et lorsqu'il pivote ne trouve pas cette ligne.

Jour XIV - 7 Mars 2016

Modélisation pince ; vue de dessous.

position des 3 capteurs de lignes.

Partie Logicielle : Machine Arrière

Nous avons abandonné le modèle à 4 capteurs pour revenir à un modèle de 3 capteurs, tous à l'avant avec celui du milieu légèrement avancé par rapport aux 2 autres. Ceci nous à pris un certains temps car le robot commence à comporter trop de fils et pour déplacer des capteurs nous avons accidentellement débranché certains fils... Nous avons sans succès réalisé un code similaire à celui du modèle précédent. Nous allons repartir de zéro sur les capteurs de lignes mais la séance prochaine sera consacrée au PCB.

Partie Matérielle  : Rien ne va plus

Ces 5 dernières séances quasiment exclusivement consacrées au suivi de lignes nous ont permises de voir que lors d'un projet il faut savoir se remettre en question quitte à modifier totalement quelque chose d'existant, qu'il ne faut pas avoir peur de faire des essais, de se tromper car c'est ainsi que nous pouvons apprendre de nos erreurs et progresser. Ceci de sorte à ce que si nous nous confrontons à un problème similaire dans le futur, nous soyons en mesure de le résoudre sans perdre du temps.

Jour XV - 10 Mars 2016

Modélisation pince ; vue de dessous.

Partie Logicielle : Fritzing, ton heure est venu !

Après avoir perdu beaucoup de temps sur le suivi de lignes, nous avons décidé d'entamer la conception du PCB. Nous avons pour cela utilisé le logiciel gratuit Fritzing. Après avoir importé les modules complémentaires spécifique à notre projet nous avons commencé à concevoir le shield qui contiendra les différents composants. Au départ la prise en main du logiciel s'est révélée difficile mais nous sommes vite habitués. Nous nous sommes également rendu compte qu'il nous restaient peu de séances pour finir le projet. A cause des difficultés rencontrés, nous ne serons probablement pas en mesure de finir totalement notre robot. Cependant nous avons déjà réalisé des parts isolé totalement fonctionnelles vues dans les précédentes vidéos.

Jour XVI - 14 Mars 2016

PCB haut du robot

Pince robot en action

Partie Logicielle : PCB : Problème Casse Bonbon

Aujourd'hui nous avons continué la conception du PCB sur Fritzing, nous avons remplacé le shield par deux petits PCB afin de pouvoir positionner le PCB contenant les capteurs directement sous le robot au bon emplacement. L'autre PCB contenant le contrôleur moteur sera lui placé au dessus du robot et contiendra le capteur ultrason. Après vérification par le professeur, il s'est avéré que le plan de masse de notre PCB présentait un problème empêchant l'impression de ce dernier.

Partie Matérielle  : J'en suis tout retourné ! Après quelques heures passés à observer le robot et plus particulièrement la pince. Nous en somme arrivés à la conclusion que la pince gênerait pour l'ultrason, une solution était donc de la retourner. Une fois ceci fait, la partie "piston" de la pince ne tenait plus... Après un peu de bricolage la pince tenait à nouveau.

Jour XVII - 17 Mars 2016

PCB bas du robot

Partie Logicielle : Un mariage réussi !

Nous avons essayé de faire fonctionner différents éléments en même temps : la pince, le capteur ultrason et les moteurs des roues. Nous avons programmé quelques fonctions basiques afin de tester la corrélation des 2 éléments (capteur ultrason et moteur) : La pince du robot s'ouvrait quand le capteur ultrason détectait une faible distance. Toutefois nous ne nous sommes pas aperçu que nous étions branché à l'ordinateur et au moment de retirer le câble pour tester le robot sur le terrain, celui ci demeurait inerte.

Jour XVIII - 21 Mars 2016

Alimentation Modulable

Robot ayant attrapé une balle

Partie Matérielle Méli-mélo

Aujourd'hui nous devons résoudre le problème du robot : nous avons réalisé un diagnostic complet de l'appareil. Tout d'abord nous avons remarqué qu'en débranchant la pince le robot fonctionnait de nouveau nous en avons donc conclu qu'il y avait un problème de puissance. Nous avons changé les piles, mais ça n'a rien changé. Nous avons ensuite testé une alimentation modulable afin de déceler d'éventuelles chutes d'intensité, témoin d'un composant défectueux. Cependant, ce test n'a rien donné de concluant, le robot ne fonctionnait toujours pas. Nous avons remarqué que lorsque le robot restait inactif la LED "L" de l'arduino clignotait continuellement alors que la LED témoin du bon fonctionnement de celui ci restait éteinte. Les recherches à ce sujet sur Internet n'ont pas abouties. Nous avons donc tenté de remuer les câbles afin de voir s'il y avait un faux contact. En effet ceci à permis au robot de refonctionner par intermittence, nous en avons déduit que notre robot présentait des problèmes de faux contacts au niveau de ses fils, il est donc primordial que nous ayons notre PCB sans quoi nous serions bloqué à cause de ce problème matériel.

Jour XIX - 11 Avril 2016

Modélisation pince ; vue de dessous.

Partie Matérielle  : Un début à tout Aujourd'hui, nous avons reçu nos PCB. Nous avons donc tenté de souder les composants dessus.. C'était une grave erreur ! En effet, nous avons du dé-souder certains composants mal placés. Nous avons appris qu'il fallait mettre des barètes femelles pour éviter d'avoir à dé-souder les composants en cas d'erreur. Malgré cela, nous avons rencontré un autre problème : les soudures touchaient la masse du PCB, et même en corrigeant à l'aide de la tresse nous ne sommes pas parvenu à rendre le PCB fonctionnel. Le problème était que les pistes étaient trop près de la masse. Pour la prochaine séance, nous réimprimerons nos PCB avec une marge de sécurité plus grande.

Jour XX - 14 Avril 2016

Programme moyenne IR.

Robot vue de devant.

Partie Logicielle : 01001101011000010111001001100011011010000110010100100000011100000110000101110011

Le programme de detection d'un capteur IR renvoyait toutes les valeurs. Comme la balle n’émet pas en continu le programme renvoyait des 0 périodiquement (quand la balle était détecté). Pour palier à cela nous avons établi une fonction qui fait la moyenne de 100 valeurs et donc ne renverra pas de 0 quand la balle sera détecté

Partie Matérielle  : Essai n°1256 Après l'échec de nos premiers PCB, nous voulions les réimprimer. Seulement, la graveuse à PCB était en panne, notre robot était démonté, nous n'avions donc plus la possibilité de faire des tests de programmes. Nous avons alors décidé de nous focaliser sur la réalisation de l'algorithme de suivi de la balle. Comme le robot était en pièce et que les contrôleurs moteurs n'étaient pas opérationnels, nous avons conçu un petit système à l'aide d'une Breadboard et de LED. Le principe était le suivant : La détection de la balle par un capteur IR provoquait l'allumage de la LED associé (voir vidéo) Nous n'aurions plus qu'a remplacer l'allumage des LED par les actions "Avancer","Tourner à gauche","Tourner à droite".

Ceci nous à donc permis de mettre à profit cette séance alors que tout semblait à notre désavantage. Notre algorithme de suivi de balle est opérationnel !

Jour BONUS - Mai 2016

2 Boitiers à piles encastrable dans le châssis

Branchement final PCB.

Partie Matérielle  : Le Jour J Nous avons reçu nos nouveaux PCB, la soudure était plus facile mais une fois fini nous nous somme rendu compte qu'il manquait un morceau de piste, et que par conséquent le PCB était inutilisable. Nous avons utilisé un autre PCB qui avait été imprimé dans une entreprise extérieur, une version plus récente qui ne contenait pas d'erreur. Nous avons dé-soudé puis re-soudé les barètes sur notre nouveau PCB, le PCB définitif. Même problème rencontré avec le petit PCB du contrôleur moteur, même résolution.

Nous avons ensuite rencontré un autre problème : en effet, nos capteurs IR étaient à l'origine placés sous le robot, sur le grand PCB... Avec notre pince massive à l'avant du robot, les capteurs étaient complètement obstrués. Nous les avons donc positionnés sur la pince à l'avant du robot.

Entre temps, nous avons réalisé un nouveau châssis pour le robot à l'aide de l'imprimante 3D. Ce châssis à été conçu sur-mesures et chaque élément avait sa place bien définie.

Une fois l'arduino dans l’habitacle du robot, les PCB fixés, la pince installée, nous étions prêt à regrouper nos programmes en un seul afin d'enfin pouvoir tester notre robot !

Partie Logicielle : Fusion ! La partie matérielle terminée, nous pouvions donc nous consacrer à la partie logicielle.

Nous avons modifié le programme de suivi de balle (initialement testé avec des LED) pour que celui-ci actionne les moteurs. Le programme à directement fonctionné et le robot suivait la balle lorsque celle-ci était assez proche de lui. Nous voulions ensuite intégrer notre pince pour attraper la balle. Au branchement de la pince, plus rien ne fonctionnait.. C'était un problème d'alimentation, nous avons ajouté un boitier de piles en parallèle pour palier à ce problème. Le servomoteur de la pince s'actionnait pour la refermer lorsque la balle était détecté à l'aide d'un 4ème capteur IR rajouté à l'intérieur de la pince. Le robot faisait ensuite un tour sur place avant d'expulser la balle...

Conclusion

Nous avons un robot fonctionnel, il ne rempli pas la totalité des tâches demandées par manque de temps.

Les 20 séances obligatoires et les nombreuses heures passées en plus, pour résoudre des problèmes ou continuer la projet nous ont permises d'avoir un robot capable d'évoluer aléatoirement à la recherche d'une balle. Quand celle-ci est dans son champ de vision, le robot est capable de s'orienter afin d'évoluer dans sa direction. Dès que le robot à la balle entre sa pince il la referme (a ce moment précis, le robot devrait s'orienter vers le but) fait un tour sur lui même et expulse la balle. Si le robot venait à sortir du terrain, les capteurs de lignes l'en empercherait.

Nous avons beaucoup appris pendant ce Bureau d'étude aussi bien côté théorique que pratique. Les expériences vécues durant ces séances nous seront utiles pour la suite de nos étude et pendant notre vie professionnel.