Binome2015-10
Sommaire
- 1 Jour I - 18 Janvier 2016
- 2 Jour II - 21 Janvier 2016
- 3 Jour III - 25 Janvier 2016
- 4 Jour IV - 28 Janvier 2016
- 5 Jour V - 29 Janvier 2016
- 6 Jour VI - 1 Février 2016
- 7 Jour VII - 5 Février 2016
- 8 Jour VIII - 8 Février 2016
- 9 Jour IX - 11 Février 2016
- 10 Jour X - 22 Février 2016
- 11 Jour XI - 25 Février 2016
- 12 Jour XII - 29 Février 2016
- 13 Jour XIII - 3 Mars 2016
- 14 Jour XIV - 7 Mars 2016
- 15 Jour XV - 10 Mars 2016
- 16 Jour XVI - 14 Mars 2016
- 17 Jour XVII - 17 Mars 2016
- 18 Jour XVIII - 21 Mars 2016
- 19 Jour XIX - 11 Avril 2016
- 20 Jour XX - 14 Avril 2016
- 21 Jour BONUS - Mai 2016
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
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
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
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
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 monter le capteur ultrason a l'avant du robot afin d'éviter les collisions lors du match.
Jour VI - 1 Février 2016
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 : Un nouveau départ
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
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
Partie Logicielle : Ultrason... je t'ai compris
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 était légèrement agrandi pour mieux guidé la balle. Certaines liaisons on étaient renforcé pour pouvoir mieux résister a l'ouverture brutal de la pince.
Jour IX - 11 Février 2016
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
Partie Logicielle : On renntre à 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 : "La t'eate dans l'cul, l'cul dans l'brouillard"
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
Partie Logicielle : Continuer tout droit jusqu'a l'autoroute
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 : Va y avoir d'la casse
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
Partie Logicielle : Ultrason... je t'ai compris
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 : Va y avoir d'la casse
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
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 : Va y avoir d'la casse 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
Partie Logicielle : Ultrason... je t'ai compris
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 : Va y avoir d'la casse
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
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.
Partie Matérielle :
Jour XVI - 14 Mars 2016
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 ai suis tout retourné !
Après quelques heures passé à observé le robot et plus particulièrement la pince. J'en suis arrivé à la conclusion que la pince générait pour l'ultrason, la seule solution qui m'est venu à l'esprit était donc de la retourné ! Ainsi je pris mon courage a deux mains et je démonta la totalité de l'avant du robot... et la nouveau problème! La pince retourné ne tenait pas la partie "piston" ne tenait pas... J'ai fais les choses à la barbare... du scotch, du carton , de l'imagination et une bonne dose de bricolage ! Tadaamm... nouveau design, toujours plus craquant, Bobby is back !!
Jour XVII - 17 Mars 2016
Partie Logicielle : Un mariage réussit !
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
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
Partie Logicielle : Ultrason... je t'ai compris
Partie Matérielle : Va y avoir d'la casse 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
Partie Logicielle : Ultrason... je t'ai compris
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 : Va y avoir d'la casse
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
Partie Logicielle : Ultrason... je t'ai compris
Partie Matérielle : Va y avoir d'la casse
