P25 Architecture ROS pour des véhicules autonomes intelligents

Cahier des charges

Présentation générale du projet

Le véhicule robuCAR à dSpace 1103

Mise en place d'une architecture à base de Robot Operating System (ROS)pour la gestion de la mobilité de véhicules intelligents autonomes

Contexte

Il y a au sein de l'école trois robuCARs, véhicules électriques pouvant transporter jusqu'à 400 kg et étant limité à la vitesse de 18 km/h. Chacun des véhicules possède une technologie de commande embarquée différente de l'autre. Le véhicule sur lequel l'essentiel du travail va être exécuté dispose d'une DSpace 1103. Dans le cadre du projet InTraDE, le RobuTainer se doit de se déplacer de façon autonome dans un environnement restreint. Il est ici proposé de travailler à l'aide d'un robuCAR car c'est bien moins encombrant et par conséquent plus adapté pour les tests d’algorithmes développés pour InTraDE .

Objectif du projet

Les différents objectifs du projet sont les suivants :

• Prendre connaissance de l'architecture matérielle et logicielle du robuCAR et réaliser les modifications nécessaires
• Réaliser une architecture ROS générique permettant de rendre possible le déplacement autonome dans le campus
• Créer une interface homme-machine pour le contrôle du robot

Description du projet

Le projet consiste à automatiser le déplacement d'un véhicule électrique dans un environnement confiné. L'architecture ROS qui permettra aux robots d'être autonome sera aussi générique possible pour permettre sa réutilisation sur d'autres plate-formes mobiles. La synthèse de différents codes existants du projet InTraDE et son adaptation permettront au binôme de rassembler ces différentes briques dans le but de relier le tout ensemble.

Choix techniques : matériel et logiciel

Le matériel mis à la disposition pour la réalisation du projet est : Un robuCAR contenant :

• Une DSpace 1103
• Un PC de contrôle
• Un module GPS
• Une centrale inertielle
• Un laser
• Un PC portable

Le code à faire évoluer sera :

• Sous Windows
  • Matlab R2006a (Simulink)
  • Control Desk
  • Python
  • PURE

Le code à créer sera :

• Sous Ubuntu
  • ROS (C++)

Étapes du projet

Partie 1 : Adaptation des codes existants

• Réalisation de la modélisation du véhicule
• Calculer les différentiels nécessaires
• Régler le problème de blocage après le dépassement de la plage de bon fonctionnement
• Faire une revue complète des codes existants (modifications et optimisations)
• Modifier mode de contrôle (humain doit pouvoir reprendre à tout moment la main)

Partie 2 : Automatisation du déplacement du véhicule dans Lille 1

• Obtenir une carte précise de la zone de travail
• Modéliser la carte à l'aide de RoadXML
• Configurer une balise RTK pour améliorer précision GPS
• Relever les données gyroscopiques, odométriques et GPS
• Localiser le véhicule(x, y, theta)
• Réaliser un évitement d'obstacle minimal
• Rechercher un chemin optimal (plus courte distance)
• Suivre le chemin le mieux possible

Partie 3 : Interaction homme-machine

• Simplifier les procédures de démarrage
• Créer une interface suffisamment intuitive permettant à l'utilisateur de se déplacer dans le campus de Lille 1

Suivi de l'avancement du Projet

Semaine 1 (21/09/2015)

Rendez-vous avec M. Vincent Coelen :

• Premier contact avec le véhicule de type robuCAR
• Récupération de rapports et codes du projet InTraDE
• Visualisation des différentes interfaces de travail
• Début de lecture et analyse des rapports

Semaine 2 (28/09/2015)

Vue globale de l'architecture du systeme

• Suite de la lecture des rapports concernant les travaux à modifier ou à intégrer. Notamment le rapport de projet IMA5 2012/2013 sur lequel le fonctionnement du robuCAR que nous allons utiliser repose toujours. Nous avons donc extrait de ce rapport, ainsi que des indications de Vincent Coelen deux modifications primordiales :
  • Résoudre le problème de butée de direction (il s'agit actuellement d'une butée logicielle via valeur arbitraire afin d’éviter un blocage physique)
  • Améliorer l'asservissement des roues en vitesse lors de virages, afin d'avoir des vitesses différentielles correctes.

Il faudra par la suite réorganiser les "modes" de pilotages ainsi que les "switch" ajoutés au fur et à mesure des modifications.

• Définition du travail à réaliser et de celui à intégrer :
  Sur le schéma suivant, on peut observer les différents actionneurs en bleu, capteurs en vert et contrôleurs en rouges. Le programme créé sous Simulink (MATLAB) est exécuté sur la dSpace. L'interface de contrôle qui permet de régler des variables et les "modes" est codée avec control desk. Si l'on veut donner des ordres de façon logiciel, la bibliothèque Clib peut écrire dans les emplacement mémoires des variables utilisées par Simulink. Afin d'automatiser le processus des scripts pythons ont donc été crées afin de récupérer grâce à un parser les correspondances entre nom de variables et adresse mémoire.

Semaine 3 (05/10/2015)

Très peu d'heures de projet cette semaine, nous avons donc récupéré le projet puis essayer de comprendre la conception et l'architecture du projet créé en 2012/2013. Pour cela nous nous sommes créé une machine virtuelle Windows XP sur nos deux machines, avec installation de MATHLAB R2006a. Cela nous a permis de afin de pouvoir observer les fichiers Simulink et donc trouver les zones sensibles ou nous devons agir. Les fichiers étant constitués de nombreux blocs de code mathlab, gérant les fonctions d’interface et de contrôle, il est probable que la structure du projet ne soit pas modifié.

Semaine 4 (12/10/2015)

Cette semaine, nous avons sorti le robuCAR du garage pour faire des essais sur piste, afin de constater les problèmes de fonctionnement extraits de la lecture du rapport des travaux du projet de 2012/2013.

• Le problème de blocage des roues est bien présent, lorsqu'un virage est pris en vitesse, et d'autant plus avec les deux trains directionnels activés. En effet, malgré la consigne de régulation, les forces physiques sur les roues entraînent la direction qui dépasse alors la limite logicielle imposée afin de ne pas aller en butée physique.

On doit alors utiliser le mode manuel afin de commander le train sans la limite logicielle.

• Le fonctionnement de la traction en boucle ouverte permet de régler les problèmes de vitesses différentielles, mais après réflexion le calcul du point de rotation du véhicule serait trop imprécis dû au jeu évident constaté sur le véhicule (deux roues d'un même train n'ayant pas le même angle). Le fonctionnement en boucle ouverte assurant les déplacements, il est envisageable de continuer la suite du projet. Il sera de toute façon toujours possible de revenir sur cet aspect du projet par la suite.

Semaine 5 (19/10/2015)

Bloc de gestion de la consigne de traction

La localisation du problème de blocage des trains en direction à été trouvée dans le projet. Une solution assez simple à été codée, puis les modifications on été apportées. Le plus long et difficile fut de trouver et de comprendre la partie du projet à modifier. Du temps a aussi été passé afin de mettre en place la modification et de la rendre effective sur le robuCAR. Il faut en effet effectuer les modifications sur le projet Matlab à partir du pc associé à la Dspace (la copie ne semble pas possible) puis recompiler la totalité du projet et enfin relancer complètement le véhicule.

Après quelques virage de test, un train de direction dépassant la consigne et bien bloqué et ne reçoit plus de consignes jusqu’à ce que la direction demandée reparte dans l'autre sens. Cependant lors de ces test deux autre problèmes ont étés détectés :

• Lors d'une marche arrière l’accélération est beaucoup moins rapide qu'en marche avant. Le système de traction étant en boucle ouverte, il en résulte que le délai [appui pédale - déplacement] est beaucoup plus (et trop) long. (entre 3 et 5 secondes)
• Une fois la marche arrière commencée, si l'on relâche l'accélérateur, le robuCAR décélère bien comme c'est le cas en marche avant. Cependant si l'on presse la pédale de frein, au lieu de s’arrêter le robot se contente de maintenir la consigne de vitesse qui était appliquée. Il s'agit là de l'un des soucis les plus dangereux que nous ayons eu à faire sur le robuCAR, car en cas de problème, on à le réflexe d'enfoncer la pédale de frein. De plus ce problème n'avait pas été indiqué sur le rapport du groupe 2012/2013 et donc probablement pas identifié à l’époque.

On peut donc constater qu'à l’origine un bloc de code Matlab traite les données des axes de pédales(axes_y/z), du rapport de vitesse choisi(intelligemment nommé "acce"), de la vitesse réelle et de l’activation ou non de la MAr. On retrouve en sortie une consigne accompagné de limites haute et basse passés à un "Rate Limiter Dynamic", qui va se rapprocher de la consigne pas à pas en fonction de l’état précédent et des limites hautes et basses. Ce bloc à l'avantage d’éviter les saut de de consigne sur les moteurs, mais aucune modification des limites haute et basse n'avait été prévu lors d'une MAr. Une fois de plus la modification fut rapide (quelques if/end supplémentaires), le plus laborieux étant d'identifier la cause du problème.

Nous avons par la suite décidé de laisser dans cet état le robot afin de passer à l’étape suivante : La commande via le protocole PURE. Pour cela nous avons récupéré un descriptif de ce protocole, qui est essentiellement un service de messagerie avec une étape de découverte des services disponibles sur le véhicule. Il a été créé par robosoft (fabricant du robuCAR, robuRIDE, robuTAINER...), afin d'unifier les méthodes de contrôle de leurs produits. Un serveur PURE est implementé sur chaque vehicule lors de sa sortie d'usine, et un client PURE-ROS a été codé précédemment au sein du laboratoire CRIStAL. Malheureusement, lors de la sortie de notre robucar puis lors de la modification de son système de traction, ce protocole n'existait pas encore. Une version précaire du serveur à été développé en c++ précédemment, mais celui ci ne permet pas d'ajout facile de service. Une refonte totale du programme, avec un usage correct des classes est envisagé.

Semaine 6 (26/10/2015)

Nous avons commencé à travailler sur le serveur PURE. Celui ci devra permettre une évolution plus simple, via une structure plus organisée. Une utilisation de classes pour les services, avec un classe mère possédant toute les fonctions définies en virtuel. La demande de services non implémentés et leur ajout par la suite sera alors plus aisé. Néanmoins les interactions entre services, notamment celui de "notifications" et "directory" impose soit une structure particulière pour ces deux là, soit une gestion au niveau du main. La gestion de l’état d'ouverture et d'utilisation des services ainsi que la récuperation des paquets UDP devrait aussi rester dans le main.

Semaine 7 (02/11/2015)

Après discussion avec M. Coelen, nous avons déterminé les parties à faire sur la dSPACE et celles sur le PC externe. Ce qui sera fait sur le PC sera codé en C++ à l'aide de ROS et ce qui sera fait sur la dSPACE sera codé avec Matlab à l'aide de PURE.

• Pour la dSPACE, nous allons récupérer les informations odométriques et celles du GPS. De plus, la localisation sera aussi effectué sur la dSPACE car les informations nécessaires pour se localiser sont déjà dans la dSPACE et on aura une plus faible latence pour déterminer le positionnement exact du véhicule.
• Pour le PC externe, nous allons réaliser l'IHM ainsi que le noeud qui permettra de convertir les lieux de destination en coordonnées GPS. A l'aide d'une map préalablement construite, un chemin pourra être généré. Le laser sera en outre branché directement sur la dSPACE pour pouvoir détecter les obstacles. L'évitement d'obstacle, la génération de chemin et la localisation permettront de suivre au plus près possible le chemin généré. On effectue cela sur le PC externe car on veut que notre système soit le plus autonome possible et c'est bien plus simple (et moins cher aussi) avec l'utilisation de ROS sur un PC qu'avec Matlab sur une dSPACE.

Localisation

La localisation prend en compte les données GPS et odométriques. Dans le cas où aucun signal GPS n'est capté, le RobuCar doit pouvoir continuer à se localiser. Un filtre de Kalman étendu est appliqué pour corriger la dérive odométrique. Les coordonnées GPS/WGS84 sont converties en coordonnées planes Lambert.

Laser

Laser Sick

Visualisation des points de mesure

Nous avons extrait les données de notre laser SICK LMS221 sur un PC personnel. Il a juste fallu installer les drivers, pluger un convertisseur RS232-USB sur le PC et alimenter le laser avec 24 V continu. Ce laser est capable de voir de 10 cm à 81 m. Il effectue des mesures sur 180° tous les 0,5°. Il fonctionne à une vitesse de 38400 bauds.
A l'aide de rviz (logiciel de visualisation intégré à ROS), nous pouvons observer les différents points de mesure vus par le laser. Chacun des points représente un point de mesure du laser. Le laser se situe au centre de la map.

Actuellement, il est prévu de réaliser un correcteur proportionnel pour éviter les obstacles. Si un obstacle se situe entre 1,5 m et 0,5 m, on diminue la vitesse proportionnellement. Si un obstacle est à moins de 50 cm, on stoppe le véhicule jusqu'à la disparition de l'obstacle.

Semaine 8 (09/11/2015)

Laser

Après avoir récupérer les points de mesure, nous avons créé des obstacles. Les obstacles proches sont considérés comme dangereux, il faudra donc réduire la vitesse en leur présence voire s'arrêter totalement. Pour ceux qui ne sont pas dans la zone de danger, on peut considérer qu'ils ne sont pas prendre en compte. Ce lien mène a une vidéo qui permet de visualiser les obstacles visibles par le laser.

Map

Afin de rendre le projet indépendant du lieu de travail, il nous faut pouvoir exporter (ou réaliser puis exporter) une carte du lieu en question. Etant donné qu'OpenStreetMap est open source, nous nous sommes donc orientés vers cette solution. Il faudra à présent pouvoir l'utiliser avec les divers modules existants.

Semaine 9 (16/11/2015)

Map

Certains modules de ROS permettent de convertir des fichiers avec l'extension osm (fichiers exportés à l'aide de OpenStreetMap) en topics. Un utilisateur lambda peut facilement exporter une map de son choix avec son navigateur préféré. Cela générera un fichier map.osm. Toutes les données brutes d'OSM (nœuds, voies, relations et propriétés/étiquettes) sont contenus dans un format XML. Ainsi, nous avons pu assez rapidement pu visualiser une map du campus de Lille 1 avec rviz (logiciel de visualisation intégré à ROS).Ci-dessous nous pouvons avoir un vis-à-vis sur la map visible sur le site d'OSM et la visualisation avec rviz. De nombreuses informations ne nous sont pas utiles pour réaliser le path finding tels que les bâtiments, les chemins seulement accessibles aux piétons ou la ligne de métro.

Semaine 10 (23/11/2015)

Path finding

Bien que nous sachions visualiser n'importe quelle OpenStreetMap, les données qui transitent dans les topics ne permettent de réaliser la recherche de chemins, en effet, tout est envoyé sous forme d'UUID (lien wikipédia UUID). Nous avons donc cherché où la correspondance était faite entre les coordonnées GPS (WSG84) et les UUID. Du code Python permettait de réaliser cela, c'est pourquoi il a fallu apprendre quelques bases en Python pour comprendre le code et le modifier pour notre usage. Une fonction Python permet de convertir les UUID des points en coordonnées de projection. La projection en question est la Transverse Universelle de Mercator dans la zone 31. Ce qui permet donc d'avoir un système métrique sur lequel on peut utiliser la géométrie de base pour se repérer, chercher un chemin, suivre un chemin, etc. Il nous reste à présent à réaliser un graphe où chaque nœud correspond à un point et chaque arc correspond à un segment de route.

Semaine 11 (30/11/2015)

Path finding

A l'aide de la librairie boost, nous avons réalisé notre graphe et y avons appliqué l'algorithme A* pour rechercher rapidement le plus court chemin pour atteindre un chemin de notre choix. Pour des raisons de pragmatiques de visualisation, nous avons travaillé sur une portion plus petite de la map. Ainsi, nous pouvons visualiser l'OSM, puis le graphe lié à notre map et la visualisation des routes sur rviz. Nous pouvons remarqué que sur rviz, nous avons les routes visibles jusqu'à ce qu'elles croisent d'autres routes. Cela est du au fait que chaque route dans OSM est une succession de points avec un point de début et un point de fin donc lors de l'exportation, nous avons tous les points compris entre le points de début et le points de fin. Les sens uniques sont en jaune et les routes en double sens sont en violet. En observant la map sur rviz, nous pouvons distingué deux problèmes :

• Les voies réservées aux piétons sont considérés comme des routes à part entières.
• Il manque des sens uniques : on ne peut prendre un rond que dans le sens trigonométrique.

Semaine 12 (07/12/2015)

Path finding

En adaptant les modules présents dans ROS, nous avons réussi à ne récupérer que les routes destinées aux véhicules et à éliminer les voies réservées aux piétons et la ligne de métro encore présentes. De plus, pour pouvoir avoir une map correspondant à la réalité physique, il suffit juste d'éditer la map dans OpenStreetMap. En à peine 5 min, n'importe quel utilisateur peut créer ou modifier des routes de part l'interface très user-friendly. Au bout de quelques secondes, la map est chargée et il ne reste plus qu'à l'utilisateur de décider où il souhaite aller. Le chemin est générée immédiatement, il n'y a aucun temps de latence. Il est visible en vert surbrillant. Dans le cas où aucun chemin ne peut être trouvé, aucun chemin n'est affiché. Il faut à présent que la communication entre la DSpace et ROS (serveur PURE) soit fonctionnelle pour envoyer les coordonnées GPS du véhicule et pour pouvoir réaliser un path finding dynamique. Ci-contre, nous pouvons voir le chemin généré pour aller de Polytech à la résidence Galois.

Semaine 13 (14/12/2015)

Durant cette semaine nous avons terminé de réaliser le rapport et le support de présentation.

Semaine 14 (04/01/2016)

Nous nous sommes penchés sur le code Matlab réalisé pour comprendre plus précisément comment fonctionne la localisation actuellement présente sur le robucar. Les données GPS (WSG84) sont converties en données Lambert pour travailler dans un système métrique. Etant donné le travail réalisé avec la recherche de chemin, nous avons plutôt besoin que les données soient converties en données UTM. En recherchant sur le web et en modifiant les codes trouvés à notre usage, nous pourrons avoir notre position en coordonnées UTM à partir du moment où le module GPS est installé sur le robuCAR. Ci-dessous, nous pouvons voir les résultats obtenus, ces résultats correspondent aux valeurs obtenues à l'aide d'autres outils de conversion. C'est pourquoi nous avons demandé à M. Pollart de bien vouloir nous mettre à disposition le module puis de l'installer sur le robuCAR. Si aucun problème ne se pose, l'installation sera faite pour la semaine prochaine.

>> lat=50.609554
    lat = 50.60955400000000
>> long=3.13836426
    long = 3.13836426000000
>> [x,y,utmzone]=deg2utm(lat,long);
>> x
    x = 5.097902208130185e+005
>> y
    y = 5.606416400588946e+006
>> utmzone
    utmzone = 31 U

A l'aide d'un soft du fabricant du module GPS Novatel, nous avons été capable de capter des signaux GPS au niveau du parking où se trouve le robuCAR. Nous obtenons les coordonnées suivantes :

• latitude : 50.60900238
• longitude : 3.13724846