Guidage et Surveillance d'un véhicule à travers un Cockpit de conduite
Dans le cadre de la quatrième année au sein de la spécialité Informatique-Microélectronique-Automatique, nous allons réaliser un projet permettant de piloter et surveiller un véhicule autonome à travers un cockpit de conduite. Ce projet sera encadré par Rochdi MERZOUKI et Xavier REDON.
Résumé du projet:
Dans le cadre du projet InTraDE, transport autonome du fret, nous souhaitons relier le cockpit de conduite de la salle C002 à un véhicule mobile RobuCar. Pour cela, le cockpit qui fonctionne sous le simulateur de dynamique du véhicule SCANeR Studio, communiquera directement via le réseau WiFi avec un véhicule autonome Robucar. Tout d'abord, nous modéliserons le parking de Polytech Lille sur le logiciel SCANeR Studio. Ensuite, nous intégrerons à ce terrain un véhicule Robucar déjà modélisé. Nous élaborerons alors un scénario dans SCANeR mettant en scène plusieurs véhicules, pilotés automatiquement par SCANeR et le Robucar, piloté par une API (Application Programming Interface) sur le PC supervision. L'objectif de ce projet est de récupérer, par le biais d'une première API, des consignes de vitesse et d'angle de braquage des roues imposées au Robucar (par le biais d'un programme MATLAB déjà opérationnel) et de les envoyer au PC Supervision où ils seront récupérées par une seconde API. Celle-ci prendra en charge l'acheminement de ces données vers le cockpit et la simulation sur les channels adéquates pour que l'API (ModelHandler) qui contrôle le véhicule simulé prenne en compte ces consignes et les applique au modèle dynamique. De ce fait, nous verrons évoluer en temps réel le Robucar 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.
Pour aller plus loin
On pourra également télé-opérer le véhicule réel à tout moment, c'est à dire le piloter via le cockpit. La manipulation pourra éventuellement être réalisée avec deux Robucars.
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.
Définition 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, piéton). Il permet la représentation d'un environnement, modélisé en 3D par 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 (Application Programming Interface) dans SCANeR Studio:
- automatiquement par la simulation : API TRAFFIC. C'est le cas des véhicules de type simples.
- à 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éhicule de type Advanced.
Pour réaliser une simulation, il faut un terrain et un scenario. C'est dans le mode scenario que nous choisissons les véhicules à mettre en place dans la simulation. Ici, nous modéliserons le Parking de Polytech Lille puis nous y intégrerons le Robucar (de type véhicule "Advanced") et éventuellement des véhicules simples. Nous choisissons également 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 précisément afin que ModelHandler puissent les 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 avants 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. 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 correspondant à celui sur MATLAB. Une interface apparaît et nous pouvons alors piloter le véhicule. Lors de la conduite, des valeurs de consignes pour la vitesse moyenne et l’angle de braquage des roues sont donc récupérées dans l’API Serveur grâce à la bibliothèque « clib32 ». Sur le PC supervision, l'API Client se connecte au serveur et reçoit alors des paquets contenant une consigne 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.
Semaine 2
Pendant cette séance, nous avons finalisé la conception du parking sur SCANeR Studio et avons débuté l'élaboration d'un scénario mettant en scène un Robucar qui est de type "vehicle Advanced" et plusieurs véhicules de type "vehicle simple" qui seront pilotés automatiquement par le logiciel. Le Robucar est piloté par l'API ModelHandler et nous pouvons donc dès à présent tester la fonctionnalité de notre terrain.
Pendant cette séance, nous avons finalisé la conception du parking sur SCANeR Studio et avons débuté l'élaboration d'un scénario mettant en scène, dans un premier temps, uniquement des véhicules de type "vehicle simple". Ces véhicules sont pilotés automatiquement par le logiciel, ce qui nous permet de nous concentrer sur notre terrain. Nous pouvons ainsi dès à présent tester sa fonctionnalité.
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 API: un serveur UDP qui sera lancé sur la Robucar et un client, lancé sur le PC de supervision. Nous commençons à nous auto-former sur la conception d'une API sous SCANeR Studio en prenant connaissance de la documentation disponible. On décide 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 nous explique comment marche 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 au cockpit depuis la simulation. Cette API est implantée sur le logiciel SCANeR du PC Supervision. Nous continuons la programmation du serveur UDP de l'API Client.
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
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 fonctionne 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.
Semaine 6
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
Semaine 7
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 cette 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 8
On continue la programmation de l'API elle est terminée rapidement. On réalise les premiers tests de l'API 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.
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
Semaine 9
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)
- 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)
Nous commençons à fusionner l'API client et cette API.
Semaine 10
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 sur la simulation. Nous avons donc poursuivi les tests en connectant le Robucar et le PC Supervision par Ethernet. Cependant, le cahier des charges nous impose une communication WIFI. Nous nous sommes procuré un routeur que nous avons configuré pour établir une connexion entre les deux appareils. Après une nouvelle phase de tests, nous constatons que l'angle de braquage des roues dans la simulation n'est pas correct. On multipliera la consigne reçue par un coefficient pour ajuster la valeur car l'angle de consigne doit être en radian alors que le cockpit envoie un entier autour de 2600. Ces réglages, nous obtenons un résultats satisfaisant en terme de rapidité de réponse de la simulation par rapport au véhicule réel. Par manque de temps, le parking de Polytech Lille utilisé pour jouer la simulation restera d'une apparence des plus basiques.
