HAL Id: dumas-01275216
https://dumas.ccsd.cnrs.fr/dumas-01275216
Submitted on 17 Feb 2016
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
fonctionnalités avancées d’aide à la conduite
Nicolas Vignard
To cite this version:
Nicolas Vignard. Mise en place d’un démonstrateur expérimental de fonctionnalités avancées d’aide à la conduite. Interface homme-machine [cs.HC]. 2013. �dumas-01275216�
CONSERVATOIRE NATIONAL DES ARTS ET METIERS
CENTRE REGIONAL RHÔNE-ALPES
CENTRE D'ENSEIGNEMENT DE GRENOBLE
___________________________________________________
MEMOIRE
présenté par Nicolas Vignard
en vue d'obtenir
LE DIPLÔME D'INGENIEUR C.N.A.M.
en INFORMATIQUE
________________________
Mise en place d'un démonstrateur expérimental
de fonctionnalités avancées
d'aide à la conduite
Soutenu le 21 février 2013
________________________
JURY
Président : M. Eric Gressier-Soudan (CNAM Paris)
Membres : M. Claude Genier (CNAM Lyon)
M. Jean-Pierre Giraudin (Université de Grenoble)
M. Christian Laugier (Inria Grenoble)
M. Mathias Perrollaz (Inria Grenoble)
CONSERVATOIRE NATIONAL DES ARTS ET METIERS
CENTRE REGIONAL RHÔNE-ALPES
CENTRE D'ENSEIGNEMENT DE GRENOBLE
___________________________________________________
MEMOIRE
présenté par Nicolas Vignard
en vue d'obtenir
LE DIPLÔME D'INGENIEUR C.N.A.M.
en INFORMATIQUE
________________________
Mise en place d'un démonstrateur expérimental
de fonctionnalités avancées
d'aide à la conduite
Soutenu le 21 février 2013
________________________
Les travaux relatifs à ce mémoire ont été effectués au sein de l’équipe e-Motion d’Inria (Institut national de recherche en informatique et en automatique), sous la direction de M. Christian Laugier et de M. Mathias Perrollaz.
Remerciements
Tout d’abord, je tiens à remercier toutes les personnes qui me font l’honneur de participer au jury de ce mémoire :
Monsieur Eric Gressier-Soudan, professeur au CNAM Paris et président du jury ; Monsieur Claude Genier, responsable régional EICNAM Lyon ;
Monsieur Jean-Pierre Giraudin, professeur à l’Université Pierre Mendès France de Grenoble ; Monsieur Christian Laugier, directeur de recherche Inria ;
Monsieur Mathias Perrollaz, ingénieur expert Inria.
Je tiens à remercier mes tuteurs Dr Christian Laugier, directeur de recherche à l’Inria et responsable scientifique de l’équipe-projet e-Motion, ainsi que Dr Mathias Perrollaz, ingénieur expert dans cette même équipe, pour ce sujet à la pointe de l’innovation et pour le suivi qu’ils m’ont apportés.
J’ai agréablement aimé travailler dans une équipe hétéroclite venant de l’Inde, du Pakistan, du Brésil, du Mexique, de la Grèce, de l’Italie et de la France. Nous avons pu partager nos cultures et nos expériences. Ce fut une équipe très sympathique avec la volonté de faire avancer le groupe et non des intérêts personnels. En ce sens, j’ai pu progresser rapidement dans un domaine jusqu’alors inconnu. Pour tout ce qu’ils m’ont apporté je les en remercie.
Je tiens à remercier plus particulièrement Dr Stéphanie Lefevre, Dr Qadeer Baig et Dr Amaury Negre de l’équipe e-Motion pour l’expérience et la connaissance qu’ils m’ont apportées.
Je voudrais exprimer mes remerciements à l’équipe SED d’Inria et surtout Soraya Arias, Nicolas Turro, et Jean-François Cuniberto pour l’aide qu’ils m’ont apportée sur la plate-forme Lexus.
Je tiens également à remercier Dorine Mazeyrat, Jean-Charles Durand et Sébastien Duffournet pour leur soutien et leurs précieux conseils lors de la rédaction ainsi que l’AIPST (l’Association des Ingé-nieurs du CNAM de Grenoble et de la Promotion Supérieure du Travail), parents et amis pour leurs relectures.
J’ai une pensée pour Mme Arbore, ancienne secrétaire de la filière informatique, et M. Giraudin, ancien responsable de la filière informatique, qui m’ont apporté leur aide tout au long de mon cursus au CNAM.
Merci aussi à Arnaud Pierrel et Sébastien Rattier, de l’entreprise Persistent Systems France, qui se sont montrés compréhensifs lors de ma formation au CNAM.
Ce mémoire est l’accomplissement de quatre années de dur labeur et je tiens à remercier mon épouse Sandra et mes enfants Enzo et Aurane pour leur compréhension et leur aide pendant cette période.
Sommaire
1 Présentation 1
1.1 Introduction . . . 1
1.2 Contexte . . . 1
1.2.1 Laboratoire de recherche Inria . . . 1
1.2.2 Équipe-projet e-Motion . . . 2
1.2.3 Collaboration avec Toyota Motor Europe . . . 4
1.2.4 Démonstrateur Inria . . . 4
1.3 Objectifs . . . 5
1.4 Plan du mémoire . . . 5
2 État de l’art 7 2.1 Véhicules intelligents . . . 7
2.1.1 Système avancé d’aide à la conduite (ADAS) . . . 8
2.1.2 Conduite autonome . . . 12 2.2 Capteurs . . . 14 2.2.1 Capteurs lasers . . . 14 2.2.2 Capteurs radars . . . 16 2.2.3 Capteurs optiques . . . 16 2.3 Intergiciels . . . 19 2.3.1 OROCOS . . . 19 2.3.2 ROS . . . 19 2.3.3 Player . . . 20 2.3.4 Orca . . . 20
2.3.5 Intergiciels soumis à licence payante . . . 20
2.3.6 Comparaison des différents intergiciels . . . 21
2.4 Démonstrateurs . . . 23
2.4.1 Présentation . . . 23
2.4.2 Démonstrateur du projet Intersafe-2 . . . 24
2.4.3 Démonstrateur de l’Université de Stanford . . . 25
2.4.4 Démonstrateur du projet SAFESPOT . . . 27
2.5 Conclusion . . . 28
3 Choix de conception 29 3.1 Problématiques . . . 29
3.3 Comparaison des intergiciels IPC et ROS . . . 33
3.3.1 Architecture des intergiciels . . . 33
3.3.2 Compatibilité système . . . 34
3.3.3 Langages pris en charge . . . 34
3.3.4 Communications . . . 35 3.3.5 Documentation . . . 35 3.3.6 Outils fournis . . . 35 3.3.7 Communauté . . . 35 3.3.8 Conclusion . . . 36 3.4 Architecture retenue . . . 37
3.5 Outils et méthodes de développement . . . 38
3.5.1 Spécificité de l’implantation logicielle destinée à la recherche . . . 38
3.5.2 Méthode de gestion de projets . . . 38
3.5.3 Environnement de développement intégré . . . 41
3.5.4 Bibliotèque OpenCV . . . 42
3.5.5 Programmation parallèle avec Cuda . . . 42
3.5.6 L’écosystème ROS : étapes de création d’un paquet . . . 43
3.5.7 L’écosystème ROS : outils . . . 45
3.5.8 Documentation du code source . . . 47
3.6 Conclusion . . . 48
4 Implantations logicielles 49 4.1 Problématiques . . . 50
4.2 Acquisition de données . . . 50
4.3 Mise en place de la plate-forme ROS . . . 51
4.3.1 Mise en place des repères capteurs . . . 52
4.3.2 Visualisation du modèle 3D du démonstrateur . . . 54
4.3.3 Champ de vue du démonstrateur . . . 55
4.3.4 Mise en place de l’architecture ROS . . . 55
4.4 Pilotes de capteurs . . . 56
4.4.1 Pilote des lidars . . . 56
4.4.2 Pilote de la caméra stéréo . . . 60
4.4.3 Pilote de la centrale inertielle . . . 64
4.4.4 Pilote du bus CAN du véhicule . . . 67
4.5 Calibration du volant . . . 69
4.6 Modules et applications . . . 71
4.6.1 Générateur de cartes de disparité et de grilles stéréo d’occupations . . . 71
4.6.2 Générateur de grilles d’occupation laser . . . 75
4.6.3 Générateur de grilles d’occupation à partir du BOF . . . 85
4.7 Intégration des modules . . . 93
4.7.1 Lancement des nœuds . . . 93
4.7.2 Enregistrement et rejeu des données capteurs . . . 94
4.7.3 Performances . . . 94
4.7.4 Greffon de grille colorisée pour l’outils rviz . . . 95
4.8 Démonstrateur Toyota . . . 98
4.8.1 Présentation du démonstrateur Toyota . . . 98
4.8.2 Livrables demandés . . . 99
4.8.3 Méthode de développement . . . 99
4.8.4 Mise en place de ROS . . . 99
4.8.5 Pilote des caméras . . . 100
4.8.6 Pilote des bus CAN du véhicule . . . 101
4.8.7 Pilote du Velodyne . . . 102
4.8.8 Pilote de la centrale inertielle . . . 103
4.8.9 Lancement des pilotes . . . 104
4.8.10 Performances . . . 105
4.9 Valorisation et diffusion de l’information . . . 105
5 Conclusion 107 5.1 Rappel des objectifs . . . 107
5.2 Synthèse des réalisations . . . 107
5.3 Perspectives . . . 108
5.4 Bilan personnel . . . 109
A Carte de disparité 111
Glossaire 113
Table des figures
1.1 Membres de l’équipe e-Motion . . . 2
1.2 Démonstrateur quadrirotor . . . 2
1.3 Démonstrateur fauteuil roulant . . . 3
1.4 Démonstrateur véhicule . . . 3
1.5 Plate-forme Lexus LS600h équipée de capteurs lidars, caméra stéréo et d’une centrale inertielle . . . 4
1.6 Présentation de la visualisation avec l’intergiciel Hugr . . . 5
2.1 Diagramme d’interactions . . . 9
2.2 Système de stationnement automatique . . . 9
2.3 Radar de régulation de distance . . . 10
2.4 Surveillance de l’angle mort . . . 10
2.5 Alerte de franchissement involontaire de ligne . . . 11
2.6 Freinage d’urgence autonome . . . 11
2.7 Véhicules autonomes . . . 13
2.8 Google car . . . 13
2.9 Laser 2D (Sick LMS200) . . . 14
2.10 Laser multicouche 2D (IBEO Lux) . . . 15
2.11 Laser 3D (Velodyne HDL-64E) . . . 15
2.12 Capteurs optiques stéréoscopiques . . . 17
2.13 Capteurs kinect . . . 18
2.14 Comparaison des intergiciels en terme de latence . . . 21
2.15 Architecture générale des démonstrateurs . . . 23
2.16 Interface de démonstration . . . 24
2.17 Démonstrateur du projet Intersafe-2 . . . 25
2.18 Capteurs du démonstrateur « Junior » . . . 26
2.19 Équipement intérieur de « Junior » . . . 26
2.20 Démonstrateur Renault . . . 27
3.1 Architecture initiale . . . 30
3.2 Architecture de l’application « Demo2sensors » . . . 31
3.3 Fonctionnement de l’intergiciel Hugr . . . 32
3.4 Architecture de l’intergiciel IPC . . . 33
3.8 Tableau Kanban à un instant du projet . . . 40
3.9 Diagramme de points consommés . . . 41
3.10 Comparaison des puissances GPU et CPU entre 2003 et 2010 . . . 42
3.11 Architecture GPU Nvidia . . . 43
3.12 Découpage d’une image . . . 43
3.13 Exemple de fichier décrivant une stack . . . 44
3.14 Exemple de fichier décrivant la compilation d’un paquet . . . 44
3.15 Exemple de fichier de lancement . . . 45
3.16 Outils rxbag pour enregistrer ou rejouer des fichiers . . . 46
3.17 Affichage de l’historique d’événements ROS . . . 46
3.18 Affichage des messages sous forme de graphiques . . . 46
3.19 Outil rviz pour l’affichage de données et la démonstration d’applications . . . 47
4.1 Route empruntée . . . 50
4.2 Caméra Prosilica . . . 51
4.3 Implantation d’un processus de perception . . . 52
4.4 Publication d’une transformation de repère . . . 53
4.5 Angles de rotation . . . 53
4.6 Position des repères capteurs dans l’espace . . . 53
4.7 Exemple de fichier URDF . . . 54
4.8 Position des différents repères des capteurs . . . 55
4.9 Champ de vue du démonstrateur . . . 55
4.10 Architecture des modules . . . 56
4.11 Capteur IBEO Lux . . . 57
4.12 Synthèse du protocole des lidars IBEO . . . 57
4.13 Position des lidars par rapport au véhicule . . . 58
4.14 Position relative des couches lasers . . . 58
4.15 Représentation d’une scène observée par des lidars . . . 59
4.16 Angles des points du lidar . . . 59
4.17 Capteur caméra stéréo TYZX . . . 60
4.18 Paramètres intrinsèques de la caméra . . . 61
4.19 Vue synthétique d’une caméra stéréo . . . 62
4.20 Position du repère caméra dans le véhicule . . . 63
4.21 Représentation d’une scène par une caméra stéréo . . . 64
4.22 Capteurs centrale inertielle (Xsens) . . . 65
4.23 Calcul de la position globale du repère véhicule . . . 66
4.24 Visualisation des données de la centrale inertielle avec GPS . . . 66
4.25 Génération du code source à partir de notre message spécifique . . . 68
4.26 Calcul du rayon de courbure . . . 69
4.28 Interface graphique de l’application Steering calibration . . . 70
4.29 Chaine de modules de suivi . . . 71
4.30 Chaîne de réalisation d’une grille d’occupation stéréo . . . 72
4.31 Carte de disparité calculée à partir des images de la caméra stéréo . . . 72
4.32 Image de détection de l’espace navigable et grille d’occupation en fonction de u . . . 73
4.33 Grille de probabilité d’occupation à partir des images stéréo . . . 73
4.34 Champ de vue et position de la grille . . . 75
4.35 Diagramme de classes initial . . . 76
4.36 Nouveau diagramme de classes . . . 77
4.37 Exemple de synchronisation de messages laser . . . 78
4.38 Interprétation du rayon laser dans la grille . . . 79
4.39 Projection d’une cellule sur le plan d’une couche laser . . . 79
4.40 Probabilité d’occupation des cellules le long d’un rayon laser mesurant un impact à une distance de 10 m . . . 80
4.41 Probabilité de collision avec le sol en fonction de la distance de l’impact et de la hauteur du rayon laser . . . 81
4.42 Algorithme du kernel GPU . . . 82
4.43 Fusion des couches des 2 lidars . . . 83
4.44 Comparaison des algorithmes (taille de cellule de 0.1 m de côté) . . . 84
4.45 Comparaison des algorithmes (taille de cellule de 0.2 m de côté) . . . 84
4.46 Comparaison des algorithmes selon le nombre de cellules à traiter . . . 85
4.47 Filtrage bayésien . . . 85
4.48 Paramètres enregistrés dans le serveur de paramètres . . . 87
4.49 Grille d’occupation provenant du BOF à partir de la grille lidars . . . 87
4.50 Calcul du nouveau rayon de courbure . . . 88
4.51 Calcul de la position des points de la trajectoire . . . 89
4.52 Génération de triangle à partir des points de la trajectoire . . . 91
4.53 Publication du message pour la trajectoire . . . 91
4.54 Trajectoire du véhicule prédite et risque associé . . . 91
4.55 Visualisation du temps avant collision et de la position de l’objet perçu . . . 92
4.56 Diagramme d’interaction des fichiers de lancement . . . 93
4.57 Prototype de l’écran du greffon . . . 95
4.58 Choix de l’échelle de couleur pour la grille . . . 95
4.59 Déclaration du nouveau greffon . . . 96
4.60 Visualisation du greffon dans rviz . . . 96
4.61 Comparaison des visualisations de la grille d’occupation stéréo . . . 97
4.62 Comparaison des visualisations de la grille d’occupation provenant des lidars . . . . 97
4.63 Plate-forme Toyota Prius équipée de capteurs caméra, laser 3D et d’une centrale iner-tielle . . . 98
4.64 Visualisation en 3D du véhicule et de ces repères . . . 100
4.65 Fichier de lancement de toutes les caméras . . . 101
A.1 Vue synthétique d’une caméra stéréo . . . 111
Liste des tableaux
2.1 Comparaison entre différents lasers . . . 162.2 Comparaison entre différents capteurs optiques . . . 18
2.3 Comparaison entre différents intergiciels . . . 22
2.4 Comparaison entre différents démonstrateurs . . . 28
Acronymes
ABS : « Anti-lock Braking System » littéralement « système antiblocage » ; est un équipement d’anti-blocage de sécurité qui a été conçu afin d’éviter le d’anti-blocage des roues d’un véhicule à l’occasion d’un freinage intense et ainsi diminuer la distance de freinage.
ADAS : « Advanced Driver Assistance Systems » littéralement « systèmes avancés d’aide à la cond-uite » ; ce sont les équipements avancés d’aide à la condcond-uite tels que la détection de piétons et la reconnaissance de panneaux.
API : « Application Programming Interface » littéralement « interface de programmation » ; est une interface de communication entre plusieurs programmes. Il permet donc de faciliter l’interac-tion entre ceux-ci par le biais de langage de programmal’interac-tion.
BOF : « Bayesian Occupation Filter » littéralement « filtre d’occupation bayésien » ; calcule une estimation de la position et de la vitesse, à partir de mesures, organisées sous forme de grille, et de prédiction faite à l’instant d’avant. Ce filtre se sert du théorème de Bayes.
CAN : « Controller Area Network » littéralement « Protocole Réseau » ; est un équipement de com-munication entre les différents modules du véhicule (volant, roues, moteur, etc.). Il permet, à travers un bus de communication, de transférer des données au calculateur afin de réagir par rapport aux données des capteurs.
CPU : « Central Processing Unit » littéralement « Unité centrale de traitement » ; est la partie de l’ordinateur qui effectue les traitements des programmes informatiques.
DATMO : « Detection And Tracking of Moving Objects » littéralement « détection et suivi des objets mobiles » ; regroupe les modèles et approches qui effectuent de la détection d’obstacles et du suivi d’objets mobiles.
ESP : « Electronic Stability Program » littéralement « Électro-Stabilisateur Programmé » ; est un équipement d’antidérapage. Il permet d’améliorer le contrôle de trajectoire d’un véhicule. GPU : « Graphics Processing Unit » littéralement « processeur graphique » ; est un circuit intégré
qui est situé dans les cartes graphiques de l’ordinateur. Il assure les calculs d’affichage mais par sa structure hautement parallèle, il peut également traiter beaucoup d’autres types de calculs. IHM : « Interface Homme Machine » définit l’interface entre l’humain et la machine dans le but de
communiquer. Ce peut être de façon visuelle, sonore ou par le biais de vibration.
IP : « Internet Protocol » littéralement « Protocole Internet » ; est une famille de protocole de com-munication réseaux utilisé par internet. Il permet, entre autres, l’adressage unique de l’ensemble des systèmes connectés.
LASER : « Light Amplification by Stimulated Emission of Radiation » littéralement « amplification de la lumière par émission stimulée de rayonnement » ; est un amplificateur de lumière. Il permet de générer un faisceau lumineux spatialement et temporellement cohérent.
ROS : « Robot Operating System » littéralement « système d’exploitation pour robot » ; est un sys-tème d’exploitation qui permet de contrôler un robot. Il peut être aussi vu comme un intergiciel qui se place entre les capteurs et les modules de traitements.
SDK : « Software Development Kit » littéralement « kit de développement logiciel » ; est un ensemble d’outils permettant aux développeurs de créer des applications pour un type défini. Grâce au kit de développement logiciel, il est souvent plus facile et plus rapide d’implanter une application. UML : « Unified Modeling Language » littéralement « langage de modélisation unifié » ; est un langage de modélisation graphique qui est utilisé dans le logiciel. Il est constitué de plusieurs diagrammes qui facilitent la compréhension d’un système.
RADAR : « RAdio Detection And Ranging » littéralement « détection et estimation de la distance par ondes radio » ; est un système qui utilise les ondes radio afin de détecter et déterminer la distance et/ou la vitesse d’objets.
RPC : « Remote Procedure Call » littéralement « appels de procédures distantes » ; est un protocole réseau permettant de faire des appels de procédures sur un ordinateur distant.
TAF : « Travail à Faire » ; est utilisé dans la méthode Kanban pour limiter le travail à effectuer dans chaque état.
WIP : « Work In Progress » littéralement « Travail à Faire » ; est utilisé dans la méthode Kanban pour limiter le travail à effectuer dans chaque état.
Chapitre 1
Présentation
1.1
Introduction
Les systèmes avancés d’aide à la conduite (Advanced Driver Assistance System, ADAS) sont de plus en plus présents dans les véhicules routiers. Leur objectif est d’assister le conducteur dans la tâche de conduite, par exemple en l’aidant à trouver le meilleur chemin pour atteindre sa destination, en lui indiquant des dangers potentiels, voire en agissant sur le contrôle du véhicule pour éviter un accident. La réalisation de nouveaux ADAS est un long processus qui nécessite des collaborations entre les constructeurs, les équipementiers, les laboratoires de recherche et les pouvoirs publics.
Au cours des différentes phases de développement d’un nouvel ADAS, il est nécessaire de tester le système et de démontrer ses fonctionnalités. C’est le rôle des véhicules dit « démonstrateurs ». Ce stage, réalisé au sein de l’équipe e-Motion d’Inria Grenoble, avait pour objet principal la conception et la réalisation d’une nouvelle architecture système pour le véhicule démonstrateur de l’équipe.
1.2
Contexte
1.2.1
Laboratoire de recherche Inria
Le stage s’est déroulé dans le laboratoire de recherche Inria (Institut National de Recherche en In-formatique et en Automatique) au centre de recherche de Grenoble, à Montbonnot-Saint-Martin dans l’Isère. Inria a été créé en 1967 suite au « Plan Calcul » pour assurer l’indépendance de la France en matière de gros ordinateurs. Inria est sous la tutelle de deux ministères, celui de l’enseignement supérieur et de la recherche et celui du redressement productif. Inria a donc une mission de recherche et une mission de transfert de connaissance. Ses missions de recherche se concentrent sur plusieurs thèmes comme l’éducation, la médecine, le transport, l’information, les logiciels, l’assistance et l’en-vironnement. Plus de 4350 personnes travaillent à Inria dont 1300 doctorants.
Inria est aujourd’hui constitué de huit centres de recherche autonomes (Bordeaux, Grenoble, Lille, Nancy, Rocquencourt, Rennes, Saclay, Sophia Antipolis). Celui de Grenoble a été fondé en 1992 puis s’est implanté en 1996 à Montbonnot-Saint-Martin. Il compte 610 personnes et est composé de 34 équipes de recherche dont 11 situées à Lyon.
1.2.2
Équipe-projet e-Motion
L’équipe-projet e-Motion d’Inria travaille sur la robotique centrée sur l’humain. Cette équipe a pour ambition de développer des modèles et des algorithmes permettant à terme de construire des systèmes artificiels dotés de capacités de perception, de dé-cision, et d’action suffisamment évolués et robustes pour les autoriser à fonctionner dans des environnements ouverts (partiellement connus), fortement dynamiques, et conduisant à des interactions variées avec l’homme[Mot13].
Les principaux domaines d’application visés par cette problématique de recherche sont ceux qui cherchent à introduire des systèmes robotisés dans notre espace de vie, afin d’accroître la sécurité des personnes et le confort d’utilisation des nouvelles technologies. Cette caractéristique se retrouve en particulier dans des applications comme les systèmes de transport intelligents, la robotique de ser-vice (par exemple pour réaliser des tâches ménagères ou pour améliorer le cadre de vie de personnes handicapées ou dépendantes), ou encore la robotique d’intervention (e.g. sécurité civile ou militaire) [Mot13]. L’équipe est constituée d’une vingtaine de personnes dont cinq chercheurs permanents.
FIGURE1.1 – Membres de l’équipe e-Motion Source : [Mot13]
Actuellement, l’équipe travaille principalement sur les thématiques suivantes :
– La localisation et la cartographie basées sur la vision par Micro-Véhicules Aériens (MAV) : le but de ce thème de recherche est de cartographier une zone inaccessible (tremblement de terre, fuite radioactive, etc.) et de se localiser à l’intérieur. Ces recherches se placent dans la thématique de la robotique autonome et visent à proposer des méthodes de navigation autonome, de cartogra-phie et de déploiement d’une équipe de Micro-Véhicules Aériens pour effectuer des missions de surveillance sur un terrain inconnu de morphologie arbitraire. Ces travaux utilisent un quadrirotor1 (cf. figure 1.2) et sont basés sur la vision assistée par une centrale inertielle dans un environnement où les coordonnées GPS sont indisponibles ;
FIGURE1.2 – Démonstrateur quadrirotor Source : [TM12]
1.2. Contexte
– La navigation autonome en environnement humain : l’objectif est de proposer des robots ca-pables de transporter de manière autonome ou semi-autonome des personnes là où elles le veulent, comme elles le feraient si elles se déplaçaient par leurs propres moyens (à pied ou en conduisant leur véhicule par exemple). Le but est d’amener un service de confort. Ce type de robots peuvent être des véhicules automobiles ou des fauteuils roulants. Ces recherches se placent dans la théma-tique de la robothéma-tique autonome et visent à proposer des méthodes de navigation sûre orientée vers un but dans des environnements hautement dynamiques peuplés d’humains. Elles sont orientées autour de la compréhension de l’environnement et sa prise en compte dans la décision de navi-gation de véhicules autonomes (véhicules automobiles et plus récemment fauteuils roulants). La figure 1.3 illustre la plate-forme utilisée pour les tests et démonstrations ;
FIGURE 1.3 – Démonstrateur fauteuil roulant Source : [Esc+12]
– La perception et l’interprétation pour les véhicules intelligents : comme tout robot mobile, un véhicule intelligent perçoit son environnement proche à l’aide de capteurs embarqués. Dans ce cas, la perception consiste à interpréter la scène observée et peut être considérée à différents niveaux. Le niveau le plus bas exploite les données capteurs pour obtenir une représentation très simplifiée de l’environnement, par exemple à l’aide d’une grille ou d’un nuage de points. A un niveau supérieur, il est possible de calculer une décomposition de la scène en un ensemble d’objets, associés à des informations de positions et de vitesses, voire de trajectoires ou encore de classes d’objets (voi-ture, piéton, avion, etc.). La difficulté majeure réside dans le fait que l’environnement est observé à travers des observations partielles, entachées d’erreurs et que l’aspect « dynamique » apporte une contrainte forte en termes de temps de calcul. L’équipe e-Motion travaille sur la perception en envi-ronnement routier et développe des algorithmes intervenant aux différents niveaux de la chaîne de perception (calcul de grille, détection et suivi, reconnaissance d’objets, estimation de manœuvres, etc.). Un véhicule instrumenté est utilisé pour valider et démontrer ces algorithmes (cf. figure 1.4).
1.2.3
Collaboration avec Toyota Motor Europe
L’équipe e-Motion travaille en partenariat avec l’entreprise Toyota Motor Europe dans le cadre de ses travaux sur les ADAS. Toyota fournit la plate-forme équipée de capteurs (cf. figure 1.4) et l’équipe présente ses résultats de recherche tous les trois mois. Ce partenariat a impliqué des présentations de notre travail à Toyota assez régulièrement durant le stage. Suite à ces présentations, Toyota a proposé que j’intègre mes travaux sur leur propre véhicule démonstrateur.
J’ai donc eu l’occasion de travailler pour Toyota Motor Europe à Bruxelles pendant 1 mois. Cet échange a permis de renforcer le partenariat entre Inria et Toyota, et a permis un transfert de connais-sances. Le démonstrateur Toyota sera décrit dans la partie 4.8.
1.2.4
Démonstrateur Inria
L’équipe e-Motion utilise un véhicule démonstrateur pour tester les algorithmes développés pour les ADAS dans un environnement réel.
Le démonstrateur de l’équipe est une voiture Lexus LS600h (cf. figure 1.5). Ce véhicule est équipé de plusieurs types de capteurs : deux capteurs lidars IBEO Lux fixés dans le pare-choc avant, une caméra stéréo TYZX située derrière le pare-brise et une centrale inertielle équipée d’un GPS. Ces capteurs ont pour but de percevoir la scène dans laquelle se trouve le véhicule. Par exemple, la caméra perçoit l’environnement avec un champ de vue de 62° et chaque lidar a un champ de vue de 110°. En plus de ces capteurs, le véhicule est équipé d’un ordinateur avec 8 Go de mémoire vive, un processeur Intel Xeon 3.4 GHz et une carte graphique NVIDIA GeForce 480.
FIGURE 1.5 – Plate-forme Lexus LS600h équipée de capteurs lidars, caméra stéréo et d’une centrale
1.3. Objectifs
Outre, le matériel installé dans le démonstrateur, associé à celui-ci, des pilotes des capteurs, des modules de traitement et un intergiciel sont installés sur cet ordinateur. Cet intergiciel, nommé Hugr, est un composant essentiel du démonstrateur, car il fait le lien entre les capteurs, les modules de traitement et la visualisation des résultats sur l’écran installé à l’arrière du véhicule (cf. figure 1.5). Par exemple, la figure 1.6 illustre un écran « type », d’affichage de résultats avec l’intergiciel Hugr.
FIGURE1.6 – Présentation de la visualisation avec l’intergiciel Hugr
Cet intergiciel n’étant plus maintenu et ne satisfaisant plus aux attentes de l’équipe, il a été décidé de le remplacer.
1.3
Objectifs
L’objectif du stage était de concevoir et d’implanter une nouvelle architecture système pour le dé-monstrateur. Pour atteindre cet objectif, notre travail s’est déroulé en deux étapes :
– Nous avons réalisé la conception de la nouvelle architecture. Tout d’abord, afin de choisir un rem-plaçant pour Hugr, nous avons effectué un état de l’art des intergiciels existant dans le domaine de la robotique. Ensuite, nous avons réalisé une comparaison détaillée des deux intergiciels les plus prometteurs afin de choisir celui qui serait utilisé dans la nouvelle architecture du démonstra-teur. Enfin, en plus de l’intergiciel, nous avons étudié les modules existants pour comprendre les interactions avec Hugr et les migrer vers le nouvel intergiciel ;
– Nous avons implanté la nouvelle architecture du démonstrateur. Cette tâche a impliqué entre autres l’utilisation d’un intergiciel inconnu pour nous jusqu’alors, l’implantation des pilotes de capteurs jamais utilisés, la compréhension des différentes utilisations du démonstrateur et la présentation des données de façon simple et compréhensible.
1.4
Plan du mémoire
Le chapitre 2 présente un état de l’art des véhicules intelligents. Ce chapitre introduit la notion d’as-sistance à la conduite et de véhicule autonome. Il traite de l’importance des capteurs pour les ADAS et présente également les intergiciels utilisés dans le domaine de la robotique. Enfin, il présente quelques démonstrateurs.
Ensuite un troisième chapitre présente les choix de conception pour la nouvelle architecture sys-tème. Ce chapitre est constitué de l’étude de l’existant, de notre comparaison des intergiciels et de
la description de l’architecture retenue. Ce chapitre présente également les outils et les méthodes de développement qui ont été utilisés au cours du stage.
Pour continuer, un quatrième chapitre présente les implantations logicielles. Ce chapitre décrit la mise en place du nouvel intergiciel puis des implantations effectuées au niveau des pilotes, modules de traitement et applications. Il expose également les réalisations accomplies pour le démonstrateur de Toyota.
Enfin un dernier chapitre conclut ce mémoire. Il présente une synthèse technique des réalisations puis décrit les perspectives du démonstrateur d’Inria. Il conclut par un bilan personnel de cette expérience de stage.
Chapitre 2
État de l’art
Ce chapitre présente le contexte scientifique dans lequel s’est déroulé le stage. Il est divisé en quatre parties. La première partie présente les systèmes avancés d’aide à la conduite et la conduite autonome. Quelles sont les différentes assistances existantes et futures ainsi que leurs problématiques ?
La deuxième partie montre les différents capteurs utilisés pour fournir une information claire et perti-nente aux véhicules intelligents. Leurs avantages et inconvénients respectifs sont également présentés. La troisième section s’intéresse à une partie importante de la mise en place de fonctionnalités avancées d’aide à la conduite : l’intergiciel. A quoi sert-il ? Quelles sont les différences entre les intergiciels existants ?
Enfin, la quatrième partie présente l’outil principal, le démonstrateur, permettant de tester des concepts et de mettre au point de nouvelles assistances à la conduite. Elle montre aussi des exemples de véhi-cules utilisés et les objectifs de chacun.
2.1
Véhicules intelligents
Depuis la création de la première voiture, le concept de celle-ci n’a pas beaucoup changé. Elle est tou-jours construite avec quatre roues, un moteur et un intérieur. La technologie s’est nettement améliorée mais les bases sont les mêmes. Les constructeurs ont perfectionné leurs véhicules en ajoutant des sys-tèmes dits de « sécurité passive » comme les ceintures de sécurité ou les coussins gonflables (airbag). Ces systèmes de sécurité passive ont pour objectif d’atténuer les conséquences d’un accident. Plus récemment, des systèmes dits de « sécurité active » ont aussi été ajoutés, tel que l’avertissement de changement de voie ou le freinage avant collision. Ces systèmes de sécurité active anticipent les situations à risque et ont pour but d’éviter l’accident ou d’en diminuer la gravité [LRA07][IG+10]. De récents développements ont montré des changements significatifs de l’électronique dans les véhi-cules (radio, ABS, ESP, GPS). L’électronique embarquée peut être découpée en trois catégories : les systèmes d’information, les systèmes de divertissement et les systèmes de sécurité. Certaines de ces catégories peuvent être en interaction comme la radio, qui peut amener un divertissement, mais aussi fournir des informations sur le trafic. Ces interactions doivent être prises en compte durant la concep-tion et la recherche sur les systèmes avancés d’aide à la conduite (Advanced Driver Assistance System, ADAS) [Tha06].
Avec tous ces systèmes embarqués, les véhicules d’aujourd’hui sont considérés comme « intelli-gents ». Effectivement, ils perçoivent leur environnement, ils prennent des décisions et accomplissent des actions tout comme un robot. Le domaine de la robotique a beaucoup en commun avec le domaine des véhicules intelligents notamment le concept de boucle robotique (perception-décision-action). Les
techniques développées dans un domaine sont souvent appliquées à l’autre.
Ainsi, pour bien comprendre comment fonctionnent les assistances à la conduite des véhicules intel-ligents, il est nécessaire d’expliquer ce qu’est la boucle robotique [FIL11].
La « perception » repose sur les capteurs dont le robot (ou véhicule intelligent) est équipé. Les données capteurs doivent être interprétées, en prenant en compte les incertitudes. Ainsi, la perception consiste à interpréter les données capteurs afin d’obtenir une description de la scène. Cette interprétation est complexe et déterminante pour les couches logicielles de plus haut niveau. Elle permet, par exemple, d’identifier le type d’objet ou de déterminer si l’objet est statique ou dynamique.
La partie « décision » prend en compte la perception mais aussi le but que le robot doit atteindre. Elle sert à choisir la stratégie que le robot va adopter pour atteindre son but. Sans une bonne étape de perception, il est difficile de prendre de bonnes décisions. La principale difficulté rencontrée dans cette partie est le nombre de décisions possibles pour atteindre le but.
La partie « action » consiste à récupérer la décision prise face à un environnement donné et appliquer cette décision à l’aide des actionneurs situés sur le robot. Dans le cas de véhicules, ce peut être le frein, le volant ou l’accélérateur.
Les véhicules intelligents se basent sur cette boucle robotique pour assister ou remplacer le conduc-teur.
2.1.1
Système avancé d’aide à la conduite (ADAS)
Les systèmes avancés d’aide à la conduite répondent à plusieurs enjeux : sociétal, industriel et scienti-fique. En conséquence, plusieurs pays, dont les pays européens, laboratoires de recherche et fabricants de véhicules ont participé et financé des projets pour diminuer les accidents, les effets de ceux-ci sur leurs passagers mais aussi pour diminuer la pollution [Eur13b]. Chaque partie prenante a son propre but, comme résoudre les problèmes liés au trafic et à la sécurité, pour les pays, travailler sur des technologies expérimentales et innovantes, pour les laboratoires de recherche, et enfin améliorer leurs gammes de véhicules, pour les constructeurs. Toutes ces parties prenantes travaillent ensemble lors de projets pour développer de nouveaux systèmes.
Depuis des années, le nombre de véhicules ne cesse d’augmenter et engendre plusieurs types de pro-blèmes. Par exemple, il a été constaté qu’en Belgique, dans l’année 2008, plus de 700 km de bouchons se produisaient par jour. Ce chiffre est 10 fois supérieur à celui de l’année 1998 [ID02]. Ajouté à ces problèmes de congestion, chaque année des millions d’accidents de la route surviennent et coûtent des millions de vies humaines et une perte économique très lourde. En 2010, sur les routes européennes, plus de 31000 personnes sont mortes et plus de 1.5 millions de personnes ont été blessées dans des accidents de la route [Eur13b].
Partant de ce constat, des études ont été menées afin de comprendre la cause de ces accidents. Elles ont montré qu’il y a 3 facteurs majeurs :
– le conducteur ; – le véhicule ; – l’infrastructure.
Parmi ces trois facteurs, 90 % des accidents sont provoqués par le conducteur [TRA08].
Les ADAS ont pour but d’aider le conducteur dans sa tâche de conduite. Ils peuvent amener plus de confort et plus de sécurité. Dans le cas particulier de la sécurité, ils peuvent signaler un danger au conducteur ou éventuellement prendre le contrôle. Ainsi, les ADAS peuvent aider le conducteur à prendre les bonnes décisions, mieux comprendre certaines situations ou accomplir des actions pour
2.1. Véhicules intelligents
rendre la conduite plus sûre et plus confortable [KUM12].
Dans le but d’illustrer comment s’insèrent les ADAS dans le véhicule et comment ils interagissent avec le conducteur, la figure 2.1 montre un diagramme d’interactions entre le conducteur, la situation potentiellement dangereuse, le système qui a le contrôle du véhicule et les ADAS [Tha06].
FIGURE2.1 – Diagramme d’interactions Traduit par le rédacteur, d’après : [Tha06], p. 89
Les ADAS perçoivent l’environnement à travers des capteurs. Ensuite, les ADAS agissent ou in-forment le conducteur de la situation avec différents modes d’assistances à la conduite : l’avertisse-ment, la suggestion ou le contrôle. L’avertissement passe par des signaux lumineux, sonores ou bien haptiques pour lesquels le conducteur peut réagir en contrôlant le véhicule. Ensuite, la suggestion peut, par exemple, prendre le contrôle du volant pendant quelques secondes pour inciter le conduc-teur à tourner. Enfin, le contrôle permet d’assister le conducconduc-teur dans la manœuvre. Par exemple, il peut adapter la vitesse ou la direction du véhicule face à une situation dangereuse [Tha06].
Les données capteurs doivent être traitées pour filtrer le bruit, les erreurs des capteurs et extraire l’in-formation pertinente pour la couche applicative. Ce traitement rend nécessaire une capacité de calcul et de mémoire assez importante pour un traitement temps réel (environ 25 Hz). Le traitement doit être le plus rapide possible afin d’anticiper et prendre une décision avant que l’environnement n’ait beaucoup changé [CSÁ11]. Afin d’illustrer les ADAS actuellement utilisés, ce mémoire va présenter certains des plus importants.
Système de stationnement automatique (Automatic Parking System, APS)
FIGURE2.2 – Système de stationnement automatique
Source : [CSÁ11]
Le système APS a été pour la première fois démontré dans le milieu des années 90 par Inria en utilisant le concept de boucle de Localisation-Planification-Exécution pour atteindre une position spécifiée de
la voiture par rapport à son environnement [PL97]. Le système mesure la place de stationnement par le biais de capteurs ultrason quand le véhicule passe devant la place. Dans le cas où la place de stationnement est assez grande, le conducteur arrête le véhicule et active la fonction de stationnement automatique. Ensuite le véhicule manœuvre automatiquement, le conducteur n’a plus qu’à accélérer ou freiner à sa convenance [CSÁ11].
Régulation de distance (Adaptive cruise control, ACC)
FIGURE2.3 – Radar de régulation de distance
Source : [aut13]
Le système de régulation de distance est une extension du conventionnel régulateur de vitesse. Il utilise un radar ou des lasers pour estimer la distance avec le véhicule précédent sur une même voie d’autoroute. Il se sert de cette information pour accélérer et décélérer afin de maintenir une allure constante à une distance sûre du véhicule [ICI10].
Surveillance de l’angle mort (Blind Spot Detection, BLIS)
FIGURE2.4 – Surveillance de l’angle mort Source : [zig13]
L’angle mort est une zone autour des véhicules qui ne peut être directement observée par le conduc-teur. Pour que le conducteur puisse voir cette zone, il doit effectuer un effort supplémentaire pour se retourner ou ajuster ses rétroviseurs. Et parfois cette zone n’est pas visible. Le BLIS est un système basé sur des capteurs radars ou des caméras qui fournissent des informations visuelles au conducteur concernant la présence d’objets (piétons, vélos, véhicules) dans l’angle mort du véhicule. Dans le cas où l’angle mort est occupé, un signal sonore ou visuel est envoyé au conducteur [CSÁ11].
2.1. Véhicules intelligents
Alerte de franchissement involontaire de ligne (Lane Departure Warning, LDW)
FIGURE 2.5 – Alerte de franchissement involontaire de ligne
Source : [ope13a]
L’alerte de franchissement involontaire de ligne est basée sur l’utilisation de caméras, de lasers ou de capteurs infrarouge afin de reconnaître le marquage des lignes au sol. Il peut donc signaler au conducteur, en utilisant des signaux sonores, lumineux ou vibrants que le véhicule est en train de sortir de sa voie. Les systèmes de maintien sur la voie (Lane Keeping Warning, LKW) ont un niveau plus haut d’automatisation et peuvent automatiquement prendre des actions pour s’assurer que le véhicule reste sur la voie [CSÁ11].
Freinage d’urgence autonome (Automatic Emergency Braking, AEB)
FIGURE2.6 – Freinage d’urgence autonome Source : [Eur13a]
Le freinage d’urgence autonome, par exemple le système city safety conçu par Volvo, permet d’éviter les accidents à faible allure ou de réduire leur degré de gravité. Le système de Volvo est basé sur un capteur lidar placé en haut du pare-brise pour obtenir une perception de l’environnement de l’avant du véhicule. Grâce à lui, le véhicule peut détecter des obstacles à une distance de 10 m et donc de calculer un risque de collision. Dans le cas d’un risque, le système de freinage d’urgence précharge les freins et renforce la sensibilité du système d’assistance de freinage d’urgence afin que le conducteur puisse freiner plus rapidement. Si le conducteur ne s’aperçoit pas de l’obstacle et que la collision devient imminente, le système de freinage d’urgence freine de manière autonome. Au-delà de 15 km/h le système ne peut éviter la collision mais réduit la vitesse d’impact [Eur13a].
ADAS du futur
Nous pouvons remarquer que la plupart des ADAS sont dédiés à la sécurité sur autoroute. Effective-ment, il est plus facile de créer des ADAS sur autoroute car l’environnement est fortement contraint. Les véhicules roulent dans le même sens et aucun objet ne peut venir sur les côtés du véhicule. Même
si les véhicules roulent à vive allure, cet environnement peut être interprété comme lent car la vitesse relative des véhicules est faible. Tandis que sur route nationale et/ou en ville, des piétons peuvent traverser la route à tout moment ou changer de direction instantanément. Ce cadre moins contraint amène des difficultés pour la perception, la prise de décision et l’action.
Seuls quelques ADAS sont aujourd’hui disponibles dans la plupart des types de véhicules (voitures, camions, tracteurs) mais le développement a pu être accéléré grâce à trois effets [KB04] :
– l’augmentation de la capacité de calcul ;
– la diminution du prix de stockage de la mémoire informatique ; – l’amélioration de la qualité des capteurs.
Il est difficile de dire à quoi vont ressembler les ADAS du futur mais nous pouvons parler des tech-nologies qu’ils vont intégrer. Ils auront des capacités de planification 3D, d’évaluation de risque pour les freinages d’urgence, des systèmes de surveillance du conducteur, des systèmes de géné-ration de trajectoires pour les véhicules environnants et une capacité d’outrepasser le contrôle du conducteur. Il est envisagé que les véhicules communiquent entre eux (Vehicle to Vehicle, V2V) et avec l’infrastructure (Vehicle to Infrastructure, V2I). Ces nouvelles technologies de communication permettraient aux véhicules de percevoir l’environnement au-delà des limites de leurs capteurs em-barqués [GGM06][Bal06][Lef12].
2.1.2
Conduite autonome
La conduite autonome est le pendant des ADAS. Souvent, les approches développées pour les ADAS sont utilisées pour la conduite autonome.
Depuis les années 80, plusieurs pays ont montré un fort intérêt pour les véhicules intelligents. Un grand projet exploratoire nommé PROMETHEUS a été lancé en Europe et suivi par d’autres au Japon et aux États-Unis. Afin d’encourager ces recherches aux États-Unis, le Defense Advanced Research Projects Agency (DARPA1) a lancé plusieurs compétitions. Déjà en 2005, les véhicules autonomes parcouraient environ 210 kilomètres dans le désert. Puis en 2007, ces véhicules tenaient compte des autres véhicules, des humains et du code de la route en évoluant dans un environnement urbain. La figure 2.7 montre Junior un véhicule autonome au DARPA urban challenge 2007 qui a reçu le 2eprix
[Pet11][Vig12].
Un autre exemple de véhicule autonome est le Cycab. Il a été présenté par Inria, dans le cadre du projet CityMobil qui a pour but de trouver de nouveaux moyens de transport pour les villes, afin de réduire le nombre de véhicules, la pollution et d’obtenir une conduite plus sûre [Cit13]. Ce Cycab est complètement autonome grâce à une caméra stéréo, des lasers et une connexion internet avec laquelle il peut communiquer avec d’autres Cycab (cf. figure 2.7) [Jia10][Vig12]. Dans le cadre du projet Cybercars, l’équipe IMARA, d’Inria, a pu faire essayer et tester le cycab pendant quatre mois à La Rochelle. Ce test grandeur nature a montré que le cycab est un moyen de transport adapté pour les villes du futur. Il est particulièrement intéressant pour le transport public à la demande car il fournit un transport plus sûr et plus fréquent que les transports publics conventionnels [Bou+11].
1. Le DARPA est une agence du département de la défense américaine qui a organisé des compétitions de véhicules autonomes.
2.1. Véhicules intelligents
(a) Véhicule autonome junior de l’Université de Stanford (b) Véhicule autonome Cycab de l’Inria
FIGURE2.7 – Véhicules autonomes
Source : [Jia10], p. 6
La voiture autonome la plus avancée actuellement est probablement la Google car (cf. figure 2.8) qui est capable de naviguer de manière autonome sur route ouverte et est désormais autorisée à conduire dans le Nevada et en Californie. Cela illustre bien l’avancée des techniques en matière d’analyse et de compréhension d’un environnement dynamique et de temps de calcul [Tim13][tec13].
FIGURE2.8 – Google car Source : [han13]
Enfin, que ce soient pour les applications ADAS ou conduite autonome, un véhicule intelligent doit être équipé de capteurs pour percevoir l’environnement. Souvent, une combinaison de capteurs est utilisée : lasers, caméras, centrales inertielles, etc. Ils fournissent des données qui permettent d’ob-tenir une représentation partielle de l’environnement du véhicule. Ces capteurs doivent être capables de détecter de petits objets mobiles, tel que les animaux, mais aussi la signalisation routière pour respecter le code de la route. La partie suivante présente les différents types de capteurs utilisés.
2.2
Capteurs
Un capteur est un dispositif permettant de convertir un signal physique en valeur électrique qui sera utilisé par les modules de traitements. Les capteurs peuvent être de type extéroceptif ou proprioceptif, actifs ou passifs. Les capteurs extéroceptifs sont des capteurs qui observent l’environnement autour du véhicule. A l’inverse, les capteurs proprioceptifs observent le véhicule. Cette partie se limite aux capteurs extéroceptifs.
Les capteurs sont la base de la perception, car il est nécessaire de capter des informations extérieures au véhicule. Plusieurs types de capteurs existent, les types laser, radar, optique et ultrason. Il existe deux catégories, les capteurs dits « actifs » et ceux dits « passifs ». La première catégorie rassemble ceux qui irradient la scène par leur énergie, par exemple le laser qui produit un faisceau lumineux. La deuxième catégorie regroupe ceux qui observent l’environnement en captant les sources d’énergie extérieures, par exemple une caméra optique qui reçoit la luminosité devant elle. [Lem05].
Enfin, selon le type de capteurs choisis, la détection se fera plus ou moins facilement. Les ADAS utilisent des capteurs qui s’insèrent facilement dans le véhicule et à prix abordable. En revanche, la conduite autonome se focalise sur des capteurs modélisant complètement l’environnement, la contrainte de coût étant moindre. Cette partie montre les différents capteurs utilisés dans le domaine des véhicules intelligents avec, pour chacun, leurs avantages et leurs inconvénients.
2.2.1
Capteurs lasers
Les capteurs laser (Light Amplification by Stimulated Emission of Radiation) appartiennent à la ca-tégorie des capteurs actifs, ils contiennent leur propre émetteur qui produit sa propre énergie pour illuminer la scène. Les capteurs lasers listés ci-après sont les plus courants pour les véhicules intelli-gents [Lem05]. Les lasers sont utilisés pour la détection d’accident, le freinage automatique d’urgence et l’assistance à l’encombrement de la circulation.
Télémètres lasers ou lidars 2D
Les lidars (Light Detection And Ranging) fonctionnent sur le principe Time Of Flight (TOF) qui me-sure le temps de vol du rayon laser lors de la réflexion sur une surface observée. Grâce à cette meme-sure, ils peuvent calculer des distances avec précision. Ce capteur émet un rayon laser au-dessus de la ro-tation d’un miroir qui détourne celui-ci sur un plan. Puis les rayons réfléchis par les obstacles sont renvoyés à un détecteur (télescope) qui calcule la distance en utilisant le temps écoulé depuis l’émis-sion de celui-ci. L’énergie qui revient dans le capteur dépend de l’albédo c’est-à-dire du coefficient d’absorption de la surface détectée et de l’angle d’incidence. Par exemple, un obstacle noir sera moins bien détecté qu’un obstacle d’une autre couleur, à cause de son coefficient d’absorption [Lem05].
FIGURE 2.9 – Laser 2D (Sick LMS200)
Source : [SIC13]
Le lidar capture des tranches d’informations 2D très précises avec un large champ de vision. Un exemple de lidar très utilisé, le Sick LMS200, a un champ de vue de 120°, une détection jusqu’à 200
2.2. Capteurs
m et une résolution angulaire de 0.25° à 1° (cf. figure 2.9). Cette résolution est encore trop limitée pour des obstacles lointains. Une autre difficulté est de différencier les rayons percutant le sol des rayons percutant des obstacles. En revanche, il fonctionne relativement bien dans toutes les conditions météo-rologiques bien que le soleil de face ou une forte pluie puissent amener des erreurs [Pet+12][Vig12].
Télémètres lasers multicouches 2D
Ce type de capteur utilise le même principe que celui vu précédemment, le balayage se fait horizonta-lement mais il contient, en plus, plusieurs couches situées à des hauteurs différentes (quatre couches pour le modèle IBEO Lux, cf. figure 2.10). Grâce à ce système de couches, il peut plus facilement détecter les faisceaux percutant le sol [PPL11][Vig12].
FIGURE2.10 – Laser multicouche 2D (IBEO Lux)
Source : [IBE13]
Télémètres lasers 3D
Le télémètre laser 3D, tel le Velodyne HDL-64E (cf. figure 2.11), utilise plusieurs lasers (64 pour le Velodyne HDL-64E) qui sont disposés à différents angles verticalement et fixés à un cylindre vertical. Un balayage laser est effectué à chaque rotation du cylindre, il a une plage de fréquence de 5 à 15 Hz et un nuage de points 3D est ainsi généré. Ce qui représente jusqu’à 2 millions de points par seconde. Cette masse de données est très avantageuse par rapport aux autres dispositifs. En revanche, la résolution n’est pas aussi bonne qu’une caméra et le coût d’un tel capteur est trop onéreux pour des véhicules commerciaux. La principale limite est le temps nécessaire pour traiter toutes ces données [Pet+12][Vig12]. Ce type de capteurs étant chers et volumineux, il n’est utilisé que pour l’instant que pour la conduite autonome. En revanche, il faut noter que tous les finalistes du DARPA Urban Challengeétaient équipés du capteur Velodyne HDL-64E.
FIGURE2.11 – Laser 3D (Velodyne HDL-64E)
Source : [Vel13]
Conclusion sur les différents types de lasers
Pour conclure, les capteurs lasers ont quelques inconvénients : – ils sont plus onéreux que les caméras ;
– ils sont consommateurs d’énergie ; – ils ont une résolution angulaire faible ;
– ils sont équipés de parties mécaniques qui les rendent fragiles ; – ils n’ont pas d’informations de couleurs.
En revanche, certains avantages les distinguent des autres capteurs :
– ils donnent une information de distance précise pour chaque rayon laser atteignant un obstacle ; – ils fonctionnent en pleine nuit ;
– ils peuvent fonctionner dans toutes les conditions météorologiques.
Le tableau 2.1 résume les différentes caractéristiques des lasers (modèles les plus courants).
1 couche (ex. Sick LMS200) 4 couches (ex. IBEO Lux) 3D (ex. Velodyne HDL-64E) Fréquence de balayage 75 Hz 25 Hz 5-15 Hz Champ de vue horizontal 180° 85° 360° Résolution angulaire horizontale 0.25° - 1.0° 0.125° - 1.0° 0.09° Champ de vue vertical non applicable 3.2° 26.8° Résolution angulaire verticale non applicable 0.8° 0.4° Résolution en distances 3.5 cm 4 cm 2 cm Portée de fonctionnement 0 m - 80 m 0.3 m - 200 m 50 m - 120 m
TABLEAU 2.1 – Comparaison entre différents lasers Source : [SIC07] [IBE10] [Fre09]
2.2.2
Capteurs radars
Les capteurs radars (RAdio Detection And Ranging) mesurent la distance en utilisant les ondes radio grâce au retard ou au déphasage du signal réfléchi. Ils peuvent mesurer des distances, jusqu’à 200 m avec une résolution de 10 cm et des vitesses par effet Doppler. Ils équipent par exemple les véhicules dotés d’un régulateur de vitesse avec détection de distance [Lem05].
Les radars ont cependant quelques inconvénients comme leur champ de vision qui est étroit (10° horizontalement et 3° verticalement pour les radars de longue portée), leurs résolutions angulaires faibles pour la mesure de position et enfin il arrive qu’une cible ne soit pas détectée (ou 2 fois au lieu d’une). Ils sont également tributaires de la surface de réflexion de l’obstacle (environ10 m2 pour une voiture et 2 m2 pour un piéton) et du matériau, ce qui entraîne une bonne détection des véhicules et une mauvaise détection des piétons [Lem05]. Mais ils ont aussi des avantages par rapport à d’autres capteurs comme une estimation de vitesse précise, une détection longue portée et ils peuvent être utilisés dans des conditions météorologiques défavorables [Pet+12][Vig12].
2.2.3
Capteurs optiques
Les capteurs optiques ou caméras captent la lumière issue de la scène observée pour former une image à l’aide d’un capteur matriciel. Les deux principales technologies sont le CCD (Charge-Coupled
Devices) et le CMOS (Complementary Metal Oxide Semiconductors). Ces types de capteurs sont
d’autant plus intéressants qu’ils fournissent une information importante et un coût faible (environ 4e) [Pet+12].
Les caméras sont caractérisées par leur champ de vision (ou Field Of View, FOV), défini par l’optique utilisée et par la taille de la matrice du capteur. Elles ont un taux de rafraichissement élevé et une haute résolution d’images [Pet+12][Vig12]. Elles sont utilisées dans la surveillance de l’angle mort, dans l’alerte de franchissement involontaire de ligne ou dans la vision de nuit.
2.2. Capteurs
Capteurs optiques monoculaires
Les capteurs optiques monoculaires sont des caméras avec une seule optique. Après l’obtention d’une image, il est nécessaire d’interpréter l’image avec une connaissance a priori de l’apparence d’un obstacle (un véhicule, un piéton) afin d’extraire des primitives spécifiques aux obstacles (des tex-tures, des couleurs, des ombres). Cette connaissance permet de trouver l’information pertinente dans l’image. Ensuite, une analyse de ces primitives cherche à les mettre en correspondance à partir de modèles d’objets. Puis, couplée à cette analyse, s’ajoute souvent une détection de zone d’intérêt dans les images ainsi qu’un suivi d’objet détecté avec une analyse temporelle. D’autres approches utilisent des détections de lignes et de contours ou des approches sur le flux optique. Il est cependant diffi-cile d’interpréter des données de caméras monoculaires. Elles ne capturent pas la distance des objets comme les données télémétriques ou les caméras stéréoscopiques [Lem05][Vig12].
Capteurs optiques stéréoscopiques
Une caméra stéréoscopique est une caméra avec plusieurs objectifs (généralement deux) dans le but d’obtenir des images en trois dimensions (cf. figure 2.12). Ils sont généralement équipés de deux caméras identiques et souvent dans une configuration géométrique appelée « rectifiée2» qui facilite
le traitement. Une fois la rectification faite, les deux images (acquises par la caméra de droite et la caméra de gauche) sont supposées être parallèles et alignées (voir annexe A). Grâce à ce principe, un point dans l’environnement est représenté par un pixel sur l’image de gauche et par un pixel sur l’image de droite, mais en plus les pixels sont situés sur une même ligne horizontale. Ce qui permet de simplifier la recherche de correspondance de pixels pour qu’elle devienne une recherche à une dimension. Une fois la correspondance faite, il est possible de mesurer la distance entre ces deux pixels sur l’axe des abscisses, elle est appelée valeur de disparité. Cette distance est inversement proportionnelle à la distance de l’objet [Lau+10][Vig12].
FIGURE2.12 – Capteurs optiques stéréoscopiques
Source : [TYZ13b]
La figure 2.12 montre une caméra stéréo TYZX qui a une résolution de 512 × 320 pixels, une base stéréoscopique3de 22 cm et une distance focale de 410 pixels [PPL11].
Le fait d’installer des caméras dans le véhicule peut amener plusieurs utilisations de celles-ci dans les fonctions d’aide à la conduite et donc permettre de diminuer le coût par rapport à d’autres capteurs. En plus de cela, les caméras stéréoscopiques procurent un large champ de vision (FOV), peuvent détecter des obstacles partiellement cachés et détecter la route. Aussi, comme ce sont des capteurs passifs, ils n’irradient pas la scène par leurs émissions et donc n’influent pas sur les autres capteurs. En revanche, ces capteurs sont sensibles aux conditions météorologiques, à la luminosité et nécessitent un traitement d’images [HU05].
2. Le principe de la rectification d’images est expliqué dans [Dev97]. 3. La base stéréoscopique est la distance entre les axes des deux caméras.
Capteurs RGB-D : kinect
Les capteurs RGB-D contiennent un objectif RGB (Rouge Vert Bleu) et un objectif pour la profondeur (D, Depth). Un exemple de ce type de capteur est le kinect (cf. figure 2.13). Le kinect fournit des informations sur la couleur et la distance des objets. Grâce à son prix attractif et ses données 3D robustes, ce capteur est utilisé dans beaucoup d’applications robotiques. Ce capteur fournit une image couleur et une image de profondeur avec une taille de 640 x 480 pixel. L’image de profondeur est obtenue grâce à une caméra infrarouge (IR) et un projecteur infrarouge. Avec ce principe, la portée du capteur peut aller de 0.5 m à 5 m. Ce capteur n’est toutefois pas utilisable en extérieur à cause de la lumière du soleil [Zou+12][Rob13].
FIGURE 2.13 – Capteurs kinect
Source : [Rob13]
Conclusion sur les différents types de capteurs optiques
Certains de ces capteurs ne sont pas utilisables dans des conditions de luminosité spécifiques comme en pleine nuit ou en plein soleil. Ils fournissent de gros volumes de données par rapport aux autres cap-teurs, mais conduisent à des difficultés de traitement et de transmission de celles-ci. Afin de résumer cette partie, le tableau 2.2 présente les différentes fonctionnalités des capteurs optiques.
Caméra stéréo TYZX (22 cm de
base stéréoscopique) Caméra kinect
Résolution 512x320 pixels 640x480 pixels
Champ de vue horizontal 75° 57°
Portée de fonctionnement 1.4 m - 18.3 m 0.5 m - 5 m
Image 3D oui oui
Sensible à la luminosité oui oui et ne fonctionne pas
en extérieur
TABLEAU 2.2 – Comparaison entre différents capteurs optiques Source : [TYZ13a] [Mic13a]
En conclusion, cette partie montre les différentes possibilités et limites de chaque capteur. Afin de compenser ces limites le développement d’ADAS utilise plusieurs types de capteurs (caméras, lasers, radars). Étant donné que le nombre de capteurs peut être grand et que les algorithmes, qui traitent les données des capteurs, ont besoin de s’affranchir de l’implantation des capteurs, une couche s’appelant « intergiciel » vient faire l’interface. La partie suivante montre donc les différents intergiciels utilisés dans le domaine de la robotique mobile.
2.3. Intergiciels
2.3
Intergiciels
Les robots mobiles sont des systèmes complexes qui demandent de nombreuses interactions entre des composants hétérogènes (logiciels et matériels). A cause de l’augmentation de la complexité des applications robotiques et du nombre important de matériels, les intergiciels robotiques ont été implantés. Ceux-ci ont pour but de gérer la complexité et l’hétérogénéité des matériels et des applica-tions, intégrer de nouvelles technologies, simplifier l’architecture logiciel, cacher la complexité de la communication bas niveau et réutiliser l’infrastructure logicielle [ES12].
Les intergiciels robotiques sont une couche d’abstraction qui se trouve entre le système d’exploitation et les logiciels applicatifs. Ainsi l’ingénieur logiciel ou le chercheur n’a plus qu’à s’occuper de l’al-gorithme comme un composant. Ce composant peut interagir, être combiné ou intégré avec d’autres composants. Les principaux avantages sont la modularité, l’abstraction de l’architecture matérielle, la standardisation des interfaces de programmation (Application Programming Interface, API) des matériels et la portabilité des logiciels applicatifs sur différentes plates-formes. Ainsi, l’intergiciel doit être facile à utiliser, robuste, fiable, évolutif, facile à maintenir et supporter la distribution sur plusieurs systèmes [ES12].
De plus, les intergiciels amènent une transparence en ce qui concerne l’enregistrement et le rejeu de données. Cette transparence permet aux équipes de recherche de faire fonctionner leurs algorithmes, soit avec les données capteurs, soit avec les données provenant d’un enregistrement.
Étant donné le nombre d’intergiciels existant dans le domaine de la robotique mobile, les prochaines parties présentent les principaux intergiciels utilisés.
2.3.1
OROCOS
Le projet OROCOS a démarré dans le mois de décembre 2000 suite à plusieurs expériences décevantes et échecs lors de la tentative d’utilisation de logiciels commerciaux de contrôle de robots pour la recherche. Aucun logiciel générique de contrôle de robots n’existait à cette date [CM10]. L’intergiciel OROCOS est organisé en cinq bibliothèques. La première est la boîte à outils en temps réel (RTT) qui fournit un cadre pour développer des systèmes de contrôle en temps réel. Ensuite deux bibliothèques fournissent des fonctionnalités de filtrage bayésien (BFL) ainsi que la modélisation et le calcul de la chaîne cinématique. Puis une bibliothèque de contrôle contient des composants prêts à l’emploi pour des applications de contrôle. Enfin, la dernière bibliothèque, la boîte à outils Simulink, permet de créer des Composants OROCOS dans Matlab et Simulink [Tho10].
2.3.2
ROS
L’intergiciel ROS a débuté avec la création d’un laboratoire de recherche nommé « Willow Garage » à la fin de l’année 2006. Il était destiné à accélérer le développement des logiciels robotiques non militaires et à fournir un intergiciel libre (open source). Comme Willow Garage produit à la fois du logiciel et des robots, l’intergiciel ROS est donc testé sur leurs propres robots [CM10].
Cet intergiciel est un type de méta-système d’exploitation car il fournit des services comme la gestion des composants et la construction de ceux-ci. Il communique à travers un système de messages qui est basé sur un serveur maître pour négocier le message d’échange et ensuite il communique les données en pair-à-pair (peer-to-peer). L’accent est mis sur la réutilisabilité des composants faiblement couplés, sur le partage et la collaboration. Effectivement, Willow Garage développe le cœur de l’intergiciel et une communauté de chercheurs et d’utilisateurs ROS implantent de nouveaux algorithmes et de
nom-breux pilotes pour qu’ils soient disponibles à tous [Tho10]. Dans le tableau 2.3, il est inscrit que ROS est capable d’effectuer du temps réel (d’après l’auteur) mais ROS ne peut garantir l’arrivée de mes-sages. Effectivement il est basé sur le noyau Linux qui n’est pas temps réel dur. En revanche, il peut fournir des messages à une fréquence élevée, ainsi les applications peuvent donner des informations en temps réel à une fréquence acceptable pour des applications de robotique mobile (25 Hz).
2.3.3
Player
Au début des années 2000, l’intergiciel Player a vu le jour. C’est une interface robotique multiplate-forme et un serveur. Il est surtout utilisé dans la recherche robotique et l’éducation. Il ne fait aucune hypothèse sur la structure interne du logiciel de commande du robot. Mais il fournit un ensemble d’interfaces génériques à une variété de capteurs et d’actionneurs. La communication entre plusieurs processus ou hôtes se fait par le biais de la représentation externe de données4(eXternal Data Repre-sentation, XDR) [Tho10].
2.3.4
Orca
Orca est un cadriciel libre (framework open source) pour le développement de systèmes robotiques à base de composants. Il est axé sur la réutilisation des logiciels dans la recherche robotique et de l’in-dustrie. L’objectif général est d’être largement applicable en imposant des contraintes de conception minimales. Il contient un ensemble d’interfaces prédéfinies dans le but de préserver l’interopérabilité avec les autres composants. Des implantations de pilotes pour une variété de robots et de capteurs sont fournies dans un sous-projet d’Orca, appelé Hydro. Alors que les versions précédentes ont été construites au-dessus de CORBA et SOAP, la dernière version utilise le moteur de communication in-ternet (Inin-ternet Communications Engine, ICE) pour la communication entre composants. ICE fournit une compatibilité multilangue et multiplateforme pour les communications et comprend également l’invocation de méthodes distantes [Tho10].
2.3.5
Intergiciels soumis à licence payante
Ce type d’intergiciels ne sont pas beaucoup utilisés dans le domaine de la recherche publique mais certains laboratoires de recherche ou industriels les emploient.
Tout d’abord l’intergiciel AROCCAM (Architecture d’Ordonnancements de Capteurs pour la Créa-tion d’Algorithmes Modulaires), créé en 2004 par le Cemagref et le Lasmea, a été conçu dans le but de dissocier les modules de fusion de données et la récupération des données des capteurs. Son prin-cipal objectif est de fournir des données aux modules de traitements avec un minimum de latence et en temps réel. AROCCAM a été utilisé et testé par le Lasmea et repris en 2009 par la société Effi-dence. Le cœur d’Aroccam est implanté en C++, il est basé sur un système de greffon5qui lui permet
d’être modulaire et de pouvoir communiquer avec de nouveaux capteurs et de nouveaux modules de traitement. La communication entre les différents composants se fait par le biais de FIFO (First In, First Out, « premier arrivé, premier sorti ») et par plusieurs fils d’exécution (multithread) [Tes+06]. Ensuite, RTmaps ouRTm@ps qui signifie Real-Time « des Mines » Automotive Prototyping System, est un intergiciel créé par le Centre de Robotique de l’école des Mines de Paris puis repris par la
4. La représentation externe de données (XDR) permet d’encoder des données indépendamment de l’architecture afin de transférer des messages sur des systèmes hétérogènes. La conversion des données vers le format XDR s’appelle aussi Marshalling.
![TABLEAU 2.1 – Comparaison entre différents lasers Source : [SIC07] [IBE10] [Fre09]](https://thumb-eu.123doks.com/thumbv2/123doknet/5566877.133445/33.892.101.795.229.434/tableau-comparaison-lasers-source-sic-ibe-fre.webp)
