Rapport final

Groupe 1176
Afsar Aris
Arnould Julien
Berrada Yassine
Bian Yu Borges de Almeida Ivo Rui
Bondroit Jérôme
Delacroix Arnold
Gier David
Mortier Denis
Rapport de projet
Le projet expliqué à travers ce rapport est la consécration de mois de travail sur un robot
chargé de jouer au basket de façon autonome. L’historique du développement du “Michael
Mouse" depuis les premières semaines d’apprentissage jusqu’au concours en passant par
la construction de la maquette et l’écriture du code y sera détaillé avec soin. Notre
solution, que nous avons imaginée durant ces trois derniers mois, est caractérisée par
l’efficacité de ses compétences. Tout cela dans le but d’aboutir à une solution mesurée et
compétitive. Le groupe 1176 est fier et honoré de vous présenter le fruit de son travail, le
“Michael Mouse" qui, nous l’espérons, vous plaira autant que nous. Avec lui, plus de
stress. Complètement autonome, il vous fera gagner tous vos paris de match de
robot-basket !
Année académique 2012 - 2013
Professeur : Raucent Benoît 5 décembre 2012
Tuteur : Bollen Xavier FSAB 1501 - Projet

Groupe 1176 Décembre 2012
Table des matières
1 Introduction 3
2 L’engin final 4
2.1 Dimensionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Dessin 2D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Fiche technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Comparaison des trois engins . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 L’engin final 10
4 Aspects techniques du robot 10
4.1 Motorisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1 Courbe caractéristique d’un moteur . . . . . . . . . . . . . . . . . . 10
4.1.2 Estimation de la vitesse du prototype LEGO® . . . . . . . . . . . . 11
4.1.3 Autonomie du prototype LEGO® . . . . . . . . . . . . . . . . . . . . 15
4.2 Cinématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1 Trajectoire rectiligne . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.2 Trajectoire curviligne . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.3 Changement de trajectoire . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.4 Etude balistique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.1 Concetion de l’engin . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.2 Plan horizontal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.3 Plan incliné . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4 Informatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5 Le bilan du travail de groupe et les bilans individuels 37
5.1 Bilan individuel : Afsar Aris . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Bilan individuel : Arnould Julien . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3 Bilan individuel : Berrada Yassine . . . . . . . . . . . . . . . . . . . . . . . 39
5.4 Bilan individuel : Bian Yu Borge de Almeida Ivo Rui . . . . . . . . . . . . . 39
5.5 Bilan individuel : Bondroit Jérome . . . . . . . . . . . . . . . . . . . . . . . 40
5.6 Bilan individuel : Delacroix Harold . . . . . . . . . . . . . . . . . . . . . . . 40
5.7 Bilan individuel : Gier David . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.8 Bilan individuel : Mortier Denis . . . . . . . . . . . . . . . . . . . . . . . . . 42
6 Conclusion 42
Bibliographie 44
7 Annexes 45
7.1 Cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.1.1 Choix des fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.2 Fiche technique de l’engin réel . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.3 Descpription de la solution présentée durant l’avant-projet . . . . . . . . . . 52
7.4 Programme Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.5 Évaluation du travail de groupe . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.5.1 Bilan S6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
FSAB 1501 - Projet 1 Rapport final

7.5.2 Bilan S12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.6 Pourquoi travailler en groupe ? . . . . . . . . . . . . . . . . . . . . . . . . . 98
7.7 Grilles des inducateurs du groupe . . . . . . . . . . . . . . . . . . . . . . . . 99
7.8 Estimation du prix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.9 Règlement du concours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.10 Spécification technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

1 Introduction
Suite au succès rencontré par les jeux paralympiques de Londres, le CIP (Comité
international paralympique) a envisagé d’introduire une nouvelle discipline pour des pa-
raplégiques profonds : le robot-basket. C’est dans ce but que le CIP nous a mandatés afin
de concevoir et créer un robot capable de jouer au basket. Ceci comprend le fait que le
robot soit capable de se repérer dans l’espace, de détecter son adversaire et la balle, de se
mouvoir aisément, d’attraper et de lancer la balle... En somme, tout ce qui est nécessaire
au robot pour qu’il puisse jouer au basket de façon autonome.
Plus précisément, notre robot final, que nous avons nommé “Michael Mouse", exécu-
tera les taches suivantes, qui nous sont imposées par le client dans le CDC (cahier des
charges). Tout d’abord, il se repérera sur le terrain. Ensuite, il détectera son adversaire
ainsi que la balle. Une fois la balle localisée, il se placera au-devant afin de la saisir et
de tenter de l’envoyer dans le panier. Durant les déplacements, la balle sera située sur un
balcon à l’arrière du robot. Cela laissera la chance à l’équipe adversaire de récupérer la
balle en la faisant tomber au moyen d’un choc, ce qui constituera un jeu plus attractif.
Au moment du tir, la balle étant toujours située sur le balcon, un mécanisme permettra
de rabattre entièrement le balcon afin que la balle puisse retourner à l’intérieur du robot.
Puis, suite à une aspiration, la balle sera amenée au canon pour qu’elle puisse être pro-
pulsée, on l’espère, jusqu’au panier.
Le travail a bien évidemment été réalisé en plusieurs étapes. Tout d’abord nous avons
établi un cahier de charges qui reprend les fonctionnalités, les performances et les contraintes
auxquelles nous devions faire face. Ce cahier est en quelque sorte le lien entre le client et
le concepteur, à savoir nous. Une fois les objectifs définis, chaque membre de l’équipe s’est
mis à réfléchir à la solution qui lui semblait être la plus efficace et ce, pour chacune des
fonctionnalités du robot. Ensuite, chacun exposait ses idées trouvées, puis nous procédions
à une mise en commun afin de retenir la meilleure solution. Après avoir évalué le robot
le plus adapté possible, nous l’avons modélisé sous forme d’une maquette afin de se faire
une meilleure représentation du robot.
En semaine 9, nous avons été lancés sur la conception d’un prototype en LEGO afin
de confronter notre solution à la réalité. Ce prototype avait pour objectif d’approfondir
nos connaissances en informatique et en physique et de mettre en pratique ce que nous
avons imaginé pour notre robot durant les 9 premières semaines. Toutes ces étapes nous
ont permis de passer d’une simple idée à une solution finale optimisée.
Nous avons donc rédigé ce rapport afin que vous puissiez juger le travail que nous
avons fourni durant ces 12 semaines pour la conception et la création d’un robot-basket.
Tout d’abord nous commencerons par vous décrire notre solution finale dans les moindres
détails. Vous trouverez ensuite les aspects techniques du robot, à savoir : la motorisation,
la cinématique, la statique et l’informatique. Après la partie technique, il y aura un large
bilan sur le travail de groupe et l’apport individuel de chacun des membres. Nous termi-
nerons par une conclusion suivie de la bibliographie et des annexes.

2 L’engin final
2.1 Dimensionnement
Type et quantité de batteries :
Avant de calculer le nombre et le type des batteries requises, il est de mise de déter-
miner quel moteur sera utilisé. Suite aux calculs pour le rapport de réduction, il était de
mise de trouver un moteur permettant de satisfaire certains critères, notamment la vitesse
de sortie du moteur et le couple du moteur. Nous avons donc choisi le moteur Siemens
1FT6021-6AK7 250W, 24V, 6.000 tours par minute et un couple de 400 mNm. Un moteur
de 250W veut dire 250J utilisées par seconde. Le CDC stipule une autonomie de 15 mi-
nutes, donc la batterie devra être capable de tenir durant 900 secondes, c’est-à-dire fournir
225.000 Joules ou 62.5Wh par moteur (en supposant que le moteur tourne toujours à fond,
situation extrême). De plus le moteur Siemens 1FT6021-6AK7 demande une batterie de
24V. D’après ces données il faut trouver une batterie permettant une marge dans l’auto-
nomie et capable de fournir le voltage requis et une énergie supérieure à celle demandée
par les 3 moteurs étant donné qu’il y a aussi les capteurs et la turbine qui demandent de
l’énergie. Sur le site iCampus de l’UCL la batterie qui correspond le mieux à la situation
serait la VARTA A23 utilisé deux fois pour être mise en série avec elle-même pour avoir
24V qui procurerait 960Wh. Grâce à cette solution, le nombre serait limité à deux batteries
de faible volume par rapport aux autres proposées et il n’y aurait pas de dépenses inutiles
pour des batteries plus puissantes, tout en dépassant largement l’autonomie stipulée dans
le CDC.
Rapport de réduction :
Étant donné que le match se joue sur un terrain de basket, il est supposé que le terrain
est plat et que par conséquent il n’y a pas de pente.
– Calcul du couple de la roue :
Force de frottements équivalente :
305 kg · 0.4N/kg = 122 N
Couple de la roue roue :
Force totale · Rayon de la roue
2
= 4.575 Nm 1
– Calcul du rapport de réduction :
En se basant sur le site officiel du fabricant du moteur Siemens 1FT6021-6AK7 : le
couple du moteur vaut 0.4Nm. En partant de là, le calcul est très simple.
Rapport de réduction =
Croue
Cmoteur
= 11.4375
1. Le couple est divisé par deux car il s’agit d’un couple pour une seule roue

Calcul de la vitesse nominale :
Pour calculer la vitesse nominale, c’est assez simple. Grâce au rapport de réduction
(11.4375) et à la vitesse maximale de sortie du moteur (6000trs/min) il est assez simple
de déterminer la vitesse angulaire de la roue et par là la vitesse linéaire nominale du robot
(en supposant qu’il n’y a pas de glissement, c’est-à-dire que les roues ne patinent pas).
Vitesse angulaire de la roue :
6000 trs/min
60 sec
·
1
11.4375
= 8.743 trs/sec
Vitesse linéaire nominale de la roue :
v =
ω
2π
· 2π · r = 8.743 · 0.075 · 2π = 4.12 [m · s−1
]
Évaluation de la masse du robot final :
Pour l’évaluation de la masse du robot, il faut tenir compte du dimensionnement du
robot et des matériaux utilisés. Ci-dessous sont les calculs pour trouver la masse du robot.
Pour commencer, il faut calculer les différentes masses par matériau.
– Volume total d’acier : (masse volumique : 7.800kg/m3)
Plaque du bas : 100cm x 120cm x 1cm = 12.000cm3
Plaque du haut – Trou pour le canon : (100cm x 120cm x 0.5cm)-(25cm x 25cm x 0.5cm)
= 5.687,5cm3
Ramassette : 25cm x 30cm x 0.5cm = 375cm3
Armatures (4x) : 80cm x 2cm x 2cm = 1.280cm3
Toit avant (1.5x) : 35cm x 30cm x 2cm = 3.150cm3
Total : 22.492,5 cm3 = 175,4415 kg
– Volume total de polyméthacrylate de méthyle (plexiglas) : (masse volumique : 1185kg/m3)
Parois latérales (2x) : 80cm x 120cm x 1cm = 9.600cm3
Paroi arrière – balcon : (80cm x 100cm x 1cm) – (25cm x 41cm x 1cm) – (8cm x 25cm x
1cm) = 6.775cm3
Paroi avant – ouverture couloir : (100cm x 80cm x 1) – (48cm x 25cm x 1cm) = 6.800cm3
Balcon : 25cm x 25cm x 1cm = 625cm3
Trappes (2x) : 25cm x 25cm x 1cm = 625cm3
Contours couloir intérieur (3x) : 95cm x 25cm x 1cm = 2.375cm3
Contours cheminée (3x) : 55cm x 25cm x 1cm = 1.375cm3
Canon : ((26cm)2-(25cm)2) x π x 80cm = 12.817,698cm3
Total : 40992,698cm3 = 48,57634713 kg
– Batteries : (masse volumique 2.5kg/dm3)
2 batteries de 211mm x 175mm x 190mm = 14.0315dm3 = 35,07875kg
– 2 moteurs de 1.2kg

– Turbine + compresseur = 42 kg
Masse totale de l’engin = 304.7 kg

2.2 Dessin 2D

2.3 Fiche technique
Voir annexe 7.2.
2.4 Comparaison des trois engins
Critère Avant-projet Prototype LEGO Engin final
Forme cubique classique, relati-
vement compact
parallélépidède
Nombre de mo-
teurs
2 pour les roues,
un pour l’ascen-
seur, un pour les
portes et 3 pour le
canon
2 pour les roues et
1 pour la pince
2 pour les roues,
1 pour le canon et
une turbine
Nombre de roues 2 motrices 1 folle 2 motrices 2 motrices 1 folle
Saisie Rampe d’accès au
couloir
Pince de type
“Forklift"
Rampe d’accès
au couloir avec
brosses sur le côté
Détection 3 bornes aux
bords du terrain
permettant une
triangularisation
Ultrason et cap-
teur de lumière
3 bornes aux
bords du terrain
permettant une
triangularisation
Autonomie 100% autonome 100% autonome 100% autonome
Nous avons forcément été limités par les contraintes du modèle LEGO, ce qui explique
le changement de certains critères, mais la réalisation expérimentale à ses avantages : elle
nous a montré diverses failles de certains critères déterminés lors de l’avant-projet qui nous
ont permis une optimisation de l’engin final.

3 L’engin final
4 Aspects techniques du robot
4.1 Motorisation
4.1.1 Courbe caractéristique d’un moteur
En S5, il a été demandé de réaliser une courbe caractéristique (couple-vitesse angulaire)
expérimentalement. Pour ce faire, un moteur électrique a été posé sur une table de hauteur
d’un mètre qui suspendait une masse le long d’un fil.
Lors de l’expérience, l’intensité, la masse et le voltage ont été varié à plusieurs reprises,
pour avoir les courbes que voici avec les données nécessaires :

Une des choses qu’il faut retenir est que chaque moteur détient sa propre courbe
caractéristique.
4.1.2 Estimation de la vitesse du prototype LEGO®
Tout d’abord, voici une liste des différentes pertes possible de rendements liées à dif-
férents frottements :
– Frottements internes au moteur
– Frottements des pneus sur le sol
– Frottements de l’air (peut être négligés du à la vitesse faible, n’interviendra donc
pas dans les calculs)
– Frottements de transmission
Voici ce qui est utilisé :
Putile = Puissance utile
Pabsorbée = puissance absorbée
Pméca = puissance mécanique qui sort du moteur
Pélec = puissance électrique
ηélec = rendement électrique
ηméca = rendement mécanique
ηtotal = rendement total
Une formule générale du rendement s’écrit sous la forme :
η =
Putile
Pabsorbée

Le rendement est toujours inférieur ou égal à 1.
Calcul du rendement total :
ηtotal = ηméca · ηélec
ηélec =
Pméca
Pélec
=
Cmoteur · ωmoteur
V · I
ηméca =
Putile
Pméca
=
Croue · ωroue
Cmoteur · ωmoteur

⇒ ηtotal =
Croue · ωroue
V · I
(4.1)
4.1.2.1 Frottement équivalent
Tout d’abord, le frottement équivalent est la somme de tout les frottements présent
sur le prototype LEGO, de manière à contrer la force et avancer à vitesse constante.
Il faut commencer par peser le prototype de manière à avoir son poids :
Masse du robot = 0.813kg
Poids du robot = 0.813 · 9.81 = 7.98N
Ensuite, il faut trouver expérimentalement l’angle d’inclinaison de la pente à partir
duquel le prototype se met à rouler, initialement au repos. Pour trouver cet angle dit
critique, le prototype a été placé sur un sol incliné pour ensuite mesurer l’angle à partir
duquel il s’est mit en mouvement.
Voici un schéma de l’expérience :
Figure 4.1 – Frottement équivalent
Ici,
αcritique = 9◦
En décomposant les forces selon l’axe des ê2 :
X
Fê2 = −Wk + Ffr. éq. = 0
Ffr. éq. = Wk = m · g · sin α
Dans le cas du prototype LEGO :
Ffr. éq. = 0.813 · 9.81 sin(9◦
) = 1.248 [N]
4.1.2.2 Vitesse
Il est maintenant possible de déterminer la vitesse linéaire de notre robot. Pour ce
faire, il faut procéder par différentes étapes. Tout d’abord, la formule de la vitesse linéaire,
en sachant que notre robot se déplace sans glissement :
v = ωroue · Rroue
Pour pouvoir arriver à cette formule, il faut calculer les différents éléments suivant :
Le couple de la roue (Croue) afin de vaincre les forces de frottements équivalents :

Croue =
Ffr. éq. · rroue
2
2
Ensuite le rapport de réduction, qui est lié au couple de la roue par rapport au couple
du moteur :
Rapport de réduction =
Croue
Cmoteur
Dans le cas présent, le rapport de réduction est de 1 car il n’y a aucun engrenage entre
le moteur et la roue (VOIR IMAGE PROTYPE LEGO).
Après avoir mesuré le rayon de la roue du prototype LEGO® qui vaut 2.75cm, il est
possible de déterminer le couple de la roue :
Croue =
0.01716 · 0.0275
2
= 0.01716 [Nm]
Figure 4.2 – Courbes couple-vitesse d’un moteur LEGO®
Grâce à la Figure 4.2, donnée dans le livret S9, il en ressort une expression analy-
tique du couple en fonction de la vitesse angulaire. Ce graphique permet de connaitre la
vitesse pour différents niveaux de commandes même si en réalité il est possible de choisir
beaucoup plus précisément la vitesse dans notre programme Java.
Comme il s’agit de droites, il est facile de les représenter sous forme de cette équation :
Croue = a · ωroue + b
Niveau de commande C(ωmoteur) ωroue [rad · s−1] v [m · s−1]
20% −0.02 · ωmoteur + 0.04 1.142 0.031
40% −0.017 · ωmoteur + 0.09 4.28 0.12
60% −0.018 · ωmoteur + 0.015 7.38 0.20
80% −0.019 · ωmoteur + 0.21 10.82 0.297
100% −0.22 · ωmoteur + 0.31 13.31 0.37
2. Le couple est divisé par deux car il s’agit d’un couple pour une seule roue

En pleine puissance, le robot a une vitesse de 0.37 [m · s−1].
4.1.3 Autonomie du prototype LEGO®
En supposant que toute l’énergie disponible dans les piles du RCX est utilisée pour
faire avancer le robot et vaincre les frottements, la distance totale que pourra parcourir le
robot se déplaçant à l’horizontal et à vitesse constante peut se calculer comme suit.
Sachant que la batterie du LEGO® est capable de délivrer un courant de 2.2 A avec
une tension de 7.4 V pendant une heure lorsque celle-ci est pleinement chargée.
Wbatterie = P · ∆t [J]
= 7.4 · 2.2 · 1 · 3600[J]
= 58608 [J]
La distance totale que pourra parcourir le robot peut se trouver grâce aux formules
(4.2) et (4.3) :
Wroue = Wbatterie · ηtotal = 58608 · 0.35 = 20512.8[J] (4.2)
Wroue = Ffr. éq. · ∆x (4.3)
La distance que va parcourir le robot est donc de :
∆x =
Wroue
Ffr. éq.
=
20512.8
1.248
= 16436.54 [m]
Et comme :
∆t =
∆x
v
=
16436.54
0.37
= 44423.08 [s]
Le robot est donc capable de parcourir une distance de 16.44 km et a une autonomie
de 12 heures et 20 minutes. Ces résultats restent bien évidemment qu’une approximation.
En effet, ici, il est considéré que toute la batterie est utilisée et ce à la même puissance
à tout moment, comme pourrait le montrer la Figure 4.3. Or la réalité est bien loin de
ça, une batterie commence par se décharger assez lentement pour ensuite avoir un temps
de décharge un peu plus constant et va finir par se décharger très rapidement, comme le
montre la Figure 4.4. Cependant, il est possible de remarquer que la batterie n’est pas
totalement déchargée, il lui restera toujours de l’énergie mais cette énergie ne sera pas
utilisable.
Il y a également d’autres critères qui entrent en jeu, comme par exemple l’ordinateur
de bord qui consomme énormément d’énergie, que ce soit en utilisant la pince, le sonar ou
le capteur lumière. Mais également les outils de mesures utilisé qui étaient peu précis.

Figure 4.3 – Décharge théorique d’une batterie
Figure 4.4 – Décharge réelle d’un batterie
4.2 Cinématique
Pour ordonner au robot d’entamer un chemin rectiligne, ou plutôt de commencer un vi-
rage, la vitesse angulaire donnée aux deux roues motrices diffère d’une situation à l’autre.
Si par exemple le robot est programmé pour commencer une trajectoire rectiligne, les
vitesses angulaires données aux deux roues doivent être les mêmes. Par contre, si le pro-
gramme veut que le robot entame un virage avec un certain rayon de courbure, les vitesses
angulaires des deux roues deviennent différentes et doivent être calculées précisément.
Voici ce qui sera utilisé lors des calculs :
– ωb Vitesse angulaire de la roue B
– ωc Vitesse angulaire de la roue C
– ωmoteur Vitesse angulaire du moteur
– ω Vitesse angulaire du robot lors d’un virage
– Vb Vitesse relative du centre de la roue B
– Vc Vitesse relative du centre de la roue C
– V Vitesse relative du centre de masse du robot
– K Rapport de réduction
– 2d Distance entre les roues
– r Rayon des roues B et C
– R Rayon de courbure du virage

4.2.1 Trajectoire rectiligne
Le robot est supposé ne pas glisser. Pour qu’il n’y ait pas de glissement, il faut que les
vitesses des deux points de contacts soient les mêmes. Pour le roulement sans glissement,
mathématiquement cela s’écrit ω=V
r
Figure 4.5 – Chemin rectiligne
ωmoteur = Kωb
= Kωc
⇒ V =
ωmoteur
K
r
4.2.2 Trajectoire curviligne
Lorsque le robot entame son virage, il est consdéré comme rigide donc l’angle balayé
par le robot au niveau de la roue B en un temps donné est égal à celui balayé par le robot
au niveau de la roue C par ce même laps de temps.
Figure 4.6 – Chemin courbé
Vb
R
=
Vc
R + 2d

De là, Vb et Vc peuvent être trouvé l’un en fonction de l’autre
Vb = Vc
R
R + 2d
Vc = Vb
R + 2d
R
Tout comme ωb et ωc
ωb = Vc
R
r(R + 2d)
= ωc
R
R + 2d
ωc = Vb
R + 2d
Rr
= ωb
R + 2d
R
Les équations disent formellement que la roue intérieure au virage a une vitesse relative
et une vitesse angulaire plus faible que son opposée.
Grâce aux équations trouvées, tourner à droite ou à gauche en respectant un certain
rayon de courbure devient possible en respectant deux raports :
Gauche :
ωb
ωc
=
R
R + 2d
Droite :
ωb
ωc
=
R + 2d
R
⇒ Du moment que le rapport est respecté, peu importe la vitesse du robot pendant le
virage, il pourra toujours effectuer le virage décidé.
4.2.3 Changement de trajectoire
Une fois la cinématique des deux trajectoires étudiée, il faut étudier la réunion des
deux : le moment où le robot va vouloir entamer son virage en venant d’un chemin recti-
ligne.
Les hypothèses sont les suivantes : il commence une trajectoire en ligne droite à vitesse
constante, puis entame un virage en MCU (mouvement circulaire uniforme).
Au point x1, le point où le robot entame son virage, l’accélération du robot est à la fois
nulle et à la fois égale à V 2
R ⇒ il y a donc une discontinuité de l’accélération au point x1.
Pour ce qui est de la vitesse relative du robot en ce point, elle vaut à la fois deux
valeurs, ce qui conduit comme avec l’accélération à une discontinuité de la vitesse en ce
point. Et vu que
v0
(t) = lim
∆t→0
v(t + ∆t) − v(t)
∆t
= a(t),
Cela voudrait dire que v0(t1)=∞ ! Il est donc impossible pour le robot d’entamer un arc
de cercle parfait.
Voici deux graphiques qui montrent la discontinuité de la vitesse et de l’accélaration en
fonction du temps au point du changement de trajectoire.

Figure 4.7 – Vitesse en fonction
du temps
Figure 4.8 – Accélération en
fonction du temps
Pour commencer son virage, le robot va donc devoir s’arrêter, se positionner en va-
riant les vitesses angulaires de ses roues motrices, et ensuite seulement pouvoir avoir une
trajectoire en arc de cercle.
4.2.4 Etude balistique
Pour pouvoir propulser une balle avec précision, l’étude balistique est crutiale pour
savoir avec présision la trajectoire de la balle au court du temps.
Ici, les choses seront simplifiées pour que les solutions analytiques restent accessibles, à
savoir, négliger les forces de frottements et imposer que la balle n’aura aucun spin lors de
sa trajectoire.
Les données :
– La balle sera au niveau du sol avant d’être propulsée
– L’élastique de la catapulte aura une raideur k
– L’angle d’inclinaison aura une inclinaison θ
– La hauteur et longueur maximale que la balle atteindra sera hmax et Lmax
– La hauteur jusqu’où le contact entre la balle et l’élastique se fera sera h
– La masse de la balle sera notée m
Les calculs :
La trajectoire de la balle sera une trajectoire plan (pas d’air ni de spin pour influencer
son mouvement). Alors, deux équations scalaires, l’une en x et l’autre en y, suffiront à
modéliser le mouvement (deux degrés de liberté),
x(t) = v0 cos(θ)t
y(t) = v0 sin(θ)t −
gt2
2
Pour calculer v0, la vitesse initiale du lancé, le théorème de la conservation d’énergie semble
être le plus approprivé.
⇒ K1 + U1él + U1pot = K2 + U2él + U2pot
Dans ce cas-ci, l’énergie stockée dans l’élastique sera transformée en énergie cinétique et

potentielle.
K1 = 0
U1él =
kx2
2
U1pot = 0
K2 =
mv2
0
2
U2él = 0
U2pot = mgh
⇒
kx2
2
=
mv2
0
2
+ mgh
v0 =
s
kx2
m

− 2gh
Une fois v0 trouvé, il peut être remplacé dans les équations de la balistique afin de trouver
hmax et Lmax.
s
kx2
m

− 2gh · sin(θ)t −
gt2
2
= 0
⇒ t1 = 0 et t2 = 2
g
r
kx2
m

− 2gh · sin(θ), t2 sera gardé.
Pour trouver ymax, il suffit d’égaler la dérivée de y(t) à 0 pour avoir le temps que la balle
prendra pour atteindre sa hauteur maximale, et ensuite remplacer t par ce nouveau temps
t3.
Lmax =
(kx2
m − 2gh) sin(2θ)
g
hmax =

kx2
m − 2gh

sin2(θ)
2

4.3 Statique
Pour pouvoir programmer le robot afin qu’il puisse se diriger seul, éviter des obstacles
et accomplir un certain nombre de tâches, il est important de connaitre toutes les forces
qui s’appliquent sur ce dernier dans plusieurs situations.
Voici les données qui seront utilisées lors des calculs :
– Na Réaction du sol sur la roue A
– Nb Réaction du sol sur la roue B
– Nc Réaction du sol sur la roue C
– ff Forces de frottements du sol aux points d’application des roues
– µs Coefficient de frottement statique
– m Masse du robot
– g Constante gravitationnelle de la Terre
– (ê1,ê2,ê3) Base orthonormée sur laquelle s’appuiera les calcules
Pour être en équilibre, ces conditions-ci doivent être satisfaites : la somme de toutes
les forces et moments de forces qui s’appliquent au robot doivent être nulles. Autrement
dit :
X
i
~
Fi = ~
0
X
i
~
τi = ~
0
4.3.1 Concetion de l’engin
Afin d’effectuer au mieux les calculs, il faut tout d’abord décrire l’engin sur lequel sera
appliqué les équations. Trois roues lui seront attribués pour raison de stabilité, car vu que
l’engin sera posé sur un sol plan, alors trois points de contacts suffiront à stabiliser l’engin.
Cela peut s’expliquer mathématiquement. En effet, pour pouvoir avoir une équation car-
tésienne d’un plan, il suffit juste de trois points. Donc ici, cela signifirait qu’une quatrième
roue serait une contrainte supplémentaire.
Pour la conception :
– Deux roues motrices à l’avant séparées d’une distance 2d
– Une roue folle à l’arrière qui est à une distance l du centre de l’essieu qui relie les
deux roues motrices
– Le centre de gravité est situé à une hauteur h du sol et à une distance d du centre
de l’essieu
4.3.2 Plan horizontal
Tout d’abord, lorsque le robot est au repos sur un sol plat.
Le point d’application pour les moments de force sera le milieu entre les deux roues
arrières au niveau du sol.

Figure 4.9 – Vue latérale Figure 4.10 – Vue du dessus
X −
→
F e3 = ~
0 (4.4)
X
−
→
τ = ~
0 (4.5)
De (4.4), il est facile d’extraire l’équation scalaire qui en sort, à savoir,
Na + Nb + Nc = m · g (4.6)
Ensuite, (4.5) donne comme indiqué l’équation vectorielle des moments de force appli-
qués au point choisi, à savoir :
(−2dê1 ⊗ Ncê3) + ((−dê1 + (l − d)ê2) ⊗ −mgê3) + ((−dê1 + lê2) ⊗ Naê3) = ~
0
⇒ 2dNcê2 − dmgê2 − (l − d)mgê1 + (dNaê2 + lNaê1) = ~
0
⇒ (lNa − (l − d)mg)ê1 + (dNa + 2dNc − dmg)ê2 = ~
0
Les deux autres équations scalaires sont,
2dNc + dNa = mg (4.7)
lNa − mg(l − d) = 0 (4.8)
Grâce aux trois équations scalaires (4.6), 4.7 et 4.8, les trois forces de réactions appli-
quées aux roues peuvent être facilement trouvées (3 équations à 3 inconnues), et donc,
Na =
(l − d)mg
l
(4.9)
Nb =
dmg
2l
(4.10)
Nc =
dmg
2l
(4.11)

4.3.3 Plan incliné
Lorsque le robot se trouvera sur un plan incliné, les forces de réactions ne seront plus
les mêmes, donc il faut les recalculer.
Deux cas seront abordés :
– Lorsque le robot sera dans sa position longitudinale
– Lorsque le robot sera dans sa position transversale
Dans chacun de ces deux cas, l’angle maximal avant que le robot se mette à glisser et
celui avant qu’il se mette à basculer seront calculés.
Premier cas :
Le robot a les deux roues motrices freinées et est positionné avec la roue libre vers le
bas.
Le point où seront appliqués les moments de force sera le point de contact entre la
roue A et le sol.
Figure 4.11 – Vue latérale
X −
→
F e2 = ~
0 (4.12)
X −
→
F e3 = ~
0 (4.13)
X
−
→
τ = ~
0 (4.14)
Les équations (4.12), (4.13) donnent ces deux équations scalaires que voici,
mg sin α = ff (4.15)
Na + Nb + Nc = mg cos α (4.16)

(Ici, ff = µs(Nb+Nc), les forces de frottements dues aux roues B et C)
Ensuite, l’équation (4.14) donne :
((−l + dê1) ⊗ Nbê3) + ((−lê2 − dê1) ⊗ Ncê3) + ((−lê2 + dê1) ⊗ −µsNbê2) (4.17)
+((−lê2 − dê1) ⊗ −µsNcê2) + ((−dê2 + hê3) ⊗ (mg sin αê2 − mg cos αê3)) = ~
0 (4.18)
⇒ (dmg cos α−lNb −lNc −hmg sin α)ê1 +(dNc −dNb)ê2 +(dµsNc −dµsNb)ê3 = ~
0 (4.19)
Les trois équations qui sortent de cette équation vectorielle sont :
− lNb − lNc + dmg cos α − hmg sin α = 0 (4.20)
dNc − dNb = 0 (4.21)
dµsNc − dµsNb = 0 (4.22)
Les équations (4.21) et (4.22) disent que Nb = Nc. A partir de cette donnée, (4.20)
devient
−2lNb = hmg sin α − dmg cos α = 0
⇒ Nb = Nc =
dmg cos α − hmg sin α
2l
Donc, avec (4.16),
Na = mg(cos α −
d cos α − h sin α
l
) (4.23)
Pour l’angle pour lequel le robot glisse, la condition générale est que Ff µsN. Ici, l’engin
se mettra à glisser une fois que ff mgsin α.
ff mg sin α
µs(Nb + Nc) mg sin α
µs(
d cos α − h sin α
l
) sin α
arctan

µsd
l + µsh

α
L’angle d’inclinaison maximal du robot dans sa position longitudinale juste avant qu’il se
mette à glisser est arctan

µsd
l+µsh

.
Pour que le robot bascule, il faut que Nb et Nc soient négatifs.
dmg cos α − hmg sin α
2l
0
d cos α h sin α
arctan

d
h

α
L’angle d’inclinaison maximal du robot dans sa position longitudinale juste avant qu’il se
mette à basculer est arctan

d
h

.

Figure 4.12 – Vue transversale
Deuxième cas : Cette fois-ci, le robot est en position transversale donc la force de
frottement de la roue A (libre) interviendra. Le point d’application pour les moments de
force sera le même que celui du plan horizontal, à savoir le point au milieu des roues B et
C au niveau du sol.
X −
→
F e1 = ~
0 (4.24)
X −
→
F e3 = ~
0 (4.25)
X
−
→
τ = ~
0 (4.26)
De 4.24et 4.25, il vient,
ffa + ffb
+ ffc = mg sin α (4.27)
Na + Nb + Nc = mg cos α (4.28)
Pour l’équation 4.26, le développement du calcul est le suivant :
(lê2⊗µsNaê1)+(lê2⊗Naê3)+(((l−d)ê2+hê3)⊗(−mg sin αê1 − mg cos αê3))+(dê1⊗Nbê3)+(−dê1⊗Ncê3) = ~
0
⇒ (lNa − (l − d)mg cos α)ê1 + (dNb − dNc − hmg sin α)ê2 + ((l − d)mg sin α − lµsNa)ê3
Il en sort,
Na =
(l − d)mg sin α
lµs
(4.29)
dNc − dNb = hmg sin α (4.30)
Avec (4.28), il est facile de trouver les deux autres forces de réactions du sol :
Nb =
mg
2

cos α −
sin α(l − d)
lµs
−
h sin α
d

(4.31)
Nc =
mg
2

cos α −
sin α(l − d)
lµs
+
h sin α
d

(4.32)
L’engin va se mettre à glisser à partir du moment où mg sin αff
mg sin α µs(Na + Nb + Nc)
mg sin α µsmg

sin α(l − d)
lµs
+ cos α −
sin α(l − d)
lµs

α arctan µs

L’angle d’inclinaison maximal du robot dans sa position transversale juste avant qu’il se
mette à glisser est arctan µs
Pour l’angle de bascule dans sa position transversale, des tests expérimentaux ont été
effectués pour voir si la roue A (libre) se soulevait du sol en même temps ou juste après
la roue B, qui se trouve au point le plus haut. Il a été remarqué que la roue B se soulevait
d’abord, donc les calculs seront basés sur cette hypothèse.
Nb 0
mg
2

cos α −
sin α(l − d)
lµs
−
h sin α
d

0
arctan

dlµs
(l − d)d + hlµs

α
L’angle d’inclinaison maximal du robot dans sa position transversale juste avant qu’il se
mette à basculer est arctan

dlµs
(l−d)d+hlµs

Calcul du centre de masse
Une fois les forces et angles critiques trouvés pour chacun des cas étudié, il faut main-
tenant estimer le centre de masse pour pouvoir ainsi remplacé les paramètres fixés plus
haut, ce qui donnerait une idée approximative des angles et forces calculés.
Pour ce faire, le robot sera simplifié au maximum pour faciliter les calculs. Il sera
constitué de cinq assemblages d’objets, à savoir : deux disques à l’avant remplaçant les
deux roues, un disque à l’arrière remplaçant la roue folle, un parallélépipède rectnagle
remplaçant le corps, et un cylindre au dessus du corps incliné de 30 degrés par rapport au
sol pour remplacer le canon. La formule générale pour trouver le centre de masse est
Figure 4.13 – Vue latérale du robot final simplifié
−
−
→
OG =
X
i
mi
−
→
ri
m1
Ici, vu que le rebot est décomposé en cinq objets, le but est de claculer le vecteur posi-
tion des centres de masses de chaque objet et ensuite appliquer la formule. La formule
est utilisable car la densité de chaque objet est uniforme. Le repert a été choisi pour que
l’origine soit centre du robot, et vu que tout est centré et que la masse est uniformément
distribuée, il n’y aura pas de composante ê1.

Le centre de masse du robot , après de longs calculs, est
−
−
→
OG = 0.52ê2 + 63ê3 (4.33)

4.4 Informatique
Introduction
Pour le prototype LEGO ont été utilisées à la fois des pièces LEGO Technix “normales
et des pièces LEGO Mindstorms, qui s’emboitent parfaitement dans les LEGO Technix et
qui permettent d’animer la construction. On passe ainsi d’une “simple construction LEGO
à un robot complexe. Dans cette partie seront développées ces pièces LEGO Mindstorms
ainsi que le code informatique du prototype LEGO.
Les pièces LEGO Mindstorms
Figure 4.14 – La boite de LEGO Mindstorms mise à disposition comprenait 3 moteurs
et 4 capteurs différents
Le NXT
Le NXT est à proprement parler le cerveau du robot. Il est muni de 4 entrées, de
3 sorties et d’une mémoire interne sur laquelle peut tourner un programme capable de
commander les moteurs et de récupérer les valeurs mesurées par les capteurs.
Le NXT possède aussi un écran LCD qui peut afficher du texte ou des données ainsi
que 4 boutons qui permettent de paramétrer le robot et choisir le programme à exécuter.
De plus, le NXT est aussi doté d’une interface Bluetooth et d’un port USB, qui lui
permettent de communiquer avec d’autres appareils. Le port USB permet au NXT de
communiquer avec un ordinateur (et permet ainsi par exemple le transfert de fichiers).
L’interface Bluetooth permet au NXT, en plus de communiquer avec un ordinateur, de

communiquer avec d’autres NXT (un robot pourrait par exemple en commander d’autres),
avec un téléphone portable (un smartphone pourrait commander un robot) ou avec cer-
tains autres périphériques disposant d’une interface Bluetooth (il est par exemple possible
qu’un robot se connecte à un GPS pour récupérer des informations telles que la localisa-
tion).
Les moteurs
Les servomoteurs sont au nombre de trois et permettent au robot de se déplacer ou
d’effectuer certaines actions comme prendre un objet ou le lancer. Ils disposent aussi d’un
capteur de rotation qui leur permet de mesurer les rotations qu’ils effectuent.
Les capteurs
Les capteurs permettent au robot de mesurer différents paramètres et fournissent au
NXT des données précises. Ces capteurs sont au nombre de quatre différents et bien qu’ils
n’aient pas tous été utilisés dans le prototype LEGO, ils seront tous détailles ici. Afin
d’utiliser les différents capteurs il faut préalablement créer une instance à l’aide de leur
constructeur correspondant et bien que ces derniers soient tous différents ils peuvent cha-
cun être créés avec comme seul argument le port sur lequel le capteur est connecté.
– Le capteur photosensible :
Le capteur photosensible permet de mesurer l’intensité lumineuse de différentes cou-
leurs (l’intensité s’exprimant sur une échelle de nuances de gris), de mesurer l’in-
tensité lumineuse dans son environnement ou de faire la distinction entre lumière et
obscurité.
– Capteur de son :
Le capteur de son permet de mesurer le niveau de décibels et peut fonctionner en
deux modes : en mode dBA il mesure uniquement l’intensité sonore des sons audibles

par l’oreille humaine et en mode dB il mesure tous les sons, y compris ceux qui se
trouvent dans une plage de fréquence que l’oreille humaine ne peut entendre. Après
avoir créé une instance du capteur, il suffit d’appeler la méthode readValue() afin de
récupérer l’intensité sonore ambiante.
– Le capteur d’ultrason :
Le capteur d’ultrason fonctionne comme un sonar, il mesure la distance en émettant
des ondes et en calculant le temps nécessaire pour que les ondes soient réfléchies
et reviennent. Le capteur ultrason peut mesurer des objets à une distance allant
de 0 à 2,5 mètres mais il faut cependant être prudent lors de l’utilisation du cap-
teur car il n’est précis qu’a trois centimètres près et après une batterie de tests
il s’avère que sa précision est fonction de la distance à laquelle se trouve l’objet
dont il mesure la distance. Pour récupérer la distance mesurée par le capteur, c’est
la méthode getDistance() qu’il faut appeler après avoir créé une instance du capteur.
– Le capteur de pression :
Le capteur de pression fonctionne comme un bouton poussoir : soit il est enfoncé et
la valeur renvoyée par isPressed() est true, soit il est relaché et la valeur renvoyée
par isPressed() est false.

Java – Lejos
Le langage JAVA est le langage qui a été utilisé pour la programmation du robot. Afin
de pouvoir programmer le robot en java il a fallu installer lejos, une machine virtuelle qui
remplace le firmware du NXT par un firmware lejos, qui permet au NXT d’interpréter le
code java.
Lejos comprends aussi une librairie de classes qui permettent d’utiliser des méthodes
propres au robot en plus des méthodes java de base et un compilateur qui permet de
compiler des fichiers java en fichiers qu’on peut envoyer sur le NXT.
Programmation par taches
Après une rapide analyse des fonctionnalités que le robot devait effectuer, il est vite
apparu qu’une “simple programmation séquentielle ne suffirait pas, car elle rendrait le
code peu modulable, avec plusieurs conditions imbriquées et plusieurs appels répétitifs de
méthodes.
Le choix s’est alors porté sur une programmation événementielle, ou les différentes
actions du robot ont été découpées en plusieurs tâches telles qu’attraper la balle, lancer la
balle, retourner à la zone de départ,... sont placées dans différentes classes qui comprennent
chacune trois méthodes : takeControl(), action() et suppress(). La première méthode est
la condition d’activation de la tâche, elle renvoie true lorsque les conditions d’activation
de cette tache sont remplies. La méthode action() est l’ensemble des actions à effectuer
lorsque cette tâche à le contrôle. Enfin, la méthode suppress() est l’ensemble des actions
a effectuer quand une tache plus prioritaire prends le contrôle afin d’arrêter les actions en
cours (typiquement, arrêter le robot)
Toutes ces taches sont ensuite assemblées dans un Arbitrator, qui va “arbitrer ces
différentes taches. Si la condition d’activation d’une tache est satisfaite, cette tache prends
le contrôle et exécute la méthode action() de cette tâche. Lorsque la condition d’activation
d’une tache plus prioritaire que celle actuellement en cours est satisfaite, l’exécution de
la tache actuelle est avortée par l’appel de la méthode suppress() de cette méthode et la
tâche plus prioritaire prends le contrôle.
Pour l’activation des différentes taches, les conditions dépendent de booléens qui sont
false depuis le début et qui deviennent true uniquement une fois la tache précédente ac-
complie avec succès. Cette méthode a été préférée a l’utilisation d’un compteur qui est
incrémenté à la fin de l’exécution de chaque tache, car le code est ainsi plus modulable
et qu’il est plus facile d’insérer une éventuelle méthode supplémentaire, ce qui est arrivé
à plusieurs reprises lors du développement du code, sans avoir à modifier les conditions
d’activation de toutes les autres taches et ainsi risquer des erreurs d’activation et de prio-
rités.
Evolution du code et de l’algorithme
Tout d’abord, les performances à réaliser ont été analysées et une première ébauche de
structure a été écrite. Ensuite des méthodes de test qui ne faisaient qu’afficher les valeurs

mesurées par les capteurs ont permis de comprendre le fonctionnement des différents cap-
teurs, leurs points forts ainsi que leurs faiblesses, et ont permis de déterminer à quel point
les mesures effectuées par les capteurs étaient fiables et précises. Fort de ca une première
ébauche de code a pu être écrite avec comme valeurs numériques uniquement des valeurs
théoriques. Une fois ce code la fonctionnel, ces valeurs ont été calibrées. Dans un dernier
temps, le code a été épuré et rendu modulable, entre autres par l’utilisation de variables
pour stocker toutes les valeurs numériques.
Figure 4.15 – Schéma des différentes classes, chaque classe étant une tache différente
La classe robot contient la classe main qui assemble toutes les autres. C’est celle-ci
qui contient l’initialisation des Behaviors, crée l’Arbitrator, et lance ce dernier juste après
avoir lancé le chronomètre.
La classe actionUn permet au robot d’aller vérifier si la zone se trouve du «1e coté», le
premier coté étant là où la méthode determineDistance() a déterminé qu’il y avait le plus
de probabilité que la zone noire se trouve.
La classe actionUnBis permet au robot de prendre la balle une fois que la zone noire
est trouvée. Pour ce faire le robot recule, abaisse la pince, ré avance puis lève légèrement
la pince pour prendre la balle.
La classe actionUnTer permet au robot d’aller chercher la balle du « 2e coté » uni-
quement si elle n’a pas été trouvée du premier côté.
La classe actionDeux permet au robot d’aller derrière la ligne M1, perpendiculairement
à celle-ci afin de pouvoir commencer à chercher la ligne grise.
La classe actionTrois permet au robot de trouver l’endroit où la ligne grise intersecte
avec la ligne M1.

La classe actionQuatre permet au robot de retourner derrière la ligne M2 tout en res-
tant aligné sur l’intersection entre la ligne M1 et la ligne grise et donc aligné sur le panier,
ainsi que de lancer la balle dans le panier.
La classe actionCinq permet au robot de retourner à sa position initiale au moyen de
la méthode goTo().
La classe emergencyRestart permet de redémarrer le robot en appuyant sur le bouton
escape du NXT sans devoir réinitialiser la console ni recalibrer le robot. La tache attend
qu’un bouton soit poussé pour redémarrer l’exécution du programme au début.
Le tableau suivant reprend les différents Behavior dans l’ordre croissant de priorité :
1 2 3 4 5 6 7 8
actionUnTer actionUn actionUnBis actionDeux actionTrois actionQuatre actionCinq emergencyRestart
Figure 4.16 – Ordre d’exécution des différentes taches
Explication de la console
Pour pouvoir facilement débuguer le code, nous avons utilisé la classe RConsole, qui

permet de transmettre simplement des données afin qu’elles soient affichées sur un pc.
Les données sont transmises soit par USB soit par Bluetooth, et permettent ainsi de
suivre en temps réel et sur pc l’avancement du robot. Pour utiliser la console, il faut éta-
blir une connexion entre le robot et l’ordinateur avec une des méthodes open (il existe
plusieurs méthodes open dépendamment de si l’on veut établir une connexion par USB,
par Bluetooth, ou via n’importe laquelle des deux). Il suffit ensuite d’appeler la méthode
RConsole().println() pour afficher du texte sur la console et finalement la méthode RCon-
sole.close() pour couper la connexion. Pour recevoir les données l’ordinateur il faut lancer
la console via la commande ‘nxjconsole’ dans l’invite de commande.
Le robot utilise la console pour envoyer un message à chaque fois qu’il rentre ou sort
d’une tache et à chaque fois qu’il lit la valeur d’un des capteurs. Le robot est programmé
de telle manière qu’il envoie un message après chaque opération conséquente qu’il effectue,
afin de pouvoir aisément localiser une éventuelle erreur dans le code.
Au début de l’exécution du code, la méthode initializeConsole() est appelée. Elle per-
met de choisir d’utiliser ou non la console en fonction du bouton pressé et le cas échéant
attend que la connexion soit établie, dans le cas contraire la suite du programme est exé-
cuté. Cette méthode est appelée avant même la création des Behaviors.
La méthode console() permet d’envoyer des données vers la console. Il est nécessaire
d’appeler cette méthode plutôt que de directement appeler RConsole.println() car la mé-
thode console vérifie qu’une connexion est établie et évita ainsi de tenter d’envoyer des
données tandis qu’aucune connexion n’est établie, ce qui risquerait de provoquer des er-
reurs et interrompre l’exécution du code. Si la connexion n’est pas établie, la méthode
console() affiche le texte sur l’écran LCD du NXT uniquement si le deuxième paramètre
est true. Si la méthode console() est appelée sans préciser le deuxième paramètre, il prend
la valeur true par défaut. La méthode addPrefix() permet de «mettre en page» le texte
qui sera envoyé à la console afin de le rendre facilement lisible et analysable sur la console.
On a ainsi en un coup d’œil une vue précise et claire des données affichées dans la console.
Même si l’implémentation de la console a pris un peu de temps à mettre en place
(comprendre le fonctionnement, créer les méthodes,...), l’utilisation de la console a été très
pratique et a été un gain de temps non négligeable pour debugger le code. En effet il ne
fallait pas suivre le robot pour lire les données sur l’écran LCD, il était possible de garder
les données affichées même après l’arrêt du robot et il était très facile de localiser l’erreur
dans le code.
Mapping / cartographie
Le robot est équipé d’un système de mapping, qui lui permet de déterminer à tout mo-
ment sa position sur un axe cartésien virtuel, ce qui permet de simplifier considérablement
les mouvements du robot. Pour mettre en place ce système de mapping, trois classes sont
utilisées : OdometryPoseProvider, Pose et Point. OdometryPoseProvider permet de créer
un objet qui enregistre tous les déplacements réalisés par un objet de type MoveProvider
tel que DifferentialPilot. La classe Pose permet de créer un objet Pose qui représente une
position (des coordonnées en x et y et un angle). Un objet Pose peut être créé manuelle-
ment ou récupéré d’un objet OdometryPoseProvider à l’aide de la méthode getPose(). La
classe Point quant à elle permet de créer des objets Point, qui représente un point selon

ces coordonnées en x et y. Cette dernière classe a été nécessaire car certaines méthodes de
la classe Pose nécessitent un objet de type Point comme argument.
Exemple de récupération de la position du robot :
1 OdometryPoseProvider pp = new OdometryPoseProvider ( p i l o t ) ;
2 // Deplacment t e l s que p i l o t . t r a v e l () ou p i l o t . rotate ()
3 Pose pose = pp . getPose () ;
4 int x = pose . getX () ;
5 int y = pose . getY () ;
Le mapping permet au robot de se rendre directement vers un point déterminé, et
pour cela une méthode goTo() a été implémentée qui permet au robot de se rendre en
ligne droite vers un point, qui est définit par ses coordonnées x et y ainsi que par l’angle
par rapport à l’axe x. Cette méthode calcule l’angle de départ et de fin ainsi que la distance
à parcourir et cette méthode fait appel à une autre, shortAngle() qui permet de «nettoyer»
l’angle. Les calculs des angles donnaient souvent des angles de plus de 180◦ ou même 360◦,
et il existe donc un angle plus court à faire parcourir au robot pour qu’il arrive au même
angle.
Améliorations possibles
Plusieurs idées de méthodes, de classes ou de fonctionnalités ont été imaginées durant
la programmation certaines n’ont pas pu être implémentées soit par manque de temps, soit
parce qu’elles dépassaient de loin nos compétences ou encore parce qu’elles dépassaient de
loin le cadre de ce cours. Voici les améliorations qui ont été envisagées :
– Le calibrage, au lieu de se faire en un point sur du gris et en un point sur du
noir pourrait se faire en plusieurs points par couleurs, afin de pouvoir calculer une
moyenne et avoir des valeurs encore plus précises
– Une tache prioritaire avoidCollision() avec conne condition d’activation une méthode
booléenne riskCollision() pourraient être implémentées pour éviter que le robot ne
cogne une paroi du terrain lors de ces déplacements. A chaque moment, en fonction
de la position actuelle ainsi que de l’angle, qui sont connus grâce à la cartographie,
la méthode riskCollision() vérifie qu’aucun point du robot ne s’approche de moins
qu’une distance critique des bords du terrain. Si le robot s’approche trop des bords,
la tache prends le contrôle et le mouvement est donc directement avorté. La tache
rectifierait la trajectoire et le robot pourrait ensuite reprendre son déplacement.

– La vitesse de chaque mouvement pourrait être optimisé à la vitesse limite acceptable
sans perte de précision, afin de gagner du temps sans pour autant perdre en fiabilité
et en efficacité.

5 Le bilan du travail de groupe et les bilans individuels
Etant composé uniquement de bisseurs, nous avions déjà vécu cette expérience une fois,
mais cela n’a pas empêché pour autant de devoir encore apprendre beaucoup de chose.
Tout d’abord nous avons dû apprendre à nous connaitre puis à s’organiser et cela resta un
défi malgré l’expérience passé.
De plus notre groupe se trouve être plus nombreux que l’année précèdent (8 garçons),
ce qui aura pour effet direct de nous faire penser que l’on aurait moins personnellement
à fournir vu qu’on est plus. Cette méprise sur l’attitude à avoir nous avait conduits droit
dans le mur lors du pré-jury qui fut catastrophique. Alors depuis S6, on s’est tous remis à
bosser comme il faut, à s’impliquer et à fournir sa part du travail.
En premier lieu nous avons mis à jour notre comportent à adopter, les différents point
sur lesquelles il fallait bosser pour s’améliorer sont énumérer ci-dessous, ainsi que des in-
dicateurs pour ceux-ci.
Pour la production du groupe, après le pré-jury, le bilan du travail qui a été effectué
avant montrait bien qu’il y avait beaucoup de chose à faire. Donc nous nous sommes mis à
faire toute les tâches demandées en séance ainsi que les demandes de séance suivante. Pour
ce rapport, nous avions déjà prévu le coup en attribuant les parties du robot à chacun
pour avoir un robot performant.
Pour l’apprentissage réalisés, nous avions encore beaucoup de chose à apprendre car
nous avons pu travail sur des parties du rapport que nous n’avions pas touché l’année
dernière, ce qui nous a permis d’apprendre des nouvelles compétence mais nous avons
aussi renforcer nos bases dans d’autres matière en aidant les autres.
Pour la participation et l’implication de chacun, avant la semaine 6 aucun d’entre nous
ne s’impliquait réellement dans quoi que ce soit mais suite à la gifle du pré-jury, l’un après
les autres nous nous sommes mis entièrement dans ce projet. Chacun apportant ces capa-
cités au profit du groupe.
Pour l’organisation du travail, nous n’avions pas énormément préparé le planning pour
le pré-jury, alors nous avons mis au point un agenda/planning qui nous aida à la réalisa-
tion du projet. Il n’est tout de même pas parfait mais son utilité fut primordiale au bon
déroulement.
Pour la répartition des rôles, dès le début de la quadrimestre, nous nous ne sommes
pas distribuer les rôles, mais au fur et à mesure que les séances se succédaient, on a vu
s’installer des caractères qui ont pris des rôles à leur mesure, par exemple Denis était celui
qui énumérerait les objectifs de séance, Harold et Aris sont ceux qui poussait les autres,
Ivo était le secrétaire et s’occupait des publications, etc.
Pour l’expression de chacun, on se trouve dans un groupe, où tout le monde est très
ouvert d’esprit et où l’échange est facile et respecter.
Pour la coopération et le climat de travail, c’était un gros défaut que l’on avait avant le
pré-jury et que l’on a essayé de régler mais pas avec un énormément de succès et beaucoup
de temps pour y parvenir. Le groupe n’était au départ que rarement complet mais durant
ces 5 dernières semaines, on était tous présent et près au travail.

Pour la gestion des conflits, il n’y en a pas eu grand nombre et même si il y en a eu ils
ont toujours été constructifs et brefs.
Ce diagramme montre l’évolution que notre groupe a subit l’or des différentes semaines
clés.
Les indicateurs :
– Il faut faire un planning complet dès le début du projet et avec des points le plus
précis possible.
– Il faut garder tous les sources consultées pour la bibliographie.
– Il faut s’impliquer dès le premier jour et s’avancer le plus tôt possible pour ne pas
être pris à la dernière minute.
5.1 Bilan individuel : Afsar Aris
Après plusieurs mois passés au sein de notre groupe, je peux dire que ce projet fut une
expérience enrichissante. Dès les premières semaines, une très bonne entente, peut-être
un peu trop bonne, s’est établie au sein du groupe. Certes, il n’y avait pas vraiment de
conflit grâce à cela mais lorsque des travaux de plus grosse ampleur sont arrivés, il a fallu
se remettre en question.
J’étais très mal organisé et je n’ai pas apporté mon maximum. Je n’avais pas vraiment
de volonté à poursuivre le projet puisqu’aucun membre du groupe ne prenait la peine de
faire ce qui lui était demandé, ce qui était une erreur de notre part. Arrivé au pré-jury,
notre groupe s’est fortement fait critiqué quant à la qualité de notre rapport. En effet
celui- ci fut de très mauvaise qualité. Mais heureusement pour nous, nous avons pu nous
ressaisir et j’ai tout de suite eu plus de plaisir à travailler avec un groupe qui se rendait
compte de l’ampleur du projet.
Le groupe a acquis une dynamique de travail plus ou moins soutenue, qui est le fruit
de six semaines de travail et de coopération, et non pas douze ! En effet, nous avons dû
faire un travail de 12 semaines en 6-7 semaines seulement. Pour ma part, j’en ressors plus
riche et plus apte à travailler en équipe. Étant en arch l’an passé, ce fut mon premier
travail de cette ampleur en groupe. J’ai pu découvrir quels étaient mes point forts et ceux

où j’éprouvais plus de difficultés, trouver ma place au sein d’un rôle, ce qui me servir sans
doute dans les années à venir.
5.2 Bilan individuel : Arnould Julien
Voici maintenant douze semaines passées en première année d’ingénierie civile. . . Pour
la deuxième fois !
D’un point de vue personnel, s’il fallait choisir un unique mot pour qualifier ces douze
semaines, à coup sûr le mot téméraire serait de mise. En effet, le fait de bisser avec relati-
vement peu de cours a germé une illusion telle que cette année serait sans peine ni travail
ardu, sous prétexte que « tout a déjà été vu et revu l’an dernier ». Il est vrai que, d’un
côté, les matières ont été étudiées l’an dernier et que le programme n’a que très peu de
différences avec l’actuel ; par contre, d’un autre côté, la nonchalance et la procrastination
répétée ont fait que, pour des tâches simples, un retard insensé a été accumulé. Après
une première remise à niveau relativement « musclée » au pré-jury, le groupe a décidé de
prendre enfin les devants, cessant de se reposer sur le principe que d’être un groupe de
bisseurs n’avait que des avantages. Certes, il y a des avantages à avoir déjà parcouru la
matière, mais l’avantage doit être utilisé dans le bon sens : il doit permettre un approfon-
dissement plus profond dans la matière et le projet en soi, plutôt que de se reposer sur un
résultat acceptable, pour un moindre effort.
Ce quadrimestre a permis de remettre en question la position que devrait avoir un
bisseur vis-à-vis de ses études : toujours viser un objectif élevé, sans choisir un résultat
arrangeant, et surtout obtenu de manière peu éducative.
5.3 Bilan individuel : Berrada Yassine
Un long périple vient donc maintenant de s’achever en même temps que ce projet, il
fut difficile de créer un robot capable de jouer au basket. Pour y parvenir je me suis mis
à jouer au basket à l’ADEPS du Blocry pendant les permanences pour le basketball.
J’ai de cette façon appréhender la vision du jeu, les règles de ce sport et les différents
aspect qui sont mis en oeuvre pour chacune des actions que le robot se devra de savoir
effectuer. Avec l’expérience accumulé, j’ai voulu aider le groupe à avancer en émettant des
idées, et j’ai aussi contribuer au calcul des aspects physique du robot.
Au sein du groupe, je me suis directement bien entendu avec chacun et je sentais
une atmosphère amicale autour de notre groupe, mais le début n’était pas très productif
parce qu’on était tous dissipé et pas très prompt au travail les 4 premières semaines. Pour
rattraper notre retard, on a tous du travailler doublement et moi y compris en faisant mes
tâches, de plus j’était toujours là prêt à aider quelqu’un.
Mon appréciation de cette période de projet est que le projet était intéressant, que mon
groupe était marrant et travailleur par moment avec toujours une excellente ambiance.
5.4 Bilan individuel : Bian Yu Borge de Almeida Ivo Rui
Dès le début le projet de ce robot m’a intéressé et passionné car je pratique moi-même
du basketball depuis maintenant presque 10 ans, j’ai gagné un certain nombre de cham-
pionnats.

L’intérêt que je trouvais dans ce rapport est de comparer ma vision pratique de ce
sport à la vision théorique que me procure ce projet.
En comparant ma technique de tir personnelle et la technique optimisée théorique que
nous avons vue dans la partie physique du rapport j’ai ressenti des doutes quant à la
possibilité de ce tir en pratique.
Le déroulement du projet ne posait de problème qu’à cause du manque d’implication
dans le groupe mais suite à l’échec au pré-jury, nous avons mis les bouchés double pour à
la fois rattraper notre retard et mieux approfondir le sujet.
Mon manque de présence était un facteur négatif que je me suis efforcé de corriger
pour pouvoir profiter de tout ce que l’on pouvait m’apporter.
Je me suis alors mis à disposition du groupe pour toutes sortes de tâches telles que la
rédaction des questions du livret (To do list, Synthèse des bilans individuels, icampus, etc.)
L’entente dans le groupe maintenait une bonne ambiance qui cependant ne permettait pas
toujours une bonne productivité. Cependant, dès la semaine 7, le sérieux était de mise
pendant les séances avec de moins en moins de moments où nous étions dissipés. Pour
le rapport nous nous y sommes pris à l’avance comme notre expérience nous le dictait
en répartissant minutieusement les tâches à chacun, de manière à ne pas nous retrouver
pressés par le temps manquant et pouvoir retravailler le tout pour limiter le nombre
d’erreurs.
5.5 Bilan individuel : Bondroit Jérome
Nous voilà déjà arrivé à la fin de ce projet Q1 et ce pour la deuxième fois. Lors des
premières semaines, le travail était plutôt difficile car tout le groupe avait déjà réalisé
toutes les taches demandées l’an passé. Je voyais plus ce projet comme une répétition. En
commençant l’année je me suis direct dit que ça n’allait pas être évident de recommencer
ce projet. Cela c’est confirmé dès le pré-jury, ou nous sommes arrivés là avec un manque
de travail évident ! Après cette grosse “claque, c’est en groupe que nous avons décidé de
réellement se mettre à travailler. Je me suis rendu compte que si je devais recommencer
ce projet c’est parce que je n’avais pas acquis toutes les notions qu’il peut représenter
l’an passé. Je me suis donc mis sérieusement à travailler, d’abord en rattrapant le retard
accumulé lors des premières semaines et ensuite en réalisant toutes les taches demandées
chaque semaine. Les réunions de groupe devenaient de plus en plus régulières au fil des
semaines.
Je me suis donc rendu compte que le faite d’être bisseur devait être vu comme un avantage
plutôt qu’un inconvénient, d’un part parce que la matière a déjà été vue en partie une
première fois mais également d’autre part parce que ça permet d’en apprendre plus sur ce
projet, de faire des recherches bien plus détaillé. Nous devons viser bien plus haut que les
autres groupes de FSA11 car nous sommes partis avec bien plus d’avance qu’eux. Au final
je ne regrette pas avoir du recommencer ce projet.
5.6 Bilan individuel : Delacroix Harold
Cette année nous avons eu beaucoup de mal à nous mettre dans le bain pour le projet
et au pré-jury un énormément manque de travail se fut ressentir autant dans notre rapport

que dans notre maquette et notre présentation. La cause vient entre autre du fait que nous
étions “blazé” devant ce projet qui ressemble en grande partie à celui de l’année passée
et une atmosphère de fainéantise qui sait installé très vite au sein du groupe. En séance
nous arrivions, répartissions les tâches et repartions, avant la fin de la séance, sans avoir
fait de travail de fond. La séance d’après rien de ce qui avait demandé et prévu était fait
et des nouvelles choses à faire venaient s’ajouter aux anciennes. Au final c’est une petite
semaine avant le pré-jury que le groupe a commencé à s’y mettre et tout fut bâclé.
Le point positif est qu’après s’être pris une claque en s6, tout le groupe sait ressaisi
et une ambiance beaucoup plus studieuse et entreprenante fut installée. Les “to do liste”
furent mieux remplies et le travail était vérifié chaque semaine. Maintenant, après 6 se-
maines de vraie implication de la pars du groupe, on sent que le rapport est le fruits de
réfections beaucoup plus approfondies et qu’il y a eu un travail sérieux derrière. Encore
une fois le plus gros c’est fait assez tard et nous n’avons malheureusement pas assez profité
du fait que nous soyons bisseur pour prendre de l’avance avant les trois jours de bloque
pour rédiger le rapport.
L’avantage d’être d’en un groupe de bisseur, surtout comme le notre où nous savons
que la raison première de notre échec est un manque clair de travail, est qu’on apprend à
ne pas trop compter sur les autres et cela nous oblige à plus nous investir personnellement.
J’ai beaucoup plus ressenti l’importance du travail en groupe cette année car nous
avons vraiment un groupe où chacun a ces points forts ; l’un est doué pour l’informatique,
l’autre pour les calcules et enfin le dernier rédige assez bien. Le tout bien coordonné donne
un résultat bien meilleur qu’un travail fait par un élève seul.
Je suis donc, au final, satisfait du travail dans l’ensemble malgré le départ plutôt mé-
diocre et les quelques laisser aller qui se sont ressenti jusqu’au bout.
5.7 Bilan individuel : Gier David
Tout d’abord, je trouve que le groupe, malgré les problèmes auxquels nous avons eu
à faire face, s’en est relativement bien sorti au niveau de l’évolution du travail d’équipe.
Étant arrivé en retard en raison de problèmes d’inscription, je n’ai pas vu les débuts du
groupe, mais même lorsque je suis arrivé il manquait relativement d’organisation et de
motivation ce qui a changé au cours des semaines. Non seulement nous commencions à
nous connaître mutuellement mais en plus nous découvrions avec qui nous travaillions le
mieux, comment pousser la productivité à son maximum et optimiser autant que possible
notre technique de travail en équipe. Un exemple concret qui explique assez bien la situa-
tion (sans citer de noms, les rôles ont changé maintes fois au cours des semaines) : Un
membre du groupe se retrouve dissipé après une longue période de concentration et c’est
là qu’un autre membre du groupe intervient, nous sommes toujours là pour nous motiver
entre nous à terminer le travail. Plus nous progressions dans le projet, plus l’organisation
et le travail productif évoluaient positivement, nous permettant au fil des semaines de finir
les travaux bien avant l’échéance et de diminuer le stress dû aux travaux vite faits juste
avant l’échéance.
Personnellement, comme je l’ai déjà précisé plus haut, je suis arrivé plus tard que les
autres dans le groupe mais je pense avoir compensé cette absence du début non seulement

par un travail motivé pour montrer au groupe que je veux participer et aider autant que
possible et vraiment être intégré dans le groupe mais aussi par un soutien des autres
membres en les aidant dans leurs parties lorsque j’avais fini la mienne. Je pense mériter
ma place dans ce groupe autant que quiconque ayant été là depuis le début.
5.8 Bilan individuel : Mortier Denis
Je trouve que le bilan du travail de groupe, au même titre que l’entièreté du rapport,
reflète bien le travail que nous avons effectué tout au long de ces douze semaines. J’ai
beaucoup aimé travailler en groupe, car le travail en groupe permet un partage de savoirs :
il y a plus dans huit cerveaux que dans un. . . Etant un groupe de bisseurs, nous étions
forts de l’expérience de l’année passée, ce qui fut un avantage non négligeable. Nous avons
en effet essayé de ne pas refaire les erreurs de l’année passée. Le « risque » du travail de
groupe est par exemple que chacun travaille là où il a le plus de facilités et que les autres
n’apprennent rien sur ce point-là. Pour éviter cela nous avons essayé de ne pas forcément
confier une partie à celui qui «gère» le mieux dans ce domaine, et nous faisions une mise
en commun à chaque fois où l’on se partageait des taches. Tout au long de ces douze
semaines il y a eu une très bonne ambiance au sein du groupe, sans toutefois être exagérée
et non propice au travail. Nous avons toujours su faire ce qui nous était demandé, parfois
en s’organisant de manière plutôt « exotique », et je suis content du travail réalisé par le
groupe.
6 Conclusion
Voila la fin de ce premier projet de l’année et, malgré les difficultés qu’il y a eu pour
s’ y mettre, un résultat satisfaisant a été atteint. Maintenant une solution de robot a
été fournie et celui-ci peut jouer une partie de basket après avoir été programmé par un
tétraplégique. Ce robot ouvre donc une porte sur un nouveau sport des jeux paralympiques.
Les avantages qui ressortent de “Micheal Mouse” sont qu’il va permettre un jeu attractif
et agréable à regarder malgré qu’il ait été trop difficile de le faire dribbler avec le ballon.
C’est dans cette optique que la plus grande partie possible du robot est faite en plexiglace
pour permettre au public de voir un maximum de ce qui se passe à l’intérieur de l’engin.
Pour la même raison, “Micheal Mouse” est muni d’ un balcon dont la balle pourra tomber
à tout moment et de parchoques pour pouvoir gêner son adversaire. Toujours pour amuser
la galerie, la balle n’émet qu’à trois mettre de rayon pour que les robots la cherchent
s’ils sont plus écartés que cela et donc cela oblige les participants à implémenter un bon
programme.
La disposition et la structure du robot a été réalisé dans le but d’être parée à toutes
éventualités et surtout de pouvoir capter la balle avec un maximum de facilité. Un toit
placé à l’avant permet de prendre la balle même si elle rebondit et grâce au balais tournant
il est possible de capter les ballons décentrés par rapport au robot.
Au final, le résultat est un “Micheal Mouse” attractif et préparé a toutes les circons-
tances, mais celui-ci est loin d’être parfait. Déjà aucun effort n’a été fourni au niveau de
l’estétique ce qui le fait resembler à une souris et une maison. Mais, plus important, le
robot est assez lourd et sont système de lancement est loin d’être simple. Ce nouveau sport
ne peut aussi être jouer que sur un terrain très bien aménagé avec les balises et l’enceinte
en plexiglace nécessaire. Cela rajoute des coûts importants et empêche donc se sport de
se jouer n’importe où car les infrastructes sont assez encombrantes .
Il est clair que si nous avions eu plus de temps nous aurions approffondi presque

tous les points. Ce qui est dommage aussi c’est que nous n’avons pas du tout profité du
pré-jury pour avoir un avis objectif des problèmes de notre robot à cette étape là du
projet. Puisque presque rien n’a été fait avant la semaine six, le jury n’a pas pu donner de
pistes d’améliorations et donc tout c’est fait avec seulement quelques remarques du tuteur
pendant les séances.
Les recherches sur les turbines et le compresseur auraient pu être beaucoup plus pous-
sées. Des calculs voir même de test auraient pu être fait pour déterminer la vitesse de
pointe, que le robot puisse atteindre, la plus adaptée à un macth de basket comme celui-
là.
“Micheal Mouse” a donc des défaults, des qualités et énorméments d’améliorations
possibles, mais il est tout de même complet sans être parfait, et c’est avec satisfaction que
nous vous l’avons présenté ci-dessus.

Références
[1] Air comprimé. http://fr.wikipedia.org/wiki/Air_comprimé#Inconv.C3.
A9nients.
[2] Api lejos. http://lejos.sourceforge.net/nxt/nxj/api/index.html.
[3] Canon à air. http://fr.wikipedia.org/wiki/Canon_à_air.
[4] Détecteurs. http://siemens.automationjet.com/dt/
synchronous-servomotor-1ft6-0-4-nm-100-k-6000-rpm-natural-air-coolin/
1ft6021-6ak7.html.
[5] Gaines et tuyaux souples. http://www.h-tube.com/produits/Industrie/
1ind-tuyaux.pdf.
[6] icampus projet 1. http://icampus.uclouvain.be/claroline/course/index.php?
cid=FSAB1501.
[7] Moteur à air comprimé. http://fr.wikipedia.org/wiki/Moteur_à_air_comprimé.
[8] Règlement de la fiba. http://www.basketfrance.com/_arbitrage/docs/
Règlement_Officiel_du_Basketball_2012-Version_Modifications_2012.pdf.
[9] Système pneumatique. http://fr.wikipedia.org/wiki/Système_pneumatique.
[10] Tube pneumatique. http://fr.wikipedia.org/wiki/Tube_pneumatique.
[11] Méthode active de dessin technique. C. Hazard, A. Ricordeau, C. Corbet. Casteilla,
2010.
[12] Roland Keunings et Jean-Didier Legat. Cours de Pysique 1 FSAB 1201.
[13] Charles Pecher et Olivier Bonaventure. Cours d’informatique 1 FSAB 1401.
[14] Freedman R. and Young H. University Physics with Modern Physics, 13th Edition.
Pearson Education, 2009.

7 Annexes
7.1 Cahier des charges
Cahier des Charges
groupe: 11.76
Cahier des charges d'un robot qui joue au
basket
date: 03/12/12
version : 5
mise à jour
date origine
Contexte :
Le comité des Jeux Paralympiques veut introduire une nouvelle discipline pour
les Jeux de Rio : le « robot-basket ». Ce sport innovant s’inspire des règles et
de l’environnement du Basket-ball traditionnel. L’EPL a été choisie, ainsi que les
étudiants en première année de bachelier en sciences de l’ingénieur (orientation
civile), afin de promouvoir cette idée en imaginant un prototype participant.
18/10
18/10
18/10
18/10
Client
Client
Client
Client
Fonctions
1. Se déplacer de manière autonome sur le terrain.
2. Déterminer sa position, ainsi que la position de la balle, du
joueur adverse, et du panier de basket.
3. Attraper la balle, qu’elle soit à l’arrêt ou en mouvement (i.e.
la balle rebondi).
4. Lancer la balle (i.e. afin de marquer un panier).
13/11
18/10
18/10
21/11
18/10
18/10
18/10
18/10
13/11
Groupe
Groupe
Groupe
Groupe
Groupe
Groupe
Groupe
Groupe
Groupe
Performances
1.1 en cherchant la balle, s’il ne l’a pas déjà.
1.2 en évitant les chocs possibles avec les murs, le panier et
le robot adverse (et les obstacles éventuels).
1.3 à une vitesse maximale de 5 m/s.
1.4 il doit pouvoir atteindre sa vitesse maximale en 5 s (i.e. il
doit donc posséder une accélération de 1 m/s^2).
2.1 le robot détecte la balle dans un rayon de 3m autour de
ce dernier.
2.2 quant aux autres positions, il est capable de les
déterminer à tout moment (portée : 14,5 m de rayon).
3
3.1 si le robot adverse n’a pas la balle, il quadrille la zone
afin de la trouver.
3.2 a contrario, il se déplace vers l’adversaire afin d’obtenir
la balle (e.g. il essaie de faire tomber la balle ou de
gêner son tir).
4
4.1 distance de tir (i.e. afin de marquer) : entre 1 et 6m.
4
.
4
1

18/10
18/10
18/10
21/11
03/12
18/10
18/10
Groupe
Groupe
Groupe
Client
Groupe
Client
Groupe
Contraintes
6. Local : terrain de 2500x1400cm, hauteur 1000cm, panier à
300cm du sol ; accès direct par une double porte de
dimensions 160x200cm ; alimentation électrique : 230V-
50Hz.
7. Dimensions de la balle : 24 cm de diamètre, masse de 650g.
8. Aucune intervention humaine n’est permise durant les
différents temps de jeu réglementaire.
9. La batterie doit avoir une autonomie suffisante pour tenir
un quart temps (soit au moins 15 minutes : 10 minutes de
jeu, plus les éventuels temps mort et lancers-francs).
10. Le terrain est clos par du plexiglas d’une hauteur de 150cm.
Des portes, de mêmes dimensions que celles du local.
11. L’accès à la balle ne peut être obstrué à plus de 30% de sa
surface pendant plus de 5 secondes.
12. La balle ne peut être à plus de 200cm du sol pendant plus
de 5 secondes.

7.1.1 Choix des fonctions
Dans les tableaux qui suivent, la pondération va de 1 à 3 suivant l’importance du
critère et des points entre 1 et 5 sont mis a chaque solution la meilleure étant celle qui a
le plus de points au final.
Ramassage de balle
PPPPPPPP
P
Critères
Choix
PondérationBras articulé
Balais
tournants
RamassetteAspirateur
Prix 1 1 3 5 3
Complexité 3 1 4 5 3
Nombre de moteurs 2 1 5 4 4
Facilité de
saisie de la balle
3 3 5 2 5
Combinaison de
fonctions
1 5 1 1 1
Total 26 51 45 46
Grâce à ce tableau, on constate que le bras articulé n’a comme avantage que ça multi-
fonctionnalité, c’est à dire qu’il permet de capter et lancer la balle. Mais on se rend bien
compte qu’à côté de ça le bras est trop complexe et pas assez maniable. Pour le nombre de
moteurs, la ramassette est en dessous des balais tournants car ceux-ci sont couplés sur le
moteur des roues, avec un rapport de réduction, pour les faire tourner à bonne vitesse. La
ramassette, par contre, à besoin d’un moteur pour s’abaisser au moment de capter la balle,
car si elle restait tout le temps sur le sol, cela rajouterait trop de force de frottement. Les
balais tournant auront aussi une bonne facilité de saisie de balle car il suffit de se diriger
vers la balle pour que celle-ci soit directement envoyée dans un couloir, quelle que soit la
vitesse du robot. Le bras articulé lui a besoin de trop de précision, donc de temps et la
ramassette est plus risquée car le robot doit avoir une vitesse suffisante pour entrainer la
balle avec elle.
Détection
PPPPPPPP
P
Critères
Choix
Pondération
Enregistrement
du déplacement
Détection ligne Balises/Capteurs
Précision 3 2 3 5
Infrastructure 2 5 3 2
Prix 1 5 5 3
Complexité 3 5 4 2
Programme 2 2 4 4
infaillibilité 3 1 3 5
Total 43 49 51
Le plus important pour le matériel de détection, c’est qu’il soit fiable. Dans cette
optique, la précision et l’infaillibilité sont les critères les plus importants. Le problème de
la précision de l’enregistrement du déplacement est qu’il ne sait pas prendre en compte le

glissement des roues sur le sol. Il y a donc une perte de précision qui va devenir de plus
en plus grande durant le match. L’autre problème est qu’avec ce procédé, il est impossible
de calculer les déplacements du aux chocs causés par l’adversaire. Malgré que ce soit une
solution nécessitant aucune infrastructure peu complexe, on ne peut donc pas compter sur
l’enregistrement du déplacement.
La détection des lignes a aussi quelque souci dans la précision car lorsqu’il est entre deux
lignes, le robot ne connait pas sa position exact. Cette solution demande une infrastructure
car les lignes de bases d’un terrains de basket ne seraient pas suffisantes. Le système de
3 balises autour du terrain et d’un capteur dans chaque robot et dans la balle est donc
le choix le plus adapté pour localiser notre robot. Sa précision est maximal et puisque les
balises sont fixe, rien ne peut perturber leur fonctionnement et elles restent infaillible à
tout moment. Un problème est la complexité du matérielle nécessaire et l’infrastructure
que demande une telle installation. Le programme à implémenter n’est pas des plus simple
car des calcules sont nécessaire pour définir la position exacte du robot avec les données
des trois bornes.
Déplacement et orientation
PPPPPPPP
P
Critères
Choix
Pondération
2 roues motrices
et une roue folle
2 roues motrices
et deux roues di-
rectionnelles
2 chenilles
Prix 1 4 2 1
Mobilité (rayon
de braquage)
3 3 1 5
Puissance
nécessaire
2 4 3 2
Nombre de
moteur
3 3 3 3
Stabilité 2 4 3 5
Complexité 3 4 3 2
Résistance 1 3 3 4
Total 53 38 49
Le rayon de braquage d’un engin doté de 2 roues motrices et d’une roue folle est plus
petit que celui d’un engin doté de 2 roues motrices et de 2 roues libres. Cela est dû au
fait que la roue folle peut se mettre perpendiculairement aux roues motrices tandis que
les roues libres ne pivotent pas. Le rayon de braquage ne dépend donc que de l’angle que
les roues motrices balayent et cet angle est inférieur à 90◦. Mais c’est un engin doté de 2
chenilles qui à la meilleur mobilité car son rayon de braquage est nul de par le fait que son
centre de gravité ne bouge pas lors de la rotation. En effet si les deux chenilles tournent
dans le sens opposé, le robot fait un demi-tour parfait. La solution des 3 roues est plus
stable que celle des 4 roues car dans le premier cas, les forces sont nécessaires alors que
dans le deuxième, il y a un surplus de force, il s’agit d’un cas d’hyperstaticité. En rajoutant
une roue, une contrainte sera ajoutée.

Lancement de la balle
PPPPPPPP
P
Critères
Choix
Pondération
Canon à
air comprimé
Catapulte Bras articulé
Précision 3 5 2 2
Prix 1 2 4 1
Poids 2 4 2 5
Puissance
de tir
3 3 5 1
Stabilité 2 4 4 1
Nombre
de moteur
2 3 5 2
Total 53 51 27
Pour pouvoir mettre des paniers et marquer des points, ce qui reste le but premier
du basket, la précision des tirs est primordiale. On se rend donc déjà compte que le bras
articulé demande l’utilisation simultanée de trop de moteurs pour pouvoir être précis. En
plus de cela, pour tirer, le bras peut se désaxer assez fort et ainsi faire perdre de la stabilité
au robot. Si on y rajoute la complexité le prix et le nombre de moteur, rien ne va en la
faveur du bras articulé. La catapulte elle avait beaucoup d’avantages surtout du côté de
la simplicité mais cette qualité lui vaut aussi le défaut d’être peut manipulable et donc
d’avoir une précision assez faible. Au final c’est le canon à air comprimé la solution la plus
adaptée malgré quelque côté assez complexe.

7.2 Fiche technique de l’engin réel
Moteur
Puissance 150[W]
Rendement 91%
Nombre 2
Marque Maxon
Energie Electrique
Couple nominal 170 [mNm]
Vitesse nominale 6930 [m/s]
Compresseur aspirateur (avec tur-
bine comprise)
Puissance 7500 [W]
Air aspiré 0,036 [m3/s]
Nombre 1
Energie Electrique et motorisée (compres-
seur)
Dimensions 20x20x20 [cm] (pour les deux)
Masse 42 kg
Type Sur mesure. Référence : Mirage 130
(servant d’exemple de fabrication).
Alimentation électrique
Source Batterie
Type de batterie VARTA 2009 (Référence : 954 006
000)
Caractéristique 12 [V] 80 [AH]
Nombre de batterie(s) 2 (en série)
Transmission
Rapport de réduction 11.4375
Mode de déplacement roues
Nombre de roues 2 roues motrices et une roue folle

Matériaux
Plexiglas
Epaisseur [cm]
Parois latérales 1
Balcon 2
Canon 1
Couloir 1
Cheminée 1
Acier
Epaisseur [cm]
Paroi du haut 0.5
Paroi du bas 1
Ramassette 0.5
Armatures 2x2 (tige carrée)
Toit avant 2
Dimension [cm]
Longueur 120
Largeur 100
Hauteur (canon non compris) 80
Masse totale 305 [kg]
Performances
Vitesse maximale 4,783 [m/s]
Autonomie 900 [sec]
Force de frottement équivalent 122 [N]
Capteur
Système de détection Emetteur-Récepteur Ultrason
Type Balise (3)
Distance de détection 1-50 [m]
Nombre de capteur(s) 3

7.3 Descpription de la solution présentée durant l’avant-projet
Présentation de la solution
1. Description générale :
La solution choisie lors de l’avant-projet peut être décrite comme un parallélépipède
rectangle (presque cubique), composé essentiellement de plexiglas, avec une arma-
ture en aluminium, et constitué de deux parties : le corps du robot, surplombé par
le canon, qui se retrouve donc au dessus du corps principal. En prime, le robot com-
porte un toit avant en prévention d’un potentiel rebond de la balle, ainsi que d’un
balcon arrière afin d’y poser la balle en cas de déplacement, afin de ne pas enfreindre
les règles.
A l’intérieur du robot se trouve le couloir, amenant la balle de l’entrée du robot
jusqu’au balcon arrière, entouré par les salles des machines, c’est-à-dire les batteries,
moteurs et le bloc-mémoire. Afin de connecter le canon et l’entrée du balcon, un
tunnel en forme de cheminée rectangulaire permet cette liaison.
Quant à son déplacement sur le terrain, la présence de bornes à des endroits stra-
tégiques permet au robot de se situer aisément et à n’importe quel moment par
triangulation.
2. Spécifications techniques :
– Dimension
Les dimensions sont d’un mètre sur un mètre sur 0,8 mètres (roues et canon non
compris). Le canon a une hauteur de 0,7 mètres et un diamètre de 0,25m.
– Roues
Notre robot possède 3 roues, deux roues motrices avant de 0,2 mètres de diamètre,
et une roue libre à l’arrière de 0,075mètre pouvant pivoter à 360◦.
– Matériaux de construction
La structure générale sera en plexiglas d’une épaisseur de trois centimètres, le tout
assemblé grâce à une armature en aluminium.
– Canon
Le canon est situé sur le dessus à l’arrière du robot et propulsera la balle en direc-
tion du panier grâce à une forte pression d’air. Il a une inclinaison de 45◦ à 90◦.
– Toit avant
Le toit sert à empêcher la balle de rebondir une fois le robot à proximité de la
balle. Cela lui permettra d’attraper la balle plus facilement.
– Balcon arrière
Le robot va aspirer la balle et celle-ci sera attirée sur le balcon situé à l’arrière
du robot, une fois la balle sur le robot, une trappe à l’intérieur se fermera pour

empêcher la balle de se dégager de l’autre côté et permettant ainsi à la balle de
tomber lors des différents contacts avec les autres robots.
Celui-ci est équipé d’un détecteur, s’activant une fois que le robot est en bonne
position pour tirer. La balle sera alors redirigée vers le canon, et pourra être en-
suite propulsé.
– Boitier de commande
Le boitier de commande est situé de part et d’autre du couloir dans la carrosserie
et contient les différents moteurs, l’électronique et les batteries.
– Capteur
Des capteurs sont situés à des endroits clé sur le terrain et sont reliés au robot,
permettant ainsi au robot de toujours savoir où il se trouve sur le terrain et donc
pouvoir tirer au bon moment. Un interrupteur a pression est situé sur la balcon
afin de fermer la première porte côté couloir et un deuxième est situe juste après
le balcon dans le couloir (dans l’ascenseur) qui fermera les deux portes. Ces deux
interrupteurs ont une temporisation de 5 secondes.
– Batteries
Le robot est constitué d’une batterie se situant dans la carrosserie. Celle-ci a une
autonomie de 20 minutes (un peu plus d’un quart temps) et permet d’être changée
et chargée à chaque interruption.
– Moteurs
Notre robot contient deux moteurs pour les deux roues motrices, un moteur pour
les portes intérieures, un moteur pour l’ascenseur, deux moteurs pour le canon (un
pour l’inclinaison et un pour la propulsion). Il a donc 6 moteurs.
3. Dessin technique
4. Commentaire

Après la présentation de notre solution d’avant-projet, le groupe s’est bien rendu
compte de la médiocrité du travail fourni. D’une part lors de la rédaction rapide de
celui-ci, mais surtout lors de la présentation devant le jury.
Par exemple, on peut observer aisément cela dans la description de la solution et
des spécifications techniques, le travail fourni est sans aucun doute insatisfaisant : la
nonchalance et la procrastination dont a fait preuve tous les membres du groupe ont
conduit à ce travail rédigé « à la va-vite » ; l’exemple le plus flagrant est qu’il n’y a
presque aucun dimensionnement présent dans les spécifications techniques, chaque
catégorie n’étant que qualifié, et non quantifié.

7.4 Programme Java
1 /∗∗
2 ∗ Classe generale qui assemble toutes l e s autres :
3 ∗ e l l e i n i t i a l i s e l e s d i f f e r e n t s Behavior ,
4 ∗ l e s assemble dans un Arbitrator et l e demarre
5 ∗
6 ∗ @author Groupe 117.6
7 ∗ @version V1.0 − Novembre 2012
8 ∗/
9
10 import l e j o s . nxt . ∗ ;
11 import l e j o s . u t i l . Stopwatch ;
12 import l e j o s . r o b o t i c s . navigation . D i f f e r e n t i a l P i l o t ;
13 import l e j o s . r o b o t i c s . subsumption . Behavior ;
14 import l e j o s . r o b o t i c s . subsumption . Arbitrator ;
15 import l e j o s . r o b o t i c s . l o c a l i z a t i o n . OdometryPoseProvider ; // Sert pour
mapping
16 import l e j o s . r o b o t i c s . navigation . Pose ; // Sert pour
mapping
17 import l e j o s . geom . Point ; // s e r t pour
mapping
18 import l e j o s . nxt .comm. RConsole ; // Sert pour la
console
19 import javax . microedition . l c d u i . Graphics ; // Sert pour
d e s s i n s sur LCD
20
21 public c l a s s ROBOT {
22 // Global Data
23 public s t a t i c int rightAngle = 95; // Angle d r o i t
24 public s t a t i c int travelSpeed = 200; // Vitesse de deplacement
25 public s t a t i c int operationSpeed = 50; // Vitesse de manoeuvre
26 public s t a t i c int colorHigh = 50;
27 public s t a t i c int colorLow = −50;
28 // Field s p e c i f i c a t i o n s
29 public s t a t i c int sheetWidth = 840;
30 public s t a t i c int sheetHeight = 1189;
31 public s t a t i c int startHeight = 297;
32 public s t a t i c int heightM1 = −909; // Hauteur de la l i g n e M1
33 public s t a t i c int heightM2 = −739; // Hauteur de la l i g n e M2
34 // Robot s p e c i f i c a t i o n s
35 public s t a t i c double wheelDiameter = 56;
36 public s t a t i c double trackWidth = 136;
37 public s t a t i c int robotWidthMarge = 250; // Largeur du robot avec marge
38 public s t a t i c int robotCenterBack = 270; // Distance entre l e centre et
l ’ a r r i e r e ( avec marge )
39 public s t a t i c int robotCenterLight = 375; // Distance entre l e centre et
l e capteur ( avec marge )
40 public s t a t i c int robotCenterPince = 240; // Distance entre l e centre et
l e bout de la pince
41 public s t a t i c int robotCenterSonar = 55; // Distance entre l e centre et
l e sonar
42 public s t a t i c int pinceOperation = 180; // Vitesse de la pince pour
l e s manoeuvres
43 public s t a t i c int distanceToCatch = 50; // Distance que l e robot doit
avancer pour attraper la b a l l e
44 public s t a t i c int pinceAngleLow = 0; // Angle bas de la pince
45 public s t a t i c int pinceAngleHigh = 150; // Angle haut de la pince
46 public s t a t i c int pinceAngleTravel = 50; // Angle de la pince l o r s des
deplacements

47 public s t a t i c int pinceSpeedThrow = 450; // Vitesse de lancer de la
pince
48
49 public s t a t i c int isZoneHereDistance = 100;
50
51 // Variables
52 public s t a t i c int lightValue ;
53 public s t a t i c int i nv er sor = 0;
54 public s t a t i c int distanceLeft = 420; // Distance entre l e milieu de
la zone de depart et l e bord gauche
55 public s t a t i c int distanceRight = 420; // Distance entre l e milieu de
la zone de depart et l e bord gauche
56 public s t a t i c int distanceUn = 420;
57 public s t a t i c int distanceDeux = 420;
58 public s t a t i c int distanceMargin = 105;
59
60 // Console
61 public s t a t i c boolean useConsole = f a l s e ;
62 public s t a t i c String p r e f i x = ;
63
64 // Boolean pour a c t i v a t i o n des a r b i t r a t o r s
65 // Pour actionUn
66 public s t a t i c boolean l e f t B l a c k = f a l s e ; // Faux tant qu ’ i l n ’ a pas
quitte la zone de depart
67 // Pour actionUnBis
68 public s t a t i c boolean foundZone = f a l s e ; // Faux tant qu ’ i l n ’ a pas
trouve la zone de la b a l l e
69 //Pour actionUnTer
70 public boolean foundFirst ; // Devient f a l s e s i i l a
pas trouve la b a l l e du premier cote et true ausinon
71 // Pour actionDeux
72 public s t a t i c boolean hasBall = f a l s e ; // Faux tant qu ’ i l n ’ a pas
la b a l l e
73 // Pour actionTrois
74 public s t a t i c boolean readySearch = f a l s e ; // Devient true une f o i s
que l e robot est pret a chercher la l i g n e
75 // Pour actionQuatre
76 public s t a t i c boolean foundLine = f a l s e ; // Devient true une f o i s
que l e robot a trouve la l i g n e
77 // Pour actionCinq
78 public s t a t i c boolean ballThrown = f a l s e ; // Devient true une f o i s
que la b a l l e a ete lancee
79
80 // Objects D e f i n i t i o n
81 public s t a t i c D i f f e r e n t i a l P i l o t p i l o t ;
82 public s t a t i c LightSensor l i g h t ;
83 public s t a t i c UltrasonicSensor sonic ;
84 public s t a t i c OdometryPoseProvider pp ;
85 public s t a t i c Pose pose ;
86 public s t a t i c Stopwatch chrono ;
87
88 // Ports d e f i n i t i o n
89 public s t a t i c NXTRegulatedMotor leftMotor = Motor .A;
90 public s t a t i c NXTRegulatedMotor rightMotor = Motor .C;
91 public s t a t i c NXTRegulatedMotor pinceMotor = Motor .B;
92 public s t a t i c ADSensorPort lightPort = SensorPort . S1 ;
93 public s t a t i c I2CPort sonicPort = SensorPort . S4 ;
94
95 public s t a t i c void main ( String [ ] args ) {
96 p i l o t = new D i f f e r e n t i a l P i l o t ( wheelDiameter , trackWidth , leftMotor ,
rightMotor , true ) ;

97 l i g h t = new LightSensor ( lightPort ) ;
98 sonic = new UltrasonicSensor ( sonicPort ) ;
99 pp = new OdometryPoseProvider ( p i l o t ) ;
100
101 // I n i t i a l i s a t i o n de la console − c h o i s i r s i on l ’ u t i l i s e et la
lancer s i oui
102 i n i t i a l i z e C o n s o l e () ;
103
104 // Calibrage des couleurs
105 c a l i b r a t e () ;
106
107 // Methode pour determiner par ou i l commence a chercher la zone
108 s e t D i r e c t i o n () ;
109
110 p i l o t . setRotateSpeed ( operationSpeed ) ;
111 p i l o t . setTravelSpeed ( travelSpeed ) ;
112
113 // Creation des Behavior
114 Behavior actionUn = new actionUn () ;
115 Behavior actionUnBis = new actionUnBis () ;
116 Behavior actionUnTer = new actionUnTer () ;
117 Behavior actionDeux = new actionDeux () ;
118 Behavior actionTrois = new actionTrois () ;
119 Behavior actionQuatre = new actionQuatre () ;
120 Behavior actionCinq = new actionCinq () ;
121 Behavior emergencyRestart = new emergencyRestart () ;
122
123 // Assemblage des Behavior dans un tableau de taches
124 Behavior [ ] taches = {actionUnTer , actionUn , actionUnBis , actionDeux ,
actionTrois , actionQuatre , actionCinq , emergencyRestart };
125
126 console ( ~ Behaviors created nn , f a l s e ) ;
127
128 chrono = new Stopwatch () ; // Lancement du chrono
129
130 // Creation et demarrage de l ’ Arbitrator
131 Arbitrator a r b i t r e = new Arbitrator ( taches ) ;
132 a r b i t r e . s t a r t () ;
133 }
134
135
136 // Methodes pour la console ( i n i t i a l i s a t i o n et envoi de donnees )
137 /∗∗
138 ∗ Envoie l e texte passe en argument
139 ∗ − s o i t (1 e condition ) sur l ’ ecran LCD du robot uniquement s i on n ’
u t i l i s e pas la console ET qu ’ i l faut
140 ∗ l ’ a f f i c h e r sur l ’ ecran LCD s i i l n ’ a pas su etre a f f i c h e dans la
console ( boolean e l s e P r i n t = true )
141 ∗ − s o i t (2 e condition ) a la console uniquement s i on l ’ u t i l i s e (
boolean useConsole = true )
142 ∗
143 ∗ L ’ u t i l i s a t i o n de c e t t e fonction permet d ’ a f f i c h e r du texte par
bluetooth dans la console d ’un ordinateur
144 ∗ et a i n s i debuger et suivre l ’ avancement du programme en d i r e c t
t r e s facilement .
145 ∗
146 ∗ @pre : l e texte passe en argument est du texte valide
147 ∗ @post : renvoie 1 , 0 ou −1 en fonction de ce qu ’ i l est advenu du
message :
148 ∗ 1: i l a pu etre envoye a la console

Rapport final

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Rapport final

Similaire à Rapport final (20)

Rapport final