synthese

PPE 2009
LY Cédric TS4
PROJET ARTEC
PROGRAMMATION

Dans le cadre du Projet Pluritechnique Encadré notre groupe, composé de Justine PORTE, Delphine
NGO, William LIEN et moi-même, avions pour but d’imaginer un robot qui doit suivre 1144cm de ligne noire
continue large de 3cm.

A N A L Y S E F O N C T I O N N E L L E
Tout d’abord, avant de nous répartir les différentes taches, nous avons réfléchi sur notre futur robot, pour cela nous avons fait une analyse préliminaire qui est l’analyse fonctionnelle, celle-ci étant composée :
- d’une bête à corne et d’un diagramme pieuvre : ceux-ci ont permis de connaitre le besoin de notre projet,
le but (parcourir la ligne le plus rapidement possible) puis ensuite grâce au diagramme pieuvre déterminer
les fonctions contraintes qu’il faudra franchir (coût, taille…).
- d’un F.A.S.T qui nous a permis de trouver une solution technique pour chaque fonction que devait réaliser
le robot comme capter la ligne (capteurs optiques) ou avancer (moteurs) par exemple.

R E P A R T I O N D E S T A C H E S



P R O G R A M M A T I O N

Page 1
PPE | 2009
1) Robot Prototype
a) Préliminaires
Il nous a tout d’abord été fourni une feuille explicative pour programmer un robot prototype, nous
avions aussi à notre disposition un robot prototype sur lequel nous pouvions transférer notre programme
que l’ont à créé sous FLOWCODE afin de le tester sur la piste !
J’ai commencé par convertir les valeurs qui nous étaient donnés comme les valeurs decimales que
l'on donnait au moteur et auquel était associé une certaine vitesse :
- 000000, 0 en code décimal, ce qui correspond à une vitesse de -1m/s
- 001111, 31 En code décimal, ce qui correspond a une vitesse de 0m/s
- 111111, 63 en code decimal, ce qui correspond a une vitesse de 1m /s
J’ai ensuite converti l’état des capteurs en code decimal : 
ici les capteurs détectent la ligne noire tout à droite ce qui correspond au code decimal
124 puisque les 2 premiers bits (C0 et C1) sont masqués, que le premier bit (C2) est situé tout a gauche, et
que l’état logique du capteur est à 0 lorsqu’il détecte la ligne noire et j’ai fait ainsi de suite pour chaque état
du capteur.
Ainsi selon la valeur que les capteurs captaient, l’ordre donne aux roues n’était pas la meme, prenons le cas de 124, puisque la ligne noire est tout a droite du robot, il faut mettre le moteur gauche a fond
(63) et le moteur droit à l’arret (31).
b) Tests
Après avoir fini le programme, j'ai testé celui-ci en le mettant sur le robot, il fallait tout d'abord
compiler le .fcf en un fichier .hex, puis ensuite utiliser MPLAB IDE pour transferer le programme sur le robot. Après plusieurs tests sans les obstacles, je me rend compte que mon robot ne suit pas très bien la
ligne, je me suis tout d'abord dit que je devais plutôt utiliser des vitesses intermédiaires au lieu de n'utiliser
que 31 et 63, ainsi j'ai rajoute plusieurs vitesses intermédiaires selon ce que captaient les capteurs, après
d'autres test le robot suivait mieux la ligne car il avait plus le temps de capter la ligne, mais ce n’était pas
encore assez car il prenait les virages trop largement et il prenait du temps avant de se remettre droit ; j’ai
donc pensé que le robot ne corrigeait pas assez sa trajectoire, il a donc fallut rajouter les états des capteurs
2 à 2 c'est-à-dire non seulement avoir  et  mais aussi , ainsi de
suite… je donnais au robot plus d’actions à faire. Grace à cela le robot suivait bien la ligne.
Il fallait aussi que le robot marche avec les obstacles, le robot parvenait bien a parcourir le circuit
avec les obstacles cependant des fois il trainait en haut du toboggan car les roues patinaient, il fallait donc
nettoyer les roues et la piste nous-mêmes pour que le robot patine le moins possible.
Après cela le robot parcourait donc la piste en suivant bien la ligne et en passant tous les obstacles.
Il fallait juste tester de nouvelles valeurs de vitesses afin de trouver l’accord parfait entre le suivi de la ligne
et la vitesse, le tableau ci-dessous représente les valeurs finales retenues, c’est un tableau récapitulatif des
vitesses, des positions :
Page 2
PPE | 2009

c) départ & arrêt du robot
Il fallait maintenant que le robot démarre complètement derrière la ligne conformément au règlement. Pour cela il suffisait de positionner le robot derrière la ligne à une distance X du début du premier
virage et le faire avancer a une vitesse Y pendant Z temps sans prendre en compte l’état des capteurs. J’ai
choisi de mettre 55 (0,75m/s) pendant 350ms, grâce à la relation
, nous avons donc
X = 26 cm, Y = 0,75 m/s, Z = 350 ms.
Il fallait aussi que le robot passe complètement la ligne d’arrivée puis qu’il s’arrête, pour cela j’ai, au
début pensé a faire un système d’incrémentation où dès qu’il détecte 2 fois la ligne noire (ligne de départ
et d’arrivée), le robot s’arrête, mais ceci n’a pas marché car le robot détectait une infinité de fois la ligne
noire dès la ligne d’arrivée. J’ai aussi pensé à calculer le temps moyen que prenait le robot pour parcourir la
totalité du parcours, cependant je n’ai pas retenu cette solution car non seulement elle n’est pas très précise mais de plus nous n’avons pas le niveau de connaissance suffisant au niveau de FLOWCODE pour pouvoir réaliser ceci.
Grace au départ vu ci-dessus le robot capte la ligne de départ mais fait comme si il n’avait rien capté donc
elle ne compte pas, grâce à cela j’ai pensé à un nouveau programme d’arrêt ou dès que le robot détectait
une ligne noire, il continue d’avancer à 60 (0,93m/s) pendant 100 ms (pour traverser complètement la
ligne d’arrivée) puis qu’il s’arrête. Ainsi le robot en descendant du pont basculant capte la ligne noire, continue d’avancer à une vitesse de 0,93 m/s sur 9,3 cm, ce qui est sensé ne pas être suffisant mais comme il
descend du pont basculant sa vitesse est en faite plus grande, de ce fait le robot peut complètement traverser la ligne noire d’arrivée.
2) Robot final
Tout d’abord, nous passons de 6 capteurs à 4 capteurs, car j’ai jugé que l’utilisation de 6 capteurs
était trop, de plus comme notre robot est beaucoup moins large que le robot prototype il peut se per-
Page 3
PPE | 2009
mettre de zigzaguer un peu sans pour autant bousculer les chicanes, c’est donc la solution qui est à mon
avis la plus adaptée. J’ai aussi repensé au problème que posait la forme rectangulaire du robot, à cause de
cela le robot se cognait sur les pont basculant et le toboggan ainsi des fois il restait coincé, j’ai donc demandé à William, chargé de la maquette numérique, de opter pour un chassis avec une forme triangle sur
l’avant.
Au niveau programmation la méthode n’est pas du tout la même, pour le prototype nous mettions
une valeur sur les 2 moteurs afin de varier la vitesse, pour nôtre robot la méthode pour varier la vitesse
sera différente :
Nous avons 2 moteurs à courant continu, avec une tension à signal carré et 2 transistors : si nous
n’alimentons plus les moteurs, ils continuent quand même à tourner du moment que les moteurs restent
non alimentés (transistors bloqués) dans un laps de temps suffisamment court, avec une vitesse de rotation
constante. Donc en modifiant le rapport cyclique nous pouvons faire varier la tension moyenne appliquée
aux moteurs, et faire varier la vitesse de rotation en conséquence.
De cette manière j’ai créé un nouveau tableau des valeurs :
CONCLUSION
En conclusión, le PPE a su me faire travailler en groupe, tel un ingénieur au sein d’une
équipe. Ce projet m’a fait utiliser le cours de manière concrète, ce qu’on à fait en classe n’est plus
de la théorie mais de la pratique pour moi, ce projet m’a aussi permit d’apprendre de nouvelles
méthodes de travail et de recherches, ce qui m’aidera surement pour la carrière d’ingénieur que je
souhaite embrasser. Je suis fier de mon boulot acharné, et j’espère aussi que vous apprécierez.
Page 4