Implémentation d un logiciel de simulation de robot mobile autonome en vue d optimiser les performances de navigation

Transcription

1 UNIVERSITE CATHOLIQUE DE LOUVAIN ECOLE POLYTECHNIQUE DE LOUVAIN Implémentation d un logiciel de simulation de robot mobile autonome en vue d optimiser les performances de navigation Promoteur : Co-promoteur : Lecteur : Charles Pecheur Steve Tumson Marc Lobelle Mémoire présenté en vue de l obtention du grade de master en science informatique et du grade de master ingénieur civil en informatique. Option : Software engineering Par : Julien Bergiers & Julien Henricot Louvain-la-Neuve Année académique

2

3 Table des matières I Préliminaires 1 1 Prérequis Produits Principe de fonctionnement Etat de l art Planificateur de jardin Viking Simulateur issu du projet ArduMower Projet étudiant de l université de Bourgogne Simulateur de robots tondeuses par Alexander Grau Les pseudo-simulateurs Robot Vacuum Simulator Lawn Mower Simulator York College of Pennsylvania Jeu Lawn Mower Conclusion des recherches Méthode de travail Méthodologie Scrum Étapes d un sprint Énoncé du problème Objectifs architecturaux Objectifs fonctionnels II Solution 21 5 Description du logiciel Éditeur

4 5.2 Simple simulation Multi-simulations Méthodes d évaluation 39 7 Validation Test de comportement Test d un cas concret III Architecture 49 8 Générale Structure Catégorie d objets Graphisme Composantes de base Listes Moteur graphique Gestionnaire de ressources Éditeur Implémentation Objets existants Conversion Google Map Simulateur Prérequis Les paramètres Les statistiques Le robot Implémentation Exemple Modules existants La navigation Implémentation

5 Exemple Algorithmes de navigation L environnement Implémentation Affichage Simulation Algorithmes de navigation Navigation classique Navigation GPS Algorithmes particuliers A-star Champ magnétique IV Conclusion et perspectives Rappel des objectifs Solution développée Améliorations et perspectives Simulateur Navigation Conclusion Références 91 V Annexe 93 A Backlog 95 B Cahier des charges 97

6

7 Remerciements En préambule à ce mémoire, nous souhaitons adresser nos remerciements les plus sincères aux personnes qui nous ont apporté leur aide et qui ont contribué à l élaboration de ce mémoire, ainsi qu à la réussite de cette dernière année universitaire. En premier lieu, nous tenons à remercier le Professeur Charles Pecheur, notre promoteur, pour ses précieux conseils, ainsi que pour le temps et l écoute qu il nous a accordés tout au long de notre travail. Nous tenons également à remercier tout particulièrement Steve Tumson, ingénieur en électro-mécanique à la société BelRobotics. En tant que co-promoteur, maître de stage et initiateur de notre projet de mémoire, il a su nous guider dans notre travail et prendre le temps de nous aider à trouver des solutions pour avancer. Nous le remercions pour son accueil et la confiance qu il nous a accordée, et cela dès le début du projet. Nous n oublions pas nos familles pour leur contribution, leur soutien et leur patience, qui nous ont aidés à surmonter bien des obstacles. Un remerciement est également adressé à tous nos proches et amis, qui nous ont toujours soutenus et encouragés au cours de la réalisation de ce mémoire. Nous voulons aussi remercier Hassan, pour sa bonne humeur et pour son invitation, durement négociée, à la friterie. Un grand merci est adressé à l ensemble de l équipe de chez BelRobotics, pour leur accueil, leur sympathie et le temps qu ils nous ont consacrés dans le cadre du stage lié à ce mémoire. Nous tenons aussi à remercier toute personne qui a participé, de près ou de loin, à l exécution de ce travail de fin d études. i

8

9 Résumé Notre sujet de mémoire touche une importante innovation technologique de cette décennie, les robots tondeuses autonomes. La technologie des tondeuses robotiques est en pleine expansion, de nombreuses sociétés se développent à travers le monde, les techniques existantes évoluent et de nouvelles innovations apparaissent continuellement. Il devient nécessaire de pouvoir tester rapidement et facilement les nouvelles améliorations possibles afin d évaluer leurs impacts sur les performances de ces robots. A l heure actuelle, lorsqu une équipe désire tester une nouvelle solution, elle doit soit tenter de démontrer mathématiquement son impact, soit concevoir un prototype et le faire tourner sur un terrain de test pendant plusieurs jours avant d obtenir des résultats permettant d évaluer l amélioration. De plus, il n existe pas encore de critères permettant d évaluer les performances des algorithmes de navigation. La solution à ce problème consiste à implémenter un logiciel de simulation de robot mobile autonome dans son environnement de travail. Un tel logiciel permettrait de faciliter le développement et la validation des futures améliorations. Il est également nécessaire de définir ces critères, afin d évaluer de manière objective les performances des robots dans leur environnement. Nous avons donc entièrement développé un logiciel en Java, que nous avons nommé Java Robot Simulateur. Il offre la possibilité d évaluer l évolution d un robot tondeuse autonome dans son environnement de travail. JRS possède un éditeur d environnement ainsi qu un éditeur de robot permettant ainsi des combinaisons infinies de tests. De plus, celui-ci produit un ensemble de données. Notre outil permet de tester rapidement et efficacement les nouvelles améliorations apportées à l élaboration des nouveaux robots tondeuses et d évaluer leurs impacts sur les performances des nouvelles machines. Celui-ci est déjà en oeuvre dans la société BelRobotics et à fait ses preuves au sein de l équipe de recherche et développement. iii

10

11 Introduction Qu arriverait-il si l humanité quittait la planète en oubliant de débrancher le dernier robot. Andrew Stanton, vice directeur artistique du studio P ixar. Une chose est sûre, les pelouses continueraient d être bien tondues! Vous l aurez compris, notre sujet de mémoire touche une importante innovation technologique de cette décennie : les robots tondeuses autonomes. Les robots tondeuses ont été inventés par l ingénieur Belge André Collens et ont pour vocation de tondre les pelouses de manière entièrement automatisée. Ceux-ci sont de plus en plus présents dans les jardins particuliers mais émergent également dans les terrains de plus grandes superficies comme les golfs ou terrains de sport. Comme toutes nouvelles technologies, les robots tondeuses n apportent pas que des solutions, mais aussi leur lot de problèmes. La technologie des tondeuses robotiques est en pleine expansion, de nombreuses sociétés se développent à travers le monde, les techniques existantes évoluent et de nouvelles innovations apparaissent continuellement. Les évolutions portent principalement sur les softwares internes des robots et plus particulièrement sur les algorithmes de navigation où de nouvelles techniques sont continuellement proposées. Cependant, cet afflux de nouvelles évolutions pose un nouveau problème : la nécessité de pouvoir tester rapidement et facilement les nouvelles améliorations possibles afin d évaluer leurs impacts sur les performances de ces robots. A l heure actuelle, lorsqu une équipe de recherche et développement désire tester une nouvelle solution, deux options se présentent à elle : Soit tenter de démontrer mathématiquement son impact sur les performances de la machine, ce qui est souvent compliqué voire parfois impossible. Soit concevoir un prototype et le faire tourner sur un terrain de test pendant plusieurs jours avant d obtenir des résultats permettant d évaluer l amélioration. Toutes ces solutions sont complexes, chronophages et coûteuses. La solution à l aboutissement d un tel projet est d implémenter un logiciel de simulation d un robot mobile autonome dans son environnement de travail. Un tel logiciel permettrait de faciliter le développement et la validation des futures améliorations. Le v

12 défi est de concevoir un tel simulateur de manière optimale en tenant compte du temps et des investissements nécessaires à la finalisation d un tel projet. Entre précision et efficacité, les choix d implémentation sont cruciaux. La modularité du logiciel peut aussi être considérée comme un challenge, mêlant génie logiciel et intégration des composantes embarquées dans les robots. La création d un logiciel permettant d évaluer rigoureusement les impacts d éventuelles améliorations soulève un second problème : Quels sont les critères permettant d évaluer les performances des algorithmes de navigation? A l heure actuelle, il n existe aucun critère et des réunions entre les différents constructeurs ont lieu à travers le monde, mais celles-ci n ont pas encore permis de déterminer les critères objectifs permettant d évaluer la bonne exécution du travail sur le terrain. Il est donc nécessaire de définir ces critères, afin d évaluer de manière objective les performances des robots dans leur environnement. Enfin, un troisième problème consiste en la création d un prototype d algorithme de navigation des robots utilisant la technologie de positionnement GPS. Les possibilités offertes par la technologie GPS sont immenses, et son utilisation dans la navigation des robots tondeuses pourrait grandement améliorer leurs performances. Il nous a donc été demandé de concevoir et de tester à l aide du logiciel développé dans le cadre du projet, un algorithme de navigation utilisant le positionnement GPS afin d améliorer les performances de la machine Ces problèmes ont été présentés à l UCL par la société belge BelRobotics. Une PME implantée à Wavre qui développe et distribue des robots tondeuses autonomes pour grandes superficies ainsi que des robots ramasseurs de balles de golf. Dans le cadre d un nouveau projet lancé en 2012, nommé Projet golf, il est envisagé de développer un simulateur destiné à concevoir et à tester les nouveaux concepts de façon théorique sans devoir attendre le développement et la production de prototype. L initiative d un nouveau logiciel découle de l initiative de notre maître de stage et co-promoteur, Steve Tumson, ingénieur électromécanicien chez BelRobotics dans le département recherche et développement. Ne possédant pas les ressources nécessaires au développement, à la réalisation et à la mise en exploitation du logiciel, Monsieur Tumson décide de faire appel à des étudiants universitaires. Il propose donc à notre promoteur, Charles Pecheur, de réaliser le travail sous la forme d un mémoire couplé à un stage en entreprise. Conscients qu ils n ont que très peu d outils à leur disposition pour vérifier l efficacité de leurs améliorations, la nécessité d un simulateur au sein de l équipe de recherche et développement s est fait sentir et est devenu au gré des besoins la motivation principale de BelRobotics. Une variante marketing du simulateur pourrait apporter également de la valeur ajoutée au sein de la société. En effet, bon nombre de clients n arrivent pas à concevoir qu une tondeuse dirigée par un comportement aléatoire mais contrôlé puisse tondre parfaitement leur terrain. Grâce à une représentation graphique de l environnement dans lequel le robot évolue, le client pourrait parfaitement constater les performances de ce genre d innovation. Pour terminer, une utilisation du logiciel durant des formations proposées aux revendeurs et installateurs agréés permettrait d illustrer efficacement les pièges à éviter lors d implantation et réalisation de nouvelles installations.. D un point de vue plus personnel, nous avons choisi ce sujet de mémoire, car

13 nous voulions travailler sur un projet concret, utile et permettant de faire évoluer la technique dans un domaine qui à ce jour reste encore confidentiel. L idée de concevoir un projet en partant d une page blanche, de concevoir l entièreté de l élaboration et l implémentation du logiciel, et la liberté d action qui nous était offerte dans le développement d une solution nous ont directement attirés. Nous avons donc entièrement développé un logiciel en Java, que nous avons nommé Java Robot Simulateur plus communément appelé JRS. JRS est un outil puissant et modulaire, permettant de tester rapidement et efficacement les nouvelles améliorations apportées à l élaboration des nouveaux robots tondeuses et d évaluer leurs impacts sur les performances des nouvelles machines. Nous avons également créé des critères objectifs permettant de définir les performances des robots dans leurs environnements. Ces derniers ont été définis sur base de l expérience des ingénieurs sur le bon fonctionnement des robots, mais également en tenant compte des possibilités offertes par le logiciel que nous avons développé. Ce rapport détaille l ensemble des solutions apportées à la problématique et est structuré comme suit : La première partie décrit le contexte du mémoire ainsi que la méthodologie utilisée. Elle aborde également les problématiques soulevées ainsi que les travaux déjà réalisés à ce sujet. La seconde partie décrit une série de solutions apportées à la problématique ainsi que la validation du modèle par rapport aux données recueillies sur le terrain. La troisième partie, le corps du projet, présente l analyse organisationnelle et fonctionnelle du logiciel. La quatrième partie consiste en un rappel des objectifs, des propositions de développement futur du projet et une conclusion au sujet du travail accompli en collaboration avec BelRobotics. La cinquième partie est quant à elle réservée aux annexes.

14

15 Première partie Préliminaires 1

16

17 Chapitre 1 Prérequis Dans ce chapitre, un synopsis des produits de la société BelRobotics sera abordé. Ceci permettra de prendre un premier contact avec le monde des robots tondeuses et donc de mieux appréhender certaines fonctionnalités du simulateur, ainsi que les différents algorithmes de navigation. 1.1 Produits BelRobotics vend actuellement quatre produits que nous pouvons séparer en trois catégories (Figure 1.1) : Robots tondeuses de grandes surfaces (Bigmow, Parcmow) : ce sont les robots tondeuses pour grandes surfaces, les plus performantes au monde. La Bigmow, peut tondre jusqu à m 2. La Parcmow est sa petite soeur et entretient des terrains jusqu à m 2. Robots tondeuses de moyennes surfaces (Greenmow) : cette tondeuse est destinée aux jardins de particuliers, allant jusqu à m 2. Robots ramasseurs de balles de golf (Ballpicker) : c est la solution de ramassage automatique et économique de balles de golf sur les practices. Le Ballpicker ramasse silencieusement les balles de golf, jusqu à ce que son bac soit rempli. Il les ramène alors à la station. Les balles sont ensuite lavées et transportées à la zone de stockage. Le Ballpicker est capable de ramasser jusqu à balles par jour. 1.2 Principe de fonctionnement Pour l utilisateur, le fonctionnement des robots BelRobotics est extrêmement simple : 3

18 1. Prérequis 1.2. Principe de fonctionnement Dans une première phase, un spécialiste de la société vient analyser la typologie du terrain afin de déterminer quel type de robot devra être utilisé, l emplacement de la station de recharge et le parcours du câble périphérique. Dans une deuxième phase, l installateur enterre, dans une fine saignée, le câble en ceinturant le terrain à entretenir. Lors de l exploitation, le champ magnétique émis par le câble empêche le robot de sortir de la surface à traiter. Une troisième et dernière phase consiste à configurer le robot au terrain. A ce stade, l installation est terminée et le robot peut travailler de manière autonome. Il va effectuer des déplacements aléatoires à l intérieur de sa zone de travail, délimitée par le câble périphérique. Quand il doit recharger ses batteries, le robot retourne automatiquement à sa station de recharge. Figure 1.1: Greenmow, Parcmow, Bigmow. 4.

19 Chapitre 2 Etat de l art Dans ce chapitre, nous listerons les travaux déjà réalisés et se rapportant à notre travail. Nous analyserons les solutions existantes et discuterons des points forts et des points faibles de certaines d entre elles. Ces analyses auront pour but de mettre en perspective notre travail, le logiciel JSR que nous avons créé et les solutions existantes. 2.1 Planificateur de jardin Viking Le planificateur de jardin Viking est un outil pour aider à concevoir les jardins, il donne une idée de ce qui peut être réalisé 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 possède un éditeur d environnement très avancé possédant de nombreuses fonctionnalités 5

20 2. Etat de l art 2.2. Simulateur issu du projet ArduMower intéressantes telles que : la possibilité d ajouter différents types d obstacles ainsi que de dessiner, comme dans notre propre simulateur, la surface de la pelouse et d en déplacer les extrémités. Un autre point fort est que l éditeur possède un système permettant de tracer automatiquement le parcours du fil périphérique, ce qui, visuellement, est un indéniable atout. Points faibles : Le gros point faible de ce logiciel est le manque complet de simulation. En effet, quand on presse le bouton Go, censé lancer la simulation, le robot se déplace jusqu au bord du terrain et termine ainsi sa simulation en affichant le temps nécessaire à la tonte purement théorique calculé en fonction de la surface du terrain. Il n y a aucune simulation réelle de déplacement du robot dans son environnement de travail. L éditeur de ce logiciel fut une source d inspiration pour quelques fonctionnalités de l éditeur de JRS. En effet, lors du traçage des pourtours du terrain, les distances et les angles sont affichés en temps réel sur le dessin, ce qui s avère extrêmement pratique. Nous avons donc décidé d intégrer ces outils dans notre logiciel. Par contre, nous n avons pas ajouté le système permettant de tracer automatiquement le parcours du fil périphérique à JRS, les bords du terrain étant considérés comme le fil périphérique. 2.2 Simulateur issu du projet ArduMower Le projet ArduMower consiste à réaliser un robot tondeuse, de la conception du logiciel à la réalisation du hardware. C est dans le cadre de ce projet qu un simulateur, permettant de tester les différents algorithmes de navigation à été créé. Figure 2.2: Simulateur issu du projet ArduMower. 6. Points forts : Le point fort de ce logiciel est qu il possède un simulateur avancé. L aspect visuel permet de suivre l évolution du robot dans l environnement de travail. Un autre point fort est que le robot effectue

21 2. Etat de l art 2.3. Projet étudiant de l université de Bourgogne un mapping de son environnement afin d utiliser cette information dans ses algorithmes de navigation. L autre gros point fort de ce logiciel est qu il possède des algorithmes de tonte inédits, comme une navigation en bandes parallèles ou encore une navigation avec déplacements bidirectionnels (le robot n effectue pas de rotation). Points faibles : Un gros point faible du logiciel est qu il ne possède pas d éditeur et ne permet que le chargement d images d environnements figées. De plus, il n y a pas de système permettant de récupérer des statistiques. Un autre point faible non négligeable est qu il n y a pas de gestion du temps permettant d accélérer la navigation, ce qui oblige de regarder le robot se déplacer lentement avant de pouvoir regarder ses résultats. Pour terminer, les robots ne sont pas paramétrables et il n est pas possible d exécuter plusieurs simulations simultanément. Ce simulateur est celui qui se rapproche le plus de notre logiciel du point de vue de la simulation. En effet, le robot évolue dans son environnement de travail et il est possible de suivre cette évolution graphiquement. De plus, le robot effectue un mapping de son environnement, comme dans l algorithme de navigation GPS que nous avons développé. La caractéristique réellement intéressante de ce logiciel est que le robot possède des algorithmes de tonte inédits. L observation du robot exécutant les différents algorithmes proposés par le simulateur nous a permis d éliminer des algorithmes que nous avions envisagés de développer au départ. Par exemple, la tonte en bandes parallèles s est avérée clairement inefficace dans le simulateur ArduMower et nous avons donc abandonné le projet de l implémenter dans notre logiciel. Mais, malgré des fonctionnalités très intéressantes, ce simulateur ne représente pas une alternative possible à JRS. Il n y a ni module de statistiques, ni éditeur, ni accélération du temps possible. 2.3 Projet étudiant de l université de Bourgogne Ce simulateur est né d un projet étudiant de l université de Bourgogne. L origine du projet consiste en l analyse d algorithmes de navigation et création d un simulateur de robot-aspirateur chargé de nettoyer un local encombré de divers obstacles. Points forts : Les points forts de ce simulateur sont les nombreuses fonctionnalités intéressantes qu il possède. Il permet tout d abord de charger un environnement sous forme de fichier texte et de choisir l algorithme de navigation utilisé pour la simulation. On peut ensuite lancer la simulation et suivre l évolution du robot dans son environnement. A la fin de la simulation, diverses statistiques sont affichées sous forme de tableaux. Points faibles : Le plus gros point faible de ce simulateur réside dans ses fonctionnalités basiques et relativement peu évoluées. Ce simulateur n est clairement pas destiné à un usage générique. 7.

22 2. Etat de l art 2.4. Simulateur de robots tondeuses par Alexander Grau Figure 2.3: Simulateur de robot aspirateur. Contrairement à JSR, ce simulateur ne possède ni éditeur d environnement, ni éditeur de robot. Il possède, par contre, des fonctionnalités similaires à notre logiciel comme la simulation en temps réel et la production de statistiques, mais celles-ci sont peu évoluées. Par contre, les algorithmes de navigation développés sont intéressants et peuvent être une source d inspiration pour le développement 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 à gazon robotique sur une pelouse avec une pente constante. Figure 2.4: Simulateur d Alexander Grau. 8.

23 2. Etat de l art 2.5. Les pseudo-simulateurs Points forts : Le point fort de ce logiciel est qu il permet de simuler un déplacement de robot tondeuse sur une pelouse en pente (allant du haut vers le bas de la pelouse). La pente ayant une influence sur la trajectoire du robot. Points faibles : Le point faible de ce simulateur est qu il ne possède aucune fonctionnalité, hormis celle identifiée comme point fort. En effet, le simulateur est très basique et permet seulement de choisir la position de départ du robot ainsi que sa taille. L intérêt de ce logiciel réside, bien évidemment, dans le fait qu il simule le déplacement d un robot sur une pelouse avec pente. Cela permet d observer que la tondeuse (comme toutes les autres tondeuses) a tendance à se déplacer dans la partie inférieure de la pelouse. La conséquence est que, même après plusieurs heures, la partie supérieure de la pelouse n est pas tondue correctement. Cette fonctionnalité très intéressante n a pas été implémentée dans JRS pour la raison suivante : un simple plan incliné n est pas représentatif de tous les cas possibles de terrains auxquels sont confrontés les robots BelRobotics. Il aurait donc fallu développer un système permettant de définir un ensemble de courbes de niveau dans un environnement, et par conséquent un ensemble de pentes. Cependant, étant donné la complexité du système, celui-ci fut abandonné. 2.5 Les pseudo-simulateurs Durant nos recherches, nous avons également trouvé des logiciels se présentant sous le descriptif de Simulateur de robots tondeuses, mais qui étaient, en réalité, bien éloignés d un simulateur de robot tondeuse dans son environnement de travail. Ceux-ci nous ont néanmoins permis de voir ce qui existait au niveau des interfaces graphiques et des simulateurs de tonte. Nous les avons listés ci-dessous : Robot Vacuum Simulator 2013 Robot Aspirateur Simulator 2013 est un simulateur 3D qui vous met dans la peau d un robot aspirateur et vous permet de vous déplacer dans votre appartement afin de le nettoyer. Ce simulateur a la particularité intéressante d utiliser un moteur graphique et physique 3D. Il n y a cependant aucune simulation de navigation automatique, aucun éditeur, ni aucune génération de statistiques. Un logiciel 3D est donc un plus, mais celui-ci n est pas un simulateur de robot autonome. 9.

24 2. Etat de l art 2.5. Les pseudo-simulateurs Figure 2.5: Robot Vacuum Simulator Lawn Mower Simulator York College of Pennsylvania Simple simulateur de tonte, implémenté par les étudiants et leur professeur dans le cadre d un exercice du cours de sciences de l informatique du York College of Pennsylvania. Celui-ci ne possède aucune fonctionnalité avancée et simule uniquement une grille sur laquelle se déplace le robot. Il est intéressant dans la mesure où il ressemble à notre logiciel, dans son tout premier modèle, et a uniquement pour but le développement d algorithmes de navigation basiques. Figure 2.6: Lawn Mower Simulator York College of Pennsylvania Jeu Lawn Mower 1988 Lawn Mower est un simulateur de tonte réalisé en ASCII. Il a la particularité d avoir été publié par Christopher D. Orr, en 1988, pour MS-DOS. C est donc le plus vieux simulateur de tondeuses que nous avons trouvé. Cependant, celui-ci n est pas un simulateur de robots tondeuses, puisqu il n y a aucune navigation automatique. Son intérêt est qu il nous a permis de voir comment représenter, de manière simpliste, un environnement de simulations pour les robots tondeuses. 10.

25 2. Etat de l art 2.6. Conclusion des recherches Figure 2.7: Jeu Lawn Mower Conclusion des recherches Les recherches concernant les différents simulateurs de robots tondeuses dans leur environnement de travail nous ont permis de dresser un inventaire des erreurs à éviter, mais également d intégrer dans notre projet des fonctionnalités et des caractéristiques intéressantes. Dans le tableau 2.1, nous avons repris les caractéristiques intéressantes de chaque logiciel, et si elles ont été implémentées dans notre logiciel. On remarque que toutes les caractéristiques intéressantes des différents logiciels ont été implémentées dans JRS, à l exception de la dernière. Les caractéristiques provenant d autres logiciels ont été, pour la plupart, améliorées et ce, afin d exploiter le maximum de leur potentialité. Une fois notre logiciel implémenté, la comparaison de celui-ci avec les différents simulateurs de robots tondeuses, montre clairement qu il n existe pas de simulateur équivalent au nôtre connu à ce jour. De façon générale, aucun de ces simulateurs ne peuvent être utiliser dans une optique de recherche et développement car ils sont bien trop basiques, contrairement à JRS qui est un outil puissant, complet et disposant de très nombreuses fonctionnalités. Simulateur Caractéristiques intéressantes Dans JRS Planificateur de jardin Viking Simulateur ArduMower Projet étudiant de l université de Bourgogne Simulateur par Alexander Grau Editeur d environnement avancé Simulation temps réel, Mapping de l environnement, algorithme de navigation gps Module statistique (basique), simulation temps réel Gestion des terrains en pente (basique) OUI OUI OUI NON Table 2.1: Tableau de comparaison. 11.

26 2. Etat de l art 2.6. Conclusion des recherches 12.

27 Chapitre 3 Méthode de travail Ce chapitre a pour but de détailler la méthodologie que nous avons utilisée pour mener à bien ce mémoire. Afin de réaliser au mieux notre travail, nous avons commencé par organiser un ensemble de réunions avec Mr Tumson pour mettre au point notre méthodologie ainsi que les objectifs à atteindre. Nous avons dû trouver une méthodologie qui soit applicable tout au long du développement de notre mémoire et qui soit surtout compatible avec notre stage. En effet, celui-ci se déroulant au second semestre, il se situe dans la continuité de notre mémoire. 3.1 Méthodologie Scrum Fort de son expérience, Mr Tumson nous a proposé d utiliser la méthodologie de développement Scrum qui fait partie de la classe des méthodologies de type agile (Figure 3.1). L idée de base est de focaliser l équipe sur une partie limitée et maîtrisable des fonctionnalités à réaliser. Cette méthodologie est également définie comme incrémentale, car l ensemble du projet est découpé en périodes, nommées sprint, durant lesquelles on améliore le produit. La durée d un sprint peut varier de quelques jours à un mois, mais celle-ci est déterminée définitivement au début du projet. Nous avons choisi des sprints d une durée de deux semaines. Chaque sprint est composé d un certain nombre d ajouts à réaliser au bout duquel un délivrable du produit est présenté au client pour que celui-ci puisse valider ou invalider ces ajouts. C est ainsi que la première phase de cette méthodologie consiste à découper le projet en un ensemble d ajouts/fonctionnalités appelé story, le tout se trouvant dans un document intitulé backlog. Chaque story identifie une fonction spécifique du produit fini. Chaque story se voit également attribuer un nombre de points représentant un niveau de complexité et un temps nécessaire à sa réalisation. Ceci permettra durant le développement du projet de définir la charge de travail nécessaire à la réalisation de celui-ci. Il est important de noter que l énumération des différentes stories n est pas définitive, c est là un avantage considérable de cette méthodologie. En effet, à tout moment, durant le développement, il est possible d ajouter, de splitter ou de modifier une story qui n est pas encore achevée. 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 caractéristique de la méthodologie Scrum en fait un outil efficace pour suivre continuellement les besoins du client (dans notre cas : BelRobotics) et permet de recadrer rapidement les choix d implémentation ou tout simplement d ajouter une fonctionnalité qui n était pas prévue au départ. 13

28 3. Méthode de travail 3.2. Étapes d un sprint Figure 3.1: Illustration de la méthodolgie Scrum. 3.2 Étapes d un sprint Abordons dès à présent l évolution chronologique d un sprint : chaque sprint est divisé en 5 étapes. Ces étapes sont répétées, sans exception, lors de chaque sprint, jusqu à la fin du projet La première étape est l estimation, elle consiste à évaluer la charge de travail que pourra supporter l équipe en fonction des ressources dont elle dispose pour ce sprint. Cette estimation se base sur les points définis précédemment pour chaque story. C est ainsi que, pour une période de deux semaines, avec deux étudiants disponibles à trois quart temps, nous sommes arrivés à un nombre de points compris entre 20 et 25. Cette estimation peut varier au cours des sprints. 2. La deuxième étape consiste à planifier le sprint et les différentes stories que l équipe va réaliser en fonction du nombre de points évalués à l étape précédente. Tout comme la première, cette étape sera réalisée avec le client (Mr Tumson dans notre cas), ce qui va lui permettre de suivre l état d avancement du projet, mais également de redéfinir les objectifs en fonction de l importance des points à réaliser. Durant cette étape, il est important d écouter tous les intervenants, autant le point de vue technique de l équipe de développement, que les exigences du client, car c est cette combinaison qui permettra de tendre vers de meilleurs résultats. 3. Vient ensuite l étape de la réalisation des stories. Chaque matin, les membres de l équipe de développement se rassemblent brièvement pour établir les objectifs de la journée. 4. Lorsque l équipe de développement est arrivée à la fin du temps imparti pour ce sprint, elle passe à l étape de démonstration. C est ainsi, qu en présence du client, l équipe de développement va organiser une réunion de démonstration pour présenter toutes les fonctionnalités implémentées.

29 3. Méthode de travail 3.2. Étapes d un sprint Chaque story sera ensuite évaluée individuellement pour déterminer si elle a bien été achevée ou s il est nécessaire d y apporter certaines améliorations. 5. La dernière étape consiste en une rétrospective du sprint qui vient d être effectué, afin d identifier ce qui n a pas bien fonctionné, et ainsi de s améliorer pour le prochain sprint. Comme vous pouvez l imaginer, cette méthodologie est très flexible et ouverte, elle permet de redéfinir rapidement les priorités. C est en grande partie pour cette raison que notre cahier des charges n a pas été suivi scrupuleusement, et qu un grand nombre de fonctionnalités développées dans le logiciel final ne s y trouvaient pas au départ. Notre backlog final (qui équivaut à notre cahier des charges) est disponible en annexe. Il contient également la répartition des stories dans les sprints, donnant une vue complète du déroulement chronologique de notre projet. 15.

30 3. Méthode de travail 3.2. Étapes d un sprint 16.

31 Chapitre 4 Énoncé du problème Le but de ce mémoire 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-ci et énoncer les problématiques que ceux-ci soulèvent. Mais, comme nous l avons précisé dans le chapitre précédent, nous avons utilisé la méthodologie Scrum. Cela explique que les objectifs ont évolué tout au long du développement. Nous allons donc partir de la dernière version de notre backlog, pour parcourir l ensemble des objectifs que nous avons sélectionnés tout au long de ce projet. 4.1 Objectifs architecturaux De la modularité La modularité du produit final est l un des points le plus important, car c est celle-ci qui va permettre aux ingénieurs de BelRobotics de continuer à développer des fonctionnalités au sein du simulateur, et ceci sans devoir réécrire l ensemble du programme. L idée est de pouvoir, par exemple et le plus simplement possible, ajouter un composant au robot, un nouveau comportement à sa navigation ou encore un filtre visuel pour l affichage en temps réel de l environnement. Deux parties distinctes Il est important de séparer le logiciel en deux parties distinctes pour conserver leur indépendance. Ainsi, la partie qui concerne l éditeur d environnement ne doit pas avoir d objet commun avec la partie qui s occupe de la simulation. Un convertisseur doit donc permettre le passage de l une à l autre. Cela permettra d apporter des modifications à l une des parties sans devoir adapter la seconde, ou encore de executer une partie sans avoir à se soucier du bon fonctionnement de l autre. 17

32 4. Énoncé du problème 4.2. Objectifs fonctionnels Une indépendance graphique Pour faciliter le développement par les ingénieurs de BelRobotics, il est préférable que toute la partie graphique soit gérée automatiquement par le programme. En effet, un ingénieur électromécanicien désirant ajouter sa fonctionnalité dans le simulateur n a certainement pas envie de devoir ajouter toutes les composantes graphiques que celle-ci va utiliser. 4.2 Objectifs fonctionnels Un environnement personnalisable Une des fonctionnalités principales du programme doit être son éditeur d environnement. Il doit être à la fois complet et simple d utilisation. Pour ce faire, l utilisateur disposera d un ensemble d outils, de dessins, et de placement d objets (arbre, station, etc). Ces environnements pourront être sauvegardés et chargés à tout moment. Un robot paramétrable Une partie du programme devra être réservée à la personnalisation du robot et à sa navigation. Cette personnalisation sera développée afin d éviter toute intervention de l utilisateur dans le code du logiciel. À travers une interface simple, l utilisateur aura la possibilité de personnaliser un maximum son robot afin de tester différentes configurations pour un environnement donné. Tout comme l environnement, l utilisateur pourra sauvegarder et réutiliser à tout moment l une de ces configurations. Un gestionnaire de simulation La deuxième partie importante du programme consistera à l exécution d une simulation. Le programme montrera graphiquement l évolution du robot dans son environnement de travail, avec la possibilité de modifier sa vitesse de simulation. Un ensemble de statistiques sera également affiché et mis à jour en temps réel par le simulateur. Des statistiques sauvegardables À la fin d une simulation, toutes les données statistiques devront être sauvegardées dans un fichier externe sous forme de tableau. Cela permettra par la suite d effectuer des analyses comparatives des différentes simulations réalisées. 18.

33 4. Énoncé du problème 4.2. Objectifs fonctionnels Des méthodes d évaluation A l heure actuelle, il n existe aucun critère permettant d évaluer les performances des algorithmes de navigation. A ce jour, des réunions entre les différents constructeurs ont lieu à travers le monde, mais celles-ci n ont pas encore permis de déterminer les critères objectifs permettant d évaluer la bonne exécution du travail sur le terrain. L équipe de recherche et développement de BelRobotics aimerait donc définir ces critères, afin d évaluer de manière objective leurs différents algorithmes de navigation. Il nous faut donc définir des critères objectifs permettant de définir les performances des robots dans leur environnement. Des filtres utiles Afin de faciliter la compréhension visuelle de l environnement dans lequel le robot travaille, un ensemble de filtres pourra être appliqué sur celui-ci. Cela permettra, par exemple, d identifier les zones dans lesquelles le robot n est pas encore passé, ou encore celles sur lesquelles le robot est resté bloqué durant une longue période. La multi-simulations L utilisateur aura la possibilité de lancer, de manière automatique, une grande quantité de simulations avec des paramètres variables, et cela dans le but de déterminer l efficacité de ces variations. Toutes les simulations disposeront d un même environnement de départ, seuls leurs paramètres varieront. Étant donné que plusieurs simulations seront lancées en même temps, seul leur état d avancement sera affiché à l écran. Les environnements ainsi que les statistiques de chaque simulation ne seront pas visibles durant l exécution. Cela permettra d économiser de la puissance de calcul, le logiciel pouvant ainsi exécuter plusieurs simulations sur des ordinateurs de puissance moyenne. Une interface graphique soignée Des composantes graphiques soignées permettront une utilisation plus confortable du logiciel. En effet, celui-ci ne servira pas uniquement à des ingénieurs pour tester leurs améliorations, il sera également utilisé par le département marketing pour présenter une solution à leurs clients. Il est donc important de soigner l aspect visuel du logiciel. 19.

34 4. Énoncé du problème 4.2. Objectifs fonctionnels 20.

35 Deuxième partie Solution 21

36

37 Chapitre 5 Description du logiciel Dans ce chapitre, nous allons présenter du point de vue de l utilisateur, les fonctionnalités que nous avons développées au sein de JRS. L architecture interne du logiciel sera quant à elle, détaillée dans les chapitres suivants. Pour commencer, il est important de bien différencier les deux grandes parties de JRS : l éditeur et le simulateur. La première partie va permettre à l utilisateur de créer son terrain et de configurer son robot, alors que la deuxième partie va permettre de simuler le comportement du robot, en fonction de ce terrain et des paramètres du robot. 5.1 Éditeur L éditeur d environnement est la première étape pour réaliser une simulation. Commençons par voir les différents boutons présents dans son interface graphique. Barre d option La barre d option se situe en haut de la fenêtre et est constituée de 10 boutons (Figure 5.1). Les quatre premiers permettent de créer un nouvel environnement, en charger un, ou sauvegarder celui en cours. Les deux suivant vont permettre d éditer les paramètres du robot, ainsi que ces statistiques. Viens ensuite un bouton pour lancer une simulation unique suivi d un second pour lancer une multi-simulations. Et pour terminer, nous avons un bouton permettant d afficher quelques informations sur JRS et un second pour quitter le programme. Figure 5.1: Barre d option de l éditeur. La première étape va donc consister à créer un environnement. L utilisateur va alors entrer les paramètres de bases de ce dernier (Figure 5.2) : nom, fichier destinataire, dimension, taille des parcelles. 23

38 5. Description du logiciel 5.1. Éditeur Figure 5.2: Fenêtre de création d environnement. Lorsque que l environnement est créé, l utilisateur va pouvoir le personnaliser. Pour cela, il va disposer d un ensemble d outil à sa gauche, d une représentation de son environnement au centre et d une liste à droite regroupant tous les éléments qui le constituent (Figure 5.3). Figure 5.3: Fenêtre de l éditeur. 24.

39 5. Description du logiciel 5.1. Éditeur Outils de base L utilisateur dispose de 2 outils de base (Figure 5.4) : 1. Un outil de sélection : Cet outil permet de sélectionner un objet dans l environnement pour le déplacer, le modifier ou le supprimer. 2. Un outil latte : Cet outil permet de prendre des mesures et vérifier la conformité de son terrain. Figure 5.4: Outils de base. Outils de dessin L utilisateur dispose également de 3 outils de dessin. Ces outils vont lui permettre de dessiner les trois types de zones existantes dans JRS (Figure 5.5) : 1. Les zones d herbe : Ces zones permettent de délimiter le terrain à entretenir. Lorsqu une zone d herbe est ajoutée à l environnement, ses pourtours émettent un champ magnétique, ce qui simule le câble périphérique. Ce dernier pourra ensuite être détecté par la bobine magnétique du robot. 2. Les zones obstacle : Ces zones permettent d identifier les obstacles physiques du terrain : une maison, un banc, une cabane de jardin. Elles n émettent pas de champ magnétique mais seront détectées par le sonar du robot. 3. Les zones îlot ou externe : Ces zones sont l inverse des zones d herbe. Tout comme ces dernières, elles émettent également un champ magnétique. Placer une zone externe au milieu d une zone d herbe revient donc à tirer le câble périphérique pour former un îlot au milieu du terrain. Elles sont par exemple utilisées pour délimiter un étang qui n est pas détectable avec le sonar du robot. Figure 5.5: Outils de dessin. Lors de la création et de la modification de ces zones, plusieurs informations utiles sont également affichées (Figure 5.6) : la surface totale de la zone, la distance entre les points sélectionnés et l angle en cours de traçage. Pour faciliter d avantage le traçage des différentes zones, l utilisateur peut également utiliser notre intégration Google Map. Celle-ci est disponible en bas à droit de la fenêtre et va afficher 25.

40 5. Description du logiciel 5.1. Éditeur Figure 5.6: Information d aide au traçage. une image satellite du terrain de l utilisateur (Figure 5.7). Celui-ci doit au préalable avoir introduit la position GPS de son terrain et le niveau de précision qu il désire. Pour permettre cette intégration nous n avons pas souscrit d abonnement professionnel chez Google. C est d ailleurs pour cette raison que la taille de l image est limitée et diminue en fonction de la précision que l on a choisie. Figure 5.7: Exemple d intégration Google Map. Outils de placement 26. 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 arbre sur l environnement. Il sera considéré comme une zone obstacle et sera détecté par le robot à l aide de son sonar. 2. Outil de placement de station : Cet outil permet de placer une station dans l environnement. Il va automatiquement placer la station sur le câble périphérique pour faciliter son installation et éviter toutes

41 5. Description du logiciel 5.1. Éditeur erreurs venant de l utilisateur. Il n y a pas de limite sur le nombre de stations. Figure 5.8: Outils de placement. Personnalisation de l environnement Lorsque l utilisateur a fini de dessiner et placer ses éléments sur l environnement, il peut les personnaliser dans la liste de droite. Il est ainsi possible d indiquer la vitesse de pousse des zones 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 éléments de l environnement. Sauvegarde et chargement d environnement Lorsque l utilisateur a entièrement fini de personnaliser son environnement, il peut le sauvegarder dans un fichier externe à l aide des boutons de la barre d option. Celui-ci pourra ainsi être rechargé plus tard même après avoir redémarré le programme. Personnalisation du robot Après avoir construit son environnement, l utilisateur peut personnaliser les paramètres de son robot et de sa navigation. Cette personnalisation va permettre de trouver la configuration idéale pour un terrain donné. La fenêtre de personnalisation du robot est composée de deux parties (Figure 5.10) : 1. Sur la droite, une liste affiche l entièreté des paramètres que l utilisateur peut faire varier. Un mécanisme de vérification indiquera toutes mauvaises valeurs. 27.

42 5. Description du logiciel 5.1. Éditeur 2. Sur la gauche, une représentation visuelle du robot est disponible. Cette représentation comprend également l affichage de certains paramètres, comme ceux indiquant une position (emplacement du sonar, des boudins de pression, etc). Nous verrons plus tard qu il est extrêmement simple d ajouter de nouveaux paramètres au robot. Cette fonctionnalité plus technique sera détaillée dans le chapitre suivant, concernant l architecture de notre solution. Figure 5.10: Fenêtre de personnalisation du robot. Tout comme l environnement, les configurations de robot peuvent être sauvegardées dans un fichier externe pour être rechargées par la suite. Les boutons de sauvegarde et chargement sont situés en haut à droite de la fenêtre. Configuration des statistiques Avant de passer à l étape de simulation, il est possible de configurer le mécanisme de sauvegarde des statistiques. En effet, à la fin d une simulation, l entièreté des statistiques peuvent être sauvegardées dans un fichier CSV. Ce fichier pourra par la suite être analysé par un programme statistique plus puissant. A l aide de la fenêtre statistique, l utilisateur va pouvoir déterminer les statistiques qu il désire sauvegarder (Figure 5.11). Trois types de valeurs sont possibles : 28.

43 5. Description du logiciel 5.1. Éditeur 1. La valeur -1 : Indique au simulateur de ne pas sauvegarder la statistique. 2. La valeur 0 : Indique au simulateur de sauvegarder uniquement la dernière valeur de la statistique, lorsque la simulation sera terminée. 3. Une valeur X : Indique au simulateur de sauvegarder la valeur de la statistique toutes les X minutes. Figure 5.11: Fenêtre 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 évolution du robot dans son environnement en temps réel. 29.

44 5. Description du logiciel 5.1. Éditeur 2. Dans le second cas, le simulateur lance un ensemble de simulations. L utilisateur a au préalable déterminé les paramètres robot qu il désire faire varier. Ceci a pour objectif de déterminer une configuration optimale. Les multi-simulations ne seront par contre, pas affichées en temps réel. Figure 5.12: Comparaison simple simulation (haut) et multi-simulations (bas). En sélectionnant la multi-simulations, le simulateur va demander à l utilisateur d indiquer les paramètres qu il désire faire varier (Figure 5.13). Ce dernier n aura le choix de faire varier que les paramètres numériques du robot. La syntaxe que nous avons imaginée est assez simple : 30. Une variation peut être, soit une valeur simple (exemple : 42 ), soit

45 5. Description du logiciel 5.1. Éditeur un intervalle (exemple : 10 > 20 : 6 ). Un intervalle est composé d une valeur de départ, d une valeur de fin et d un nombre d étapes (exemple : 10 > 20 : 6 va générer 6 simulations différentes, avec les valeurs 10,12,14,16,18 et 20). Plusieurs variations peuvent être combinées avec le séparateur ; (exemple : 10 > 20 : 6 ; 42 ). Figure 5.13: Fenêtre de paramètres robot pour la multi-simulations. L utilisateur peut également déterminer le nombre de répétitions qu il désire réaliser pour chaque variation. En fonction de ce nombre, le simulateur va donc répéter une même simulation, plusieurs fois. Cela a pour objectif de déterminer les valeurs moyennes de chaque statistique, pour une configuration donnée. Cela permet de supprimer l effet aléatoire présent dans la navigation du robot. 31.

46 5. Description du logiciel 5.2. Simple simulation L utilisateur peut aussi indiquer le nombre de threads qu il désire allouer à la multi-simulations. Lorsqu il valide ses choix, il passe à la deuxième étape du logiciel. 5.2 Simple simulation Nous allons commencer par aborder la simple simulation, la multi-simulations sera détaillée dans la section suivante. La simulation est la deuxième étape de notre logiciel. C est ici que nous allons simuler le comportement du robot en fonction de sa navigation et du terrain. Au niveau de l interface graphique elle est fort similaire à l éditeur (Figure 5.14) : En haut de la fenêtre se trouve une barre d option qui permet de redémarrer la simulation ou repasser dans la partie éditeur. Au centre de la fenêtre se trouve l environnement de simulation. On peut remarquer qu il est légèrement différent que celui de l éditeur car il a été converti pour que le simulateur puisse interagir plus facilement avec (nous verrons pourquoi dans l architecture). Sur la droite de la fenêtre se trouve une grande liste composée de trois éléments : le contrôleur de la simulation (en haut), la liste des statistiques (au centre) et le choix des filtres à appliquer sur l environnement (en bas). Figure 5.14: Fenêtre de simple simulation. 32.

47 5. Description du logiciel 5.2. Simple simulation Contrôleur de simulation Le contrôleur permet à l utilisateur de déterminer la durée de la simulation et de modifier sa vitesse d exécution (Figure 5.15). Par défaut, les simulations durent 72 heures et sont lancées en vitesse x1. Il est possible d accélérer les simulations jusque x128 tout en voyant le robot évoluer sur le terrain. Pour aller encore plus vite il est possible de passer en mode instantané. La position du robot ainsi que l environnement ne sont alors plus mis à jour graphiquement. Figure 5.15: Contrôleur de simulation. Statistiques de simulation Durant la simulation un ensemble de statistiques sont affichées en temps réel (Figure 5.16). Ces statistiques sont à la fois liées au robot (vitesse moyenne, distance parcourue, etc) mais également à son environnement (pourcentage visité, uniformité, etc). Ce sont ces statistiques qui seront sauvegardées en fin de simulation. Figure 5.16: Statistiques de simulation. 33.

48 5. Description du logiciel 5.2. Simple simulation Voici la liste des statistiques les plus pertinentes qui sont actuellement implémentées dans le simulateur : 1. Vitesse moyenne. 2. Distance parcourue. 3. Uniformité de la tonte. 4. Pourcentage de zones visitées (1x, 2x, 3x). 5. Surface totale. 6. État de la navigation. 7. Nombre de retours station. 8. Pourcentage du temps passé à travailler/charger/rentrer en station. 9. Nombre total de collisions physiques. 10. Nombre total de détections du câble périphérique. Nous verrons plus tard qu il est extrêmement simple d ajouter de nouvelles statistiques au sein du simulateur. Cette fonctionnalité plus technique sera détaillée dans le chapitre suivant, concernant l architecture de notre solution. Filtres de simulation Nous avons développé un système de filtre pour afficher notre environnement sous différents angles de vue. Ce système permet à tout moment, pendant la simulation, de passer d une vue à une autre. Cela va par exemple permettre d identifier plus facilement les endroits critiques d un terrain, en affichant graphiquement la fréquence de passage du robot sur chaque parcelle. Voici la liste des filtres les plus pertinents qui sont actuellement implémentés dans le simulateur (Figure 5.17) : 1. Filtre de hauteur d herbe : Il dessine la hauteur d herbe de chaque parcelle du terrain. 2. Filtre de fréquence de passage : Il dessine la fréquence de passage du robot sur chaque parcelle du terrain avec une échelle allant de 0 à 3 passages. 3. Filtre de fréquence relative de passage : Il dessine également la fréquence de passage du robot mais utilise cette fois ci, la plus grande et la plus petite valeur comme échelle. 4. Filtre de mapping : Il dessine la carte interne que le robot construit lors de la navigation GPS. 5. Filtre d uniformité : Il dessine l uniformité du terrain (détaillé dans la prochaine section). Nous verrons plus tard qu il est extrêmement simple d ajouter de nouveaux filtres au sein du simulateur. Cette fonctionnalité plus technique sera détaillée dans le chapitre suivant, concernant l architecture de notre solution. 34.

49 5. Description du logiciel 5.2. Simple simulation 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 fonction des préférences définies précédemment. Ces statistiques vont être enregistrées sous la forme d un fichier CSV (Figure 5.18), pouvant être ouvert par la plupart des logiciels statistiques. Une image de chaque filtre en fin de simulation sera également enregistrée dans le dossier des résultats. Figure 5.18: Exemple de fichier CSV affiché avec Microsoft Excel. 35.

50 5. Description du logiciel 5.3. Multi-simulations 5.3 Multi-simulations La multi-simulations est fort similaire à la simple simulation à la différence qu elle en exécute plusieurs simultanément. Commençons par aborder son interface graphique (Figure 5.19) : Au centre de la fenêtre se trouve une liste contenant la progression de chaque simulation. Sur la droite de la fenêtre se trouve également une liste composée de deux éléments : le contrôleur des simulations (en haut) et la liste des statistiques propre à une simulation (au centre). Figure 5.19: Fenêtre de multi-simulations. Contrôleur des simulations Le contrôleur va permettre à l utilisateur d affecter la vitesse de simulation de toutes celles qui sont en cours d exécution. Il permet également de définir la durée totale de chaque simulation (Figure 5.20). 36.

51 5. Description du logiciel 5.3. Multi-simulations Figure 5.20: Contrôleur des simulations. Progression des simulations La liste des simulations contient un récapitulatif ainsi qu un contrôleur pour chacune d elles (Figure 5.21). Dans ce récapitulatif sont affichés la vitesse, la progression et le nom de la simulation. En plus du contrôleur de simulation, un bouton permet d afficher ses statistiques dans la liste de droite et un second permet de stopper définitivement la simulation. Figure 5.21: Contrôleur et récapitulatif d une simulation. Statistiques d une simulation Il est possible d accéder aux statistiques d une simulation. Celles-ci seront alors affichées dans la liste de droite (Figure 5.22). Deux boutons supplémentaires sont disponibles en bas de cette liste : un premier pour afficher à titre informatif, les paramètres du robot utilisés pour cette simulation, et un second pour ouvrir une nouvelle fenêtre et voir le robot évoluer dans son environnement. Cette seconde fenêtre ne peut être affichée que pour une seule simulation à la fois. 37.

52 5. Description du logiciel 5.3. Multi-simulations Figure 5.22: Liste des statistiques d une simulation. Sauvegarde en fin de simulation Lorsque toutes les simulations sont terminées, un fichier CSV global est également généré (en plus de celui propre à chaque simulation). Ce fichier va permettre d avoir une vue d ensemble sur toutes les simulations exécutées. Il va aider l utilisateur à comparer les simulations afin de déterminer laquelle de celles-ci a la configuration robot la plus performante. 38.

53 Chapitre 6 Méthodes d évaluation Comme expliqué dans l introduction, à l heure actuelle, il n existe aucun critère permettant d évaluer les performances d algorithmes de navigation des robots tondeuses. Nous avons donc dû définir des critères objectifs permettant d évaluer les performances des robots dans leur environnement. Pour cela, nous avons organisé plusieurs réunions avec les ingénieurs de chez BelRobotics afin de définir conjointement ces critères. Ces derniers ont été définis sur base de l expérience des ingénieurs en tenant compte du bon fonctionnement des robots, mais également en tenant compte des possibilités offertes par le logiciel que nous avons développé. Nous avons identifié 3 critères : 1. Un premier critère est le pourcentage de passages sur tous les endroits de sa zone de travail, dans un laps de temps déterminé. Cela permet de déterminer si le robot a correctement couvert sa zone de travail. Le critère actuel est le suivant : la zone de travail est considérée comme correctement tondue si le robot est passé au moins une fois sur 98% de sa zone de travail, en moins de trois jours. 2. Un deuxième critère est cependant nécessaire pour pouvoir affirmer que la pelouse est correctement tondue : l uniformité du terrain. En effet, il n est pas acceptable que les 2% du terrain où le robot n est pas passé soient concentrés au même endroit, ce qui représenterait une surface non négligeable d herbe non tondue. Nous avons donc créé un deuxième critère, permettant de calculer l uniformité de la tonte sur le terrain. L uniformité est calculé selon un critère déterminant si la tonte est correcte. Ce critère de bonne tonte peut être calculé selon deux données : la hauteur de la pelouse minimum ou le nombre de passages minimum. 3. Le calcul de l uniformité requiert le calcul d un 3ème critère : le rapport entre le nombre de parcelles de pelouse respectant le critère d une tonte correcte et le nombre de parcelles de pelouse dans le quadrant. On calcule l uniformité totale du terrain de la manière suivante : On divise un rectangle englobant l entièreté de la zone de travail du robot en un nombre de quadrants rectangulaires. Ces quadrants sont eux-mêmes divisés en petits carrés appelés parcelles. Une fois cette division réalisée, on applique le calcul suivant : 39

54 6. Méthodes d évaluation. avec U représente l uniformité en pourcent. Q i représente la valeur du 3 eme critère pour quadrant i. S représente le nombre de quadrants possédant au moins une parcelle de pelouse. i représente l ensemble des quadrants possédant au moins une parcelle de pelouse. Q représente la moyenne des Q i. C i représente le nombre de parcelles de pelouse respectant le critère d une tonte correcte. P i représente le nombre de parcelles de pelouse dans Q i. Avec ce calcul, on obtient une série de statistiques permettant de définir l uniformité de la tonte du terrain. Par ailleurs, on obtient le pourcentage de parcelles tondues pour chaque quadrant, ce qui permet de définir, 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 éventuels morceaux de la zone de travail qui ne sont pas correctement tondus par rapport au reste du terrain. On obtient également l uniformité générale en pourcent, 100% signifiant que la tonte est uniforme sur l ensemble du terrain. Ainsi, si l uniformité tend vers 100%, nous savons qu il n y a pas de grands ensembles de parcelles d herbe non tondus sur le terrain. Les différents critères développés ont permis la quantification d une notion complexe qui, auparavant, nécessitait de visualiser le terrain pour évaluer si le résultat de la tonte était acceptable. Grâce aux trois critères numériques développés, il est possible de comparer plusieurs simulations sur la simple base de leurs statistiques, afin de déterminer laquelle d entre elles donne les meilleurs résultats. Figure 6.1: Comparaison environnement (à gauche) et filtre d uniformité (à droite). 40.

55 Chapitre 7 Validation Pour valider notre solution nous avons effectué une batterie de tests fonctionnels durant son développement. Nous allons dans ce chapitre vous présenter les tests les plus pertinents que nous avons réalisés avec le simulateur. Pour chaque situation, nous décrirons dans un premier temps le comportement attendu qui a été observé dans la réalité, puis dans un second temps, le comportement observé au sein du simulateur. 7.1 Test de comportement Norme d efficacité Les ingénieurs de BelRobotics ont déterminé que pour qu un robot soit considéré comme efficace sur un terrain donné, il doit être passé au moins une fois en trois jours sur 98% du terrain à entretenir. De plus, la valeur d uniformité issue de nos critères de performance doit tendre vers 100% afin d avoir une tonte la plus homogène possible. En sachant que la BigMow est théoriquement capable de tondre 2 hectares, nous avons créé un terrain de cette dimension et nous avons lancé dix simulations de trois jours. Les résultats observés lors de ces simulations sont assez positifs. En effet, le robot tondeuse passe en moyenne une fois au moins sur 99,18% de la parcelle avec un écart type de 0.12, en moyenne deux fois au moins sur 95,56% de celle-ci avec un écart type de 0.87 et en moyenne trois fois ou plus sur 86,93% avec un écart type de De plus, l uniformité atteint 97.16% de moyenne avec un écart type de Cela montre que le travail réalisé a été réparti de façon homogène sur le terrain. Enfin, la vitesse moyenne issue de notre simulation est de 0.85 m/s ce qui est, selon les ingénieurs de BelRobotics, représentatif de la vitesse moyenne de leurs machines. JRS arrive donc bien à simuler les normes en place chez BelRobotics et permet même d affirmer que sur un terrain vide, le robot est légèrement plus performant. 41

56 7. Validation 7.1. Test de comportement Figure 7.1: Parcelles visitées au moins trois fois (vert), deux fois (orange clair), une fois (orange foncé) et zéro fois (rouge). Terrain en H Le problème du terrain en H permet d identifier une erreur de placement de station. En effet, si le technicien chargé de placer la station sur ce genre de configuration ne fait pas attention et ne respecte pas les contraintes de placement, il risque de constater régulièrement des alertes provenant du robot. La raison est la suivante : lorsque le robot suit le câble périphérique, il s attend à recevoir un signal de la station pour ensuite se rapprocher du câble afin d accoster à la station. Si après avoir détecté la station, il ne s est pas accosté après avoir parcouru 27 mètres alors il s arrête et soulève une alerte par mesure de précaution. Pour ce comportement nous avons donc reproduit un terrain en H avec la station à l intersection des deux zones et le robot s est arrêté suite à une erreur lors de chaque retour en station comme on peut le voir sur la Figure ci-dessous. La simulation est donc correcte et représente donc une façon très efficace de présenter les erreurs à ne pas commettre aux installateurs qui suivent leur formation technique. 42.

57 7. Validation 7.1. Test de comportement Figure 7.2: Exemple de terrain en H. Détection d îlots Pour certains obstacles physiques à l intérieur de la zone de travail, il est nécessaire de les entourer à l aide du câble périphérique. Par exemple, un parterre de fleurs ou encore un étang doivent être protégés à l aide du câble, car les autres capteurs du robot ne détecteraient pas ces obstacles. Cet entourage de l obstacle depuis le câble périphérique permet de créer ce que l on appelle un îlot. En effet, le champ magnétique du câble s annulera sur le chemin entre le câble périphérique externe et l îlot réalisé. On peut voir un exemple d îlot avec la piscine sur la Figure 7.3. Figure 7.3: Exemple d îlot cablé, représenté ici par la piscine. 43.

58 7. Validation 7.1. Test de comportement Un problème fréquent se produit lors du retour station lorsque le terrain contient trop d îlots. En effet, le robot possède une procédure qui fait qu au delà d un certain nombre de tours effectués en suivant le fil périphérique, celui-ci décroche du fil et va le raccrocher à un autre endroit. Le robot va donc identifier correctement les îlots et s en décrocher mais au final va passer d un îlot à l autre et ainsi se décharger avant d atteindre sa station. Dans la réalité, un maximum de 5 îlots est autorisé, le robot risquerait donc de tomber en panne régulièrement si l on augmentait ce nombre. Nous avons réalisé une simulation sur un terrain possédant 7 îlots et les résultats montrent effectivement que, sur 5 simulations, le robot est à chaque fois tombé en panne à cause des îlots, et cela en moins de 30 heures. Figure 7.4: Les îlots empêchent le robot d accrocher le bon câble périphérique. Traces dans la pelouse Un des problèmes principaux de BelRobotics sur les terrains de golfs sont les traces qu engendrent les passages répétés du robot en suivant son câble lors du retour station. C est l un des objectifs du projet golf visant l amélioration des robots que de minimiser les traces laissées par les robots. Une solution de robot à pneus larges a été proposée, mais comme on le voit sur la Figure 7.5, cela n est pas concluant. Nous avons décidé de tester un robot sur une période de 3 jours. Comme expliqué par la suite dans le chapitre 12, nous avons développé un prototype d algorithme utilisant un module GPS 44.

59 7. Validation 7.1. Test de comportement Figure 7.5: Photographie des traces laisse es par le robot lors des retours stations. permettant au robot de connaı tre sa position approximative et d effectuer un mapping de son environnement afin de pouvoir rentrer a sa station sans suivre le cable. Pour de montrer l utilite de cet algorithme pour re soudre ce proble me de traces, nous avons compare deux simulations, l une utilisant l algorithme classique, l autre utilisant l algorithme GPS. Nous obtenons comme re sultat inte ressant la Figure 7.6. Celle-ci a e te re alise e avec le filtre Relative Passage Number, les zones les plus vertes repre sentent donc les endroits les plus fre quente s, et les zones rouges les endroits les moins fre quente s. On observe clairement sur la partie gauche une ligne verte faisant le tour du terrain. Cette ligne repre sente le grand nombre de passages re alise s le long de fil pe riphe rique par rapport au reste du terrain, passages qui engendreront des traces dans la pelouse. JSR met donc en e vidence le proble me des traces laisse es par les robots. Figure 7.6: Comparaison des traces laisse es par le robot. Navigation classique (gauche) et navigation GPS (droite). Par contre, on observe sur la partie droite qu aucune ligne verte n est pre sente. Comme explique dans le chapitre sur les algorithmes de navigation, cela montre que notre algorithme 45.

60 7. Validation 7.2. Test d un cas concret de navigation GPS apporte une solution viable concernant le problème des traces dans les terrains de golf. 7.2 Test d un cas concret Pour conclure notre validation, nous nous sommes intéressés à un cas provenant des formations techniques données aux techniciens chargés d installer les robots. Il s agit d une grande surface de pelouse privée dans la région du Brabant Wallon. Les explications données lors de la formation recommandent de placer deux stations et d utiliser une BigMow. La surface totale du terrain est de 1.19 hectare. D après les exigences imposées par BelRobotics, plus de 98% du terrain devrait donc avoir été visité au moins une fois. Figure 7.7: Terrain privé. Simulation Pour commencer, nous avons construit le terrain dans l éditeur d environnement. L intégration de Google Map dans JRS nous a permis de reproduire facilement l installation avec beaucoup de précision. Nous avons dans un premier temps pu valider cette extension car la surface totale que nous avons obtenue avec l éditeur est de m 2, ce qui correspond à 1.19 hectare (erreur de moins de 1%). Nous avons également dessiné les zones alentours pour donner un peu plus de vie à la simulation. Les deux stations étant placées, nous avons ensuite lancé dix simulations avec la configuration de base de la BigMow. En moyenne, après trois jours de simulation, les statistiques indiquent une performance de % pour la couverture d au moins un passage et % 46.

61 7. Validation 7.2. Test d un cas concret Figure 7.8: Parcelles visitées au moins trois fois (vert), deux fois (orange clair), une fois (orange foncé) ou zéro fois (rouge)). pour la couverture d au moins trois passages. L uniformité valant quant à elle 97.98%, ce qui montre que le terrain a été correctement couvert. Ces résultats confirment donc les informations provenant des formations techniques. Mais nous n en sommes pas restés là, nous avons voulu aller plus loin avec le simulateur afin de prouver que deux stations sont obligatoires pour ne pas que le robot tombe en panne. Nous avons donc supprimé une des stations et nous avons également lancé 10 simulations. Au terme de ce processus, les résultats sont sans appel, 8 simulations ont soulevé l erreur SHUT DOWN ERROR, indiquant que le robot est tombé en panne. Très certainement car il n est pas arrivé à revenir jusqu à sa station à temps, à cause des deux îlots et de la longueur du câble périphérique. En conclusion, pour chaque situation, le comportement attendu qui a été observé dans la réalité est très proche du comportement observé au sein du simulateur, ce qui prouve la validité du simulateur. De plus, les membres de BelRobotics, autant les techniciens que les installateurs ou que les ingénieurs, ont observé une grande similitude entre le comportement réel des robots sur le terrain et les résultats obtenus par nos simulations. Il est donc juste de considérer que JRS permet une simulation de l activité des robots dans leur environnement de travail qui est très proche de la réalité. On peut donc considérer le logiciel comme valide. 47.

62 7. Validation 7.2. Test d un cas concret Figure 7.9: Le parcours du retour station mis en évidence avec le nombre de passages. 48.

63 Troisième partie Architecture 49

64

65 Chapitre 8 Générale Notre architecture est composée de trois parties : la partie graphique, la partie éditeur et la partie simulateur. Pour commencer, abordons quelques concepts généraux de notre architecture, nous verrons ensuite ces trois parties de façon plus détaillée. 8.1 Structure La totalité de notre mémoire comptabilise plus de lignes réparties dans 150 classes triées dans 30 packages. On comprend alors vite qu une structure performante a dû être mise en place pour organiser tous ces fichiers. Séparation conceptuelle Une première séparation conceptuelle a été opérée dans notre architecture. Celle-ci a été réalisée en suivant le pattern Model View Controler, aussi appelé MVC. Le pattern MVC est destiné aux applications interactives, comme c est le cas pour le simulateur. Il a pour but de séparer les différentes composantes en les regroupant selon leurs fonctions respectives. On distingue 3 packages principaux : le modèle, la vue et le contrôleur. 1. Model : Le modèle représente le cœur algorithmique du logiciel. Il regroupe les fonctions concernant le stockage des données, ainsi que leur traitement. 2. View : La vue constitue l interface avec l utilisateur. Elle affiche les informations stockées dans le Modèle et relaye les différents évènements produits par l utilisateur (mouvement de souris, sélection d un bouton, etc). 3. Controller : Le contrôleur prend en charge la gestion des événements afin de les synchroniser entre la Vue et le Modèle. 51

66 8. Générale 8.2. Catégorie d objets Séparation fonctionnelle Dans chacun des packages Model et View une seconde séparation sous-jacente dite fonctionnelle a été réalisée afin de distinguer les éléments spécifiques de l éditeur et du simulateur. Cette séparation fonctionnelle nécessite donc la création de deux packages editor, et simulator dans la View et dans le Model. 8.2 Catégorie d objets Les 150 classes que nous avons implémentées nous ont également forcés à trier nos classes intelligemment. Pour ce faire, nous nous sommes basés sur le pattern Composite que nous avons quelque peu remanié. Il est important de bien comprendre ce concept, car il est présent partout dans notre architecture. Nous nous sommes rendu compte que la grande majorité de nos objets sont regroupables en catégories. Tous ces objets possèdent fréquemment un ensemble de fonctionnalités communes, qu ils doivent impérativement implémenter. Pour rendre obligatoire ces fonctionnalités, nous sommes passés par des classes abstraites. En effet, celles-ci permettent de définir un ensemble de méthodes obligatoires mais également d implémenter celles qui sont identiques à chaque objet. Avec ce système nous avons identifié trois types d objets (Figure 8.1) : les racines, les feuilles et les gestionnaires. 1. Root : Les objets racines sont des classes abstraites décrivant les fonctionnalités de base que doit implémenter une catégorie d objets. 2. Leaves : Les objets feuilles sont les classes d une catégorie. Elles implémentent l objet racine de cette dernière. 3. Manager : Les objets gestionnaires manipulent et agencent les objets feuilles de leur catégorie. Figure 8.1: Racine, feuilles et gestionnaire. 52.

67 8. Générale 8.2. Catégorie d objets Afin de plus facilement identifier la catégorie de nos objets, nous avons adopté une convention de nommage régie par 3 règles : 1. Chaque catégorie est identifiée par une lettre de l alphabet. 2. Il n existe qu un objet racine par catégorie et celui-ci doit obligatoirement s appeler XObject (où X est la lettre de la catégorie). 3. Chaque objet feuille d une catégorie doit obligatoirement s appeler XMyObject (où X est la lettre de la catégorie et MyObject le nom de l objet). Catégories existantes Dans l architecture actuelle du code, nous avons identifié 10 catégories : Catégorie Domaine Racine Gestionnaire Nbr de feuilles Environnement Editeur EObject.java Environment.java 6 Paramètre 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: Catégories existantes 53.

68 8. Générale 8.2. Catégorie d objets 54.

69 Chapitre 9 Graphisme La première architecture que nous allons aborder est celle relative à l interface graphique. Lorsque nous avons commencé l implémentation du logiciel nous avons très vite été insatisfaits des composantes basiques de Java. En effet, les différents objectifs que nous nous étions fixés ne nous permettaient pas, avec les composantes standards de Java, de développer et aboutir à une application acceptable. De plus, nous trouvions que le style bleu métallique de l API Swing n était pas approprié à notre simulateur. Le logiciel ayant également pour vocation d être utilisé par le département marketing, il était donc primordial de soigner notre interface graphique pour ne pas faire fuir les clients au premier coup d oeil. Nous avons donc décidé de développer nos propres composantes graphiques. Le travail que nous avons réalisé à ce niveau peut être divisé en 3 catégories : 1. Les composantes de base : Nous avons redessiné toutes les composantes de base d une interface graphique. Cela comprend les boutons, les zones de texte ou encore les barres de progression. 2. Les listes : Nous avons développé notre propre système de listes. Celuici sert à afficher verticalement des informations à l utilisateur. Ces listes n ont rien de comparable avec une liste déroulante, elles peuvent contenir de gros objets. Elles sont utilisées dans quasiment toutes les fenêtres du simulateur. 3. Le moteur graphique : Nous avons également développé notre propre moteur graphique. Celui-ci permet de dessiner et de manipuler un ensemble de formes ou d images. Parmi ces fonctionnalités, il y a un mécanisme de zoom fluide, un système de déplacement intuitif ou encore des échelles personnalisables. 55

70 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 mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin

71 9. Graphisme 9.2. Listes 9.2 Listes A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin Moteur graphique A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin Gestionnaire de ressources A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin

72 9. Graphisme 9.4. Gestionnaire de ressources 58.

73 Chapitre 10 Éditeur L éditeur va permettre à l utilisateur de créer son environnement (Figure 10.1). Il va également permettre de personnaliser le robot et les statistiques de simulation, mais ces deux fonctionnalités seront détaillées dans l architecture du simulateur. Figure 10.1: Fenêtre de l éditeur d environnement. Commençons par aborder la façon dont nous avons agencé la fenêtre de notre éditeur. Elle est composée de 2 éléments principaux : 1. Au centre de la fenêtre se trouve l environnement que l utilisateur construit. Il est représenté à l aide de notre moteur graphique. 2. A droite de la fenêtre se trouve une liste. Celle-ci contient tous les éléments présents au sein de l environnement. Chaque élément de l environnement est donc simultanément présent dans la liste de droite et dans le moteur graphique au centre. 59

74 10. Éditeur Google Map 10.1 Implémentation A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin Objets existants A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin Conversion A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin Google Map A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin

75 Chapitre 11 Simulateur Nous allons maintenant aborder la dernière architecture de notre logiciel, celle du simulateur. Contrairement au chapitre décrivant le logiciel, il est ici important de bien se rendre compte que nous ne sommes plus à la place d un simple utilisateur. Pour expliquer l architecture du simulateur nous allons nous mettre à la place d un ingénieur de BelRobotics qui désire ajouter des fonctionnalités au logiciel. Ces nouvelles fonctionnalités vont nécessiter de sa part une intervention dans le code source. Bien entendu, comme vous le constaterai, nous avons essayé de rendre notre architecture la plus modulable possible pour lui faciliter la tâche. Lorsque nous parlerons dans nos explications d un développeur externe ou d un ingénieur de BelRobotics, cela fera donc référence à un développeur peu familier avec le code source et son architecture. Nous allons maintenant aborder la dernière 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 étant qu un ensemble de simples simulations, nous ne l aborderons quasiment pas. Figure 11.1: Fenêtre de simulation. 61

76 11. Simulateur. Commençons par voir les trois composantes d une simple simulation (Figure 11.2) : 1. Un robot : Le robot est composé d un ensemble de modules qui simulent ses composantes électroniques. Chaque module est indépendant des autres et remplit une tâche bien précise. 2. Une navigation : La navigation est le corps décisionnel du robot, elle utilise une liste de comportements ainsi qu un ordonnanceur pour déterminer dans quel état elle se trouve. 3. Un environnement : L environnement représente le monde virtuel dans lequel le robot va évoluer. Il est composé d un grand tableau de parcelles qui représente l environnement de simulation. Chaque parcelle pointe vers un type de zone particulière. L environnement gère également une multitude de stations. Figure 11.2: Composantes d une simulation. 62.

77 11. Simulateur Prérequis 11.1 Prérequis A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin Les paramètres A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin Les statistiques A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin

78 11. Simulateur Prérequis 64.

79 11. Simulateur Le robot 11.2 Le robot Maintenant que les concepts de paramètres et statistiques ont bien été assimilés, nous allons aborder le premier point central du simulateur : le robot. Pour le robot, nous avons du imaginer une architecture qui soit à la fois modulable, efficace et surtout, simple d utilisation. En effet, une grande partie des modifications qu apporteront les ingénieurs de BelRobotics se situeront dans le robot. Il est donc primordial que son fonctionnement soit simple et efficace, afin de leur donner un maximum de liberté dans leurs expérimentations. Nous avons choisi de représenter notre robot comme un ensemble de boîtes ayant chacune un rôle bien précis. Nous avons appelé ces boîtes, des modules. Un module seul n a pas d intérêt, mais plusieurs modules rassemblés forment un robot (Figure 11.3). Figure 11.3: Les modules d un robot. Les modules jouent un rôle central dans le simulateur, ils sont considérés comme les yeux et les oreilles de la navigation. Chaque module est une composante électronique du robot. Nous avons donc par exemple, un module sonar, un module magnétique, un module de déplacement, ou encore un module de tonte. Ils ont chacun une fonctionnalité bien précise et n ont quasiment pas d interaction entre eux (le module sonar ne va jamais interagir de lui-même avec le module de déplacement). C est en réalité, à travers la navigation, que les modules vont avoir du sens. Celle-ci va, par exemple, vérifier d éventuels obstacles avec le module sonar, pour ensuite décider de l action à réaliser avec le module de déplacement. Voyons les trois raisons qui nous ont poussés à développer ce système de modules : 1. Cacher l environnement à la navigation : Dans la réalité, la navigation n a pas connaissance de son environnement, elle doit le découvrir à l aide de ses nombreux senseurs (sonar, bobine magnétique, boudin de pression, etc). Dans le simulateur nous avons voulu reproduire ce 65.

80 11. Simulateur Le robot concept de visibilité, et ne laisser paraître à la navigation que ce qu elle est censée voir dans la réalité. L environnement n est donc pas accessible à la navigation, cette dernière doit passer par les modules pour le découvrir. 2. Rendre les modules indépendants : La division du robot en modules permet de rendre presque tous les modules indépendants les uns des autres. De cette manière, on pourrait imaginer un robot sans lame de tonte, simplement en lui enlevant le module de tonte. Il pourrait toujours se déplacer, détecter les obstacles et les éviter, mais il ne tondrait plus. La suppression de ce module n entraînerait aucune erreur dans les autres modules étant donné qu ils n interagissent pas entre eux. Cependant, il arrive parfois que cette indépendance ne soit pas possible. C est le cas, par exemple, pour le module de déplacement qui a besoin d interagir avec le module batterie pour prendre en compte sa consommation énergétique. 3. Faciliter l intégration de nouvelles fonctionnalités : Pour finir, cette division en modules permet d ajouter facilement de nouvelles fonctionnalités, sans devoir les ajouter dans une grosse classe illisible. Elle permet de rendre notre architecture très modulable. Nos modules étant indépendants, ils peuvent également être facilement mis à jour car leur domaine d action se limite à leur classe Implémentation A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin Exemple A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin

81 11. Simulateur Le robot Modules existants A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin

82 11. Simulateur Le robot 68.

83 11. Simulateur La navigation 11.3 La navigation Abordons dès à présent le deuxième point central du simulateur : la navigation. Le système de navigation concerne la partie qui reçoit les informations des différents modules et qui décide de la prochaine action à réaliser. Elle utilise une liste de comportements ainsi qu un ordonnanceur pour déterminer dans quelles tâches elle se situe (Figure 11.4) : Figure 11.4: L ordonnanceur et ses comportements (version simplifiée). Avant de choisir ce type d ordonnanceur, nous avons envisagé d autres solutions, toutes plus tordues les unes que les autres. C est finalement suite au conseil de Mr. Pecheur que nous avons décidé d utiliser une architecture de contrôle par tâches : L architecture de contrôle par tâches permet de réaliser un programme réactif de manière modulaire. Le principe est de décomposer le programme en plusieurs tâches qui sont exécutées au besoin, en respectant un ordre de priorité, plutôt que de manière prédéterminée par le programme. Ceci permet de caractériser clairement chaque aspect du comportement, et d ajouter facilement des tâches supplémentaires. 12 Nous nous sommes basés sur l architecture présente dans le LoJOS NXJ, qui est un environnement de programmation Java pour le Lego Mindstorms NXT. Nous l avons entièrement réécrit et avons adapté son fonctionnement afin qu il soit compatible avec une exécution en 69.

84 11. Simulateur La navigation temps discret, comme c est le cas dans notre simulateur. En effet, dans notre cas les calculs sont réalisés lors de chaque itération, toutes les 100 millisecondes Implémentation A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin Exemple A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin Algorithmes de navigation A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin

85 11. Simulateur L environnement 11.4 L environnement Pour finir, abordons le troisième point central du simulateur : l environnement. L environnement représente le monde virtuel dans lequel le robot va évoluer. Il est composé de parcelles, chacune pointant vers un type de zone particulière (Figure 11.5). Il est important de faire la différence entre l environnement côté simulateur et celui côté éditeur, car leur représentation est complètement différente. Figure 11.5: Les stations, parcelles et zones de l environnement Implémentation A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin Affichage A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin

86 11. Simulateur L environnement 72.

87 11. Simulateur Simulation 11.5 Simulation A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin

88 11. Simulateur Simulation 74.

89 Chapitre 12 Algorithmes de navigation Nous avons, dans le cadre de ce mémoire, implémenté deux algorithmes de navigation : L algorithme de navigation actuel des robots (algorithme classique) afin de pouvoir étudier son comportement et ses éventuels défauts, mais également afin de pouvoir tester le bon fonctionnement du simulateur. Un prototype d algorithme utilisant le positionnement GPS dans sa navigation. Tous les algorithmes de navigation ont été réalisés en suivant l architecture de navigation développée précédemment. Cela nous a permis notamment de réutiliser des éléments de l algorithme classique pour notre prototype d algorithme GPS Navigation classique A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin Navigation GPS A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin

90 12. Algorithmes de navigation Navigation GPS 76.

91 Chapitre 13 Algorithmes particuliers Dans cette section, nous détaillerons quelques algorithmes particuliers qui ont été intégrés à notre logiciel et qui valent la peine d être détaillés dans le cadre de ce travail A-star Comme expliqué dans la chapitre sur les algorithmes de navigation, concernant l algorithme de navigation GPS, le robot rentre en calculant le chemin le plus court vers un point de réentrée station tout en évitant un maximum les tournants. L algorithme de calcul du plus court chemin se base sur l algorithme A* modifié afin d éviter un maximum de tournants. Pour rappel, l algorithme A* est un algorithme permettant de trouver un chemin entre deux noeuds dans un graphe. Une fonction heuristique est utilisée sur chaque noeud afin d estimer le meilleur chemin et les noeuds sont ensuite visités dans l ordre donné par l évaluation de la fonction. Dans notre cas, le graphe est construit à partir de de la matrice réalisée par le mapping du module MMap. Le coût heuristique utilisé pour notre implémentation est le suivante : costheuristic(node) = cost(node) + functionheuristic(node) cost(node) : distance parcourue entre le noeud courant et le noeud initial (1 par déplacement normale ; 1.5 par tournant) functionheuristic(node) : distance à vol d oiseau entre le noeud courant et le noeud final. A* commence au noeud de départ (la case correspondant à la position du robot). Il va appliquer la fonction heuristique à ce noeud, et si celui-ci est le noeud d arrivée (la case correspondant au point de ré-entrée station) alors la recherche de chemin s arrête. Si ce n est pas le cas, il va alors appliquer la fonction d évaluation à tous ses noeuds limitrophes (cases de pelouse limitrophes dans la matrice de mapping) et les ajouter dans une file de priorités. A* prendra ensuite le noeud le plus prioritaire de la file (le retirera) et y appliquera les mêmes étapes que celles appliquées au noeud de départ, c est à dire : appliquer la fonction 77

92 13. Algorithmes particuliers Champ magnétique d évaluation à tous ses noeuds limitrophes (cases de pelouse limitrophes dans la matrice de mapping) et les ajouter dans une file de priorité.s L algorithme s arrête quand le noeud analysé est le noeud de destination, dans ce cas on a trouvé 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 on reconstruit un chemin du noeud de départ au noeud d arrivée. Il est nécessaire de sauvegarder une liste des noeuds explorés afin d éviter de réaliser des boucles lors de l exploration du graphe. Figure 13.1: Exemple de l algorithme A* avec une heuristique de distance manhattan (distance en L). Le principal avantage de cet algorithme est qu il n y a pas de pré-calcul nécessaire et qu il consomme peu de mémoire, il est donc adapté au petit processeur des robots tondeuses Champ magnétique Comme expliqué précédemment, l environnement est représenté par une matrice de parcelles. Chaque parcelle possède une variable représentant la distance par rapport au point du câble le plus proche. La valeur du champ magnétique émis par le câble en chaque parcelle, est simulée par la valeur de la distance par rapport au câble. Afin de représenter le changement de phase du champ magnétique entre l intérieur et l extérieur du câble périphérique, les distances sont positives à l intérieur et négatives à l extérieur. On construit donc une matrice de distances par rapport au câble afin de simuler le champ magnétique en tout point du terrain. Cette matrice est calculée avant l exécution de la simulation. L algorithme de construction de la matrice du champ magnétique est décomposé en trois étapes : La première étape consiste à initialiser l ensemble des valeurs de la matrice afin de savoir quelles sont les cases intérieures et quelles sont les cases extérieures au fil périphérique. La valeur de la case est initialisée à 1 si celle-ci se trouve à l intérieur du câble périphérique, c est-à-dire si la parcelle correspondante est sur une zone de type ZObstacle ou ZGrass. 78.

93 13. Algorithmes particuliers Champ magnétique La valeur de la case est initialisée à -1 si celle-ci se trouve à l extérieur du câble périphérique, c est-à-dire si la parcelle correspondante est sur une zone de type ZObstacle ou ZGrass. La seconde étape consiste à mettre la valeur de toutes les cases non limitrophes au fil périphérique à 0. On parcourt donc toute la matrice et toutes les cases ne possédant pas un voisin de valeur opposée sont mise à 0. On obtient la valeur de toutes les cases à la bordure du fil périphérique. La troisième étape va consister à donner la valeur de la distance par rapport au cable en tout point de la matrice. Pour cela, on part de l ensemble des cases dont la valeur est égale à +/- la valeur courante, 1 étant la valeur courante initiale de l étape. Pour chaque case de l ensemble, on regarde toutes les cases limitrophes (mais pas les cases situées en diagonale) dont la valeur vaut 0, on les appellera les voisins. On met la valeur des voisins a +/- [la valeur courante + 1], + si les voisins sont limitrophes à une case négative, - autrement. Une fois la liste vide, on incrémente la valeur courante de 1, et on recommence l étape 3. L étape se termine lorsqu il n y a plus de case correspondant à la valeur courante. On obtient ainsi une matrice donnant la distance par rapport au câble en tout point du terrain (Figure 13.2). Figure 13.2: Exemple de matrice de distance par rapport au cable. Il est à noter que, ce sont le filtre magnétique et le module magnétique qui produisent l effet de champ constant à partir d une certaine distance du câble. C est à dire qu à partir d une certaine distance du câble, la valeur du champ magnétique retournée par le module MMagnetic sera constante. Cela représente le fait qu au delà d une certaine distance du fil périphérique, le champ possède une valeur faible quasi constante. Ce système de matrice permet une approximation convenable du champ magnétique produit par le fil périphérique. Il permet de par le pré-calcul, d alléger les opérations réalisées pendant la 79.

94 13. Algorithmes particuliers Champ magnétique simulation et ainsi d accélérer celle-ci. Le module magnétique du robot est également simplifié car celui-ci n a plus qu à lire la valeur de la distance en fonction de la parcelle sur laquelle il se trouve. C est donc une solution simple, robuste et efficace. 80.

95 Quatrième partie Conclusion et perspectives 81

96

97 Chapitre 14 Rappel des objectifs Pour rappel, le but de ce mémoire était de concevoir un logiciel de simulation pour robots autonomes afin de pouvoir tester rapidement et facilement les nouvelles améliorations possibles et ainsi d évaluer leurs impacts sur les performances de ces robots. Nous allons brièvement revoir l ensemble des objectifs qu il nous a été demandé de réaliser tout au long de ce projet. Les objectifs architecturaux étaient les suivants : La solution doit être modulaire afin de permettre aux ingénieurs de BelRobotics de continuer à développer facilement des fonctionnalités au sein du simulateur. Le logiciel doit être séparé en deux parties distinctes, simulateur et éditeur, pour conserver leur indépendance et faciliter ainsi les développements futurs. Enfin, l interface graphique du logiciel doit être gérée automatiquement par le programme afin de ne pas devoir s occuper de l ajout des composantes graphiques lors du développement de nouvelles solutions par les ingénieurs. Les objectifs fonctionnels étaient les suivants : Le logiciel doit posséder un éditeur permettant de créer des environnements personnalisables. Le robot doit facilement être paramétrable via une interface dédiée, permettant de sauvegarder et réutiliser à tout moment l une de ses configurations. Le programme doit comporter un gestionnaire de simulation montrant graphiquement l évolution du robot dans son environnement de travail, avec la possibilité de modifier sa vitesse de simulation. La simulation graphique doit comporter un ensemble de filtres permettant de faciliter la compréhension visuelle de l environnement via l affichage de différents types d informations. 83

98 14. Rappel des objectifs. À la fin d une simulation, toutes les données statistiques doivent être sauvegardées dans un fichier externe sous forme de tableau. L utilisateur doit avoir la possibilité de lancer, de manière automatique, une grande quantité de simulations avec des paramètres variables, et cela dans le but de déterminer l efficacité de ces variations. L interface graphique doit être soignée et permettre une utilisation plus confortable du logiciel. Des critères objectifs permettant de définir les performances des robots dans leur environnement doivent être définis. 84.

99 Chapitre 15 Solution développée Le premier problème auquel nous avons été confronté a été la nécessité de pouvoir tester rapidement et facilement les nouvelles améliorations possibles des robots afin d évaluer leurs impacts sur les performances de ces robots. Toutes les solutions existantes étant complexes, chronophages et coûteuses. Afin de résoudre ce problème, nous avons donc développé JRS, un logiciel de simulation de robots mobiles autonomes dans son environnement de travail. JRS permet, de par ses nombreuses fonctionnalités, de tester rapidement et efficacement les nouvelles améliorations afin d évaluer leurs impacts sur les performances des nouveaux robots. Les nouveaux algorithmes peuvent être facilement encodés dans notre logiciel grâce à l architecture modulaire du système de navigation par contrôle de tâches. La décomposition du robot en un ensemble de modules dans JSR, rend très facile la modification des éléments le constituant afin de tester par exemple un module GPS modifié. Les systèmes des paramètres et des statistiques, permettent facilement l ajout de nouveaux paramètres et de nouvelles statistiques de simulation qui seront rendus disponibles automatiquement dans les interfaces graphiques. Un éditeur de robots et de paramètres, ainsi qu un éditeur d environnement complet permettent à l utilisateur de tester un grand nombre de configurations différentes de test. Le simulateur permet d observer l évolution en temps réel du robot dans son environnement de travail, avec la possibilité d accélérer la vitesse d exécution du robot et d utiliser des filtres affichant différents types d informations. Il est également possible d exécuter plusieurs simulations simultanément avec des ensembles de paramètres différents, afin d exploiter pleinement la puissance de calcul d un ordinateur en vue d une optimisation des paramètres de navigation. 85

100 15. Solution développée. L évaluation de l impact des améliorations à l aide de notre logiciel a soulevé un second problème : la nécessité de pouvoir quantifier les performances d un robot. Etant donné qu il n existait aucun critère permettant d évaluer les performances des robots tondeuses, nous avons dû définir des critères objectifs permettant d évaluer les performances des robots dans leur environnement. Les différents critères développés ont permis la quantification d une notion complexe qui, auparavant, nécessitait de visualiser le terrain pour évaluer si le résultat de la tonte était acceptable. Grâce aux trois critères numériques développés, il est maintenant possible de comparer plusieurs simulations sur la simple base de leurs statistiques, afin de déterminer laquelle d entre elles donne les meilleurs résultats. Enfin le troisième problème qui nous a été posé consiste en la création d un prototype d algorithme de navigation des robots utilisant la technologie de positionnement GPS. Après avoir implémenté l algorithme de navigation actuel des robots tondeuses BelRobotics, nous avons donc développé un prototype d algorithme utilisant un module GPS permettant au robot de connaître sa position approximative et d effectuer un mapping de son environnement afin de pouvoir rentrer à sa station sans suivre le cable. Cet algorithme apporte une solution efficace au problème des traces que réalise le robot en suivant son câble, du fait que le robot rentre à sa station par des chemins différents qui passent par le centre du terrain. 86.

101 Chapitre 16 Améliorations et perspectives Dans ce chapitre, nous présenterons les différentes améliorations qu il serait intéressant d apporter au projet. Nous aborderons deux types de travaux futurs, les améliorations à apporter au logiciel, et les améliorations à apporter aux algorithmes de navigation Simulateur A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin Navigation A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin

102 16. Améliorations et perspectives Navigation 88.

103 Chapitre 17 Conclusion En conclusion, parmi l ensemble des problèmes qui nous ont été posée au départ, tous ont été résolus. Nous avons été amenés à développer JRS, qui est devenu à ce jour un puissant outil muni de nombreuses fonctionnalités et, comme le montre le chapitre sur les travaux futurs, possédant beaucoup de potentiel. Nous avons également développé les premiers critères numériques rendant possible la comparaison de plusieurs simulations. Pour terminer, nous avons réalisé un nouvel algorithme de navigation GPS résolvant un important problème de la navigation classique des robots. Le logiciel que nous avons développé, JRS offre de nombreuses possibilités. JRS, de par sa modularité, permet de continuellement adapter le robot et d évaluer ses performances, ce qui est un énorme atout dans un contexte technologique en évolution constante. Il rend possible la prise en compte de l évolution continue de la technologie de positionnement GPS, permettant ainsi d améliorer et d affiner sans cesse les résultats au cours de cette évolution. La technologie GPS n est pas la seule en évolution constante : les véhicules électriques suscitant un intérêt croissant, l amélioration des batteries devient une source d innovations importantes. Nous pouvons d ailleurs le constater avec les nouvelles batteries développées à l UCL qui allient super capacité et charge ultra-rapide 15. Mais la modularité et la flexibilité de JRS ne se limite pas à sa capacité d adaptation à l évolution technologique. Cela rend également envisageable, moyennant une interface adéquate, la compilation directe du code source du software robot afin de pouvoir valider ce code directement sur PC à l aide de JRS. Cette approche est dite host build. La validation directe du code source du robot serait un puissant outil de validation et de développement. Les possibilités offertes par JRS ne concernent pas que le test d amélioration des concepts et des machines existantes. Il peut également être utilisé afin de tester de tout nouveaux systèmes comme par exemple estimer les performances d une flotte de robots coopérant entre eux, comme c est le cas dans le projet Swarm-Bots 14. Le principe serait d utiliser des robots simples et peu coûteux, d un intérêt individuel limité, mais qui ensemble forment un système complexe et robuste. Il est également important de noter que JRS offre des possibilités aux équipes de recherche et développeme, mais aussi aux équipes de management. Par exemple, une 89

104 17. Conclusion. modélisation correcte du robot Ballpicker permettrait de prédire approximativement le nombre de balles ramassées par jour offrant ainsi la possibilité de développer un nouveau modèle financier pour BelRobotics où le client ne payerait pas l installation du système, mais payerait par balle ramassée. Son utilisation à des fins commerciales peut aussi concerner le dimensionnement des cas d installations très complexes et quasi impossibles à modéliser, comme par exemple des vergers ou des surfaces industrielles complexes. Enfin, une utilisation du logiciel à plus large spectre est clairement envisageable. On pourrait imaginer d étendre JRS aux robots de traitements de surfaces comme les aspirateurs robots autonomes par exemple. Comme le montrent tous ces exemples, la modularité et la flexibilité de notre solution offre des perspectives d avenir fort intéressantes. Et qui sait, si un jour l humanité quitte la planète en oubliant de débrancher le dernier robot, celui-ci aura peut-être été développé à l aide de JRS. 90.

105 Chapitre 18 Références 1. Dynamite, Site internet de BelRobotics, http :// version 2014, éditeur : BelRobotics, site internet 2. Belrobotics sa/nv, Formation technique, version 2014, éditeur : BelRobotics, document 3. Ho Trong Viet - Charles Pecheur, Programmer le NXT, Version 4 13 Nov 2012, éditeur : FSAB 1501 Projet 1, document 4. ArduMower Project, http :// site internet 5. Dr. Marco Dorigo, Swarm-bots Project, European Commission (IST ), http :// site internet 6. Java TM Platform, Standard Edition 7 API Specification, , Oracle and/or its affiliates, site 7. Ponciano Jean-Jacques - Prudhomme Claire, Simulation d un robot aspirateur chargé de nettoyer une pièce comportant des obstacles, publié durant l année académique , éditeur : cours L2 Informatique - Université de Bourgogne, document & logiciel 8. Viking, Planificateur de jardin imow, http ://plan-imow.viking-jardin.fr/, publié en 2014, éditeur : Viking, logiciel 9. Sebastien Roed Mangseth, Robot Vacuum Simulator 2013, http ://www. itwire.com/your-it-news/entertainment/60619-robot-vacuum-simulator will-suck-up-your-life, publié en 2013, éditeur : Stolidus Simulation, logiciel 10. David Hovemeyer, York College of Pennsylvania, Assignment 4 : Robot Lawnmower Simulation, http ://goose.ycp.edu/ dhovemey/fall2009/ cs201/assign/assign4.html, logiciel 11. Gardensoft, Advanced Lawnmower Simulator, publié en 1988, éditeur : Your Sinclair (UK), logiciel 91

106 18. Références. 12. LeJOS Project, LeJOS NXJ, http :// publié en 2006, document & logiciel 13. Caceres Frias Edgard - Henricot Julien - LauchKim-Séang - Moulin Rémy - Poelvoorde Nora - Toussaint Sébastien, Analyse de BelRobotics, publié en mai 2014, éditeur : FSA2230-Sensibilisation à la gestion d entreprise, document & exposé 14. Scrum (software development), http ://en.wikipedia.org/wiki/scrum ( software development), publié le 27 May 2014, éditeur : Wikipédia 15. Des batteries qui allient super capacité et charge ultra-rapide, actualités, http :// UCL 16. Axel van Lamsweerde, INGI Software Enginnering and Project, , UCL, Cour. 17. Yves Deville, INGI Artificial Intelligence, , UCL, Cour. 92.

107 Cinquième partie Annexe 93

108

109 Annexe A Backlog A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin

110 A. Backlog. 96.

111 Annexe B Cahier des charges Contexte Le but du travail est de concevoir de nouveaux logiciels de navigation pour robot automatique de type tondeuse ou ramasseur de balles de golf. Dans un premier temps, il faudra développer un logiciel de simulation de robot tondeuse automatique, dans son environnement de travail. Dans un second temps suivra une phase de recherches et de tests sur de nouveaux algorithmes de navigation, cette phase sera réalisée à l aide du logiciel de simulation développé dans la première phase du projet. Ce travail se fera en collaboration avec la société BelRobotics à Wavre, qui développe ce type de robots. Il sera idéalement couplé à un stage au sein de BelRobotics. L objectif de ce programme est de faciliter les tests sur leurs produits ou sur différents prototypes afin de développer des algorithmes de navigation plus performants. Il sera également utilisé à des fins marketing dans le but de montrer au client les différentes possibilités offertes par les produits BelRobotics. Fonctions A la demande de l entreprise dans laquelle ce mémoire a été réalisé, cette partie n est pas disponible publiquement. Elle cessera d être confidentielle en juin