P25 Architecture ROS pour des véhicules autonomes intelligents

Cahier des charges

Présentation générale du projet

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 proposé de travailler à l'aide d'un RobuCar car c'est bien moins encombrant et par conséquent plus adapté pour les tests.

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é.