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.