Banc de test sol

Afin de s’assurer que les applications sont correctement implémentées avant de les tester sur le terrain (ce qui nécessite au moins une demi-journée et fait courir des risque de détérioration du matériel), elles sont intégrées et testées sur le banc de test sol de SCUAL (fig. 6.103, p. 158). Celui-ci est le pendant sol de la flotte aérienne. Il est donc composé de

5 unités comportant chacune :

– un autopilote nu (i.e. sans les capteurs ni la partie volante de l’appareil) en mode simulation : la partie déplacement est simulée mais l’ensemble des fonctionnalités, dont la communication avec la charge utile, est identique à celle d’un drone de la flotte ;

– un Overo ;

– un module XBee permettant la communication intra-essaim ;

– une interface USB permettant de se connecter à la console de l’Overo (équivalent du lien de debug XBee) ;

– les capteurs mission éventuels (généralement en USB).

Comme on peut le voir sur la figure 6.103 (p. 158), les unités sont indépendantes les unes des autres et facilement transportables. De plus, elles sont empilables, rendant l’ensemble modulable (utilisation de tout ou partie de l’essaim, création d’îlots).

(a) Les bancs de tests démontés (b) Les bancs des tests nus empilés Figure 6.103 – Le banc de test SCUAL

6.3 Conclusion

Dans la première partie de ce chapitre, nous avons défini ce qu’est un drone et avons dressé un état de l’art des différents types de drones existants. Nous nous sommes concentrés sur les flottes de drones, celles-ci constituant le sujet principal de nos travaux. Nous avons différencié les flottes qui évoluent en intérieur de celles qui évoluent en extérieur (et les technologies employées pour leurs implémentations), bien que depuis peu certaines flottes soient capables de passer d’un mode à l’autre en fonction du contexte et de la disponibilité des différentes technologies.

Dans la seconde partie de ce chapitre, nous avons décrit la flotte de drones SCUAL mise en place au LaBRI. Les engins sont basés sur des produits de la société Fly-n-Sense auxquels a été ajoutée une charge utile capable de modifier dynamiquement le plan de vol se trouvant dans l’autopilote et ayant des capacités de communication pair-à-pair. Certains choix, liés aux applications visées et aux technologies disponibles, ont été faits au moment de la création de la flotte. En particulier, pour les projets à venir, les évolutions de la flotte SCUAL compteront l’ajout de techniques d’évitement de collisions qui sont déjà à l’étude.

CARUS

7.1 Scénario, Mission . . . 160 7.2 Station de contrôle sol . . . 161 7.3 Visualisateur Mission . . . 162 7.4 Algorithmique Mission . . . 163 7.4.1 Parcours de la grille . . . 163 7.4.2 Évitement de collision . . . 164 7.4.2.1 Découpage en paliers . . . 165 7.4.2.2 Ascenseurs, points d’intervention et distances de sécurité 166 7.4.2.3 Entrée et sortie de la zone de surveillance . . . 169 7.4.3 Répartition des tâches et gestion d’incident . . . 170 7.4.3.1 Limites de l’approche utilisée . . . 170 7.4.3.2 Découpage de la grille en tâches et calcul de priorités . 171 Fonction de calcul des tranches. . . 171 Fonction de calcul des priorités. . . 173 7.4.3.3 Algorithme distribué de répartition de tâches . . . 173 Fonction de réaffectation reassign() . . . 174 7.4.3.4 Traitement distribué d’incident . . . 175 Fonction de sélection de comportement behaviour_selection()176 7.4.3.5 Règles ADAGRS . . . 176 7.4.4 Analyse . . . 182 Calcul de longueur des parcours. . . 183 7.4.4.1 Analyse du comportement global . . . 184 Borne maximale sur le temps de revisite d’un point. . . . 185 Borne maximale instantanée sur le temps de revisite . . . 186 Espoir de temps de revisite à un instant donné. . . 189 7.4.4.2 Analyses des fonctions et procédures utilisées . . . 190 Analyse de la fonction de calcul des tranches. . . 190 Analyse de la fonction de calcul des priorités. . . 191 Analyse de la fonction de calcul d’affectation. . . 191 Analyse de la fonction de sélection de comportement. . . . 192 7.4.4.3 Analyse de l’impact des hypothèses réalisées . . . 192

Version avec FGE égaux à FGR. . . 192 Version avec FGE égaux entre eux mais différents de FGR. 193 Version avec FGE différents avec NGE

up: égaux. . . 193 Version avec FGE différents avec NGE

up: différents. . . 194 7.5 Retour d’expérience . . . 195 7.5.1 Station sol et visualisateur . . . 195 7.5.2 Algorithmique . . . 196 7.5.3 Réglementation et procédures de sécurité . . . 196 CARUS (Cooperative Autonomous Reconfigurable UAV Swarm) est un projet du LaBRI mené dans le cadre du GIS Albatros, mis au service du cluster AETOS de La Région Aquitaine et soutenu par celui-ci en tant que son premier démonstrateur. Outre le LaBRI qui en est le responsable scientifique et technique, il implique les sociétés Fly-n-Sense et Thales ainsi que Bordeaux Technowest et La Région Aquitaine [36].

L’objectif de ce projet est de montrer la faisabilité de la mise en essaim d’une flotte co-opérative de drones autonomes communiquant par échanges de messages de type broadcast asynchrone et de faire un retour sur les problèmes techniques, humains (IHM en particulier) et réglementaires soulevés par un tel dispositif.

Nous introduisons dans un premier temps le scénario de la mission (sec. 7.1). Nous présentons ensuite la station de contrôle sol (sec. 7.2, p. 161), développée par Fly-n-Sense, ainsi que le visualisateur mission (sec. 7.3, p. 162), mis en œuvre par Thales. La première permet à l’opérateur sol de suivre l’état de chacun des drones durant les opérations, alors que le second permet à l’utilisateur, et au public, d’avoir une vue globale de l’évolution de la mission et d’interagir avec elle. Nous présentons ensuite les différents points algorithmiques (sec. 7.4, p. 163) qui ont dû être traités lors de ce projet, tels que les méthodes mises en place pour éviter les collisions ou la méthode de partage du travail au sein de la flotte. Nous présentons enfin notre retour d’expérience (sec. 7.5, p. 195).

7.1 Scénario, Mission

Cinq drones se partagent dynamiquement la surveillance continue de 15 points d’in-cidents potentiels (au sol) disposés sur une grille de 3 lignes par 5 colonnes (fig. 7.104, p 161). Pour les besoins du démonstrateur, une station dite de visualisation permet de créer/supprimer des incidents (feux, radiations, fumées, mouvements, . . . ) sur chacun des points de la grille. Lorsqu’un drone passe au dessus d’un point en incident, il s’en rapproche (en descendant) pour réaliser un traitement spécifique (relevé, marquage, . . . ). Pendant toute la durée de l’incident, le reste de la flotte doit prendre en charge les points que le(s) drone(s) en incident ne traite(nt) plus. L’objectif est qu’à terme l’ensemble des points en incident soit traité par la flotte tout en essayant de garder un ordre de survol de l’ensemble des points de la grille qui facilite la compréhension, par un opérateur ou par le public, de ce qui se passe au sein de la flotte.

La figure 7.104 (p. 161) présente une configuration possible du dispositif expérimental. Au départ, chaque drone se situe sur la ligne des points initiaux, d’où l’ensemble des appareils de la flotte décolle, potentiellement simultanément. Comme nous le verrons

(0,0) (0,1) (0,2) (1,0) (1,1) (1,2) (2,0) (2,1) (2,2) (3,0) (3,1) (3,2) (4,0) (4,1) (4,2) 1 2 3 6 5 4 7 8 9 12 11 10 13 14 15 id : 20 id : 21 id : 22 id : 23 id : 24

Station de contrôle sol Station de Visualisation Station de monitoring mission

ligne des points d’entrée/sortie

ligne des points initiaux

30m

Figure 7.104 – Schéma global CARUS

plus loin (sec. 7.4.2.3, p. 169), cette ligne de départ doit être pensée de manière à ce que les trajectoires des drones ne puissent pas se couper lors de leur entrée/sortie de la zone de surveillance (opérations pour lesquelles ils doivent emprunter un point de la ligne d’entrée/sortie). Les points initiaux se situent entre la grille et les trois stations (station de contrôle sol, station de visualisation et station de monitoring mission). Ceci permet aux différents opérateurs (et au public) d’être suffisamment proches des appareils lors des phases de décollage et atterrissage sans pour autant gêner leur déploiement ou risquer une collision avec l’un d’eux.

7.2 Station de contrôle sol

La station de contrôle sol (Ground Control Station - GCS), ou station sol, de la société Fly-n-Sense (présentée section 6.2.1.2, p. 149) permet à l’opérateur mission de suivre en direct le fonctionnement des drones de la flotte et, si besoin est, d’intervenir sur n’importe lequel d’entre eux ou sur tous à la fois.

Sur la capture d’écran 7.105 (p. 162) faite lors d’un vol CARUS, on peut voir : – les signes vitaux de chaque drone (niveau de batterie, altitude, position, attitude) ; – un fond de carte 2D de la situation sur le terrain qui montre, avec une couleur

différente pour chaque drone : – sa position

– les waypoints de son plan de vol

– une trace représentant ses positions passées – les blocs du plan de vol de chaque drone ;

Figure 7.105 – Capture d’écrans de la station sol lors d’un vol CARUS

– des boutons d’accès rapide permettant de donner simultanément certaines directives (décollage, atterrissage, mise en attente, . . . ) à l’ensemble des appareils de la flotte.