Dossier Developpement RobAFIS 2013 Collegium IDF

Robos’πR

Équipe Collegium Île-de-France

À l’attention du comité d’organisation du concours RobAFIS 2013

CONCOURS ROBAFIS 2013

TABLE DES MATIÈRES

Introduction 5

1 Définition des exigences 61.1 Description générale du système (LOT 11) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.1.1 Finalité, mission et objectifs du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.1.2 Contexte organique du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1.3 Contexte fonctionnel du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2 Document des exigences techniques (référentiel d’exigences) (LOT 12) . . . . . . . . . . . . . . 91.2.1 Exigences fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2.2 Exigences de performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2.3 Exigences d’interfaces (fonctionnelles, physiques) . . . . . . . . . . . . . . . . . . . . . . 91.2.4 Exigences opérationnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2.5 Contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2.6 Exigences de validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Dossier de conception architecturale du système en sous-systèmes 122.1 Description générale (LOT 21) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.1 Système de préhension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.2 Système de déplacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.3 Appréhension de l’environnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.4 Modélisation en 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.5 Outil et langage de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Architecture fonctionnelle et comportementale (LOT 22) . . . . . . . . . . . . . . . . . . . . . . 162.2.1 Arborescence fonctionnelle statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.2 Architecture fonctionnelle et dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Architecture organique/physique (LOT 23) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.1 Arborescence organique/physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.2 Architecture organique/physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4 Moyens consommés, utilisés, produits (LOT 24) . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5 Interfaces (LOT 25) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5.1 Définition des interfaces externes au système . . . . . . . . . . . . . . . . . . . . . . . . . 212.5.2 Définition des interfaces internes au système . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.6 Description fonctionnelle et organique des sous-systèmes (LOT 26) . . . . . . . . . . . . . . . . 232.6.1 Système de préhension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.6.2 Système de contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.6.3 Système de déplacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.6.4 Système d’orientation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.6.5 Système de détection des obstacles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.6.6 Système de détection de l’élément . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.6.7 Système châssis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2

3 Configuration de référence (LOT 30) 293.1 Nomenclature de la solution validée et retenue . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2 Schéma général d’interconnexion électrique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3 Schéma de la chaîne cinématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4 Instructions d’identification du système et de ses constituants . . . . . . . . . . . . . . . . . . . 32

4 Dossier justificatif (LOT 40) 334.1 Dossier justificatif du choix de l’architecture retenue (LOT 41) . . . . . . . . . . . . . . . . . . . 33

4.1.1 Système de déplacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.1.2 Système de préhension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1.3 Système d’orientation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.1.4 Système de détection de l’élément . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.1.5 Système de détection des obstacles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Dossier justificatif de la conception (LOT 42) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.1 Exigences fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.2 Exigences de performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.3 Exigences d’interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.4 Exigences opérationnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Plan d’intégration vérification validation (LOT 50) 445.1 Plan d’intégration mécanique et électrique du système . . . . . . . . . . . . . . . . . . . . . . . 445.2 Plan de vérification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.3 Plan final de validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.3.1 Plan de validation au niveau du système complet . . . . . . . . . . . . . . . . . . . . . . 465.3.2 Plan de validation des exigences réglementaires . . . . . . . . . . . . . . . . . . . . . . . 48

6 Dossier d’étude de maintenabilité - Définition de la maintenance 496.1 Dossier d’études de maintenabilité (LOT 61) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.2 Plan de maintenance (LOT 62) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.3 Fiches de maintenances (LOT 63) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.4 Validation du plan de maintenance (LOT 64) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7 Management du projet 587.1 Organisation et suivi de projet (LOT 71) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.1.1 Organisation au sein de l’équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.1.2 Répartition du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.1.3 Jalons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597.1.4 WBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597.1.5 Bilan des points d’avancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617.1.6 Compte rendu de revue interne de fin de développement . . . . . . . . . . . . . . . . . . 62

7.2 Pilotage par la qualité, les coûts et les délais (LOT 72) . . . . . . . . . . . . . . . . . . . . . . . . 627.2.1 Études d’analyse de la valeur réalisées relatives au coût du produit et au coût de son

développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627.2.2 Courbe d’évolution du développement en homme/jour . . . . . . . . . . . . . . . . . . 627.2.3 Courbe d’évolution du coût unitaire du robot . . . . . . . . . . . . . . . . . . . . . . . . 63

7.3 Management des risques (LOT 73) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

8 Dossier de réalisation (LOT 80) 668.1 Synoptique général du montage et de contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668.2 Description de l’organisation des postes de montage et de contrôle . . . . . . . . . . . . . . . . 67

8.2.1 Gamme de montage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678.2.2 Gamme de contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688.2.3 Définition des moyens prévus pour le chargement du logiciel . . . . . . . . . . . . . . . 68

A Diagrammes d’exigences 69A.1 Exigences fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70A.2 Exigences de performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71A.3 Exigences d’interfaces (fonctionnelles, physiques) . . . . . . . . . . . . . . . . . . . . . . . . . . 71A.4 Exigences opérationnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72A.5 Contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73A.6 Exigences de validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

B Tests 75B.1 Vérification de sûreté de saisie (T01) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75B.2 Comparaison de la précision du suivi de ligne entre 1 et 2 capteurs au sol (T02) . . . . . . . . . 75B.3 Détection de la couleur pour balles en fonction de la position du capteur optique (T03) . . . . . 76B.4 Test de seuil de détection du capteur de couleur (T04) . . . . . . . . . . . . . . . . . . . . . . . . 76B.5 Test de la précision de fonctionnement du sonar (T05) . . . . . . . . . . . . . . . . . . . . . . . . 77B.6 Test de la précision du sonar installé sur le robot (T06) . . . . . . . . . . . . . . . . . . . . . . . . 77B.7 Test de détection effective d’obstacles avec le robot (T07) . . . . . . . . . . . . . . . . . . . . . . 78

C Guide de montage 80

Références 99

Page 4/101

INTRODUCTION

L’édition 2013 du concours RobAFIS aura marqué la première participation du Collegium Île-de-France. LeCollegium n’est pas une mais 3 grandes écoles d’ingénieurs avec chacune son domaine d’expertise :

– l’EISTI pour les technologies de l’information ;– l’ENSEA pour l’électronique ;– SUPMECA pour la mécanique.

L’équipe Collegium est composée de 10 étudiants et 5 encadrants. Les groupes de chaque école ont puapporter, de par leurs formations, des méthodes, des approches et des sensibilités différentes. Une tellerichesse s’est révélée être un défi pour la collaboration entre élèves-ingénieurs, mais elle a surtout constituéune formidable opportunité et un espace de partage. Chacun a pu apprendre de l’autre et progresser enacquérant de nouvelles compétences à la fois techniques et humaines.

Ces 11 semaines de travail auront permis de mener à son terme un projet conséquent, rendu possiblepar l’implication de tous les membres de l’équipe Collegium. Cette expérience aura montré les vertus de lacoopération entre ingénieurs de formations différentes au service de l’ingénierie système. En effet, le projeta été soutenu par PLACIS, une des Initiatives d’Excellence en Formation Innovante, labellisées par l’ANR(Agence Nationale de la Recherche) en 2012. PLACIS a pour ambition de promouvoir l’ingénierie système etde sensibiliser les futurs ingénieurs, toutes formations confondues, à l’intérêt d’apprendre à collaborer autourde projets nécessitant des ingénieurs de tous corps de métiers.

Finalement, nous souhaitons remercier tous les participants et les nombreuses personnes qui nous aurontsoutenu tout au long de cette aventure, amis, professeurs, et parfois les deux en même temps.

Tuteur : Pierre VINTER

Liste des participants :Pierre SUDRON (chef de projet), Jeremie BIALOWAS, Baptiste BOIROUX, Juliette BOUCLIER, Johanna EL-BEZE,Alexandre FUGIER, Thomas PAPILLON, Kevin PIRES, Flavien RAYNAUD, Frédéric TORCHEUX

Encadrants pédagogiques :Zoubeida ABDELMOULA, Antoine BRUNNER, Yimeng DONG, Nga NGUYEN

Page 5/101

CHAPITRE 1

DÉFINITION DES EXIGENCES

1.1 Description générale du système (LOT 11)

1.1.1 Finalité, mission et objectifs du systèmeCette section rappelle les éléments de cahier des charges applicables au Système RobAFIS :

Finalité Tous les éléments de l’atelier de production de la société ManAFIS doivent être triésselon leurs couleurs

MissionsTrier les éléments

de façon automatiséeTransporter les éléments

Stocker les éléments

Objectifs

Se déplacer à un stock d’entrée (transtockeur ou stock partagé d’entrée)

Regarder la présence ou non d’éléments

Saisir l’élément

Déterminer la couleur (si présence d’élément)

Se rendre au stock (d’arrivée ou d’échange) selon la couleur de l’élément

Déposer l’élément

Revenir en position d’attente quand le transtockeur et le stock partagé d’entrée sontvides

Page 6/101

1.1.2 Contexte organique du systèmeCette section présente, sous forme graphique, les objets constituant le contexte d’utilisation en liaison avec

le système étudié et leurs liens physiques. Un diagramme de blocs internes de SysML a été utilisé pour décrireles différents objets, ainsi que les connexions et les flots envoyés entre ces objets.

L’utilisation de SysML s’est naturellement intégrée dans la méthodologie imposée par l’AFIS pour ce projet.Par conséquent, nous avons pu profiter du formalisme fort pour modéliser toutes les facettes du système,et ainsi maintenir la rigueur nécessaire pour mener à terme le projet. Ce choix s’est révélé judicieux, car lesmembres de l’équipe avaient tous reçu (dans leurs établissements respectifs) une formation à SysML. Cela adonc fortement amélioré la cohésion de groupe.

Page 7/101

1.1.3 Contexte fonctionnel du systèmeLes différents schémas représentent les flux d’entrées et de sorties entre les fonctions des objets du contexte

et la fonction ou mission du système étudié comme indiqués ci-dessous.

Page 8/101

1.2 Document des exigences techniques (référentiel d’exigences) (LOT12)

1.2.1 Exigences fonctionnellesLes exigences complexes seront décomposées en exigences simples.

EFO1 Le système doit exécuter la mission en fonction du paramètre p.

EFO2 Le système doit agir de manière autonome.

EFO3 Le système doit aller chercher les pièces dans les zones de stockage.

EFO31 Le système doit suivre les lignes tracées au sol.

EFO32 Le système doit détecter la couleur de la pastille.

EFO33 Le système doit utiliser les pastilles de couleur comme indicateur de changement de directionou de positionnement.

EFO4 Le système doit s’occuper des pièces dans le SPE de manière prioritaire.

EFO5 Le système doit détecter la présence ou l’absence d’un élément.

EFO6 Le système doit saisir un ou plusieurs éléments.

EFO7 Le système doit analyser la couleur de l’élément.

EFO8 Le système doit être capable de stocker un ou plusieurs éléments.

EFO9 Le système doit acheminer les bonnes pièces dans les bonnes zones.

EFO91 Le système doit amener tous les éléments de sa couleur dans son stock d’arrivé SA.

EFO92 Le système doit amener tous les éléments de l’adversaire dans le stock partagé de départ SPD.

EFO10 Le système doit être capable de lâcher une ou plusieurs pièces.

EFO11 Le système doit revenir dans la zone de départ une fois la mission accomplie.

Un diagramme SysML est disponible pour ce jeu d’exigences : figure A.2 des annexes

1.2.2 Exigences de performance

EPE1 Le système doit réaliser la mission en moins de temps possible.

EPE2 Le système doit réaliser la mission dans un délai prescrit de 4 minutes.

EPE3 Le système doit réaliser la mission sans dépasser 6 minutes.

EPE4 Le système doit prendre en compte la pièce en attente dans le SPE avant undélai de 2 minutes après l’apparition de celle-ci.

EPE5 Le système doit être capable de réaliser 3 missions successives sur une périodede service maximale de 4 heures.


1.2.3 Exigences d’interfaces (fonctionnelles, physiques)

EIN1 Le système doit télécharger son programme par moyen de communicationUSB ou Bluetooth.

EIN2 Le système doit être mis en marche manuellement.

EIN3 Le système doit être capable de recevoir le paramètre p de la mission.

EIN4 Le système doit pouvoir être relancé par l’opérateur de l’équipe.


Page 9/101

1.2.4 Exigences opérationnelles

Modes opérationnels et scénarios opérationnels

EOP1 Le système doit posséder un mode d’essai de mise au point et de vérificationfonctionnelle in situ.

EOP2 Le système doit posséder un mode veille.

EOP3 Le système doit posséder un mode opérationnel.

EOP4 Le système doit être capable de redémarrer.

EOP5 Le système doit avoir un mode de maintenance.

Exigences d’ergonomie

EER1 Le système doit être préhensible manuellement.

Exigences de sûreté de fonctionnement

ESF1 Le système doit s’arrêter en cas d’obstacle sur son chemin.

Exigences d’environnement opérationnel

EEO1 Le système doit pouvoir évoluer dans une plage de température compriseentre 10oC et 32oC.

EEO2 Le système doit pouvoir évoluer sous une pression atmosphérique compriseentre 1000 et 1030mb.

EEO3 Le système doit pouvoir évoluer dans un taux d’humidité entre 40% et 75%.

EEO4 Le système doit pouvoir se déplacer sur une surface parfaitement plane ethorizontale, rigide, avec une surface dure et de couleur claire uniforme.

Exigences de stockage et de transport

EST1 Le système doit pouvoir être transporté de Paris à Nîmes.

EST2 Le système doit pouvoir être stocké entre les missions.

Exigences de maintenance

EMA1 Le système doit être maintenable.

EMA2 Après la maintenance, le système doit pouvoir reprendre sa mission à l’en-droit où il s’est arrêté ou à l’endroit où il a quitté la piste.


1.2.5 Contraintes

Contraintes de conception et de réalisation

CCR1Le système doit être conçu par des étudiants ou membres de clubs ou asso-ciations des Universités et Grandes Écoles francophones de niveau bac+3 àbac+6 dans une discipline d’ingénierie.

CCR2 Le système doit être développé pour le 18 novembre au plus tard.

CCR3 Le système doit être développé et réalisé uniquement avec des constituantsappartenant au kit fourni par l’AFIS.

CCR4 Le système doit être piloté à partir de l’outil de programmation du kit princi-pal ou d’une programmation basée sur les langages C ou JAVA.

Page 10/101

Contraintes physiques (dimension)

CPH1 Le système doit pouvoir tenir dans un cube de 300mm x 300mm x 300mmlorsqu’il se trouve au repos.

Contraintes de mise en service, de montage

CMS1 Le système doit être assemblable en moins de 20 minutes.

Contraintes de maintenance

CM1 Le système doit être maintenable en moins de 5 minutes.

CM2 Le système doit être reconstruit conformément à l’assemblage d’origine.

CM3 Le système doit être vérifiable par un test automatique complet.

CM4 Le système doit posséder un logiciel interne rechargeable.

CM5 Le système doit être maintenable sur le lieu de l’incident technique.

Contraintes de retrait de service

CRS1 Le système doit être démontable.


1.2.6 Exigences de validation

EVA1 Le système subit une phase d’audit de configuration.

EVA2 Le système subit une phase de validation opérationnelle.


Page 11/101

CHAPITRE 2

DOSSIER DE CONCEPTIONARCHITECTURALE DU SYSTÈME EN

SOUS-SYSTÈMES

2.1 Description générale (LOT 21)

Pour arriver à la version finale de notre robot, nous avons dû faire un certain nombre de choix deconception. Cette section a pour objectif de présenter brièvement les solutions écartées et la solution retenue. Ils’agit de choix de solutions pour le système de préhension, le système de déplacement, l’appréhension del’environnement, l’outil de modélisation 3D, l’outil et le langage de programmation. Dans le dossier justificatif(lot 40), vous trouverez des photos des différentes solutions de conception étudiées.

FIGURE 2.1 – Aperçu en vue isométrique de la version finale de Robos’πR

Page 12/101

FIGURE 2.2 – Vue avant et arrière de Robos’πR

FIGURE 2.3 – Vue droite et gauche de Robos’πR

FIGURE 2.4 – Vue de dessus et en-dessous de Robos’πR

Page 13/101

2.1.1 Système de préhensionPour le système de préhension des balles, nous avons commencé par lister tous les systèmes possibles de

saisie :– FOURCHE HORIZONTALE : constituée de deux bras parallèles qui viendraient se glisser sous la balle.

Cette solution a été écartée car le stock gênait le passage des bras et la balle risquait d’être éjectée.– GRAPPIN : constitué de crochets se refermant sur la balle pour la saisir. Cependant, étant donné la forme

du stock, cette solution nécessitait 2 mouvements (déplacement + saisie) : utiliser un seul moteur pourengendrer 2 mouvements est techniquement compliqué à mettre en œuvre (les 2 autres étant utiliséspour les roues motrices). Nous l’avons donc écartée.

– PINCE HORIZONTALE : constituée de deux axes horizontaux coaxiaux qui se positionneraient au niveaude la balle, et la saisiraient par pression en se resserrant sur elle. Cependant, le contact sphère/axe nousparaissait assez instable, mais surtout il aurait fallu trouver une solution pour réaliser deux mouvements(déplacement + saisie) avec un seul moteur. Cette solution a été écartée.

– PELLETEUSE NO 1 : constituée de bras coudés venant se glisser sous la balle pour la saisir. Mais une foisencore le stock était gênant lorsque le robot devait sortir du stock avec la balle ; nous avons donc écartécette solution.

– PELLETEUSE NO 2 : constituée de bras coudés venant attraper la balle par le dessus en la plaquant contrele corps du robot. C’est cette solution que nous avons retenue pour la saisie de la balle.

2.1.2 Système de déplacementPour la mobilité du robot, plusieurs systèmes ont été envisagés :– 4 ROUES AVEC UN SYSTÈME DE CHENILLES : permettant une grande adhérence avec le sol. Cependant,

en comparant cette solution avec les autres, il s’est avéré que les chenilles ralentissent le système. Cettesolution a été écartée.

– 2 ROUES MOTRICES ET UNE ROUE D’APPUI : constitué à l’avant de 2 roues motrices et à l’arrière d’unepetite roue sans pneu, permettant au robot de rouler et glisser sur le sol et assurant son équilibre. Cettesolution a été écartée car la roue d’appui arrière engendrait un frottement important dans les virages.

– 4 ROUES DONT 2 ROUES MOTRICES : cette solution est envisageable mais nécessite 2 roues folles doncun coût supplémentaire et apporte une stabilité supplémentaire négligeable, cette solution a donc étéécartée.

– 2 ROUES MOTRICES ET UNE ROUE FOLLE : constitué de 2 roues motrices à l’avant et d’une roue folle type«caddy» à l’arrière permettant au robot de tourner sans problème dans les virages. Cette solution a étéretenue.

2.1.3 Appréhension de l’environnementPour que le robot puisse appréhender son environnement, voici les systèmes que nous avons envisagés :– Pour pouvoir suivre les bandes noires au sol et repérer les pastilles, nous avons dans un premier temps

utilisé un capteur RGB, cette solution était peu précise. Afin d’augmenter la précision nous avons placéun capteur de lumière et un capteur RGB côte à côte espacés d’environ la largeur de la bande noire. Cettesolution a finalement été écartée puisqu’un seul capteur RGB au sol n’était pas suffisant pour détecter àcoup sûr les couleurs de pastilles au sol. Nous avons donc retenu une solution utilisant deux capteursRGB au sol.

– Pour pouvoir détecter la couleur des balles, au début, un capteur RGB a été utilisé. Il a été fixé sur lapartie avant du châssis. Cette solution était efficace mais étant donné la solution retenue précédemment,le capteur RGB n’est plus disponible. Par conséquent, nous avons positionné le capteur de lumière sur lesystème de préhension. Cette solution détecte bien les différences de couleur. Elle a donc été retenue.

– Pour pouvoir détecter les obstacles sur son chemin, nous avons écarté la solution du capteur de contactcar il ne permet pas de détecter correctement un obstacle léger comme les éléments. La solution technique,qui a été retenue, est le sonar.

2.1.4 Modélisation en 3DNous avons décidé d’utiliser CATIA V6, une plateforme de conception virtuelle et collaborative, pour

modéliser notre robot en 3D. Ce choix nous a permis de garder une trace des différentes versions du robot etde générer plus aisément tous les documents techniques relatifs du système RobAFIS.

Page 14/101

2.1.5 Outil et langage de programmationPour ce qui est de l’outil utilisé pour le développement du programme permettant au robot d’effectuer sa

mission, nous avons étudié plusieurs possibilités :– NXT_PYTHON : cette solution nous apportait la puissance et la flexibilité du langage de programmation

Python et la possibilité de travailler avec un environnement stable. Il s’est cependant avéré que laconnexion entre le NXT et le PC était très lente via USB et inexistante via Bluetooth ; nous avons doncécarté cette solution ;

– NQC (Not Quite C) : cette solution offre un langage ayant une syntaxe très proche du langage C,avec cependant quelques fonctionnalités manquantes et surtout plusieurs éléments rendant le codelourd, difficile à relire par une personne différente de l’auteur des lignes de code concernées. De plus,l’environnement fourni avec NQC est assez pauvre et offre très peu d’outils permettant de déboguer unprogramme. C’est pourquoi nous avons rejeté cette solution ;

– ROBOTC : cette dernière solution envisagée nous a rapidement été proposée, étant donné que nousdisposions de plusieurs licences pour ce logiciel. À l’instar de NQC, RobotC reprend principalement lasyntaxe de C sans une surcouche gênante. L’accès aux différents états des capteurs et à la vitesse desservomoteurs est facile et fluide. De plus, un débogueur est fourni avec l’environnement, la connexionen Bluetooth et USB se fait simplement et deux PCs peuvent se passer rapidement la main sur le robot,permettant un avancement plus rapide. Ainsi, cette solution a été retenue.

Une fois le choix de l’outil de programmation effectué, nous avons réfléchi à la façon dont notre robot allaiteffectuer sa mission, c’est à dire dans quel ordre aller chercher les balles. Nous en sommes arrivé à la solutionexpliquée dans le diagramme UML ci-dessous :

FIGURE 2.5 – Diagramme d’activité pour la mission nominale

Page 15/101

2.2 Architecture fonctionnelle et comportementale (LOT 22)

L’analyse fonctionnelle se fait de manière descendante. On va donc partir de la fonction « réaliser lamission » qui est la fonction principale du robot. De celle-ci, un certain nombre de sous-fonctions en découlera.

2.2.1 Arborescence fonctionnelle statiqueNous avons commencé par un diagramme de cas d’utilisation qui permet de décrire les fonctions au niveau

système.

FIGURE 2.6 – Diagramme de cas d’utilisation au niveau système

Les flux d’entrées et de sorties entre ces fonctions sont représentés dans le diagramme d’activités de lafigure 2.7.

FIGURE 2.7 – Diagramme d’activité : analyse fonctionnelle statique

Page 16/101

La décomposition fonctionnelle nous a donné l’arborescence suivante :

Niveau 1 Niveau 2 Niveau 3

[F.1] Se déplacer [F.1.1] Propulser le système [F.1.1.1] Avancer

[F.1.1.2] Reculer

[F.1.2] Tourner [F.1.2.1] Aller à droite

[F.1.2.2] Aller à gauche

[F.1.3] S’arrêter

[F.2] Contrôler le système [F.2.1] Sélectionner le programme

[F.2.2] Charger le programme

[F.2.3] Exécuter le programme

[F.2.4] Adapter la puissance fournie aux servomoteurs

[F.3] Alimenter en énergie [F.3.1] Stocker l’énergie

[F.3.2] Fournir de l’énergie [F.3.2.1] Fournir de l’énergie auxservomoteurs

[F.3.2.2] Fournir de l’énergie auxcapteurs

[F.4] Interagir avec l’environ-nement

[F.4.1] Appréhender les impacts [F.4.1.1] Détecter les stocks

[F.4.1.2] Détecter les obstacles

[F.4.1.3] Protéger le système

[F.4.2] Interagir avec les éléments [F.4.2.1] Saisir les éléments

[F.4.2.2] Stocker les éléments

[F.4.2.3] Lâcher les éléments

[F.4.2.4] Déterminer la couleur del’élément

[F.4.3] S’orienter en fonction desindications au sol

[F.4.3.1] Suivre la ligne noire

[F.4.3.2] Détecter les pastilles decouleur

[F.4.4] Supporter la masse decertains sous-systèmes afin degarder

[F.4.3.1] Suivre la ligne noire

2.2.2 Architecture fonctionnelle et dynamiqueA partir de l’arborescence fonctionnelle statique, nous pouvons modéliser le comportement dynamique du

système en utilisant les diagrammes de séquence pour montrer les interactions entre les entités du systèmevia les flux échangés. Sans vouloir être exhaustif, nous allons présenter 3 diagrammes : un scénario pour sedéplacer, un scénario pour tourner et un scénario pour interagir avec les éléments.

Page 17/101

FIGURE 2.8 – Diagramme de séquence du déplacement

FIGURE 2.9 – Diagramme de séquence de la rotation

Page 18/101

FIGURE 2.10 – Diagramme de séquence de la préhension

2.3 Architecture organique/physique (LOT 23)

2.3.1 Arborescence organique/physiqueLa structure du système RobAFIS est modélisée via un diagramme de définition de blocs (BDD) de SysML

(Figure 2.11). Cela nous permet de décrire les constituants du système étudié, ainsi que les relations entre lesdifférents composants.

2.3.2 Architecture organique/physiqueLe diagramme de blocs internes (Figure 2.12) permet de modéliser la structure interne du robot : ses

différents composants et les connections physiques existantes entre eux.

2.4 Moyens consommés, utilisés, produits (LOT 24)

Les moyens matériels consommés sont les suivants :– 6 piles de type AA 1.5V ;– Les pièces des kits LEGO (ces pièces seront détaillées dans le lot 30) ;– Planches, peinture, scotch, outils divers – afin de recréer une arène semblable à celle qui sera utilisée lors

de la compétition.L’entrée nécessaire est la variable p.Les produits nécessaires sont les éléments que le système doit transporter ; à savoir les 3 balles rouges et les 3balles bleues.

Dans un cadre plus logistique, les moyens consommés sont :

Page 19/101

FIGURE 2.11 – Arborescence organique/physique

FIGURE 2.12 – Architecture organique/physique

• [SWYM] – pour la communication, ainsi que le partage de ressources ;• [CATIA V6] – pour la modélisation 3D ;• [ARTISAN STUDIO] – pour la modélisation SysML ;• [STARUML] – pour la modélisation UML ;• [ROBOTC] – pour la programmation du NXT ;• [LATEX] – pour la rédaction du rapport ;• [GITLAB] – pour la mise en place des dépôts GIT, pour la gestion des versions du rapport ainsi que du

code RobotC ;• [GOOGLE GROUPS] – pour la mise en place d’une mailing-list.Les références de ces outils sont disponibles à la page 99.

Page 20/101

2.5 Interfaces (LOT 25)

2.5.1 Définition des interfaces externes au système

Liens ou interfaces physiquesexternes

Outils d’interface Élément appliqué Flux d’entrée ou de sortie

Lumière réfléchie sur l’objet Capteur de lumière Élément sphère Éclairage fourni par le capteur (sortie)Longueur d’onde récupérée (entrée)

Lumière réfléchie sur l’objet Capteur de couleurRGB

Pastille de couleur ausol

Éclairage fourni par le capteur (sortie)Longueur d’onde récupérée (entrée)

Lumière réfléchie sur l’objet Capteur de couleurRGB

Ligne noire appliquéeau sol

Éclairage fourni par le capteur (sortie)Longueur d’onde récupérée (entrée)

Contact Sonar Obstacles/stocks Distance (sortie)Ondes (entrée)

Contact Roues Sol Effort de traction et de rotation (sortie)Effort de gravité et de frottement (en-trée)

Contact Système de préhension Élément sphère Couple de serrage de l’élément (sortie)Effort de gravité (entrée)

Contact NXT L’opérateur Pression exercée par la main de l’opéra-teur (entrée)Écran (sortie)

Bluetooth NXT Bluetooth Onde radio contenant le programme(entrée)

USB NXT Port et câble USB Flux de données comportant le pro-gramme de la mission (entrée)

Contact Robot Mains des assembleurs Montage du robotMise en place du programme

N.B : Pour les liens externes, on détermine si un flux est d’entrée ou de sortie en se plaçant au niveau du robot.

Page 21/101

2.5.2 Définition des interfaces internes au système

Liens ou interfacesphysiques internes

Élément 1 Élément 2 Flux d’entrée ou de sortie

Câble électrique Capteur RGB NXT Tension analogique d’alimentation du capteur (entrée capteur)Information sur la couleur des pastilles (sortie capteur)

Câble électrique Capteur RGB NXT Tension analogique d’alimentation du capteur (entrée capteur)Information sur la présence de la bande noire au sol (sortiecapteur)

Câble électrique Capteur lumière NXT Tension analogique d’alimentation du capteur (entrée capteur)Information sur la couleur des éléments (sortie capteur)

Câble électrique Sonar NXT Tension analogique d’alimentation du capteur (entrée capteur)Information sur la présence d’obstacle (sortie capteur)

Câble électrique Moteurs NXT Tension analogique d’alimentation des moteurs (entrée mo-teur)Information sur la rotation (sortie moteur)

Axes de transmission Moteurs Roues Couple rotationnel (entrée roue)Effort de frottement et gravité (sortie roue)

Axes de transmission Moteur Système depréhension

Couple rotationnel (entrée préhension)Effort de frottement et gravité (sortie préhension)

Page 22/101

2.6 Description fonctionnelle et organique des sous-systèmes (LOT 26)

2.6.1 Système de préhensionCaractéristiques techniques

Système de pinces fermées Servomoteur

Longueur 70 mm Précision des tachymètres 1o

Hauteur 135 mm Vitesse de rotation d’un moteur sans charge 170 tours/min

Largeur 65 mm Courant moteur sans charge 60mA

Profondeur 38 mm Tension moteur 9V

Angle de rotation des pinces 93 o

Architecture fonctionnelle et comportementale

F.4.2 Interagir avec les éléments

F.4.2.1 Saisir les éléments

F.4.2.2 Stocker les éléments

F.4.2.3 Lâcher les éléments

F.2.4 Adapter la puissance fournie aux servomoteurs

Architecture organique / physique

Traçabilité des fonctions allouées

Fonctions à remplir Constituants associés

F.2.4 : Adapter la puissance fournie aux servomoteurs NXT

F.4.2 : Interagir avec les éléments Bras + servomoteur

2.6.2 Système de contrôleCaractéristiques techniques du boitier NXT, ainsi que des câbles électriques et des piles d’alimentation

Page 23/101

Microprocesseur 32 bit ARM7

Bluetooth PC

Port USB 2.0 (12Mb/s)

Ports d’entrée capteur 4

Ports de sortie moteur 3

Ecran à cristaux liquides 100*64 pixels

Haut-parleur intégré qualité sonore 8 kHz - 8 bit - échantillonnage 2-16 kHz

Dimension 112*72*40 mm

Câbles électriques 20, 35 et 50 cm

Alimentation 6 piles AA


F.2 Contrôler le système

F.2.1 Sélectionner le programme

F.2.2 Charger le programme

F.2.3 Exécuter le programme

F.3 Alimenter en énergie

F.3.1 Stocker l’énergie

F.3.2 Fournir de l’énergie

F.3.2.1 Fournir de l’énergie aux servomoteurs

F.3.2.2 Fournir de l’énergie aux capteurs




F.2.1 : Sélectionner le programme NXT

F.2.2 : Charger le programme NXT

F.2.3 : Exécuter le programme NXT

F.3.1 : Stocker l’énergie Piles et câbles

F.3.2 : Fournir de l’énergie Piles et câbles

Page 24/101

2.6.3 Système de déplacementCaractéristiques techniques

Système Servomoteur

Roues avant D = 60 mm Précision des tachymètres 1o

Roue arrière D = 22 mm Vitesse de rotation d’un moteur sans charge 170 tours/min

Courant moteur sans charge 60mA

Tension moteur 9V


F.1.1 Propulser le système

F.1.1.1 Avancer

F.1.1.2 Reculer

F.2.4 Adapter la puissance fournie aux servomoteurs

F.1.2 Tourner

F.1.2.1 Aller à droite

F.1.2.2 Aller à gauche

F.1.3 S’arrêter




F.1.1 : Propulser le système Roues avant + Roue arrière + Servomoteur

F.1.2 : Tourner Roues avant + Roue arrière + Servomoteur

F.1.3 : S’arrêter Roues avant + Roue arrière + Servomoteur

F.2.4 : Adapter la puissance fournie aux servomoteurs NXT

2.6.4 Système d’orientationCaractéristiques techniques

Page 25/101

2 Capteur couleur RGB

Hauteur 43mm

Profondeur 32mm

Largeur 24mm


F.4.3 S’orienter en fonction des indications au sol

F.4.3.1 Suivre la ligne noire

F.4.3.2 Détecter les pastilles de couleur




F.4.3.1 : Suivre la ligne noire Capteur RGB

F.4.3.2 : Détecter la couleur des pastilles Capteur RGB

2.6.5 Système de détection des obstaclesCaractéristiques techniques du sonar

Hauteur 32mm

Profondeur 43mm

Largeur 56mm


F.4.1 Appréhender les impacts

F.4.1.1 Détecter les stocks

F.4.1.2 Détecter les obstacles

Page 26/101




F.4.1.1 : Détecter les stocks Sonar

F.4.1.2 : Détecter obstacles Sonar

2.6.6 Système de détection de l’élémentCaractéristiques techniques du capteur de lumière

Hauteur 43mm

Profondeur 32mm

Largeur 24mm


F.4.2.4 Déterminer la couleur de l’élément


Page 27/101



F. 4.2.4 : Déterminer la couleur de l’élément Capteur de lumière

2.6.7 Système châssisCaractéristiques techniques : pièces LEGO


F.4.4 Supporter la masse de certains sous-systèmes

F.4.1.3 Protéger le système


Le châssis est lié à l’ensemble des sous-systèmes. Ce sont les pièces de LEGO qui le constituent et quipermettent de réaliser les liens physiques.Traçabilité des fonctions allouées


F.4.1.3 : Protéger le système Pièces LEGO

F.4.4 : Supporter la masse de certains sous-systèmes Pièces LEGO

Page 28/101

CHAPITRE 3

CONFIGURATION DE RÉFÉRENCE(LOT 30)

3.1 Nomenclature de la solution validée et retenue

Robos’πR a été créé à partir des kits LEGO Mindstorms 9695 et 9797. Le tableau suivant (tables 3.1 et 3.2)constitue la nomenclature de définition du système Robos’πR – Version 4 (la solution retenue et validée dusystème en état fonctionnel).

Les éléments ont été classés par sous-systèmes afin de faire apparaître l’arborescence. Pour des raisons declarté, les pièces LEGO constituant le sous-système châssis ont été intégrées directement aux sous-systèmes lesutilisant.

Dans un souci de lisibilité, la nomenclature a été séparée en deux dans ce document, les parties étant misesà la suite.

TABLE 3.1 – Nomenclature du système - Première partie

Page 29/101

TABLE 3.2 – Nomenclature du système - Seconde partie

Page 30/101

3.2 Schéma général d’interconnexion électrique

Le système est alimenté en énergie électrique par les six piles de la console NXT.La figure suivante représente le schéma général d’interconnexion électrique (puissance et commande

contrôle du système Robos’πR :

FIGURE 3.1 – Schéma général d’interconnexion électrique

3.3 Schéma de la chaîne cinématique

La figure suivante représente le schéma cinématique du système Robos’πR :

FIGURE 3.2 – Schéma cinématique du système Robos’πR

Page 31/101

3.4 Instructions d’identification du système et de ses constituants

Seul le système de préhension est à configuration variable. Par conséquent, seules lesdites variations de cesous-système seront décrites :

(a) Configuration limite no1, angle minimal autorisé pour lapince

(b) Configuration limite no2, angle maximal autorisé pour lapince

(c) Configuration indésirable, angle maximal physiquementpossible pour la pince

FIGURE 3.3 – Configurations possibles du système de préhension

Le sous-système Préhension du système Robos’πR peut évoluer entre la configuration limite 1 et la configu-ration limite 2. Il est important qu’il ne sorte pas de ce champ de possibilités pour ne pas se retrouver dans laconfiguration indésirable décrite ci-dessus.

Page 32/101

CHAPITRE 4

DOSSIER JUSTIFICATIF (LOT 40)

4.1 Dossier justificatif du choix de l’architecture retenue (LOT 41)

Modèles décisionnels

Afin d’avoir un robot qui puisse remplir la mission qui lui est demandée, nous avons suivi le modèledécisionnel qui est décrit aux figures 4.1 et 4.2.

La première étape a été de rédiger l’ensemble des exigences de la mission. Les différentes exigences ontpermis de créer des sous-systèmes organiques et des sous-systèmes fonctionnels.

L’étape suivante a été de faire un brainstorming pour chaque sous-système et de mettre en avant toutes lessolutions possibles. Pour chaque solution des sous-systèmes, la faisabilité est vérifiée à la fois par l’équipeconception et l’équipe de programmation, par exemple à l’aide de modèles CATIA. Les solutions restantessont modélisées directement avec les pièces LEGO et comparées par l’équipe programmation afin de choisir lameilleure solution du point de vue de la conception mécanique et programmation.

Lorsque les solutions sont choisies pour les sous-systèmes, le système est testé et modifié si nécessaire.

FIGURE 4.1 – Méthodologie de validation du système

Page 33/101

FIGURE 4.2 – Méthodologie de validation des sous-systèmes

Description des solutions non retenues

Pour permettre de décrire les choix technologiques qui ont été réalisés, les solutions évoquées serontclassées par sous-système organique.

Dans la suite de ce lot, l’ensemble des solutions imaginées pour les sous-systèmes est énuméré et la solutionretenue est indiquée au moyen du logo : X

Page 34/101

4.1.1 Système de déplacement

No Description Références

1 Utilisation de chenilles -

2 3 roues : 2 roues motrices et 1 roulette 4.4a, 4.4b, 4.4c, 4.4d X

FIGURE 4.3 – Liste des solutions imaginées pour le système de déplacement

Suite à la réalisation de tests sur prototype entre le modèle à chenille et un modèle à trois roues, le derniermodèle a été choisi (solution No 2). Dès lors, il existe plusieurs façons de réaliser une roue de caddie. Plusieursessais ont été réalisés et testés afin d’obtenir la meilleure solution possible.

Les schémas de la figure 4.4 illustrent les différentes tentatives réalisées.

(a) Cette solution a été écartée car la roulettecréait trop de frottements et gênait le mouvementlors de la rotation.

(b) Cette solution a été écartée car la roue util-isée était trop grande et causait un problèmed’équilibre pour le châssis ; de plus elle bloquaitau niveau de la rotation.

(c) Cette version a donné de très bons résultats,mais elle nécessitait un grand nombre de piècespour être déployée ; elle a été remplacée par uneversion moins coûteuse.

(d) Cette version de la roue de caddie a étéretenue : elle est minimaliste par conception etdonne de très bons résultats.

FIGURE 4.4 – Schémas de différents essais pour le système de déplacement (troisième roue)

Les raisons principales ayant mené au choix de la solution illustrée en 4.4d, notamment par rapport au4.4c, et la réduction du nombre de pièces LEGO nécessaire et donc du coût final du robot.

Page 35/101

4.1.2 Système de préhension


1 Fourche horizontale -

2 Grappin -

3 Pince horizontale -

4 Pelleteuse no 1 : l’élément sera saisi par un mouvementde bas en haut -

5 Pelleteuse no 2 : l’élément sera saisi par un mouvementde haut en bas 4.6a, 4.6b X

FIGURE 4.5 – Liste des solutions imaginées pour le système de préhension

Un certain nombre de solutions ont été envisagées pour permettre une préhension sûre de l’élément.Les trois premières solutions évoquées ont été rapidement écartées dû à la difficulté de réalisation ou au

manque de performance dès les premiers tests. De plus, les choix faits sur la partie motrice imposaient den’utiliser qu’un seul moteur.Pour les deux types de pelleteuses, des tests ont été réalisés pour choisir la solution la plus sûre et la plusrapide.

(a) Cette solution a été retenue car elle permet desaisir l’élément même si l’on n’est pas parfaite-ment centré sur le stock et les tests montrent quele système est assez fiable.

(b) La solution 4 a été modifiée afin de s’adapter àla mise en place des autres éléments du système.Il a été remarqué que la saisie de l’élément estplus sûre avec la nouvelle position du moteur.

FIGURE 4.6 – Photographies des évolutions de la solution No 5 de préhension

Page 36/101

4.1.3 Système d’orientation


1 Utilisation d’un seul capteur de couleur qui permet decapter la ligne noire et les pastilles 4.8a

2Utilisation de deux capteurs RGB qui permettent desuivre la ligne noire et de détecter les pastilles decouleur au sol

4.8b X

FIGURE 4.7 – Liste des solutions imaginées pour le système de déplacement

(a) Cette solution n’a pas été gardée car le robotperdait du temps et de la vitesse pour suivre laligne.

(b) Cette solution a été retenue car elle permetde suivre la ligne de façon efficace et précise. Lesdeux capteurs sont placés de part et d’autre de laligne au sol.

FIGURE 4.8 – Photographies de différents systèmes permettant le suivi de ligne

Page 37/101

4.1.4 Système de détection de l’élémentLe capteur de lumière a été utilisé afin de détecter la couleur de l’élément sur un stock. Les capteurs RGB

ont en effet été considérés plus fiables pour la détection des pastilles et le capteur de lumière est suffisantpour distinguer les deux couleurs possibles pour les éléments (rouge et bleu) à partir des niveaux de gris.Cependant, sa position dans le prototype a évolué au fil de la conception afin d’améliorer sa fiabilité dedétection, mais aussi en fonction des contraintes liées aux autres éléments (préhension, détection d’obstacles).


1 Le capteur est placé sur le système de préhension 4.10a

2 Le capteur est placé sur le côté du robot 4.10b

3 Le capteur est placé sur le moteur dans une positionverticale 4.10c X

FIGURE 4.9 – Liste des solutions imaginées pour le système de détection de l’élément sur un stock d’entrée

(a) Cette solution n’a pas été retenue car le cap-teur gênait pour la saisie de l’élément (balle),augmentait de façon trop importante la taille durobot et gênait le sonar.

(b) Cette solution a donné d’assez bons résultatsmais risquait de pousser la balle dans le stockquand le prototype arrivait avec un biais mêmeléger.

(c) Au termes de tests, la solution retenue serévèle être fiable et ne gêne pas la préhension.

FIGURE 4.10 – Photographies de différents approches pour la détection de la couleur de la balle

Page 38/101

4.1.5 Système de détection des obstacles


1 Utilisation du sonar afin de détecter les obstacles 4.12a X

2 Utilisation du capteur de contact pour permettre ladétection des obstacles («pare-choc») 4.12b

3 Utilisation des capteurs de contact et RGB pour lesobstacles 4.12b, 4.12c

FIGURE 4.11 – Liste des solutions imaginées pour le système de détection des obstacles sur le plateau

Deux capteurs sont proposés pour la détection des obstacles : le sonar et le capteur de contact. Pour rappel,il a été choisi d’utiliser deux capteurs pour le suivi de ligne. Avec le détecteur de balle, il ne reste donc plusqu’un seul port de capteur disponible sur le bloc NXT. Le choix et la configuration du capteur d’obstaclesdevra donc permettre de couvrir un maximum de risques.

(a) Malgré sa faible précision, cette solution a fi-nalement été retenue car elle est la seule capablede détecter les obstacles à une distance suffisantepour permettre d’arrêter le dispositif avant con-tact.

(b) Cette solution n’a pas été retenue car si lecapteur de contact permet de détecter les stocksou des ensembles qui ne peuvent pas bouger, ilne peut pas capter des éléments mobiles légers(comme des balles perdues).

(c) Cette solution a été écartée car la zone scrutéeest très faible et est obstruée quand le dispositiftransporte une balle.

FIGURE 4.12 – Photographies de différents systèmes de détection d’obstacle.

La solution 3 propose d’associer le capteur de couleur pour les éléments et un capteur de contact pour ladétection des obstacles. Cette proposition avait pour but de fiabiliser la détection des stocks d’entrée/sortieavec le capteur de contact, mais la détection d’obstacles à proprement parler n’est pas fiable. De fait, le sonar aété retenu comme outil de détection des obstacles.

Page 39/101

4.2 Dossier justificatif de la conception (LOT 42)

L’ensemble des tests référencés dans ce lot est consultable dans l’annexe B du présent document.

4.2.1 Exigences fonctionnelles

Ref. Exigence Réponses techniques Dispersion Tests

EF01Le système doit exécuterla mission en fonction duparamètre p

Implémentation du paramètre p dans lecode embarqué

EF02 Le système doit agir defaçon autonome

Le code embarqué pilote le dispositif sansintervention, le dispositif est alimenté parune pile ou batterie

EF03Le système doit allerchercher les pièces dans leszones de stockage

T01

EF031 Le système doit suivre leslignes tracées au sol Deux capteurs de couleur (RGB) T02 T04

EF032

Le système doit utiliser lespastilles de couleur commeindicateur de changementde direction ou de position-nement

Deux capteurs de couleur (RGB)Non détectiond’une pastille(≤ 5%)

T02 T04

EF04Le système doit s’occuperdes pièces dans le SPE demanière prioritaire

Préférence dans le code embarqué

EF05 Le système doit saisir uneou plusieurs pièces Système de préhension

Les branches dela pince peuvents’écarter

T02

EF06 Le système doit analyser lacouleur des pièces Capteur de lumière

Aléas selon l’é-clairage ambiant(≤ 5%)

T03

EF07Le système doit être ca-pable de stocker une ouplusieurs pièces

Système de préhension

EF08Le système doit acheminerles bonnes pièces dans lesbonnes zones

EF081

Le système doit amenertoutes les pièces de sacouleur dans son stock d’ar-rivée SA

Capteur de lumière + code + système demouvement

EF082

Le système doit amenertoutes les pièces de l’adver-saire dans le stock partagéde départ SPD

Capteur de lumière + Code + système demouvement

EFO9Le système doit être ca-pable de lâcher une ouplusieurs pièces

Système de préhension T01

EFO10Le système doit revenirdans la zone de départ unefois la mission accomplie

Système de mouvement + CodeErreur à la détec-tion du bord duplateau

T05

Page 40/101

4.2.2 Exigences de performance


EPE1Le système doit réaliser lamission en moins de tempspossible

Système RobAFIS T02

EPE2Le système doit réaliser lamission dans un délai pre-scrit de 4 minutes

Système RobAFIS

EPE3Le système doit réaliser lamission sans dépasser 6minutes

Système RobAFIS

EPE4

Le système doit prendre encompte la pièce en attentedans SPE avant un délaide 2 minutes après l’appari-tion de celle-ci

Code

EPE5

Le système doit être capa-ble de réaliser 3 missionssuccessives sur une périodede service maximale de 4heures

Système RobAFIS (piles ou batterie)

4.2.3 Exigences d’interface


EIN1

Le système doit téléchargerson programme par moyende communication, USB ouBluetooth

NXT

EIN2 Le système doit être mis enmarche manuellement NXT

EIN3Le système doit être capa-ble de recevoir le paramètrep de la mission

Code embarqué

EIN4Le système doit pouvoirêtre relancé par l’opérateurde l’équipe

NXT

Page 41/101

4.2.4 Exigences opérationnelles


EOP1

Le système doit posséderun mode d’essai de mise aupoint et de vérification fonc-tionnelle in situ

RobAFIS

EOP2 Le système doit posséderun mode veille RobAFIS

EOP3 Le système doit posséderun mode opérationnel RobAFIS

EOP4 Le système doit être capa-ble d’être redémarré NXT

EOP5 Le système doit avoir unmode de maintenance RobAFIS

Exigences d’ergonomie


EER1 Le système doit être préhen-sible manuellement Système de préhension

Exigences de sûreté de fonctionnement


ESF1Le système doit s’arrêteren cas d’obstacle sur sonchemin

Sonar Marge d’erreurdu sonar

T05 T06 T07

Exigences d’environnement opérationnel


EEO1

Le système doit pouvoirévoluer dans une plage detempérature comprise entre10oC et 32oC

RobAFIS

EEO2

Le système doit pouvoirévoluer sous une pres-sion atmosphérique com-prise entre 1000 et 1030mb

RobAFIS

EEO3Le système doit pouvoirévoluer dans un taux d’hu-midité entre 40 et 75%

RobAFIS

EEO4

Le système doit pouvoir sedéplacer sur une surfaceparfaitement plane et hor-izontale, rigide, avec unesurface dure et de couleurclaire uniforme

RobAFIS T02 T03

Page 42/101

Exigences de stockage et de transport


EST1Le système doit pouvoirêtre transporté de Paris àNîmes

RobAFIS

EST2Le système doit pouvoirêtre stocké entre les mis-sions

RobAFIS

Exigences de maintenance


EM1 Le système doit être main-tenable RobAFIS

Page 43/101

CHAPITRE 5

PLAN D’INTÉGRATION VÉRIFICATIONVALIDATION (LOT 50)

5.1 Plan d’intégration mécanique et électrique du système

Vous pouvez trouver la notice de montage dans l’annexe C du présent document.

5.2 Plan de vérification

Les activités de vérification ont pour but de montrer que l’activité technique a été bien effectuée, c’est-à-direque le système est conforme à ses exigences systèmes. Ces vérifications se font sous forme de tests ou devérifications visuelles, que ce soit au niveau des sous-systèmes ou au niveau de l’assemblage final.

TestNo

Système Objectif Procédure Résultat at-tendu

Procédure résultatnon satisfaisant

1 Système de dé-placement

Vérifier le blocage ax-ial des roues

Contrôler la présence desbutées axiales et l’absencede jeu entre les butées, laroue et le moteur

Absence de jeuaxial

Déplacer la pièce réf.4211622 pour arriveren butée


Vérifier le bonfonctionnement enrotation des axes desroues

Effectuer une rotationmanuelle des axes

Seule la résis-tance du moteurest perceptibledurant la rota-tion

Vérifier le montagedu système (si mon-tage OK, changer lemoteur)


Vérifier le montagedes pneus

Vérification visuelle dumontage des pneus

La lèvre dupneu est posi-tionnée sur lebord de la jante

Repositionner le pneusur la jante


Vérifier la libre rota-tion de la roue folle

Faire tourner manuelle-ment la roue arrière

La roue tournelibrement

Vérifier le montagedu système

5 Système depréhension

Vérifier le bon fonc-tionnement en rota-tion

Effectuer une rotationmanuelle de l’axe

Seule la résis-tance du moteurest perceptibledurant la rota-tion

Vérifier le montagedu système (si mon-tage OK, changer lemoteur)

Page 44/101

TestNo

Système Objectif Procédure Résultat at-tendu

Procédure résultatnon satisfaisant


Vérifier l’absenced’obstacles sur latrajectoire des pinces

Effectuer une rotationmanuelle de l’axe

Les pinces tour-nent sans ren-contrer d’obsta-cles dans la zoneangulaire prévu



Vérifier le blocage ax-ial des bras

Contrôler la présence desbutées axiales et l’absencede jeu entre les butées, lapince et le moteur

Absence de jeuaxial

Déplacer la pièce réf.4211622 pour arriveren butée

8 Système com-plet

Vérifier la solidité dusystème

Appliquer une légèrecharge transversale etaxiale

Pas de démon-tage de pièce


9 Système châssis Vérifier le bon em-boîtement des pièces Contrôle visuel Pas de pièce mal

emboîtéeRemboîter les piècessuivant la notice

10 Système de con-trôle

Vérifier que les fichesdes câbles sont bienfixées

Tirer légèrement sur lescâbles

Le câble reste enplace au niveaudu NXT

Renficher les câbles

11 Brique NXTVérifier le bon assem-blage de la brique surle châssis

Soulever le robot par labrique NXT

La brique restesolidaire duchâssis

Vérifier le montage (simontage OK, changerles clips)

12 Système de con-trôle

Vérifier le bon posi-tionnement des piles(+ et -)

Contrôle visuelL’orientationdes piles (+ et -)est correcte

Remettre les pilesdans le bon sensen accord avec lesindications dans leboitier

13Système com-plet / détectionau sol

Vérifier la distance en-tre les capteurs et lesupport

Contrôle visuel

Positionnementen accord avecla notice demontage


14 Système com-plet

Vérifier la connexiondes câbles entre leNXT et les autrescomposants (moteur /capteur)

Contrôle visuel

Les câblesdoivent êtreconnectés suiv-ant le plan demontage

Connecter les câblessuivant le plan demontage

15 Système com-plet

Vérifier que l’intégral-ité des pièces prévuesont été utilisées

Contrôle de l’absence depièces non utilisées

Absence depièces restantes


16Système de dé-tection des ob-stacles

Vérifier l’angle entrele radar et l’horizon-tale

Contrôle visuel

Positionnementen accord avecla notice demontage


17Système de dé-tection de l’élé-ment

Vérifier le bon fonc-tionnement du cap-teur de lumière

Exécuter un programmepermettant de tester la lu-minosité du rouge et dubleu

Le capteur dé-tecte les bonnescouleurs

Vérifier la positionverticale du capteuret la connexion avecle NXT (si vérificationOK, changer le cap-teur)

18 Système de dé-tection au sol

Vérifier le bon fonc-tionnement du sous-système

Exécuter un programmepermettant de suivre uneligne et de détecter unepastille

Le robot suit laligne et tourne àla pastille

Vérifier la connexionavec le NXT (si véri-fication OK, changerles capteurs)

Page 45/101

TestNo

Système Objectif Procédure Résultat attendu Procédure résultatnon satisfaisant

19

Systèmede détec-tion ausol

Vérifier la présence dedeux capteurs RGB (etnon un capteur RGBet un capteur de lu-mière)

Contrôle visuel Présence de deux cap-teurs RGB

Remplacer le capteurde lumière par un cap-teur RGB

20Systèmede déplace-ment

Vérifier la mobilité durobot

Exécuter un programmepermettant le déplacementdu système en ligne droiteet en rotation

Le robot avance ettourne

Vérifier la connexionavec le NXT (si véri-fication OK, changerles moteurs)

21

Systèmede détec-tion desobstacles

Vérifier le bon fonc-tionnement du cap-teur

Exécuter un programmepermettant de détecter unobstacle préalablement dis-posé devant le capteur

Le système détectel’obstacle

Vérifier la connexionavec le NXT (si vérifi-cation OK, changer lecapteur)

22Systèmede préhen-sion

Vérifier la bonnepréhension deséléments

Exécuter un programmepermettant de saisir un élé-ment

Le système saisit l’élé-ment

Vérifier la connexionavec le NXT (si vérifi-cation OK, changer lemoteur)

5.3 Plan final de validation

5.3.1 Plan de validation au niveau du système completLe plan de validation final permet de vérifier que l’activité technique répond à son objectif, que le produit

résultant de l’activité répond au besoin pour lequel l’activité a été faite. Le lien est fait entre chaque produit dusystème et la ou les exigences auxquelles il répond.

Phase Exigence Référence

Le système est assemblé, leprogramme est chargé, le tout estvérifié, à Nîmes

Le système doit télécharger son programme par un moyen decommunication, USB ou Bluetooth EIN1

Le système doit posséder un mode d’essai de mise au point etde vérification fonctionnelle in situ EOP1

Le système est placé par un opérateurdans la zone de départ Le système doit être préhensible manuellement EER1

L’opérateur sélectionne la valeur duparamètre p à intégrer

Le système doit exécuter la mission en fonction du paramètre p EFO1

Le système doit être capable de recevoir le paramètre p de lamission EIN3

L’opérateur lance le programmeLe système doit agir de manière autonome EFO2

Le système doit être mis en marche manuellement EIN2

Le système possède un mode opérationnel EOP3

Le système suit la ligne noire jusqu’àla première pastille Le système doit suivre les lignes tracées au sol EFO31

Le système analyse la couleur de lapastille Le système doit détecter la couleur de la pastille EFO32

Le système tourne Le système doit utiliser les pastilles de couleur comme indica-teur de changement de direction ou de positionnement EFO33

Le système détecte le stock Le système doit utiliser les pastilles de couleur comme indica-teur de changement de direction ou de positionnement EFO33

Le système détecte la présence ou l’ab-sence d’un élément Le système doit détecter la présence ou l’absence d’un élément EFO5

Page 46/101

Phase Exigence Référence

Le système analyse la couleur de l’élé-ment Le système doit analyser la couleur de l’élément EFO7

Le système saisit l’élément Le système doit saisir un ou plusieurs éléments EFO6

Le système recule et transportel’élément au bon stock

Le système doit être capable de stocker un ou plusieurs élé-ments EFO8

Le système doit amener tous les éléments de sa couleur dansson stock d’arrivée SA EFO91

Le système doit amener tous les éléments de l’adversaire dansle stock partagé de départ SPD EFO92

Le système dépose l’élément dans lestock Le système doit être capable de lâcher un ou plusieurs éléments EFO10

Le système contrôle la présenced’élément dans le stock partagé

Le système doit s’occuper des pièces dans le SPE de manièreprioritaire EFO4

Le système doit prendre en compte la pièce en attente dansSPE avant un délai de 2 minutes après l’apparition de celle-ci EPE4

Le système retourne dans la zone d’at-tente

Le système doit revenir dans la zone de départ une fois lamission accomplie EFO11

Le système s’arrête si un obstacle estprésent sur sa route Le système doit s’arrêter en cas d’obstacle sur son chemin ESF1

L’opérateur relance le programme Le système doit pouvoir être relancé par l’opérateur de l’équipe EIN4

Le système effectue sa mission de tridans les conditions et délais imposés

Le système doit agir de manière autonome EFO2

Le système doit réaliser la mission en un minimum de temps EPE1

Le système doit réaliser la mission dans un délai prescrit de4 minutes EPE2

Le système doit réaliser la mission sans dépasser 6 minutes EPE3

Le système doit posséder un mode d’essai de mise au point etde vérification fonctionnelle in situ EEO1

Le système doit posséder un mode veille EEO2

Le système doit posséder un mode opérationnel EEO3

Le système doit être capable d’être redémarré EEO4L’opérateur effectue les opérations demaintenance sur le système entredeux missions successives

Le système doit avoir un mode maintenance EOP5

Le système doit être maintenable EMA1

L’opérateur effectue les opérations demaintenance sur le système pendantla mission

Le système doit être maintenable EMA1

Après la maintenance, le système doit pouvoir reprendre samission à l’endroit où il s’est arrêté ou à l’endroit où il a quittéla piste

EMA2

Le système doit pouvoir être redémarré EOP4

Le système doit avoir un mode de maintenance EOP5

Le système effectue 3 missionssuccessives sur une période de servicemaximale de 4 heures

Le système doit avoir un mode de maintenance EPE5

Le système doit posséder un mode veille EOP2

Le système doit posséder un mode opérationnel EOP3

Le système doit pouvoir être stocké entre les missions EST2

Page 47/101

5.3.2 Plan de validation des exigences réglementairesLe développement du système doit suivre les règles établies par l’AFIS, un plan de validation réglementaire

est donc nécessaire.

Exigence réglementaire Référence de l’exigence Validation

Le système doit être conçu par des étudiants ou membres de clubs ou associ-ations des Universités et Grandes Écoles francophones de niveau BAC+3 àBAC+6 dans une discipline d’ingénierie

CCR1 Validé

Le système doit être développé pour le 18 novembre au plus tard CCR2 Validé

Le système doit être développé et réalisé uniquement avec des constituantsappartenant au kit fourni par l’AFIS CCR3 Validé

Le système doit être piloté à partir de l’outil de programmation du kit princi-pal ou d’une programmation basée sur les langages C ou Java CCR4 Validé

Le système doit pouvoir tenir dans un cube de 300mm×300mm×300mmlorsqu’il se trouve au repos CPH1 Validé

Le système doit être assemblable en moins de 20 minutes CMS1 Validé

Page 48/101

CHAPITRE 6

DOSSIER D’ÉTUDE DEMAINTENABILITÉ - DÉFINITION DE LA

MAINTENANCE

6.1 Dossier d’études de maintenabilité (LOT 61)

Dans cette section, un ensemble des scénarii propres aux opérations de maintenance est identifié etreprésenté comme suit :

Scénario Description

SCM1 Roue arrière se détache

SCM2 Roues avant se détachent

SCM3 Pneus déjantés

SCM4 Les capteurs ne marchent plus

SCM5 Les moteurs des roues ne répondent pas correctement

SCM6 Le moteur de la préhension ne répond pas correctement

SCM7 Câbles défaillants

SCM8 Les câbles empêchent le robot de faire sa mission

SCM9 Problème d’importation du programme sur le NXT

SCM10 Problème de batterie

SCM11 Bug programme

SCM12 Une pièce LEGO se casse ou est endommagée

SCM13 Une pièce LEGO se détache

SCM14 Le robot perd l’équilibre

SCM15 Le robot perd la ligne noire

Page 49/101

Suite à l’ensemble des scénarii listés ci-dessus, le référentiel des exigences est réalisé.

Decription des contraintes et exigences

EM1 Le système doit être maintenable.

EM2 Après la maintenance, le système doit pouvoir reprendre sa mission à l’endroit où il s’est arrêté

ou à l’endroit où il a quitté la piste.

CM1 Le système doit être maintenable en moins de 5 minutes

CM2 Le système doit être reconstruit conformément à l’assemblage d’origine.

CM3 Le système doit être vérifiable par un test automatique complet.

CM4 Le système doit posséder un logiciel interne rechargeable.

CM5 Le système doit être maintenable sur le lieu de l’incident technique.

EOP4 Le système doit pouvoir être redémarré.

EOP5 Le système doit avoir un mode de maintenance.

6.2 Plan de maintenance (LOT 62)

Le tableau suivant représente la liste exhaustive des opérations de maintenance préventives et curativescorrespondant aux scénarii de maintenance.

Scénario Opérations préventives Opérations curatives

SCM1 Vérifier la fixation de la roue arrière Rattacher la roue

SCM2 Vérifier que la roue arrière est bien mise Remettre le robot debout et vérifier la roue

SCM3 Vérifier que les pneus épousent la forme desjantes et effectuer un tour de roue à la main

Remettre le pneu en place et vérifier l’étatde celui-ci.

SCM4 Vérifier la propreté des capteurs Vérifier la propreté des capteurs

Utiliser les programmes de test du NXT Refaire les branchements et/ou changer lescâbles

Vérifier que les capteurs sont bien branchés Utiliser les programmes de test du NXT

SCM5 Comparer la rotation des deux moteurs Refaire les branchements et/ou changer lescâbles

Utiliser les programmes de test du NXT Utiliser les programmes de test du NXT

Vérifier que les moteurs sont bien branchés Vérifier que les moteurs sont bien branchés

Vérifier que les pneus ne frottent pas contreles moteurs

Vérifier que le pneu n’est pas déjanté(SCM3)

SCM6 Utiliser les programmes de test du NXT Utiliser les programmes de test du NXT

Vérifier que le moteur est bien branché Vérifier que le moteur est bien branché

SCM7 Tester le câble avec un capteur ou servomo-teur non défaillant

Remplacer le câble défaillant par un fonc-tionnel

SCM8 Vérifier que les câbles ne bloquent ni lesroues, ni le système de préhension

Remettre en place les câbles

SCM9 Vérifier qu’aucun autre programme n’est encours sur le NXT

Changer de mode de connexion

Vérifier que la place est suffisante dans lamémoire du NXT

Si cela ne suffit pas, redémarrer le robot

Vérifier que le NXT et le PC arrivent bien àétablir une connexion

SCM10 Vérifier l’état de charge des piles Changer les piles

Page 50/101

SCM11 Effectuer un tour de test Stopper le robot et modifier le code

SCM12 Vérifier l’état des LEGO Remplacer les pièces cassées par des piècesidentiques du kit

SCM13 Vérifier que les pièces sont bien fixées entreelles

Remettre en place les pièces et éventuelle-ment changer le connecteur si celui-ci estendommagé

Vérifier l’état de la pièce LEGO connecteur

SCM14 Vérifier le montage Remettre le robot en place

SCM15 Mettre en place le robot de façon à ce qu’iltrouve la ligne en début de mission

Remettre le robot en place

6.3 Fiches de maintenances (LOT 63)

Pour chaque opération de maintenance, les données suivantes seront indiquées :– La liste des éventuels composants de rechange nécessaires ;– La liste des outillages nécessaires pour l’intervention : test et démontage/remontage/réglage ;– Le temps d’intervention ;– Le mode opératoire succinct.

SCM1 : Roue arrière se détache

Composant de rechange Aucun

Outillage pour l’intervention Mains de l’opérateur

Notice de montage

NXT

Temps d’intervention 3 minutes

Mode opératoire1. Stopper le programme en cours

2. Vérifier qu’aucune pièce n’est endommagée ou cassée sinonvoir scénario SCM13

3. Puis remettre la roue en place selon l’énoncé du guide demontage

4. Utiliser un programme test pour vérifier que la roue reste enplace lorsque le robot se déplace en translation et rotation

Page 51/101

SCM2 : Roue avant se détache



Notice de montage

NXT




3. Puis remettre la roue en place selon l’énoncé du guide demontage

4. Utiliser un programme test pour vérifier que la roue reste enplace lorsque le robot se déplace en translation et rotation

SCM3 : Pneu(s) déjanté(s)



Notice de montage

NXT




3. Puis remettre le pneu en place selon la notice de montage

4. Utiliser un programme test pour vérifier que le pneu resteen place lorsque le robot se déplace

Page 52/101

SCM4 : Les capteurs ne marchent plus

Composant de rechange Câble

Capteur


Schéma d’interconnexion électrique

NXT



2. Vérifier que les capteurs sont propres et bien branchés avecla fiche d’interconnexion électrique

3. Utiliser le programme test du NXT pour vérifier le fonction-nement du capteur

4. Vérifier l’état du câble (cf. SCM7)

5. Si le capteur ne marche toujours pas, décréter qu’il est défail-lant et utiliser un capteur de rechange identique si disponible

SCM5 : Les moteurs des roues ne répondent pas correctement


Moteur



NXT

Guide de montage



2. Vérifier visuellement que les moteurs sont bien branchésavec la fiche d’interconnexion électrique

3. Vérifier visuellement que le pneu n’est pas déjanté sinon seréférer à SCM 3

4. Vérifier visuellement que la roue ne frotte pas contre le mo-teur

5. Utiliser le programme test du NXT pour vérifier le fonction-nement du moteur

6. Vérifier l’état du câble (voir SCM7)

7. Si le moteur ne marche toujours pas, décréter qu’il est défail-lant et utiliser un moteur de rechange identique si disponible

Page 53/101

SCM6 : Le moteur de la préhension ne répond pas correctement


Moteur



NXT

Guide de montage



2. Vérifier visuellement que les moteurs sont bien branchésavec la fiche d’interconnexion électrique

3. Utiliser le programme test du NXT pour vérifier le fonction-nement du moteur

4. Vérifier l’état du câble (voir SCM7)

5. Si le moteur ne marche toujours pas, décréter qu’il est défail-lant et utiliser un moteur de rechange identique si disponible

SCM7 : Câbles défaillants





2. Vérifier le bon enclenchement du câble sur le servomoteuret le NXT

3. Tester le câble sur un capteur ou servomoteur non défaillantà l’aide d’un programme test NXT

4. Si le câble ne marche toujours pas, changer le câble testé

SCM8 : Les câbles empêchent le robot de faire sa mission




Mode opératoire1. Vérifier visuellement que les câbles ne gênent pas le déplace-

ment du robot

2. Modifier la position des câbles

3. Utiliser un programme test pour vérifier que la nouvelleposition des câbles ne gêne pas le déplacement du robot entranslation et rotation

Page 54/101

SCM9 : Problème d’importation du programme sur le NXT

Composant de rechange Câble USB a/b


NXT

PC avec RobotC

Code source


Mode opératoire1. Connecter le NXT et le PC par câble

2. Vérifier que le NXT est allumé

3. Vérifier que le PC détecte et reconnaît le NXT

4. Établir la connexion

5. Valider le code sur le NXT si demandé

6. Charger le code

SCM10 : Problème de batterie

Composant de rechange Piles




2. Retirer les piles usagées et les remplacer par les nouvellespiles

SCM11 : Bug programme

Composant de rechange Nouveau code source


NXT

PC avec RobotC

Code source



2. Identifier l’erreur en fonction de la tâche et des conditionsdu robot lors de l’erreur

3. Modifier le code erroné

4. Tester les étapes litigieuses en mode débogage

5. Remplacer l’ancien programme par le nouveau

Page 55/101

SCM12 : Une pièce LEGO se casse ou est endommagée

Composant de rechange Pièce LEGO


Guide de montage



2. Repérer visuellement la pièce endommagée ou cassée

3. La remplacer par une pièce identique en bon état selon leguide de montage

SCM13 : Une pièce LEGO se détache



Guide de montage



2. Vérifier visuellement l’état de la pièce qui se détache et celuide son connecteur LEGO qui la relie au sous-système durobot

3. Si une des pièces est en mauvais état, suivre le scénario SCM12, sinon remettre en place la pièce détachée selon le guidede montage

SCM14 : Le robot perd l’équilibre



Guide de montage

Guide de maintenance



2. Vérifier visuellement l’assemblage du robot

3. Si il y a problème au niveau de l’assemblage, voir le scénariocorrespondant au problème

4. Remettre le robot en place

Page 56/101

SCM15 : Le robot perd la ligne noire



Temps d’intervention 1 minute

Mode opératoire1. Vérifier visuellement l’assemblage du robot

2. Remettre le robot en place

3. Appuyer sur le bouton pour reprendre la mission

6.4 Validation du plan de maintenance (LOT 64)

La validation du plan de maintenance est décrite dans le lot 40 du rapport.

Page 57/101

CHAPITRE 7

MANAGEMENT DU PROJET

7.1 Organisation et suivi de projet (LOT 71)

7.1.1 Organisation au sein de l’équipeL’équipe Robos’πR est constituée de 10 étudiants. Ce nombre relativement élevé nécessite une certaine

organisation afin d’éviter des problèmes de communication. L’équipe a utilisé de nombreux logiciels, certainspour interagir au sein de l’équipe et d’autres pour partager des données.

La communication indirecte à travers l’équipe a pu se faire facilement grâce à la création d’une mailing list.Cette mailing a permis que tous les acteurs du projet soient informés par mail sur l’actualité et l’avancementdu projet, même si la personne n’était pas impliquée directement sur le sujet évoqué. Chacun pouvait doncréagir et exposer son point de vue sur les différents sujets.

Pour la partie partage des données, plusieurs moyens ont été utilisés :– Pour le partage du code source de l’intelligence artificielle, le logiciel Git a été utilisé. C’est un logiciel

de versioning permettant de stocker l’évolution des versions d’un fichier et permettant en plus detravailler à plusieurs, au même moment, sur un fichier, sans que des conflits apparaissent au momentde la sauvegarde. Tous les fichiers étant sauvegardés sur un serveur afin de pouvoir y accéder depuisn’importe quel ordinateur. Le même système a été utilisé pour le rapport.

– Pour le partage de fichiers tels que des fichiers Catia, des images et des vidéos, nous avons utiliséla plateforme collaborative "Swym" développée par Dassault. Cette dernière permet de visualiser lesmodèles 3D directement dans le navigateur.

Afin de coordonner le travail de chacun et surtout de pouvoir tous se rassembler, nous organisions desréunions hebdomadaires. Ces réunions permettaient de réunir notre groupe de travail provenant de 2 écoleset donc de 2 campus séparés. Les réunions étaient l’occasion d’échanger sur les sujets sur lesquels tous lesétudiants étaient impliqués, quel que soit leur spécialité et de discuter sur l’avancement du projet.

7.1.2 Répartition du projetLe projet RobAFIS peut être découpé en 2 parties. Une partie mécanique qui concerne le montage et la

conception du robot et une partie informatique qui concerne le développement de l’IA, c’est-à-dire la stratégiequ’adoptera le robot durant cette mission. Les 2 parties ne sont pas pour autant indépendantes l’une del’autre mais leur développement peut s’effectuer en parallèle. Grâce à cela, la répartition des tâches s’esteffectuée simplement. Les élèves provenant de Supméca, ayant un profil de mécanicien, s’occupent de la partiemodélisation de la solution du robot et les élèves de l’Eisti s’occupent de la partie développement de l’IA.Toute l’équipe s’occupe de la conception du robot.

Page 58/101

FIGURE 7.1 – Répartition du projet

7.1.3 Jalons

Numéro Livrable/Jalon Date d’échéance

1 Présentation du projet 09/09/13

2 Recrutement de l’équipe EISTI 13/09/13

3 Recrutement des membres Supméca 30/09/13

4 Inscription au concours 15/09/13

5 Confirmation de l’inscription 01/10/13

6 Réception de la boite LEGO 21/10/13

7 Rendu dossier de développement 18/11/13

8 Départ pour la compétition 25/11/13

9 Dépôt des posters 26/11/13

10 Compétition 26 et 27 /11/2013

7.1.4 WBS

FIGURE 7.2 – Work Breakdown Structure

Page 59/101

FIGURE 7.3 – Gantt prévisionnel

Page60/101

7.1.5 Bilan des points d’avancement– 13/09/2013 : 1ère réunion

L’équipe informatique est constituée de 7 élèves. Ils seront encadrés par 2 tuteurs. Un chef de projet,dont le rôle sera de suivre l’avancement du projet, d’organiser les réunions a été désigné. 2 opérateurssont sélectionnés. Les discussions portent sur la création de la table. A-t-on tout le matériel nécessaire ?Comment créer les stocks ? Une salle de travail est désignée afin de pouvoir y stocker le matériel enpermanence.

– 20/09/2013 : 2ème réunionRépartition du travail :– Un groupe s’occupera d’analyser le sujet, de remonter les exigences ;– Un groupe s’occupera de faire une première IA qui permet de suivre une ligne et de tourner et de

tester capteurs et moteurs ;– Un dernier groupe s’occupera de la préhension d’une balle sur un stock.

– 3/10/2013 : 3ème réunionÉquipe des mécaniciens :– Simulation du châssis sur le parcours avec Catia V6 et de la préhension des balles.Équipe des informaticiens :– Diagramme d’activité : montage, maintenance, déplacement ;– Demande d’un PC avec Catia pour l’équipe informatique.– Planification de déplacement pour Nîmes ;– Utilisation de Dymola afin de simuler les mouvements du robot ;– Compréhension de l’ingénierie système ;– Récupération des caractéristiques des moteurs en LEGO afin de pouvoir procéder à la simulation sur

logiciel.– 10/10/2013 : 4ème réunion

Les différents capteurs ont été testés. Un premier prototype de robot suiveur de ligne a été créé afin devoir comment fonctionne un robot basique et prendre en main le logiciel pour l’IA. Nous avons utilisé 2capteurs pour suivre une ligne (de chaque côté de la ligne) afin de permettre une gestion plus fine dudéplacement.

– 11/10/2013 : 5ème réunion– Discussion autour des questions à poser au comité RobAFIS et du mode de déplacement à utiliser : 2

chenilles ou 3/4 roues ;– Démonstration du robot suiveur de ligne au groupe des mécaniciens ;– Réalisation des tests afin de valider la solution de déplacement ;– Management du projet attribué à l’équipe des informaticiens ;– Avancement de diagrammes des exigences ;– Diagramme d’activité : la stratégie utilisée ne doit pas y apparaître pour l’instant.

– 20/10/2013 : 6ème réunion– Envoyer un mail au comité RobAFIS pour les questions soulevées ;– Finir le robot pour pouvoir avancer le rapport ;– Finir l’organisation du voyage pour pouvoir acheter les billets.

– 7/11/2013 : 7ème réunion– Faire les points sur le document à livrer ;– Ajouter les mécaniciens au Gitlab ;– Mettre à jour les exigences ;– Agrandir les diagrammes du lot 23 ;– S’assurer de la lisibilité avec les couleurs ;– Déposer une version du rapport sur Swym ;– Créer un fichier Excel pour suivre au mieux l’avancement.

– 14/11/2013 : 8ème réunion– Organiser la semaine suivante ;– Finir le lot 40 ;– Rédiger le lot 80 en tenant compte du fait que 2 opérateurs effectuent le montage du robot et déposer

la notice de montage sur Swym.

Page 61/101

7.1.6 Compte rendu de revue interne de fin de développementLe prototype final est capable de réaliser la mission pour laquelle il a été conçu tout en respectant les

exigences et contraintes du cahier des charges. Les performances semblent très intéressantes par rapport à ladurée maximale de la mission évoquée dans le cahier des charges. Grâce à une bonne organisation qui a étépermise par l’utilisation de bons outils de communication et la tenue de réunion hebdomadaire, la missions’est déroulée dans de bonnes conditions. La communication entre le groupe des informaticiens et celui desmécaniciens s’est bien passée, ce qui a permis de travailler en parallèle sur différentes parties tout en se tenantau courant des évolutions de l’autre groupe. Les dernières tâches à effectuer sont l’entrainement au montagedu robot ainsi que pour la soutenance et la réalisation des posters pour la compétition.

7.2 Pilotage par la qualité, les coûts et les délais (LOT 72)

7.2.1 Études d’analyse de la valeur réalisées relatives au coût du produit et au coût deson développement

La qualité du travail ainsi que le respect des délais ont été contrôlés tout au long du projet dans l’optiqued’obtenir le meilleur résultat possible.

Le projet a commencé par l’analyse du travail à réaliser qui a fait ressortir les exigences à respecter et lesactions que notre robot devait pouvoir effectuer. La qualité du travail effectué lors de cette première étape apermis de partir sur de bonne base pour avancer par la suite dans les meilleures conditions.

Les délais ont été suivis grâce à la réalisation au préalable d’un Gantt qui nous a permis de suivre, jouraprès jour, l’avancement du travail et ce, tout en tenant compte de la charge de travail de chacun.

7.2.2 Courbe d’évolution du développement en homme/jourLe graphique suivant représente l’évolution du coût de développement du robot exprimé en homme/jour.

Il a été réalisé à partir des phases importantes du projet.

FIGURE 7.4 – Évolution du coût en homme/jour

Page 62/101

FIGURE 7.5 – Répartition de la quantité de travail

7.2.3 Courbe d’évolution du coût unitaire du robotLe graphique suivant représente l’évolution du coût du robot calculé à partir du tableau des coûts des

pièces et des pièces utilisées pour construire le robot.

FIGURE 7.6 – Evolution du coût du robot

Au final, la solution retenue a un coût de 208 en utilisant au total 161 pièces LEGO. Grâce à une phased’optimisation, le coût du robot n’a pas toujours croît. À partir de la version 3, l’accent a été mis sur l’utilisationdu nombre de pièces afin de réduire le coût du robot tout en améliorant ce dernier. Le tableau 7.7 montre lecoût de la dernière version du robot ainsi que les pièces utilisées et leur nombre.

Page 63/101

FIGURE 7.7 – Tableau de coût

Référence article Désignation article Quantité Coût unitaire Coût total

4210857 Connecteur 1 croix/2 cercles (gris) 2 1 2

4121667 Connecteur 2 croix/1 cercle (noir) 4 1 4

4239601 Bague mince (jaune) 4 1 4

4206482 Connecteur cercle/croix (bleu) 9 1 9

4211622 Bague large (grise) 6 1 6

4514553 Connecteur 3U (bleu) 8 1 8

4121715 Connecteur 2U (noir) 52 1 52

4225033 Connecteur 3w (gris) 6 1 6

4140801 Connecteur 2U + stop (noir) 4 1 4

4211775 Connecteur cercle/croix (gris clair) 2 1 2

4210668 Angle 5x9 (gris) 6 1 6

4210755 1x11 (gris) 2 1 2

4210751 1x3 (gris) 4 1 4

4495931 1x7 (gris) 4 1 4

4210753 5x3 (gris) 6 1 6

4522937 1x13 (gris) 3 2 6

4542576 1x15 (gris) 2 2 4

4645730 1x9 (gris) 6 1 6

4210667 4x2 (gris) 2 1 2

4210686 1x5 (gris) 2 1 2

4211815 Axe 3U (gris) 1 1 1

4142865 Axe 2U (rouge) 2 1 2

4566927 Axe 3U + stop (beige) 1 1 1

370626 Axe 6U (noir) 2 1 2

370726 Axe 8U (noir) 1 1 1

4514555 Biseau d’engrenage (jaune) 1 1 1

4297210 Jante (grise) 2 2 4

4297209 Pneu (noir) 2 2 4

4297174 Sonar 1 4 4

Capteur RGB 2 4 8

4296825 NXT 1 - -

4297008 Servomoteur 3 5 15

4296917 Capteur lumière 1 4 4

4297187 Câble court (20cm) 1 2 2

4297188 Câble moyen (35cm) 4 3 12

4297185 Câble long (50cm) 2 4 8

SYSTÈME COMPLET 208

7.3 Management des risques (LOT 73)

Ce plan de management des risques nous permet de lister les risques pouvant entraîner un échec ouun ralentissement de la mission. Pour chaque risque potentiel, on attribue un impact et une probabilitéd’apparition. Un seuil de déclenchement est donné indiquant à partir de quel moment on doit réagir afind’éviter l’apparition du risque. Un seuil de déclenchement bas indique que le risque a des chances d’arriver etqu’il sera gênant. Un seuil élevé indique un risque peu probable pouvant juste ralentir le projet.

Page 64/101

FIGURE 7.8 – Matrice de risques

No Libellé Commentaire Impact(1 à 5)

Probabilité(1 à 5)

Résultant(1 à 5)

Seuil de dé-clenchementrésultant (1 à 25)

Méthode d’évitement

1 Technique Usure / perte depièces LEGO 4 3 12 20

Utiliser d’anciens capteurs et moteurs pendantune majorité des tests pour ne pas user ceux pourle concours

2 Technique

Utilisation delogiciels nonutilisables parl’ensemble del’équipe

4 3 12 24 Obtenir des licences ou des ordinateurs avec leslogiciels posant problèmes

3 Humain Vacances 3 4 12 20 Continuer à communiquer et organiser des réu-nions durant les vacances

4 Humain

Détérioration dela communica-tion au sein del’équipe

5 1 5 15 Faire régner une bonne ambiance durant lesséances de travail

5 HumainIndisponibilitédu chef deprojet

3 2 6 22 Désigner un suppléant qui organisera les réu-nions à la place

6 Humain Manque de mo-tivation 5 1 5 20 Impliquer toute l’équipe dans le projet, gérer les

conflits

7 Humain Maladie 3 2 6 24 Prévoir des remplaçants des personnes malades

8 OrganisationManque depréparation desreprésentants

4 2 8 18 Définir et respecter des moments réservés à l’en-trainement en vue des présentations

9 OrganisationMauvais suividu travail dechacun

4 2 8 20 Réaliser un suivi de projet à chaque instant afinde réagir au plus vite si un problème intervient

10 Organisation

Utilisation delogiciels decommunicationnon adaptés

4 4 16 20Réaliser des tutos pour les outils posant problème,ne pas hésiter à abandonner un logiciel si pasadapté

11 OrganisationRépartitioninadaptée dutravail

5 2 10 20 Bien analyser le problème au départ et redis-tribuer le travail si mal adapté

12 Organisation

Communicationdifficile due à laséparation descampus

4 3 12 18 Réaliser des réunions hebdomadaires, mettre enplace de mailing, git, plateforme Swym

Page65/101

CHAPITRE 8

DOSSIER DE RÉALISATION (LOT 80)

8.1 Synoptique général du montage et de contrôle

Voici une vue éclatée des sous-assemblages du robot :

FIGURE 8.1 – Sous-assemblages du robot

Page 66/101

8.2 Description de l’organisation des postes de montage et de contrôle

Le montage du système peut être décomposé comme suit :

Sous-montages

Roue avant droite Roue avant gauche

NXT Roue arrière

Capteurs Châssis supérieur et préhension

Chacun de ses sous-systèmes seront mis dans des sachets afin de faciliter l’organisation des postes. Enaccord avec les conditions fixées par l’audit de configuration, deux opérateurs sont disponibles pour monter etcontrôler le système. Il y a deux postes disponibles, appelés poste A et poste B. L’organisation des postes demontages s’appuie sur des opérateurs expérimentés et rigoureux. Ainsi, une estimation de la longueur dechaque tâche a été réalisée pour optimiser l’assemblage.

Afin de faciliter l’assemblage, un grand sachet contenant les petits sachets des sous-systèmes sera présentépour chaque poste, ainsi que les manuels de montage associés.

Poste A Poste B

Roue avant droite Châssis supérieur et préhension

Roue avant gauche Montage final

Roue arrière Chargement du logiciel

NXT

Capteurs

L’ordonnancement des tâches ainsi que le schéma d’assemblage des sous-systèmes sont présentés dans lesschémas ci-après :

Poste A

Roue droite Roue gauche Roue arrière NXT Capteurs

Châssis supérieur / Préhension Montage final Chargementdu logiciel

Temps

FIGURE 8.2 – Schéma d’assemblage temporel

Poste B

Roue droite Capteurs Roue gauche NXT Roue arriere

Châssis supérieur/ Préhension

Sous-assemblage A1 Sous-assemblage A2 Sous-assemblage A3 Sous-assemblage A4

FIGURE 8.3 – Schéma mécanique d’assemblage

8.2.1 Gamme de montageLe montage des différents sous-systèmes et du système final est effectué exactement de la même manière

que dans la partie 5.1.

Page 67/101

8.2.2 Gamme de contrôleLes différents contrôles ont lieu exactement de la même manière que dans la partie 5.2.

8.2.3 Définition des moyens prévus pour le chargement du logicielLe système permettant les deux, le chargement du logiciel se fera par USB – au chargement initial comme

en maintenance – en se gardant la possibilité d’utiliser le Bluetooth si jamais le premier présente des dysfonc-tionnements.

Page 68/101

ANNEXE A

DIAGRAMMES D’EXIGENCES

Cet annexe reprend l’ensemble des diagrammes d’exigences réalisés pour le lot 12 du dossier de développe-ment (section 1.2). Ces diagrammes ont été réalisés en reprennant le formalisme SysML.

FIGURE A.1 – Diagramme SysML d’exigences du système

Page 69/101

A.1 Exigences fonctionnelles

FIGURE A.2 – Diagramme SysML d’exigences fonctionnelles

Page 70/101

A.2 Exigences de performances

FIGURE A.3 – Diagramme SysML des exigences de performance

A.3 Exigences d’interfaces (fonctionnelles, physiques)

FIGURE A.4 – Diagramme SysML des exigences d’interface

Page 71/101

A.4 Exigences opérationnelles

FIGURE A.5 – Diagramme SysML de modes et de scénarios opérationnels

Page 72/101

A.5 Contraintes

FIGURE A.6 – Diagramme SysML de contraintes de conception et de réalisation

Page 73/101

A.6 Exigences de validation

FIGURE A.7 – Diagramme SysML d’exigences de validation

Page 74/101

ANNEXE B

TESTS

B.1 Vérification de sûreté de saisie (T01)

Description du test

Le prototype démarre sur une ligne noire de suivi le menant à un stock d’entrée (SE ou SPE). Ce dernieravance jusqu’au stock et saisit la balle puis recule, toujours en suivant la ligne, durant 800ms, jusqu’à la pastillede changement de direction. Ensuite, le robot avance pour se présenter de nouveau devant le stock pourdéposer la balle, puis recule pendant 800ms.

Cette opération de saisie/dépôt de la balle sur un stock est répétée un grand nombre de fois, afin depouvoir valider la fiabilité de la préhension de la balle.

L’opération de saisie/dépôt a été répétée 30 fois lors de ce test. Les moteurs de déplacement ont été utilisésà 40% de la vitesse maximale de rotation, et le moteur affecté à la préhension a été utilisé à 20% de la vitessemaximale. Ces valeurs de vitesse de rotation du moteur on été choisies pour leur bon compromis entre rapiditéet fiabilité.

Résultats

1 sur 30 tests (96.9% de réussite)

L’échec a eu lieu vers la fin du test : les deux branches de la pince s’étaient légèrement écartés à la suite dunombre important de tests consécutifs. Ceci étant, le faible taux d’erreur est satisfaisant pour la durée de lamission.

B.2 Comparaison de la précision du suivi de ligne entre 1 et 2 capteursau sol (T02)

Description du test

Le robot doit suivre un ligne faisant un tracé en ligne droite. L’objectif du test est de comparer les vitessesde déplacement permises par deux systèmes de suivi de ligne :

– un seul capteur de couleur, situé au-dessus de la ligne à suivre– deux capteurs : un capteur de couleur est placé de part et d’autre de la lignePour ce test, on s’intéresse à la distance qu’est capable de parcourir le robot en 5 secondes avec chacun de

ces systèmes de détection de ligne. La vitesse des moteurs de traction est réglée à 40%.

Page 75/101

Résultats

Les résultats sont nettement en faveur du suivi de ligne avec deux capteurs. Le déplacement avec un seulcapteur est 23% moins performant que la version retenue. Ces résultats confortent le choix de conception faitsur le dispositif.

0 10 20 30 40 50 60 70 80 90 100

2 capteurs

1 capteur

89.5

69

Distance parcourue en 5 secondes (en cm)

L’écart observé sur ce test semble suffisant pour permettre justifier le choix de conception.

B.3 Détection de la couleur pour balles en fonction de la position ducapteur optique (T03)

Description du test

Pour ce test, on cherche à comparer deux positions du capteur permettant la détection de la couleur d’uneballe sur un stock (capteur de lumière). Dans le premier cas, le capteur de lumière est placé sur le côté dudispositif de préhension ; dans le second il est placé au-dessus de la pince, devant le moteur actionnant lapréhension.

Résultats

Le capteur sur le côté :

La couleur de la balle est reconnue dans le stock, quand la pince est ouverte. Cependant, si la pince estfermée, elle obstrue le capteur de lumière qui ne voit alors plus la couleur de la balle une fois saisie.

Un peu en marge de la détection de la couleur d’une balle, cet emplacement du capteur peut poser desproblèmes à l’approche du stock. En effet, si le robot se présent un peu en biais devant un stock d’entrée, lecapteur peut alors pousser la première balle du stock et en empêcher la saisie. Cet aléa justifie en grande partiele rejet de cette solution.

Le capteur en haut :

Ne peut pas détecter une balle dans le stock, mais est très fiable une fois la balle saisie. Cette optionnécessite au moins d’attraper une balle dans le stock (qui peut être vide), mais ne pose pas de problèmesrelatifs à la fiabilité de la saisie, contrairement à la solution précédemment testée.

B.4 Test de seuil de détection du capteur de couleur (T04)

Description du test

Par ce test, on cherche à déterminer la distance à laquelle le capteur RGB est en mesure de déterminercorrectement la couleur d’un élément (balle ou pastille au sol). Pour ce faire on place le capteur face contre unedes pastilles rouges. Ensuite, on déplace le capteur verticalement en mesurant la distance entre la pastille et lecapteur de couleur.

Résultats

Le capteur RGB fonctionne entre 0.2cm et 3cm

Ces résultats permettent de valider l’utilisation des capteurs de couleur pour le suivi de ligne et la détectiondes marqueurs au sol (indicateurs de stocks et de changement de direction), ces derniers étant placés à 1cm dela surface du plateau.

Page 76/101

B.5 Test de la précision de fonctionnement du sonar (T05)

Descritpion du test

On cherche à déterminer quelle est la précision effective du sonar. Pour ce faire on mesure à l’aide du sonarla distance jusqu’à une balle (obstacle le plus probable dans le cadre de la mission) et on évalue l’écart entre ladistance indiquée par le sonar et la distance réelle.

Résultats

0 5 10 15 20 25 30 35 40 450

10

20

30

40

50

60

Distance réelle (en cm)

Dis

tanc

em

esur

ée(e

ncm

)

Distance réelleDistance mesurée

Erreur

Les résultats sont assez bons, mais se dégradent en rapprochant le sonar de l’objet. Aussi, le sonar ne peutdétecter d’obstacle que entre 5 et 43 cm. Lors de nos tests, aucun objet situé à l’extérieur de cet intervalle n’aété détecté. Dans ces cas, le sonar retourne la distance maximale : 255 cm.

B.6 Test de la précision du sonar installé sur le robot (T06)

Description du test

On effectue le même test que précédemment. Cependant, cette fois le sonar est installé sur le robot, et setrouve donc en conditions de fonctionnement : le sonar est installé sur le robot selon le modèle final et lestests sont réalisés dans une reproduction du plateau de la compétition. Ainsi, le sonar se retrouve en positionplongeante au-dessus du robot.

Le sonar tente donc d’estimer la distance entre le robot immobile (on mesure à partir des deux capteursfrontaux de suivi de ligne) et la surface d’une balle de couleur. Deux séries de mesures on été réalisées :

– série no 1 : la balle est placée exactement en face (au milieu) du robot– série no 2 : la balle est placée sur le bord, en face des roues du robot

Il n’a pas été jugé nécessaire de faire de tests au-delà de la largeur du robot : un objet situé plus loin que lesroues de robot ne sera pas sur la trajectoire du robot et ne constitue pas stricto sensu un obstacle.

Pour la série no 1, des tests complets sur la précision du capteur ont été réalisés (entre autre pour compareravec le test précédent). Pour le test no 2, seul les bornes auxquelles le sonar peut détecter un objet ont étéreportées.

Page 77/101

Résultats

10 15 20 25 30 35 40 450

10

20

30

40

50

60

Distance réelle (en cm)

Dis

tanc

em

esur

ée(e

ncm

)

Distance réelleDistance mesurée (frontale)

Distance mesurée (bord)Erreur (frontal)

Ces résultats sont assez proches de ceux obtenus dans le test précédent. Avec son sonar, le robot est capablede détecter des obstacles situés entre 16 et 40 cm de l’avant du robot. Encore une fois, la détection est plusprécise quand l’objet est éloigné du capteur.

Aussi, pour les éléments situés au niveau de roues, la détection est possible entre 19 et 38cm.

De façon générale, on remarque que l’erreur est toujours la plus importante pour les objets proches etexcentrés par rapport au milieu du robot. On définira une zone «sûre» pour la détection des obstacles entre 20et 35cm devant le robot.

B.7 Test de détection effective d’obstacles avec le robot (T07)

Description du test

Afin de vérifier que le sonar satisfait les contraintes de sûreté de fonctionnement, la détection d’obstacles aété testée en conditions réelles de fonctionnement. En fonctionnement, le robot doit pourvoir détecter différentsobjets posés sur sa trajectoire alors qu’il est en déplacement. D’après les résultats du test B.6, la distance desécurité a été fixée à 25cm. Cette distance définit le seuil de détection d’obstacles : tout objet détecté à unedistance inférieure ou égale à 25cm provoque l’arrêt du robot.

Différents tests ont été réalisés pour vérifier que ce réglage est judicieux.

Un premier test a été fait sur la détection d’obstacle en mouvement. Une balle (obstacle le plus probabledans le cadre de la mission) a été placée sur la trajectoire du robot, ce dernier en déplacement à une vitessev = 40 (40% de la vitesse maximale), puis v = 100 (vitesse maximale de rotation des moteurs). Dans ces deuxcas on détecte la distance effective entre l’obstacle et le robot une fois ce dernier arrêté.

Un second jeu de test a été réalisé pour la détection de divers objets à l’arrêt. Des obstacles de formes et dedimensions diverses ont été disposés sur la trajectoire du robot, à 25cm de ce dernier.

Résultats

Vitesse du robot Détection de la balle Distance d’arrêt effective

v = 40 oui 25cm

v = 100 oui 17cm

Page 78/101

Ces résultats confortent les observations faites lors du test de précision du sonar. Quelle que soit la vitesse,la balle est bien détectée. À vitesse maximale des moteurs, on observe un délai pour la détection de l’obstacleet l’arrêt du robot. Ce délai n’est pas lié à la distance d’arrêt du robot (ce dernier peut en effet se stopperquasi-instantanément quelle que soit la vitesse) mais plus probablement aux vibrations amplifiées par la vitesse.

Obstacle Dimensions (surface présentée au sonar) Détecté à 25cm

Capteur LEGO Mindsorm 3cm × 4.5cm oui

Personnage LEGO 0.5 × 4cm oui

Tige LEGO 1 0.4cm × 10cm oui

Tige LEGO 2 0.4 × 2cm non

Superbe poney en plastique 9cm × 11cm oui

Seul un des objets testés n’a pas été détecté, très certainement à cause de sa trop petite taille. Nous avonsaussi constaté que dans certains cas, l’orientation d’un objet peut altérer la précision du sonar : c’est unequestion d’angle d’incidence des ondes émises par le sonar.

En outre, le sonar semble être capable de détecter à une distance de 25cm une grande variété d’objets. Cestests permettent de valider à la fois le choix et l’emplacement du sonar et le seuil de détection d’obstacles, fixéà 25cm.

Remarques

Bien que la surface sur laquelle le robot est posé ne soit situé qu’à 22cm du sonar, ce dernier ne le détectejamais car l’angle d’incidence est trop important pour que la surface plane sur laquelle le robot évolue neréfléchisse d’ondes en direction du capteur.

Ainsi, en l’absence d’obstacles, le sonar indique bien 255cm, soit aucun objet n’est détecté.

Page 79/101

ANNEXE C

GUIDE DE MONTAGE

Page 80/101

1

Composants du lot capteurs

2x (9 unités) 10x 4x

2x capteur RGB 2x

2x (5 unités)

1x

1

2

1x

3

1x 5x 2x 1x capteur RGB

1x

4

9 unités

5 unités

2

5

6

2x

7

1x 1x capteur RGB

1x

8

1x

5 unités

9

10

1x

11

2x 3x

9 unités

3

Composants du lot capteurs/châssis

2x 4x

1x (Capteur lumière)

2x 1x 1x (sonar)

9x 1x (7 unités) 2x (11 unités)

1x (3 unités)

1

2

1x lumière

3

1x 2x 1x

4

2x

4

5

6

7

8

1x 1x 1x

1xSonar

1x

9

10

11

12

1x 1x

3 unités

1x

1x

1x

11 unités

5

13

14

15

16

1x 1x

2x 1x

7 unités

Attention:

ne connecter qu’un

seul connecteur noir,

et laisser l’autre

connecteur reposer

sur la brique 1x11

17

18

1x

19

1x 1x

20

11 unités

6

Composants du lot châssis supérieur/préhension

1x 1x 4x

2x 2x 3x

13x 1x

2x


1x

1

2

2x

3

1x 2x 1x

4

2x

7

5

6

1x

7

1x 3x

8

1x

9

10

1x

11

1x Sous-système capteur/châssis

12

1x 1x 1x

7 unités

8

13

14

1x

15

1x 2x

16

1x

17

18

4x

19

2x 2x

20

2x

9

21

Composants du lot roue avant droite


2x 1x (7 unités) 1x

2x

1x 1x 1x

10

1

1x 2x

2

3x

3x

3

1x 1x 1x

9 unités 7 unités

4

1x 2x 1x

5

1x

Attention au

sens de la jante!

11

Composants du lot roue avant gauche


2x 1x (7 unités) 1x

2x

1x 1x 1x

1

1x 2x

2

3x

3x

3

1x 1x 1x

9 unités 7 unités

12

4

1x 2x 1x

5

1x

Attention au

sens de la jante!

Composants du lot NXT

1x 2x 6x

2x 1x

13

1

1x 2x

2

2x 2x

4x

3

1x

13 unités

Composants du lot roue arrière

2x 2x 1x 1x

2x 2x 6x

2x

1x (15 unités)

14

1

2x 2x

2

2x 2x

1x

3

1x

2x

2x

1x

2

2

3

1

4

5

4x 2x

6

2x 1x

2x

5

5

6

15 unités

15

Composants de l’assemblage final

1x

2x (9 unités)

1x 1x 1x


1 2

16

3 4

1x 1x

9 unités 9 unités

5 6

1x

15 unités

17

7

1x

15 unités

8

9 10

1x

15 unités

18

RÉFÉRENCES

Moyens consommés

b SwYm : https://placis.cloud.3ds.com/b CatiaV6 : http://www.3ds.com/fr/produits-et-services/catia/portefeuille/catia-v6/b Artisan Studio : http://www.atego.com/products/artisan-studio/b StarUML : http://staruml.sourceforge.net/en/b RobotC : http://www.robotc.net/b LATEX : http://www.latex-project.org/b Gitlab : http://gitlab.org/

b Git : http://git-scm.com/b GoogleGroups : https://groups.google.com/

Bibliographie

Z AFIS, Référentiel de Développement, 2013Z AFIS, Cahier des charges applicable au Système RobAFIS, 2013Z AFIS, Découvrir et comprendre l’Ingénierie Système, 2009Z Pascal Roques, SysML par l’exemple , Un langage de modélisation pour systèmes complexes, EYROLLES, 2013Z Jon Holt et Simon Perry, SysML for Systems Engineering, 2007Z AFIS, Guide AFIS Penser système, 2012

Page 99/101

https://placis.cloud.3ds.com/

http://www.3ds.com/fr/produits-et-services/catia/portefeuille/catia-v6/

http://www.atego.com/products/artisan-studio/

http://staruml.sourceforge.net/en/

http://www.robotc.net/

http://www.latex-project.org/

http://gitlab.org/

http://git-scm.com/

https://groups.google.com/

TABLE DES FIGURES

2.1 Aperçu en vue isométrique de la version finale de Robos’πR . . . . . . . . . . . . . . . . . . . . 122.2 Vue avant et arrière de Robos’πR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3 Vue droite et gauche de Robos’πR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Vue de dessus et en-dessous de Robos’πR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 Diagramme d’activité pour la mission nominale . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.6 Diagramme de cas d’utilisation au niveau système . . . . . . . . . . . . . . . . . . . . . . . . . . 162.7 Diagramme d’activité : analyse fonctionnelle statique . . . . . . . . . . . . . . . . . . . . . . . . 162.8 Diagramme de séquence du déplacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.9 Diagramme de séquence de la rotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.10 Diagramme de séquence de la préhension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.11 Arborescence organique/physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.12 Architecture organique/physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Schéma général d’interconnexion électrique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2 Schéma cinématique du système Robos’πR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3 Configurations possibles du système de préhension . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Méthodologie de validation du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2 Méthodologie de validation des sous-systèmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3 Liste des solutions imaginées pour le système de déplacement . . . . . . . . . . . . . . . . . . . 354.4 Schémas de différents essais pour le système de déplacement (troisième roue) . . . . . . . . . . 354.5 Liste des solutions imaginées pour le système de préhension . . . . . . . . . . . . . . . . . . . . 364.6 Photographies des évolutions de la solution No 5 de préhension . . . . . . . . . . . . . . . . . . 364.7 Liste des solutions imaginées pour le système de déplacement . . . . . . . . . . . . . . . . . . . 374.8 Photographies de différents systèmes permettant le suivi de ligne . . . . . . . . . . . . . . . . . 374.9 Liste des solutions imaginées pour le système de détection de l’élément sur un stock d’entrée . 384.10 Photographies de différents approches pour la détection de la couleur de la balle . . . . . . . . 384.11 Liste des solutions imaginées pour le système de détection des obstacles sur le plateau . . . . . 394.12 Photographies de différents systèmes de détection d’obstacle. . . . . . . . . . . . . . . . . . . . 39

7.1 Répartition du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597.2 Work Breakdown Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597.3 Gantt prévisionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607.4 Évolution du coût en homme/jour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627.5 Répartition de la quantité de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637.6 Evolution du coût du robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637.7 Tableau de coût . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647.8 Matrice de risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

8.1 Sous-assemblages du robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668.2 Schéma d’assemblage temporel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Page 100/101

8.3 Schéma mécanique d’assemblage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

A.1 Diagramme SysML d’exigences du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69A.2 Diagramme SysML d’exigences fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70A.3 Diagramme SysML des exigences de performance . . . . . . . . . . . . . . . . . . . . . . . . . . 71A.4 Diagramme SysML des exigences d’interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71A.5 Diagramme SysML de modes et de scénarios opérationnels . . . . . . . . . . . . . . . . . . . . . 72A.6 Diagramme SysML de contraintes de conception et de réalisation . . . . . . . . . . . . . . . . . 73A.7 Diagramme SysML d’exigences de validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Page 101/101

Documents

Dossier Developpement RobAFIS 2013 Collegium IDF