Rasv-Raf-13 06 2013

Projet RASV
World Robotic Sailing Championship
17/01/2013
Thibaud Berthomier
Florian Nicolas
Pierre-Emmanuel Dalidec
Kai Zhang
Projet RASV
Table des matières

Remerciements .......................................................................................................................................................................... 2
Introduction ............................................................................................................................................................................... 3
Résumé du Projet RASV .............................................................................................................................................................. 4
Abstract ...................................................................................................................................................................................... 5
World Robotic Sailing Championship ......................................................................................................................................... 6
1) Présentation ................................................................................................................................................................ 6
2) Les règles ..................................................................................................................................................................... 6
3) L’organisation .......................................................................................................................................................... 12
Présentation du projet RASV .................................................................................................................................................... 13

1) Cahier des charges fonctionnel ................................................................................................................................. 13
2) Validation fonctionnelle ........................................................................................................................................... 24
a. Validation des fonctions........................................................................................................................................ 24

b. Logistique, durée et coût de la validation fonctionnelle ........................................................................................ 27
3) Etat de l’art ............................................................................................................................................................... 28
a. Premiers exemples ................................................................................................................................................ 28

b. Compétitions de voile robotique ........................................................................................................................... 29
c. Les équipes et leurs robots voiliers ....................................................................................................................... 31
4) Organisation prévisionnelle du travail ............................................................................................................... 37
Réalisation du projet RASV ....................................................................................................................................................... 40

1) Réalisation de la mécanique .................................................................................................................................... 40
2) Réalisation de l’électronique..................................................................................................................................... 41
a. Choix des composants du bateau à moteur............................................................................................................ 41

b. Choix des composants du voilier .......................................................................................................................... 44
3) Paramétrage des moyens de communication .......................................................................................................... 48
a. La technologie Wifi .............................................................................................................................................. 48

b. La technologie Xbee ............................................................................................................................................. 49
c. La station météo .................................................................................................................................................... 52
4) Avancement de l’hydroglisseur........................................................................................................................... 53
a. Paramétrage et test des cartes de puissances et propulseurs .................................................................................. 53

b. Rappels de l’architecture physique ....................................................................................................................... 54
c. Epreuve de suivi de cibles ..................................................................................................................................... 54
d. Navigation autonome de l’hydroglisseur .............................................................................................................. 60
Et après ? .................................................................................................................................................................................. 62
Conclusion ................................................................................................................................................................................ 63
Bibliographie ............................................................................................................................................................................ 64
Annexes .................................................................................................................................................................................... 65
Page 1
Projet RASV
Remerciements
Nos remerciements s'adressent dans un premier temps au pôle d'enseignement SPID de

l'ENSTA Bretagne et en particulier à Messieurs Fabrice LE BARS et Luc JAULIN, enseignants
chercheurs en robotique, qui ont su répondre à toutes nos interrogations et nous conseiller tout au
long de ce projet sur un plan technique.
Nous tenons à remercier tout particulièrement et à témoigner toute notre reconnaissance

aux personnes et entités suivantes, pour l’expérience enrichissante et pleine d’intérêt qu’elles nous
ont fait vivre durant ce projet :
Messieur Bruno AIZIER, Expert en modélisation de systèmes embarqués au sein de

l'ENSTA Bretagne, pour son aide précieuse lors des différentes phases inhérentes à l'analyse
fonctionnelle.
Le Club Robotique de l'ENSTA Bretagne pour nous avoir fourni l'ensemble du matériel
nécessaire à l'aboutissement du projet.
L'IFREMER, et tout particulièrement Messieurs Olivier MENAGE, Ingénieur, et Patrick

ROUSSEAU, Technicien supérieur, pour leur implication dans le projet et leur rôle clé quant à la
conception de notre hydroglisseur.
Enfin, l'ensemble des personnes que nous avons eu l'occasion de cotoyer tout au
long de ce projet pour leur sympathie et leur coopération professionnelle.
Page 2
Projet RASV
Introduction
Actuellement étudiants en 2ème année option SPID à l’ENSTA Bretagne, nous avons, dans le
cadre de l’UV 4.4, la responsabilité de mener à bien un projet. Celui-ci, dénommé projet R.A.S.V
(Robot Autonomous Surface Vehicle), consiste en la création d’un voilier et d’un hydroglisseur
autonomes dans l’optique d’une participation à la WRSC 2013 (World Robotic Sailing
Championships), qui aura lieu en Septembre 2013. Cette compétition regroupe de nombreuses
équipes étudiantes à travers le monde, faisant concourir leurs systèmes autonomes dans diverses
épreuves permettant d’évaluer les capacités des bateaux en termes d’analyse, de réactivité et
d’autonomie.
D’un point de vue pédagogique, le but de ce projet est de nous faire découvrir la création
d’un système, de la simple conception jusqu’à sa réalisation finale. Suite à la définition des exigences
et à l’identification précise de nos besoins lors de la phase d’avant-projet, nous avons poursuivi avec
la réalisation concrète de celui-ci. Nous avons pu de cette façon implanter nous-mêmes les solutions
que nous avions retenues et nous confronter aux différents problèmes et imprévus que celles-ci
impliquaient.
Le document ci-présent retrace donc l’élaboration progressive et complète de notre projet,

incluant les deux phases le constituant, celle de réflexion et d’élaboration, puis celle de réalisation.
Dans un souci logique de faire figurer l’ensemble de notre démarche dans le rapport final, nous
avons volontairement laissé l’ensemble du travail effectué lors du premier semestre. Nous y avons
évidemment ajouté l’ensemble des paragraphes relatifs à la réalisation de notre projet et modifié
certains autres en fonction des modifications survenues lors de l’avancement de notre projet.
Page 3
Projet RASV
Résumé du Projet RASV
Les innovations dans le domaine des véhicules autonomes tels que les AUV (Autonomous
Underwater Vehicle) ou autres UAV (Unmanned Aerial Vehicle) ont été croissantes ces dernières
années et leurs champs d’application se sont multipliés.
Les voiliers autonomes, bien qu’actuellement moins répandus, jouent également un rôle clé,
en particulier dans l’observation de l’environnement marin puisqu’ils permettent de mesurer la
température, la salinité ou encore le taux de chlorophylle.
Afin de stimuler et motiver les avancées dans ce domaine, de nombreux voiliers autonomes
participent chaque année à la course WRSC, où ils s’affrontent lors de différentes épreuves, du
simple parcours à suivre, au suivi d’un autre véhicule via du traitement d’images en passant par le
remorquage.
Au-delà de l’objectif principal du projet qui consiste à participer à cette régate, les nombreux
équipements dont disposeront nos véhicules pourront se voir offrir de nouvelles applications. En
effet, le traitement d’images pourrait permettre de cartographier la surface marine à la recherche
d’objets émergés, avec la collaboration de drones aériens, comme par exemple lors de crashs aériens
en milieu maritime.
Page 4
Projet RASV
Abstract
Over the past few years, innovations in the field of autonomous vehicles such as AUVs
(Autonomous Underwater Vehicles) and UAV (Unmanned Aerial Vehicles) have been steadily
increasing and their application scopes are becoming more and more numerous.
Autonomous sailboats and motorboats, although they are not widespread yet, play a leading
role in the domain of marine observation and monitoring as they are able to measure sea
temperature, salinity or chlorophyll rates. In the case of motor boats, they are already used for
military security and safety close to shore.
Beyond such applications, several sailboats and motorboats take part every year in the WRSC
(World Robotic Sailing Championship), where they compete in multifarious trials, ranging from
autonomous navigation based on beforehand set waypoints to target tracking using real-time image
processing, through boat towing.
Furthermore, besides the main objective which consists in taking part in this regatta, the
numerous devices which equip our vehicles give us a glimpse of their potential future application.
Indeed, the real-time image processing could allow us to map the marine area to look for emerged
objects, in collaboration with UAVs, to search for plane fragments after crashes for example.
Page 5
Projet RASV
World Robotic Sailing Championship

1) Présentation
La WRSC (World Robotic Sailing Championship) est une compétition ouverte aux robots
voiliers entièrement autonomes et sans pilote jusqu’à 4 m de longueur. Cette année, la WRSC et
l’IRSC (International Robotic Sailing Conference) se tiendront à Brest, France. C’est la 6ème édition de
la régate, dont les éditions précédentes se sont déroulées en Autriche en 2008, au Portugal en 2009,
au Canada en 2010, en Allemagne en 2011 et au Pays de Galles, UK en 2012.
La tenue de la conférence internationale de robotique à la voile (IRSC) est le moment idéal

pour discuter des différents problèmes scientifiques rencontrés lors du design et le développement
des voiliers autonomes.
2) Les règles
Sauf mentions particulières (épreuve d’endurance…) ou conditions particulières (évitement
d’une collision avec un autre robot …), aucun point pour une épreuve ne sera attribué si une
intervention manuelle ou à distance sur un robot est effectuée pendant une épreuve où le robot doit
être autonome. De plus, les épreuves impliquant la participation de tous les concurrents en même
temps ne pourront être tentées qu’une seule fois (pour des raisons d’organisation). Pour le reste, les
points gagnés lors de la meilleure tentative seront utilisés. (Lebars [2012])
Figure 1 – Zones de compétition
Page 6
Projet RASV
Catégories de robots
 Petits voiliers autonomes jusqu'à 1 m de long, 2 m de hauteur, 100 kg, nommée catégorie
Microvoiliers (code MV).
 Voiliers autonomes jusqu'à 4 m de long, 10 m de hauteur, 500 kg, nommée catégorie Voiliers
(code V).
 Tout type de bateau autonome jusqu'à 4 m de long, 10 m de hauteur, 500 kg, nommée
catégorie Bateaux à moteur (code M). L'organisation se réserve le droit de refuser un robot jugé
dangereux, inapproprié... Consulter les organisateurs à l'avance si nécessaire. Tous les robots devront
avoir le nécessaire pour faciliter leur mise à l’eau, arrêt, récupération et fonctionner en toute
sécurité. Les robots pouvant aller à une vitesse supérieure à 5 km/h devront pouvoir être contrôlés à
distance (pour des raisons de sécurité). Cependant, il est fortement recommandé que tous les robots
puissent être contrôlés à distance.
Robots classés
Il y aura des classements distincts pour chaque catégorie. Chaque robot devra avoir un nom
unique et gagner au moins 1 point pendant les épreuves pour pouvoir être classé. Un robot classé
pourra être repesé, remesuré (et les valeurs max constatées seront retenues) s’il subit des
changements significatifs pendant la compétition (changement de pièces importantes, utilisation
d’un robot de secours…). Un rapport (dizaine de pages) et une vidéo (décrivant le robot, sa
construction, ses algorithmes, sa philosophie…) devront être fournis 15 jours avant la compétition.
De plus, une courte présentation devra être faite pendant la compétition. Ces documents seront
publiés sur le site web de la WRSC et sur YouTube après la compétition. Leur qualité sera notée (100
points max).
1) Epreuve de station
Aller de manière autonome dans le carré MNOP (de 50 m de côté), rester au milieu pendant 5
min et le quitter. Les concurrents pourront choisir le point de départ, qui sera en dehors du carré. Le
robot sera considéré régulé au milieu du carré 5 min après le début de la tentative. Le robot devra
être en dehors du carré max 15 min après le début de la tentative. Aucun point ne sera attribué si le
robot n’entre jamais dans le carré ou n’est pas en dehors à la fin de la tentative. Le fichier log du GPS
tracker sera utilisé pour calculer de manière automatique le temps passé dans le carré ainsi que
l'écart maximum et l'écart moyen au centre entre la 5ème et 10ème minute après le début de la
tentative, et vérifier les conditions de validation. Les points seront attribués selon cette formule :
max(30,6*nb_min_inside_square)+max(20,500/max_dist)+max(50,250/avg_dist). Des bouées seront
installées pour indiquer visuellement la position du carré, mais elles ne seront pas utilisées pour
l'attribution des points.
Durée max d’une tentative : 15 min

Points max : 100
MV+V+M
Page 7
Projet RASV
2) Epreuve de précision
Effectuer de manière autonome un triangle JKL (de 50 m de côté pour catégorie MV, 200 pour
les autres). Les concurrents pourront choisir le point de départ mais le triangle devra être fait dans
l'ordre JKLJ. Le triangle sera considéré comme commencé lorsque le robot aura franchi la
perpendiculaire à JK en J et fini lorsque la perpendiculaire à LJ en J aura été franchie. Aucun point ne
sera attribué si la première perpendiculaire n’est jamais franchie ou la dernière perpendiculaire n’est
pas franchie 50 min (25 min pour catégorie MV) après la première perpendiculaire. Le fichier log du
GPS tracker sera utilisé pour calculer de manière automatique l'écart maximum et l'écart moyen au
triangle, et vérifier les conditions de validation. Les points seront attribués selon cette formule :
max(50,50/ecartmax)+max(50,50/ecartmoy). Des bouées seront installées pour indiquer
visuellement la position du triangle, mais elles ne seront pas utilisées pour l'attribution des points.
Durée max d’une tentative : 50 min (25 min pour catégorie MV)
Points max : 100
MV+V+M
3) Epreuve de vitesse en vent arrière
Parcourir de manière autonome le plus vite possible une distance de 400 m (100 m pour
catégorie MV). Tous les robots partiront en même temps depuis une ligne de départ AB et devront
dépasser une ligne d'arrivée CD (lignes de 400 m (100 m pour catégorie MV) de large, le tout formant
un carré ABCD de 400 m (100 m pour catégorie MV) de large). Aucun point ne sera attribué si la ligne
d'arrivée CD n'est pas franchie 30 min après le départ. Le fichier log du GPS tracker sera utilisé pour
calculer de manière automatique la vitesse max et moy, et vérifier les conditions de validation. Les
points seront attribués selon cette formule : max(50,vmax)+max(50,vmoy), v en m/s. Ces points
seront ajustés pour prendre en compte les différences de taille des voiliers avec la formule :
multiplication par sqrt(overall hull length) (pour les microvoiliers et voiliers). Des bouées seront
installées pour indiquer visuellement la position des lignes, mais elles ne seront pas utilisées pour
Durée max : 30 min

Points max : 100
MV+V+M
4) Epreuve de vitesse face au vent
Epreuve précédente en sens inverse
5) Epreuve de vitesse en vent de travers
Epreuve précédente en travers
Page 8
Projet RASV
6) Epreuve d'évitement d'un obstacle mobile de position connue
Naviguer de manière autonome dans un carré DEFG de 200 m de côté et en sortir lorsqu'un
bateau perturbateur rentre dans le carré. Les concurrents pourront choisir le point de départ, qui
devra être dans le carré. Le bateau perturbateur gardera un cap et une vitesse constants pendant son
passage dans le carré, qui se fera dans les 45 min après le début de la tentative. Le bateau
perturbateur (probablement un zodiac) sera visible au radar et diffusera par Wifi, XBee ses position,
cap, vitesse (les concurrents pourront utiliser leur propre boitier émetteur). Aucun point ne sera
attribué si le robot s'approche à moins de 5 m du bateau perturbateur, si le robot sort avant que le
bateau perturbateur ne rentre dans le carré ou si le robot n'est pas sorti 15 min après l'entrée du
bateau perturbateur dans le carré. Les fichiers logs du GPS tracker du bateau perturbateur et du
robot seront utilisés pour vérifier de manière automatique ces conditions. Des bouées seront
installées pour indiquer visuellement la position du carré, mais elles ne seront pas utilisées pour

Points max : 100
MV+V+M
7) Epreuve d'évitement d'un obstacle immobile bien visible en ligne droite

en vent favorable
Faire des aller-retour autonomes sur 400 m (100 m pour catégorie MV) depuis une ligne de
départ HC et jusqu'à une ligne d'arrivée IB (lignes de 50 m (20 m pour catégorie MV) de large, le tout
formant un rectangle HIBC de 400 m * 50 m (100 m * 20 m pour catégorie MV)) en évitant un grand
obstacle immobile (probablement 5 zodiacs à l'arrêt mis bout à bout, de couleur distincte
(probablement orange, rouge ou jaune) des autres bateaux (mais les 5 auront la même couleur),
visible au radar mais n'émettant aucune information particulière). Le grand obstacle sera placé après
le départ du robot et en travers de sa route, à au moins 50 m (20 m pour catégorie MV) en face du
robot et 50 m (20 m pour catégorie MV) avant la ligne d'arrivée. Aucun point ne sera attribué si le
robot s'approche à moins de 5 m du grand obstacle, si la ligne d'arrivée IB n'est pas franchie au moins
1 fois 45 min après le départ ou si le robot sort du rectangle HIBC avant que le grand obstacle ait
commencé à y rentrer. Les fichiers logs du GPS tracker du grand obstacle et du robot seront utilisés
pour vérifier de manière automatique ces conditions. Des bouées seront installées pour indiquer
visuellement la position des lignes, mais elles ne seront pas utilisées pour l'attribution des points.

Points max : 100
MV+V+M
8) Epreuve d'évitement d'un obstacle immobile inconnu en ligne dro ite
Epreuve précédente mais avec un grand obstacle sans couleur particulière.

Points max : 200
M
Page 9
Projet RASV
9) Epreuve de suivi
Suivre de manière autonome un zodiac muni d'une bouée de 50 cm de diamètre et de couleur

particulière (probablement orange, rouge ou jaune) sur une distance de 100 m et en restant à moins
de 10 m d'elle. Le zodiac aura une vitesse proche de 0.25 m/s et suivra un parcours non rectiligne
inconnu. Le départ se fera à 5 m de la bouée. Points = nb de m consécutifs parcourus par le zodiac
avec le robot toujours à moins de 10 m de lui. Les fichiers logs des GPS trackers du robot et de la
bouée sur le zodiac seront utilisés pour vérifier de manière automatique ces conditions.

Points max : 100
M
10) Epreuve de remorquage et coopération
Un 1er robot tracte de manière autonome un 2ème robot sur au moins 100 m puis lâche le
2ème robot et s’arrête. Le 2ème robot démarre et parcourt ensuite au moins 100 m
supplémentaires, le tout en moins de 45 min. 30 points si le 1er robot réussit à tracter le 2ème robot
sur 100 m, 30 points si les robots parviennent à se séparer sans entrer en collision par la suite, 40
points si le 2ème robot parcourt les 100 m supplémentaires. Les points seront multipliés par 2 si l’un
des robots est un voilier. Les points seront multipliés par 3 si l’un des robots est un microvoilier. Le
2ème robot sera considéré comme correctement tracté s’il reste à moins de 10 m du 1er robot. Ils
seront considérés comme séparés dès que cette distance sera dépassée. Les fichiers logs des GPS
trackers des 2 robots seront utilisés pour vérifier de manière automatique ces conditions. Comme
cette épreuve met en jeu 2 robots, tous les points gagnés seront donnés à chaque robot.

Points max : 300
MV+V+M
11) Epreuve d'endurance et mesures (sponsorisée par Ifremer ?)
Faire de manière autonome un quadrillage d'une zone (mesures) de 500 m de côté ou un autre
type de parcours pendant au moins 8 h, (2 h pour catégorie M). Tous les concurrents seront lancés en
même temps. Mesures possibles : divers paramètres de l'eau (température, salinité, oxygène,
chlorophylle, profondeur, qualité, vagues...), de l'air (vitesse, angle du vent, température...), sons,
images vidéo, sonar, radar, lidar…, estimation de l'énergie consommée, des forces et couples sur les
actionneurs… Les concurrents devront annoncer à l’avance le trajet et les mesures effectuées pour
pouvoir obtenir des points. 300 points seront attribués par les juges. Les critères permettant de
classer les concurrents seront les suivants : qualité de couverture de zone (ex : surface max couverte
(en supposant 10 m autour du bateau couvert pour 1 point GPS chaque s)), qualité des mesures,
nombre et nature des éventuelles interventions physiques ou à distance en cours de route…
Durée max d’une tentative : 10 h

Points max : 300
MV+V+M
Page 10
Projet RASV
12) Epreuve spéciale du voyageur de commerce (sponsorisée par ENSTA

Bretagne et Ifremer)
Les participants devront utiliser le voilier autonome VAIMOS pour effectuer un trajet passant
par des points GPS prédéfinis (et avec une précision prédéfinie) dont l’ordre de passage peut être
choisi (http://en.wikipedia.org/wiki/Travelling_salesman_problem). Les points GPS seront les mêmes
pour tous les participants et seront communiqués au début de la compétition (trajet de moins de 2h
en conditions normales). Un manuel expliquant le fonctionnement de VAIMOS sera fourni (comment
rentrer une route dans VAIMOS, paramètres réglables…). L’idée de cette épreuve est de faire
réfléchir les participants sur une route optimale compte tenu des conditions de vent et des
caractéristiques aussi bien physiques qu’algorithmiques d’un voilier autonome. Les logs de VAIMOS
seront utilisés pour valider le passage des points et calculer le temps de parcours. Un classement des
équipes ayant réalisé le meilleur temps sera établi et un prix spécial sera remis pour les gagnants de
cette épreuve.
Page 11
Projet RASV
3) L’organisation
Déroulement des épreuves
 02.09.2013 : Premières conférences et installation des équipes, remontage des robots, visite
de l'ENSTA Bretagne le soir+buffet/repas/barbecue de bienvenue.
 03.09.2013 : Suite éventuelle des conférences, début des épreuves au Moulin-Blanc.
o 14h00 – 15h30 : Epreuve de vitesse en vent arrière
 04.09.2013 : Epreuves au Moulin-Blanc.
o 17h00 – 18h00 : Epreuve de vitesse face au vent
 05.09.2013 : Epreuves au Moulin-Blanc.
o 16h00 – 17h00 : Epreuve de vitesse en vent de travers
o 17h00 – 18h00 : Epreuve de formation en meute
 06.09.2013 : Epreuve d’endurance et présentations, démos de robots invités (voilier
autonome VAIMOS de l'Ifremer, ASV MOBESENS de l'Ifremer, ASV GESMA, ASV OCARINA LATMOS…)
et soirée de remise des prix avec buffet (Oceanopolis ?).
Prix
Des prix seront remis sur la base des points gagnés par chaque robot pour les 3 catégories
(catégorie Microvoiliers, catégorie Voiliers et catégorie Bateaux à moteurs), chaque catégorie divisée
en un classement pour les équipes étudiantes et un classement pour les équipes libres :
Microvoilier étudiant
Voilier étudiant
Bateau à moteur étudiant
Microvoilier libre
Voilier libre
Bateau à moteur libre
Des prix spéciaux seront aussi attribués (e.g. Meilleur MicroMagic, Meilleur SailBot, Meilleur Bateau
à Essence, Meilleur Bateau Electrique, Robot le plus Innovant, MeilleurePremière Participation…).
(Lebars [2012])
Page 12
Projet RASV
Présentation du projet RASV

1) Cahier des charges fonctionnel
Objectif
Remporter la WRSC organisée par les écoles en réalisant deux engins de surface autonomes :
un voilier et un bateau à moteur capables de faire du traitement d’image en temps réel.
Contexte
Dans le cadre de l’option (Systèmes, Perception, Informations, Décision) lors de notre

deuxième année à l’ENSTA Bretagne, nous devons procéder à la réalisation d’un projet technique.
Notre projet consiste donc en la réalisation de deux navires de compétitions capables de naviguer en
totale autonomie sur un lac ou en mer. Ces bateaux devront être capables de détecter d'autres
robots marins téléopérés ou autonomes et de vrais bateaux puis de les éviter. L’un sera un voilier et
naviguera uniquement à l’aide du vent. L’hydroglisseur verra quant à lui sa propulsion assurée par
deux hydrojets. Les deux systèmes embarqueront un système capable de réaliser du traitement
d’images en temps réel. Les bateaux devront également être en mesure de répondre aux exigences
et à la règlementation de la WRSC et pourquoi pas ramener le précieux trophée de la WRSC à
l’ENSTA Bretagne qui, rappelons-le, est cette année l’organisatrice de la compétition.
Page 13
Projet RASV
Services et contraintes
Les deux prototypes devront être capables de :
Voilier Hydroglisseur
• Se déplacer seul selon des consignes • Se déplacer seul selon des consignes
données (cap à suivre et/ou but à atteindre données (cap à suivre et/ou but à atteindre
et/ou zone à éviter) au moyen d'une propulsion et/ou zone à éviter) au moyen de deux
vélique. propulseurs.
• Se déplacer selon les ordres d’un pilote déporté à terre, ou sur un navire suiveur à portée
d’une liaison sans fil (Wi-Fi, Xbee, radio,…).
• Supporter des états de mer élevés : les caractéristiques essentielles sont d’être
insubmersible et que le gréement sorte indemne de ces coups de vents.
• Transmettre des informations concernant son état (position, cap, vitesse, alimentation
électrique,…) et ce, indépendamment de sa position : de par l’informatique embarquée, le bateau
sera capable de prendre les décisions nécessaires pour suivre une route et atteindre un objectif.
Toutefois un retour d’information régulier sur son comportement doit pouvoir être reçu sur un
équipement à terre.
• Recevoir des commandes de contrôle et gestion des équipements de bord : selon les
informations reçues en provenance du bateau ou selon le contexte de la course, certaines actions
peuvent être nécessaires (changement de route, arrêt/démarrage de capteurs, changement de
configuration, demande de réémission de données,…). Cependant, la sécurité du navire ne doit pas
être mise en cause : pas de redémarrage des organes qui entrainerait une perte définitive de
communication ainsi qu’un comportement imprévisible.
• Etre capable d’interagir avec le milieu extérieur, c’est-à-dire pouvoir gérer un obstacle
inconnu (qui n’envoie pas de données sur sa position, sa vitesse, sa taille …), gérer une cible connue
(qui envoie des informations sur sa position, sa vitesse, sa taille, …). Enfin, il faut pouvoir gérer le
remorquage : l’un des deux bateaux doit être en mesure de remorquer l’autre.
• Avoir une autonomie énergétique suffisante pour plusieurs jours de fonctionnement.

L’énergie embarquée devra permettre aux bateaux de fonctionner durant au moins la totalité d’une
épreuve : l’épreuve la plus longue pouvant durer jusqu’à dix heures.
• Capable de détecter les obstacles à l’aide de sa caméra embarquée et de suivre une cible
mouvante
• Participer à la WRSC qui a lieu en septembre 2013 à Brest : les bateaux devront en effet être
prêts pour débuter la compétition et porter haut les couleurs de l’école.
Page 14
Projet RASV
Bête à cornes
Diagramme pieuvre du voilier
Page 15
Projet RASV
Page 16
Projet RASV
Diagramme pieuvre de l’hydroglisseur
Page 17
Projet RASV
Page 18
Projet RASV
Diagramme FAST
Fonction Solutions
principale technologiques
Connaître sa position et sa
vitesse GPS
Conaître les donées de

Connaître son cap boussole
navigation
Connaître le sens du vent

(voilier) Gyromètre
FP_1:
Naviguer en autonomie sur Obtenir les coordonnées de
un plan d'eau Calculer le cap théorique géolocalisation du point Liaison Wi-F, Xbee...
d'arrivée
Naviguer en portant : Algorithme et actionneurs

trajectoire directe (vent de Suivre la route (moteur ou gouvernail +
dos ou bateau à moteur) voile)
Déterminer la stratégie de
navigation
Naviguer en louvoyage : Algorithme et actionneurs
Calculer les N bords à tirer
trajectoire indirecte Suivre la route (moteur ou gouvernail +
contre le vent
(voilier et vent de dos) voile)
Page 19
Projet RASV
Page 20
Projet RASV
Page 21
Projet RASV
Analyse Fonctionnelle
Page 22
Projet RASV
Page 23
Projet RASV
2) Validation fonctionnelle
Les différents scénarii correspondant aux épreuves imposées par la WRSC, la validation
fonctionnelle revient à vérifier le bon fonctionnement des trois fonctions principales qui sont
ressorties de notre analyse fonctionnelle. Celles-ci garantiront ainsi le bon déroulement des scénarii
auxquels nous aurons à faire face lors de la compétition.
a. Validation des fonctions
Les résultats permettant de considérer les tests comme concluants figurent en gras.
i. Navigation en autonomie sur un plan d’eau
Le voilier/hydroglisseur devra être capable d’atteindre un point B(xb, yb), dont les coordonnées
seront fournies par l’utilisateur, à partir d’un point de départ A(xa, ya).
Hydroglisseur :
En ce qui concerne l’hydroglisseur, un tel trajet devra bien évidemment être effectué en ligne
droite, le recueil des données GPS devant permettre de s’en assurer.
Le résultat sera considéré comme concluant si l’erreur par rapport au point d’arrivée
théorique est inférieure à 7-8 mètres et également que la trajectoire est proche de la ligne droite.
Voilier :
Pour le voilier, nous distinguons deux cas :
Page 24
Projet RASV
Vent arrière (navigation en portant/de près) :
Après avoir correctement positionné le voilier vis-à-vis de la direction du vent, il faudra ici
s’assurer que la trajectoire du voilier est proche d’une ligne droite en étant tout de même plus
tolérant qu’avec l’hydroglisseur.
Louvoyage :
Le sens du vent étant ici opposé à la direction que l’on souhaite suivre, il faudra dans ce cas
optimiser le nombre de virements de bord pour atteindre l’objectif souhaité, la trajectoire ne
pouvant être rectiligne (cf. schéma), dans le but de rejoindre le point B le plus rapidement possible.
Ces procédures de tests devraient à priori s’avérer concluantes puisque le voilier utilisé ici sera le
VAIMOS, déjà opérationnel et disposant de l’ensemble des algorithmes nécessaires à une navigation
efficace.
Via l’acquisition temps réel des données GPS et stockage dans un fichier texte, nous serons
capables de visualiser la trajectoire du voilier et ainsi de vérifier son comportement.
Concernant la précision, nous tolèrerons une erreur de 10 mètres par rapport au point
d’arrivée demandé.
ii. Interaction avec le milieu extérieur
Détection d’obstacles inconnus :
Via la caméra embarquée, l’hydroglisseur devra être capable de suivre une cible en
mouvement (bouée rouge tractée d’un diamètre d’environ 1m) en conservant une distance vis-à-vis
de celle-ci inférieure à 10 mètres tout en évitant la collision. Des sorties ont été réalisées au lac de
Bourg-Blanc afin de tester la bonne exécution de l’algorithme de suivi de cible.
Détection d’obstacles connus :
Nous disposerons d’un zodiac en mouvement et équipé d’une balise AIS qui transmettra
continuellement ses coordonnées via WiFi et Xbee. Notre robot sera également en mouvement.
Premièrement, le voilier/hydroglisseur devra être capable de récupérer de telles données pour
localiser l’obstacle. Ensuite, le véhicule devra régulièrement calculer sa distance par rapport à cet
obstacle.
Le système émettant ces informations n’a cependant pas encore été créé, nous ne pourrons
donc effectuer les tests de validation concernant cet aspect avant la fin du projet.
L’objectif que nous nous étions initialement fixés était que le bateau soit continuellement à
plus de 5 mètres de l’obstacle.
Page 25
Projet RASV
Gestion du remorquage :
A l’origine, nous devions procéder de la façon suivante. L’hydroglisseur devait tracter le

voilier grâce à la pince et l’anneau de remorquage dont ils sont équipés puis le relâcher. Les trois
tests essentiels pour cette partie consistaient à vérifier la solidité de la pince, le bon fonctionnement
du mécanisme d’ouverture et la stratégie d’évitement une fois le deuxième robot lâché, afin d’éviter
la collision entre les deux robots. Nous avions prévu de gérer le problème de la collision en fin de
course, en décidant d’écarter l’hydroglisseur à 45° de la route du voilier une fois ce dernier lâché.
Cependant, par manque important de temps, nous avons préféré nous concentrer sur la
réalisation des fonctions essentielles (déplacement, suivi/évitement) de l’hydroglisseur afin de
répondre aux exigences fixées, notamment en termes de navigation. La réalisation et l’implantation
de la pince dans le système ne seront donc pas effectuées et par conséquent non sujettes à une
phase de validation.
De plus, le fait d’opter pour le VAIMOS et un nouveau type d’hydroglisseur rendent notre
stratégie caduque au vu des dimensions et de la constitution des deux véhicules. En effet, il paraît
assez utopique d’obtenir un remorquage efficace et optimisé étant données leurs caractéristiques
respectives.
iii. Interaction avec l’utilisateur
Commande manuelle du véhicule : Pour le voilier VAIMOS, ici aussi la commande est déjà
effective, comme expliqué dans le rapport de PFE de notre encadrant Olivier Ménage. Il est donc
possible de piloter manuellement le VAIMOS en utilisant un clavier d’ordinateur à terre ou une
télécommande de modélisme (après calibrage).
En ce qui concerne l’hydroglisseur, après avoir opté dans un premier temps pour une
interface graphique minimaliste permettant un contrôle en temps réel de celui-ci en cliquant sur des
boutons, nous avons finalement estimé qu’il serait plus simple de le commander directement au
clavier. Ainsi, une commande réactive et précise en temps réel est attendue. Nous pourrons donc
valider le bon fonctionnement de cette commande à l’œil mais également grâce au flux vidéo
renvoyé en temps réel par la caméra présente sur l’hydroglisseur. Les sorties au lac de Bourg-Blanc
ont également été réalisées dans le but de vérifier le bon comportement de l’hydroglisseur.
De façon générale, nous étant vus confié le VAIMOS, nous ne ferons que supposer que
l’ensemble des tests se rapportant à des fonctions déjà opérationnelles chez celui-ci est supposé
valide, puisque nous n’effectuerons finalement pas de sortie en mer afin de les tester. Le rapport de
PFE de Mr Ménage et le succès des missions effectuées par le VAIMOS nous confortent cependant
dans cette hypothèse. Cependant, il nous sera impossible d’évaluer, pour les mêmes raisons, les
parties de code adaptées au VAIMOS et relatives à la réalisation des épreuves.
Page 26
Projet RASV
b. Logistique, durée et coût de la validation fonctionnelle
En termes de coûts, nous devons tout d’abord considérer les commandes passées en fin de
projet et destinées à rendre notre hydroglisseur fonctionnel. Celles-ci comprenaient notamment
l’achat d’un hydrojet, un inverseur de flux, 8 soufflets pour la partie purement mécanique de
l’hydroglisseur et 4 batteries pour assurer une autonomie correcte. Nous avons également dû
recourir à l’achat de deux nouveaux moteurs suite à la dégradation important qu’avaient subis les
moteurs initiaux après la première demi-journée de tests.
Du matériel électronique a également été commandé par Mr Le Bars au cours du projet, afin de
pouvoir établir le système complet, et rentrant dans le cadre d’un réapprovisionnement du
laboratoire robotique. Etant donnés les délais de livraison du matériel et l’assemblage sur le nouvel
hydroglisseur, nous n’aurons le temps d’effectuer qu’un nombre réduit de tests. Ceux-ci seront
réalisés dans la cuve du bâtiment M pour une première approche (hydroglisseur de test en mousse),
puis au lac de Bourg-Blanc pour les tests du vrai hydroglisseur en conditions réelles. Ils occuperont en
moyenne une demi-journée, le temps de sortir le matériel, de le préparer, de le mettre à l’eau,
d’effectuer les tests et d’appliquer les corrections nécessaires.
Page 27
Projet RASV
3) Etat de l’art
a. Premiers exemples
Figure 2 : SKAMP (Station Keeping Figure 3 : RelationShip Figure 4 : Atlantis

Autonomous Mobile Platform)
Station Keeping Autonomous Mobile Platform (SKAMP)
La première tentative de la voile autonome dans la littérature est un projet

nommé SKAMP (plate-forme mobile). Le SKAMP était une plate-forme mobile propulsé de
surveillance à propulsion vélique qui a utilisé une aile rigide courbe en forme d'anneau (Figure 1). Il a
été développé en 1968 par EW Schieben avec la Radio Corporation of America et a été optimisé pour
être une station autonome immobile plutôt que pour une performance dynamique (Schieben [1969],
Smith [1970]). Les données de navigation réelles n'ont jamais été publiées, il reste donc difficile de
savoir si SKAMP ait jamais navigué de manière autonome. (Elkaim [2002])
RelationShip
La deuxième tentative connue de voile autonome était le projet RelationShip de l'Université

des sciences appliquées de Furtwangen, Allemagne (Figure 2). Le projet a démarré en 1995 avec un
plan ambitieux : faire le tour du monde avec un trimaran sans pilote. Selon Elkaim [2002] l'intention
initiale était de naviguer de manière autonome. Cependant, après quelques difficultés le projet a été
revu, le contrôle du bateau se ferait à distance via un satellite. Après quelques années, le projet a été
annulé en raison des difficultés de réglementation. Ils n'ont pas obtenu la permission de faire le tour
du globe avec leur bateau sans pilote. L'idée de déclarer le bateau otsam n'a pas convaincu les
autorités maritimes. (Spiegel [1998])
Atlantis
Le projet Atlantis de l'Université de Stanford a commencé en 1997 avec le concept d'un voilier
muni d’une aile rigide, sans pilote, autonome, guidé par GPS. Le bateau est basé sur un catamaran
Prindle-19, avec un ajustement automatique de l’aile-voile (Figure 3). Le voyage inaugural a eu lieu à
Redwood City Harbour en Janvier 2001. (Elkaim [2002, 2006])
Page 28
Projet RASV
b. Compétitions de voile robotique

Dans de nombreux champs de la robotique, les compétitions internationales organisées attirent
l'attention des médias et l’intérêt du public, et sont susceptibles de susciter une forte incitation à la
recherche et au développement dans le domaine en question. Les exemples les plus populaires de la
robotique sont DARPA Grand Challenge pour les voitures entièrement autonomes (Thrun et al.
[2007]) et RoboCup pour les robots qui jouent au football et dont le but est de battre les champions
du monde humains en 2050 (RoboCup [2011]). La même chose est arrivée à la voile autonome au
cours de la première décennie du 21e siècle, lorsque différents évènements ont été organisés
quasiment en même temps.
Microtransat
La recherche sur la voile autonome a été récemment stimulée par l'idée d'Yves Brière (ISAE,
France) et Mark Neal (Université d'Aberystwyth, Pays de Galles, Royaume-Uni) (Brière [2008]; Brière
et al [2005].) d’une Microtransat. Les organisateurs décrivent la Microtransat sur leur site Web
comme suit : « Le défi Microtransat est une course transatlantique de voiliers entièrement
autonomes. La course a pour but de stimuler le développement de voiliers autonomes à travers une
compétition amicale. » (Microtransat [2011]). Les voiliers participants doivent être de petite taille
(max. 4 m de longueur), sans pilote, et utiliser le vent comme seule force de propulsion. La
compétition Microtransat a parfois eu lieu avant la vraie course transatlantique. Les participants ont
alors pu échanger des idées et tester leurs bateaux dans des environnements moins sévères. La
première course Microtransat a eu lieu sur un lac à Saint Nicolas de la Grave, près de Toulouse, en
France, en Juin 2006. Au total, trois équipes ont participé avec leurs robots à voile et ont parcouru
environ 2 km, sans intervention humaine. Le prototype Roboat I était le seul bateau qui a terminé la
course avec succès.
La deuxième compétition Microtransat s’est tenue à Aberystwyth, Pays de Galles, UK en

Septembre 2007. Afin de se rapprocher de l'ultime défi d'une traversée entièrement autonome de
l'Atlantique, cet événement a eu lieu sur mer, dans la baie de Cardigan sur la côte d'Aberystwyth.
Quatre bateaux ont participé, mais seulement deux d'entre eux ont pris part à des courses, une
course courte et une course de 24 h d’endurance. ASV Roboat était le seul bateau qui a navigué à la
voile autonome au cours de ces 24 heures.
Le troisième défi Microtransat a été la première tentative de la traversée de l'océan

Atlantique. Tout a commencé à partir de Valentia, en Irlande en Septembre 2010. Le seul bateau qui
ait participé au concours était Pinta de l'Université d'Aberystwyth, Pays de Galles, Royaume-Uni.
Selon un membre de l'équipe, Sauze Colin, le bateau a tenu 49 h et 87 km sous contrôle autonome
avant que le système informatique embarqué ne plante.
Page 29
Projet RASV
SailBot
Sur la base d'un projet étudiant à l'Université de la Colombie-Britannique, au Canada, où les

élèves ont travaillé sur un voilier robotisé, des règles ont été établies pour une compétition amicale
dans la voile autonome au sein des équipes universitaires en Amérique du Nord. La première
compétition de Voiliers a eu lieu en 2006. Les organisateurs décrivent SailBot sur leur site Web
comme suit : « SailBot est un concours international pour voiliers autonomes contrôlés. Destiné
principalement aux étudiants de premier cycle des équipes, l'objectif est de donner aux élèves
ingénieurs une application pratique des sujets qu'ils ont appris, tout en offrant une façon amusante
d'apprendre la gestion de projet dans un environnement multidisciplinaire. » Le succès au concours
SailBot repose sur l’équilibre entre les besoins de l'architecture navale, de l'ingénierie mécanique, et
l’ingénierie des systèmes et électrique. Excepté en 2007, les compétitions SailBot ont lieu chaque
année depuis 2006. SailBot est ouvert pour voiliers semi-autonomes et entièrement autonome
jusqu'à 2 m de longueur. Depuis 2010, ils fournissent une classe supplémentaire ouverte pour les
bateaux d'une longueur maximale de 4 m. Pour le concours de 2011 cinq épreuves différentes sont
annoncées :
1. Course
2. Maintien de cap
3. Concours d'endurance
4. Navigation autonome
5. Présentation et design
Le Championnat du Monde de Voile robotique et la Conférence internationale Voile robotique
Le Championnat du Monde de Voile robotique (WRSC) est une compétition internationale

pour les voiliers autonomes. La première WRSC s'est tenue en Autriche en 2008. Depuis, elle a lieu
chaque année dans différents pays : Portugal (2009), le Canada (2010), Allemagne (2011) et Pays de
Galles (2012). La compétition est ouverte aux bateaux de 4 m de longueur ou moins. Les détails des
règles de WRSC changent chaque année dans le but de répondre aux récentes évolutions
scientifiques et afin de stimuler certains domaines de recherche.
La compétition coïncide avec la Conférence internationale de Voile robotique (IRSC). Cette

conférence est la base de l'échange scientifique dans le milieu de la voile robotique. La compétition
sur l'eau faisant suite à la tenue de cette conférence scientifique, elle permet une démonstration
pratique des théories évoquées.
Page 30
Projet RASV
c. Les équipes et leurs robots voiliers
Cette section donne un aperçu des équipes qui ont participé au cours des dernières compétitions
de voile robotique et couvertes par la littérature scientifique. Beaucoup d'entre eux ont été
encouragés par ces événements pour lancer la recherche dans le domaine de la navigation
autonome. La figure 4 montre le nombre croissant de bateaux participant aux compétitions de voile
autonomes depuis leur invention en 2006. Les équipes sont présentées ici par ordre alphabétique.
Des illustrations des robots voiliers sont consultables dans l’annexe.
Figure 5 : nombre de bateaux participants par année
Société autrichienne pour l'innovation en sciences informatiques (INNOC) / DeMontfort University

(DMU)
Le concepteur a formé son équipe de recherche en voile robotique dans le cadre de l’INNOC.
Cette équipe se concentre sur des algorithmes de contrôle plutôt que sur la conception des bateaux.
Jusqu'à présent, les deux coques disponibles dans le commerce ont été adaptées à des fins de
navigation autonome.
Roboat I (figure 9) est basé sur un modèle de yacht ready-made de type Robbe Atlantis
destiné à être contrôlé à distance. Il possède une longueur totale de 1,38 m et pèse 17,5 kg. Roboat I
a gagné le concours Microtransat en 2006.
La coque utilisée pour l’ASV Roboat (figure 20) est un type de bateau disponible dans le
commerce Laerling3. Il possède une longueur de 3,72 m et 60 kg, comprend une quille lestée et une
surface de voilure totale de 4,05 m2. ASV Roboat a remporté en 2007 la Microtransat ainsi qu’au
WRSC en 2008, 2009, et en 2010.
Page 31
Projet RASV
L'Ecole nationale supérieure de techniques Avancées (ENSTA) de Bretagne
Une équipe de l'ENSTA Bretagne a participé avec son bateau Breizh Spirit (Figure 8) en 2009 à
la WRSC. Leur conception utilise une coque construite sur mesure basée sur la classe IMOCA d’une
longueur de 1,3 m et équipée deux voiles traditionnelles. Le système de contrôle est mis en œuvre
sur un microcontrôleur PIC18F2550. (Sliwka et al. [2009])
A l’initiative d’un de ses étudiants alors en projet de fin d’étude, VAIMOS (Voilier Autonome
Instrumenté de Mesures Océanographiques de Surface) (figure 22) voit le jour en 2011 en
partenariat avec l’IFREMER (Institut Français de Recherche pour l'Exploitation de la Mer). Il utilise
une coque de la classe miniJ de 3.65 m (données constructeur) et un gréement sloop fait sur mesure.
VAIMOS est un outil scientifique conçu pour des expéditions de longue haleine en pleine mer et n’a
participé à aucune compétition. (Menage O., [2011])
Institut supérieur de l'aéronautique et de l'espace (ISAE)
L’iBoat de l'ISAE, France (figure 16) est fait de fibre de verre et de carbone et est donc
relativement léger. IBoat a une longueur de 2,04 m et une hauteur de 3 m. Il dispose d'1,05 m2 de
surface de voile avec une combinaison de deux voiles (grand-voile et foc) montées sur une plate-
forme équilibrée. Les capteurs utilisés sont une boussole électronique, un capteur de vent (vitesse et
direction) et un récepteur GPS. Les capteurs sont reliés à un microcontrôleur via CAN bus (Briere
[2006]). IBoat a participé à la Microtransat 2006 et 2007 ainsi qu’à la WRSC de 2009.
Queen's University
Mostly Autonomous Sailboat Team (MAST) a été fondée en 2004 à la Queen’s University.
Leur premier navire entrant en compétition à la SailBot de 2007 a été Black Adder (figure 12),
mesurant 2 m et équipé d’une longue coque en fibre de carbone avec des voiles traditionnelles.
Depuis 2007, l'équipe d'étudiants de premier cycle a apporté des modifications importantes à leur
première conception et participé au Défi Microtransat en 2007, à la WRSC en 2008 et 2010 ainsi que
SailBot en 2008, 2009 et 2010. (Burnie [2010])
Institut fédéral suisse de technologie de Zurich (ETH)
Avalon (figure 21) a été développé par une équipe d'étudiants de l'Institut fédéral de
technologie de Zurich pour relever le défi de la Microtransat et a participé à l'édition 2009 de la
WRSC. Avalon dispose d'un design monocoque d'une longueur de 3,95 m, une plate-forme et d'un
système de double gouvernail, et est alimenté par quatre panneaux solaires de 90 W chacun, quatre
batteries lithium-manganèse de 600 W chacune et d'une cellule methanol/fuel pour l’alimentation
de secours. Le système de contrôle est mis en œuvre sur un ordinateur industriel MPC213
fonctionnant sous Linux. (Giger et al. [2009])
United States Coast Guard Academy (USCGA)
Intuition a été développé par la United States Coast Guard Academy et a participé à SailBot et
à la WRSC en 2010. Le bateau de l’USCGA de conception monocoque de 2 m dispose d'un gréement
sloop classique avec une surface de voile de 1,7 m2. Le système de contrôle est mis en œuvre sur un
ordinateur ISIS PC104 fonctionnant sous Windows XP et MATLAB. (Burnie [2010])
Page 32
Projet RASV
United States Naval Academy (USNA)
L’USNA a commencé ses activités en 2007. Ils ont participé avec leur bateau First Time (figure
13) à SailBot en 2008.
En 2009, ils font entrer Luce Canon (figure 15) dans les compétitions SailBot et WRSC.
En 2010, ils ont participé avec le bateau Gil the Boat (figure 14) à SailBot et à la WRSC.
L'équipe d’étudiants de premier cycle comprenant des architectes navals et des ingénieurs systèmes
conçoit et fabrique de nouveaux voiliers chaque année tout en améliorant continuellement les
bateaux des années précédentes. Leur conception utilise une coque unique construite sur mesure
d'une longueur de 2 m et un gréement sloop classique avec une surface de voilure d'environ 3 m2.
(Miller et al. [2009, 2010])
Université d'Aberystwyth
L'équipe qui travaille avec Mark Neal et Colin Sauzé construit de multiples robots voiliers
dont la longueur varie entre 50 cm et 3,05m dans le but d'effectuer des missions autonomes à long
terme pour la surveillance océanographique.
Aroo (figure 10) a été construit à la fin 2004 comme une preuve d’un concept pour un petit
robot voilier durable. La coque est d'environ 1,5 m de long et est gréé avec une voile de 1 m à aile
haute (Neal [2006]).
L’ARC (figure 11) est d'environ 1,5 m de longueur et dispose de deux voiles ailées
commandées indépendamment et deux safrans commandés par un seul actionneur. Il est équipé
d'un compas à cardan, un récepteur GPS et une combinaison d'un microcontrôleur Au-Mega128 et
d’un ordinateur Gumstix5 fonctionnant sous Linux. La seule source d'énergie est une banque de 20
piles de type AA rechargeables de 1,2V avec une capacité de 2500 mA chacune. (Sauzé & Neal
[2008])
Beagle-B (figure 19) est leur plus grand bateau et a été construit fin 2006 par Robosoft (une
entreprise française de robotique). Il mesure 3,5 m de long et utilise une voile de type aile rigide de 3
m. Beagle-B est destiné à fournir une plate-forme sérieuse pour les missions océanographiques de
longue durée. Son alimentation est assurée par deux panneaux solaires de 15 W et quatre batteries
60 A de 12 V. Il comprend une sonde YSI 660 pour recueillir des données océanographiques ainsi
qu'un émetteur-récepteur et un modem GSM Iridium SBD pour la transmission de données. Beagle-B
a participé au Défi Microtransat de 2007, dans lequel il a navigué un total de 25 km sur 19 heures.
(Sauzé & Neal [2008])
Pinta (figure 18) a été construit pour la WRSC de 2008 et la course Microtransatlantic.
Contrairement aux autres bateaux de l'équipe il utilise une seule voile traditionnelle contrôlée par un
système de treuil électrique. Pinta est basé sur un dériveur Toper Taz avec une voile d'une longueur
de 2,95 m. Pinta était le seul bateau à entrer en compétition dans le Challenge 2010 de la
Microtransat.
Le Moop (Mini Plate-forme d’observation de l'océan; la figure 6) est un robot à voile légère
avec une longueur totale de 0,72 m. De multiples Moop ont été construits à ce jour avec la
Page 33
Projet RASV
configuration de voile simple ou aile double, à la fois avec les safrans et sans gouvernail. Ils sont
commandés soit par un microcontrôleur PIC seulement, soit par une combinaison d'un PIC et d’un
ordinateur à carte unique Gumstix. Plusieurs Moop prennent part aux compétitions SailBot et WRSC
en 2009 et 2010. (Burnie [2010])
Université de Lübeck
L'Université de Lübeck a commencé ses activités de voile autonome en 2009. Elle a participé
à la Sailbot et à la WRSC en 2010 avec deux bateaux.
Däumling (figure 5) conçu par un Club de l'Université (Graupner, Allemagne) est un bateau
d'une longueur de 0,53 m possédant deux voiles d'une superficie totale de 0,145 m2. Il est destiné à
être utilisé comme banc d'essai pour les différentes méthodes de l'intelligence artificielle. (Bruder et
al. [2009])
Pi-mal-Daumen (figure 7) est basé sur une norme OIM (classe internationale d'un mètre)
assis sur une coque d'une longueur de 1 m et monté de deux voiles avec une surface de voilure totale
de 0,4 m2. Le tableau de commande est assuré par un circuit construit sur mesure avec un
microprocesseur ATMEGA2560. (Ammann et al. [2010])
Université de Porto
L’équipe FASt (figure 17) a mis au point une longue coque de 2,05 m construite sur mesure
coiffée d’une surface de voilure totale de 3,7 m2. Le design a été inspiré par les bateaux modernes de
course au large. Le système de contrôle est mis en œuvre sur une petite base munie d’un FPGA,
ordinateur de bord unique, comprenant un microprocesseur RISC 32 bits cadencé à 50 MHz. Une
communication avec le bateau est possible en utilisant le Wi-Fi, GSM ou un Iridium SBD et un
récepteur classique RC utilisé pour les radiocommandes de modèles réduits. FASt a participé en 2008
à la WRSC et en 2009. (Stelzer [2010])
Page 34
Projet RASV
Figure 6 Figure 7 Figure 8 Figure 9
Page 35
Projet RASV
Figure 22 Figure 23
Navires autonomes avec une longueur inférieure à 2 m :

 Figure 5 Däumling, Université de Lübeck
 Figure 6 MOOP, Université d’Aberystwyth
 Figure 7 Pi-mal-Daumen, Université de Lübeck
 Figure 8 Breizh Spirit, ENSTA Bretagne
 Figure 9 Roboat I, INNOC
 Figure 10 AROO, Université d’Aberystwyth
 Figure 11 ARC, Université d’Aberystwyth
Navires autonomes mesurant 2 m :
 Figure 12 Black Adder, Queen's University
 Figure 13 First Time, USNA
 Figure 14 Gill the Boat, USNA
 Figure 15 Luce Canon, USNA
Navires autonomes de plus de 2 m de longueur :
 Figure 16 IBoat, ISAE
 Figure 17 FASt, Université de Porto
 Figure 18 Pinta, Université d’Aberystwyth
 Figure 19 Beagle-B, Université d’Aberystwyth
 Figure 20 ASV Roboat, INNOC
 Figure 21 Avalon, ETH Zurich
 Figure 22 VAIMOS, ENSTA Bretagne et Ifremer
Page 36
Projet RASV
4) Organisation prévisionnelle du travail

Nous sommes une équipe de quatre personnes pour réaliser ce projet et avons pour encadrant
MM. Fabrice Le Bars, Olivier Ménage, Patrick Rousseaux et Bruno Aizier en ce qui concerne
l’ingénierie système. Pour la réalisation de ce projet, nous nous sommes vite rendu compte que
l’intérêt et toute la complexité de ce projet résidaient dans la diversité et la multitude des
connaissances nécessaires à sa conduite et sa réalisation :
Gestion de projet et relations humaines

Ingénierie système
Robotique et automatique
Programmation des systèmes embarqués ARDUINO et WINDOWS
Communication sans fil (Wi-Fi, Xbee,…)
Programmation d’une IHM pour le suivi de la navigation
Définition et intégration des systèmes électroniques
Traitement d’images en temps réel
Algorithme de navigation en autonomie
Nous avons réalisé un programme prévisionnel à l’aide d’un diagramme de Gantt, afin d’être
en mesure de modéliser la planification des tâches nécessaires à la réalisation, en temps et en heure,
du projet.
Liste des tâches :
Nom Date de Date Ressources

début de fin
Séquence introductive 17/09/12 28/09/12 NICOLAS Florian, BERTHOMIER
● Introduction à l’avant-projet Thibaud, DALIDEC Pierre-Emmanuel,
● Introduction à l’IS LEBLIC Valère, ZHANG Kai, Kun Jiao
● introduction à la gestion de projet
● Exigence, analyse, architecture et
spécification fonctionnelle
● Introduction au travail en équipe
● Les outils pour travailler
ensemble
● Forum des projets
Séquence avant-projet 01/10/12 12/10/12 NICOLAS Florian, BERTHOMIER

● Choix des projets Thibaud, DALIDEC Pierre-Emmanuel,
● Constitution des équipes LEBLIC Valère, ZHANG Kai, Kun Jiao
● Choix des compétences techniques
● Réunion de lancement
● Exigences et fonctions
● Interview des encadrants
Page 37
Projet RASV
● Fonctions du système
● Livrables :
■ Comptes-rendus de l’équipe projet
Interview des encadrants 08/10/12 12/10/12 NICOLAS Florian, BERTHOMIER

- Interview des encadrants du projet SIA et Thibaud, DALIDEC Pierre-Emmanuel,
Visite virtuel de l'école LEBLIC Valère, ZHANG Kai
- Rédaction du comptre-rendu de l'interview
TD Simulink 01/10/12 05/10/12 NICOLAS Florian, BERTHOMIER

Prise en main du logiciel Simulink Thibaud, DALIDEC Pierre-Emmanuel,
LEBLIC Valère, ZHANG Kai
Choix du Projet 01/10/12 05/10/12 NICOLAS Florian, BERTHOMIER
Thibaud, DALIDEC Pierre-Emmanuel,
LEBLIC Valère, ZHANG Kai, Kun Jiao
Pont en spaghetti 01/10/12 05/10/12 NICOLAS Florian, BERTHOMIER
LEBLIC Valère, ZHANG Kai, Kun Jiao
TD Stateflow 08/10/12 12/10/12
Prise en main du logiciel Statflow
Découverte du projet 08/10/12 12/10/12 NICOLAS Florian, BERTHOMIER

Découverte du projet Thibaud, DALIDEC Pierre-Emmanuel,
Réunion avec les encadrants LEBLIC Valère, ZHANG Kai, Kun Jiao
Réunion d'équipe
Recherches sur la WSRC
Séquence compétence technique 15/10/12 09/11/12 NICOLAS Florian, BERTHOMIER

● Approfondissement technique Thibaud, DALIDEC Pierre-Emmanuel,
● Avant-projet LEBLIC Valère, ZHANG Kai
● Approfondissement technique
● Évaluation individuelle de la
compétence technique
● Avant-projet
● Livrables :
■ Liste des fonctions
Exigences et Fonctions 15/10/12 09/11/12 NICOLAS Florian, BERTHOMIER

Délimitation du sujet Thibaud, DALIDEC Pierre-Emmanuel,
Recherche des fonctions LEBLIC Valère, ZHANG Kai
Réunions avec nos encadrants
Réalisation de la Bête à corne, des diagrames
pieuvre et FAST.
Réunions avec Mr Aizier

● Raffinement des fonctions Thibaud, DALIDEC Pierre-Emmanuel,
● Architecture logique LEBLIC Valère, ZHANG Kai
● Spécification fonctionnelle
● Livrables :
■ Diagramme de l’architecture logique
Planing Gant 12/11/12 16/11/12 BERTHOMIER Thibaud

Entretien encadrant 19/11/12 23/11/12 NICOLAS Florian, BERTHOMIER
Rencontre avec Mr Aizier pour discuter de Thibaud, DALIDEC Pierre-Emmanuel,
l'architecture logique/physique LEBLIC Valère, ZHANG Kai
Rédaction d'un compte rendu
Préparation des livrables
Architecture logique 12/11/12 16/11/12 NICOLAS Florian, BERTHOMIER

Utilisation des diagrammes FAST réalisés la Thibaud, DALIDEC Pierre-Emmanuel,
semaine prochaine pour réaliser l'architecture ZHANG Kai
logique du bateau (voilier et moteur)
Carte ARDUINO 12/11/12 23/11/12 NICOLAS Florian, BERTHOMIER

Se familiariser avec la carte ADUENO qui sera Thibaud, DALIDEC Pierre-Emmanuel,
Page 38
Projet RASV
par la la suite utilisée pour le voilier : LEBLIC Valère, ZHANG Kai

- Recherches sur la carte
- Tests avec une carte du laboratoire
Logo WRSC 12/11/12 23/11/12 LEBLIC Valère

Créer le logo de la WSRC organisée par
l'ENSTA Bretagne.
Code VAIMOS 12/11/12 16/11/12 NICOLAS Florian, BERTHOMIER

Séquence Compétence technique 26/11/12 14/12/12 NICOLAS Florian, BERTHOMIER
● Approfondissement technique Thibaud, DALIDEC Pierre-Emmanuel,
● Avant-projet LEBLIC Valère, ZHANG Kai
● Avant-projet
● Évaluation individuelle de la compétence
technique
● Avant-projet
● Livrables :
■ Compte-rendu de l’équipe projet
Architecture physique 19/11/12 14/12/12 BERTHOMIER Thibaud, DALIDEC

Pierre-Emmanuel, LEBLIC Valère
Choix des composants (BM) 26/11/12 21/12/12 NICOLAS Florian, BERTHOMIER
Choix des composants pour le bateau à Thibaud, DALIDEC Pierre-Emmanuel,
moteur et tests des différents composants. LEBLIC Valère, ZHANG Kai
● Plan de validation fonctionnel Thibaud, DALIDEC Pierre-Emmanuel,
● Ebauche des livrables pour l'évaluation LEBLIC Valère, ZHANG Kai
● Spécification fonctionnelle
● Livrables :
■ Compte-rendu de l’équipe projet
Etat de l'art 17/12/12 04/01/13 BERTHOMIER Thibaud, DALIDEC

Pierre-Emmanuel, LEBLIC Valère,
ZHANG Kai
Compte rendu 17/12/12 21/12/12 DALIDEC Pierre-Emmanuel, LEBLIC
Valère
Planning Gant 17/12/12 21/12/12 BERTHOMIER Thibaud, LEBLIC Valère
Préparation des livrables pour 07/01/13 15/01/13 NICOLAS Florian, BERTHOMIER
l'évaluation Thibaud, DALIDEC Pierre-Emmanuel,
Séquence évaluation 16/01/12 23/02/12 NICOLAS Florian, BERTHOMIER
● Livrables à remettre pour évaluation pair à Thibaud, DALIDEC Pierre-Emmanuel,
pair LEBLIC Valère, ZHANG Kai
● Evaluation pair à pair
● Livrables à remettre pour évaluation finale
● Evaluation finale
Page 39
Projet RASV
Réalisation du projet RASV

1) Réalisation de la mécanique
A l’origine, les épreuves de la WRSC n’étaient pas encore fixées et nous pensions donc devoir
réaliser un unique bateau, à savoir un voilier, comme le stipulent les éditions précédentes de la
WRSC. Deux choix s’offraient à nous : confectionner nous-même le voilier ou en acheter un,
dépensant ainsi la majeure partie du budget nous étant alloué. Etant données nos connaissances en
mécanique et le travail nécessaire en termes d’ingénierie système, électronique ou encore
algorithmique, nous avons choisi la deuxième solution. Toutefois, le prix de ce genre de bateau est
assez élevé et ne rentrait pas vraiment dans notre budget. Nous avions donc opté pour l’achat d’une
coque et de l’ensemble des composants nécessaires indépendamment puis d’assembler le tout.
Cependant, suite à la rencontre avec notre consultant de l’Ifremer Olivier Ménage et notre
encadrant Fabrice Le Bars, notre projet a pris une nouvelle tournure, puisque nous avons appris que
nous aurions également à charge la création d’un bateau à moteur. En effet, la compétition étant
organisée par l’école, la décision fût prise de rajouter une nouvelle catégorie de bateau lors de la
WRSC, à savoir les bateaux à moteur (hydroglisseur). Ces bateaux n’ayant pas de problèmes de
navigation liés au vent, ils doivent, en contrepartie, être capables d’éviter tous les autres bateaux et
obstacles et d’en suivre un autre, à l’aide, entre autres, d’une caméra. La conception des parties
mécaniques de ces deux bateaux devait être assurée par Mr.Ménage.
La coque du voilier est une coque de 2,60m de long pour 30 cm de large et pèse environ 25
kilos. Elle a été réalisée par Mr.Ménage à l’Ifremer. Cependant, il ne lui a pas été possible de
terminer la partie mécanique du voilier par manque de temps. Par conséquent, il a été décidé par
nos encadrants que nous nous servirions du VAIMOS, en adaptant nos codes, pour concourir dans la
catégorie voilier, ce qui a évidemment solutionné le problème de la conception mécanique du voilier.
Quant à l’hydroglisseur, après avoir attendu un long moment son arrivée, et implanté en
attendant notre système sur un drone en mousse afin d’effectuer divers tests, il a finalement été
décidé que nous utiliserions un modèle réduit de l’Azimut CHALLENGER du groupe Graupner.
Mr.Ménage puis Mr.Rousseaux nous ont permis de remettre l’hydroglisseur à neuf, en réparant puis
effectuant le montage mécanique complet, suite à l’achat de nouvelles pièces. Il mesure environ
1,20m de long pour 30 cm de large.
Photo de la coque du bateau :
Page 40
Projet RASV
2) Réalisation de l’électronique
Au cours de la phase d’avant-projet, nous nous sommes consacrés à toute la partie ingénierie
système, à la gestion de projet mais aussi au choix des composants électroniques de nos deux
bateaux afin de pouvoir élaborer l’architecture logique des deux bateaux. Nous avions commencé la
mise en relation et l’implémentation de ces éléments en fin de première phase, et les avons
approfondies lors de la phase de réalisation.
a. Choix des composants du bateau à moteur
Tout d’abord, en ce qui concerne le choix du système embarqué, plusieurs systèmes

s’offraient à nous : Smartphone, PC/104, carte ARMADEUS ou Eee PC. Le système de calcul doit être
en mesure de faire fonctionner les différents algorithmes de navigation mais aussi le traitement
d’images en temps réel, ce qui exige une puissance de calcul assez élevée. En accord avec nos
encadrants, nous avons choisi d’embarquer un Eee PC. Il dispose en effet du meilleur rapport
poids/performance et d’un avantage en termes d’autonomie, ne nécessitant pas forcément
d’embarquer des batteries supplémentaires à bord.
Pour les autres composants nécessaires à l’hydroglisseur (propulseurs, cartes de puissance,

GPS, module Wi-Fi, caméra, adaptateurs, centrale inertielle), nous avons utilisé des composants que
l’école avait en stock et qui ont déjà été utilisés au cours de projets précédents. Cela permet ainsi de
ne pas partir de zéro et de pouvoir se servir de l’existant (VAIMOS, SAUCISSE,..) pour notre bateau.
Toutefois, pour l’évitement d’obstacle, nous avons cherché quel pourrait être le meilleur composant
permettant la détection des obstacles, à savoir un sonar, une caméra, radar, l’AIS... Notre choix s’est
finalement porté sur la caméra (car obligatoire pour certaines épreuves) pour la détection
d’obstacles visibles. Pour les obstacles dit connus, à savoir ceux qui enverront via Wi-Fi ou Xbee des
informations sur leur position, vitesse et taille, nous avons décidé de simplement effectuer un
traitement sur les données recueillies, et donc de mettre en place une antenne Wi-Fi ou un module
XBee (plutôt Wi-Fi étant donnée les difficultés rencontrées face au XBee et évoquées plus tard).
Il y avait en revanche un choix à faire en ce qui concerne la connexion du GPS, des cartes de
commande et de la centrale inertielle : utiliser une carte LabJack ou une carte SSC-32. Dans un
premier temps, nous étions tentés par les cartes LabJack car nous en avions à notre disposition et
nous avions trouvé de nombreux tutoriels en lien avec cette carte. Mais, après des tentatives de tests
et sur les conseils de Mr. Ménage, nous avons décidé de modifier légèrement l’architecture de notre
système, afin de s’affranchir de l’utilisation des cartes LabJack (notices et tutoriels basiques
compliqués à trouver). Dans l’idée, nous permuterons simplement les emplacements du groupe «
moteurs » et du GPS, et nous n’utiliserons que le convertisseur USB-série ainsi qu’une carte SSC-32
pour recueillir les données du GPS, de la centrale, et actionner les moteurs.
Voici à quoi ressemblait initialement l’architecture logique de l’hydroglisseur : cf. page

suivante.
Page 41
Projet RASV
Page 42
Projet RASV
Page 43
Projet RASV
Suite au changement d’hydroglisseur, il a été nécessaire d’apporter quelques petites

modifications à notre système et donc à notre architecture logique, essentiellement parce que le
système de propulsion du Challenger n’était pas le même que celui prévu au départ. En effet, celui-ci
est propulsé par l’intermédiaire de deux moteurs faisant fonctionner deux hydrojets. Le reste de la
partie électronique reste le même, chacun des moteurs étant commandé par une carte navy control.
Cependant, étant donnés la puissance nécessaire au fonctionnement des deux moteurs et l’ajout de
la caméra, le système fonctionne avec trois batteries. Le fonctionnement de chaque moteur
nécessite une batterie, et la troisième permet d’alimenter la carte SSC-32 et la caméra présentes à
bord. L’ordinateur reste quand à lui sur sa propre batterie.
b. Choix des composants du voilier

De même, en ce qui concerne le choix du système embarqué, plusieurs systèmes s’offraient à
nous : Smartphone, PC/104, carte ARDUINO, carte ARMADEUS ou Eee PC. Nous avons choisi d’utiliser
une carte ARDUINO Mega car le codage s’effectue en C adapté (pas de système d’exploitation), la
carte est petite, légère, peu onéreuse et consomme peu d’énergie. La carte convient également pour
faire tourner tous les algorithmes de navigation. Elle est multiplateforme car on peut la programmer
avec Windows, Mac et Linux. De nombreuses librairies sont disponibles avec diverses fonctions
implémentées. Le logiciel et le matériel est open source et extensible. Il existe aussi de nombreux
modules (« shields » qui se connectent sur le module Arduino pour augmenter les possibilités comme
par exemple : afficheur graphique, interface ethernet, GPS, WiFi, etc...). Cependant, elle serait vite
limitée dans le cas de traitement d’images, mais le voilier n’étant pas prévu pour cela initialement, le
problème n’existait pas
Pour les autres composants nécessaires au voilier (servo-moteurs, station météo,

boussole,…), nous avons utilisé des composants que l’école avait en stock et qui ont déjà été utilisés
au cours de projets précédents. Cela permet, comme précédemment pour l’hydroglisseur, de ne pas
partir de zéro et de pouvoir se servir de l’existant (VAIMOS, SAUCISSE,..) pour notre bateau. En ce qui
concerne la détection et l’évitement d’obstacles, nous avions opté ici aussi pour la récupération des
données des obstacles connus par Wifi, le voilier ne devant initialement pas concourir au suivi ou à
l’évitement d’obstacle inconnu.
Page 44
Projet RASV
Voici à quoi ressemblait initialement l’architecture logique du voilier :
Page 45
Projet RASV
Page 46
Projet RASV
Page 47
Projet RASV
Même si nos architectures physique et logique étaient correctes et validées par notre
consultant en ingénierie système, l’absence de la partie mécanique du voilier et la date butoir se
rapprochant a décidé nos encadrants à nous faire utiliser le VAIMOS en tant que voilier pour notre
projet. L’ensemble des nouvelles architectures existe donc déjà, et est disponible dans le rapport de
PFE de Mr.Ménage. Il reste cependant à implémenter certains scripts dans le code de VAIMOS et le
tester afin qu’il soit opérationnel lors de la WRSC.
3) Paramétrage des moyens de communication
a. La technologie Wifi
Cette technologie est utilisée aussi bien sur
l’hydroglisseur que sur le bateau. Pour le premier, elle doit
permettre de contrôler le Eee PC à distance. Pour le second,
elle lui est utile afin de communiquer toutes ses données de
navigation comme sa position GPS, sa vitesse, son cap, la
force du vent…
Toutefois, nous n’avons pas utilisé les Ubiquiti (photo

ci-contre) mais plutôt celle qui est embarquée sur le Eee PC ou le shield Wifi pour l’Arduino. Lors de
la compétition ou lors de tests sur des vastes étendues, l’Ubiquiti devient nécessaire pour ne pas
perdre la communication avec le bateau autonome. Les deux prochains paragraphes expliquent
comment configurer les PC branchés aux Ubiquiti via ethernet et comment paramétrer les Ubiquiti
pour créer un pont Wifi entre les deux PC.
i. Configurer la connexion Ubiquiti/PC en réseau local :
1. Aller dans Panneau de Configuration > Centre de Réseau et Partage > Connexions locales
2. Dans Statut de la connexion > Onglet Général, cliquer sur Propriétés
3. Dans l’onglet général, sélectionner Internet Protocol (TCP/IP) et cliquer sur Propriétés
4. Entrer votre adresse IP (par défaut, l’Ubiquiti a pour adresse 192.168.1.20 donc il faut entrer
une adresse différente comme 21) : ici doit être différent de 67 et 68
5. Entrer le masque réseau : 255.255.255.0
6. Entrer l’adresse IP de la passerelle : (par défaut : 192.168.1.20) : ici : 192.168.1.68
Page 48
Projet RASV
ii. Configuration des Ubiquiti pour faire un pont Wifi entre deux PC
Accès à la page de
PC1 PC2
configuration
Adresse http 192.168.1.67 192.168.1.68
Username ubnt
Password ubnt
Onglet Wireless PC1 PC2

Mode sans fil WDS du poste WDS Point d’accès
SSID RASVWifiMotorBoat RASVWifiMotorBoat
Sécurité Aucune Aucune
Onglet Network PC1 PC2

Mode réseau Pont Pont
Disable Network None None
Adresse IP du port Statique Statique
Adresse IP 192.168.1.67 192.168.1.68
Masque réseau 255.255.255.0 255.255.255.0
IP Passerelle 192.168.1.68 192.168.1.68
Onglet Services PC1 PC2

Telnet/port /23 /23
SSH/port /22 /22
Onglet System PC1 PC2

Nom d’hôte RASVWifiMotorBoat2 RASVWifiMotorBoat1
b. La technologie Xbee
i. Objectif :
Le but de l’utilisation de modules Xbee dans le voilier autonome est de pouvoir programmer
la carte Arduino à distance. En effet, une fois le matériel embarqué dans le voilier et ce-dernier mis à
l’eau, il s’avère peu pratique d’ouvrir la boîte étanche contenant l’Arduino et de la brancher au PC
pour programmer la carte. L’intérêt du Xbee serait donc de s’affranchir des problèmes d’étanchéité
qui pourraient se produire en ouvrant les boîtes étanches mais aussi et surtout de pouvoir
programmer la carte à distance sans avoir à se brancher à la carte.
Page 49
Projet RASV
ii. Configurer les modules Xbee
Pour établir une communication avec l’ordinateur, nous avons utilisé les différents éléments
ci-dessus. La communication en direct sans passer par une Arduino permet de configurer rapidement
le module Xbee. La communication entre l’ordianteur et le Xbee se fait via une liaison série
asynchrone. Le Xbee n’a donc besoin que de quatre fils : deux pour l'alimentation (la masse et le +),
un pour la réception et un pour l'émission. En effet le XBee permet de recevoir et d'émettre des
données en même temps, on dit qu'il est full duplex.
Afin de configurer les modules Xbee, il est conseillé d’utiliser le logiciel XTCU qui a été créé
par les développeurs de cette technologie et qui permet de régler les différents paramètres
(Identifiant du réseau, Channel de communication, mode de fonctionnement,…). Dans notre cas,
nous voulons réaliser une simple liaison RS232 sans fil donc nous allons configurer nos modules dans
le mode « peer to peer ». Les réglages sont alors les suivants :
 PanID et Channel sont identiques pour les 2 Xbee
 CE = 0 (Choix du mode « peer to peer »)
 A1=1
 A2=0
Pour mettre en place ces réglages, nous raccordons les Xbee au PC et dans un terminal (par
exemple celui de XTCU) et nous suivons les étapes suivantes :
 Mise en mode configuration (+++ et AT)
 ATND permet de récupérer les informations sur le module
 ATCN permet de quitter le mode de configuration
Page 50
Projet RASV
iii. Communication entre un PC et l’ARDUINO via Xbee :

Pour pouvoir communiquer via Xbee avec
une Arduino, il suffit d’installer le shield Xbee sur la
carte, comme sur la photo ci-contre :
Il est ensuite possible de faire

communiquer les deux Xbee, soit en ouvrant deux
terminaux : un sur le Xbee connecté au PC, l’autre
sur la Arduino ; soit en téléportant un programme
sur l’Arduino qui envoie des messages via Xbee.
Exemple de programme :
*/
#include <SoftwareSerial.h>
SoftwareSerial xbee(2, 3); // RX, TX

char c = 'A';
int pingPong = 1;
void setup() {
Serial.begin(57600);
Serial.println( "Arduino started sending bytes via XBee" );
// set the data rate for the SoftwareSerial port

xbee.begin( 19200 );
}
void loop() {
// send character via XBee to other XBee connected to Mac
// via USB cable
xbee.print( c );
//--- display the character just sent on console ---

Serial.println( c );
//--- get the next letter in the alphabet, and reset to ---
//--- 'A' once we have reached 'Z'.
c = c + 1;
if ( c>'Z' )
c = 'A';
//--- switch LED on Arduino board every character sent---

if ( pingPong == 0 )
digitalWrite(13, LOW);
else
digitalWrite(13, HIGH);
pingPong = 1 - pingPong;
delay( 1000 );
iv. Résultats de nos expérimentations :

Malheureusement, nous n’avons su répondre à l’objectif initial. En effet, nous n’avons pas
réussi à remplacer la liaison série filaire entre l’Arduino et le PC par une liaison série Xbee sans fil
dans le but de programmer la carte Arduino à distance. Toutefois, nous sommes arrivés à
communiquer entre deux Xbee, chacun connecté à un PC différent, mais aussi un connecté à un PC,
l’autre à l’Arduino.
Page 51
Projet RASV
c. La station météo
En s’inspirant des programmes existants du voilier autonome VAIMOS, nous devions créer un
code Arduino permettant de récupérer les données de navigation dont le voilier a besoin. Nous
utilisons la station météo WS-200 qui est fabriquée par FURUNO. Elle nous fournit toutes les
informations sur le temps et l’environnement où nous travaillons. Parmi ce flux de données, toutes
ne nous intéresse pas, il faut donc que notre programme fasse certains choix afin qu’il récupère
seulement le temps, la vitesse du vent, la direction du vent, la position (la longitude et l’attitude)
ainsi que le cap.
Afin d’organiser et clarifier la tâche à effectuer, nous avons divisé notre travail en trois étapes :
La configuration de la station météo
La communication entre la station et la carte Arduino UNO
La programmation de la carte Arduino UNO pour enregistrer les données de
navigation dans le bon format.
Premièrement, pour configurer la station météo, nous avons essayé de la configurer en utilisant
un logiciel qui lui est spécialement dédié. Mais, au vu du peu de succès que nous avions avec ce
logiciel, nous avons décidé d’utiliser l’HyperTerminal. Nous avons alors réussi à paramétrer la station
afin qu’elle nous envoie seulement les données utiles.
Ensuite, nous avons effectué de nombreux tests pour trouver un convertisseur simple qui nous
permettrait de récupérer le signal transmis en RS484 en un signal RS232, compatible avec l’Arduino
UNO. Mais au final, nous nous sommes procurés un shield Arduino qui s’appelle RS485 et qui a rendu
possible cette conversion ainsi que la transmission des données. Nous avons donc opté pour cette
solution et sommes passés à l’étape suivante.
Ainsi, nous avons créé un petit programme qui permet d’enregistrer dynamiquement les
données de navigation. Les données sont ensuite extraites dans le but de les afficher au bon format.
Page 52
Projet RASV
4) Avancement de l’hydroglisseur
a. Paramétrage et test des cartes de puissances et
propulseurs
Après quelques tests afin de comprendre le fonctionnement des cartes de commande, et la

prise en main du logiciel associé, nous avons fini par pouvoir commander manuellement les vitesses
et sens de rotation des deux propulseurs (commande par signaux PWM). Dans un souci de
téléopérabilité de notre système final, nous avons donc envisagé une commande à distance. Ci-
dessous se trouve le schéma initial de téléopération des propulseurs :
Schéma du montage :
Page 53
Projet RASV
b. Rappels de l’architecture physique
c. Epreuve de suivi de cibles

i. Traitement d’images en temps réel
Comme nous avons pu le voir lors de la phase dédiée à l’architecture fonctionnelle, nous
procédons comme suit pour être en mesure de suivre une cible grâce à sa couleur :
Cependant, bien que le résultat se soit avéré concluant avec cette méthode, nous nous
sommes rendu compte que la librairie OpenCV, via la fonction GetMoments(), calculait le centre de
Page 54
Projet RASV
gravité des pixels colorés grâce à la moyenne, alors qu’une médiane serait bien plus robuste en
présence de valeurs extrèmes (pixels isolés apparaissant dans le champ de vision et n’appartenant
pas à la cible).
Ainsi, nous avons décidé de laisser de côté cette moyenne en programmant notre propre
algorithme de calcul du barycentre via cette médiane, comme en témoigne la portion de code ci-
dessous :
def imageProcess(im,hmin,hmax,smin,smax,vmin,vmax,width,height):
imghsv=cv.CreateImage(cv.GetSize(im),8,3)
# Conversion RGBHSV
cv.CvtColor(im,imghsv,cv.CV_BGR2HSV)
nbSelectedPixel=0
obji=0
objj=0
# Deux boucles pour parcourir les lignes et les colonnes de pixels de l’image
for i in range(height):
for j in range(width):
# Récupération du pixel
pixel=cv.Get2D(imghsv,i,j)
# Si le pixel répond aux critères de couleurs
if pixel[0]>=hmin and pixel[0]<=hmax and pixel[1]>=smin and pixel[1]<=smax and pixel[2]>=vmin and
pixel[2]<=vmax:
nbSelectedPixel=nbSelectedPixel+1
# On ajoute son abscisse et ordonné à notre variable
objj=objj+j
obji=obji+i
# On assigne la couleur rouge au pixel
cv.Set2D(imghsv,i,j,cv.Scalar(255,0,0))
else:
cv.Set2D(imghsv,i,j,cv.Scalar(0,0,0))
return imghsv, nbSelectedPixel, obji, objj
Ainsi nous sommes capable d’en déduire les coordonnées (x,y) du barycentre :
x= et y=
Cependant, il faut se rappeler qu’au-delà du calcul du barycentre, nous effectuons divers

traitements pour éliminer les pixels isolés, comme nous pouvons le voir sur le haut de la page
suivante.
Page 55
Projet RASV
En revanche, le filtre gaussien, l’érosion et la dilatation ont dû être supprimés car la vitesse
de traitement d’images s’effondrait, ce qui altérait considérablement le comportement de notre
hydroglisseur.
Toutefois, cela n’est pas si dramatique puisque, comme nous l’avons dit précédemment, la
médiane est plus robuste que la moyenne.
Enfin, en raison de ces possibles pixels isolés, il est désormais nécessaire de fixer un seuil,
ratio entre le nombre de pixels de même couleur que l’objet et le nombre total de pixels (résolution).
Ainsi, si l’on se trouve au-dessus de ce seuil, on considérera que la cible est en vue et le suivi de cible
sera effectuer, et, le cas échéant, qu’elle ne l’est pas et le robot pivotera sur lui-même pour la
retrouver.
Quant à la distance, on est capable de calculer le rayon apparent de l’objet ainsi (méthode
empirique) :
Avec width : largeur de l’image

: Nombre de pixels sélectionnés (correspondant à la couleur)
: Nombre total de pixels de l’image (= résolution)
Ensuite, pour en déduire la distance, la formule empirique suivante permet d’y parvenir :
Avec : Distance estimée entre la caméra et l’objet
Page 56
Projet RASV
: Rayon réel de l’objet, supposé connu

: rayon apparent précédemment calculé
: Taille représentée par un pixel (dépend de l’ouverture horizontale de la
caméra, voir le code pour plus de précision)
Voici un exemple de résultat :
Avec cible Sans cible
ii. Régulation
Pour tester nos algorithmes de régulation, nous avons équipé un modèle char d’une caméra
et de notre servo-controleur SSC-32 pour être en mesure de traquer une cible.
Nous avons ainsi mis en place une simple commande proportionnelle, agissant
simultanément sur le cap et la distance, de la forme :
Avec : Coefficients pour le cap et pour la distance

, : Erreurs normalisée pour le cap et la distance
Une fois les coefficients réglés grâce à nos nombreux tests, le résultat c’est avéré très
concluant, ce qui nous a immédiatement amené à appliquer une telle régulation sur notre
hydroglisseur en mousse qui était disponible à l’école, à tort…
Page 57
Projet RASV
En effet, une fois notre robot à l’eau… le robot semblait faire tout et n’importe quoi, ce qui
nous a amené à remettre en question notre régulation. Sur les conseils de Fabrice LEBARS, nous
avons simplifié notre commande comme suit :
Avec et U=
Cependant, cela n’ayant pas réglé le problème, nous avons consulté Mr JAULIN, qui nous a
conseillé d’ajouter un terme dérivé à notre régulateur pour contrer le phénomène d’inertie de l’eau.
Ainsi, en tenant compte de l’inertie, nous aboutissons à la commande suivante, dont les tests
ont donné une entière satisfaction.
Avec et U=
Page 58
Projet RASV
Cependant, une fois n’est pas coutume, des modifications ont été apportées au projet,
entrainant ainsi un changement de bateau, dont la commande est légèrement différente puisque
qu’il ne s’agit plus d’un différentiel.
Ainsi, il n’est plus possible d’inverser le sens de rotation des hélices, le sens de
marche étant géré par des inverseurs de flux. De plus, pour la gestion du cap, un
servomoteur permet l’orientation du robot.
Page 59
Projet RASV
d. Navigation autonome de l’hydroglisseur

i. Description du programme
VNav est le programme s’exécutant sur l’hydroglisseur qui gère la navigation autonome. Il
contrôle les deux propulseurs en fonction des données de la boussole/centrale inertielle, du GPS et
des waypoints demandés.
Ce programme est une application Python et utilise les fichiers de configuration suivante :
 Waypoints.csv : fichier dans lequel sont entrés tous les Waypoints
 Navpoints.csv : fichier dans lequel sont stockés la position et le cap du bateau à
chaque instant
Les fichiers sources utilisés par ce programme sont :

 Nav_main : contient le code principal
 VNav : communique par liaison série avec la carte de contrôle des propulseurs.
 Waypoints : gestion des waypoints
 gps : communique avec le GPS
 imu : communique avec la station inertielle
ii. Fonctionnement du programme

L’exécution du programme se déroule de la manière suivante. Au lancement, le programme
ouvre le fichier ‘Navpoint.csv’ dans lequel seront stockées toutes les données de navigation à chaque
instant. Ensuite, il initialise toutes les variables qui seront utilisées par la suite. Le fichier contenant
tous les waypoints est ensuite ouvert et lu. Un repère de référence est défini avec pour origine la
position GPS actuelle, ce qui permet ensuite de calculer la longueur et l’angle de la première ligne à
suivre. Vient alors la boucle principale :
 Sauvegarde des données de navigation

 Vérifie si l’utilisateur ne veut pas stopper le programme c'est-à-dire si l’utilisateur n’a
pas appuyé sur une des touches du clavier
 Récupération des données actuelles des capteurs : position GPS, le cap suivi ; et
conversion diverses pour les exprimer dans le repère de référence
 Test de fin de ligne : si le bateau a passé la perpendiculaire à la ligne courante
passant par le deuxième waypoint formant la ligne courante, alors il passe à la ligne suivante. Si le
dernier Waypoint est atteint, passage en mode de station, c'est-à-dire que le bateau défini des lignes
temporaires allant de sa position actuelle au dernier waypoint. Il devrait donc toujours chercher à
revenir vers le dernier waypoint.
 Calculs divers
 Calcul du cap à essayer de suivre
 Calcul des commandes à appliquer aux propulseurs pour que le bateau suive ce cap
 Application des commandes aux propulseurs
Cette boucle s’exécute tant que l’utilisateur n’appuie sur aucune touche du clavier. Dès
l’appui sur une des touches de clavier, le programme termine la boucle, ferme le fichier dans lequel
sont enregistrées les données de navigation puis s’achève.
Page 60
Projet RASV
iii. Limite du programme :

Le programme n’a pas été testé dans des conditions réelles de navigation. L’utilisation du
GPS nécessite des tests en extérieurs et dans un lieu suffisamment vaste pour qu’il n’y ait pas de
problèmes dus à la précision du GPS (qui est de l’ordre de quelques mètres).
Pour tester le programme, nous avons créé une fonction getPosGPS2() qui renvoie une
position GPS calculée en fonction des commandes données au moteur. Toutefois, les coefficients
utilisés ne permettent pas de vérifier que l’algorithmie du programme fonctionne et des tests
grandeurs nature sont nécessaires.
Page 61
Projet RASV
Et après ?
Les tests en milieu naturel ont révélé que notre traitement d’images, bien que répondant à
nos attentes, montrait quelques limites en présence de conditions défavorables (contre-jour,…).
Ainsi, il pourrait s’avérer intéressant d’implémenter de nouveaux algorithmes plus robustes, basés
sur une estimation d’état, tels que le filtrage de Kalman Discret, Hidden Markov ou l’algorithme
CamShift, plus répandu, qui se base sur la couleur et la forme de l’objet pour en faire la détection.
Pour le calcul de notre erreur qui apparait dans le régulateur dérivé, nous utilisons le flux
optique. Ainsi, si une cible se meut trop rapidement et n’apparait plus à l’écran, cela devient
compliqué, d’où l’intérêt d’utiliser la boussole pour le calcul de cette erreur.
Pour que l’hydroglisseur soit fonctionnel en toutes circonstances, il pourrait être intéressant
de lui ajouter un terme intégral dans sa régulation pour compenser l’erreur statique (utile en cas de
mer agitée).
N’ayant procédé qu’à des simulations pour la navigation autonome, il serait souhaitable de
tester une telle fonctionnalité en condition réelle.
En ce qui concerne le voilier, seule la coque étant à disposition, une majeure partie du travail
reste à faire pour espérer le voir participer à une future compétition, bien que certaines
fonctionnalités électroniques et logicielles, telles que le traitement des données de la station météo,
soient opérationnelles.
Page 62
Projet RASV
Conclusion
La création d’un projet est constituée de deux phases, celle de conception et celle de
réalisation. Le premier semestre aura été pour nous l’opportunité d’effectuer la phase de conception
du projet RASV. Après nous être dans un premier temps largement documentés sur le sujet, par
l’intermédiaire de recherches externes et de discussions avec nos encadrants, nous avons entamé le
travail de réflexion autour du système que nous aurions à créer. Pour cela, nous avons consulté à de
nombreuses reprises MM. Ménage, Le Bars et Aizier, afin d’organiser au mieux les solutions
techniques que nous allions déployer, et d’en avoir une vue d’ensemble claire et exhaustive. De
nombreux documents ont été créés lors de cette étude, à savoir tous les documents traitant de
l’architecture logique et de l’analyse fonctionnelle de notre système. En termes de gestion, nous
avons également établi de façon hebdomadaire les parts de travail de chaque membre de l’équipe,
afin d’augmenter au maximum notre rendement.
Après cette phase de conception et d’organisation est venue la phase de réalisation. Les
premiers tests unitaires ont été un moyen efficace d’appréhender et de vérifier le bon
fonctionnement des systèmes que nous avions élaborés. Suite au bon déroulement de ces tests, nous
avons pu associer les parties logicielle et mécanique afin d’effectuer nos premiers tests de suivi de
cible à échelle réduite, avant de les effectuer à taille réelle sur le nouvel hydroglisseur. Après
quelques désagréments et ajustements, nous avons fini par aboutir à un résultat plutôt satisfaisant.
Nos tâches concernant le voilier consistaient essentiellement à mettre au point les divers
moyens de communication dont il serait équipé, l’essentiel du code régissant la navigation étant à
reprendre du VAIMOS, bien que nous ne soyons pas parvenus à obtenir les résultats souhaités pour
l’ensemble de nos tentatives.
L’UV 4.4 aura été pour nous l’occasion de découvrir l’élaboration complète d’un projet, nous
faisant notamment découvrir l’importance et la nécessité de la phase de conception et les difficultés
inhérentes à la phase de réalisation. En effet, nous avons du faire face à plusieurs problèmes, que
nous avons pu solutionner pour certains, après des phases de questionnement et de concertation au
sein de l’équipe. D’autres n’ont pas pu être résolus, à cause de divers problèmes, notamment de
manque de temps. De façon globale, ce projet nous aura permis d’adopter une démarche
professionnelle, de la simple conception de projet à sa réalisation finale. Il nous aura été de ce point
de vue très instructif dans l’optique de notre future vie professionnelle. Même si le projet n’a pu
complètement aboutir, nous espérons avoir facilité de façon significative la tâche de nos successeurs
et contribué à la future réussite des deux bateaux lors de la WRSC en septembre prochain.
Page 63
Projet RASV
Bibliographie
BRIÈRE (2006). The first microtransat challenge, http://web.ensica.fr/microtransat, ENSICA
ELKAIM, G. (2006). The Atlantis project: A GPS-guided wing-sailed autonomous catamaran.

Navigation
MENAGE O. (2011), Rapport du projet de fin d'étude : VAIMOS, ENSTA Bretagne
SAUZE, C. & NEAL, M. (2010). A Raycast Approach to Collision Avoidance in Sailing

Robots
SCHIEBEN, E.W. (1969). SKAMP - an amazing unmanned sailboat! Ocean Industry
SPIEGEL (1998). Fliegender Schwarzwälder. Der Spiegel
STELZER (2010), Autonomous Sailboat Navigation, De Montfort University, Leicester
JAULIN, L. (2011), Contrôleurs et Observateurs, ENSTA Bretagne

www.ensta-bretagne.fr/jaulin/poly_etat_ensi2.pdf
Communication sans fil avec Xbee : http://www.bde.enseeiht.fr/clubs/robot/node/34
Xbee et Arduino : http://jeromeabel.net/ressources/xbee-arduino#toc6
Tutorial : Arduino and Xbee Communication :

http://cs.smith.edu/dftwiki/index.php/Tutorial:_Arduino_and_XBee_Communication
Communication à l’aide du protocole ZigBee entre un PC et une carte Arduino :

http://www.csquad.org/2009/09/06/communication-a-laide-du-protocole-zigbee-entre-un-pc-et-
une-carte-arduino-2/
Page 64
Projet RASV
Annexes
Bête à cornes (RASV-BC-11.11.12.pdf)

Diagramme Pieuvre du Voilier (RASV-PIV-11.11.12.pdf)
Diagramme Pieuvre de l’Hydroglisseur (RASV-PIM-11.11.12.pdf)
Diagramme FAST (RASV-FA-11.11.12.pdf)
Analyse Fonctionnelle (RASV - AF - 25.11.12.pdf)
Validation Fonctionnelle (RASV-VF-21.01.13.pdf)
Etat de l’Art (RASV-EA-12.01.13.pdf)
Diagramme de Gantt (RASV-GA-17.01.13.pdf)
Architecture Logique de l’Hydroglisseur (RASV - ALH - 25.11.12.pdf)
Architecture Logique du Voilier (RASV - ALV - 25.11.12.pdf)
Dossier d’architecture de l’Hydroglisseur (RASV-DAH-220313.pdf)
Dossier d’architecture du Voilier (RASV-DAV-220313.pdf)
Schéma du montage pour commander les propulseurs à l’aide de la
télécommande (RASV-SCHEMA-20122012.pdf)
Compte-rendu d’interview (RASV-IN-04102012.pdf)
Comptes-rendus intermédiaires :
o 01 octobre 2012 (RASV-CR-01102012.pdf)
o 08 novembre 2012 (RASV-CR-08112012.pdf)
o 06 décembre 2012 (RASV-CR-06122012.pdf)
o 13 décembre 2012(RASV-CR-13122012.pdf)
o 20 décembre 2012 (RASV-CR-20122012.pdf)
o 10 janvier 2013 (RASV-CR-10012013.pdf)
o 12 avril 2013 (RASV-CR-12042013.pdf)
o 18 mai 2013 (RASV-CR-18052013.pdf)
Page 65
Projet RASV
Projet RASV
Over the past few years, innovations in the field of autonomous vehicles such as AUVs
(Autonomous Underwater Vehicles) and UAV (Unmanned Aerial Vehicles) have been steadily
increasing and their application scopes are becoming more and more numerous.
Autonomous sailboats and motorboats, although they are not widespread yet, play a leading
role in the domain of marine observation and monitoring as they are able to measure sea
temperature, salinity or chlorophyll rates. In the case of motor boats, they are already used for
military security and safety close to shore.
Beyond such applications, several sailboats and motorboats take part every year in the WRSC
(World Robotic Sailing Championship), where they compete in multifarious trials, ranging from
autonomous navigation based on beforehand set waypoints to target tracking using real-time image
processing, through boat towing.
Furthermore, besides the main objective which consists in taking part in this regatta, the
numerous devices which equip our vehicles give us a glimpse of their potential future application.
Indeed, the real-time image processing could allow us to map the marine area to look for emerged
objects, in collaboration with UAVs, to search for plane fragments after crashes for example.
Page 66

Rasv-Raf-13 06 2013

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rasv-Raf-13 06 2013

Transféré par

Droits d'auteur :

Formats disponibles

Projet RASV

World Robotic Sailing Championship

Table des matières

2) Les règles ..................................................................................................................................................................... 6

Présentation du projet RASV .................................................................................................................................................... 13

2) Validation fonctionnelle ........................................................................................................................................... 24

a. Validation des fonctions........................................................................................................................................ 24

a. Premiers exemples ................................................................................................................................................ 28

Réalisation du projet RASV ....................................................................................................................................................... 40

a. Choix des composants du bateau à moteur............................................................................................................ 41

a. La technologie Wifi .............................................................................................................................................. 48

a. Paramétrage et test des cartes de puissances et propulseurs .................................................................................. 53

Nos remerciements s'adressent dans un premier temps au pôle d'enseignement SPID de

Nous tenons à remercier tout particulièrement et à témoigner toute notre reconnaissance

Messieur Bruno AIZIER, Expert en modélisation de systèmes embarqués au sein de

L'IFREMER, et tout particulièrement Messieurs Olivier MENAGE, Ingénieur, et Patrick

Le document ci-présent retrace donc l’élaboration progressive et complète de notre projet,

Résumé du Projet RASV

World Robotic Sailing Championship

La tenue de la conférence internationale de robotique à la voile (IRSC) est le moment idéal

Figure 1 – Zones de compétition

Durée max d’une tentative : 15 min

3) Epreuve de vitesse en vent arrière

Durée max : 30 min

4) Epreuve de vitesse face au vent

Epreuve précédente en sens inverse

5) Epreuve de vitesse en vent de travers

Epreuve précédente en travers

6) Epreuve d'évitement d'un obstacle mobile de position connue

Durée max d’une tentative : 60 min

7) Epreuve d'évitement d'un obstacle immobile bien visible en ligne droite

Durée max d’une tentative : 45 min

8) Epreuve d'évitement d'un obstacle immobile inconnu en ligne dro ite

Epreuve précédente mais avec un grand obstacle sans couleur particulière.

Durée max d’une tentative : 45 min

Suivre de manière autonome un zodiac muni d'une bouée de 50 cm de diamètre et de couleur

Durée max d’une tentative : 10 min

10) Epreuve de remorquage et coopération

Durée max d’une tentative : 45 min

11) Epreuve d'endurance et mesures (sponsorisée par Ifremer ?)

Durée max d’une tentative : 10 h

12) Epreuve spéciale du voyageur de commerce (sponsorisée par ENSTA

Déroulement des épreuves

Présentation du projet RASV

Dans le cadre de l’option (Systèmes, Perception, Informations, Décision) lors de notre

Les deux prototypes devront être capables de :

• Avoir une autonomie énergétique suffisante pour plusieurs jours de fonctionnement.

Diagramme pieuvre du voilier

Diagramme pieuvre de l’hydroglisseur

Conaître les donées de

Connaître le sens du vent

Naviguer en portant : Algorithme et actionneurs

a. Validation des fonctions

i. Navigation en autonomie sur un plan d’eau

Pour le voilier, nous distinguons deux cas :

Vent arrière (navigation en portant/de près) :

ii. Interaction avec le milieu extérieur

Détection d’obstacles inconnus :

Détection d’obstacles connus :

A l’origine, nous devions procéder de la façon suivante. L’hydroglisseur devait tracter le

iii. Interaction avec l’utilisateur

b. Logistique, durée et coût de la validation fonctionnelle

Figure 2 : SKAMP (Station Keeping Figure 3 : RelationShip Figure 4 : Atlantis