Guidage et Surveillance d'un véhicule à travers un Cockpit de conduite
Charlotte BRICOUT
Nathan MARTIN
IMA4 - Polytech Lille
Dans le cadre de la quatrième année au sein de la spécialité Informatique-Microélectronique-Automatique à Polytech Lille, nous allons réaliser un projet permettant de piloter et surveiller un véhicule autonome à travers un cockpit de conduite. Ce projet est dans la continuité du projet européen InTraDE (Intelligent Transportation for Dynamic Environment), consistant au transport autonome d'un fret. Notre projet sera encadré par Rochdi MERZOUKI et Xavier REDON.
Résumé du projet:
Nous souhaitons relier le cockpit de conduite de Polytech Lille à un véhicule autonome Robucar. Le cockpit qui fonctionne sous le logiciel de simulation temps réel SCANeR Studio, communiquera directement en WiFi avec le Robucar. Tout d'abord, nous modéliserons le parking de Polytech Lille sur le logiciel SCANeR Studio afin de créer un environnement pour la simulation. Ensuite, nous élaborerons un scénario dans lequel nous intégrerons un véhicule de type Robucar, pouvant être piloté par une API (Application Programming Interface) que nous programmerons sur le PC supervision du cockpit de conduite. L'objectif de ce projet est de récupérer la vitesse et l'angle de braquage des roues du Robucar et de les envoyer au PC Supervision où ils seront récupérés par une API. L’envoie de ces consignes se fera par le biais d’un serveur UDP. L’API, constituant un client pour le serveur, prendra en charge l'application des consignes reçues au cockpit de conduite et au modèle dynamique Robucar de la simulation. De ce fait, nous verrons évoluer le Robucar en temps réel dans la simulation et simultanément, le volant du cockpit suivra les mouvements du véhicule réel. L'utilisateur pourra ainsi suivre le déplacement de la Robucar dans la simulation et observer, parallèlement, les mouvements du volant dans le cockpit. Cette application est utile pour la surveillance mais aussi pour le guidage d’un véhicule.
Sommaire
Matériel à disposition
Pour notre projet nous avons à disposition:
- un véhicule Robucar muni d'un PC intégré et d'une carte d'acquisition DSPACE (en C002)
- les logiciels permettant sa conduite, à savoir Matlab, Simulink et Control Desk
- un PC supervision (en C002)
- un Cockpit de simulation (en C002)
- un Accès au logiciel de simulation SCANeR Studio (en C002)
Nous travaillerons sur le logiciel de développement Microsoft Visual Studio 2005 pour programmer le serveur et l'API.
Description des outils à disposition
SCANeR Studio: Logiciel de simulation pour la recherche et l'ingénierie
SCANeR Studio est un logiciel de simulation de conduite automobile Temps Réel offrant à ses utilisateurs une interface de surveillance ou de contrôle d'un véhicule (voiture, poids lourd, cycliste, 2 roues etc). Il permet la représentation d'un environnement, modélisé en 3D dans le logiciel, auquel un ou plusieurs véhicules sont intégrés. Les véhicules simulés sont de différents types et on s'intéressera pour notre application aux véhicules "simples" et "Advanced".
Selon leur type, les véhicules sont contrôlés par différentes API dans SCANeR Studio:
- automatiquement par la simulation : API TRAFFIC, c'est le cas des véhicules de type simple.
- à l'aide d'un élément extérieur tel qu'un cockpit de simulation ou un véhicule réel : API Modelhandler, c'est le cas des véhicules de type Advanced.
Le logiciel comporte 5 modes permettant de réaliser une simulation:
- Terrain : permet de modéliser un environnement
- Véhicule : permet de sélectionner, de créer ou d’importer un véhicule dans la simulation
- Scénario : permet d’établir un scénario avec un Terrain et des Véhicules et de choisir les API
- Simulation : permet de simuler le Scénario en Temps réel
- Analyse : permet de récupérer des données de la simulation
Pour réaliser notre simulation, nous commençons par créer un terrain représentant le parking de Polytech Lille. C'est dans le mode scénario que nous choisissons les véhicules à intégrer à la simulation. Ici, nous avons intégré un véhicule Robucar (de type véhicule "Advanced") et on intègre éventuellement des véhicules simples. Dans le mode simulation, nous choisissons les API qui seront actives. Ici, les API indispensables sont "Modelhandler" et l'API que nous avons développé pour lire les consignes envoyées par le serveur et les appliquer dans la simulation. Les deux API vont s'échanger des données par le biais de canaux : les Export Channels. Notre API enverra donc une consigne de vitesse et d'angle de braquage des roues sur des Export Channels, définis par un nom ou un numéro, afin que ModelHandler puissent lire ces informations.
Le véhicule ROBUCAR
Le Robucar est un véhicule automatique "intelligent", autonome et électrique, commercialisé par la société ROBOSOFT. Il est composé d'un châssis à quatre roues motrices et directionnelles pilotables séparément. Il y a donc deux paramètres de commande pour chaque roue : l'orientation et la vitesse de rotation). Le véhicule est équipé d'un ordinateur de bord et d'une carte d'acquisition Temps Réel DSPACE qui récupère les données du véhicule. L'accès à ces données sur d'ordinateur intégré est rendu possible par la librairie CLIB. Celle-ci permet, en effet, de récupérer les données acquise par la DSPACE.
Dans le cadre de notre projet, nous considérons que seules les roues avant du véhicule sont directionnelles. Nous appliquerons donc la même consigne de vitesse et de braquage aux deux roues avant.
Création d'un Serveur UDP
Pour créer une communication entre le PC supervision et le PC intégré au Robucar, nous avons choisi de créer un serveur UDP. Nous avons préféré ce protocole au TCP car il est plus rapide et la perte de quelques paquets n'est pas gênante pour notre application. C'est donc sur l'aspect temps réel de la simulation que nous souhaitons mettre l'accent. Le serveur est implémenté en langage C++ sur Windows grâce à la bibliothèque Windows Sockets 2 (« Winsock2 »). Le RobuCar est piloté avec un programme Matlab et son programme Simulink correspondant. On charge dans le logiciel dSPACE ControlDesk du Robucar le programme de pilotage correspondant à celui sur MATLAB. Une interface apparaît et nous pouvons alors accès à un poste de pilotage pour diriger le véhicule (cf figure ci-dessous). Lors de la conduite, des valeurs de consignes de la vitesse moyenne et l’angle de braquage des roues sont récupérées par le serveur grâce à la bibliothèque «clib32». Le serveur implémente une structure de données contenant les deux valeurs et forme avec celles-ci un paquet à envoyer au client. Sur le PC supervision, l'API Client se connecte au serveur et reçoit alors des paquets contenant les consignes de vitesse et de braquage.
Journal de bord
Semaine 1
Lors de cette première séance, nous avons pris en main le logiciel SCANeR Studio et notamment le mode terrain qui permet de concevoir un environnement de simulation. De ce fait, nous avons débuté la conception du parking de Polytech Lille sur le logiciel. Pour créer des routes identiques à celles du parking, on utilise une image satellite de celui-ci et on calque les routes créées sur la photo. Pour chacune des routes, on définit le sens de circulation et le mode de priorité.
Semaine 2
Pendant cette séance, nous avons finalisé la conception du parking sur SCANeR Studio. Pour le tester, nous créons un scénario mettant en scène plusieurs véhicules de type "simple" qui sont pilotés automatiquement par le logiciel grâce à l'API Traffic. Nous lançons ainsi la simulation et observons le comportement des véhicules sur les routes que nous avons conçu pour s'assurer du bon paramétrage de chacune des parcelles de routes.
Résultats des simulations sur le terrain:
- Dans certains virages et dans le rond point à l'entrée du parking, le comportement des véhicules en mode automatique est anormal
- Les véhicules se comportent normalement sur les lignes droites, aux Cédez-le-passage et dans les virages à 90 degrés.
Les virages étaient modélisés en "Polyline" ce qui est compliqué à traiter d'un point de vue logiciel. Nous avons dû re-modéliser plusieurs virages en prenant des sections de route plus simples. Ainsi, les défauts de trajectoire des véhicules sont corrigés. Le parking est opérationnel pour l'élaboration de notre scénario futur.
Semaine 3
La prochaine étape est la conception de deux programmes: un serveur UDP qui sera lancé sur le PC du Robucar et une API client, lancé sur le PC supervision. Nous commençons à nous auto-former sur la conception d'une API sous SCANeR Studio en prenant connaissance de la documentation disponible. Pour débuter, nous décidons de réaliser une API simple qui affiche la vitesse d'un véhicule de type "simple". On débute alors la conception de cette API.
En première partie de séance, nous nous entretenons avec le doctorant Vincent Coelen pour faire un point sur les API. On évoquera entre autre les points suivants:
- comprendre l'utilisation des canaux (EXPORT CHANNEL)
- mettre à disposition la documentation nécessaire pour les utiliser
- comment transformer un projet C++ en une API qui évoluera dans le logiciel
Nous nous entretenons également avec M. Merzouki pour définir plus précisément le cahier des charges. Les points abordés sont les suivants:
- Programmation d'un Serveur UDP sur l'ordinateur intégré au Robucar pour communiquer en WIFI avec une API Client
- Programmation d'une API Client à implanter sur le logiciel SCANeR du PC Supervision
- Conception d'une seconde API permettant d'envoyer des consignes de vitesse et de braquage dans la simulation
- Fusion de ces deux dernières API
Ensuite, nous commençons à prendre en main l'utilisation des sockets en C++ pour le serveur UDP et l'API Client. Nous utiliserons les sources suivantes:
Frampeip: Serveur en mode non connecté
Cours IMASC : Programmation Réseau
Linux: Tutoriel sur les Serveurs
Semaine 4
Nous commençons à nous focaliser sur le fonctionnement du Robucar. Vincent Coelen nous explique comment fonctionne la DSPACE et comment utiliser un programme MATLAB pour récupérer des données du véhicule tels que la vitesse, l'angle de braquage, la position de la boîte de vitesse etc. On découvre aussi le fonctionnement du Cockpit en utilisant une API déjà fonctionnelle permettant d'envoyer des commandes à celui-ci depuis la simulation. L'API Cockpit est implantée sur le logiciel SCANeR du PC Supervision. Nous utiliserons cette API par la suite car notre API enverra les consignes de vitesse et d'angle braquage à ModelHandler et l'API Cockpit lira ces valeurs par le biais des Export Channels sur ModelHandler.
Nous continuons la programmation du serveur UDP et de l'API Client et nous réalisons les premiers tests du serveur:
- On met le PC Supervision et le PC du Robucar sur le même réseau
- On essaie de se "pinger" l'un l'autre pour vérifier la connexion entre les deux ordinateurs: la connexion est ouverte
Problème rencontré:
Les codes du serveur et du client ne compilent pas car il manque des librairies. Nous renseignons les librairies manquantes et corrigeons les erreurs de compilation.
Semaine 5
Nous réorganisons les codes du serveur et du client avec l'aide de M. Redon. Le serveur et l'API Client ne fonctionnent actuellement pas. Afin d'accéder aux données de la DSPACE, il nous faut utiliser un Parser, programmé par un doctorant ayant travaillé sur le Robucar auparavant. Ce parser prend en paramètre les noms des variables dans le programme Simulink et nous renvoie leur nom système correspondant, exploitable en C++. Pour cela, il faut indiquer au parser le chemin (path) et le nom exact des variables dans Simulink. Dans le serveur UDP, on récupère donc grâce à la librairie Clib les valeurs de la vitesse et l'angle de braquage des roues du Robucar.
Après une série de débogages, le serveur UDP est fonctionnel. Les échanges de paquets entre les deux PC connectés se font rapidement. Grâce à un compteur dans le programme du Serveur, on constate que beaucoup de paquets sont perdus mais ceci ne devrait pas poser trop de problèmes dans la simulation, dans la mesure ou le débit d'émission de paquets est rapide.
Semaine 6
On débute la programmation de la seconde API permettant d'envoyer des données à la simulation. Pour ce faire, on doit prendre en main l'écriture sur les EXPORT CHANNELS. En effet, ils permettent d'échanger des informations entre les différentes API. Ici, on cherche à échanger des données entre notre API et l'API ModelHandler qui pilote le modèle Robucar dans la simulation. On va donc renseigner les cases mémoires de la vitesse et de l'angle de braquage des roues dans lesquelles Modelhandler lis ces informations pour les envoyer sur le modèle de la simulation.
Semaine 7
On continue et termine rapidement la programmation de l'API. On réalise les premiers tests de celle-ci dans Scaner Studio. Pour ce faire, on charge notre terrain (parking de Polytech Lille), on ajoute un scénario qui dans notre cas est l'ajout d'un véhicule de type Advanced piloté par Modelhandler. On ajoute ensuite une API en utilisant le fichier .exe généré par notre projet sur Visual Studio. Enfin, on sélectionne notre API et l'API ModelHandler dans le mode simulation.
Problèmes rencontrés:
- Problème dans les héritages des dépendances supplémentaires du projet dans Microsoft Visual Studio: on doit ajouter certaines librairies supplémentaires
- l'API bloque la simulation bien qu'elle compile correctement indépendamment de la simulation. A première vue, ce problème serait dû à une erreur de segmentation.
Semaine 8
L'API envoyant des données fixes à SCANeR Studio est fonctionnelle.
Les problèmes résolus sont :
- Le format d'envoi des consignes de vitesse et de braquage n'était pas correct (Float au lieu de Double). Cette erreur de format occasionnait une erreur de segmentation
- Il est nécessaire de démarrer le moteur en fixant la variable "IgnitionKey" à 3 ce qui correspond à moteur en marche (Engine Start)
- Il est préférable d'écrire sur la variable "TimeOfUpdate" pour "synchroniser" l'envoi de données entre ModelHandler qui fonctionne à 500Hz et notre API qui fonctionne à 100Hz
- On mettra également la boîte de vitesse à 1 (GearBox)
Les commandes envoyées sur les canaux sont :
Com_setDoubleData(CabToModelOutput,"Accelerator", OutputData.accelerator); Com_setDoubleData(CabToSteeringOutput,"SteeringWheel",OutputData.vehiculewheelangle); Com_setShortData(CabToModelOutput, "GearBoxAutoMode", 0); Com_setShortData(CabToModelOutput, "WantedGear", 1); Com_setShortData(CabToModelOutput, "IgnitionKey", 3); Com_setDoubleData(CabToModelOutput, "TimeOfUpdate",Process_GetTime());
On impose 0 sur “GearBoxAutoMode” pour gérer la boîte de vitesse manuellement.
On impose 3 sur “IgnitionKey” pour démarrer le moteur (Start Engine)
On impose 1 sur “WantedGear” pour démarrer en vitesse numéro 1
Nous commençons à fusionner l'API client et cette API.
Semaine 9
Les deux API sont fusionnées et nous commençons les tests de notre nouvelle API. Nous l'ajoutons à SCANeR et celle-ci devient rapidement fonctionnelle. Cependant, nous rencontrons des problèmes avec la connexion WIFI qui n'est pas fiable et qui coupe très souvent. En effet, nous avons dans un premier temps créé un réseau ad hoc. Ce type de réseau est facile et rapide à mettre en place mais sa fiabilité reste limitée. Il y a des pertes de données et de connexion assez fréquentes. De plus, La bande passante est limitée. Un problème subsiste donc, le temps de latence entre l'envoi des consignes et l'application de celles-ci au modèle de SCANeR Studio est très important. En d'autres mots, les déplacements du Robucar ne sont pas fiables dans la simulation. Nous avons donc poursuivi les tests en connectant le Robucar et le PC Supervision par Ethernet. La connexion est plus stable mais le cahier des charges nous impose une communication WIFI. Nous nous sommes donc procurés un routeur que nous avons configuré pour établir une connexion entre les deux PC. La connexion est alors stable et les échanges de paquets se font rapidement. On conservera donc cette configuration pour la suite des tests.
Après une nouvelle phase de tests, nous constatons que l'angle de braquage des roues dans la simulation n'est pas correct. Le Robucar fourni un angle compris entre 2242 (angle de 30° à gauche) et 3002 (angle de 30° à droite). De ce fait, le déplacement tout droit correspond à une valeur de 2622. Dans la simulation, la direction tout droit correspond à zéro. Pour tourner à gauche, on veut un angle en radian positif et pour tourner à droite un angle négatif. Dans la mesure où la variation de l’angle en fonction de la position du volant est sensible, on choisit un intervalle I ∈[2600;2670] pour aller tout droit. Le calcul de l’angle pour tourner à gauche ou à droite est réalisé selon une règle de 3. Nous avons également réajusté la vitesse du véhicule dans la simulation. En effet, la consigne de vitesse envoyée par le Robucar représente la moyenne des vitesses des roues avant et arrière. Or les roues arrière ont une vitesse plus faible que les roues avant. De ce fait, nous avons calculé un coefficient permettant d’ajuster la vitesse uniquement selon la vitesse des roues avant. Ici, ce coefficient vaut 1,34.
Semaine 10
Une fois les paramètres réajustés, les mouvements du modèle dans SCANeR sont relativement précis et on peut maintenant surveiller le véhicule lors de son déplacement selon plusieurs points de vue (Top View, Driver View etc).
Malheureusement, le cockpit de conduite n'est plus à Polytech Lille depuis plusieurs semaines et ne pouvons donc pas tester le système complet avec le Robucar, le PC supervision et le cockpit de conduite. L'API cockpit étant fonctionnelle, le système dans sa globalité devrait fonctionner sans problème.
Bilan de fin de projet
Ce projet nous a permis d'appréhender les notions de serveur et de client, jamais étudiées jusqu'ici. Ces nouvelles notions ont soulevé plusieurs problèmes tels que le débit d'émission et la fiabilité du réseau entre les deux composantes du système. Nous avons pris en main SCANeR Studio en utilisant chacun des modes pour créer une simulation complète. En parallèle, nous avons pu comprendre le fonctionnement des API ainsi que les liens internes entre celles-ci.
En utilisant un cockpit de conduite tel que celui de la salle C002 à Polytech Lille, la surveillance d’un véhicule est possible à courte distance. En effet, la connectivité actuelle ne permet pas la communication entre le cockpit (ou le PC supervision ici) et le Robucar. Par ailleurs, si on pallie à ce problème, on pourrait imaginer le guidage du véhicule dans des zones confinées où la perception d’obstacles et la détection de collision par le conducteur est difficile. On pourrait également utiliser le télémètre laser pour la détection d’obstacles et envoyer, de la même façon, les informations à l’opérateur sur le cockpit de simulation.
Rendus du projet
Rapport de projet: Fichier:-BRICOUT MARTIN- Rapport projet IMA4.pdf
