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 ou être gérée par une classe différente.

Le schéma suivant permet de mieux comprendre le fonctionnement de ce protocole. Les différents services presents sur le robot sont listés par le service Directory, puis une fois les services connus on peut alors en interroger un en particulier. Une commande Get permet de récupérer ses propriétés puis avec un Insert dans le service Notification, on peut obtenir son état de façon périodique. On peut enfin adresser aussi des commandes, par le biais de notifications entrantes (pour le serveur) directement envoyés sur le service désiré (ici le service CAR).

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)

GPS

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

Semaine 15 (11/01/2016)

GPS

Nous avons modifié le programme Simulink afin de pouvoir récupérer les données GPS à travers le port RS232 de la dSPACE. Un parser a été réalisé afin de pouvoir interpréter les différentes trames GPS (GPA et ZDA). Après quelques tests, nous avons été heurtés à différents problèmes notamment le fait qu'il faille travailler au plus bas niveau possible ie récupérer les octets un à un puis de convertir les données grâce au tableau de correspondance ASCII. Nous avons réussi à récupérer la trame GPS, il reste juste à réaliser quelques corrections dans le parser.

Semaine 16 (18/01/2016)

GPS

Après avoir modifier les paramètres de différents blocs Simulink, nous sommes arrivés à recevoir les données GPS trame par trame. Auparavant, on les recevait octet par octet et du coup nous étions incapables de récupérer une trame complète ou alors il aurait fallu augmenter la fréquence de fonctionnement de la dSpace. Avant de passer la trame GPS au parser, nous utilisons un bloc permettant de vérifier si la trame ne comporte pas d'erreur car il y a régulièrement des erreurs de transmission. Au terme de la semaine, nous sommes parvenus à obtenir notre position en latitude, longitude ainsi qu'en coordonnées UTM avec seulement une différence de quelques décimètres par rapport à la réalité.

Odométrie

Nous avons récupéré les vitesses des roues du train avant et du train arrière assez rapidement car une bonne partie du codage était d'ores et déjà réalisé. En ce qui concerne les angles de braquage du train avant et du train arrière, il a fallu rechercher dans la documentation technique du robucar le type de codeur permettant de connaître ces angles en question. Les codeurs du train avant et arrière sont des codeurs 13 bits, avec un simple produit en croix nous avons donc pu déterminer les angles de braquage et quelques tests ont permis de valider les valeurs obtenues.

Localisation

Comme il avait déjà été précisé précédemment, nous allons utiliser un filtre de Kalman étendu pour fusionner les données odométriques et GPS. Cependant, nous n'allons pas réutiliser le modèle bicyclette avec uniquement le train avant directionnel qui avait été codé auparavant. Nous allons réalisé un modèle bicyclette avec les deux trains directionnels. Ainsi, quel que soit le type de fonctionnement du robucar (train avant seulement, train arrière seulement, multidirectionnel, parking), notre modèle fonctionnera.

PURE

Le développement du serveur Pure à repris. Il s'articulera autour d'une classe de gestion du protocole UDP, (principalement les envois et receptions) ainsi qu'une classe Service qui servira de classe mère à tous les autres services qui devront être implémentés par la suite. Ainsi, l'ajout de fonctionnalités dans le serveur sera grandement simplifié puisqu'il suffira de developer la classe souhaitée en redéfinissant uniquement les fonctions correspondantes aux actions du service. Si une fonction n'as pas été re-définie mais ce retrouve appelée, on aura alors le code de la classe mère qui effectuera un retour à l'utilisateur.

La classe de gestion udp fera aussi un premier tri sur les paquets entrant, en éliminant les paquets ayant trop peu de données ou ceux ne respectant pas le format. Ensuite, elle appellera le code correspondant à l'action du service concerné. Pour cela, il lui faut un accès à l'ensemble des services instanciés par le serveur.

Les services effectuent donc les actions via les appels du gestionnaires udp, puis envoient les réponses tels que codifié par le protocol PURE. Afin de faire les envois, les services doivent faire un appel à la fonction send(&buffer) du gestionnaire UDP. Petite difficultée donc, les classes Service et udpManager doivent être "entreliés". (Il aurait pu être envisageable de passer lors de l'appel un buffer de sortie lors de l'appel à la fonction du service, mais le comportement (presence de réponse) n'est pas forcement toujours le même suivant les services et actions. De plus pour les notifications sortantes (périodiques), il faut là aussi pouvoir avoir accès au send, et cet appel n'est pas effectué par le gestionnaire UDP mais par le service approprié : Notification.

Semaine 17 (25/01/2016)

Localisation

Afin de déterminer notre modèle cinématique, nous utilisons les équations de roulement et de glissement dues aux contraintes des roues. Nous avons commencé à utiliser deux équations de roulement (train avant et arrière) et une équation de glissement (train avant) car il était aisé de réaliser l'inversion d'une matrice carrée (pour plus de détails voir les calculs qui seront fournis prochainement). Cependant, nous avions une singularité qui provoquait des résultats impossibles dès le moment où les roues arrières étaient alignées et droites. Nous avons donc utilisé la méthode des moindres carrés afin de pouvoir utiliser les deux équations de roulement et les deux équations de glissement. D'après la théorie, nous ne devrions plus avoir de singularité donc notre modèle cinématique devrait fonctionner tous le temps. Cependant le filtre ne converge toujours pas, il faudra donc peaufiner les réglages des matrices P et Q.

PURE

Développement de la classe "udpManager" tel que décrite la semaine passée, avec outils de gestion de la socket et des adresses via winsock2. En effet le développement à lieu sous windows puisque le code devra être exécuté en parallèle de ceux gérant la dSpace, afin d'aller modifier certaines variables utilisées pour controller le robuCAR. Cette classe contient donc tout les éléments nécessaire à la gestion UDP, ainsi qu'un shared pointer d'un vecteur de Service*. Cet element sera initialisé dans le main (rempli avec des services spécifiques et non la classe mère Service) puis passé à notre classe. Cela lui permettra d’accéder aux fonctions standards de chacun de nos services, notamment lors de la reception d'un nouveau paquet, la fonction receive effectuera un dépilage du buffer reçu et pourra donc directement appeler l'action du service visé.

La classe mère Service possède quand à elle des éléments de description du service (type, numéro d'instance et description texte) qui seront instancié lors de la construction de l'objet par la classe fille. Elle possède aussi un pointeur sur la classe de communication UDP, ainsi qu'un pointeur sur l'objet ClibTk, instancié dans le main et qui permettra d’accéder aux données de la dSpace. Cette classe permettra de servir de base au service codés par la suite. Elle possède aussi une definition pour chacune des actions et notification (entrantes/sortantes) possibles par le protocole pure. Ces fonctions sont définies de façon virtuelles et retourneront une sortie textuelle si jamais elle sont appelées (donc non re-déclarée par la classe fille).

Les classes filles restent à créer mais respecteront donc ce schéma :

                 Services                            : Classe mère
     _______________|______________
     |            |       |       |
 Directory  Notification Car Localization            : Classe fille

Semaine 18 (01/02/2016)

Localisation

Nous avons réalisé des simulations afin de valider notre modèle par la théorie. Nous avons ensuite exporté les données odométriques et GPS lors des tests réalisés sur la piste d'essai afin de pouvoir par la suite réaliser des simulations sous Matlab-Simulink. Ainsi, nous avons pu mieux régler notre filtre de Kalman. Nous avons ensuite édité un fichier .kml pour vérifier sur Google Earth si les données obtenues correspondaient bien à la suite. Ensuite, nous avons vérifié si notre filtre "filtrait" correctement, c'est-à-dire qu'il ne se contentait pas juste de suivre les données GPS mais qu'il fusionnait celles-ci avec les données odométriques pour obtenir une trajectoire non saccadée.

PURE

Les services fils ont été développés. Les services Directory et Notifications sont un peu particuliers car il doivent avoir un accès sur les autres services existants. Ils possèdent donc tous deux un même accès au vecteur de Service* précédemment évoqué. Ainsi, le Directory peux donc aller interroger chaque service pour obtenir ses infos et les redonner, et le service notification peut aussi lancer les outbound notifs de chacun des autres services. Afin de gérer les abonnement aux notifications, une structure est créée afin de retenir le numéro d'instance et la période souhaitée. Celle ci est définie sous le nom de NotificationEntry dans le protocole PURE, et est stocké dans la classe sous forme d'un set. Ainsi des operations d'insert ou d'erase sur ce set pourront être effectué après recherche sur les éléments lors des différentes operations.

Le service Car et Localization quand à eux sont un peu plus simples. Ils ne contiennent que des structures permettant de stocker les informations qui leurs sont propres (Propriétés, état, commande pour le service Car) et les re-définitions de leurs actions. Ces fonctions utilisent alors l'objet ClibTk évoqué la semaine passé afin d'aller lire et écrire sur des variables utilisées par la dSpace.

Semaine 19 (08/02/2016)

PURE

Afin d’améliorer la gestion reception/emission, un thread afin d'assurer l'appel périodique à la fonction de gestion des notifications sortantes est mis en place. L'utilisation de thread sous Visual c++ 2010 requiert l'utilisation des outils propres à Microsoft : la fonction CreateThread stockée dans un HANDLE, avec un DWORD pour l'id du tread. De même, les objets mutex ne sont pas disponible, il faut passer par des CRITICAL_SECTION afin de verrouiller et de mettre en attente l’accès a certaines portions de code. Après quelques ajustement sur des formats de variables dans les buffers des messages sortants, des tests concluants ont eu lieux en localhost avec des clients PURE windows développés auparavant. Leur implementation impose d'ouvrir un client par service voulu. Le programme de test ouvre donc un client Directory, un client Car et un client Localization. Un affichage est effectué avec les données reçues, puis boucle permet de recevoir les notifications et d'en envoyer afin de simuler une boucle de régulation.

Schema UML des différentes classes

Test Serveur-Client en local