Rapport de Projet de Fin d'études Méthodes ensemblistes pour la validation de trajectoires

Transcription

1 ENSTA Bretagne ENSI 2014 option SPID Robotique Rapport de Projet de Fin d'études Méthodes ensemblistes pour la validation de trajectoires Vincent LE DOZE MBDA France Le Plessis-Robinson, FRANCE Dates : 24/03/ /08/2014 Encadrant École: M. Luc JAULIN (ENSTA Bretagne) Ce document est la propriété de MBDA France. Il ne peut être communiqué à des tiers et/ou reproduit sans l'autorisation préalable écrite This document and the information contained herein is proprietary information of MBDA France and shall not be disclosed or reproduced

2 2 Résumé L arithmétique par intervalles propose une approche mathématique différente par rapport aux méthodes classiques utilisées pour analyser la stabilité de systèmes complexes. Ces méthodes ont déjà été appliquées avec succès au domaine de la robotique mobile; il s agit maintenant de montrer leur potentiel dans le cadre d autres domaines comme celui des missiles et des drones. Il s agit notamment de comparer cette approche par rapport à d autres méthodes actuellement utilisées comme les méthodes probabilistes à base de simulations Monte-Carlo. La problématique principale de ce stage est de démontrer que les méthodes par intervalles peuvent être plus efficaces (preuves des résultats et rapidité d exécution des algorithmes) que les autres méthodes utilisées jusqu à présent pour la validation de systèmes dynamiques, munis de leurs lois de commande (systèmes dynamiques autonomes); l évolution de tels systèmes étant décrite par modèles d état. On considérera plus particulièrement le cas d un engin aérien devant suivre une trajectoire de référence. Valider la loi de commande et la trajectoire d un tel système autonome, revient à démontrer que lorsqu on lui assigne une trajectoire à suivre (définie par des points de passage, par exemple) ce système suivra sa mission quel que soit les perturbations (vent par exemple), et cela sans jamais dépasser un écart limite entre la position ou il devrait se trouver et celle où il se trouve réellement. Un tel logiciel doit permettre d aider à la mise au point et à la validation d une loi de contrôle commande. De plus, un autre but est de prouver que, s il existe un obstacle (fixe ; éventuellement mobile) entre l objectif à atteindre et la position initiale de l engin, et que l on en tient compte en planifiant une trajectoire adéquate, alors il n y aura aucune collision entre l obstacle et l engin (peu importe les perturbations qu il rencontrera). Abstract The interval arithmetic provides a different approach over conventional methods to analyze the stability of complex autonomous systems. These methods have already been successfully applied in problematic relatives to the field of mobile robotics, and it is now time to show their potential in other areas such as path planning for autonomous aerial systems. Hence, it includes comparing this approach to other methods currently used as probabilistic methods based on Monte Carlo simulations. So, this project aims to show that interval methods can be more effective (evidence of results and speed of algorithms execution) than other methods used to validate autonomous dynamic systems with their laws control (systems described by state equations). In this project, we are specifically going to consider the case of an autonomous system following a reference trajectory. Then, to validate the control law and trajectory of such a system, we need to demonstrate that this system will follow its mission path regardless of the disturbances (wind, for example), without ever exceeding a limit distance between its position and the trajectory line. Therefore, these methods could be used in parallel of probabilistic method to give additional information on the system behavior when following a reference trajectory.

3 3 Remerciements Je tiens à remercier et à témoigner toute ma reconnaissance à mon maître de stage, pour m avoir guidé et encadré tout au long de ce stage de fin d études. Sa présence et ses conseils m ont été particulièrement utiles et indispensables pour mener à bien ce projet. Je remercie également Monsieur Luc JAULIN, ainsi que Monsieur Jordan NININ, enseignants à l ENSTA Bretagne, pour avoir assuré la partie théorique de ce projet, ainsi qu un suivi attentif des avancées au cours de ce stage. Je remercie également l équipe pédagogique de L ENSTA Bretagne et les intervenants professionnels responsables de la formation SPID pour avoir assuré l enseignement de celle-ci. Je souhaite aussi remercier l équipe du service Guidage, Pilotage et Navigation de MBDA France, pour leur accueil sympathique et leur coopération professionnelle tout au long de ces trois mois. Enfin, je voudrais remercier Messieurs Rémi B., Rémi L., Paul A. et Ronan F. pour leur sympathie et leur bonne humeur tout au long de ce stage.

4 4 Contenu Résumé... 2 Abstract... 2 Remerciements... 3 Notations et conventions... 6 Introduction Présentation de MBDA Département Pilotage, Guidage, Navigation et Traitement d images Déroulement du Stage... 8 Introduction à l Arithmétique par Intervalles Algorithme SIVIA Les Contracteurs Utilisations dans le cadre de la Robotique mobile Projet Bubbibex Principe du programme Mise en place du programme a) Programmation avec Ibex b) Diagramme de Classe c) Interface graphique Cas de test et d utilisation a) Robot terrestre holonome b) Robot terrestre non-holonome c) Robot aérien non-holonome Problèmes rencontrés et modifications apportées a) Évolution temporelle de la bulle b) Intégration des Solutions c) Accélération de la résolution d) Résultats obtenus Planification de mission a) Adaptation du programme Bubbibex b) Résultats obtenus c) Voies d améliorations Projet Ellibex... 46

5 5 1- Principe du programme a) Incertitudes de pilotage b) Q-Intersections Mise en place a) Diagramme de Classe b) Interface graphique Test du programme Projet Reachable Sets Principe du programme a) Utilisation des méthodes par Intervalles b) Limitation du temps de calcul Mise en place a) Fonctionnalités du programme b) Interface graphique Test du programme Conclusion Table des Figures Bibliographie... 68

6 6 Notations et conventions : Temps en secondes. : Pas de discrétisation du temps pour l intégration d une trajectoire. : Coordonnées (m) de la position d un robot dans le plan ou dans l espace. : Angle (rad) de cap d un robot dans le plan, ou de gisement dans l espace. : Angle (rad) de site d un robot dans l espace. : Vecteur d état décrivant un système donné. : Dimension du vecteur d état. : composante du vecteur d état avec. : Fonction d évolution d un système. : Entrée d un système dynamique. : Fonction cible représentant l état dans lequel un système doit se trouver : Nombre de composantes de la fonction correspond au nombre de contraintes spatiotemporelles à respecter pour le système. : Intervalle contenant l ensemble des solutions pour la variable. I Ensemble des intervalles sur. : Vecteur d intervalles ou «boîte» contenant l ensemble des solutions pour le vecteur d état [ ] : Estimée du vecteur d intervalles : Sous-ensemble du vecteur d intervalles tel que. : Sur-ensemble du vecteur d intervalles tel que. : Ensemble complémentaire du vecteur d intervalles tel que I : Largeur de l intervalle, égal à. : Valeur médiane de l intervalle, égal à. : Fonction de contraction ou contracteur sur l intervalle.

7 7 Introduction Ce stage de fin de cursus ingénieur avait pour intitulé «Étude des méthodes ensemblistes pour la validation de trajectoires», et s est déroulé sur le site de MBDA France du Plessis- Robinson(92), dans le service Futurs Systèmes du département Pilotage, Guidage, Navigation et Traitement d Image. Il a permis de mettre en pratique des connaissances et des compétences acquises tout au long de mon cursus ingénieur, et surtout d obtenir une vraie expérience professionnelle dans le domaine de l ingénierie. Au cours de ce stage de 5 mois, j ai principalement été amené à travailler sur trois problématiques différentes, qui seront détaillées au cours de ce rapport, résolues à partir des méthodes ensemblistes et particulièrement de l analyse par intervalles. La résolution de ces problématiques rentrait en partie dans le cadre d un partenariat entre l ENSTA Bretagne et MBDA France, ce qui m a amené à travailler en collaboration avec M. Jaulin et M. Ninin de l ENSTA Bretagne. 1- Présentation de MBDA Avec un chiffre d'affaires annuel de 3 milliards d'euros et un carnet de commandes de plus de 10,5 milliards d'euros, MBDA est un des leaders mondiaux des missiles et systèmes de missiles. Seul Groupe capable de répondre à toute la gamme des besoins opérationnels présents et futurs des trois armées (terre, marine et air), MBDA propose une gamme de 45 programmes de systèmes de missiles et de contre-mesures en service opérationnel et plus de 15 autres en développement. La société MBDA regroupe plus de collaborateurs principalement en Europe et est codétenue par BAE SYSTEMS (37,5%), AIRBUS Group (37,5%) et FINMECCANICA (25%)*. * Présentation de l entreprise provenant d un communiqué de presse Figure 1 : MBDA est issue principalement de la fusion entre Matra Défense (France), BAe Dynamics (UK) et Alenia Marconi Systems (Italie)

8 8 2- Département Pilotage, Guidage, Navigation et Traitement d images Les activités Pilotage, Guidage, Navigation et Traitement d images consistent à élaborer les algorithmes qui seront implémentés dans les calculateurs de mission des missiles et systèmes de missiles. Grâce à des techniques appropriées issues de l automatique, du traitement du signal ou du traitement d images, les équipes définissent, simulent et valident les traitements qui permettront d élaborer les trajectoires, les manœuvres, la précision de localisation et un guidage terminal adapté à la cible visée. Ces équipes caractérisent, dans les phases amont du projet, les besoins en performances des équipements (capteurs, imageurs, autodirecteurs, calculateur de bord, actionneurs). Elles valident ensuite les algorithmes embarqués dans les calculateurs, à partir d une modélisation fine du comportement des équipements et de leur environnements physiques dans un modèle de référence ; la réalisation de ce modèle de référence faisant appel à des techniques comme la mécanique du vol, l aérodynamique, la propulsion ou encore la détonique. 3- Déroulement du Stage Le stage s est organisé autour de 3 grands projets (détaillés plus tard): le projet Bubbibex, le projet Ellibex et le projet Reachable Sets. Comme le montre le diagramme de Gantt suivant, ces trois projets ont été réalisés en simultané, car les programmes utilisent tous les trois un algorithme SIVIA, et ont été conçus de manière presque identique. Ainsi toutes les améliorations et les corrections apportées à un programme, ont été répercutées directement sur les autres. Figure 2 : Diagramme de Gantt

9 9 Introduction à l Arithmétique par Intervalles Les méthodes ensemblistes caractérisent une approche mathématique fondamentalement différente des approches classiques dans la résolution de systèmes d équations. L arithmétique par intervalles est un cas particulier des méthodes ensemblistes, où une variable n est plus représentée comme une valeur, mais comme un intervalle, c est-à-dire un ensemble de valeurs possibles comprises entre un minimum et un maximum. Pour illustrer l intérêt de ce concept, l arithmétique par intervalles permet de situer que la taille vraie d un individu est entre 1.70m et 1.90m, plutôt que de donner une taille approximée avec l arithmétique usuelle. Aussi, comme dans l arithmétique classique, l arithmétique par intervalles définit des opérateurs de base qui permettent de faire des opérations sur des intervalles min ma - min ma si. La division par un intervalle contenant 0 n est pas définie en arithmétique des intervalles. L ensemble des intervalles sur qui se note I, est un anneau commutatif. On peut également introduire les fonctions usuelles de l arithmétique sur les réels comme ceci : l Ceci rend les techniques de calculs par intervalles facilement utilisables sur des cas concrets de résolution d équations où l on peut approcher la (ou les) solution(s) jusqu à une certaine précision en travaillant sur les deux bornes d un intervalle qui contient cette (ou ces) solution(s). D autre part, l arithmétique par intervalles peut aussi s appliquer sur des dimensions supérieures à 1. On parle alors de boîtes ou de vecteurs d intervalles : ( ) avec. L ensemble des vecteurs d intervalles sur de dimension se note I. 1- Algorithme SIVIA Comme expliqué précédemment, les méthodes par intervalles proposent d autres alternatives pour la résolution de problèmes formulés sous forme d équations ou d inéquations. Par exemple, si l on souhaite trouver l ensemble des couples solution tels que, (. ) (. )

10 10 Il suffit alors de trouver les sous-ensembles (ou sous-pavages) de I suivants : I (. ) (. ) Pour des intervalles de départ et définis à l avance (par exemple ) la résolution d un tel problème peut se faire immédiatement avec des méthodes détaillées un peu plus tard (cf. Les Contracteurs). Cependant pour des problèmes plus complexes, il devient vite nécessaire d utiliser un algorithme de calcul traduisant les méthodes par intervalles pour résoudre le problème donné. L Algorithme SIVIA (Set Inversion Via Interval Analysis) permet de résoudre des équations ou inéquations à partir de méthodes de classification et de bissection. Cet algorithme permet d obtenir l encadrement d un sous-ensemble de I sous la forme grâce à une fonction de test sur une boîte I qui renvoie : - Vrai: si - Faux : si - Peut-être : si l on ne peut pas conclure. Par exemple on ne peut pas répondre à la question : l intervalle est-il inclus dans l intervalle? Lorsque l on ne peut pas conclure sur une boîte I on vient alors bissecter cette boîte en deux boîtes différentes et telles que. Ces boîtes seront ensuite testées à leur tour. À partir du moment où les boîtes testées ont atteint une précision suffisante (. ), on arrête de les bissecter et on considère ces boîtes comme nonconclues. Ainsi l algorithme SIVIA, renvoie alors 3 sous-pavages de l espace initial I qui sont. Figure 3 : Algorithme SIVIA et résultats obtenus lors de la résolution de l équation du disque de centre (. l équation (. ) (. ).. ) et de rayon 1 décrit par Le problème principal de ce type d algorithme est son explosion combinatoire. Celle-ci le rend très gourmand en mémoire (stockage des boîtes ) et en puissance de calcul dès que l on veut une précision faible concernant les boîtes à bissecter (pour 10 appels récurrents, jusqu à boîtes différentes peuvent être générées).

11 11 2- Les Contracteurs Pour limiter les problèmes soulevés par l algorithme SIVIA, des opérateurs de contraction, ou contracteurs, sont mis en place pour bissecter le moins possible les boîtes présentes en entrée. Un contracteur, est un opérateur I I qui vérifie les 3 propriétés suivantes : ntra tan e I nsistan e ( ) aible ntinuit ( ) Avec la boule de centre et de rayon. Une boîte est dite insensible au contracteur si. Aussi la propriété de Contractance nous assure que par l action d un contacteur, un pavé ne peut que se contracter. La propriété de Consistance nous dit que tout pavé gardera, après contraction, tous ses points insensibles à ce même contracteur. Enfin, la propriété de faible Continuité nous assure que l ensemble des sensibles à est un ensemble ouvert, et donc que l ensemble des insensibles est fermé. Dans la pratique, un contracteur est une fonction crée à partir d une ou plusieurs contrainte(s), qui permet de réduire une boîte en entrée pour récupérer une sous-boîte qui satisfait ces contraintes. Figure 4 : Contraction de boites sur la fonction sinus Sur la figure précédente, la contrainte à respecter est sin. On remarque que l effet du contracteur est de réduire la taille des boîte sur lesquelles il est appliqué, jusqu à l ensemble vide si besoin. Il existe plusieurs algorithmes de contraction possibles. Le plus classique est l algorithme de «Forward-Backward», que l on peut illustrer avec des calculs à la main. Prenons, par exemple, le calcul suivant : Le but ici est de réduire les intervalles et par rapport à la contrainte. On va alors commencer par la partie «Forward» du calcul :

12 12 On peut ensuite, à partir du nouvel intervalle obtenu pour, réaliser la partie «Backward» du calcul : ( ) Figure 5 : Boîte initiale, puis contraction «Forward», et contraction «Backward» On a alors réduit les deux intervalles à et. Ce processus de «Forward- Backward» peut ensuite être répété un certain nombre de fois, jusqu à ce que les deux intervalles ne puissent plus être contractés. On dit alors qu on a atteint un point fixe. Cette méthode est facilement applicable à des calculs plus complexes, après avoir décomposé ceux-ci en un ensemble d opérations élémentaires réparties sur un arbre syntaxique. Ces méthodes de contraction, une fois qu elles sont implémentées dans l algorithme de SIVIA, améliorent considérablement le temps de calcul et la consommation en mémoire lors de la résolution d un problème par l analyse par intervalles. Figure 6 : Exemple d algorithme SIVIA amélioré. Ici, on a rajouté une étape de contraction sur [w] par rapport à une contrainte [z]

13 13 3- Utilisations dans le cadre de la Robotique mobile Les méthodes par intervalles ont déjà démontrées leurs efficacités dans le domaine de la robotique avec des applications telles que : - La reconnaissance et l extraction de formes géométriques dans une image, - L estimation de vecteurs d état pour un système non-linéaire, - La cartographie de l environnement dans lequel un robot évolue, ainsi que sa localisation (SLAM :Simultaneous Localization And Mapping). Il existe aussi d autres approches pour résoudre ces problèmes, cependant, en comparaison, les méthodes par intervalles ont des avantages non-négligeables. Ces méthodes sont tout d abord très robustes vis-à-vis des non-linéarités d un problème donné. En effet, l arithmétique classique nécessite souvent de linéariser un problème avant de pouvoir le traiter, ce qui n est pas le cas avec les intervalles. D autre part, les méthodes par intervalles peuvent prendre facilement en compte les incertitudes qui interviennent sur les variables d un problème, ce qui les rendent particulièrement utiles pour la résolution de problèmes sur des systèmes réels, souvent soumis à des perturbations (bruits des capteurs, incertitudes de pilotage ). Enfin, ces méthodes sont aussi utilisables en embarqué, avec des contraintes de temps réel, donnant ainsi de la robustesse aux algorithmes de guidage, de pilotage ou de navigation d un engin autonome.

14 14 Projet Bubbibex Le projet «Bubbibex» a débuté dans le cadre d une collaboration entre MBDA France et l ENSTA Bretagne sur l utilisation des méthodes ensemblistes. Il traite de la création d un programme en langage C++ de validation de la trajectoire d un robot décrit par ses équations d état. Considérer que la trajectoire d un robot est valide, revient à prouver qu à tout instant le robot ne s écarte pas trop de la trajectoire qui lui a été assignée, peu importe les perturbations qu il rencontrera. Cette problématique est très intéressante pour réaliser la planification de la trajectoire (préparation de missions) d un engin mobile, car elle permet d assurer la non-collision d un système autonome avec n importe quel obstacle présent dans son environnement, ou avec un autre système évoluant dans la même zone. Actuellement, cette validation de trajectoires s effectue à partir de méthodes probabilistes, comme par exemple avec la simulation d un certain nombre de scenarios possibles par tirage Monte- Carlo. L inconvénient de ces méthodes est qu elles ne peuvent pas traiter l intégralité des scénarios possibles pour un système autonome; il se peut alors qu un cas particulier, ne validant pas les critères de performance du système, ne soit pas évalué lors du tirage Monte-Carlo. Aussi, l intérêt des méthodes ensemblistes, en comparaison des méthodes classiques, est la garantie de la validation de l ensemble des scenarios possibles. 1- Principe du programme Si on considère un système défini par : - son vecteur d état ( : dimension du vecteur d état), - de sa fonction d évolution. Alors pour valider la trajectoire d un tel système, il faut tout d abord définir des critères de validation. Ces critères de validation peuvent s exprimer comme ceci : - Critère de Stabilité : Prouver que, peu importe les perturbations rencontrées, si ce système se trouve dans sa zone cible, alors il y restera sans en sortir, - Critère de Capture : Prouver que, si ce système se trouve hors de sa zone cible, alors il s y dirige. Dans les systèmes mécaniques ces critères sont souvent validés à partir d une fonction de Lyapounov. Un système est stable si tel que, on a. Cette condition traduit, en termes de physique, la stabilité de l énergie totale du système autour d un point d équilibre.

15 15 Figure 7 : Stabilité d un système dynamique autour d un point d équilibre Ici, le même principe sera utilisé avec une zone spatio-temporelle cible ayant la propriété de capturer le système. Cette zone sera appelée «bulle» ou encore tube de capture (projection sur le temps), et sera définie par la condition : Par la suite, pour nos applications, on se restreint au critère de stabilité uniquement. On introduit alors les concepts de trajectoire «Safe» et par extension de système «Safe». Si toutes les trajectoires d un système sont «Safe», c est-à-dire que pour des états initiaux elles valident toutes le critère de stabilité, alors ce système est considéré comme «Safe». Cependant, prouver que toutes les trajectoires d un système sont «Safe» n est pas facile. Ainsi, pour démontrer qu un engin autonome décrit par ses équations d état est «Safe», on montre qu il n existe aucune trajectoire «non-safe», c est-à-dire qu il n existe aucun état initial tel que pour, sort du tube de capture. En pratique, il suffit alors de prouver que pour tout, le système d équations suivant n admet aucune solution: { {. Dans notre cas, le critère de stabilité de Lyapounov tient compte de l évolution temporelle de la zone de capture (la «bulle») à travers le terme de dérivée temporelle de. Résoudre ce système d équations avec l arithmétique classique peut s avérer compliqué, notamment si il s agit de valider la trajectoire d un robot non-holonome, défini par des équations d état non-linéaires. L arithmétique par intervalles apparait alors comme une solution viable pour la

16 16 résolution de ces équations quel que soit le système présent en entré, car l application d un algorithme de type SIVIA va nous permettre d éliminer avec certitude tous les vecteurs d états initiaux correspondant à des trajectoires «Safe» pour garder seulement ceux qui conduisent à une trajectoire «Non-Safe». 2- Mise en place du programme a) Programmation avec Ibex L utilisation des méthodes par intervalles dans un programme en langage C++, nécessite des bibliothèques de fonctions bien spécifiques. La bibliothèque de fonctions Ibex, développée par M. Gilles CHABERT, enseignant aux Mines de Nantes, en collaboration avec M. Luc JAULIN et M. Jordan NININ enseignants à l ENSTA Bretagne, a été spécialement créée pour la résolution d équations ou d inéquations avec les méthodes par intervalles. Elle propose à la fois : - Un calculateur sur les Intervalles, - Une librairie de contracteurs, - Un Solveur/Optimiseur de systèmes de contraintes. La programmation et l utilisation des intervalles se font alors de manière très simplifiée au travers de cette librairie. Figure 8 : Déclaration d une fonction sur un Intervalle Figure 9 : Évaluation de l image d un Intervalle par cette fonction, et calcul de sa dérivée Figure 10 : Création d un contracteur Forward-Backward sur 3 Intervalles [x], [y], et [z]

17 17 Figure 11 : Utilisation du contracteur Figure 12 : Composition et Intersection de contracteurs b) Diagramme de Classe Les fonctionnalités du programme se devaient d être les suivantes : - Être utilisable pour différents systèmes définis par leur vecteur d état et leurs équations d état. o Description de la fonction d évolution dans un fichier f.txt que l on peut charger à partir du programme. o Description de la fonction cible dans un fichier g.txt que l on peut aussi charger à partir du programme. o Possibilité d utiliser entre 2 et 11 composantes pour définir le vecteur d état. - Être utilisable pour différents scénarios. o Possibilité de générer l équation d une trajectoire à suivre à partir des coordonnées de points de passage. Ces points de passage sont soit chargés à partir d un fichier de points de passage (générés par un programme tiers) ou rentrés manuellement dans l interface. - Avoir des paramètres de résolution du problème réglable. o Les intervalles initiaux pour chaque composante de sont ajustables : réglage des bornes et pour tout. o L intervalle de temps sur lequel la résolution doit être réalisée est réglable. o La largeur minimale des intervalles à bissecter lors du SIVIA est ajustable. - Afficher graphiquement les résultats obtenus. o Affichage dans une fenêtre graphique de la trajectoire à suivre ainsi que des résultats obtenus sur deux composantes de sous forme de pavage. o Affichage des résultats suivant l évolution temporelle du système entre et.

18 18 Le diagramme de classe du programme est alors de la forme suivante : Scenario String f, g List<double*> waypoints Void Load_f() Void Save_f() String CalcTarget() Repere Scene scene Void xtopix(double x, double y) Void DrawRobot(double x, double y, double angle, double taille) MainWindow Sivia sivia Repere R Scenario scenario IntervalVector x Void Init() Void OnPushRunClicked() Sivia Function f, g CtcFwdBwd ctc IntervalVector x Double[] eps_x List<IntervalVector> Sp, Sout Void InitSivia() Void RunSivia() Figure 13 : Diagramme de Classe de Bubbibex La classe Sivia contient l algorithme SIVIA, et est pilotée par la classe MainWindow. La classe Sivia communique avec la classe MainWindow pour accéder aux données du problème, comme par exemple la fonction d évolution du système, et elle lui renvoie ensuite les résultats obtenus après l utilisation de ses algorithmes. La classe MainWindow est le cœur du programme. Elle permet à l utilisateur d interagir avec le programme, via une interface graphique. L utilisateur peut alors spécifier la modélisation du système étudié, la trajectoire de référence à valider, les paramètres de résolution de l algorithme SIVIA pour enfin visualiser les résultats obtenus dans une fenêtre graphique dessinée grâce à la classe Repere. La classe Repere propose plusieurs méthodes utiles à la représentation des résultats obtenus, et surtout à leur compréhension. Enfin la classe Scénario charge (si elles existent) ou bien génère automatiquement les fonctions du système, et les équations de la trajectoire à suivre à partir des paramètres spécifiés par l utilisateur. Ces équations et fonctions sont ensuite sauvegardées sous forme de scripts (.txt) facilement accessibles pour la classe Sivia pour la résolution du problème et par la classe MainWindow pour l affichage du système modélisé et de la trajectoire à valider. Cette classe est pilotée par la classe MainWindow.

19 c) Interface graphique Intervalle de temps t Min t Max Fonctions f(x t), g(x t) et dg(x t) dt forme de scripts éditables sous Intervalles de départ pour chacune des composantes du vecteur d état Précision demandée pour la bissection des intervalles sur chaque composante du vecteur d état. Sauvegarde des paramètres et des fonctions choisies. Figure 14 : Réglage des paramètres pour la résolution d un problème donné (Bubbibex version finale) Ce document est la propriété de MBDA France. Il ne peut être communiqué à des tiers et/ou reproduit sans l'autorisation préalable écrite This document and the information contained herein is proprietary information of MBDA France and shall not be disclosed or reproduced

20 Temps de parcours total Nombre de points de passage utilisés MBDA France 20 Équations de la trajectoire à suivre (x d y d z d ), de sa dérivée temporelle (x dd y dd z dd )et de sa dérivée temporelle seconde (x ddd y ddd z ddd ). Ces équations sont générées à partir de méthodes de régression linéaire (cf. Projet Bubbibex 5.a. ) Validation des points de passage et génération des équations associées Coordonnées temporelles des points de passage (x y z t) Tracé de la trajectoire projetée dans le plan (x y), (y z), ou encore (x z) Figure 15 : Réglage des paramètres de la trajectoire à suivre Ici elle est générée à partir de points de passage rentrés manuellement (Bubbibex version finale)

21 21 Équations de la trajectoire à suivre (cf. Figure précédente). Nombre de points de passage sélectionnés dans le fichier (les n premiers), et temps de parcours associé. Chargement du fichier de points de passage. (cf. Annexes pour la forme du fichier chargé) Figure 16 : Réglage des paramètres de la trajectoire à suivre Ici elle est générée automatiquement à partir d un fichier de points de passage (cf. Annexes, Bubbibex version finale)

22 22 Récapitulatif des résultats de la résolution du problème par l algorithme SIVIA Temps de calcul Intervalles de départ (Vecteur d état + temps) Nombre de solutions trouvées. (solutions «Relatively safe», voir 4.a. Integration des solutions) Marges du tube enveloppe (cf. 4.a Intégration des solutions) Lancement de la résolution du problème avec l algorithme SIVIA Figure 17 : Affichage des résultats après la résolution du problème (Bubbibex version finale)

23 23 Options d affichage : - Tracé des solutions «Safe» - Tracé des solutions «Relatively safe» (cf. 4.a) - Tracé de la trajectoire à suivre - Tracé des dynamiques pour chacune des solutions (cf. Figure suivante) Tracé d une trajectoire solution à partir d un état initial X(0) G(0) pris au hasard. Barre d avancement sur le temps. Permet de voir l évolution temporelle des solutions sur t Min t Max Figure 18 : Affichage graphique des résultats après la résolution du problème (Bubbibex version finale)

24 24 3- Cas de test et d utilisation Tout au long du projet, le programme a été utilisé dans des cas de validation de trajectoire pour 3 Robots différents. Le premier robot, est un modèle très simplifié de robot terrestre holonome. Ce modèle dont le comportement est complètement connu, a principalement permis de régler les bugs de programmation. Le second robot terrestre et non-holonome, a servis en tant que modèle de référence pour comparer les performances de calculs de chacune des améliorations proposées. Enfin, le second robot, est un modèle de robot aérien non-holonome simplifié qui a permis de valider les performances du programme pour la validation de la trajectoire d un robot plus complexe. a) Robot terrestre holonome Comme précisé précédemment, le robot holonome est défini dans le but de pouvoir détecter les bugs de programmations du programme. Son état est caractérisé par les coordonnées de sa position dans le plan et par l angle de son cap. Ainsi son équation d évolution est de la forme, Celle-ci le force à suivre la droite d équation, avec des commandes non-bornées. Ce système est idéal pour tester la cohérence des résultats fournis par Bubbibex car le comportement de ce robot est déterministe. Aussi en théorie ce robot ne peut pas s écarter de la trajectoire fixée, et ne doit donc présenter aucune solution «non-safe». La fonction cible choisie correspond à une «Bulle» définie par les critères suivants : - Le robot doit être dans un cercle centré sur de rayon. - Le cap du robot doit se trouver dans un cône d axe dirigé vers la position désirée à l instant suivant, et de base de largeur. { ( s ) sin Figure 19: La "Bulle" à respecter est décrite par un cercle et un cône

25 25 b) Robot terrestre non-holonome Le robot non-holonome a été défini dans le but de comparer les performances des différentes améliorations proposées pour le programme. C est un robot de référence, dont le modèle d état simule un comportement plus proche de celui de robot terrestre réel. Ses variables d état sont les coordonnées de sa position dans le plan (en mètres), et l angle de son cap (en radians). Aussi son équation d évolution s écrit, (. s. sin) Si on considère un point de coordonnées à atteindre au temps, alors on peut définir les consignes du robot comme ceci : x X ( y) θ V x y Soit Et sin n ( x d x y d y ) Δθ U n X d X d (x d y d ) X d (x d y d ) Figure 20 : Évolution du robot terrestre non-holonome dans le plan lors du suivi d une trajectoire De même que pour le robot terrestre holonome, la fonction cible pour ce système correspond à une «Bulle» définie par un cercle de rayon centré sur la position à suivre et par un cône dirigé suivant et de base. L équation de la fonction cible choisie peut alors s écrire de la manière suivante, { ( s ) (sin ) ave la dire ti n vis e Figure 21 : La «bulle» à respecter par le robot terrestre non-holonome est décrite par un cercle et un cône

26 26 c) Robot aérien non-holonome Enfin, afin de tester les performances en termes de temps de calculs et d occupation de mémoire du programme, un modèle simplifié d engin aérien autonome a été créé. Celui-ci est défini par les variables d états suivantes : - : coordonnées de la position du robot dans l espace (en mètres). - : angle de gisement du robot dans l espace (en radians). - : angle de site du robot dans l espace (en radians). k j u u x z 0 φ θ u y i Figure 22 : Représentation du robot aérien non-holonome dans l espace Comme nous pouvons le remarquer, l angle de roulis et le vecteur vitesse (en coordonnées sphériques) ne sont pas pris en compte comme variables d état du système. Ce choix a été fait dans le but de limiter le nombre de variables pour la résolution de l algorithme SIVIA, il fera l objet d une discussion dans les parties suivantes. Aussi, l équation d évolution du système s écrit,.. s. sin.. { De même que pour le robot terrestre non-holonome, nous allons considérer un point à atteindre à l instant. Dans ce cas les différentes consignes, et seront définies de la manière suivante :

27 MBDA France sin - sin. avec. avec. avec et et (. ). k x V ( y ) z U n X d x d X d ( y d ) z d j x z n ( x d y d z d x y) z X d (x d y d z d ) 0 φ θ y i Figure 23 : Suivi d une trajectoire pour le robot aérien non-holonome De manière similaire aux deux précédents robots, la fonction cible pour ce système correspond ici à une «Bulle» définie par une sphère de rayon centrée sur la position désirée et par un cône dirigé par et de base le cercle de rayon. L équation de la fonction cible choisie peut alors s écrire de la manière suivante, ( s ) (sin ) ( s ) (sin ) { ave la dire ti n vis e

28 28 Cette fonction cible peut être illustrée par la figure suivante, x X ( y) z Cône de base le cercle de rayon r U n X d r Figure 24 : «Bulle» pour le robot aérien non-holonome. Sa position doit se trouver dans la sphère (rouge) et sa vitesse d avance doit se trouver dans le cône (noir) 4- Problèmes rencontrés et modifications apportées Les trois systèmes présentés précédemment ont permis en premier lieu, de détecter certains bugs relatifs à la programmation de l algorithme et à la méthode initiale de résolution employée, puis en second lieu de relever les améliorations qui pouvaient être apportées à l algorithme du SIVIA et à la structure générale du programme. De manière générale, les principaux bug et améliorations possibles étaient les suivantes : - Les solutions trouvées semblent parfois incohérentes avec la théorie. Par exemple, sur la figure ci-dessus des solutions sont trouvées pour le robot terrestre holonome, dont le comportement déterministe ne devrait pas en permettre l existence. D autre part, les dynamiques moyennes des solutions (flèches noires) montrent bien que ces solutions donneront des trajectoires non-divergentes (trajectoire à suivre ). Figure 25 : Solutions trouvées pour le robot terrestre holonome

29 29 - Les solutions trouvées sont souvent des configurations pour lesquelles le robot rentrera dans la «bulle» lors du pas de temps suivant. Par exemple on observe sur la figure suivante que si l on trace l évolution (triangles rouges) d une des solutions trouvées (triangle bleu) pour le robot terrestre non-holonome, on remarque alors que celle-ci ne diverge pas de la trajectoire assignée (tracée en rouge). Figure 26 : Exemple d évolution rentrante pour le robot terrestre non-holonome - La précision demandée pour la bissection des intervalles a un impact non-négligeable sur le nombre de solutions trouvées. Si celle-ci est faible, c est çà dire que la largeur minimale des intervalles à bissecter est faible, alors le nombre de solutions trouvées diminue. Mais, en contrepartie, le temps de calcul et la quantité de RAM occupée augmentent aussi considérablement. Aussi, comme nous pouvons le voir sur la figure suivante, pour un même problème résolu avec des précisions de bissection différentes (epsilon =... ), le nombre de solutions diminue jusqu à une certaine limite («Unsafe boxes»), mais le nombre de boîtes calculées et le temps de calcul explosent. Figure 27 : Trois résolutions du robot terrestre sur la même trajectoire avec des précisions différentes (en Bleu). Aussi pour résoudre ces problèmes, plusieurs améliorations et corrections ont été proposées au cours du stage, et notamment grâce au projet Ellibex développé en parallèle (cf. Partie Projet Ellibex). Les principales améliorations et corrections apportées au programme Bubbibex et à l algorithme du SIVIA sont les suivantes : - Correction du problème de dérivation automatique de la fonction du programme. - Ajout d un processus d intégration au sein de l algorithme SIVIA afin d éliminer toutes les solutions amenant à une trajectoire rentrante dans la «bulle».

30 30 - Amélioration de la vitesse de calcul et de la consommation de mémoire du programme. o Utilisation de «Threads» pour la parallélisation des calculs. o Utilisation de stratégies de bissection différentes. - Prise en compte des incertitudes des modèles à partir d une inclusion différentielle. a) Évolution temporelle de la bulle La figure 23 représente les résultats obtenus pour le robot holonome sur une ligne droite. Ces résultats sont premièrement incohérents vis-à-vis du comportement déterministe de ce modèle de robot holonome (cf. partie 3.a), et deuxièmement incohérent vis-à-vis de la dynamique des solutions (flèches noires), ce qui montre bien que celles-ci ne divergent pas de la trajectoire. Il semble alors que ce problème d incohérence des résultats est dû à l équation (1) utilisée pour trouver les solutions amenant à des trajectoires «Non-safe» pour le système : { {. À la suite de cette remarque, je me suis particulièrement intéressé à la condition traduisant la sortie du tube de capture d un système dont l évolution est décrite par l équation. En termes de géométrie, cette condition peut être comparée à un produit scalaire entre la normale à la bulle et la fonction d évolution. En conséquence cette condition permet de trouver tous les états du système qui n évoluent pas dans le même sens que la bulle et qui, par conséquent, en sortent. Aussi, jusqu à présent les dérivées partielles et étaient obtenues automatiquement avec une fonction de la librairie Ibex. Ce qui nous donnait, pour le robot terrestre holonome, le résultat suivant, { ( s ) sin { { Ce résultat, est incohérent, car il traduit que cette «bulle» décrite par la fonction n évolue pas dans le temps. En réalité le vecteur d état du système dépend du temps, et, donc il faut en tenir compte lors de la dérivée temporelle de.

31 31 Rectifier ceci est revenu à créer un nouveau script de fonction ( ) dérivant «à la main» la fonction, et à remplacer ainsi l équation (1) de l algorithme par: en {. ( ) Ainsi avec ce nouveau script de dérivée temporelle, comme on peut le remarquer sur la figure suivante, l algorithme ne trouve plus aucune solution pour le modèle de robot holonome, ce qui est cohérent avec la théorie, Figure 28 : Aucune solution trouvée pour le robot holonome sur une trajectoire en ligne droite (y=0) b) Intégration des Solutions Comme on a pu l observer sur les exemples précédents (Figure 24), lorsque l on intègre certaines solutions trouvées à partir de la fonction d évolution, elles sortent souvent de la «Bulle» pour y entrer de nouveau aux instants suivants. Figure 29 : Les solutions intégrées rentrent à nouveau dans le tube de capture, en s écartant d une certaine distance de celui ci. Aussi, un moyen d écarter des solutions trouvées par le programme est de les intégrer afin de vérifier que celles-ci sont bien rentrantes ou non-rentrantes à un horizon de temps donné. Ces solutions réentrantes, qualifiées alors de «Relatively Safe», s écartent d une certaine distance du tube de capture. Cette distance ou marge de manœuvre, va permettre de définir ce que l on appelle un tube «enveloppe» (représenté sur la figure suivante), qui prendra en compte l impossibilité du système à parfaitement suivre une trajectoire présentant par exemple des virages

32 32 trop serrés (ou simplement le fait que l on ne va pas assez loin dans le processus de bissection lors de la résolution avec l algorithme SIVIA). Tube enveloppe Figure 30: Tube enveloppe Ainsi, pour définir le tube «enveloppe», il faut montrer que les solutions trouvées à l instant, une fois intégrées sur pas de temps, retournent dans la bulle définie à l instant.. Or le problème majeur du processus d intégration sur les intervalles ou vecteurs d intervalles, est la surapproximation de la solution trouvée. Si on utilise la méthode d Euler pour évaluer à l instant suivant le vecteur d état du système, on a : X t X t dt [X ] t dt g(x t) g(x t dt) Figure 31 : Sur-Approximation lors de l intégration ave [ ] une estim e de telle ue [ ] Ainsi, après intégration, pourrait être inclus dans la bulle, mais souvent son estimée [ ] ne permet pas de le vérifier car une partie se trouve à l extérieur de cette «bulle». En effet, la largeur d une ou de plusieurs composante(s) de l estimée peut être supérieure à la largeur définie par «Bulle», à cause des approximations dû au schéma d intégration d Euler, accentuées ici par l utilisation de l arithmétique des intervalles. Pour contourner ce problème, une méthode d intégration «Forward-Backward» a été mise en place. On cherche à montrer que, avec l ensemble formé par la condition. Si l on inverse le problème, il s agit alors de montrer que le système suivant n admet aucune solution :

33 33 { La résolution de l équation (2) peut alors se faire avec une technique combinant une intégration «Forward-Backward» et un contracteur éliminant la partie des boîtes intégrées situé à l intérieur de la «Bulle». Aussi sur chacune des boîtes de type solution le processus suivant est réalisé, [X ] t ext Intégration «Backward» Contraction X t ext X t Intégration «Forward» ext [X ] t dt [X ] t dt g(x t) g(x t dt) Figure 32 : Forward-Backward sur l intégration et contraction. Cette méthode est utilisée au cœur de l algorithme SIVIA, et permet d éliminer beaucoup de solutions rapidement. Ainsi, cette méthode permet d écarter toutes les solutions pour le robot terrestre holonome, et le robot terrestre non-holonome en ligne droite, avec des temps de calcul relativement courts. Cependant, si l on considère des trajectoires un peu plus complexes, alors le temps de calcul explose rapidement, ce qui rend le programme toujours inexploitable. D autre part, cette méthode va aussi nous permettre de caractériser le tube «enveloppe» sur-approximé du problème, en calculant pour chacune des solutions intégrées les valeurs maximales des composantes de la fonction. Ces valeurs seront appelées marges maximales de la «Bulle» Figure 33 : En gris, les boîtes éliminées par intégration et en Jaune, les solutions restantes

34 34 Comme on peut le constater sur la figure précédente, pour le robot terrestre non-holonome, cette méthode a permis d éliminer beaucoup de solutions (en gris). Cependant il subsiste encore des solutions non éliminées (en jaune), et d autre part, les marges maximales du tube «enveloppe» sont plutôt importantes, ce qui laisse supposer que la trajectoire demandée est trop difficile à suivre pour le contrôleur proposé dans le modèle de ce robot. Enfin, étant donné que cette méthode permet d éliminer au cœur de l algorithme SIVIA les boîtes dont la trajectoire intégrée est prouvée rentrante dans le tube de capture, le temps de calcul et l occupation de la RAM du programme se trouvent considérablement améliorés. Aussi, comme on peut le constater sur la figure suivante, pour le robot terrestre non-holonome la méthode d intégration permet d être environ 2 fois plus rapide («Ellapsed time»), et d avoir à calculer environ 2 fois moins de boîtes («Number of boxes)» pour valider la même trajectoire. Figure 34 : Comparaison temps de calcul et nombre de boîtes calculées sans la méthode d intégration (à gauche) et avec la méthode d intégration (à droite) c) Accélération de la résolution Malgré les améliorations et les corrections apportées précédemment, la contrainte principale dans l utilisation de ce programme est le temps de calcul. Pour un problème donné, si l on diminue par deux la précision de bissection demandée, on peut souvent multiplier par 100 le temps de réponse du programme. Ceci est principalement dû à la complexité, dite exponentielle, de l algorithme Sivia : chaque boîte traitée est bissectée en deux boîtes différentes qui seront aussi à traiter postérieurement. Pour contourner ce problème, deux solutions majeures ont été mises en place. La première consiste à paralléliser les calculs en utilisant des «threads». Elle se révèlera particulièrement efficace au regard de la structure facilement parallèlisable de l algorithme Sivia. Enfin, la deuxième méthode utilisée consiste à changer de type de bissecteur afin de couper les boîtes suivant la composante la plus intéressante pour le contracteur utilisé.

35 35 i- Parallélisation des calculs Les «threads» sont des processus légers fonctionnant en parallèle au sein d un même processus. L utilisation des «threads» permet notamment de paralléliser le traitement de calculs intensifs, ce qui rend l exécution de ces calculs bien plus rapides sur des machines avec un processeur multi-cœurs. La structure de l algorithme SIVIA permet d utiliser aisément ces techniques dans le but d accélérer la résolution des calculs sur les boîtes. Concrètement, lorsque l algorithme a traité une boîte, soit par il la stocke dans une des listes ou, soit il la bissecte en deux boîtes différentes. Dans le deuxième cas, les deux boîtes obtenues sont alors rajoutées à la liste des boîtes à traiter successivement par le SIVIA. Cependant l ordre dans lequel seront traitées ces deux boîtes n a aucune importance ; leur intersection étant nulle, les résultats donnés par le contracteur puis par le bissecteur du SIVIA pour chacune de ces deux boîtes ne sont pas corrélés. Il est alors concevable de résoudre un problème en bissectant la boîte initiale en plusieurs boîtes différentes qui seront traitées par autant d algorithmes SIVIA exécutés sur des «threads» en concurrence. Les résultats donnés par chaque SIVIA devront ensuite être mis en commun pour accéder à toutes les solutions du problème. X X Sivia Sivia Sivia X X 4 Sivia Boite initiale bissectée en 4. Chaque sous-boite est allouée à un «thread» différent. Les résultats donnés par les «threads» sont mis en commun, puis affichés Figure 35 : Principe d utilisation des threads pour paralléliser les calculs La figure précédente présente le principe suivant lequel sont utilisés les «threads» au sein du programme Bubbibex. En théorie, cette méthode permet de diviser par 4 le temps de calcul pour un problème donné. Cependant, en pratique, certains «threads» arrivent à conclure beaucoup plus rapidement que d autres. Ceci a pour conséquence de ralentir le programme sur les phases de fin de calculs car un «thread» seul est doté d une puissance de calcul plus limitée que celle dont peut bénéficier un processus. Pour limiter ce problème, une méthode de redistribution des boîtes à traiter a été mise en place. Ainsi, lorsque 3 «threads» sur 4 ont terminé leur travail, le programme arrête le dernier «thread», récupère la liste des boîtes encore à traiter par ce dernier, les répartit entre eux et les relance tous en même temps. Cette logique d utilisation des «threads» n est cependant pas optimale, car la vitesse d exécution de chaque «thread» dépend du problème traité et il peut y avoir

36 36 dans certains cas plus d un «thread» limitant. En conséquent, dans le cas d une possible implémentation sur des structures multi-cœurs, cette logique pourrait être fortement améliorée, augmentant en conséquence considérablement les performances de l algorithme SIVIA pour la résolution de n importe quel problème. Figure 36 : Temps de réponse pour le Robot holonome sans «thread» (à gauche) puis avec 4 «threads» (à droite) Comme nous pouvons le remarquer sur la figure précédente, le temps de calcul a été globalement divisé par 4 (Ici l ajout de la méthode d intégration entre les deux versions de Bubbibex fausse un peu la comparaison). Ainsi, l utilisation des «threads» a énormément apporté en termes de performances pour l algorithme SIVIA et a ouvert la voie à l utilisation des méthodes par intervalles pour des applications en temps réel à partir d architectures massivement parallèles, comme par exemple les cartes multiprocesseurs utilisables avec la librairie OpenCL. Cependant ceci posera surement un problème de compatibilité et de portabilité avec la librairie Ibex. ii- Changement de Bissecteur La deuxième approche utilisée pour diminuer le temps de calcul a été l utilisation d autres méthodes de bissections au cœur de l algorithme SIVIA. Cette approche m a été proposée par M. Jordan NININ, enseignant à l ENSTA Bretagne, à la suite d une remarque de ma part concernant le nombre important de boîtes traitées pour le cas simple du robot holonome. On ne peut bissecter une boîte que suivant une seule dimension, et il existe plusieurs manières de bissecter cette boîte au cours d un Sivia, dont celles décrites ci-dessous : - La bissection «tour-à-tour», ou «round-robin», qui consiste à couper les boîtes successivement sur les dimensions. - La bissection basée sur un critère de largeur des intervalles d une boîte. - La bissection basée sur un critère de fonction objectif à minimiser. L utilisation d une règle de bissection plutôt qu une autre va influencer considérablement l action du contracteur utilisé dans l algorithme Siva, et ne donnera en général pas exactement les mêmes résultats car l ensemble solution sera décrit par des boîtes différentes (forme, précision, ).

37 37 La stratégie de bissection utilisée précédemment était basée sur un critère de minimisation de la largeur maximale des intervalles décrivant la boîte. Prenons une boîte, avec respectivement les précisions demandées sur chacun des intervalles qui la composent. Alors cette stratégie, appelée «Maximum Width», peut s exprimer de la manière suivante : ave lar eur de l intervalle Il suffit alors de bissecter cette boîte suivant l intervalle pour lequel la valeur est la plus grande Cette méthode est très simple à mettre en place, et présente un critère de bissection rapide à calculer, cependant elle est loin d être la plus efficace. Méthode 1 : «Maximum Width» Méthode 3 : nécessite 74% de bissections en moins en comparaison avec la méthode 1 (meilleure méthode) Figure 37 : Tableau récapitulatif des résultats obtenus par M. CSENDES et M. RATZ : nombre total de bissections réalisées par 4 méthodes de bissection pour la résolution de 25 problèmes différents. La figure précédente, montre une partie des résultats obtenus par M. CSENDES et M. RAZT [3] lors de la comparaison de 4 méthodes de bissection sur 24 fonctions de test d optimisation (Fonction d optimisation de Shekel, Hartmann, Goldstein-Price, Branin, ). Compte tenu des résultats obtenus, j ai décidé de choisir la troisième méthode dite «Maximum Smear» (résultats colonne 3 sur la figure précédente). Cette méthode de bissection repose sur une fonction de «mérite» qui permet de choisir la composante à bissecter sur une boîte. Concrètement, cette fonction est issue du contracteur utilisé, et permet d optimiser son action sur les deux boîtes obtenues après bissection. La règle «Maximum Smear» s exprime alors comme ceci : ( ( ) Avec la composante du gradient de la fonction de «mérite», et la valeur médiane de l intervalle. Figure 38 : Comparaison entre le nombre de boîtes traitées avec la méthode «Maximum Width» (à gauche) et la méthode «Maximum Smear» (à droite) (Robot terrestre non-holonome).

38 38 Comme on peut le constater sur la figure précédente, le nombre de boîtes traitées a été divisé par deux avec la nouvelle méthode de bissection, ce qui a réduit de manière significative le temps de réponse du programme. Cependant, la méthode «Maximum Smear» est souvent difficile à mettre en place. D une part, parce qu il faut trouver une fonction de «mérite» adaptée à la situation, et d autre part, car celle-ci peut aussi augmenter le temps de calcul si elle est trop compliquée à calculer à chaque tour du Sivia. d) Résultats obtenus Afin de montrer l efficacité du programme Bubbibex pour la validation d une trajectoire, nous allons comparer la validation de deux trajectoires différentes assignées au robot terrestre holonome. Figure 39 : Les deux trajectoires à valider avec Bubbibex pour le robot terrestre non-holonome Comme nous pouvons le constater sur la figure précédente, les deux trajectoires présentent une suite de deux virages. Cependant sur la deuxième trajectoire, les rayons de courbure des deux virages sont beaucoup plus faibles que pour la première, ce qui doit la rendre plus difficile à suivre pour le robot. Les résultats obtenus lors de la validation de la première trajectoire sont présentés dans les figures suivantes,

39 39 Figure 40 : Résultats obtenus pour la première trajectoire à valider Comme nous pouvons le constater sur la figure précédente, aucune solution «non-safe» (Unsafe boxes) a été trouvé pour cette trajectoire, cependant beaucoup de solutions ayant nécessité une intégration ont été trouvées (Relatively Safe boxes). Ces solutions «Relatively Safe» sont affichées en gris sur la trajectoire, et nous pouvons alors remarquer qu elles sont seulement présentes dans les virages de la trajectoire de référence. Elles peuvent alors être interprétées comme un signe montrant que le contrôleur mis en place dans le modèle de robot ne lui permet de suivre proprement la trajectoire qui lui est assignée. En conséquence, cette faiblesse du contrôleur devrait poser des problèmes lors de la validation de la seconde trajectoire. Figure 41 : Résultats obtenus pour la seconde trajectoire à valider

40 40 Comme le montre la figure précédente, la deuxième trajectoire n est pas validée par le programme, car des solutions «non-safe» ont été trouvée (pour des mêmes paramètres de résolution). Le tracé de ces solutions va alors nous permettre de mieux comprendre pourquoi cette trajectoire n est pas «Safe», Figure 42 : Affichage des solutions trouvées pour le premier, puis le second virage de la Trajectoire 2 On peut alors voir sur les deux figures précédentes, que les solutions trouvées correspondent à des configurations dans lesquelles le robot est incapable de suivre la suite de virages proposée de la trajectoire de référence. Comme nous l avions remarqué sur la trajectoire précédente, ceci est surement dû au contrôleur utilisé pour le robot, incapable de suivre une succession de virage. D autre part, nous pouvons aussi remarquer que les marges calculées pour les deux trajectoires sont assez importantes ; elles donnent des tubes enveloppes de rayons maximum respectivement égaux à environ 28m et 31m. Il faut toutefois, prendre ces résultats comme étant des sur-approximations des marges de manœuvre réellement nécessaires au robot pour revenir dans sa «bulle». Nous pouvons cependant nous rapprocher des marges réelles maximales de manœuvre du robot en demandant des précisions de bissection des intervalles par le SIVIA plus faibles. En contrepartie ceci augmente considérablement le temps de résolution de l algorithme, comme le montre les résultats suivant, obtenus lors la validation de la première trajectoire avec des précisions de bissections divisées par 10 sur les intervalles des variables d état du robot terrestre non-holonome.

41 41 Figure 43 : Résultats obtenus pour la validation de la trajectoire 1 avec des précisions de bissection des intervalles divisées par 10 Ainsi, sur la figure précédente, nous pouvons observer que les marges obtenues lors du nouveau calcul de validation de la première trajectoire, sont plus faibles que celles obtenues précédemment (rayon maximal du tube de capture environ égal à 24m). Ces simulations valident donc l utilisation de Bubbibex pour des problématiques de validation de trajectoires planifiées. D autre part, Bubbibex peut aussi apporter un critère de performance du contrôleur pour le suivi de trajectoire d un engin autonome, car il peut aider à détecter les difficultés du contrôleur à suivre les passages complexes d une trajectoire (comme par exemple, dans les virages des deux trajectoires précédentes). 5- Planification de mission Les résultats obtenus avec le programme Bubbibex sont encourageants, notamment vis-à-vis d une possible implémentation des algorithmes utilisés dans un logiciel de planification de mission existant. Cependant, il faut tout d abord montrer que ce programme et ces algorithmes peuvent être intéressants dans ce contexte. Aussi, une version allégée du programme Bubbibex a été créée dans le but de pouvoir être appelé par un logiciel de planification de mission, pour valider un tube de capture autour de la trajectoire de vol fournie par celui-ci. a) Adaptation du programme Bubbibex Ce logiciel de planification de mission, permet de générer une trajectoire de vol pour un engin aérien autonome. Cette trajectoire est optimisée en prenant en compte le relief du terrain et des contraintes de zones aériennes à ne pas survoler, pour être la plus proche possible du sol. Cependant, ce logiciel utilise seulement des méthodes probabilistes pour réaliser cette optimisation de trajectoire. Aussi, les méthodes ensemblistes utilisées dans le programme Bubbibex pourraient apporter des informations complémentaires aux résultats du programme, en validant avec certitude la trajectoire proposée comme étant «Safe».

42 42 Figure 44 : Carte numérique de terrain et trajectoire planifiée sur le logiciel MBDA En premier lieu, je me suis intéressé à la validation de la trajectoire pour le modèle simplifié de robot aérien non-holonome défini dans la partie 3.c. Ce modèle est très simplifié car il considère l engin aérien comme un point matériel défini par les variables d états et les équations d états suivantes : - : position du robot dans le repère terrestre ( ) (Est-Nord-Haut). - : Angle de cap du robot. - : Angle d assiette du robot... s. sin.. (.. ) L intérêt premier de ce modèle était de pouvoir tester le programme Bubbibex sur la validation d une trajectoire dans l espace, sans trop surcharger la résolution de variables pour avoir des temps de réponse corrects. Cependant, nous nous sommes rendus compte plus tard que les méthodes précédemment mises en place permettent d obtenir des temps de réponse corrects, et d envisager l utilisation de Bubbibex sur des modèles d états plus complexe. Dans un premier temps, le programme Bubbibex a été amélioré afin de pouvoir prendre en compte une trajectoire définie par des coordonnées temporelles ( ) des points de passage. Aussi une méthode de régression polynomiale pour estimer l équation paramétrique de la trajectoire à partir de ces coordonnées a été implémentée. Cette méthode était nécessaire pour utiliser les méthodes par intervalles sur cette trajectoire. {

43 43 Figure 45 : Exemple d équations décrivant la trajectoire à suivre par un système Comme on peut le constater sur la figure précédente, les équations générées sont sous la forme de polynômes. En réalité, l ensemble des points ( ) sont utilisés pour calculer avec les méthodes de régression polynomiale, les coefficients des polynômes et dont le degré (ici 3) a été fixé à l avance. À partir de ces coefficients il est ensuite aisé de calculer la dérivée temporelle de la trajectoire ( ) et sa dérivée seconde ( ) qui sont aussi des fonctions polynomiales. b) Résultats obtenus En considérant la trajectoire suivante issue du programme de planification de mission, et parcourue par l engin aérien durant 1seconde, nous avons : Figure 46 : Régression linéaire réalisée pour construire la trajectoire à partir des points de passage récupérés.

44 44 Figure 47 : Validation d un morceau de trajectoire (1s) par la version simplifiée du programme Bubbibex (Console) Figure 48 : Validation d un morceau de trajectoire (10s) par la version simplifiée de Bubbibex (Console) Nous pouvons alors remarquer que, malgré le nombre de variables d état à traiter par l algorithme Sivia (5 variables d état et le temps), et la longueur de la trajectoire à valider (1 seconde, et 10 secondes) le temps de réponse du programme est relativement correct, ce qui laisse envisager une bonne intégration du programme dans le logiciel. D autre part, on peut aussi remarquer que les marges définissant le tube enveloppe augmentent lorsque le morceau de trajectoire à parcourir est plus long, ce qui nous pousse à comparer les valeurs de ces marges avec les dépassements de trajectoire que l on pourrait observer avec des simulations de Monte-Carlo (tirage d état initial aléatoire et intégration de la trajectoire). Figure 49 : Chevelu de trajectoires issu d un tirage de positions initiales aléatoires situées dans la «bulle»

45 45 La figure précédente illustre 20 trajectoires possibles d un même système essayant de suivre la trajectoire assignée (en rouge) et dont les positions initiales ont été tirée aléatoirement telles que. On remarque que conformément aux résultats fournis par Bubbibex, il n existe aucune trajectoire «non-safe», et qu il existe aussi certaines trajectoires s éloignant de la trajectoire de référence, mais qui reviennent au cours du temps. L écart maximal enregistré entre les trajectoires et la trajectoire de référence est de 4.12mètre, ce qui est inférieur à la marge maximale fournie par Bubbibex sur cette même trajectoire de référence (écart maximal de environ mètres). Ceci valide donc les résultats fournis par Bubbibex. c) Voies d améliorations De nombreuses améliorations sont encore possibles pour que les résultats fournis par Bubbibex soient totalement exploitables dans des problématiques de planification de missions. Tout d abord, le modèle d état décrivant l engin aérien peut être affiné en introduisant par exemple de nouvelles variables d état telles que les angles d incidence et de dérapage de l engin, ou encore en introduisant une loi de guidage en navigation proportionnelle. D autre part, la régression linéaire utilisée pour décrire les équations paramétriques de la trajectoire de références peut amener à lisser la trajectoire et à trop l approximer. Ceci peut aussi amener à une résolution faussée du problème, car les zones où la trajectoire peut être trop difficile à suivre, ne seront pas forcement bien représentées par ces équations. Enfin, la logique de parallélisation des calculs pourrait être approfondie, notamment avec des architectures «multithreads», dans le but d avoir un outil qui n handicape pas le temps de calcul du logiciel de planification de missions.

46 46 Projet Ellibex Le projet Ellibex a été mis en place pour répondre à la problématique suivante : Comment valider la trajectoire de robots qui effectuent des patrouilles autour de zones stratégiques, et assurer la non-collision de ces robots entre eux, ou avec un élément de l environnement. Cette problématique intervient dans le cadre d un projet traitant de scenarios d aide à la prise de décision pour la défense de points d intérêts par des bateaux patrouilleurs autonomes. Figure 50 : Exemple de scénario ; défense des iles de Hawaï par trois bateaux patrouilleurs 1- Principe du programme Ce programme a été créé dans une optique de planification de patrouilles autours de points stratégiques. Il permet dans un premier temps de valider les trajectoires de patrouilles de 3 robots, comme étant «Safe», puis dans un deuxième temps de valider la non-collision entre les robots, en prenant compte des incertitudes de navigation pour chaque robot (marges de manœuvres). Les équations utilisées pour décrire l évolution des robots sont celles décrites précédemment pour le robot terrestre non-holonome (cf. partie Projet Bubbibex, 3.b.). Aussi chacun de ces robots se voit attribuer un chemin de ronde, qui sera validé de la même manière que dans le programme Bubbibex. À la suite de quoi, le programme calcule toutes les intersections possibles entre les bulles validées avec leurs marges. Pour cela, j ai utilisé la méthode par intervalles des Q-intersections (cf. 1.b). a) Incertitudes de pilotage Les trajectoires à suivre sont plutôt simples, et dans le cas d un robot idéal, ne pose aucune difficulté pour être suivies. Cependant le but final de ce programme est de pouvoir appliquer les résultats obtenus sur des robots réels (Wifibots). Pour prendre en compte les imperfections de ces robots, qui peuvent intervenir sur le guidage, la navigation (estimations de la position, biais de capteurs ) ou encore le pilotage (roues qui patinent, ), on utilise une inclusion différentielle pour décrire la dynamique du robot.

47 47 Si on considère un système avec l équation d évolution, utiliser l inclusion différentielle sur ce système revient à changer cette équation par. Ceci permet de considérer, à la place d une seule évolution, un ensemble d évolutions réalisables par le robot à l état. Ceci change alors en partie la méthode de validation de la bulle. On cherche maintenant tous les états possibles du robot se trouvant à la frontière de la bulle, et dont au moins une des évolutions possibles le ferait sortir de la bulle. (X t) F(X t) (X d t) Figure 51 : État «non-safe» du robot, car au moins une de ses évolutions possibles sort de la bulle Pour prendre en compte l inclusion différentielle dans la résolution d un problème de validation de trajectoire, il suffit de résoudre le système d équation suivant : {. [ ] En pratique la fonction est créée à partir de la fonction d évolution du système, à laquelle on vient ajouter un vecteur d incertitudes qui dépend des caractéristiques du système réel. b) Q-Intersections De manière théorique, la q-intersection entre sous-ensembles de l ensemble de vecteurs d intervalles I, est l ensemble des appartenant à au moins un nombre de boîtes. La q-intersection est alors décrite par ;

48 48 Figure 52 : Q-intersections de 6 sous-ensembles de I, pour (en Rouge), (en Vert), (en Bleu) et (en Jaune) Calculer les Q-intersections des sous ensembles de I, revient alors à poser un problème d inversions d intervalles, résolu avec une méthode de Sivia avec contracteurs, en définissant la fonction suivante, Cette méthode des Q-Intersections est couramment utilisée en robotique mobile pour des problématiques de localisation de robots à partir de points de référence (Amers). Par exemple, elle permet d obtenir la ou les zone(s) dans le(s)quelle(s) peut se trouver un robot à partir de mesures de distances entre ces amers et le robot, avec leurs incertitudes et la présence potentielle de mesures aberrantes. d D Amer Amer D Amer d D d Figure 53 : Zones (en rouge) dans lesquelles peut se trouver un robot dont les distances entre lui et chaque amers sont comprises entre et. Dans le cas présenté, les zones sont calculées en prenant au moins un des amers comme aberrant. D autre part, la méthode des Q-intersections est déjà implémentée dans la bibliothèque Ibex avec une très bonne vitesse d exécution. Ainsi, dans notre cas il a juste suffit de considérer les centres des bulles de chacun des robots à l instant t comme des «Amers», avec des distances nulles et égales au dépassement maximal (marges) de chaque bulles.

49 49 2- Mise en place a) Diagramme de Classe Les fonctionnalités du programme se devaient d être les suivantes : - Être utilisable pour un seul type de robot fixé (robot 2D non-holonome). o Description de la fonction d évolution de chaque robot dans un fichier fi.txt généré automatiquement par le programme, en tenant compte de la trajectoire de patrouille qu il doit suivre. o Description de la fonction cible de chaque robot dans un fichier gi.txt généré aussi automatiquement par le programme, en tenant compte des paramètres de sa bulle. (cf. figure 14) - Être utilisable pour différents scénarios. o Les équations paramétriques de chacune des trajectoires de patrouille (Ellipses), sont générées automatiquement à partir des paramètres rentrés manuellement dans l interface graphique (Coordonnées du centre, demi grand-axe, demi petit-axe, orientation, ). o Possibilité de choisir le point de départ des robots (à t=0), sur leur trajectoire de patrouille. - Avoir des paramètres de résolution du problème réglable o Les Intervalles initiaux pour chaque composantes de sont ajustables : réglage de et pour tout. o L intervalle de temps sur lequel la résolution doit être réalisée est réglable. o La largeur minimale des Intervalles à bissecter lors du SIVIA est réglable. - Afficher graphiquement les résultats obtenus. o Affichage dans une première fenêtre graphique des trajectoires de patrouille avec la carte des objectifs à défendre. Permet de régler la forme et la position des rondes que chaque robot doit réaliser. o Affichage dans une deuxième fenêtre graphique des résultats obtenus (Bulle et collisions) avec les trajectoires de patrouille et la carte de l environnement. o Affichage des résultats suivant l évolution temporelle du système entre et. Aussi le diagramme de classe du programme est relativement identique à celui du programme Bubbibex:

50 50 Scenario String f, g List<double*> waypoints Void Load_f() Void Save_f() String CalcTarget() Repere Scene scene Void xtopix(double x, double y) Void DrawRobot(double x, double y, double angle, double taille) MainWindow Sivia sivia SiviaCollision collision Repere R, Rscenario Scenario scenario1, scenarion 2, scenario3 IntervalVector x Void Init() Void OnPushRunClicked() Sivia Function f, g CtcFwdBwd ctc IntervalVector x Double[] eps_x List<IntervalVector> Sp, Sout Void InitSivia() Void RunSivia() SiviaCollision Function f1, f2, f3 Qintersection ctcq IntervalVector x Double[] epsx List<IntervalVector> Sp, Sout Void InitSivia() Void RunSivia() Figure 54 : Diagramme de classes d Ellibex La classe MainWindow est le cœur du programme. Elle permet à l utilisateur d interagir avec le programme, via une interface graphique comme pour le programme Bubbibex, et de lancer la résolution du problème en appelant les classes Sivia, SiviaCollision et Scenario. L utilisateur peut alors spécifier les trajectoires de patrouilles à valider, les paramètres de résolution de l algorithme SIVIA pour enfin visualiser les résultats obtenus dans une fenêtre graphique dessinée grâce à la classe Repere (comme pour le programme Bubbibex). Cependant, à l inverse de Bubbibex, les fonctions d évolutions des robots sont fixées par le programme. Les classes Sivia et SiviaCollision contiennent toutes les deux un algorithme SIVIA. La classe Sivia traite de la validation des trajectoires de patrouille, suivant le même principe que le programme Bubbibex, et la classe SiviaCollision calcule les zones de potentielles collisions entre les robots patrouilleurs. Ces deux classes communiquent avec la classe MainWindow pour accéder aux données du problème, comme par exemple les intervalles initiaux pour chacune des variables d état, et lui renvoient ensuite les résultats obtenus. Enfin la classe Scénario génère automatiquement les fonctions du système, en prenant en compte les équations des trajectoires de patrouilles à suivre. Ces équations et fonctions sont ensuite sauvegardées sous forme de scripts (.txt) facilement accessibles pour les classe Sivia et SiviaCollision pour la résolution du problème et par la classe MainWindow pour l affichage du système modélisé et de la trajectoire à valider.

51 b) Interface graphique Boite initiale, et précision de bissection demandée sur chacune des dimensions de la boite initiale (Sivia) MBDA France Incertitudes sur les variables d état des robots 51 Paramètres des ellipses Elle sont ensuite automatiquement placées sur la carte en dessous Intervalle de temps pas de temps et Paramètres des bulles pour chaque robots Mise à jour de trajectoire vis-à-vis des paramètres d ellipses demandés. Trajectoires de patrouille autours des iles de Hawaï. Celle-ci sont des ellipses tracées automatiquement à partir des paramètres rentrés manuellement (audessus) Figure 55 : Réglages des paramètres du programme (Ellibex version finale)

52 52 Fenêtre de récapitulatif des résultats trouvés Temps de calculs Marges maximales trouvés pour chacune des trajectoires de patrouille Intervalles de départ (vecteur d état + temps) et précisions utilisées pour la bissections des intervalles Récapitulatif du nombre de solutions trouvées pour la validation de chacune des trajectoires de patrouille (cf. Bubbibex) Nombre de solution trouvées pour le calcul des zones de collisions potentielles entre les robots Lancement de la résolution par les algorithmes SIVIA Figure 56 : Résultats obtenus pour la validations de trajectoires de patrouilles pour 3 robots (Ellibex version finale)

53 53 Trajectoires de patrouille «Bulles» avec leur marge (cf. Bubbibex) Zones de collisions potentielles (Affichées en Rouge). Pour la validation des trajectoires le même code couleur que Bubbibex a été adopté (i.e. en Jaune les solutions «non- Safe» et en gris les solutions «relatively Safe») Options d affichage permet de choisir les trajectoires et les résultats à afficher Échelle temporelle permet d afficher l évolution des solutions au cours du temps Figure 57 : Affichage graphique des résultats (Ellibex version finale)

54 54 3- Test du programme Concernant la validation des trajectoires, le programme Ellibex utilise exactement les mêmes algorithmes que Bubbibex. Cependant l intérêt de ce programme réside surtout dans les résultats obtenus lorsqu on ajoute des incertitudes sur les variables d état. Pour illustrer ceci, trois exemples de simulations vont être présentés. Il s agit dans les trois cas de la validation des mêmes trajectoires de patrouilles avec des incertitudes différentes sur les variables d état, comme illustré dans le tableau suivant : Incertitudes sur (m) Incertitudes sur (m) Incertitudes sur (rad) Cas d étude Cas d étude Cas d étude Les trajectoires de patrouilles sont disposées comme sur la figure ci-dessous, sur une carte des iles de Hawaï. On peut y distinguer les points de départ des robots sur chacune de ces trajectoires (Points noirs). Dans les 3 cas, les trajectoires seront validées sur un temps de parcours de 0.5secondes. Figure 58 : Trajectoires à suivre pour les 3 robots patrouilleurs Dans le premier cas d étude aucune incertitude n est prise en compte pour la validation des trajectoires. Nous obtenons alors les résultats suivants : 3 Figure 59 : Résultats obtenus pour le cas d étude 1

55 55 On peut remarquer sur la figure précédente qu aucune solution «non-safe» (Unsafe boxes) est trouvée pour les trois trajectoires. D autre part, il n existe aucune zone de l espace dans lesquelles les robots pourraient potentiellement rentrer en collision (en considérant les marges de manœuvre calculées pour les robots). Enfin, les marges des bulles (cf. Bubbibex) pour chacune des trajectoires sont relativement faibles avec par exemple, un tube enveloppe de rayon maximum égal à 6.32 mètres, pour la trajectoire du robot n 2. Dans le cas d étude n 2, nous avons rajouté des incertitudes sur le cap de. radians ; cette incertitude peut traduire par exemple, une précision du compas embarqué de. radians. Cette incertitude est valable pour tous les robots, car nous considérons ici qu ils sont tous du même type. Nous obtenons alors les résultats suivants : 3 4 Figure 60 : Résultats obtenus pour le cas d étude 2 Figure 61 : Affichage graphique des résultats obtenus pour le cas d étude 2 Nous pouvons alors constater sur les figures précédentes que l incertitude sur le cap à beaucoup d influence sur la capacité des robots à suivre la trajectoire qui leur est demandée. Tout d abord le nombre de solutions «non-safe» (Unsafe boxes) a explosé pour les trois trajectoires de patrouilles. D autre part, les marges sont nulles pour les deux premiers robots, ce qui montrent qu aucun tube enveloppe n a pu être calculé pour leur trajectoire, car ceux-ci en divergent trop. Enfin, nous pouvons observer graphiquement ces trajectoires divergentes sur la dernière figure.

56 56 Dans le dernier cas d étude, nous allons maintenant considérer des incertitudes sur la position des robots de. Ceci pourrait par exemple traduire une incertitude sur le positionnement GPS de ces robots. Nous obtenons alors les résultats suivants, Figure 62 : Résultats obtenus pour le cas d étude 3 Figure 63 : Affichage graphique des résultats pour le cas d étude 3 Sur les figure précédentes, les résultats obtenus pour le cas d étude n 3, montrent que les incertitudes sur la position des robots n a pas beaucoup d influence sur le nombre de solutions «non-safe» trouvées (Unsafe boxes) pour chaque trajectoire. Cependant, les marges des «bulles» ont augmenté considérablement, ce qui pourrait poser problème lors du calcul des zones de collisions de ces robots. Ici le calcul des zones de collisions n est réalisé que pour les robots entre eux, mais si on s intéresse aux zones de collisions avec les éléments de l environnement, nous pouvons déjà affirmer qu elles existeront (cf. figure précédente). Une fois les trajectoires de patrouille validées, le programme nous permet de les sauvegarder sous forme de points de passage, pour être réutilisées par la suite dans des simulations d interception de menaces arrivant sur ces objectifs, ou encore sur des robots en laboratoire.

57 MBDA France 57 Projet Reachable Sets Le projet Reachable Sets a été proposé par M. Stéphane LE MENEC, et a pour objectif de montrer l efficacité des méthodes ensemblistes sur une nouvelle problématique ; comment calculer les zones de capture de jeux différentielles, à un horizon temporel donné, entre deux robots. Cette problématique avait été précédemment abordée par M. Victor LE COINTRE, lors de sa césure à MBDA France, qui s était heurté principalement au problème du temps de calcul. Aussi, l intérêt de ce projet était de montrer la possibilité de résoudre ce problème en utilisant les techniques développées lors des deux projets précédents (Bubbibex et Ellibex). 1- Principe du programme On se place ici dans un scénario, où l on considère deux robot non-holonomes et noncoopératifs dans le plan. Le premier robot est dit fugitif (E : Evader) et le second robot est dit poursuivant (P : Pursuer) et tous les deux sont respectivement caractérisés par leur fonction d évolution et. Aussi dans ce scénario, le robot E aura une commande bornée sur sa vitesse angulaire, qui doit lui permet d échapper au robot P, qui lui cherche à rentrer en collision, avec une commande bornée sur sa vitesse angulaire. On pose alors les vecteurs d état avec, et l évolution des robots est décrite par les équations d état suivantes : {. s. sin. {. s.. { Figure 64 : Scénario Reachable Sets avec deux robots non-collaboratifs

58 MBDA France 58 Dans notre cas, nous allons chercher à représenter la zone de capture du «jeu des deux automobiles» dans un repère centré sur le robot fugitif (E) en utilisant une approche «Backward Reachable Set» (cf. Partie 1.b.). Cette zone de capture peut être traduite de la manière suivante : - Si le robot poursuivant (P) est situé dans cette zone de capture, alors on ne peut pas garantir d éviter la collision entre les deux robots dans un horizon temporel fixé. - Si P se trouve hors de cette zone de capture, alors il existe au moins une stratégie pour E (qui donne une commande à suivre en fonction des états et ) qui lui permet d éviter la collision avec P sous un horizon temporel fixé. Donc la zone de capture donne les états du jeu pour lesquelles il y a une stratégie du joueur P poursuivant qui lui permet de capturer (intercepter, rentrer en collision, ) le robot E sous un horizon temporel fixé (délai), quels que soient les manœuvres de ce dernier. Cette zone de capture est aussi appelée la zone des états non-sûrs et son complémentaire, la zone des états sûrs. Pour calculer ces zones, nous allons centrer le problème sur le robot E en passant du repère fixe à un repère d origine E et dirigé par le cap (axe selon le cap ). Nous allons alors poser le nouveau vecteur d état pour décrire le système de robots, tel que : Ainsi, on passe d un système d équations d état de dimension 6 à un système avec 3 variables d état, décrit par l équation d évolution suivante : s ( ) { Si l on considère une zone correspondant à la collision (cible, ou «target» du jeu différentiel) à l instant noté, encadré par et tels que, alors trouver les zones pour lesquelles le robot E est sûr d échapper au Robot P pour un horizon temporel, revient à trouver tous les états I pour lesquels, malgré toutes les commandes applicables à P, il existe une commande applicable à E permettant d éviter toute collision à venir sur une durée. Le problème peut alors être reformulé de la manière suivante: I

59 59 a) Utilisation des méthodes par Intervalles De manière classique, le calcul de ces zones de capture s effectue avec les méthodes d intégration en marche arrière (Backward integration). L espace est alors discrétisé, et une méthode d intégration (ex. Euler, Runge-Kutta,..) est utilisée pour trouver les états qui permettent d atteindre la frontière de la zone de collision. Figure 65 : Zones de capture obtenues avec des techniques de Backward Integration. Nous pouvons observer à gauche sur la figure précédente, d une part la zone de capture obtenue (en rouge), tracée dans l espace, et d autre part un exemple de trajectoire simulée pour le couple (en noir) sans collision ; la trajectoire reste à l extérieur de la zone de capture suite à la réalisation par E d une manœuvre d évitement avant d entrer dans la zone des états nonsûrs. À droite sur cette même figure, nous pouvons observer des coupes de la zone de capture suivant l axe (en degrés) qui permettent de mieux comprendre comment ces zone du plan peuvent mener à la capture de E par P pour différents caps donnés. Aussi, une méthode similaire sera utilisée avec l arithmétique par intervalles. Si l on pose le nouveau vecteur d état avec la fonction d évolution, et un espace cible, alors on peut créer le contracteur :. Ce contracteur nous permet de calculer la frontière de la zone de capture, à un horizon temporel, avec un algorithme de type Sivia ; c est-à-dire tous les états qui nous permettent d atteindre la limite de zone de collision entre les deux Robots. Enfin, pour calculer la zone de capture sur un horizon temporel plus important, il suffit d utiliser une récurrence sur les résultats ; c est-à-dire, réutiliser les résultats précédemment calculés sur un horizon temporel, en posant une nouvelle zone de collision (cible du jeu). Il est alors possible de calculer tous les états qui nous permettent d atteindre sur un horizon temporel égal à, et par conséquent qui nous permettent d atteindre sur un horizon temporel égal à.

60 60 b) Limitation du temps de calcul À l instant t, la frontière de la zone de collision est souvent composée d un ensemble de boîtes discontinu. Ceci nous oblige à utiliser l algorithme Sivia sur chacun des sous-ensembles de, puis de fusionner l ensemble des boîtes solutions qui permettent d atteindre. En conséquent, le temps de calcul peut devenir très important si est composé de trop de vecteurs d intervalles, ce qui est le cas lorsque l on souhaite calculer la zone de capture pour un horizon temporel important, comme le montre la figure suivante : X(t) T (t dt) X u (t dt) T (t) T(t) Figure 66 : Calcul de la zone de capture pour une zone de collision. On remarque que la frontière de la nouvelle zone de collision va être composée de plus de boîtes que. Afin de limiter le temps de calcul à chaque pas de temps en arrière, il faut trier les boîtes à calculer pour garder seulement celles qui forment la frontière extérieure de. Cependant comparer les boîtes entre elles, une à une, pour sélectionner celles qui se trouvent les plus à l extérieur de, prend beaucoup de temps de calcul et se révèle être une stratégie perdante à cause de la dimension des boîtes traitées. Aussi, afin de contourner ce problème, une fonction de tri a été créée : { ar tan } Ainsi, il suffit de parcourir l ensemble des boîtes pour comparer entre elles seulement celles qui se trouvent dans une même zone de l espace (grâce à l indice ). D autre part, avec cette fonction de tri, le nombre de boîtes qui composent la frontière est limité à.

61 61 2- Mise en place a) Fonctionnalités du programme Les fonctionnalités du programme se devaient d être les suivantes : - Avoir des paramètres de résolution du problème réglable. o Les Intervalles initiaux pour chaque composantes de sont ajustables. o L horizon temporel maximum sur lequel sera résolu le problème est réglable. On fixe un pas de temps (. ) puis les calculs seront réalisés un horizon.,. o La largeur minimale des Intervalles à bissecter lors du SIVIA est réglable. - Affichage clair des résultats ; L intérêt est de pouvoir comprendre la forme des zones de captures affichées. o Affichage des boîtes projetées sur le plan et sectionnées suivant une valeur fixée de. o Affichage de l évolution d une solution (prise aléatoirement) afin de permettre la meilleure compréhension du comportement des deux robots menant à leur collision. - Sauvegarde des résultats afin de pouvoir être exploités par la suite, sous forme de fichier.txt. Ces fichiers contiennent les coordonnées des points de l enveloppe extérieure de la zone de capture à horizon, pour un fixé. Aussi étant donné que l on utilise encore une fois un algorithme Sivia, avec un affichage des résultats dans une fenêtre graphique, la structure du programme sera relativement identique à celle de Bubbibex (cf. Partie projet Bubbibex, 2.b.).

62 62 b) Interface graphique Enveloppe extérieure de la zone de capture Contour de la zone de collision entre les deux Robots Paramètres du Sivia et horizon temporel Maximum. Paramètres des Robots Limite de la zone dans laquelle doit se trouver le Robot P à t-dt (dans ce cas) pour être en collision avec le Robot E. Angle de cap pris en compte pour l affichage Horizon temporel pris en compte pour l affichage Figure 67 : Interface Graphique (Reachable Sets version finale)