ecole Nationale Supérieure

de Techniques Avancées

Semaine Système

Rapport de réalisation

Auteurs
Alexandre DOLLE
Benjamin DIEU
Eliott DUPONT
Fanny DUFRESNE
Encadreur :
Hatem DHOUIB
Mr.Alexander Gepperth
Jérémy DUVERGE
Jimmy DORR
Maxime DUCHET
Philomène
DESJONQUERES
Rapport de réalisation Groupe 5

Table des matières

1 Introduction 3

2 Stratégie 4
2.1 Exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Notre stratégie de combat . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Le Grafcet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Architecture 6
3.1 Détecteur de lignes blanches . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Boucliers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Les actionneurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Boı̂tier Central Adaptator CM-5 . . . . . . . . . . . . . . . . . . . . . . . . 7

4 Management du projet 9
4.1 Lundi après-midi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Mardi matin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3 Mardi après-midi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4 Mercredi matin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5 Mercredi après-midi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.6 Jeudi matin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.7 Jeudi après-midi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.8 Vendredi matin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.9 Vendredi après-midi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5 Réalisation 11
5.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2 Détection des lignes blanches . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.1 Capteur de luminosité . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.2 Capteur infrarouge . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.3 Tests sur l’arène . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3 Programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3.1 Stratégie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3.2 Ajout de la musique . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6 Conclusion 16

7 Annexe 17
7.1 Photo de la première version de notre robot . . . . . . . . . . . . . . . . . 17
7.2 Photo du robot final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3 Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1
Rapport de réalisation Groupe 5

Table des figures

1 Les exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Le Grafcet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 le capteur AX-S1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 L’actionneur utilisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5 Boı̂tier Central Adaptator CM-5 . . . . . . . . . . . . . . . . . . . . . . . . 8
6 La boucle contenant toutes les phases . . . . . . . . . . . . . . . . . . . . . 13
7 La fonction de virage à gauche . . . . . . . . . . . . . . . . . . . . . . . . . 13
8 Photo du robot final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9 La fonction d’avancement . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10 L’ajout de la musique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11 Photo de la première version de notre robot . . . . . . . . . . . . . . . . . 17
12 Photo du robot final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13 Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
*

2
Rapport de réalisation Groupe 5

1 Introduction
Dans le cadre de la semaine système, nous avons du mettre en place une démarche
d’ingénierie système. Le projet avait pour but de créer un robot qui puisse expulser un
autre robot du dohyō ou bien de lui résister. Afin de parvenir à cette fin, certaines exigences
(détaillées dans la partie Stratégie) nécessitaient d’être respectées. La réalisation du
projet fut alors conduite en deux étapes : la construction du robot et la rédaction d’un
rapport d’étape présentant notre approche du problème.
Suite à notre considération des exigences, nous avons immédiatement réparti le travail
entre les membres de l’équipe. La mise en place de l’équipe et notre organisation sont
détaillées dans le rapport d’étape. Afin de bien répondre aux exigences, nous avons du
modifier l’architecture du robot, celle-ci sera donc détaillée dans la partie Architecture.
Nous verrons aussi comment nous avons su adapter nos souhaits et exigences au matériel
que nous avions à disposition.
Dans ce rapport, nous présenterons donc le travail effectué ainsi que le rendu final, nous
discuterons des difficultés rencontrées et des manières dont nous les avons contournées,
et en particulier nous nous attarderons sur les différences entre le robot présenté dans le
rapport d’étape et le robot final. Nous discuterons aussi des performances de notre robot
lors de la compétition.

3
Rapport de réalisation Groupe 5

2 Stratégie

2.1 Exigences

Figure 1 – Les exigences

2.2 Notre stratégie de combat

Nous avons baptisé notre robot Philo 2.0 afin d’instaurer un climat de frayeur chez
notre adversaire dès le début du combat, lui faisant ainsi commettre une première erreur
sur la position initiale de son robot.
Notre stratégie de combat est la suivante :
→ Phase 1 : Attente de 3 secondes
→ Phase 2 : Fuite immédiate vers l’angle situé à la droite de Philo 2.0, afin d’éviter
l’éventuelle charge d’un robot d’attaque.
→ Phase 3 : Si détection d’une bande blanche, virage à angle droit vers l’intérieur du
dohyo. Si détection frontale de l’adversaire, virage à angle droit vers la gauche.
Caractéristiques duales de notre robot :

— fuite : déplacement à vitesse maximale tout le temps, de sorte à fuir le robot

adverse aussi vite que possible
— défense : à la suite de combats d’essai, nous avons constaté une faiblesse de
notre robot au niveau des roues, qui pouvaient facilement être bloquées. Afin de se
préserver des attaques ennemies, par des pinces ou des béliers, nous avons ajouté
des protections latérales afin de protéger les roues et d’éviter une prise latérale,
ainsi que des  garde-boues  sur les roues arrières afin de les protéger également.
Les matchs tests qui s’en sont suivis ont été plutôt concluant, nous confortant dans
ce choix.

4
Rapport de réalisation Groupe 5

Comment gagner ?
Philo 2.0 adopte une tactique de fuite pendant tout le combat. Elle cherche à gagner au
poids au bout des 2 minutes, ou attendre que le robot adverse sorte de lui même du dohyo
par une erreur de programmation.

2.3 Le Grafcet

Notre stratégie de fuite nous a conduit à élaborer le grafcet suivant. Nous partons
sur une phase d’initialisation qui permet de patienter les 3 secondes entre le top départ et
la mise en route du robot. Cette phase nous permet également de bien positionner notre
robot le long le la ligne délimitant le dohyo, car le robot doit être initialement orienté
selon la diagonale du dohyo.
La phase suivante est une boucle infinie. Dans l’état ”normal”, le robot ne détecte ni la
ligne ni le robot adverse, on lui demande alors de suivre une trajectoire rectiligne. Cet
état ne peut être perturbé que par deux phénomènes : la détection du robot ennemi ou
celle de la ligne délimitant le dohyo.
Dans les deux cas, nous demandons à notre robot de faire une rotation de 90◦ sur la
gauche, de jouer une musique de fuite dans le cas où le robot adverse a été détecté, puis
de reprendre son état ”normal” dans lequel il doit se contenter d’avancer tout droit.

Figure 2 – Le Grafcet

5
Rapport de réalisation Groupe 5

3 Architecture
La version finale de notre robot comporte pas mal de différences par rapport à l’ar-
chitecture prévue.
On a levé le AX-S1 pour mieux détecter les bandes blanches.
On a ajouté aussi des boucliers pour protéger les roues et éviter les robots qui visent les
roues et bloquent leur fonctionnement.
Les choix étaient limités vu qu’on ne peut utiliser que les pièces du kit Bioloid.

3.1 Détecteur de lignes blanches

Pour la détection des lignes blanches nous avons utilisé le AX-S1 qui est un capteur
tout-en-un. Il dispose d’un capteur infrarouge, d’un capteur ultra-son et d’un micro. Sa
détection des distances et de la luminosité se fait dans trois directions (avant, gauche,
droite)

Figure 3 – le capteur AX-S1

3.2 Boucliers

C’est à la vue des robots adverses qui possèdaient pour la plus part d’un système de
bélier plus ou moins perfectionné.
Les roues de notre engin sont son point faible. On peut les bloquer et alors il serait facile
de nous pousser vers la bordure du ring. Nous avons donc déployé deux ailles, de part

6
Rapport de réalisation Groupe 5

et d’autre de notre bolide, afin, tout d’abord d’amortir les chocs et ensuite de limiter les
risques de blocage des roues et de retournement de la machine.
Les plaques en équerre ont été vissées au boitier contenant le CM5 à l’aide d’une autre
plaque servant de support.
La contre-partie de cette protection est une surcharge du robot qui peut le pénaliser en
cas de match ex-aequo. C’est un risque à prendre.
L’avantage de ces boucliers est donc multiple. Ils protègent le robot des chocs, préviennent
son retournement et lui confère un avantage esthétique indéniable par rapport à la struc-
ture basique de tortue à roulette que nous adoptâmes au début de la semaine.

3.3 Les actionneurs

Concernant les actionneurs, nous n’avons pas rencontré de problèmes techniques. Au

début de la conception, nous hésitions entre 3 et 4 roues. Mais très vite, notre choix
s’est porté sur l’utilisation des quatre moteurs pour les quatre roues, pour des raisons de
stabilité ainsi que pour maximiser la vitesse et la quantité de mouvement de notre robot.
Les moteurs de roues, qui transforment de l’énergie électrique en énergie mécanique afin de
faire tourner les roues, permettant le déplacement du robot, sont des actionneurs AX-12+.

Figure 4 – L’actionneur utilisé

3.4 Boı̂tier Central Adaptator CM-5

Le boı̂tier Adaptator CM-5 aura été placé au centre de notre robot, placé en longueur
dans l’axe du robot. Il constitue l’équivalent de l’habitacle de notre robot, si on le regarde

7
Rapport de réalisation Groupe 5

comme une voiture, ou de la carapace si on le voit plus comme une tortue.

Nous avons fixé les roues aux quatres coins du boitier contenant le CM-5, telles des pattes
pour permettre à notre véhicule de se mouvoir. Nous avons pris garde de les agencer de
manière à abaisser le centre de gravité du robot mais afin de garder une bonne mobilité
et un robot relativement large, nous les avons vissées sous le boı̂tier.
Ainsi sur le boı̂tier viennent se fixer les roues, la tête, constitué d’une plaque et des cap-
teurs AX-S1 ainsi que les boucliers.

Figure 5 – Boı̂tier Central Adaptator CM-5

8
Rapport de réalisation Groupe 5

4 Management du projet

4.1 Lundi après-midi

Toute l’équipe prend connaissance de la boı̂te et des instructions pour la semaine.

Les pôles sont créés : un pôle programmation et un pôle conception/construction. Fanny,
Jimmy, Eliott et Jérémy s’attèleront à l’élaboration du code tandis que les autres membres
travailleront ensemble sur l’élaboration physique du robot. Hatem est nommé chef d’équipe !
Inventaire des éléments fournis.

4.2 Mardi matin

Le pôle Programmation commence à prendre connaissance du code tandis que la

conception s’allie à la réalisation dans la salle annexe. Des tests sont effectués pour évaluer
la détection des obstacles. Premiers pas de notre robot.

4.3 Mardi après-midi

Début de la rédaction du rapport. La construction touche à sa fin, après de longues

recherches quant à la fabrication du pare-buffle. On apprend que la plupart des robots
des années précédentes sortent seuls de la zone de jeu. De ce fait les premiers tests de
détection de la bande blanche sont effectués par les programmeurs. Le robot est enfant !

4.4 Mercredi matin

Le rapport progresse. Les programmeurs se heurtent à une difficulté : le capteur ne

détecte aucunement la bande blanche, on décide donc de changer notre stratégie et de
programmer directement une trajectoire qui nous permettrait de fuir devant l’adversaire
tout en restant dans les lignes supposées du terrain.

4.5 Mercredi après-midi

Finalisation du rapport d’étape. Programmation de la trajectoire. Nous faisons face à

un revirement de situation des plus heureux ! Notre capteur ne détectait pas notre bande
blanche parce qu’il était trop près du sol, on décide donc de le rehausser ! Notre robot
fait désormais de la musique, ses LED clignotent et il parcourt avec fougue les salles
d’informatique. C’est une adolescence heureuse que traverse notre petit robot !

9
Rapport de réalisation Groupe 5

4.6 Jeudi matin

Fin de la programmation. Commencement de la rédaction de ce rapport. On effectue

les derniers tests de détection des bandes blanches directement sur l’arène. Le robot ne
détecte toujours pas les bandes blanches de l’arène, les programmeurs décident d’abaisser
le niveau d’IR pour le rendre plus sensible. C’est adulte, que notre robot parcourt fièrement
l’arène, applaudi par les programmeurs en folie !

4.7 Jeudi après-midi

On s’engage dans un combat contre une autre équipe. De deux choses, l’une : notre
robot s’est fait expulser du terrain. Mais en plus de ça, il est trop vulnérable sur les flancs.
On décide donc d’ajouter des pièces latérales afin de protéger les roues et d’offrir moins
de prises à l’adversaire.

4.8 Vendredi matin

Dernières vérifications, cette fois-ci, on essaye sur le terrain de jeu final. Malheur ! La
luminosité est mauvaise dans l’amphithéâtre, les programmeurs décident une ultime fois
de modifier le seuil d’IR.

4.9 Vendredi après-midi

A l’attaque !

10
Rapport de réalisation Groupe 5

5 Réalisation

5.1 Construction

La construction a débuté en essayant de coller au plus près de notre conception.

Cependant nous avons dû faire face à des difficultés liées à la forme prédéfinie des pièces,
à la malformation de quelques unes d’entre elles (les écrous ne rentraient pas dans tous
les trous prévus à cet effet), à la quantité des éléments fournis, mais aussi à la petitesse
des vis et écrous qui faisait de la construction tout un art !
Mais grâce à une dévotion et une imagination sans limites, la boı̂te ne nous a pas résisté
bien longtemps !

5.2 Détection des lignes blanches

Détecter les bandes blanches à coup sûr a été pour nous une priorité. En effet, notre
stratégie est une stratégie de fuite : pour gagner, notre robot doit rester dans l’arène le
plus longtemps possible, en attendant que l’adversaire en sorte de lui-même.

5.2.1 Capteur de luminosité

Nous avons tout d’abord essayé de détecter les lignes blanches grâce au capteur de
luminosité, ce qui s’est avéré être un échec. Aucun des capteurs ne détectait de la lumière,
sauf en mettant un flash de portable à 1 cm au maximum du capteur. Les bandes blanches
n’émettant pas de lumière, nous avons décidé d’utiliser le capteur infrarouge pour détecter
les bandes blanches.

5.2.2 Capteur infrarouge

Le capteur infrarouge étant déjà utilisé comme détecteur d’obstacles, nous avons
mis un peu de temps avant de penser à l’utiliser pour la détection des bandes blanches.
Nous avons également eu du mal à mettre en place cette méthode de détection. En effet,
nous avons commencé par le tester au-dessus du bois de la table de bureau des salles
informatique. Or, ce bois renvoie presque aussi bien la lumière que le scotch blanc. Le
capteur infrarouge apparaissait alors tout le temps saturé, ce qui n’allait pas en faveur
d’une détection des bandes blanches. Après un peu de réflexion nous nous sommes apperçu
de notre erreur et avons décidé de faire les tests au-dessus d’une surface noire. Cela a
permis des variations un tout petit peu plus marquées, mais toujours peu concluantes.
C’est alors que nous nous sommes aperçus qu’il fallait bien régler la hauteur du capteur

11
Rapport de réalisation Groupe 5

pour obtenir un contraste maximal dans les valeurs renvoyées. Quelques modifications
de la structure du robot on permis d’ajuster la hauteur du capteur pour un contraste
infrarouge satisfaisant.

5.2.3 Tests sur l’arène

Au sol dans la salle informatique, notre scotch blanc, déplacé à la main, était infailli-
blement détecté. Nous avions mis un seuil à 250. Pourtant, jeudi matin, au moment des
tests sur l’arène, les bandes blanches du côté n’étaient pas détectées, même en allumant
toutes les lumières. Nous nous sommes alors rendus compte que pour éviter que notre
scotch ne colle partout nous l’avions collé sur un papier blanc, tandis que les scotch de
l’arène étant collé sur de la moquette noire, le détecteur infrarouge est moins efficace.
De plus, les lumières venant du plafond et non de fenêtres horizontales comme en salle
informatique, le robot fait de l’ombre sur le scotch au moment où il passe dessus, ce qui
ne facilite pas la détection. Après plusieurs allers-retours, nous avons décidé d’abaisser le
seuil de détection à 150, seuil suffisamment faible pour détecter les bandes blanches à coup
sûr, et suffisamment élevé pour ne pas confondre la moquette avec une bande blanche.

5.3 Programmation

5.3.1 Stratégie

Afin de traduire notre stratégie plutôt défensive nous avons utilisé un capteur fron-
tal et un autre dirigé vers le sol. Le capteur frontal permet de détecter l’ennemi et de
fuir, puis l’autre permet de détecter les bandes blanches dans le but de ne pas sortir du
terrain. Pour détecter la bande blanche nous avons utilisé la fonction centerInfrared qui
nous donnait la valeur mesurée par le capteur infrarouge. Nous avons imposé nous même
un seuil de détection de la bande blanche. Par ailleurs pour la détection d’obstacles nous
avons utilisé la fonction CheckObstacle qui était déjà définie avec un seuil. Cette fonction
renvoie la présence ou non d’un obstacle devant les capteurs.
Ainsi dans la programmation, nous avons créé une boucle infinie dans laquelle nous mesu-
rons les valeurs du capteur infrarouge à tout moment afin de s’adapter à la situation. En
cas de dépassement d’un certain seuil, que nous avions déterminé au préalable, le robot
rentre dans une phase de  fuite . Dans cette phase, le programme fait appel à une
fonction qui permet au robot de tourner sur lui-même. Afin de tourner sur lui même nous
avons imposé des vitesses de sens opposées aux roues de droites par rapport aux roues de
gauches à l’aide de la fonction setSpeed.
Par ailleurs le capteur frontal utilise la fonction CheckObstacle, et nous avons modifié le
seuil de détection afin d’avoir une meilleur portée de détection de l’ennemi.

12
Rapport de réalisation Groupe 5

Voici un extrait du code que nous avons utilisé, on peut y voir la boucle infinie avec les
différentes phases :

Figure 6 – La boucle contenant toutes les phases

Voici la fonction qui nous permet de faire une rotation vers la gauche :

Figure 7 – La fonction de virage à gauche

On peut voir qu’on a remplacé des délais par des notes de musique à l’aide de la fonction
buzzWtihDelay. Ceci sera expliqué dans la partie progrommation de la musique.

Nous avons aussi créé une fonction spécifique au démarrage du robot pour le début du
combat qui nous permet de mettre dans une position favorable à la fuite. Voici la fonction :

13
Rapport de réalisation Groupe 5

Figure 8 – Photo du robot final

Pour finir nous avons utilisé une fonction qui permet de faire avancer le robot :

Figure 9 – La fonction d’avancement

Petit problème lors du combat :

Le capteur d’obstacles nous permettait de détecter notre ennemi d’assez loin, et lors du
combat les spectateurs étaient très proches du  dohyo . Ainsi notre robot détectait les
jambes de ces derniers et ne pouvait donc pas effectuer la stratégie que nous avions prédit.

5.3.2 Ajout de la musique

En constatant la présence d’un buzzer, nous avons essayé de générer des sons. Trou-
vant dans le manuel un tableau nous donnant la correspondance entre les notes et des
arguments à donner à la fonction appropriée, nous avons donc décidé de trouver un moyen
d’intégrer la génération de musique dans le code.
Cependant il est impossible d’exécuter d’autre ligne de code pendant l’émission d’un son,
c’est pourquoi nous avons décidé de remplacer toutes nos temporisations par des séries
de notes. Il suffit d’adapter la durée d’une mesure, le nombre de notes et de combler le
temps restant avec une temporisation.
Ainsi lors du début du combat, le robot joue the ”Imperial March” from Star Wars et
lorsque qu’il effectue une rotation dans le but de rester dans le dohyo, les premières notes
du thème de Mario Bros retentissent. Enfin lorsque le robot tourne afin d’esquiver un

14
Rapport de réalisation Groupe 5

adversaire, il émet une alternance de deux notes évoquant une alarme.

Cet ajout est avant tout ludique mais il nous a tout de même permis d’acquérir la maitrise
de la fonction de génération de son et de nous interroger sur le fonctionnement de notre
code.
ceci remplace par exemple un temporisation de 2,1s en jouant la musique de mario bros :

Figure 10 – L’ajout de la musique

15
Rapport de réalisation Groupe 5

6 Conclusion
Nous sommes finalement parvenu à respecter les exigences du cahier des charges
avec le matériel fourni. Cependant, malgré le bon fonctionnement de notre robot, notre
stratégie ne nous a pas réussi car notre robot perdit toutes ses rencontres. La plupart du
temps, le robot arrivait à fuir l’adversaire durant une bonne partie de la rencontre mais la
taille du robot a fait qu’au moment où le robot se trouvait proche des bandes et subissait
une déviation de la part de l’adversaire, le robot ne pouvait pas se sortir de sa situation
et se retrouvait alors légèrement hors du terrain. A l’exception d’un combat, le robot a
toujours fonctionné selon nos souhaits. Seule la stratégie d’un robot de fuite ”résistant”
fut la raison de notre défaite. Ceci nous a amené à remettre en cause la stratégie d’un
robot polyvalent.
Durant ce projet, nous avons eu la possibilité de réaliser un projet concret, l’opportunité
de travailler en équipe et ainsi d’obtenir un aperçu du métier d’ingénieur. Bien que le
projet ne fut pas d’une complexité débordante, nous avons pourtant du nous organiser et
apprendre à travailler en équipe. C’est ainsi que nous avons abouti à la formation de deux
groupes : l’un chargé d’établir l’architecture du robot, l’autre de réaliser la programmation
des stratégies du robot. Les deux équipes étaient constamment en contact ce qui a permis à
chaque groupe de s’adapter aux idées et aux problèmes qu’encontraient les membres. Cette
communication a fait naı̂tre une cohésion au sein de l’équipe, qui fut très certainement
bénéfique à la bonne marche de ce projet.
La communication et l’organisation au sein de l’équipe furent les deux piliers nécessaires
à la réalisation du robot. Cette démarche, suivie tout au long de la semaine, constitue le
noyau de l’ingénierie système.

16
Rapport de réalisation Groupe 5

7 Annexe

7.1 Photo de la première version de notre robot

Figure 11 – Photo de la première version de notre robot

17
Rapport de réalisation Groupe 5

7.2 Photo du robot final

Figure 12 – Photo du robot final

18
Rapport de réalisation Groupe 5

7.3 Nomenclature

Figure 13 – Nomenclature

19