Rapport Cachan Teneo

Damien HABAS 18.01.
2018
Frank FACUNDO
Seydou DIA
Jonathan ANDRIEU
Anthony PAOLOZZI
Loïc CLAEYS
TENEO - Rapport Concours

Cachan Montpellier 2018
Global
Rapport de projet : Robot Cachan
TABLE DES MATIERES
PROLOGUE 3
INTRODUCTION 3
MODALITES 4
Terrain 4
Généralités 4
Cahier des charges 5
Règles du jeu 5
RÉALISATION 6
Organisation 6
Capteurs 6
Détecter la ligne 7
Différencier une ligne épaisse d’une ligne fine 7
Phase de test 9
Mise en forme du signal 10
Carte électronique 12
Objectifs pour la suite du projet 12
Traitement et support 13
Composants sur raspberry PI 13
Assemblage des parts 13
Installation de Linux Ubuntu Mate et des logiciels nécessaire 15
Raspberry, Ubuntu et python 17
Organigramme 18
Code réalisé 18
Code pour l’initialisation 18
Code pour la boussole 19
Code pour le moteur 20
Objectifs à court terme 21
Expérience issue des essais avec la Raspberry et des conseils de M. Vaillé 21
Actionneurs 22
Gestion de la balle 22
Premières idées 23
Analyse des besoins 23
Essais de projection 23
Ejection avec ressort 24
Choix de gestion de la balle retenu 24
HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 1

Essais servomoteur de trappe 25

Gestion des moteurs 25
CONCLUSION 26
ANNEXES 27
Nomenclature 27
Choix des résistances 28
Trigger de Schmitt 29

1. PROLOGUE
Le nom TENEO vient de l’ancien français. En effet, le tennis découle directement du
jeu de paume. L’apparition du tennis daterait des années 1850, c’est à dire plus de quatre
siècles après que les anglo-saxons aient découvert le jeu de paume. Par habitude les
joueurs annonçaient l’engagement en disant ‘Tenets !’ qui se traduit en français actuel par
‘Tenez !’. À cette époque les anglo-saxons ont mal entendu ce mot et ont compris ‘tenis’.
Ensuite ce mot est devenu ‘tennis’ comme on le connaît de nos jours et est repassé au
français. Le Concours Cachan étant un jeu de tennis évolué, nous avons décidé de nommer
notre robot ‘teneo’, l’infinitif de ‘tenets’.
2. INTRODUCTION
Ce rapport est un suivi de l’avancement du robot TENEO, à mi parcours, développé
par une équipe de Génie Électrique et Informatique Industrielle de Montpellier pour participer
au FRC (Festival Robotique Cachan) 2018. Ce festival organise une coupe des IUT GEII qui
rassemble 100 à 130 étudiants répartis dans toute la France. Cette coupe, initiée par le
Festival Robotique de Vierzon, est organisée par l’association ASTECH depuis 2002.
Pour cette nouvelle édition, le FRC a établi de nouvelles règles : les robots passent
au tennis. Le but des robots est d’envoyer un maximum de balles de tennis dans le camp
adverse, sans entrer dans le camp adverse et sans jamais contrôler plus d’une balle à la
fois. Malheureusement, ce changement d’objectif à été fait environ un mois et demi après le
début de la réalisation du projet. Il a donc obligé un redémarrage de nombre de réflexions et
essais.
Pour réaliser ce projet, nous constituons un groupe de 6 personnes en mettant à
profit les compétences et expériences : Anthony, Damien, Frank, Jonathan, Loïc et Seydou.
Nous nous sommes associés car nous sommes passionnés par la robotique et les
technologies.
Ce projet représente pour nous un challenge car nous utilisons une technologie que
nous n’avons pas encore étudiée lors de notre formation et dont nous avions tous envie de
découvrir.

3. MODALITES
3.1. Terrain
Les robots vont s’affronter sur un terrain de 8 x 4m. Soit un carré de 4 x 4m pour
chaque équipe. Il n’y a pas de filet qui sépare les deux parties. Des ballons de couleurs
seront répartis de chaque côté. Les ballons de baudruches sont fixés à 30cm du sol et à
10cm à l’extérieur du terrain. Les lignes au sol sont réalisées en scotch blanc et font 19mm
de large. Au centre, la ligne médiane fait 10cm de large avec une bande noire centrale de
19mm.
Figure 3.1.1 : aire de jeu du concours
3.2. Généralités
Les robots des anciennes et de la nouvelle version peuvent participer au concours.
En cas de non-respect le match est arrêté et le robot fautif perd.
Déroulement de la compétition : le robot vainqueur marque 2 points, 1, en cas de
match nul et 0 en cas de défaite.
Si le robot a totalement franchi la ligne de milieu de terrain le match est
immédiatement arrêté et le robot fautif est disqualifié. Les balles ne doivent pas être
éjectées hors du terrain. Toute balle éjectée hors du terrain entraîne une pénalité pour le
lanceur.
Le robot à 10 secondes une fois qu’il est immobilisé pour lancer un projectile de
faible masse dans l’air (avec un angle de 20° par rapport à la verticale). Cette action
déclenche l’ajout d’une balle dans le camp adverse.

3.3. Cahier des charges

Le robot doit avoir les dimensions suivantes : 40 x 30 x 30cm. Sa hauteur ne doit pas
dépasser 30 cm.
Le système pour propulser les balles ne doit présenter aucun danger pour le public
et les participants. Il ne doit pas endommager le terrain ni endommager ou altérer le
fonctionnement du robot/balises adverse.
Pour crever les ballons le robot est autorisé à sortir temporairement un dispositif de
son gabarit. Cependant il ne doit pas être déclenché à moins de 50cm du ballon. Il a les
mêmes contraintes que le dispositif d’expulsion de balles.
Le robot doit être autonome mais peut être communicants. La position de départ des
robots est la ligne de fond de court. Au bout de 90 secondes, le robot doit s’arrêter de
lui-même.
Il est possible de poser jusqu’à 3 balises qui peuvent communiquer avec le robot de
dimension maximale 20 x 20 x 20 cm3. Elles ne peuvent pas effectuer d’action et elles sont
fixes, autonomes et positionner dans son camp sur les supports de balises.
3.4. Règles du jeu

Des balles de tennis sont présentes en nombre variable sur la piste en début de
partie. Elles sont placées de façon pseudo aléatoire. Le but des robots est d’envoyer le
maximum de balles dans le camp adverse en moins de 90 secondes. Il ne peut pas entrer
dans le camp adverse et ni contrôler plusieurs balles à la fois. A la fin du temps
réglementaire, les robots doivent pouvoir s’arrêter. Le camp où on comptabilise le moins de
balles est déclaré vainqueur.

4. RÉALISATION
4.1. Organisation
Le projet peut se voir et se découper selon 3 axes. Comme tout projet de robotique,
nous avons séparé les capteurs, les actionneurs et le traitement intermédiaire. C’est de cette
façon que nous nous sommes répartis les tâches. C’est donc de la même manière que sera
axé la partie ‘réalisation’ de ce rapport.
4.2. Capteurs
Pour que le robot puisse se déplacer sans pouvoir être disqualifié, il doit être capable
de différencier les lignes fines des lignes épaisses pour ne dépasser la ligne du milieu de
terrain.
Nous sommes tout d’abord penché sur tous les cas de figure que pourrait rencontrer le robot
en s’approchant d’une ligne.
Sachant qu’une ligne épaisse fait 40mm de large et une ligne fine 19mm. Le robot
doit pouvoir les différencier quelque soit sa position relative à ces dernières.
Nous avons distingué trois cas de figure majeurs :
Il faut trouver une structure de capteurs qui permettent de détecter

les lignes dans un premier temps et de les différencier dans un
second temps.

4.2.1. Détecter la ligne
Nous choisissons un capteur infrarouge OBP704 ; Ce capteur fonctionne à l’aide

d’un phototransistor et d’une LED qui émet des rayons infrarouges. Lorsque qu’une ligne
blanche se trouve en-dessous du capteur les rayons sont réfléchis et ces derniers sont
captés par le phototransistor qui devient alors passant
Lorsque les rayons sont réfléchis le transistor

est fermé. La tension Vcapteur vaut alors 0V
dans le cas contraire Vcapteur vaut Vcc.
Remarque : Les rayons émis sont réfléchis

pour une distance supérieure ou égale à
5mm.
Rd=330Ω
Rt=47kΩ
Cf. annexe pour calcul
4.2.2. Différencier une ligne épaisse d’une ligne fine
Pour différencier les lignes nous avons mis au point un système de trois capteurs
infrarouges.
Ces capteurs sont positionnés de manière à ce que l’unique cas où les trois détectent une
ligne sera le cas où le robot est confronté à une ligne épaisse.
Les distances entre les capteurs ont été calculés de

manière à ce quelque soit l’angle du robot par rapport
à une ligne fine, seulement deux capteurs seront à
l’état haut.

Présentation des différents cas de figure pour une ligne fine :
cas 1
cas 2
cas 3
Si l’on rencontre une ligne épaisse alors l’intégralité des capteurs seront à l’état haut et cela
dans tous les cas de figure que l’on va rencontrer :
cas 4
cas 5
cas 6
Schéma du robot vue de haut (les capteurs ne sont pas schématisés à l’échelle) :

4.2.2.1. Phase de test
Pour tester notre système nous avons fait une mise en forme avec des comparateurs
Tout Ou Rien (TOR).
Nous avons comparé la tension fourni par le capteur avec une tension de 2.5V. Le circuit
suivant est alimenté en 5V.
Si un capteur détecte une ligne la sortie de l’AOP pas à l’état haut dans le cas contraire la
sortie est à l’état bas

Oscillogrammes des 3 AOPs :
Les trois capteurs détectent la ligne
Un des trois capteurs a détecté la ligne
Aucun capteur ne détecte la ligne
4.2.3. Mise en forme du signal
La Raspberry ne peut traiter que des informations logiques alors que le capteur nous
fournit une tension continue comprise en 0 et Vcc. Il faut donc faire une mise forme des
signaux. Pour cela nous utilisons un Trigger de Schmitt inverseur à seuil réglable. Le trigger
nous permet de travailler avec des signaux logiques mais nous donne aussi une marge de
sécurité. En effet l’environnement dans lequel va évoluer le robot est très perturbé et les
capteurs sont susceptibles de détecter des rayons infrarouges alors qu’il ne se trouve pas
confronté à une ligne.

Nous avons rajouté un AOP suiveur pour que les trigger de Schmitt ne se perturbent pas les
uns les autres.
Cf. annexe pour calcul

4.2.4. Carte électronique
Cf. Annexe pour nomenclature
4.2.5. Objectifs pour la suite du projet
En plus d’être capable de différencier les lignes fines des lignes épaisses, le robot
doit pouvoir détecter les murs, repérer les balles à ramasser, pouvoir se réorienter dans la
direction de la zone adverse et détecter les balises qui se situent au abords du terrain.
Au moment où ce rapport est écrit, le capteur que nous avons choisis est un
GP2Y0E02A (Cf. annexe). C’est un capteur infrarouge qui peut mesure une distance de 4 à

50 cm.
4.3. Traitement et support
4.3.1. Composants sur raspberry PI
- Pixy Camera
- Dissipateur pour la Raspberry PI
- Batterie portable 10400mAh - DC5V/2.4A max
- 16 GB Class 10 MicroSD
- Moteur Driver Adafruit
Le driver a les circuits suivants:
- PCA9685PW - I2C PWM
- TB6612FNG - DRIVER IC DUAL DC MOTOR
- 24C32 - EEPROM PROGRAMMER
- Câbles USB
- Stacking Headers
- Nylon Standoffs (M2.5) pour placer differents stages.
- Wireless Adapter 5GHz pour communication sans fils avec ordinateur.
4.3.2. Assemblage des parts
Tout d’abord nous avons collé les dissipateurs de la Raspberry, ensuite brancher la
carte microSD et finalement monter les “Nylon Standoffs”

Figure 2.1
Figure 2.2
Nous avons soudé les “stacking headers” Figure 2.3 avec le Driver Moteur Figure 2.4
Figure 2.3

Figure 2.4
Finalement on connecte le Driver Moteur et la Raspberry Pi.
4.3.3. Installation de Linux Ubuntu Mate et des logiciels

nécessaire
REMARQUE: Avant de commencer à expliquer la procédure, il est à savoir que toutes

les configurations, logiciels utilisés et exécution des lignes de commandes sont faits
sous Linux Ubuntu.
D’abord il faut télécharger le système d’exploitation depuis la page:
https://ubuntu-mate.org/download/
Ensuite il faut une image du système d’exploitation sur la microSD, pour cela, on exécuter la
commande:
$ sudo fdisk -l
Finalement on sélectionne notre carte microSD.
1. Une fois que l’image est sur la microSD, il faut vérifier que l’image du système a bien
été créée. Pour le savoir on vérifie les 2 partitions qui s’appellent “PI_ROOT” et
“PI_BOOT”
2. On branche la mémoire sur la Raspberry Pi pour booter.
3. Après avoir rempli toutes nos informations personnelles du robot “cachanmtp” on a

installé plusieurs logiciels, pour ce faire on exécute les commandes suivantes :
$ sudo apt update

$ sudo apt dist-upgrade

//On configure SSH, I2C et l’interface graphique

$ sudo raspi-config
Choisir “3. Interfacing Options”, et activer SSH, I2C.
Also disable graphical boot:
Choisir “2. Boot Options”, on configure option pour démarrage.
//Editor de textes
$ sudo apt install -y vim emacs byobu zsh
//”Monitor système processes”
$ sudo apt install htop atop nethogs iftop
//Libraries pour développer en Python
$ sudo apt install -y python-dev
//Libraries pour l’I2C
$ sudo apt install -y python-dev
//code pour installer driver de l’adaptateur sans fil
$ git clone git@github.com:duckietown/rtl8822bu.git
$ cd rtl8822bu
$ make
$ sudo make install
//Installation ROS
$ sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu
$(lsb_release -sc) main" > /etc/apt/
sources.list.d/ros-latest.list'
$ sudo apt-key adv --keyserver hkp://ha.pool.sks-keyservers.net:80
--recv-key
421C365BD9FF1F717815A3895523BAEEB01FA116
$ sudo apt update
$ sudo apt install ros-kinetic-desktop-full
$ sudo apt install
ros-kinetic-{tf-conversions,cv-bridge,image-transport,camera-info-man
ager,theora-image-transport,joy,image}
$ sudo rosdep init
$ rosdep update

4.3.4. Raspberry, Ubuntu et python
Nous avons choisi la carte Raspberry pour sa grande puissance, Quad-Core de

1.2Ghz et pour la grande quantité de librairies qui y sont développées.
Ubuntu parce qu’on peut utiliser le Robotic Operating System (ROS) qui a comme avantage
d’être multi-langages, dans notre cas nous allons coder en python qui est un langage de
programmation assez simple en syntaxe.
Cette partie est gérée par la Raspberry PI3 model B :
Figure 2.5
Sur la carte SD de la Raspberry se trouve un système d’exploitation libre Linux, la

distribution de Linux utilisé est Ubuntu 16.04 spécialement conçu pour Raspberry. C’est
grâce à cette interface graphique simple et intuitive qu’il est facile de programmer, ici en
python, directement sur la Raspberry. Cependant on utilise une connexion SSH pour
contrôler la carte directement depuis un autre ordinateur.
C’est donc ainsi que nous prévoyons de coder le programme visant à faire fonctionner les
moteurs, les capteurs ainsi que la balise et la boussole.

4.3.5. Organigramme
Figure 2.6
4.3.6. Code réalisé
4.3.6.1. Code pour l’initialisation
import RPi.GPIO as GPIO

import time
import Robot
Import hmc58831
GPIO.setmode(GPIO.BCM) #voir figure 2.7
GPIO.setup(20,GPIO.IN) #CAPTEUR
GPIO.setup(19,GPIO.IN)
GPIO.setup(26,GPIO.IN)
LEFT_TRIM = 0
RIGHT_TRIM = 0

Figure 2.7
La librairie RPI.GPIO sert à utiliser les ports de la Raspberry Pi, la librairie time nous
aide à gérer la PWM, Robot est la librairie qui permet d’utiliser le driver moteur, hmc58831
est le driver de la boussole, BCM est le type de nom des ports, et finalement on attribue le
capteur de ligne sur les ports 20,19,26.
4.3.6.2. Code pour la boussole
Pour la boussole nous avons dû installer plusieurs modules et bibliothèques.
Ø i2clibraries
Ø HMC5883libraries
Ces librairies rendent le dialogue avec la boussole plus simple. En effet les fonctions
présentes dans HMC5883libraries nous permettent de récupérer les données en quelques
lignes.
Cela dit la boussole renvoie 5 données :
Ø Sa position en x
Ø Sa position en y
Ø Sa position en z
Ø La déclinaison qui ne change jamais

Ø S
on orientation en degré minute
Voici le code qui nous permet de récuperer la valeur en degrés et minutes:
import time
Angle_numerique = hmc58831.getHeading()
4.3.6.3. Code pour le moteur
Pour adapter la vitesse des moteurs il faut tout d’abord être capable de la modifiée.
On agit sur les moteurs grâce aux au driver qui communique avec la Raspberry Pi par le
protocole I2C, mais si on regarde de plus près on a besoin de 4 ports : 2 pour l’I2C, 2 pour
I2C ID EEPROM. Pour la borne plus et la borne moins, rien de compliqué, la carte est prévu
pour inverser la tension PWM de puissance. Pour la PWM, Pulse Width Modulation, on va
modifier la largeur d’impulsion de notre signal pour faire varier la vitesse. Plus exactement,
on modifie le rapport cyclique.
Nous avons donc créé plusieurs fonctions utilisant ces 6 ports afin de pouvoir utiliser
toutes les fonctions des moteurs.
Ainsi lorsqu’un capteur détecte un obstacle il suffit d’appeler la fonction qui permet
de faire avancer le moteur mais en appliquant les rapports cycliques correspondant.
while True:
if GPIO.input(20) == GPIO.LOW:
robot.forward(255)
print("Il n’y a pas de ligne blanche")

if GPIO.input(20) == GPIO.HIGH:
robot.stop()
print("Ligne blanche detecte ")
GPIO.cleanup()
4.3.7. Objectifs à court terme

- Intégrer ROS et mesurer vitesse par cycle.
- Camera Pixie
- Balise
- Plus de capteurs
4.3.8. Expérience issue des essais avec la Raspberry et des

conseils de M. Vaillé
Le choix de l'unité de calcul dépend fortement de la nature de notre projet : ce qui est
la première chose à laquelle il faut penser.
Le Raspberry est un ordinateur miniature, sur lequel est installé un OS qui va faire
l'interface entre le matériel (entrées / sorties) et le soft que l’on veut faire tourner. Le point
positif, c'est que manipuler le matériel est simplifié, ensuite, c'est souvent au prix des
performances (tous les OS ne sont pas temps réel).
C'est effectivement bien adapté pour des projets assez haut niveau où l'on se
concentre sur des algorithmes un peu complexes, du traitement du signal massif, ou
éventuellement du réseau. De plus, les broches de la RPi sont des entrées / sorties
numériques il faut donc avoir un convertisseur analogique numérique, soit un PIC ou un
circuit spécialisé, qui fait l'interface avec certains capteurs / actionneurs en écrivant le driver
adapté ou en ayant des capteurs spécialement créés pour le Raspberry Pi.
Le problème étant que la Raspberry est plus adaptée pour des applications
majoritairement informatique mais pour faire de la robotique elle est beaucoup trop sensible
et est beaucoup trop lente avec l’OS (Operating System) que nous avons choisi « Ubuntu
Mate ». Car l’interface graphite est très gourmande en énergie et en ressources. Il nous
faudrait alors utiliser un OS plus léger et plus adapté à la robotique.
Une solution serait, de programmer la Raspberry en SSH sans interface graphique à
charger et de ne pas programmer en Python comme nous le faisons. Le langage Python est
un langage interprété contrairement au langage C qui est un langage compilé et donc plus
rapidement interprétable par un processeur.
Par ailleurs, on ne peut pas faire d’interruptions en temps réel par soucis de gestion
du temps car il nous faudrait sauvegarder le contexte, charger l’interruption, exécuter
l’interruption et recharger le contexte. Il nous faudrait gérer en parallèle plusieurs tâches :

c’est le multitâches. Et découper les tâches les plus longues et faire une machine à états par
exemple.
Alors, nous pourrons aussi utiliser un Pic18 ou 32 avec un OS temps réel comme
FreeRTOS et développer sur MpLAB Harmony qui prend en charge les RTOS et propose
des librairies et services pour les systèmes embarqués.
4.4. Actionneurs
4.4.1. Gestion de la balle
Cette partie du rapport relève de la mécanique. C’est à dire la structure, le châssis

sur base duquel le robot TEINO à été développé ainsi que la partie gérant la balle de tennis.
La récupération, gestion et éjection de la balle était donc la principale tâche.
Avant de rentrer directement dans le vif du sujet nous avons commencé par en parler tout
autour de nous pour acquérir le maximum d’idée en terme de stratégie. En effet, la stratégie
globale dépendait des contraintes imposées sur tous les domaines du robot : les capteurs,
les dimensions, le software, notre temps, nos capacités, etcaetera. Une vision d’ensemble
aussi sommaire fût-elle était donc nécessaire pour démarrer les réflexions sur la partie
mécanique.
D’après la forme du terrain et les règles du jeu, nous savons qu’il faut envoyer les
balles dans une direction particulière le plus rapidement possible. Ci-dessous un schéma de
l’arène.

4.4.1.1. Premières idées

Nous avons dès le début pensé à plusieures solutions spontanément puis nous
avons effectué des recherches sur les différentes méthodes similaires. La projection de balle
en générale est un cas classique de mécanique et particulièrement de balles de tennis.
Nous nous sommes donc inspirés des appareils de projection de balles de tennis placés sur
les terrains pour l’entrainement ainsi que des appareils manuels pour envoyer des balles à
des chiens. Un document annexe nommé ‘idees_projection_balle’ au rapport présent
contient les pistes que nous avons envisagées à priori.
4.4.1.2. Analyse des besoins

Après avoir réfléchi aux différentes possibilités pour gérer la balle de tennis, il
devenait nécessaire de faire des essais pour évaluer les forces à appliquer afin d’envoyer la
balle de l’autre côté du terrain.
La réflexion était donc la suivante. La distance minimale à laquelle le projecteur doit
être capable d’envoyer la balle est la diagonale d’un demi-terrain environ. Le terrain total
mesurant 8 m par 4 m, cette diagonale est égale à 4 * √2 = 5.7 m . Si nous envoyons la balle
de tennis trop loin nous risquions de la voir ricocher sur un bord adverse et revenir dans
notre camp.
4.4.1.3. Essais de projection

Pour pouvoir connaître l’énergie suffisante nécessaire à l’envoi d’une balle de tennis
à la distance idéale évaluée à 5.7 m environ, l’expérience s’imposait. La difficulté est de tenir
compte de la manière dont on propulse la balle. En effet, si la balle est frappée brutalement,
elle subit une déformation dont il aurait fallu tenir compte. Pour éviter de prendre en compte
ce genre de paramètre nous nous sommes focalisés sur la vitesse initiale nécessaire.
Pour obtenir l’information de vitesse initiale nous avons donc frappé une balle de
tennis standard sur un échantillon de moquette réglementaire d’au moins 5.7 m. En filmant
le premier mètre nous avons pu analyser la vidéo avec un logiciel adéquat (cela peut
fonctionner simplement avec VLC Media Player en mode image par image). De cette
manière, à partir d’un moyennage des première positions et instants, nous avons évalué
approximativement la vitesse initiale. La vidéo se trouve en complément dans le dossier
sous le nom ‘video_cinematique_balle_5m’.
La vidéo a été prise à 30,15 images par secondes donc on peut aisément obtenir le résultat
de la manière suivante :

v initiale ≃ 1m
14 images ≃ 1m
0.5 s ≃ 2 m.s −1
La vitesse initiale retenue a donc été celle-ci.
4.4.1.4. Ejection avec ressort
Nous avons pensé dans un premier temps d’éjecter la balle avec un système de
ressort. Une fois la balle coincée dans la cage et le robot bien orienté vers sa cible, un
piston se déploie et permet d’éjecter la balle. Le piston serait tendu et détendu par un petit
moteur. Le désavantage de cette solution est de dimensionner le ressort. En effet si le
ressort fournit une force trop importante la balle risque de rebondir, et inversement la balle
ne pourrait pas avancer.
4.4.1.5. Choix de gestion de la balle retenu
Il est évident que le robot entier, s’il ne gère pas la balle n’est d’aucune utilité. Étant
donné que nos domaines de compétences ne s’étendent pas jusqu’à la mécanique nous
nous sommes décidés à opter dans un premier temps pour une solution simple et sans
faille. Nous avons donc choisi de n’utiliser aucun mécanisme de projection de la balle au
début, quitte à optimiser ou même changer le système de gestion de balle une fois le projet
bien avancé.
La solution choisie se décompose en plusieurs étapes. Premièrement, la balle sera
saisie avec une trappe en rotation autour d’un axe vertical, qui sera commandée par un
servomoteur. De cette façon, la balle sera piégée dans la cage du robot. Deuxièmement,
nous nous servons de la mobilité du robot pour se diriger vers le camp adverse. De cette
façon, avec l’élan donné à la balle, l’ouverture de la trappe suivie de l'arrêt du robot avant la
ligne de séparation, permet à la balle de continuer son chemin dans le camp adverse. Le
robot peut alors réitérer autant de fois qu’il y a de balle.
Le mécanisme qui permet de réaliser cette opération est concus et en cours de
fabrication. Des version plus efficaces suivront probablement.
Les essais sur le servomoteur qui servira à la rotation de la trappe son élémentaires et
donnent les résultats situés dans le paragraphe dédié.

4.4.1.6. Essais servomoteur de trappe
Cette partie concerne les tests effectués pour l’emploi d’un ou deux servomoteurs
pour l’ouverture de la trappe du “récolteur” de balle.
La référence est . Ils sont alimentés en 5V et sont tolérants pour l’amplitude du signal
d’entrée donc c’est compatible avec l’utilisation des sorties GPIO de la raspberry si le choix
est à faire. Le signal de commande est une MLI de 2ms de période. Le temps à l’état haut
restera à fixer en fonction de l’angle souhaité pour l’ouverture de la trappe.
4.4.2. Gestion des moteurs

Nous avons procédé à des tests moteurs afin de connaitre ses caractéristiques. Ces
caractéristiques sont primordiales pour choisir le driver moteur, l’occurrence un L293D. Nous
devons utiliser un driver car l’inconvénient de la raspberry et qu’elle fournit par broche
seulement 50mA et 3,3V. On a alimenté le moteur sous 12V pour mesurer son courant
nominal et son courant de court-circuit. On mesure In = 334 mA et Icc (en bloquant le
moteur) = 550 mA.
A l’aide du raspberry, on configure le driver de moteur pour avoir une tension variable
de 0 à 5V. De ce fait on pourra lancer un programme permettant de faire varier la PWM et
on pourra mesurer la tension aux bornes du moteur.
On a une caractéristique linéaire et proportionnelle avec une pente de 0,05. La tension de

sortie (donc la vitesse du robot) dépend du signal PWM.

5. CONCLUSION
Le robot Cachan a la particularité cette année de ne pas être un robot esquiveur

d’obstacle mais un ramasseur de balle. Nous sommes donc les premiers étudiants à
travailler dessus.
Le projet à été difficile car au mois de Novembre le concours a complétement changé
ses règles et nous avons dû réaliser un tout autre robot. Nous étions déjà bien avancés sur
le robot esquiveur d’obstacles lorsque les professeurs nous ont informé de ce changement
de cap.
L’apprentissage de la communication et de la répartition des tâches fut un point clé
du déroulement du projet. En effet nous étions six à rapidement s’organiser pour atteindre
un but commun. Par exemple ceux responsables de la partie analogique devaient
constamment échanger avec ceux responsables du software pour que le traitement de
l’information soit le plus adapté.
Durant le projet nous nous sommes vite rendus compte qu’il y aurait un compromis à
faire entre nos ambitions et le robot final. En tant qu’étudiants nous n’avions pas conscience
des ressources que demandait la réalisation d’un tel projet. Faute d’expérience, il a fallu se
lancer pour comprendre ce que représentait de mettre en œuvre un robot de cette ampleur.
Ce projet à la particularité d’être encore en cours de la réalisation au moment où ce
rapport est écrit. Ce dernier avait pour but de faire état de notre avancement et de nous
rendre compte des étapes qu’ils nous restent à faire. De cette manière la première partie du
projet nous a donc servi au titre d’une expérience à part entière.

6. ANNEXES
6.1. Nomenclature
Repère Quantité Désignation (valeurs, puissance, techno, etc) Boîtier (référence)

R1, R3, 3 Résistance de 330
R5
R2,R4,R6 3 Résistance de 47k
R9,R10,R 3 Résistance de 220k

11
R7,R8,R1 5 Résistance de 22k
2,R13,R1
4
JP1,JP2 2 Connecteur MHDR1X8
U1 1 Résistance de 1k LM324
I.U.T. de Montpellier Dépt G.E.I.I. 2ème année Groupe :

Projet : Robot Cachan 2018 Auteur :M.Paolozzi
Date :17/01/2018
Sous-ensemble :Projet tuteuré Vérification: Effectuée
Auteur :DIA
NOMENCLATURE Date : 17/01/2018

6.2. Choix des résistances

6.3. Trigger de Schmitt

Rapport Cachan Teneo

Transféré par

Droits d'auteur :

Formats disponibles

Rapport Cachan Teneo

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Cachan Teneo

Transféré par

Droits d'auteur :

Formats disponibles

Damien HABAS 18.01.

TENEO - Rapport Concours

TABLE DES MATIERES

​HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS​ ​ 1

Essais servomoteur de trappe 25

​HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS​ ​ 2

​HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS​ ​ 3

Figure 3.1.1 : aire de jeu du concours

​HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS​ ​ 4

3.3. Cahier des charges

3.4. Règles du jeu

​HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS​ ​ 5

Nous avons distingué trois cas de figure majeurs :

Il faut trouver une structure de capteurs qui permettent de détecter

​HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS​ ​ 6

4.2.1. Détecter la ligne

Nous choisissons un capteur infrarouge OBP704 ; Ce capteur fonctionne à l’aide

Lorsque les rayons sont réfléchis le transistor

Remarque : Les rayons émis sont réfléchis

4.2.2. Différencier une ligne épaisse d’une ligne fine

Les distances entre les capteurs ont été calculés de

​HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS​ ​ 7

Présentation des différents cas de figure pour une ligne fine :

​HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS​ ​ 8

4.2.2.1. Phase de test

​HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS​ ​ 9

Oscillogrammes des 3 AOPs :

Les trois capteurs détectent la ligne

Un des trois capteurs a détecté la ligne

Aucun capteur ne détecte la ligne

4.2.3. Mise en forme du signal

​HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS​ ​ 10

Cf. annexe pour calcul

​HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS​ ​ 11

4.2.4. Carte électronique

Cf. Annexe pour nomenclature

4.2.5. Objectifs pour la suite du projet

​HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS​ ​ 12

4.3. Traitement et support

4.3.1. Composants sur raspberry PI

4.3.2. Assemblage des parts

​HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS​ ​ 13

​HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS​ ​ 14

Finalement on connecte le Driver Moteur et la Raspberry Pi.

4.3.3. Installation de Linux Ubuntu Mate et des logiciels

REMARQUE: Avant de commencer à expliquer la procédure, il est à savoir que toutes

D’abord il faut télécharger le système d’exploitation depuis la page:

Finalement on sélectionne notre carte microSD.

2. On branche la mémoire sur la Raspberry Pi pour booter.

3. Après avoir rempli toutes nos informations personnelles du robot “cachanmtp” on a

$ sudo apt update

​HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS​ ​ 15

//On configure SSH, I2C et l’interface graphique

​HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS​ ​ 16

4.3.4. Raspberry, Ubuntu et python

Nous avons choisi la carte Raspberry pour sa grande puissance, Quad-Core de

Sur la carte SD de la Raspberry se trouve un système d’exploitation libre Linux, la

​HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS​ ​ 17

4.3.6. Code réalisé

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 1

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 2

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 3

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 4

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 5

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 6

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 7

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 8

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 9

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 10

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 11

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 12

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 13

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 14

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 15

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 16

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 17

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 18

Ø La déclinaison qui ne change jamais

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 19

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 20

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 21

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 22

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 23

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 24

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 25

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 26

Repère Quantité Désignation (valeurs, puissance, techno, etc) Boîtier (référence)

I.U.T. de Montpellier Dépt G.E.I.I. 2ème année Groupe :

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 27

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 28

HABAS FACUNDO DIA ANDRIEU PAOLOZZI CLAEYS 29