#explorebycreative Episode 2 : Notre robot et ses capteurs

#explorebycreative Episode 2 : Notre robot et ses capteurs
#explorebycreative

Après la présentation des objectifs du projet, revenons plus en détails sur le robot et le matériel utilisés pour les accomplir. L'exploration autonome est une tâche complexe qui nécessite que le robot construise une représentation interne de son environnement, qu'il peut ensuite utiliser pour choisir ses prochains objectifs et les atteindre sans collisions.

D'abord, quelques précisions sur le robot : on se sert aujourd'hui du terme "robot" pour de nombreux systèmes qui possèdent un certain degré d'autonomie, mais la définition précise que nous retenons pour le projet est la suivante :

Un robot est un agent autonome et physique, constitué de :

·  Capteurs pour percevoir son environnement ;

·  Actionneurs (moteurs) pour interagir avec son environnement (déplacement, manipulation...) ;

· Une tâche : il faut garder à l'esprit qu'un robot "autonome" est en réalité autonome uniquement dans la réalisation de cette tâche, fixée extérieurement par un opérateur humain, et les décisions du robot sont guidées par celle-ci.

La représentation schématique du robot

Percevoir l'environnement

Pour le projet Explore, nous utilisons Pepper, un robot humanoïde holonome développé par Aldebaran puis SoftBank. Pepper est conçu comme un robot d'accueil, spécialisé pour l'interaction avec des humains. Il embarque donc des capteurs avancés pour la perception de son environnement, et des routines de sécurité pour éviter de rentrer en collision avec ce qui se trouve autour de lui.

Pour se repérer, Pepper dispose d'un LiDAR au niveau de ses pieds et de 2 caméras (une caméra RGB et une caméra RGBD) au niveau de la tête. Cependant, ces capteurs, qui sont suffisants pour des tâches de localisation dans un environnement connu ou de détection d'obstacles et de personnes, sont limités pour les tâches d'exploration et de reconstruction qui nous concernent : ils fournissent notamment des mesures trop peu précises, et à trop faible résolution.

Pour pallier ce problème, nous avons choisi d'équiper Pepper de capteurs plus performants :

·     Un LiDAR 2D plan de la marque RPLiDAR (modèle A2M8), qui offre une résolution de 1° pour les mesures de distance contre 45° pour le LiDAR embarqué de Pepper.

·     Une caméra RGBD Kinect Azure : après le succès commercial de la Kinect pour la XBox, Microsoft a continué le développement de sa caméra pour en faire un capteur haut de gamme destiné à des applications robotiques plus exigeantes.

D'autres possibilités ont également été envisagées, notamment pour le choix de la technologie RGBD à utiliser pour la caméra; nous envisageons aussi à terme l'utilisation d'un LiDAR 3D qui permettrait de mieux fusionner les données de la caméra avec les données du LiDAR.

Intégration et contrôle

Pour accéder aux mesures de ces capteurs additionnels, il est nécessaire de les relier d'une manière ou d'une autre à Pepper afin qu'il puisse prendre ses décisions sur la base de ces données plus riches. Pour alimenter les capteurs et effectuer le traitement des données à bas niveau, nous avons choisi d'utiliser un kit de développement Jetson Nano de NVidia : il s'agit d'un micro-ordinateur, comparable en termes de fonctionnalité avec un RaspberryPi, mais embarquant une carte graphique pour une puissance de calcul supérieure, particulièrement pour des applications de traitement d'image.

Les capteurs sont reliés à la Jetson Nano et l'ensemble est fixé mécaniquement sur Pepper (nous détaillerons la conception et la réalisation de l'assemblage mécanique dans un prochain post!). Pour la communication entre Pepper et ces nouveaux capteurs, nous nous appuyons sur le middleware ROS (également détaillé dans un futur article), qui offre la possibilité de communiquer avec les capteurs en WiFi. La communication est donc établie en connectant la Jetson Nano et Pepper sur le même réseau WiFi.

La Jetson Nano utilisée pour interfacer Pepper et ses nouveaux capteurs

Une remarque pratique

Pour une tâche difficile telle que l'exploration autonome, on voit que le système devient rapidement complexe, particulièrement dans un contexte de recherche, il faut composer avec les limites de chacun des composants et les faire fonctionner ensemble de manière cohérente. Pour cette raison, les procédures expérimentales peuvent être longues à mettre en place, et le développement sur un robot réel fortement ralenti par la durée nécessaire pour tester les fonctionnalités développées.

Il est donc indispensable de développer également une simulation du système, qui permette d'accélérer le cycle de développement en facilitant le test rapide de nouvelles fonctionnalités dans un environnement contrôlé. La simulation doit idéalement être un équilibre entre facilité d'utilisation et réalisme du système; elle doit aussi rester aussi proche que possible de celui-ci en termes d'interfaces de contrôle. Un futur article sera également dédié entièrement à la simulation développée pour Explore.

N'oubliez pas, abonnez-vous ! #explorebycreative sur la page LinkedIn du groupe