Impl ementation d’un logiciel de simulation de robot … · 2016-04-11 · toujours soutenus et encourag es au cours de la r ealisation de ce m emoire. Nous voulons aussi remercier

UNIVERSITE CATHOLIQUE DE LOUVAINECOLE POLYTECHNIQUE DE LOUVAIN

Implementation d’un logiciel desimulation de robot mobile autonome

en vue d’optimiser les performances denavigation

Promoteur : Charles Pecheur

Co-promoteur : Steve Tumson

Lecteur : Marc Lobelle

Memoire presente en vue de l’obtention

du grade de master en science informatique

et du grade de master ingenieur civil en

informatique.

Option : Software engineering

Par : Julien Bergiers & Julien Henricot

Louvain-la-NeuveAnnee academique 2013 - 2014

Table des matieres

I Preliminaires 1

1 Prerequis 3

1.1 Produits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Principe de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Etat de l’art 5

2.1 Planificateur de jardin Viking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Simulateur issu du projet ArduMower . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Projet etudiant de l’universite de Bourgogne . . . . . . . . . . . . . . . . . . . . 7

2.4 Simulateur de robots tondeuses par Alexander Grau . . . . . . . . . . . . . . . . 8

2.5 Les pseudo-simulateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5.1 Robot Vacuum Simulator 2013 . . . . . . . . . . . . . . . . . . . . . . . 9

2.5.2 Lawn Mower Simulator York College of Pennsylvania . . . . . . . . . . . 10

2.5.3 Jeu Lawn Mower 1988 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6 Conclusion des recherches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Methode de travail 13

3.1 Methodologie Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Etapes d’un sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Enonce du probleme 17

4.1 Objectifs architecturaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Objectifs fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

II Solution 21

5 Description du logiciel 23

5.1 Editeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3

5.2 Simple simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3 Multi-simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6 Methodes d’evaluation 39

7 Validation 41

7.1 Test de comportement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.2 Test d’un cas concret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

III Architecture 49

8 Generale 51

8.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

8.2 Categorie d’objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

9 Graphisme 55

9.1 Composantes de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

9.2 Listes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

9.3 Moteur graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

9.4 Gestionnaire de ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

10 Editeur 59

10.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

10.2 Objets existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

10.3 Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

10.4 Google Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

11 Simulateur 61

11.1 Prerequis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

11.1.1 Les parametres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

11.1.2 Les statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

11.2 Le robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

11.2.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

11.2.2 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

11.2.3 Modules existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

11.3 La navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

11.3.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

11.3.2 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

11.3.3 Algorithmes de navigation . . . . . . . . . . . . . . . . . . . . . . . . . . 70

11.4 L’environnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

11.4.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

11.4.2 Affichage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

11.5 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

12 Algorithmes de navigation 75

12.1 Navigation classique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

12.2 Navigation GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

13 Algorithmes particuliers 77

13.1 A-star . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

13.2 Champ magnetique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

IV Conclusion et perspectives 81

14 Rappel des objectifs 83

15 Solution developpee 85

16 Ameliorations et perspectives 87

16.1 Simulateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

16.2 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

17 Conclusion 89

18 References 91

V Annexe 93

A Backlog 95

B Cahier des charges 97

Remerciements

En preambule a ce memoire, nous souhaitons adresser nos remerciements les plussinceres aux personnes qui nous ont apporte leur aide et qui ont contribue a l’elaborationde ce memoire, ainsi qu’a la reussite de cette derniere annee universitaire.

En premier lieu, nous tenons a remercier le Professeur Charles Pecheur, notrepromoteur, pour ses precieux conseils, ainsi que pour le temps et l’ecoute qu’il nous aaccordes tout au long de notre travail.

Nous tenons egalement a remercier tout particulierement Steve Tumson, ingenieuren electro-mecanique a la societe BelRobotics. En tant que co-promoteur, maıtre destage et initiateur de notre projet de memoire, il a su nous guider dans notre travail etprendre le temps de nous aider a trouver des solutions pour avancer. Nous le remercionspour son accueil et la confiance qu’il nous a accordee, et cela des le debut du projet.

Nous n’oublions pas nos familles pour leur contribution, leur soutien et leur pa-tience, qui nous ont aides a surmonter bien des obstacles.

Un remerciement est egalement adresse a tous nos proches et amis, qui nous onttoujours soutenus et encourages au cours de la realisation de ce memoire.

Nous voulons aussi remercier Hassan, pour sa bonne humeur et pour son invitation,durement negociee, a la friterie.

Un grand merci est adresse a l’ensemble de l’equipe de chez BelRobotics, pour leuraccueil, leur sympathie et le temps qu’ils nous ont consacres dans le cadre du stagelie a ce memoire.

Nous tenons aussi a remercier toute personne qui a participe, de pres ou de loin, al’execution de ce travail de fin d’etudes.

i

Resume

Notre sujet de memoire touche une importante innovation technologique de cettedecennie, les robots tondeuses autonomes. La technologie des tondeuses robotiquesest en pleine expansion, de nombreuses societes se developpent a travers le monde,les techniques existantes evoluent et de nouvelles innovations apparaissent continuel-lement.

Il devient necessaire de pouvoir tester rapidement et facilement les nouvelles amelio-rations possibles afin d’evaluer leurs impacts sur les performances de ces robots. Al’heure actuelle, lorsqu’une equipe desire tester une nouvelle solution, elle doit soittenter de demontrer mathematiquement son impact, soit concevoir un prototype et lefaire tourner sur un terrain de test pendant plusieurs jours avant d’obtenir des resultatspermettant d’evaluer l’amelioration. De plus, il n’existe pas encore de criteres permet-tant d’evaluer les performances des algorithmes de navigation.

La solution a ce probleme consiste a implementer un logiciel de simulation derobot mobile autonome dans son environnement de travail. Un tel logiciel permettraitde faciliter le developpement et la validation des futures ameliorations. Il est egalementnecessaire de definir ces criteres, afin d’evaluer de maniere objective les performancesdes robots dans leur environnement.

Nous avons donc entierement developpe un logiciel en Java, que nous avons nomme“Java Robot Simulateur”. Il offre la possibilite d’evaluer l’evolution d’un robot ton-deuse autonome dans son environnement de travail. JRS possede un editeur d’envi-ronnement ainsi qu’un editeur de robot permettant ainsi des combinaisons infinies detests. De plus, celui-ci produit un ensemble de donnees.

Notre outil permet de tester rapidement et efficacement les nouvelles ameliorationsapportees a l’elaboration des nouveaux robots tondeuses et d’evaluer leurs impacts surles performances des nouvelles machines. Celui-ci est deja en oeuvre dans la societeBelRobotics et a fait ses preuves au sein de l’equipe de recherche et developpement.

iii

Introduction

“Qu’arriverait-il si l’humanite quittait la planete en oubliant de debrancher le dernier robot.”

Andrew Stanton, vice−directeur artistique du studio P ixar.

Une chose est sure, les pelouses continueraient d’etre bien tondues !

Vous l’aurez compris, notre sujet de memoire touche une importante innovationtechnologique de cette decennie : les robots tondeuses autonomes. Les robots ton-deuses ont ete inventes par l’ingenieur Belge Andre Collens et ont pour vocation detondre les pelouses de maniere entierement automatisee. Ceux-ci sont de plus en pluspresents dans les jardins particuliers mais emergent egalement dans les terrains deplus grandes superficies comme les golfs ou terrains de sport. Comme toutes nouvellestechnologies, les robots tondeuses n’apportent pas que des solutions, mais aussi leurlot de problemes.

La technologie des tondeuses robotiques est en pleine expansion, de nombreusessocietes se developpent a travers le monde, les techniques existantes evoluent et denouvelles innovations apparaissent continuellement. Les evolutions portent principale-ment sur les softwares internes des robots et plus particulierement sur les algorithmesde navigation ou de nouvelles techniques sont continuellement proposees. Cependant,cet afflux de nouvelles evolutions pose un nouveau probleme : la necessite de pouvoirtester rapidement et facilement les nouvelles ameliorations possibles afin d’evaluerleurs impacts sur les performances de ces robots.

A l’heure actuelle, lorsqu’une equipe de recherche et developpement desire testerune nouvelle solution, deux options se presentent a elle :

• Soit tenter de demontrer mathematiquement son impact sur les per-formances de la machine, ce qui est souvent complique voire parfoisimpossible.

• Soit concevoir un prototype et le faire tourner sur un terrain de test pen-dant plusieurs jours avant d’obtenir des resultats permettant d’evaluerl’amelioration.

Toutes ces solutions sont complexes, chronophages et couteuses.

La solution a l’aboutissement d’un tel projet est d’implementer un logiciel de simu-lation d’un robot mobile autonome dans son environnement de travail. Un tel logicielpermettrait de faciliter le developpement et la validation des futures ameliorations. Le

v

defi est de concevoir un tel simulateur de maniere optimale en tenant compte du tempset des investissements necessaires a la finalisation d’un tel projet. Entre precision etefficacite, les choix d’implementation sont cruciaux. La modularite du logiciel peutaussi etre consideree comme un challenge, melant genie logiciel et integration descomposantes embarquees dans les robots.

La creation d’un logiciel permettant d’evaluer rigoureusement les impacts d’event-uelles ameliorations souleve un second probleme : Quels sont les criteres permettantd’evaluer les performances des algorithmes de navigation ? A l’heure actuelle, il n’existeaucun critere et des reunions entre les differents constructeurs ont lieu a travers lemonde, mais celles-ci n’ont pas encore permis de determiner les criteres objectifs per-mettant d’evaluer la bonne execution du travail sur le terrain. Il est donc necessairede definir ces criteres, afin d’evaluer de maniere objective les performances des robotsdans leur environnement.

Enfin, un troisieme probleme consiste en la creation d’un prototype d’algorithme denavigation des robots utilisant la technologie de positionnement GPS. Les possibilitesoffertes par la technologie GPS sont immenses, et son utilisation dans la navigation desrobots tondeuses pourrait grandement ameliorer leurs performances. Il nous a doncete demande de concevoir et de tester a l’aide du logiciel developpe dans le cadre duprojet, un algorithme de navigation utilisant le positionnement GPS afin d’ameliorerles performances de la machine

Ces problemes ont ete presentes a l’UCL par la societe belge BelRobotics. UnePME implantee a Wavre qui developpe et distribue des robots tondeuses autonomespour grandes superficies ainsi que des robots ramasseurs de balles de golf.

Dans le cadre d’un nouveau projet lance en 2012, nomme “Projet golf”, il estenvisage de developper un simulateur destine a concevoir et a tester les nouveauxconcepts de facon theorique sans devoir attendre le developpement et la production deprototype. L’initiative d’un nouveau logiciel decoule de l’initiative de notre maıtre destage et co-promoteur, Steve Tumson, ingenieur electromecanicien chez BelRoboticsdans le departement recherche et developpement. Ne possedant pas les ressourcesnecessaires au developpement, a la realisation et a la mise en exploitation du logiciel,Monsieur Tumson decide de faire appel a des etudiants universitaires. Il propose donca notre promoteur, Charles Pecheur, de realiser le travail sous la forme d’un memoirecouple a un stage en entreprise.

Conscients qu’ils n’ont que tres peu d’outils a leur disposition pour verifier l’effi-cacite de leurs ameliorations, la necessite d’un simulateur au sein de l’equipe de re-cherche et developpement s’est fait sentir et est devenu au gre des besoins la motivationprincipale de BelRobotics. Une variante marketing du simulateur pourrait apporteregalement de la valeur ajoutee au sein de la societe. En effet, bon nombre de clientsn’arrivent pas a concevoir qu’une tondeuse dirigee par un comportement aleatoiremais controle puisse tondre parfaitement leur terrain. Grace a une representation gra-phique de l’environnement dans lequel le robot evolue, le client pourrait parfaitementconstater les performances de ce genre d’innovation. Pour terminer, une utilisation dulogiciel durant des formations proposees aux revendeurs et installateurs agrees per-mettrait d’illustrer efficacement les pieges a eviter lors d’implantation et realisationde nouvelles installations..

D’un point de vue plus personnel, nous avons choisi ce sujet de memoire, car

nous voulions travailler sur un projet concret, utile et permettant de faire evoluer latechnique dans un domaine qui a ce jour reste encore confidentiel. L’idee de concevoirun projet en partant d’une page blanche, de concevoir l’entierete de l’elaborationet l’implementation du logiciel, et la liberte d’action qui nous etait offerte dans ledeveloppement d’une solution nous ont directement attires.

Nous avons donc entierement developpe un logiciel en Java, que nous avons nomme“Java Robot Simulateur” plus communement appele JRS. JRS est un outil puissant etmodulaire, permettant de tester rapidement et efficacement les nouvelles ameliorationsapportees a l’elaboration des nouveaux robots tondeuses et d’evaluer leurs impacts surles performances des nouvelles machines.

Nous avons egalement cree des criteres objectifs permettant de definir les perfor-mances des robots dans leurs environnements. Ces derniers ont ete definis sur base del’experience des ingenieurs sur le bon fonctionnement des robots, mais egalement entenant compte des possibilites offertes par le logiciel que nous avons developpe.

Ce rapport detaille l’ensemble des solutions apportees a la problematique et eststructure comme suit :

• La premiere partie decrit le contexte du memoire ainsi que la methodologieutilisee. Elle aborde egalement les problematiques soulevees ainsi que lestravaux deja realises a ce sujet.

• La seconde partie decrit une serie de solutions apportees a la problematiqueainsi que la validation du modele par rapport aux donnees recueillies surle terrain.

• La troisieme partie, le corps du projet, presente l’analyse organisation-nelle et fonctionnelle du logiciel.

• La quatrieme partie consiste en un rappel des objectifs, des propositionsde developpement futur du projet et une conclusion au sujet du travailaccompli en collaboration avec BelRobotics.

• La cinquieme partie est quant a elle reservee aux annexes.

Premiere partie

Preliminaires

1

Chapitre 1

Prerequis

Dans ce chapitre, un synopsis des produits de la societe BelRobotics sera aborde. Cecipermettra de prendre un premier contact avec le monde des robots tondeuses et donc de mieuxapprehender certaines fonctionnalites du simulateur, ainsi que les differents algorithmes denavigation.

1.1 Produits

BelRobotics vend actuellement quatre produits que nous pouvons separer en trois categories(Figure 1.1) :

• Robots tondeuses de grandes surfaces (Bigmow, Parcmow) : cesont les robots tondeuses pour grandes surfaces, les plus performantesau monde. La Bigmow, peut tondre jusqu’a 20.000 m2. La Parcmow estsa petite soeur et entretient des terrains jusqu’a 10.000 m2.

• Robots tondeuses de moyennes surfaces (Greenmow) : cette ton-deuse est destinee aux jardins de particuliers, allant jusqu’a 6.000 m2.

• Robots ramasseurs de balles de golf (Ballpicker) : c’est la solu-tion de ramassage automatique et economique de balles de golf sur lespractices. Le Ballpicker ramasse silencieusement les balles de golf, jus-qu’a ce que son bac soit rempli. Il les ramene alors a la station. Les ballessont ensuite lavees et transportees a la zone de stockage. Le Ballpickerest capable de ramasser jusqu’a 12.500 balles par jour.

1.2 Principe de fonctionnement

Pour l’utilisateur, le fonctionnement des robots BelRobotics est extremement simple :

3

1. Prerequis 1.2. Principe de fonctionnement

Dans une premiere phase, un specialiste de la societe vient analyser la typologie du terrainafin de determiner quel type de robot devra etre utilise, l’emplacement de la station de rechargeet le parcours du cable peripherique.

Dans une deuxieme phase, l’installateur enterre, dans une fine saignee, le cable en ceinturantle terrain a entretenir. Lors de l’exploitation, le champ magnetique emis par le cable empechele robot de sortir de la surface a traiter.

Une troisieme et derniere phase consiste a configurer le robot au terrain. A ce stade, l’ins-tallation est terminee et le robot peut travailler de maniere autonome. Il va effectuer desdeplacements aleatoires a l’interieur de sa zone de travail, delimitee par le cable peripherique.Quand il doit recharger ses batteries, le robot retourne automatiquement a sa station de re-charge.

Figure 1.1: Greenmow, Parcmow, Bigmow.

4.

Chapitre 2

Etat de l’art

Dans ce chapitre, nous listerons les travaux deja realises et se rapportant a notre travail.Nous analyserons les solutions existantes et discuterons des points forts et des points faibles decertaines d’entre elles. Ces analyses auront pour but de mettre en perspective notre travail, lelogiciel JSR que nous avons cree et les solutions existantes.

2.1 Planificateur de jardin Viking

Le planificateur de jardin “Viking” est un outil pour aider a concevoir les jardins, il donneune idee de ce qui peut etre realise avec le robot-tondeuse iMow de la marque Viking.

Figure 2.1: Planificateur de jardin Viking.

• Points forts : Le point fort de ce logiciel est qu’il possede un editeurd’environnement tres avance possedant de nombreuses fonctionnalites

5

2. Etat de l’art 2.2. Simulateur issu du projet ArduMower

interessantes telles que : la possibilite d’ajouter differents types d’obs-tacles ainsi que de dessiner, comme dans notre propre simulateur, lasurface de la pelouse et d’en deplacer les extremites. Un autre pointfort est que l’editeur possede un systeme permettant de tracer automa-tiquement le parcours du fil peripherique, ce qui, visuellement, est unindeniable atout.

• Points faibles : Le gros point faible de ce logiciel est le manque completde simulation. En effet, quand on presse le bouton � Go �, cense lancerla simulation, le robot se deplace jusqu’au bord du terrain et termineainsi sa simulation en affichant le temps necessaire a la tonte purementtheorique calcule en fonction de la surface du terrain. Il n’y a aucunesimulation reelle de deplacement du robot dans son environnement detravail.

L’editeur de ce logiciel fut une source d’inspiration pour quelques fonctionnalites de l’editeurde JRS. En effet, lors du tracage des pourtours du terrain, les distances et les angles sontaffiches en temps reel sur le dessin, ce qui s’avere extremement pratique. Nous avons doncdecide d’integrer ces outils dans notre logiciel. Par contre, nous n’avons pas ajoute le systemepermettant de tracer automatiquement le parcours du fil peripherique a JRS, les bords duterrain etant consideres comme le fil peripherique.

2.2 Simulateur issu du projet ArduMower

Le projet ArduMower consiste a realiser un robot tondeuse, de la conception du logiciel ala realisation du hardware. C’est dans le cadre de ce projet qu’un simulateur, permettant detester les differents algorithmes de navigation a ete cree.

Figure 2.2: Simulateur issu du projet ArduMower.

• Points forts : Le point fort de ce logiciel est qu’il possede un simula-teur avance. L’aspect visuel permet de suivre l’evolution du robot dansl’environnement de travail. Un autre point fort est que le robot effectue

6.

2. Etat de l’art 2.3. Projet etudiant de l’universite de Bourgogne

un mapping de son environnement afin d’utiliser cette information dansses algorithmes de navigation.

L’autre gros point fort de ce logiciel est qu’il possede des algorithmes detonte inedits, comme une navigation en bandes paralleles ou encore unenavigation avec deplacements bidirectionnels (le robot n’effectue pas derotation).

• Points faibles : Un gros point faible du logiciel est qu’il ne possede pasd’editeur et ne permet que le chargement d’images d’environnementsfigees. De plus, il n’y a pas de systeme permettant de recuperer desstatistiques. Un autre point faible non negligeable est qu’il n’y a pas degestion du temps permettant d’accelerer la navigation, ce qui oblige deregarder le robot se deplacer lentement avant de pouvoir regarder sesresultats. Pour terminer, les robots ne sont pas parametrables et il n’estpas possible d’executer plusieurs simulations simultanement.

Ce simulateur est celui qui se rapproche le plus de notre logiciel du point de vue de lasimulation. En effet, le robot evolue dans son environnement de travail et il est possible de suivrecette evolution graphiquement. De plus, le robot effectue un mapping de son environnement,comme dans l’algorithme de navigation GPS que nous avons developpe. La caracteristiquereellement interessante de ce logiciel est que le robot possede des algorithmes de tonte inedits.L’observation du robot executant les differents algorithmes proposes par le simulateur nousa permis d’eliminer des algorithmes que nous avions envisages de developper au depart. Parexemple, la tonte en bandes paralleles s’est averee clairement inefficace dans le simulateurArduMower et nous avons donc abandonne le projet de l’implementer dans notre logiciel. Mais,malgre des fonctionnalites tres interessantes, ce simulateur ne represente pas une alternativepossible a JRS. Il n’y a ni module de statistiques, ni editeur, ni acceleration du temps possible.

2.3 Projet etudiant de l’universite de Bourgogne

Ce simulateur est ne d’un projet etudiant de l’universite de Bourgogne. L’origine du projetconsiste en l’analyse d’algorithmes de navigation et creation d’un simulateur de robot-aspirateurcharge de nettoyer un local encombre de divers obstacles.

• Points forts : Les points forts de ce simulateur sont les nombreusesfonctionnalites interessantes qu’il possede. Il permet tout d’abord decharger un environnement sous forme de fichier texte et de choisir l’al-gorithme de navigation utilise pour la simulation. On peut ensuite lancerla simulation et suivre l’evolution du robot dans son environnement. Ala fin de la simulation, diverses statistiques sont affichees sous forme detableaux.

• Points faibles : Le plus gros point faible de ce simulateur reside dansses fonctionnalites basiques et relativement peu evoluees. Ce simulateurn’est clairement pas destine a un usage generique.

7.

2. Etat de l’art 2.4. Simulateur de robots tondeuses par Alexander Grau

Figure 2.3: Simulateur de robot aspirateur.

Contrairement a JSR, ce simulateur ne possede ni editeur d’environnement, ni editeur derobot. Il possede, par contre, des fonctionnalites similaires a notre logiciel comme la simulationen temps reel et la production de statistiques, mais celles-ci sont peu evoluees. Par contre, lesalgorithmes de navigation developpes sont interessants et peuvent etre une source d’inspirationpour le developpement futur d’autres algorithmes de navigation.

2.4 Simulateur de robots tondeuses par Alexander Grau

Il s’agit d’un programme de simulation d’une tondeuse a gazon robotique sur une pelouseavec une pente constante.

Figure 2.4: Simulateur d’Alexander Grau.

8.

2. Etat de l’art 2.5. Les pseudo-simulateurs

• Points forts : Le point fort de ce logiciel est qu’il permet de simuler undeplacement de robot tondeuse sur une pelouse en pente (allant du hautvers le bas de la pelouse). La pente ayant une influence sur la trajectoiredu robot.

• Points faibles : Le point faible de ce simulateur est qu’il ne possedeaucune fonctionnalite, hormis celle identifiee comme point fort. En effet,le simulateur est tres basique et permet seulement de choisir la positionde depart du robot ainsi que sa taille.

L’interet de ce logiciel reside, bien evidemment, dans le fait qu’il simule le deplacement d’unrobot sur une pelouse avec pente. Cela permet d’observer que la tondeuse (comme toutes lesautres tondeuses) a tendance a se deplacer dans la partie inferieure de la pelouse. La consequenceest que, meme apres plusieurs heures, la partie superieure de la pelouse n’est pas tondue cor-rectement. Cette fonctionnalite tres interessante n’a pas ete implementee dans JRS pour laraison suivante : un simple plan incline n’est pas representatif de tous les cas possibles deterrains auxquels sont confrontes les robots BelRobotics. Il aurait donc fallu developper unsysteme permettant de definir un ensemble de courbes de niveau dans un environnement, etpar consequent un ensemble de pentes. Cependant, etant donne la complexite du systeme,celui-ci fut abandonne.

2.5 Les pseudo-simulateurs

Durant nos recherches, nous avons egalement trouve des logiciels se presentant sous le des-criptif de � Simulateur de robots tondeuses”, mais qui etaient, en realite, bien eloignes d’unsimulateur de robot tondeuse dans son environnement de travail. Ceux-ci nous ont neanmoinspermis de voir ce qui existait au niveau des interfaces graphiques et des simulateurs de tonte.Nous les avons listes ci-dessous :

2.5.1 Robot Vacuum Simulator 2013

Robot Aspirateur Simulator 2013 est un simulateur 3D qui vous met dans la peau d’unrobot aspirateur et vous permet de vous deplacer dans votre appartement afin de le nettoyer. Cesimulateur a la particularite interessante d’utiliser un moteur graphique et physique 3D. Il n’ya cependant aucune simulation de navigation automatique, aucun editeur, ni aucune generationde statistiques. Un logiciel 3D est donc un plus, mais celui-ci n’est pas un simulateur de robotautonome.

9.

2. Etat de l’art 2.5. Les pseudo-simulateurs

Figure 2.5: Robot Vacuum Simulator 2013.

2.5.2 Lawn Mower Simulator York College of Pennsylvania

Simple simulateur de tonte, implemente par les etudiants et leur professeur dans le cadred’un exercice du cours de sciences de l’informatique du York College of Pennsylvania. Celui-cine possede aucune fonctionnalite avancee et simule uniquement une grille sur laquelle se deplacele robot. Il est interessant dans la mesure ou il ressemble a notre logiciel, dans son tout premiermodele, et a uniquement pour but le developpement d’algorithmes de navigation basiques.

Figure 2.6: Lawn Mower Simulator York College of Pennsylvania.

2.5.3 Jeu Lawn Mower 1988

Lawn Mower est un simulateur de tonte realise en ASCII. Il a la particularite d’avoir etepublie par Christopher D. Orr, en 1988, pour MS-DOS. C’est donc le plus vieux simulateurde tondeuses que nous avons trouve. Cependant, celui-ci n’est pas un simulateur de robotstondeuses, puisqu’il n’y a aucune navigation automatique. Son interet est qu’il nous a permisde voir comment representer, de maniere simpliste, un environnement de simulations pour lesrobots tondeuses.

10.

2. Etat de l’art 2.6. Conclusion des recherches

Figure 2.7: Jeu Lawn Mower 1988.

2.6 Conclusion des recherches

Les recherches concernant les differents simulateurs de robots tondeuses dans leur environ-nement de travail nous ont permis de dresser un inventaire des erreurs a eviter, mais egalementd’integrer dans notre projet des fonctionnalites et des caracteristiques interessantes.

Dans le tableau 2.1, nous avons repris les caracteristiques interessantes de chaque logiciel,et si elles ont ete implementees dans notre logiciel. On remarque que toutes les caracteristiquesinteressantes des differents logiciels ont ete implementees dans JRS, a l’exception de la derniere.Les caracteristiques provenant d’autres logiciels ont ete, pour la plupart, ameliorees et ce, afind’exploiter le maximum de leur potentialite.

Une fois notre logiciel implemente, la comparaison de celui-ci avec les differents simulateursde robots tondeuses, montre clairement qu’il n’existe pas de simulateur equivalent au notreconnu a ce jour. De facon generale, aucun de ces simulateurs ne peuvent etre utiliser dans uneoptique de recherche et developpement car ils sont bien trop basiques, contrairement a JRS quiest un outil puissant, complet et disposant de tres nombreuses fonctionnalites.

Simulateur Caracteristiques interessantes Dans JRS

Planificateur de jardinViking

Editeur d’environnement avance OUI

Simulateur ArduMowerSimulation temps reel, Mapping de

l’environnement, algorithme denavigation gps

OUI

Projet etudiant del’universite de Bourgogne

Module statistique (basique),simulation temps reel

OUI

Simulateur par AlexanderGrau

Gestion des terrains en pente(basique)

NON

Table 2.1: Tableau de comparaison.

11.

2. Etat de l’art 2.6. Conclusion des recherches

12.

Chapitre 3

Methode de travail

Ce chapitre a pour but de detailler la methodologie que nous avons utilisee pour mener abien ce memoire. Afin de realiser au mieux notre travail, nous avons commence par organiserun ensemble de reunions avec Mr Tumson pour mettre au point notre methodologie ainsi queles objectifs a atteindre. Nous avons du trouver une methodologie qui soit applicable tout aulong du developpement de notre memoire et qui soit surtout compatible avec notre stage. Eneffet, celui-ci se deroulant au second semestre, il se situe dans la continuite de notre memoire.

3.1 Methodologie Scrum

Fort de son experience, Mr Tumson nous a propose d’utiliser la methodologie de developpementScrum qui fait partie de la classe des methodologies de type agile (Figure 3.1). L’idee de baseest de focaliser l’equipe sur une partie limitee et maıtrisable des fonctionnalites a realiser.

Cette methodologie est egalement definie comme incrementale, car l’ensemble du projet estdecoupe en periodes, nommees � sprint �, durant lesquelles on ameliore le produit. La dureed’un sprint peut varier de quelques jours a un mois, mais celle-ci est determinee definitivementau debut du projet. Nous avons choisi des sprints d’une duree de deux semaines. Chaque sprintest compose d’un certain nombre d’ajouts a realiser au bout duquel un delivrable du produitest presente au client pour que celui-ci puisse valider ou invalider ces ajouts.

C’est ainsi que la premiere phase de cette methodologie consiste a decouper le projet enun ensemble d’ajouts/fonctionnalites appele � story �, le tout se trouvant dans un documentintitule � backlog �. Chaque story identifie une fonction specifique du produit fini. Chaquestory se voit egalement attribuer un nombre de points representant un niveau de complexiteet un temps necessaire a sa realisation. Ceci permettra durant le developpement du projet dedefinir la charge de travail necessaire a la realisation de celui-ci.

Il est important de noter que l’enumeration des differentes � stories � n’est pas definitive,c’est la un avantage considerable de cette methodologie. En effet, a tout moment, durant ledeveloppement, il est possible d’ajouter, de splitter ou de modifier une � story � qui n’est pasencore achevee. C’est ainsi que notre backlog initial ne comptait qu’une vingtaine de stories,alors que le final en compte plus d’une soixantaine. Cette caracteristique de la methodologieScrum en fait un outil efficace pour suivre continuellement les besoins du client (dans notre cas :BelRobotics) et permet de recadrer rapidement les choix d’implementation ou tout simplementd’ajouter une fonctionnalite qui n’etait pas prevue au depart.

13

3. Methode de travail 3.2. Etapes d’un sprint

Figure 3.1: Illustration de la methodolgie Scrum.

3.2 Etapes d’un sprint

Abordons des a present l’evolution chronologique d’un sprint : chaque sprint est divise en 5etapes. Ces etapes sont repetees, sans exception, lors de chaque sprint, jusqu’a la fin du projet.

1. La premiere etape est l’estimation, elle consiste a evaluer la charge detravail que pourra supporter l’equipe en fonction des ressources dont elledispose pour ce sprint. Cette estimation se base sur les points definisprecedemment pour chaque story. C’est ainsi que, pour une periode dedeux semaines, avec deux etudiants disponibles a trois quart temps,nous sommes arrives a un nombre de points compris entre 20 et 25.Cette estimation peut varier au cours des sprints.

2. La deuxieme etape consiste a planifier le sprint et les differentes storiesque l’equipe va realiser en fonction du nombre de points evalues a l’etapeprecedente. Tout comme la premiere, cette etape sera realisee avec leclient (Mr Tumson dans notre cas), ce qui va lui permettre de suivrel’etat d’avancement du projet, mais egalement de redefinir les objectifsen fonction de l’importance des points a realiser. Durant cette etape,il est important d’ecouter tous les intervenants, autant le point de vuetechnique de l’equipe de developpement, que les exigences du client,car c’est cette combinaison qui permettra de tendre vers de meilleursresultats.

3. Vient ensuite l’etape de la realisation des stories. Chaque matin, lesmembres de l’equipe de developpement se rassemblent brievement pouretablir les objectifs de la journee.

4. Lorsque l’equipe de developpement est arrivee a la fin du temps impartipour ce sprint, elle passe a l’etape de demonstration. C’est ainsi, qu’enpresence du client, l’equipe de developpement va organiser une reunionde demonstration pour presenter toutes les fonctionnalites implementees.

14.


Chaque story sera ensuite evaluee individuellement pour determinersi elle a bien ete achevee ou s’il est necessaire d’y apporter certainesameliorations.

5. La derniere etape consiste en une retrospective du sprint qui vient d’etreeffectue, afin d’identifier ce qui n’a pas bien fonctionne, et ainsi des’ameliorer pour le prochain sprint.

Comme vous pouvez l’imaginer, cette methodologie est tres flexible et ouverte, elle permet deredefinir rapidement les priorites. C’est en grande partie pour cette raison que notre cahier descharges n’a pas ete suivi scrupuleusement, et qu’un grand nombre de fonctionnalites developpeesdans le logiciel final ne s’y trouvaient pas au depart. Notre backlog final (qui equivaut a notrecahier des charges) est disponible en annexe. Il contient egalement la repartition des storiesdans les sprints, donnant une vue complete du deroulement chronologique de notre projet.

15.


16.

Chapitre 4

Enonce du probleme

Le but de ce memoire est de concevoir un logiciel de simulation pour robots autonomes.Initialement, il aurait fallu partir du cahier des charges pour aborder chaque point de celui-ciet enoncer les problematiques que ceux-ci soulevent. Mais, comme nous l’avons precise dans lechapitre precedent, nous avons utilise la methodologie Scrum. Cela explique que les objectifsont evolue tout au long du developpement. Nous allons donc partir de la derniere version denotre backlog, pour parcourir l’ensemble des objectifs que nous avons selectionnes tout au longde ce projet.

4.1 Objectifs architecturaux

De la modularite

La modularite du produit final est l’un des points le plus important, car c’est celle-ci qui vapermettre aux ingenieurs de BelRobotics de continuer a developper des fonctionnalites au seindu simulateur, et ceci sans devoir reecrire l’ensemble du programme. L’idee est de pouvoir, parexemple et le plus simplement possible, ajouter un composant au robot, un nouveau comporte-ment a sa navigation ou encore un filtre visuel pour l’affichage en temps reel de l’environnement.

Deux parties distinctes

Il est important de separer le logiciel en deux parties distinctes pour conserver leur indepen-dance. Ainsi, la partie qui concerne l’editeur d’environnement ne doit pas avoir d’objet communavec la partie qui s’occupe de la simulation. Un convertisseur doit donc permettre le passage del’une a l’autre. Cela permettra d’apporter des modifications a l’une des parties sans devoir adap-ter la seconde, ou encore de executer une partie sans avoir a se soucier du bon fonctionnementde l’autre.

17

4. Enonce du probleme 4.2. Objectifs fonctionnels

Une independance graphique

Pour faciliter le developpement par les ingenieurs de BelRobotics, il est preferable quetoute la partie graphique soit geree automatiquement par le programme. En effet, un ingenieurelectromecanicien desirant ajouter sa fonctionnalite dans le simulateur n’a certainement pasenvie de devoir ajouter toutes les composantes graphiques que celle-ci va utiliser.

4.2 Objectifs fonctionnels

Un environnement personnalisable

Une des fonctionnalites principales du programme doit etre son editeur d’environnement.Il doit etre a la fois complet et simple d’utilisation. Pour ce faire, l’utilisateur disposera d’unensemble d’outils, de dessins, et de placement d’objets (arbre, station, etc). Ces environnementspourront etre sauvegardes et charges a tout moment.

Un robot parametrable

Une partie du programme devra etre reservee a la personnalisation du robot et a sa naviga-tion. Cette personnalisation sera developpee afin d’eviter toute intervention de l’utilisateur dansle code du logiciel. A travers une interface simple, l’utilisateur aura la possibilite de personnaliserun maximum son robot afin de tester differentes configurations pour un environnement donne.Tout comme l’environnement, l’utilisateur pourra sauvegarder et reutiliser a tout moment l’unede ces configurations.

Un gestionnaire de simulation

La deuxieme partie importante du programme consistera a l’execution d’une simulation.Le programme montrera graphiquement l’evolution du robot dans son environnement de tra-vail, avec la possibilite de modifier sa vitesse de simulation. Un ensemble de statistiques seraegalement affiche et mis a jour en temps reel par le simulateur.

Des statistiques sauvegardables

A la fin d’une simulation, toutes les donnees statistiques devront etre sauvegardees dansun fichier externe sous forme de tableau. Cela permettra par la suite d’effectuer des analysescomparatives des differentes simulations realisees.

18.


Des methodes d’evaluation

A l’heure actuelle, il n’existe aucun critere permettant d’evaluer les performances des al-gorithmes de navigation. A ce jour, des reunions entre les differents constructeurs ont lieu atravers le monde, mais celles-ci n’ont pas encore permis de determiner les criteres objectifspermettant d’evaluer la bonne execution du travail sur le terrain. L’equipe de recherche etdeveloppement de BelRobotics aimerait donc definir ces criteres, afin d’evaluer de maniere ob-jective leurs differents algorithmes de navigation. Il nous faut donc definir des criteres objectifspermettant de definir les performances des robots dans leur environnement.

Des filtres utiles

Afin de faciliter la comprehension visuelle de l’environnement dans lequel le robot travaille,un ensemble de filtres pourra etre applique sur celui-ci. Cela permettra, par exemple, d’identifierles zones dans lesquelles le robot n’est pas encore passe, ou encore celles sur lesquelles le robotest reste bloque durant une longue periode.

La multi-simulations

L’utilisateur aura la possibilite de lancer, de maniere automatique, une grande quantite desimulations avec des parametres variables, et cela dans le but de determiner l’efficacite de cesvariations. Toutes les simulations disposeront d’un meme environnement de depart, seuls leursparametres varieront. Etant donne que plusieurs simulations seront lancees en meme temps, seulleur etat d’avancement sera affiche a l’ecran. Les environnements ainsi que les statistiques dechaque simulation ne seront pas visibles durant l’execution. Cela permettra d’economiser de lapuissance de calcul, le logiciel pouvant ainsi executer plusieurs simulations sur des ordinateursde puissance moyenne.

Une interface graphique soignee

Des composantes graphiques soignees permettront une utilisation plus confortable du logi-ciel. En effet, celui-ci ne servira pas uniquement a des ingenieurs pour tester leurs ameliorations,il sera egalement utilise par le departement marketing pour presenter une solution a leurs clients.Il est donc important de soigner l’aspect visuel du logiciel.

19.


20.

Deuxieme partie

Solution

21

Chapitre 5

Description du logiciel

Dans ce chapitre, nous allons presenter du point de vue de l’utilisateur, les fonctionnalitesque nous avons developpees au sein de JRS. L’architecture interne du logiciel sera quant a elle,detaillee dans les chapitres suivants.

Pour commencer, il est important de bien differencier les deux grandes parties de JRS :l’editeur et le simulateur. La premiere partie va permettre a l’utilisateur de creer son terrain etde configurer son robot, alors que la deuxieme partie va permettre de simuler le comportementdu robot, en fonction de ce terrain et des parametres du robot.

5.1 Editeur

L’editeur d’environnement est la premiere etape pour realiser une simulation. Commenconspar voir les differents boutons presents dans son interface graphique.

Barre d’option

La barre d’option se situe en haut de la fenetre et est constituee de 10 boutons (Figure5.1). Les quatre premiers permettent de creer un nouvel environnement, en charger un, ousauvegarder celui en cours. Les deux suivant vont permettre d’editer les parametres du robot,ainsi que ces statistiques. Viens ensuite un bouton pour lancer une simulation unique suivi d’unsecond pour lancer une multi-simulations. Et pour terminer, nous avons un bouton permettantd’afficher quelques informations sur JRS et un second pour quitter le programme.

Figure 5.1: Barre d’option de l’editeur.

La premiere etape va donc consister a creer un environnement. L’utilisateur va alors entrerles parametres de bases de ce dernier (Figure 5.2) : nom, fichier destinataire, dimension, tailledes parcelles.

23

5. Description du logiciel 5.1. Editeur

Figure 5.2: Fenetre de creation d’environnement.

Lorsque que l’environnement est cree, l’utilisateur va pouvoir le personnaliser. Pour cela, ilva disposer d’un ensemble d’outil a sa gauche, d’une representation de son environnement aucentre et d’une liste a droite regroupant tous les elements qui le constituent (Figure 5.3).

Figure 5.3: Fenetre de l’editeur.

24.


Outils de base

L’utilisateur dispose de 2 outils de base (Figure 5.4) :

1. Un outil de selection : Cet outil permet de selectionner un objet dansl’environnement pour le deplacer, le modifier ou le supprimer.

2. Un outil latte : Cet outil permet de prendre des mesures et verifier laconformite de son terrain.

Figure 5.4: Outils de base.

Outils de dessin

L’utilisateur dispose egalement de 3 outils de dessin. Ces outils vont lui permettre de dessinerles trois types de zones existantes dans JRS (Figure 5.5) :

1. Les zones d’herbe : Ces zones permettent de delimiter le terraina entretenir. Lorsqu’une zone d’herbe est ajoutee a l’environnement,ses pourtours emettent un champ magnetique, ce qui simule le cableperipherique. Ce dernier pourra ensuite etre detecte par la bobine magnetiquedu robot.

2. Les zones obstacle : Ces zones permettent d’identifier les obstaclesphysiques du terrain : une maison, un banc, une cabane de jardin. Ellesn’emettent pas de champ magnetique mais seront detectees par le sonardu robot.

3. Les zones “ılot” ou “externe” : Ces zones sont l’inverse des zonesd’herbe. Tout comme ces dernieres, elles emettent egalement un champmagnetique. Placer une zone externe au milieu d’une zone d’herbe re-vient donc a tirer le cable peripherique pour former un ılot au milieudu terrain. Elles sont par exemple utilisees pour delimiter un etang quin’est pas detectable avec le sonar du robot.

Figure 5.5: Outils de dessin.

Lors de la creation et de la modification de ces zones, plusieurs informations utiles sontegalement affichees (Figure 5.6) : la surface totale de la zone, la distance entre les pointsselectionnes et l’angle en cours de tracage.

Pour faciliter d’avantage le tracage des differentes zones, l’utilisateur peut egalement utilisernotre integration Google Map. Celle-ci est disponible en bas a droit de la fenetre et va afficher

25.


Figure 5.6: Information d’aide au tracage.

une image satellite du terrain de l’utilisateur (Figure 5.7). Celui-ci doit au prealable avoir intro-duit la position GPS de son terrain et le niveau de precision qu’il desire. Pour permettre cetteintegration nous n’avons pas souscrit d’abonnement professionnel chez Google. C’est d’ailleurspour cette raison que la taille de l’image est limitee et diminue en fonction de la precision quel’on a choisie.

Figure 5.7: Exemple d’integration Google Map.

Outils de placement

Pour terminer, l’utilisateur dispose de deux outils de placement d’objets (Figure 5.8) :

1. Outil de placement d’arbre : Cet outil permet de placer un arbresur l’environnement. Il sera considere comme une zone obstacle et seradetecte par le robot a l’aide de son sonar.

2. Outil de placement de station : Cet outil permet de placer unestation dans l’environnement. Il va automatiquement placer la stationsur le cable peripherique pour faciliter son installation et eviter toutes

26.


erreurs venant de l’utilisateur. Il n’y a pas de limite sur le nombre destations.

Figure 5.8: Outils de placement.

Personnalisation de l’environnement

Lorsque l’utilisateur a fini de dessiner et placer ses elements sur l’environnement, il peutles personnaliser dans la liste de droite. Il est ainsi possible d’indiquer la vitesse de pousse deszones d’herbe, le courant de charge des stations ou encore la couleur des zones obstacle et ılot(Figure 5.9).

Figure 5.9: Personnalisation des elements de l’environnement.

Sauvegarde et chargement d’environnement

Lorsque l’utilisateur a entierement fini de personnaliser son environnement, il peut le sau-vegarder dans un fichier externe a l’aide des boutons de la barre d’option. Celui-ci pourra ainsietre recharge plus tard meme apres avoir redemarre le programme.

Personnalisation du robot

Apres avoir construit son environnement, l’utilisateur peut personnaliser les parametres deson robot et de sa navigation. Cette personnalisation va permettre de trouver la configurationideale pour un terrain donne. La fenetre de personnalisation du robot est composee de deuxparties (Figure 5.10) :

1. Sur la droite, une liste affiche l’entierete des parametres que l’utilisa-teur peut faire varier. Un mecanisme de verification indiquera toutesmauvaises valeurs.

27.


2. Sur la gauche, une representation visuelle du robot est disponible. Cetterepresentation comprend egalement l’affichage de certains parametres,comme ceux indiquant une position (emplacement du sonar, des boudinsde pression, etc).

Nous verrons plus tard qu’il est extremement simple d’ajouter de nouveaux parametres aurobot. Cette fonctionnalite plus technique sera detaillee dans le chapitre suivant, concernantl’architecture de notre solution.

Figure 5.10: Fenetre de personnalisation du robot.

Tout comme l’environnement, les configurations de robot peuvent etre sauvegardees dansun fichier externe pour etre rechargees par la suite. Les boutons de sauvegarde et chargementsont situes en haut a droite de la fenetre.

Configuration des statistiques

Avant de passer a l’etape de simulation, il est possible de configurer le mecanisme de sauve-garde des statistiques. En effet, a la fin d’une simulation, l’entierete des statistiques peuvent etresauvegardees dans un fichier CSV. Ce fichier pourra par la suite etre analyse par un programmestatistique plus puissant.

A l’aide de la fenetre statistique, l’utilisateur va pouvoir determiner les statistiques qu’ildesire sauvegarder (Figure 5.11). Trois types de valeurs sont possibles :

28.


1. La valeur � -1 � : Indique au simulateur de ne pas sauvegarder lastatistique.

2. La valeur � 0 � : Indique au simulateur de sauvegarder uniquementla derniere valeur de la statistique, lorsque la simulation sera terminee.

3. Une valeur � X � : Indique au simulateur de sauvegarder la valeur dela statistique toutes les X minutes.

Figure 5.11: Fenetre de configuration des statistiques.

Simple ou multi-simulations

Pour terminer, l’utilisateur a le choix de lancer une ou plusieurs simulations (Figure 5.12) :

1. Dans le premier cas, il peut visualiser l’evolution du robot dans sonenvironnement en temps reel.

29.


2. Dans le second cas, le simulateur lance un ensemble de simulations. L’uti-lisateur a au prealable determine les parametres robot qu’il desire fairevarier. Ceci a pour objectif de determiner une configuration optimale.Les multi-simulations ne seront par contre, pas affichees en temps reel.

Figure 5.12: Comparaison simple simulation (haut) et multi-simulations (bas).

En selectionnant la multi-simulations, le simulateur va demander a l’utilisateur d’indiquerles parametres qu’il desire faire varier (Figure 5.13). Ce dernier n’aura le choix de faire varierque les parametres numeriques du robot. La syntaxe que nous avons imaginee est assez simple :

• Une variation peut etre, soit une valeur simple (exemple : � 42 �), soit

30.


un intervalle (exemple : � 10 > 20 : 6 �).

• Un intervalle est compose d’une valeur de depart, d’une valeur de fin etd’un nombre d’etapes (exemple : � 10 > 20 : 6 � va generer 6 simulationsdifferentes, avec les valeurs 10 ,12 ,14 ,16 ,18 et 20).

• Plusieurs variations peuvent etre combinees avec le separateur � ; � (exemple :� 10 > 20 : 6 ; 42 �).

Figure 5.13: Fenetre de parametres robot pour la multi-simulations.

L’utilisateur peut egalement determiner le nombre de repetitions qu’il desire realiser pourchaque variation. En fonction de ce nombre, le simulateur va donc repeter une meme simulation,plusieurs fois. Cela a pour objectif de determiner les valeurs moyennes de chaque statistique,pour une configuration donnee. Cela permet de supprimer l’effet aleatoire present dans la na-vigation du robot.

31.

5. Description du logiciel 5.2. Simple simulation

L’utilisateur peut aussi indiquer le nombre de threads qu’il desire allouer a la multi-simulations.Lorsqu’il valide ses choix, il passe a la deuxieme etape du logiciel.

5.2 Simple simulation

Nous allons commencer par aborder la simple simulation, la multi-simulations sera detailleedans la section suivante.

La simulation est la deuxieme etape de notre logiciel. C’est ici que nous allons simuler lecomportement du robot en fonction de sa navigation et du terrain. Au niveau de l’interfacegraphique elle est fort similaire a l’editeur (Figure 5.14) :

• En haut de la fenetre se trouve une barre d’option qui permet de redemarrerla simulation ou repasser dans la partie editeur.

• Au centre de la fenetre se trouve l’environnement de simulation. Onpeut remarquer qu’il est legerement different que celui de l’editeur caril a ete converti pour que le simulateur puisse interagir plus facilementavec (nous verrons pourquoi dans l’architecture).

• Sur la droite de la fenetre se trouve une grande liste composee de troiselements : le controleur de la simulation (en haut), la liste des statistiques(au centre) et le choix des filtres a appliquer sur l’environnement (enbas).

Figure 5.14: Fenetre de simple simulation.

32.


Controleur de simulation

Le controleur permet a l’utilisateur de determiner la duree de la simulation et de modifier savitesse d’execution (Figure 5.15). Par defaut, les simulations durent 72 heures et sont lanceesen vitesse x1. Il est possible d’accelerer les simulations jusque x128 tout en voyant le robotevoluer sur le terrain. Pour aller encore plus vite il est possible de passer en mode instantane.La position du robot ainsi que l’environnement ne sont alors plus mis a jour graphiquement.

Figure 5.15: Controleur de simulation.

Statistiques de simulation

Durant la simulation un ensemble de statistiques sont affichees en temps reel (Figure 5.16).Ces statistiques sont a la fois liees au robot (vitesse moyenne, distance parcourue, etc) maisegalement a son environnement (pourcentage visite, uniformite, etc). Ce sont ces statistiquesqui seront sauvegardees en fin de simulation.

Figure 5.16: Statistiques de simulation.

33.


Voici la liste des statistiques les plus pertinentes qui sont actuellement implementees dansle simulateur :

1. Vitesse moyenne.

2. Distance parcourue.

3. Uniformite de la tonte.

4. Pourcentage de zones visitees (1x, 2x, 3x).

5. Surface totale.

6. Etat de la navigation.

7. Nombre de retours station.

8. Pourcentage du temps passe a travailler/charger/rentrer en station.

9. Nombre total de collisions physiques.

10. Nombre total de detections du cable peripherique.

Nous verrons plus tard qu’il est extremement simple d’ajouter de nouvelles statistiques ausein du simulateur. Cette fonctionnalite plus technique sera detaillee dans le chapitre suivant,concernant l’architecture de notre solution.

Filtres de simulation

Nous avons developpe un systeme de filtre pour afficher notre environnement sous differents� angles de vue �. Ce systeme permet a tout moment, pendant la simulation, de passer d’unevue a une autre. Cela va par exemple permettre d’identifier plus facilement les endroits critiquesd’un terrain, en affichant graphiquement la frequence de passage du robot sur chaque parcelle.Voici la liste des filtres les plus pertinents qui sont actuellement implementes dans le simulateur(Figure 5.17) :

1. Filtre de hauteur d’herbe : Il dessine la hauteur d’herbe de chaqueparcelle du terrain.

2. Filtre de frequence de passage : Il dessine la frequence de passagedu robot sur chaque parcelle du terrain avec une echelle allant de 0 a 3passages.

3. Filtre de frequence relative de passage : Il dessine egalement lafrequence de passage du robot mais utilise cette fois ci, la plus grandeet la plus petite valeur comme echelle.

4. Filtre de mapping : Il dessine la carte interne que le robot construitlors de la navigation GPS.

5. Filtre d’uniformite : Il dessine l’uniformite du terrain (detaille dansla prochaine section).

Nous verrons plus tard qu’il est extremement simple d’ajouter de nouveaux filtres au sein dusimulateur. Cette fonctionnalite plus technique sera detaillee dans le chapitre suivant, concer-nant l’architecture de notre solution.

34.


Figure 5.17: Filtres pertinents du simulateur.

Sauvegarde en fin de simulation

En fin de simulation le simulateur va sauvegarder un ensemble de statistiques en fonctiondes preferences definies precedemment. Ces statistiques vont etre enregistrees sous la formed’un fichier CSV (Figure 5.18), pouvant etre ouvert par la plupart des logiciels statistiques.Une image de chaque filtre en fin de simulation sera egalement enregistree dans le dossier desresultats.

Figure 5.18: Exemple de fichier CSV affiche avec Microsoft Excel.

35.

5. Description du logiciel 5.3. Multi-simulations

5.3 Multi-simulations

La multi-simulations est fort similaire a la simple simulation a la difference qu’elle en executeplusieurs simultanement. Commencons par aborder son interface graphique (Figure 5.19) :

• Au centre de la fenetre se trouve une liste contenant la progression dechaque simulation.

• Sur la droite de la fenetre se trouve egalement une liste composee dedeux elements : le controleur des simulations (en haut) et la liste desstatistiques propre a une simulation (au centre).

Figure 5.19: Fenetre de multi-simulations.

Controleur des simulations

Le controleur va permettre a l’utilisateur d’affecter la vitesse de simulation de toutes cellesqui sont en cours d’execution. Il permet egalement de definir la duree totale de chaque simulation(Figure 5.20).

36.


Figure 5.20: Controleur des simulations.

Progression des simulations

La liste des simulations contient un recapitulatif ainsi qu’un controleur pour chacune d’elles(Figure 5.21). Dans ce recapitulatif sont affiches la vitesse, la progression et le nom de lasimulation. En plus du controleur de simulation, un bouton permet d’afficher ses statistiquesdans la liste de droite et un second permet de stopper definitivement la simulation.

Figure 5.21: Controleur et recapitulatif d’une simulation.

Statistiques d’une simulation

Il est possible d’acceder aux statistiques d’une simulation. Celles-ci seront alors afficheesdans la liste de droite (Figure 5.22). Deux boutons supplementaires sont disponibles en bas decette liste : un premier pour afficher a titre informatif, les parametres du robot utilises pourcette simulation, et un second pour ouvrir une nouvelle fenetre et voir le robot evoluer dansson environnement. Cette seconde fenetre ne peut etre affichee que pour une seule simulationa la fois.

37.


Figure 5.22: Liste des statistiques d’une simulation.

Sauvegarde en fin de simulation

Lorsque toutes les simulations sont terminees, un fichier CSV global est egalement genere (enplus de celui propre a chaque simulation). Ce fichier va permettre d’avoir une vue d’ensemblesur toutes les simulations executees. Il va aider l’utilisateur a comparer les simulations afin dedeterminer laquelle de celles-ci a la configuration robot la plus performante.

38.

Chapitre 6

Methodes d’evaluation

Comme explique dans l’introduction, a l’heure actuelle, il n’existe aucun critere permettantd’evaluer les performances d’algorithmes de navigation des robots tondeuses. Nous avons doncdu definir des criteres objectifs permettant d’evaluer les performances des robots dans leurenvironnement. Pour cela, nous avons organise plusieurs reunions avec les ingenieurs de chezBelRobotics afin de definir conjointement ces criteres. Ces derniers ont ete definis sur base del’experience des ingenieurs en tenant compte du bon fonctionnement des robots, mais egalementen tenant compte des possibilites offertes par le logiciel que nous avons developpe. Nous avonsidentifie 3 criteres :

1. Un premier critere est le pourcentage de passages sur tous les endroits de sa zone detravail, dans un laps de temps determine. Cela permet de determiner si le robot acorrectement couvert sa zone de travail. Le critere actuel est le suivant : la zone detravail est consideree comme correctement tondue si le robot est passe au moins unefois sur 98% de sa zone de travail, en moins de trois jours.

2. Un deuxieme critere est cependant necessaire pour pouvoir affirmer que la pelouseest correctement tondue : l’uniformite du terrain. En effet, il n’est pas acceptableque les 2% du terrain ou le robot n’est pas passe soient concentres au meme endroit,ce qui representerait une surface non negligeable d’herbe non tondue. Nous avonsdonc cree un deuxieme critere, permettant de calculer l’uniformite de la tonte sur leterrain. L’uniformite est calcule selon un critere determinant si la tonte est correcte.Ce critere de “bonne tonte” peut etre calcule selon deux donnees : la hauteur de lapelouse minimum ou le nombre de passages minimum.

3. Le calcul de l’uniformite requiert le calcul d’un 3eme critere : le rapport entre lenombre de parcelles de pelouse respectant le critere d’une tonte correcte et le nombrede parcelles de pelouse dans le quadrant.

On calcule l’uniformite totale du terrain de la maniere suivante : On divise un rectangleenglobant l’entierete de la zone de travail du robot en un nombre de quadrants rectangulaires.Ces quadrants sont eux-memes divises en petits carres appeles parcelles. Une fois cette divisionrealisee, on applique le calcul suivant :

39

6. Methodes d’evaluation .

avec

• U represente l’uniformite en pourcent.

• Qi represente la valeur du 3eme critere pour quadrant i.

• S represente le nombre de quadrants possedant au moins une parcellede pelouse.

• i represente l’ensemble des quadrants possedant au moins une parcellede pelouse.

• Q represente la moyenne des Qi.

• Ci represente le nombre de parcelles de pelouse respectant le critered’une tonte correcte.

• Pi represente le nombre de parcelles de pelouse dans Qi.

Avec ce calcul, on obtient une serie de statistiques permettant de definir l’uniformite de latonte du terrain.

Par ailleurs, on obtient le pourcentage de parcelles tondues pour chaque quadrant, ce quipermet de definir, via un filtre d’affichage du logiciel, quels sont les quadrants les plus tondus(exemple figure ci-dessous). Cela a pour but d’identifier d’eventuels morceaux de la zone detravail qui ne sont pas correctement tondus par rapport au reste du terrain.

On obtient egalement l’uniformite generale en pourcent, 100% signifiant que la tonte estuniforme sur l’ensemble du terrain. Ainsi, si l’uniformite tend vers 100%, nous savons qu’il n’ya pas de grands ensembles de parcelles d’herbe non tondus sur le terrain.

Les differents criteres developpes ont permis la quantification d’une notion complexe qui,auparavant, necessitait de visualiser le terrain pour evaluer si le resultat de la tonte etaitacceptable.

Grace aux trois criteres numeriques developpes, il est possible de comparer plusieurs simu-lations sur la simple base de leurs statistiques, afin de determiner laquelle d’entre elles donneles meilleurs resultats.

Figure 6.1: Comparaison environnement (a gauche) et filtre d’uniformite (a droite).

40.

Chapitre 7

Validation

Pour valider notre solution nous avons effectue une batterie de tests fonctionnels durant sondeveloppement. Nous allons dans ce chapitre vous presenter les tests les plus pertinents quenous avons realises avec le simulateur. Pour chaque situation, nous decrirons dans un premiertemps le comportement attendu qui a ete observe dans la realite, puis dans un second temps,le comportement observe au sein du simulateur.

7.1 Test de comportement

Norme d’efficacite

Les ingenieurs de BelRobotics ont determine que pour qu’un robot soit considere commeefficace sur un terrain donne, il doit etre passe au moins une fois en trois jours sur 98% duterrain a entretenir. De plus, la valeur d’uniformite issue de nos criteres de performance doittendre vers 100% afin d’avoir une tonte la plus homogene possible. En sachant que la BigMowest theoriquement capable de tondre 2 hectares, nous avons cree un terrain de cette dimensionet nous avons lance dix simulations de trois jours.

Les resultats observes lors de ces simulations sont assez positifs. En effet, le robot tondeusepasse en moyenne une fois au moins sur 99,18% de la parcelle avec un ecart type de 0.12, enmoyenne deux fois au moins sur 95,56% de celle-ci avec un ecart type de 0.87 et en moyennetrois fois ou plus sur 86,93% avec un ecart type de 0.34. De plus, l’uniformite atteint 97.16%de moyenne avec un ecart type de 0.23. Cela montre que le travail realise a ete reparti defacon homogene sur le terrain. Enfin, la vitesse moyenne issue de notre simulation est de 0.85m/s ce qui est, selon les ingenieurs de BelRobotics, representatif de la vitesse moyenne de leursmachines. JRS arrive donc bien a simuler les normes en place chez BelRobotics et permet memed’affirmer que sur un terrain vide, le robot est legerement plus performant.

41

7. Validation 7.1. Test de comportement

Figure 7.1: Parcelles visitees au moins trois fois (vert), deuxfois (orange clair), une fois (orange fonce) et zero fois (rouge).

Terrain en H

Le probleme du terrain en H permet d’identifier une erreur de placement de station. En effet,si le technicien charge de placer la station sur ce genre de configuration ne fait pas attentionet ne respecte pas les contraintes de placement, il risque de constater regulierement des alertesprovenant du robot. La raison est la suivante : lorsque le robot suit le cable peripherique, ils’attend a recevoir un signal de la station pour ensuite se rapprocher du cable afin d’accostera la station. Si apres avoir detecte la station, il ne s’est pas accoste apres avoir parcouru 27metres alors il s’arrete et souleve une alerte par mesure de precaution.

Pour ce comportement nous avons donc reproduit un terrain en H avec la station a l’inter-section des deux zones et le robot s’est arrete suite a une erreur lors de chaque retour en stationcomme on peut le voir sur la Figure ci-dessous. La simulation est donc correcte et representedonc une facon tres efficace de presenter les erreurs a ne pas commettre aux installateurs quisuivent leur formation technique.

42.


Figure 7.2: Exemple de terrain en H.

Detection d’ılots

Pour certains obstacles physiques a l’interieur de la zone de travail, il est necessaire de lesentourer a l’aide du cable peripherique. Par exemple, un parterre de fleurs ou encore un etangdoivent etre proteges a l’aide du cable, car les autres capteurs du robot ne detecteraient pasces obstacles. Cet entourage de l’obstacle depuis le cable peripherique permet de creer ce quel’on appelle un ılot. En effet, le champ magnetique du cable s’annulera sur le chemin entre lecable peripherique � externe � et l’ılot realise. On peut voir un exemple d’ılot avec la piscinesur la Figure 7.3.

Figure 7.3: Exemple d’ılot cable, represente ici par la piscine.

43.


Un probleme frequent se produit lors du retour station lorsque le terrain contient tropd’ılots. En effet, le robot possede une procedure qui fait qu’au dela d’un certain nombre detours effectues en suivant le fil peripherique, celui-ci decroche du fil et va le raccrocher a unautre endroit. Le robot va donc identifier correctement les ılots et s’en decrocher mais au finalva passer d’un ılot a l’autre et ainsi se decharger avant d’atteindre sa station. Dans la realite,un maximum de 5 ılots est autorise, le robot risquerait donc de tomber en panne regulierementsi l’on augmentait ce nombre.

Nous avons realise une simulation sur un terrain possedant 7 ılots et les resultats montrenteffectivement que, sur 5 simulations, le robot est a chaque fois tombe en panne a cause des ılots,et cela en moins de 30 heures.

Figure 7.4: Les ılots empechent le robot d’accrocher le bon cable peripherique.

Traces dans la pelouse

Un des problemes principaux de BelRobotics sur les terrains de golfs sont les traces qu’en-gendrent les passages repetes du robot en suivant son cable lors du retour station. C’est l’un desobjectifs du projet “golf ” visant l’amelioration des robots que de minimiser les traces laisseespar les robots. Une solution de robot a pneus larges a ete proposee, mais comme on le voit surla Figure 7.5, cela n’est pas concluant.

Nous avons decide de tester un robot sur une periode de 3 jours. Comme explique par la suitedans le chapitre 12, nous avons developpe un prototype d’algorithme utilisant un module GPS

44.


Figure 7.5: Photographie des traces laissees par le robot lors des retours stations.

permettant au robot de connaıtre sa position approximative et d’effectuer un mapping de sonenvironnement afin de pouvoir rentrer a sa station sans suivre le cable. Pour demontrer l’utilitede cet algorithme pour resoudre ce probleme de traces, nous avons compare deux simulations,l’une utilisant l’algorithme classique, l’autre utilisant l’algorithme GPS.

Nous obtenons comme resultat interessant la Figure 7.6. Celle-ci a ete realisee avec le filtre“Relative Passage Number”, les zones les plus vertes representent donc les endroits les plusfrequentes, et les zones rouges les endroits les moins frequentes. On observe clairement surla partie gauche une “ligne verte” faisant le tour du terrain. Cette ligne represente le grandnombre de passages realises le long de fil peripherique par rapport au reste du terrain, passagesqui engendreront des traces dans la pelouse. JSR met donc en evidence le probleme des traceslaissees par les robots.

Figure 7.6: Comparaison des traces laissees par le robot.Navigation classique (gauche) et navigation GPS (droite).

Par contre, on observe sur la partie droite qu’aucune ligne verte n’est presente. Commeexplique dans le chapitre sur les algorithmes de navigation, cela montre que notre algorithme

45.

7. Validation 7.2. Test d’un cas concret

de navigation GPS apporte une solution viable concernant le probleme des traces dans lesterrains de golf.

7.2 Test d’un cas concret

Pour conclure notre validation, nous nous sommes interesses a un cas provenant des forma-tions techniques donnees aux techniciens charges d’installer les robots. Il s’agit d’une grandesurface de pelouse privee dans la region du Brabant Wallon.

Les explications donnees lors de la formation recommandent de placer deux stations etd’utiliser une BigMow. La surface totale du terrain est de 1.19 hectare. D’apres les exigencesimposees par BelRobotics, plus de 98% du terrain devrait donc avoir ete visite au moins unefois.

Figure 7.7: Terrain prive.

Simulation

Pour commencer, nous avons construit le terrain dans l’editeur d’environnement. L’integrationde Google Map dans JRS nous a permis de reproduire facilement l’installation avec beaucoupde precision. Nous avons dans un premier temps pu valider cette extension car la surface totaleque nous avons obtenue avec l’editeur est de 12.008 m2, ce qui correspond a 1.19 hectare (erreurde moins de 1%). Nous avons egalement dessine les zones alentours pour donner un peu plusde vie a la simulation.

Les deux stations etant placees, nous avons ensuite lance dix simulations avec la configu-ration de base de la BigMow. En moyenne, apres trois jours de simulation, les statistiquesindiquent une performance de 99.62 % pour la couverture d’au moins un passage et 94.83 %

46.


Figure 7.8: Parcelles visitees au moins trois fois (vert), deuxfois (orange clair), une fois (orange fonce) ou zero fois (rouge)).

pour la couverture d’au moins trois passages. L’uniformite valant quant a elle 97.98%, ce quimontre que le terrain a ete correctement couvert. Ces resultats confirment donc les informationsprovenant des formations techniques.

Mais nous n’en sommes pas restes la, nous avons voulu aller plus loin avec le simulateurafin de prouver que deux stations sont obligatoires pour ne pas que le robot tombe en panne.Nous avons donc supprime une des stations et nous avons egalement lance 10 simulations. Auterme de ce processus, les resultats sont sans appel, 8 simulations ont souleve l’erreur � SHUTDOWN ERROR �, indiquant que le robot est tombe en panne. Tres certainement car il n’estpas arrive a revenir jusqu’a sa station a temps, a cause des deux ılots et de la longueur du cableperipherique.

En conclusion, pour chaque situation, le comportement attendu qui a ete observe dans larealite est tres proche du comportement observe au sein du simulateur, ce qui prouve la validitedu simulateur. De plus, les membres de BelRobotics, autant les techniciens que les installateursou que les ingenieurs, ont observe une grande similitude entre le comportement reel des robotssur le terrain et les resultats obtenus par nos simulations. Il est donc juste de considerer queJRS permet une simulation de l’activite des robots dans leur environnement de travail qui esttres proche de la realite. On peut donc considerer le logiciel comme valide.

47.


Figure 7.9: Le parcours du retour station mis enevidence avec le nombre de passages.

48.

Troisieme partie

Architecture

49

Chapitre 8

Generale

Notre architecture est composee de trois parties : la partie graphique, la partie editeur et lapartie simulateur. Pour commencer, abordons quelques concepts generaux de notre architecture,nous verrons ensuite ces trois parties de facon plus detaillee.

8.1 Structure

La totalite de notre memoire comptabilise plus de 24.000 lignes reparties dans 150 classestriees dans 30 packages. On comprend alors vite qu’une structure performante a du etre miseen place pour organiser tous ces fichiers.

Separation conceptuelle

Une premiere separation conceptuelle a ete operee dans notre architecture. Celle-ci a eterealisee en suivant le pattern Model View Controler, aussi appele MVC. Le pattern MVC estdestine aux applications interactives, comme c’est le cas pour le simulateur. Il a pour butde separer les differentes composantes en les regroupant selon leurs fonctions respectives. Ondistingue 3 packages principaux : le modele, la vue et le controleur.

1. Model : Le modele represente le cœur algorithmique du logiciel. Il re-groupe les fonctions concernant le stockage des donnees, ainsi que leurtraitement.

2. View : La vue constitue l’interface avec l’utilisateur. Elle affiche lesinformations stockees dans le Modele et relaye les differents evenementsproduits par l’utilisateur (mouvement de souris, selection d’un bouton,etc).

3. Controller : Le controleur prend en charge la gestion des evenementsafin de les synchroniser entre la Vue et le Modele.

51

8. Generale 8.2. Categorie d’objets

Separation fonctionnelle

Dans chacun des packages Model et View une seconde separation sous-jacente dite fonction-nelle a ete realisee afin de distinguer les elements specifiques de l’editeur et du simulateur. Cetteseparation fonctionnelle necessite donc la creation de deux packages “editor”, et “simulator”dans la View et dans le Model.

8.2 Categorie d’objets

Les 150 classes que nous avons implementees nous ont egalement forces a trier nos classesintelligemment. Pour ce faire, nous nous sommes bases sur le pattern Composite que nous avonsquelque peu remanie. Il est important de bien comprendre ce concept, car il est present partoutdans notre architecture.

Nous nous sommes rendu compte que la grande majorite de nos objets sont regroupables encategories. Tous ces objets possedent frequemment un ensemble de fonctionnalites communes,qu’ils doivent imperativement implementer. Pour rendre obligatoire ces fonctionnalites, noussommes passes par des classes abstraites. En effet, celles-ci permettent de definir un ensemble demethodes obligatoires mais egalement d’implementer celles qui sont identiques a chaque objet.Avec ce systeme nous avons identifie trois types d’objets (Figure 8.1) : les racines, les feuilleset les gestionnaires.

1. Root : Les objets racines sont des classes abstraites decrivant les fonc-tionnalites de base que doit implementer une categorie d’objets.

2. Leaves : Les objets feuilles sont les classes d’une categorie. Elles implemententl’objet racine de cette derniere.

3. Manager : Les objets gestionnaires manipulent et agencent les objetsfeuilles de leur categorie.

Figure 8.1: Racine, feuilles et gestionnaire.

52.


Afin de plus facilement identifier la categorie de nos objets, nous avons adopte une conven-tion de nommage regie par 3 regles :

1. Chaque categorie est identifiee par une lettre de l’alphabet.

2. Il n’existe qu’un objet racine par categorie et celui-ci doit obligatoire-ment s’appeler XObject (ou X est la lettre de la categorie).

3. Chaque objet feuille d’une categorie doit obligatoirement s’appeler XMyOb-ject (ou X est la lettre de la categorie et MyObject le nom de l’objet).

Categories existantes

Dans l’architecture actuelle du code, nous avons identifie 10 categories :

Categorie Domaine Racine GestionnaireNbr defeuilles

Environnement Editeur EObject.java Environment.java 6

Parametre Simulateur PObject.java Parameters.java 10

Statistique Simulateur SObject.java Statistics.java 5

Module Simulateur MObject.java Robot.java 9

Action Simulateur AObject.java MMotion.java 4

Comportemant Simulateur BObject.java Scheduler.java 22

Zone Simulateur ZObject.java Parcel.java 3

Filtre Simulateur FObject.java Statistics.java 9

Liste Graphisme LObject.java List.java 18

Moteur Graphique Graphisme GObject.java Graphic.java 10

Table 8.1: Categories existantes

53.


54.

Chapitre 9

Graphisme

La premiere architecture que nous allons aborder est celle relative a l’interface graphique.Lorsque nous avons commence l’implementation du logiciel nous avons tres vite ete insatisfaitsdes composantes basiques de Java. En effet, les differents objectifs que nous nous etions fixesne nous permettaient pas, avec les composantes standards de Java, de developper et aboutir aune application acceptable. De plus, nous trouvions que le style bleu metallique de l’API Swingn’etait pas approprie a notre simulateur. Le logiciel ayant egalement pour vocation d’etre utilisepar le departement marketing, il etait donc primordial de soigner notre interface graphique pourne pas faire fuir les clients au premier coup d’oeil.

Nous avons donc decide de developper nos propres composantes graphiques. Le travail quenous avons realise a ce niveau peut etre divise en 3 categories :

1. Les composantes de base : Nous avons redessine toutes les compo-santes de base d’une interface graphique. Cela comprend les boutons, leszones de texte ou encore les barres de progression.

2. Les listes : Nous avons developpe notre propre systeme de listes. Celui-ci sert a afficher verticalement des informations a l’utilisateur. Ces listesn’ont rien de comparable avec une liste deroulante, elles peuvent contenirde gros objets. Elles sont utilisees dans quasiment toutes les fenetres dusimulateur.

3. Le moteur graphique : Nous avons egalement developpe notre propremoteur graphique. Celui-ci permet de dessiner et de manipuler un en-semble de formes ou d’images. Parmi ces fonctionnalites, il y a un mecanismede zoom fluide, un systeme de deplacement intuitif ou encore des echellespersonnalisables.

55

9. Graphisme 9.1. Composantes de base

Figure 9.1: Architecture graphique.

9.1 Composantes de base

A la demande de l’entreprise dans laquelle ce memoire aete realise, cette partie n’est pas disponible publiquement.Elle cessera d’etre confidentielle en juin 2019.

56.

9. Graphisme 9.2. Listes

9.2 Listes


9.3 Moteur graphique


9.4 Gestionnaire de ressources


57.

9. Graphisme 9.4. Gestionnaire de ressources

58.

Chapitre 10

Editeur

L’editeur va permettre a l’utilisateur de creer son environnement (Figure 10.1). Il va egalementpermettre de personnaliser le robot et les statistiques de simulation, mais ces deux fonctionna-lites seront detaillees dans l’architecture du simulateur.

Figure 10.1: Fenetre de l’editeur d’environnement.

Commencons par aborder la facon dont nous avons agence la fenetre de notre editeur. Elleest composee de 2 elements principaux :

1. Au centre de la fenetre se trouve l’environnement que l’utilisateur construit.Il est represente a l’aide de notre moteur graphique.

2. A droite de la fenetre se trouve une liste. Celle-ci contient tous leselements presents au sein de l’environnement.

Chaque element de l’environnement est donc simultanement present dans la liste de droiteet dans le moteur graphique au centre.

59

10. Editeur 10.4. Google Map

10.1 Implementation


10.2 Objets existants


10.3 Conversion


10.4 Google Map


60.

Chapitre 11

Simulateur

Nous allons maintenant aborder la derniere architecture de notre logiciel, celle du simulateur.Contrairement au chapitre decrivant le logiciel, il est ici important de bien se rendre compteque nous ne sommes plus a la place d’un simple utilisateur. Pour expliquer l’architecture dusimulateur nous allons nous mettre a la place d’un ingenieur de BelRobotics qui desire ajouterdes fonctionnalites au logiciel. Ces nouvelles fonctionnalites vont necessiter de sa part uneintervention dans le code source. Bien entendu, comme vous le constaterai, nous avons essayede rendre notre architecture la plus modulable possible pour lui faciliter la tache. Lorsque nousparlerons dans nos explications d’un developpeur externe ou d’un ingenieur de BelRobotics,cela fera donc reference a un developpeur peu familier avec le code source et son architecture.

Nous allons maintenant aborder la derniere architecture de notre logiciel, celle du simulateur.Dans ce chapitre nous allons principalement parler du fonctionnement des simples simulations(Figure 11.1). La multi-simulations n’etant qu’un ensemble de simples simulations, nous nel’aborderons quasiment pas.

Figure 11.1: Fenetre de simulation.

61

11. Simulateur .

Commencons par voir les trois composantes d’une simple simulation (Figure 11.2) :

1. Un robot : Le robot est compose d’un ensemble de modules qui si-mulent ses composantes electroniques. Chaque module est independantdes autres et remplit une tache bien precise.

2. Une navigation : La navigation est le corps decisionnel du robot,elle utilise une liste de comportements ainsi qu’un ordonnanceur pourdeterminer dans quel etat elle se trouve.

3. Un environnement : L’environnement represente le monde virtueldans lequel le robot va evoluer. Il est compose d’un grand tableau deparcelles qui represente l’environnement de simulation. Chaque parcellepointe vers un type de zone particuliere. L’environnement gere egalementune multitude de stations.

Figure 11.2: Composantes d’une simulation.

62.

11. Simulateur 11.1. Prerequis

11.1 Prerequis


11.1.1 Les parametres


11.1.2 Les statistiques


63.

11. Simulateur 11.1. Prerequis

64.

11. Simulateur 11.2. Le robot

11.2 Le robot

Maintenant que les concepts de parametres et statistiques ont bien ete assimiles, nous allonsaborder le premier point central du simulateur : le robot.

Pour le robot, nous avons du imaginer une architecture qui soit a la fois modulable, effi-cace et surtout, simple d’utilisation. En effet, une grande partie des modifications qu’apporte-ront les ingenieurs de BelRobotics se situeront dans le robot. Il est donc primordial que sonfonctionnement soit simple et efficace, afin de leur donner un maximum de liberte dans leursexperimentations.

Nous avons choisi de representer notre robot comme un ensemble de boıtes ayant chacuneun role bien precis. Nous avons appele ces boıtes, des modules. Un module seul n’a pas d’interet,mais plusieurs modules rassembles forment un robot (Figure 11.3).

Figure 11.3: Les modules d’un robot.

Les modules jouent un role central dans le simulateur, ils sont consideres comme les yeux etles oreilles de la navigation. Chaque module est une composante electronique du robot. Nousavons donc par exemple, un module sonar, un module magnetique, un module de deplacement,ou encore un module de tonte. Ils ont chacun une fonctionnalite bien precise et n’ont quasimentpas d’interaction entre eux (le module sonar ne va jamais interagir de lui-meme avec le modulede deplacement).

C’est en realite, a travers la navigation, que les modules vont avoir du sens. Celle-ci va, parexemple, verifier d’eventuels obstacles avec le module sonar, pour ensuite decider de l’actiona realiser avec le module de deplacement. Voyons les trois raisons qui nous ont pousses adevelopper ce systeme de modules :

1. Cacher l’environnement a la navigation : Dans la realite, la navi-gation n’a pas connaissance de son environnement, elle doit le decouvrira l’aide de ses nombreux senseurs (sonar, bobine magnetique, boudinde pression, etc). Dans le simulateur nous avons voulu reproduire ce

65.


concept de visibilite, et ne laisser paraıtre a la navigation que ce qu’elleest censee voir dans la realite. L’environnement n’est donc pas acces-sible a la navigation, cette derniere doit passer par les modules pour ledecouvrir.

2. Rendre les modules independants : La division du robot en modulespermet de rendre presque tous les modules independants les uns desautres. De cette maniere, on pourrait imaginer un robot sans lame detonte, simplement en lui enlevant le module de tonte. Il pourrait toujoursse deplacer, detecter les obstacles et les eviter, mais il ne tondrait plus.La suppression de ce module n’entraınerait aucune erreur dans les autresmodules etant donne qu’ils n’interagissent pas entre eux.

Cependant, il arrive parfois que cette independance ne soit pas possible.C’est le cas, par exemple, pour le module de deplacement qui a besoind’interagir avec le module batterie pour prendre en compte sa consom-mation energetique.

3. Faciliter l’integration de nouvelles fonctionnalites : Pour finir,cette division en modules permet d’ajouter facilement de nouvelles fonc-tionnalites, sans devoir les ajouter dans une grosse classe illisible. Ellepermet de rendre notre architecture tres modulable. Nos modules etantindependants, ils peuvent egalement etre facilement mis a jour car leurdomaine d’action se limite a leur classe.

11.2.1 Implementation


11.2.2 Exemple


66.


11.2.3 Modules existants


67.


68.

11. Simulateur 11.3. La navigation

11.3 La navigation

Abordons des a present le deuxieme point central du simulateur : la navigation. Le systemede navigation concerne la partie qui recoit les informations des differents modules et qui decidede la prochaine action a realiser. Elle utilise une liste de comportements ainsi qu’un ordonnan-ceur pour determiner dans quelles taches elle se situe (Figure 11.4) :

Figure 11.4: L’ordonnanceur et ses comportements (version simplifiee).

Avant de choisir ce type d’ordonnanceur, nous avons envisage d’autres solutions, toutes plustordues les unes que les autres. C’est finalement suite au conseil de Mr. Pecheur que nous avonsdecide d’utiliser une architecture de controle par taches :

”L’architecture de controle par taches permet de realiser un programmereactif de maniere modulaire. Le principe est de decomposer le pro-gramme en plusieurs taches qui sont executees au besoin, en respec-tant un ordre de priorite, plutot que de maniere predeterminee par leprogramme. Ceci permet de caracteriser clairement chaque aspect ducomportement, et d’ajouter facilement des taches supplementaires.”12

Nous nous sommes bases sur l’architecture presente dans le LoJOS NXJ, qui est un envi-ronnement de programmation Java pour le Lego Mindstorms NXT. Nous l’avons entierementreecrit et avons adapte son fonctionnement afin qu’il soit compatible avec une execution en

69.

11. Simulateur 11.3. La navigation

temps discret, comme c’est le cas dans notre simulateur. En effet, dans notre cas les calculssont realises lors de chaque iteration, toutes les 100 millisecondes.



11.3.2 Exemple


11.3.3 Algorithmes de navigation


70.

11. Simulateur 11.4. L’environnement

11.4 L’environnement

Pour finir, abordons le troisieme point central du simulateur : l’environnement. L’environ-nement represente le monde virtuel dans lequel le robot va evoluer. Il est compose de parcelles,chacune pointant vers un type de zone particuliere (Figure 11.5). Il est important de faire ladifference entre l’environnement cote simulateur et celui cote editeur, car leur representationest completement differente.

Figure 11.5: Les stations, parcelles et zones de l’environnement.



11.4.2 Affichage


71.

11. Simulateur 11.4. L’environnement

72.

11. Simulateur 11.5. Simulation

11.5 Simulation


73.

11. Simulateur 11.5. Simulation

74.

Chapitre 12

Algorithmes de navigation

Nous avons, dans le cadre de ce memoire, implemente deux algorithmes de navigation :

• L’algorithme de navigation actuel des robots (algorithme classique) afinde pouvoir etudier son comportement et ses eventuels defauts, maisegalement afin de pouvoir tester le bon fonctionnement du simulateur.

• Un prototype d’algorithme utilisant le positionnement GPS dans sa na-vigation.

Tous les algorithmes de navigation ont ete realises en suivant l’architecture de navigationdeveloppee precedemment. Cela nous a permis notamment de reutiliser des elements de l’algo-rithme classique pour notre prototype d’algorithme GPS.

12.1 Navigation classique


12.2 Navigation GPS


75

12. Algorithmes de navigation 12.2. Navigation GPS

76.

Chapitre 13

Algorithmes particuliers

Dans cette section, nous detaillerons quelques algorithmes particuliers qui ont ete integresa notre logiciel et qui valent la peine d’etre detailles dans le cadre de ce travail.

13.1 A-star

Comme explique dans la chapitre sur les algorithmes de navigation, concernant l’algorithmede navigation GPS, le robot rentre en calculant le chemin le plus court vers un point de re-entree station tout en evitant un maximum les tournants. L’algorithme de calcul du plus courtchemin se base sur l’algorithme A* modifie afin d’eviter un maximum de tournants.

Pour rappel, l’algorithme A* est un algorithme permettant de trouver un chemin entre deuxnoeuds dans un graphe. Une fonction heuristique est utilisee sur chaque noeud afin d’estimerle meilleur chemin et les noeuds sont ensuite visites dans l’ordre donne par l’evaluation de lafonction. Dans notre cas, le graphe est construit a partir de de la matrice realisee par le mappingdu module MMap.

Le cout heuristique utilise pour notre implementation est le suivante :

costHeuristic(node) = cost(node) + functionHeuristic(node)

• cost(node) : distance parcourue entre le noeud courant et le noeudinitial (1 par deplacement normale ; 1.5 par tournant)

• functionHeuristic(node) : distance a vol d’oiseau entre le noeud cou-rant et le noeud final.

A* commence au noeud de depart (la case correspondant a la position du robot). Il vaappliquer la fonction heuristique a ce noeud, et si celui-ci est le noeud d’arrivee (la case cor-respondant au point de re-entree station) alors la recherche de chemin s’arrete. Si ce n’est pasle cas, il va alors appliquer la fonction d’evaluation a tous ses noeuds limitrophes (cases depelouse limitrophes dans la matrice de mapping) et les ajouter dans une file de priorites.

A* prendra ensuite le noeud le plus prioritaire de la file (le retirera) et y appliquera lesmemes etapes que celles appliquees au noeud de depart, c’est a dire : appliquer la fonction

77

13. Algorithmes particuliers 13.2. Champ magnetique

d’evaluation a tous ses noeuds limitrophes (cases de pelouse limitrophes dans la matrice demapping) et les ajouter dans une file de priorite.s L’algorithme s’arrete quand le noeud analyseest le noeud de destination, dans ce cas on a trouve un chemin, ou quand la liste est vide,dans ce cas il n’existe pas de chemin possible. Si le noeud de destination est atteint, alors onreconstruit un chemin du noeud de depart au noeud d’arrivee. Il est necessaire de sauvegarderune liste des noeuds explores afin d’eviter de realiser des boucles lors de l’exploration du graphe.

Figure 13.1: Exemple de l’algorithme A* avec une heuristique dedistance manhattan (distance en L).

Le principal avantage de cet algorithme est qu’il n’y a pas de pre-calcul necessaire et qu’ilconsomme peu de memoire, il est donc adapte au petit processeur des robots tondeuses.

13.2 Champ magnetique

Comme explique precedemment, l’environnement est represente par une matrice de parcelles.Chaque parcelle possede une variable representant la distance par rapport au point du cable leplus proche. La valeur du champ magnetique emis par le cable en chaque parcelle, est simuleepar la valeur de la distance par rapport au cable. Afin de representer le changement de phasedu champ magnetique entre l’interieur et l’exterieur du cable peripherique, les distances sontpositives a l’interieur et negatives a l’exterieur.

On construit donc une matrice de distances par rapport au cable afin de simuler le champmagnetique en tout point du terrain. Cette matrice est calculee avant l’execution de la simula-tion. L’algorithme de construction de la matrice du champ magnetique est decompose en troisetapes :

La premiere etape consiste a initialiser l’ensemble des valeurs de la matrice afin de savoirquelles sont les cases interieures et quelles sont les cases exterieures au fil peripherique.

La valeur de la case est initialisee a 1 si celle-ci se trouve a l’interieur du cable peripherique,c’est-a-dire si la parcelle correspondante est sur une zone de type ZObstacle ou ZGrass.

78.


La valeur de la case est initialisee a -1 si celle-ci se trouve a l’exterieur du cable peripherique,c’est-a-dire si la parcelle correspondante est sur une zone de type ZObstacle ou ZGrass.

La seconde etape consiste a mettre la valeur de toutes les cases non limitrophes au filperipherique a 0. On parcourt donc toute la matrice et toutes les cases ne possedant pas unvoisin de valeur opposee sont mise a 0. On obtient la valeur de toutes les cases a la bordure dufil peripherique.

La troisieme etape va consister a donner la valeur de la distance par rapport au cable en toutpoint de la matrice. Pour cela, on part de l’ensemble des cases dont la valeur est egale a +/- lavaleur courante, 1 etant la valeur courante initiale de l’etape. Pour chaque case de l’ensemble,on regarde toutes les cases limitrophes (mais pas les cases situees en diagonale) dont la valeurvaut 0, on les appellera les voisins. On met la valeur des voisins a +/- [la valeur courante +1], + si les voisins sont limitrophes a une case negative, - autrement. Une fois la liste vide, onincremente la valeur courante de 1, et on recommence l’etape 3. L’etape se termine lorsqu’iln’y a plus de case correspondant a la valeur courante.

On obtient ainsi une matrice donnant la distance par rapport au cable en tout point duterrain (Figure 13.2).

Figure 13.2: Exemple de matrice de distance par rapport au cable.

Il est a noter que, ce sont le filtre magnetique et le module magnetique qui produisent l’effetde “champ constant” a partir d’une certaine distance du cable. C’est a dire qu’a partir d’unecertaine distance du cable, la valeur du champ magnetique retournee par le module MMagneticsera constante. Cela represente le fait qu’au dela d’une certaine distance du fil peripherique, lechamp possede une valeur faible quasi constante.

Ce systeme de matrice permet une approximation convenable du champ magnetique produitpar le fil peripherique. Il permet de par le pre-calcul, d’alleger les operations realisees pendant la

79.


simulation et ainsi d’accelerer celle-ci. Le module magnetique du robot est egalement simplifiecar celui-ci n’a plus qu’a lire la valeur de la distance en fonction de la parcelle sur laquelle il setrouve. C’est donc une solution simple, robuste et efficace.

80.

Quatrieme partie

Conclusion et perspectives

81

Chapitre 14

Rappel des objectifs

Pour rappel, le but de ce memoire etait de concevoir un logiciel de simulation pour robotsautonomes afin de pouvoir tester rapidement et facilement les nouvelles ameliorations possibleset ainsi d’evaluer leurs impacts sur les performances de ces robots. Nous allons brievementrevoir l’ensemble des objectifs qu’il nous a ete demande de realiser tout au long de ce projet.

Les objectifs architecturaux etaient les suivants :

• La solution doit etre modulaire afin de permettre aux ingenieurs deBelRobotics de continuer a developper facilement des fonctionnalites ausein du simulateur.

• Le logiciel doit etre separe en deux parties distinctes, simulateur etediteur, pour conserver leur independance et faciliter ainsi les develo-ppements futurs.

• Enfin, l’interface graphique du logiciel doit etre geree automatiquementpar le programme afin de ne pas devoir s’occuper de l’ajout des compo-santes graphiques lors du developpement de nouvelles solutions par lesingenieurs.

Les objectifs fonctionnels etaient les suivants :

• Le logiciel doit posseder un editeur permettant de creer des environne-ments personnalisables.

• Le robot doit facilement etre parametrable via une interface dediee, per-mettant de sauvegarder et reutiliser a tout moment l’une de ses confi-gurations.

• Le programme doit comporter un gestionnaire de simulation montrantgraphiquement l’evolution du robot dans son environnement de travail,avec la possibilite de modifier sa vitesse de simulation.

• La simulation graphique doit comporter un ensemble de filtres permet-tant de faciliter la comprehension visuelle de l’environnement via l’affi-chage de differents types d’informations.

83

14. Rappel des objectifs .

• A la fin d’une simulation, toutes les donnees statistiques doivent etresauvegardees dans un fichier externe sous forme de tableau.

• L’utilisateur doit avoir la possibilite de lancer, de maniere automatique,une grande quantite de simulations avec des parametres variables, etcela dans le but de determiner l’efficacite de ces variations.

• L’interface graphique doit etre soignee et permettre une utilisation plusconfortable du logiciel.

• Des criteres objectifs permettant de definir les performances des robotsdans leur environnement doivent etre definis.

84.

Chapitre 15

Solution developpee

Le premier probleme auquel nous avons ete confronte a ete la necessite de pouvoir testerrapidement et facilement les nouvelles ameliorations possibles des robots afin d’evaluer leursimpacts sur les performances de ces robots. Toutes les solutions existantes etant complexes,chronophages et couteuses.

Afin de resoudre ce probleme, nous avons donc developpe JRS, un logiciel de simulationde robots mobiles autonomes dans son environnement de travail. JRS permet, de par ses nom-breuses fonctionnalites, de tester rapidement et efficacement les nouvelles ameliorations afind’evaluer leurs impacts sur les performances des nouveaux robots.

• Les nouveaux algorithmes peuvent etre facilement encodes dans notrelogiciel grace a l’architecture modulaire du systeme de navigation parcontrole de taches.

• La decomposition du robot en un ensemble de modules dans JSR, rendtres facile la modification des elements le constituant afin de tester parexemple un module GPS modifie.

• Les systemes des parametres et des statistiques, permettent facilementl’ajout de nouveaux parametres et de nouvelles statistiques de simula-tion qui seront rendus disponibles automatiquement dans les interfacesgraphiques.

• Un editeur de robots et de parametres, ainsi qu’un editeur d’environne-ment complet permettent a l’utilisateur de tester un grand nombre deconfigurations differentes de test.

• Le simulateur permet d’observer l’evolution en temps reel du robot dansson environnement de travail, avec la possibilite d’accelerer la vitessed’execution du robot et d’utiliser des filtres affichant differents typesd’informations.

• Il est egalement possible d’executer plusieurs simulations simultanementavec des ensembles de parametres differents, afin d’exploiter pleinementla puissance de calcul d’un ordinateur en vue d’une optimisation desparametres de navigation.

85

15. Solution developpee .

L’evaluation de l’impact des ameliorations a l’aide de notre logiciel a souleve un secondprobleme : la necessite de pouvoir quantifier les performances d’un robot. Etant donne qu’iln’existait aucun critere permettant d’evaluer les performances des robots tondeuses, nous avonsdu definir des criteres objectifs permettant d’evaluer les performances des robots dans leurenvironnement.

Les differents criteres developpes ont permis la quantification d’une notion complexe qui,auparavant, necessitait de visualiser le terrain pour evaluer si le resultat de la tonte etait accep-table. Grace aux trois criteres numeriques developpes, il est maintenant possible de comparerplusieurs simulations sur la simple base de leurs statistiques, afin de determiner laquelle d’entreelles donne les meilleurs resultats.

Enfin le troisieme probleme qui nous a ete pose consiste en la creation d’un prototyped’algorithme de navigation des robots utilisant la technologie de positionnement GPS.

Apres avoir implemente l’algorithme de navigation actuel des robots tondeuses BelRobotics,nous avons donc developpe un prototype d’algorithme utilisant un module GPS permettant aurobot de connaıtre sa position approximative et d’effectuer un mapping de son environnementafin de pouvoir rentrer a sa station sans suivre le cable. Cet algorithme apporte une solutionefficace au probleme des traces que realise le robot en suivant son cable, du fait que le robotrentre a sa station par des chemins differents qui passent par le centre du terrain.

86.

Chapitre 16

Ameliorations et perspectives

Dans ce chapitre, nous presenterons les differentes ameliorations qu’il serait interessant d’ap-porter au projet. Nous aborderons deux types de travaux futurs, les ameliorations a apporterau logiciel, et les ameliorations a apporter aux algorithmes de navigation.

16.1 Simulateur


16.2 Navigation


87

16. Ameliorations et perspectives 16.2. Navigation

88.

Chapitre 17

Conclusion

En conclusion, parmi l’ensemble des problemes qui nous ont ete posee au depart,tous ont ete resolus. Nous avons ete amenes a developper JRS, qui est devenu a cejour un puissant outil muni de nombreuses fonctionnalites et, comme le montre le cha-pitre sur les travaux futurs, possedant beaucoup de potentiel. Nous avons egalementdeveloppe les premiers criteres numeriques rendant possible la comparaison de plu-sieurs simulations. Pour terminer, nous avons realise un nouvel algorithme de naviga-tion GPS resolvant un important probleme de la navigation classique des robots.

Le logiciel que nous avons developpe, JRS offre de nombreuses possibilites.

JRS, de par sa modularite, permet de continuellement adapter le robot et d’evaluerses performances, ce qui est un enorme atout dans un contexte technologique enevolution constante. Il rend possible la prise en compte de l’evolution continue dela technologie de positionnement GPS, permettant ainsi d’ameliorer et d’affiner sanscesse les resultats au cours de cette evolution.

La technologie GPS n’est pas la seule en evolution constante : les vehicules electriquessuscitant un interet croissant, l’amelioration des batteries devient une source d’inno-vations importantes. Nous pouvons d’ailleurs le constater avec les nouvelles batteriesdeveloppees a l’UCL qui allient super capacite et charge ultra-rapide15.

Mais la modularite et la flexibilite de JRS ne se limite pas a sa capacite d’adap-tation a l’evolution technologique. Cela rend egalement envisageable, moyennant uneinterface adequate, la compilation directe du code source du software robot afin depouvoir valider ce code directement sur PC a l’aide de JRS. Cette approche est dite’host build’. La validation directe du code source du robot serait un puissant outil devalidation et de developpement.

Les possibilites offertes par JRS ne concernent pas que le test d’amelioration desconcepts et des machines existantes. Il peut egalement etre utilise afin de tester detout nouveaux systemes comme par exemple estimer les performances d’une flottede robots cooperant entre eux, comme c’est le cas dans le projet Swarm-Bots14. Leprincipe serait d’utiliser des robots simples et peu couteux, d’un interet individuellimite, mais qui ensemble forment un systeme complexe et robuste.

Il est egalement important de noter que JRS offre des possibilites aux equipes derecherche et developpeme, mais aussi aux equipes de management. Par exemple, une

89

17. Conclusion .

modelisation correcte du robot Ballpicker permettrait de predire approximativementle nombre de balles ramassees par jour offrant ainsi la possibilite de developper unnouveau modele financier pour BelRobotics ou le client ne payerait pas l’installationdu systeme, mais payerait ”par balle ramassee”.

Son utilisation a des fins commerciales peut aussi concerner le dimensionnementdes cas d’installations tres complexes et quasi impossibles a modeliser, comme parexemple des vergers ou des surfaces industrielles complexes.

Enfin, une utilisation du logiciel a plus large spectre est clairement envisageable.On pourrait imaginer d’etendre JRS aux robots de traitements de surfaces comme lesaspirateurs robots autonomes par exemple.

Comme le montrent tous ces exemples, la modularite et la flexibilite de notresolution offre des perspectives d’avenir fort interessantes.

Et qui sait, si un jour l’humanite quitte la planete en oubliant de debrancher ledernier robot, celui-ci aura peut-etre ete developpe a l’aide de JRS.

90.

Chapitre 18

References

1. Dynamite, Site internet de BelRobotics, http ://www.belrobotics.com/,version 2014, editeur : BelRobotics, site internet

2. Belrobotics sa/nv, Formation technique, version 2014, editeur : BelRo-botics, document

3. Ho Trong Viet - Charles Pecheur, Programmer le NXT, Version 4 – 13Nov 2012, editeur : FSAB 1501 – Projet 1, document

4. ArduMower Project, http ://www.ardumower.de, site internet

5. Dr. Marco Dorigo, Swarm-bots Project, European Commission (IST-2000-31010), http ://www.swarm-bots.org/, site internet

6. JavaTM Platform, Standard Edition 7 API Specification, 1993 - 2014,Oracle and/or its affiliates, site

7. Ponciano Jean-Jacques - Prudhomme Claire, Simulation d’un robot as-pirateur charge de nettoyer une piece comportant des obstacles, publiedurant l’annee academique 2011-2012, editeur : cours L2 Informatique -Universite de Bourgogne, document & logiciel

8. Viking, Planificateur de jardin iMow, http ://plan-imow.viking-jardin.fr/,publie en 2014, editeur : Viking, logiciel

9. Sebastien Roed Mangseth, Robot Vacuum Simulator 2013, http ://www.itwire.com/your-it-news/entertainment/60619-robot-vacuum-simulator-2013-will-suck-up-your-life, publie en 2013, editeur : Stolidus Simulation,logiciel

10. David Hovemeyer, York College of Pennsylvania, Assignment 4 : Ro-bot Lawnmower Simulation, http ://goose.ycp.edu/ dhovemey/fall2009/cs201/assign/assign4.html, logiciel

11. Gardensoft, Advanced Lawnmower Simulator, publie en 1988, editeur :Your Sinclair (UK), logiciel

91

18. References .

12. LeJOS Project, LeJOS NXJ, http ://www.lejos.org/nxj.php, publie en2006, document & logiciel

13. Caceres Frias Edgard - Henricot Julien - LauchKim-Seang - MoulinRemy - Poelvoorde Nora - Toussaint Sebastien, Analyse de BelRobo-tics, publie en mai 2014, editeur : FSA2230-Sensibilisation a la gestiond’entreprise, document & expose

14. Scrum (software development), http ://en.wikipedia.org/wiki/Scrum (software development), publie le 27 May 2014, editeur : Wikipedia

15. Des batteries qui allient super capacite et charge ultra-rapide, actualites,http ://www.uclouvain.be/464558.html, UCL

16. Axel van Lamsweerde, INGI2251 - Software Enginnering and Project,2012-2013, UCL, Cour.

17. Yves Deville, INGI2261 - Artificial Intelligence, 2012-2013, UCL, Cour.

92.

Cinquieme partie

Annexe

93

Annexe A

Backlog


95

A. Backlog .

96.

Annexe B

Cahier des charges

Contexte

Le but du travail est de concevoir de nouveaux logiciels de navigation pour robot auto-matique de type tondeuse ou ramasseur de balles de golf. Dans un premier temps, il faudradevelopper un logiciel de simulation de robot tondeuse automatique, dans son environnementde travail. Dans un second temps suivra une phase de recherches et de tests sur de nouveauxalgorithmes de navigation, cette phase sera realisee a l’aide du logiciel de simulation developpedans la premiere phase du projet. Ce travail se fera en collaboration avec la societe BelRoboticsa Wavre, qui developpe ce type de robots. Il sera idealement couple a un stage au sein deBelRobotics.

L’objectif de ce programme est de faciliter les tests sur leurs produits ou sur differentsprototypes afin de developper des algorithmes de navigation plus performants. Il sera egalementutilise a des fins marketing dans le but de montrer au client les differentes possibilites offertespar les produits BelRobotics.

Fonctions


97

Documents

Impl ementation d’un logiciel de simulation de robot … · 2016-04-11 · toujours soutenus et encourag es au cours de la r ealisation de ce m emoire. Nous voulons aussi remercier