doivent être réajustés en fonction de la situation. Mais comme ces modèles proviennent souvent d’autres disciplines scientifiques telles que l’hydrogéologie ou la biologie, les au- tomaticiens ne sont pas forcément familiers avec ces concepts. Leur intégration aux lois de commande nécessite que ces connaissances soient suffisamment explicites pour être manipulées simplement.
– Adaptation des objectifs : De nombreux évènements "inattendus" peuvent se produire et il est nécessaire d’y réagir rapidement afin de maintenir l’intégrité du robot et de permettre autant que possible la poursuite de la mission. Cela implique aussi de pou- voir intégrer et représenter les conditions qui dictent les changements de stratégie de commande et les connaissances qui leur sont associées.
– Communications : Même si les robots sont capables de fonctionner de manière auto- nome, maintenir un lien de communication avec la surface est important. Cela permet à l’opérateur de suivre le déroulement de la mission, d’ajuster les objectifs si nécessaire, d’être informé d’un éventuel problème rencontré par l’AUV et de récupérer un certain nombre de données au fur et à mesure afin de limiter les dommages causés par la perte d’un robot. Or les communications sous-marines, basées sur des ondes sonores, sont for- tement limitées dans le rapport entre débit et portée. D’autres stratégies telles que la mise en place d’un ombilical détachable si jamais il venait à menacer l’intégrité du robot, en se coinçant par exemple, sont donc à considérer.
– Gestion de l’énergie : Les AUVs devant embarquer leur propre réserve en énergie, il est nécessaire de mettre en place les mécanismes permettant de gérer celle-ci d’une manière efficace afin d’optimiser l’utilisation de cette ressource limitée. Cela impose de choisir les stratégies de commande les plus sobres du point de vue énergétique ou de n’utiliser certains systèmes (comme les capteurs) que lorsque cela est nécessaire.
Toutes ces problématiques doivent être prises en compte lors de la description du contrôleur du robot et ensuite répercutées lors de l’implémentation de celui-ci sur l’architecture logicielle de contrôle du robot. Dans le contexte de nos travaux, les problématiques d’énergie et de communication ne seront pas abordées tout comme l’adaptation des objectifs de mission.
Nous allons maintenant présenter le robot utilisé pour mener à bien nos expérimentations.
1.3
Entre ROV et AUV : Le Jack
Avant d’introduire le robot que nous mettons en œuvre, nous allons rappeler les notations utilisées en robotique sous-marine.
1.3.1
Notations
La Figure 1.2 présente les deux principaux repères utilisés en robotique sous-marine. {U} = {~xu, ~yu, ~zu} est le repère monde qui sert de référence. L’axe ~xu est orienté vers le Nord, ~yu vers
l’Est et ~zu vers le fond (ainsi {U} est un repère direct). Le repère {B} = {~xB, ~yB, ~zB} est le
repère robot [Lap06].
Figure1.2 – Le repère robot {B} et le repère monde {U}
[φ, θ, ψ] désignent les orientations du robot dans le repère monde, respectivement le roulis, le tangage et le lacet (cap).
d = [x, y, z] représente la position de {B} par rapport à {U }.
[u, v, w] désignent les vitesses linéaires du robot exprimées dans {B}. Il s’agit respective- ment des vitesses d’avance (surge), de glissement (sway) et de déplacement vertical (heave).
[p, q, r] sont les vitesses angulaires autour des axes ~xB, ~yB et ~zB respectivement.
On notera FB = [Fu, Fv, Fw, Γp, Γq, Γr]⊺ le vecteur des forces appliqué au robot dans le
cadre de la commande.
1.3.2
Le Jack
Le robot que nous utiliserons pour illustrer nos travaux sera le ROV Jack (Figure 1.3) développé à partir d’une version commercialisée par la société Ciscrea. Dans sa configuration de base, ce ROV mesure 54 cm de long, 41 cm de large et 26 cm de haut tout en ne pesant que 11 kg hors de l’eau (hors éventuelle charge utile). Il est donc parfaitement adapté à notre contexte applicatif puisqu’il peut facilement naviguer dans un volume navigable restreint et ne nécessite pas une logistique lourde pour le transporter et le déployer.
1.3. Entre ROV et AUV : Le Jack
Figure1.3 – Le ROV Jack et son actionnement
De plus la structure vectorielle de ses moteurs lui assure une grande manœuvrabilité indis- pensable dès lors que le robot doit évoluer dans un faible volume d’eau et un environnement potentiellement encombré. Quatre moteurs horizontaux permettent des déplacements suivant l’avance (u), le glissement (v) et en rotation autour de l’axe ~zB (r). Deux moteurs orientés
verticalement permettent de faire évoluer sa profondeur (w) et de contrôler son roulis (p). Le tangage (q) n’est pas contrôlable mais est naturellement stabilisé.
Le Jack transporte également deux batteries qui assurent son autonomie énergétique. L’échange de données avec le robot est réalisé à l’aide d’un ombilical d’une longueur de 80 mètres permettant une liaison Ethernet avec l’engin. De par le fait que le Jack embarque sa propre réserve d’énergie, il est envisageable de se passer de ce câble et de faire fonctionner ce robot en mode AUV avec une autonomie décisionnelle et opérationnelle élevée. Le fonctionne- ment en mode AUV peut être utilisé soit parce que l’application le permet car elle ne nécessite pas une prise de décision par l’opérateur soit parce que les circonstances de mission l’imposent car l’ombilical peut s’être coincé entre des rochers par exemple. Cette évolution est d’autant plus importante à envisager que les perturbations importantes induites par l’ombilical rendent très délicates la téléopération ou la tenue des asservissements.
Le contrôleur matériel du robot est une BeagleBone Black Révision C [Col14]. Cette carte assure la gestion de l’électronique du robot, permet de réaliser les asservissements de base (cap ou profondeur, par exemple) et assure le transfert des données vers la surface. Elle est dotée d’un noyau Linux patché avec Xenomai 2.6 sur lequel est installé le Middleware temps-réel ContrACT. Ce dernier sera présenté plus précisément au Chapitre 7.
Le Jack est équipé de plusieurs capteurs. Une caméra IP permet la remontée d’images via le lien Ethernet. Le robot dispose également d’un capteur de profondeur et d’une centrale inertielle (XSens MTI) nous permettant d’obtenir les orientations (roulis, tangage et cap), les vitesses angulaires dans le repère robot (p, q et r) ainsi qu’une estimation des accélérations linéaires subies par le robot dans {B} ( ˙u, ˙v et ˙w). D’autres capteurs fournissent la température
interne du robot, la température de l’eau, l’état de charge des batteries et la détection de voies d’eau.
Néanmoins, la taille réduite du Jack, si elle permet la navigation dans les milieux visés, limite également la charge utile embarquable. Dès lors, il est nécessaire de cibler les capteurs à utiliser pour chaque application visée afin de n’embarquer que ceux qui sont pertinents. Il faut alors que l’architecture matérielle et la structure mécanique de l’engin soient mo- dulaires afin de faciliter l’adaptation de la charge utile du robot aux spécificités de chaque mission. L’architecture matérielle présentée ci-dessus intègre donc ces préoccupations grâce à deux prises Ethernet, permettant l’ajout de capteurs de charge utile, de puissance de calcul supplémentaire (carte de contrôle haut-niveau), et autorisant également l’ajout d’un étage d’actionnement supplémentaire.
Du point de vue mécanique, un skid, comme celui présenté aux Figures 1.4 et 1.5, permet de fixer différents capteurs au robot. Lorsque la capacité d’emport du robot devient insuffi- sante, il est également possible de mettre en œuvre une version comprenant un second étage d’actionnement relié mécaniquement à l’étage supérieur, comme illustré à la Figure 1.6. Cette version sera présentée de manière plus détaillée au Chapitre 8.
Figure1.4 – Le ROV Jack équipé d’un sonar sectoriel monté sur un skid
Il apparaît dès lors que, pour pouvoir tirer parti de la modularité matérielle du Jack, le logiciel assurant son contrôle doit s’adapter aux différentes versions du robot. Outre la possi- bilité d’accéder aux données fournies par les capteurs en proposant les drivers adéquats, il doit également permettre d’embarquer, suivant les besoins de chaque application, les connaissances qui permettent d’utiliser les informations fournies par les capteurs pour le contrôle du robot. Cela souligne que le contrôleur du robot doit lui aussi être modulaire pour exploiter au mieux la polyvalence offerte par l’architecture matérielle.