IMA4 2016/2017 P25 Robot mobile : Différence entre versions

Version actuelle datée du 19 mai 2017 à 21:35

Cahier des charges

Objectif

Le projet initial consistait à créer un kit de robot mobile pour l'enseignement secondaire. Etant donné la cible de ce projet toutes les parties doivent être facilement utilisables. Le but est qu'à terme, on puisse avoir un robot mobile conçu à partir d'éléments de base et de logiciels de conception libres tels que fritzing.

Description du projet

Partir du stage de l'an passé concernant la plateforme robotique pour l'enseignement secondaire et le finaliser. Les modifications à apporter sont au niveau de :

• La carte principale.
  • La version à base d'ATmega traversant, et réalisée dans le cadre du stage de l'an dernier, est presque fonctionnelle. Elle nécessite cependant quelques changements: lier les LEDs à une tension VCC=5V au lieu de la masse, changer la capacité des condensateurs du quartz à 22 pF, changer l'emplacement de quelques composants, tel que le quartz, qui doit être éloigné du convertisseur afin d'éviter les perturbations causées par ce dernier, tout en étant proche du µC. De même que pour les capacités de découplage qui doivent être proche du μC.
  • La version à base d'ATmega CMS, faite dans le cadre du projet [1], ne fonctionne pas, peut-être à cause du quartz qui s'avère difficile à souder.
• Du châssis: concevoir un châssis qui arrive à porter les deux types de motorisation : moto-réducteur d'entrée de gamme et moto-réducteur de qualité correcte.
• De la carte moteur : relier les deux plans de masse.
• De la carte suiveur de ligne : vérifier sa performance, prévoir son positionnement sur le chassis.
• Des piles : à mettre au dessous du châssis.
• La carte ultrason : concevoir une carte électronique avec des capteurs ultrason plus performants que sur les capteurs d'entrée de gamme du commerce. Réaliser le schématique et le PCB avec le logiciel Fritzing.
• Retour de vitesse : implanter un capteur de vitesse sur toutes les motorisations.

Choix techniques:matériel et logiciel

Après le premier rendez-vous avec notre encadrant, nous avons établi une première liste non exhaustive des composants que nous utiliserons.

• Le logiciel qui sera utilisé est Fritzing. Pour la conception du châssis, on prévoit utiliser Onshape
• Châssis : Plexiglas, moteur-réducteur ;
• Cartes électroniques : résistances, capteurs optiques, amplificateurs, connecteurs RJ11.
• Capteurs ultrason
• Capteurs Vitesse: Encodeurs incrémentaux

Liste des tâches

• Effectuer les modifications nécessaires sur la carte ATmega traversant et faire l'essai
  • Changement des LEDs, capacités..
• Diagnostique des problèmes de la carte ATmega CMS en faisant des essais
  • Soudage du quartz
• Proposer un modèle du châssis et faire une simulation sur Onshape
• Vérifier la carte moteur et faire des modifications jugées nécessaires
• Essais sur la carte suiveur de ligne
• Pour la carte ultrason, cette partie est la plus compliquée et qui prend le plus du temps, il faut faire le schématique et le PCB de nouveau, ainsi que changer les capteurs ultrasons
• Intégrer des capteurs vitesse pour avoir un retour sur les motorisations

Calendrier Prévisionnel

• 10H: Prise en main du logiciel Fritzing
• 20H sur la carte ultrason
• 10H: Réparation et simulation de la carte principale

Feuille d'heures

Etat d'avancement du projet

Phase préparatoire

Vendredi 16/12/16 - Rendez-vous avec M.Redon pour la présentation du projet et la définition du cahier des charges .

Semaine 1

Cette semaine fut entièrement consacrée à la prise en main des différents logiciels nécessaire à l'aboutissement du projet. Nous avons aussi repris les traveaux sur l'Atmega traversant et apportés les modifications explicités dans le cahier des charges. A savoir:

• Augmenter l'espacement entre le quartz et le convertisseur.
• Rapprocher le quartz et les capacités de découplage du µC.
• Lier l'anode des diodes d'état à une tension Vcc.

Nos modifications ont abouti aux schématique et PCB ci dessous:

• 

  Fig.1:Schématique

• 

  Fig.2:PCB

Semaine 2

Durant cette semaine, nous avons bossé sur la conception des cartes qui vont gérer la fonction suiveur de lignes et les moteurs( avec encodeur ). Nous avons abouti aux résultats suivants:

• Pour la fonction suiveur:

• 

  Fig 3.1:Schématique

• 

  Fig 3.2:PCB

• Pour la fonction moteur:

• 

  Fig 3.1:Schématique

• 

  Fig 3.2:PCB

Semaine 3

Nous nous sommes attaqués à la version CMS de l'Atmega au cours de cette semaine. En prenant en compte les remarques des travaux précédents, nous avons choisi de remplacer le quartz par un quartz plus grand :

• 

  Fig 4.1:Schématique

• 

  Fig 4.2:PCB

Nous avons aussi, après s'être entretenu avec nos encadrants, modifié:

• Le circuit du module USB FT232R des deux cartes principales:

• Le routage de toutes les cartes:

Atmega traversant

• 

  Fig 6:Carte moteur

• 

  Fig 7:Carte suiveur

Semaine 4

Au cours de cette semaine, nous avons eu un autre entretien avec nos encadrants. En effet, ils n'étaient pas très emballés par la production de la semaine précédente. Dans cette optique, ils nous ont demandé de tout d'abord, revoir le routage, puis rajouter les empreintes de résistances aux pins TXD et RXD du FT232R au cas où(car sur deux datasheets différentes, une présente ces résistances alors que l'autre non), rechercher les bonnes valeurs de condensateurs à l'entrée et à la sortie du LM1117, enlever la résistance et le condensateur aux bornes des pins RTS et DTR du FT232R, et enfin, de faire en sorte que toutes les pistes venant de composants en top soit en bottom. Cette semaine était donc consacrée à la réalisation de ses tâches.

Pour les valeurs de condensateurs, conformément à la datasheet du LM1117 (figure 8) on choisit une valeur de 10µF pour les deux.

Fig 8

Les figure ci-dessous présentent le schéma de câblage actualisé du FT232R ainsi que le routage des différentes cartes:

Fig 9

• 

  Fig 9.1 Carte moteur

• 

  Fig 9.2:Carte suiveur

• 

  Fig 9.3: Atmega traversant

• 

  Fig 9.4: Atmega CMS

Semaine 5

Ayant relativement avancé sur les cartes, je décide de basculer sur la partie programmation. Pour ce faire, j'ai installé Atmel studio pour pouvoir compiler mon code avant de le tester avec Proteus. J'implémente, pour commencer, la partie du code qui va commander les moteurs. D'un point de vue hardware, cette fonction est rempli par le composant TB6612FNG. Je me suis donc référé à la datasheet de ce dernier pour mieux comprendre son fonctionnement. La commande de chaque moteur est réalisé grâce à une combinaison de quatre signaux suivant la table ci-dessous.

Fig 10

Fig 11

En se référant au schéma de cablâge entre l'atmega et le TB6612FNG (fig. 11), je dois configurer les pins PB3, PB1, PD7 et PD8 en sortie et génerer un PWM sur les pins de sortie OC0A du timer0 et OC1B du timer1.

Comment générer un PWM:

Les Timers sont des compteurs cadencés selon une certaine fréquence définie. Lorsqu’il atteint son maximum (255 pour 8 bits et 65535 pour 16 bits ), il passe à 0 et recommence à compter. Ce passage de MAX à 0 peut s’accompagner d’une interruption interne. A ces Timers se rajoutent un comparateur dont on peut définir le seuil à l’aide du registre OCRxx. Lorsque le registre TCNTn du timer atteint la valeur de OCRn, alors la patte OCn change de valeur, passant de 0 à 1 ou de 1 à 0 selon la configuration puis retournant à la valeur initiale lorsque TCNTn passe de MAX à 0.

La configuration demandée est définie par la fonction init_mot:

Fig 12

Puis j'ai crée des fonctions pour chaque combinaison de commande du moteur. Pour la commande avancé tout droit, par exemple, je mets la broche 1 du port B à l'état 0 et la broche 3 du port B à l'état 1 pour le moteur A, la broche 7 du port D à l'état haut et la broche 0 du port B à l'état bas conformément au schéma de cablage ainsi qu'à la table de fonctionnement du TB6612FNG. La vitesse des moteurs est quant à elle fonction du rapport cyclique µ du PWM. Ce dernier peut être modifié grâce aux registres OCR0A et OCR1B, par la formule µ= OCRxx/255. Pour avancer droit, on doit logiquement donner la même vitesse au deux moteurs.

Fig 13

Afin de tester cette fonction, j'ai mis en place une simulation sous Proteus (figure 14), contenant, entre autre, un oscilloscope pour visualiser le PWM et des leds, aux broches PD7 et PB0, représentant le moteur B et aux broches PB1 et PB3 pour le moteur A.

• 

  Fig 14

• 

  Fig 15: Etat lors de l'execution de la fonction Avance

En suivant la même méthodologie,j'ai implémenter et testé les fontions permettant de réculer, s'arrêter, tourner à droite et tourner à gauche:

Fig 16

• 

  Fig 17

• 

  Fig 18

• 

  Fig 19

Semaine 6

Notre robot sera équipé de deux codeurs incrémentaux qui seront montés sur les moteurs. Cette fonction sera réalisée par le composant ktir0221ds. Il s'agit d'une fourche composée d'une diode infrarouge et de deux phototransistors montés en Darlington, ce qui permet une réponse très rapide. Ainsi si nous placions une roue à encoches entre la diode et le phototransistor, la fourche renverrait une série d'implusions: état bas lorsque une encoche se présente devant la diode et laisse ainsi passer le faisceau, état haut sinon (fig 20). Ce qui nous permettra par la suite de determiner la vitesse de rotation ou mesurer la position du robot.

Fig 20

Au niveau du code, j'ai choisi d'utiliser les interruptions externes INT0 et INT1. On génère une interruption à chaque front descendant pour aller incrémenter un compteur.

Fig 21.1

Ensuite pour lire la vitesse, j’utilise le timer 2 pour générer des interruptions. Étant un timer 8 bits, il n’est pas possible de générer une interruption toutes les secondes. Ainsi pour remédier à cela, je décide d’en générer toutes les millisecondes et dans la routine incrémenter un compteur qui, lorsqu'elle vaut la valeur 1000 entre dans une boucle qui nous permettra de rafraîchir la vitesse.

Fig 21.1

Le disque que j’ai modélisé sur Onshape (figure 21.3)contient 8 encoches. Ainsi pour avoir la vitesse en tour par secondes, on doit diviser, dans la routine d'interruption,la valeur du compteur par 8.

Fig 21.2

Fig 21.3

Semaine 7

Durant cette semaine je me suis occupé de l'implémentation du code permettant au robot de suivre une ligne. Le capteur utilisé est le QRE1113, il est composé d'une led infrarouge et d'un phototranstior. Le principe de fonctionnement est le suivant: le capteur étant orienté vers le sol, la LED émettrice envoie une lumière infrarouge que le sol réfléchit en direction du phototransistor qui capte ainsi la quantité de lumière en retour. Sachant que les couleurs foncées réfléchissent moins facilement la lumière que les couleurs claires. On pourra ainsi différencier une ligne noire d'une zone blanche.

• 

  Fig 22:Fonctionnement

• 

  Fig 23:Schéma de câblage

Le capteur utilisé étant analogique, j'ai utilisé le CAN du µC. Les voies de lectures sont la voie 3,4 et 5 (fig 23). je définis alors une fonction lecture_CAN pour qui prend en argument la voie de lecture et retourne la valeur du CAN relatif à la voie de lecture(fig 24)

Fig 24

Semaine 8 et au delà

j’ai travaillé sur la conception sur Onshape d’un châssis qui permettra d’accueillir les deux types motorisations ainsi que la carte de capteurs QRE1113 qui se sera suspendu à l’avant du châssis. Pour changer de moteur, il suffira d'enlever le bouchon rectangulaire et de disposer de la façon suivante: Le moto-reducteur de qualité correcte sera disposé sur la largeur alors que celle d'entrée de gamme, sera elle disposée sur la longueur.

Fig 25

J'ai aussi travaillé sur le code de fonctionnement générale du robot dont l'algorithme est représenté par le grafcet ci-dessous:

Fig 26

Livrables

• Cartes : Fichier:Mes Circuits.zip
• Code : Fichier:Code.zip
• Rapport : Fichier:Rapport Projet.pdf