Wiki d'activités IMA - Contributions de l’utilisateur [fr]

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-02-23T14:55:11Z

Csmagghe : /* Semaine 21 (22/02/2016) */

==Cahier des charges==
===Présentation générale du projet===
[[Fichier:P25_2015_RobuCar_det.png|150px|thumb|right|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 [http://www.intrade-nwe.eu/fr/ 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++)
<br>

==Étapes du projet==

<b>Partie 1 : Adaptation des codes existants</b>
<br>
*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)
<br>
<b>Partie 2 : Automatisation du déplacement du véhicule dans Lille 1</b>
<br>
*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
<br>
<b>Partie 3 : Interaction homme-machine</b>
<br>
*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
<br>

==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)===
[[Fichier:P25_2015_first_schem.png|400px|thumb|right|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 :<br> 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. <div style="clear: both"></div>

===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)===
[[Fichier:P25_2015_ConsigneTractionFreinage.PNG|400px|thumb|right|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é.
<div style="clear: both"></div>

===Semaine 6 (26/10/2015)===
[[Fichier:P25_2015Pure_protocol.png|thumbs|400px|right]]
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).

<div style="clear: both"></div>

===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.
[[Fichier:architecture_restante.png|center]]
=====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.<br>
=====Laser=====
[[Fichier:laser_sick.jpg|thumb|200px|left|Laser Sick]]
[[Fichier:Capture_rviz.png|thumb|200px|right|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.<br>
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.<br>
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. <div style="clear: both"></div>

===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 [https://www.youtube.com/watch?v=9DunFgo-5iY 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.<br/>
<center>[[Fichier:Osmcampuslille1.png|400px]] [[Fichier:Campusrvizosm2.png|420px]]</center>
<div style="clear: both"></div>

===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 ([https://en.wikipedia.org/wiki/Universally_unique_identifier 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 [https://fr.wikipedia.org/wiki/Transverse_Universelle_de_Mercator 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'[https://fr.wikipedia.org/wiki/Algorithme_A* 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.
<center>[[Fichier:Osmrondpoint.png|650px]] [[Fichier:grapherondpoint.png|80px]] [[Fichier:Rvizrondpoint.png|300px]] </center>

===Semaine 12 (07/12/2015)===
=====Path finding=====
[[Fichier:cheminpolytechgalois.png|right|300px]]
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.
<div style="clear: both"></div>

===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
[[Fichier:Capture_GPS_parking.PNG|thumb|right]]
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
<div style="clear: both"></div>

===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. Ci-dessous nous pouvons observer une schématisation du modèle utilisé pour le robuCAR.
[[Fichier:ModelisationRobucar.png|center]]

=====PURE=====
Le développement du serveur Pure a repris.
Il s'articulera autour d'une classe de gestion du protocole UDP, (principalement les envois et réceptions) 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 développer la classe souhaitée en redéfinissant uniquement les fonctions correspondantes aux actions du service.
Si une fonction n'a pas été redéfinie mais se retrouve appelée, on aura alors le code de la classe mère qui effectuera un retour a 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 gestionnaire UDP, puis envoient les réponses tels qu'elles sont codifiées par le protocole PURE. Afin de faire les envois, les services doivent faire un appel à la fonction send(&buffer) du gestionnaire UDP. Petite difficulté donc, les classes Service et udpManager doivent être "entrelacées". (Il aurait pu être envisageable de passer un buffer de sortie lors de l'appel à la fonction du service, mais le comportement (présence 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 a 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 contrôler le robuCAR. Cette classe contient donc tous les éléments nécessaires à la gestion UDP, ainsi qu'un shared pointer d'un vecteur de Service*. Cet élément sera initialisé dans le programme principal (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 réception 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és 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 aux services codés par la suite. Elle possède aussi une définition pour chacune des actions et notifications (entrantes/sortantes) possibles par le protocole pure. Ces fonctions sont définies de façon virtuelle et retourneront une sortie textuelle si jamais elle sont appelées (donc non redéclarée par la classe fille).

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

Service : 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 Notification 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 peut 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 abonnements 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ée dans la classe sous forme d'un set. Ainsi des opérations d'insert ou d'erase sur ce set pourront être effectué après recherche via un itérateur sur les éléments lors des différentes opérations.

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ée afin d'aller lire et écrire sur des variables utilisées par la dSpace.

===Semaine 19 (08/02/2016)===
=====Localisation=====
Afin de pouvoir observer le modèle du robuCAR et réaliser des tests en simulation, nous avons inversé notre modèle. Ainsi on exprime les angles et les vitesses des roues en fonction des vitesses suivant x, y et theta. Les tests ont confirmé la validité de notre modèle inverse. Nous pouvons voir ci-dessous que les écarts en position entre le modèle et le modèle faisant suite au modèle inverse sont très faibles (jamais supérieur à 1 cm).
[[Fichier:CaptureEcartSystemeInverse.png|center]]
=====PURE=====
Afin d’améliorer la gestion réception/émission, un thread est mis en place pour assurer l'appel périodique à la fonction de gestion des notifications sortantes.
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 disponibles, il faut passer par des CRITICAL_SECTION afin de verrouiller et de mettre en attente l’accès à certaines portions de code.
Après quelques ajustements sur des formats de variables dans les buffers des messages sortants, des tests concluants ont eu lieu sur le serveur local avec des clients PURE windows développés auparavant.
Leur implémentation impose d'ouvrir un client par service voulu. Le programme de test ouvre donc un client Directory, un client Car et un client Localization. Le service Notification est aussi testé puisqu'un abonnement est automatiquement effectué par le client Car et le client Localization. Un affichage est effectué avec les données reçues, puis une boucle permet de recevoir les notifications et d'en envoyer afin de simuler une boucle de régulation.
{|align=center
|[[Fichier:P25_2015_UMLServeur_PURE.PNG|380px|thumb|Schema UML des différentes classes]]
|[[Fichier:P25_2015capture_serveur_PURE.PNG|700px|thumb|Test Serveur-Client en local]]
|}

=====Suivi de trajectoire=====

Afin de faciliter les test, des nœuds ROS de développement ont été réalisés. Ils permettent de simuler le comportement physique du robuCAR ou d'un autre véhicule suite à l'envoi de commande, et publie des informations de localisation.
Ainsi, le développement du suivi de chemin est possible sans risquer de détériorer le véhicule. Celui-ci symbolise le véhicule avec une flèche sur la carte déjà utilisée lors de la recherche de chemin.
Plusieurs types d'algorithmes de suivi de trajectoire ont été essayés, puis une adaptation de plusieurs méthodes a été choisi. La position de la flèche est actualisée au fur et à mesure de la progression (virtuelle) du véhicule, et nous a permis d’identifier phénomènes d'oscillation et de lenteur de convergence lors de certaines régulations.

===Semaine 20 (15/02/2016)===
Après avoir intégré la librairie Clib permettant de modifier les valeurs de la dSpace dans le code du serveur PURE, des tests ont été tentés sur le PC du robuCAR. Malheureusement, le développement ayant été effectué sous Visual C++ 2010 (une version présente sur le pc robuCAR, mais non utilisé par les projets précédemment réalisés), nous avons rencontré une grande liste de soucis avec la librairie Clib.
Celle ci était en effet livrée pré-compilée et sans les sources. Il y a donc incompatibilité avec les librairies standards de Visual c++ 2010 et celles utilisées dans Clib.
Il a donc fallu modifier le projet contenant le serveur PURE afin de le faire passer sous visual c++ 2005. Lors de ce passage, l’installation et l’utilisation la librairie boost a été nécessaire, car les objets de type shared pointers ne sont pas disponibles avec Vc++2005. De plus l’initialisation de l’objet critical section a aussi du être modifiée.
Une fois le programme adapté, une correspondance entre les valeurs à lire et écrire par le serveur et les emplacements mémoire de la dSpace a été effectuée grâce au fichier de configuration de la bibliothèque clibClient, développé auparavant.
Un autre souci est alors apparu : la bibliothèque Clib ne fonctionne pas lors d’un appel via le thread. Les outils de débogage n’ont pas indiqué de différences des données lors de l’appel aux fonctions, mais le problème reste entier.
Le fonctionnement du serveur est donc modifié afin de n’avoir qu’une boucle principale avec la réception de paquets (avec timeOut) puis l’appel aux notifications sortantes.

Le nœud du suivi de trajectoire a lui été modifié afin d’être compatible avec les données fournies par le nœud PURE-ROS.

Et le 17/02, dans l’après-midi, VICTOIRE. La communication est fonctionnelle, et un test de suivi de chemin a été effectué avec succès, sur le parking de Polytech.

Par la suite, des améliorations sur le simulateur de suivi de trajectoire ont été effectuées. Celui-ci est maintenant capable de recevoir des ordres manuels, puis de reprendre un suivi de trajectoire normal.
Sur le serveur PURE, le timeOut appliqué directement sur la socket winsock2 ne donnait pas satisfaction, car il n’était pas capable de descendre en dessous de 500 ms environ. Un select a donc été mis en place afin d’améliorer les performances. Le select permet en effet d’aller scruter des modifications sur la socket, et donc de gérer plus finement le timeOut.

===Semaine 21 (22/02/2016)===
Nous avons tapé le rapport de fin de projet et préparé le diaporama qui servira de support de présentation pour la soutenance. Nous avons réalisé une courte vidéo "faite maison" pour mettre en avant le fait que toutes les éléments fonctionnent de concert pour créer un véhicule autonome. Elle est disponible à ce [https://youtu.be/b7GYsDRwY6g lien]

== Fichiers Rendus ==

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-02-23T13:42:57Z

Csmagghe : /* Localisation */

Fichier:ModelisationRobucar.png

2016-02-23T13:39:34Z

Csmagghe :

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-02-23T13:36:02Z

Csmagghe : /* Semaine 19 (08/02/2016) */

==Cahier des charges==
===Présentation générale du projet===
[[Fichier:P25_2015_RobuCar_det.png|150px|thumb|right|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 [http://www.intrade-nwe.eu/fr/ 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++)
<br>

==Étapes du projet==

<b>Partie 1 : Adaptation des codes existants</b>
<br>
*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)
<br>
<b>Partie 2 : Automatisation du déplacement du véhicule dans Lille 1</b>
<br>
*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
<br>
<b>Partie 3 : Interaction homme-machine</b>
<br>
*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
<br>

==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)===
[[Fichier:P25_2015_first_schem.png|400px|thumb|right|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 :<br> 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. <div style="clear: both"></div>

===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)===
[[Fichier:P25_2015_ConsigneTractionFreinage.PNG|400px|thumb|right|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é.
<div style="clear: both"></div>

===Semaine 6 (26/10/2015)===
[[Fichier:P25_2015Pure_protocol.png|thumbs|400px|right]]
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).

<div style="clear: both"></div>

===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.
[[Fichier:architecture_restante.png|center]]
=====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.<br>
=====Laser=====
[[Fichier:laser_sick.jpg|thumb|200px|left|Laser Sick]]
[[Fichier:Capture_rviz.png|thumb|200px|right|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.<br>
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.<br>
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. <div style="clear: both"></div>

===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 [https://www.youtube.com/watch?v=9DunFgo-5iY 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.<br/>
<center>[[Fichier:Osmcampuslille1.png|400px]] [[Fichier:Campusrvizosm2.png|420px]]</center>
<div style="clear: both"></div>

===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 ([https://en.wikipedia.org/wiki/Universally_unique_identifier 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 [https://fr.wikipedia.org/wiki/Transverse_Universelle_de_Mercator 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'[https://fr.wikipedia.org/wiki/Algorithme_A* 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.
<center>[[Fichier:Osmrondpoint.png|650px]] [[Fichier:grapherondpoint.png|80px]] [[Fichier:Rvizrondpoint.png|300px]] </center>

===Semaine 12 (07/12/2015)===
=====Path finding=====
[[Fichier:cheminpolytechgalois.png|right|300px]]
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.
<div style="clear: both"></div>

===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
[[Fichier:Capture_GPS_parking.PNG|thumb|right]]
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
<div style="clear: both"></div>

===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 a repris.
Il s'articulera autour d'une classe de gestion du protocole UDP, (principalement les envois et réceptions) 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 développer la classe souhaitée en redéfinissant uniquement les fonctions correspondantes aux actions du service.
Si une fonction n'a pas été redéfinie mais se retrouve appelée, on aura alors le code de la classe mère qui effectuera un retour a 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 gestionnaire UDP, puis envoient les réponses tels qu'elles sont codifiées par le protocole PURE. Afin de faire les envois, les services doivent faire un appel à la fonction send(&buffer) du gestionnaire UDP. Petite difficulté donc, les classes Service et udpManager doivent être "entrelacées". (Il aurait pu être envisageable de passer un buffer de sortie lors de l'appel à la fonction du service, mais le comportement (présence 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 a 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 contrôler le robuCAR. Cette classe contient donc tous les éléments nécessaires à la gestion UDP, ainsi qu'un shared pointer d'un vecteur de Service*. Cet élément sera initialisé dans le programme principal (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 réception 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és 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 aux services codés par la suite. Elle possède aussi une définition pour chacune des actions et notifications (entrantes/sortantes) possibles par le protocole pure. Ces fonctions sont définies de façon virtuelle et retourneront une sortie textuelle si jamais elle sont appelées (donc non redéclarée par la classe fille).

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

Service : 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 Notification 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 peut 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 abonnements 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ée dans la classe sous forme d'un set. Ainsi des opérations d'insert ou d'erase sur ce set pourront être effectué après recherche via un itérateur sur les éléments lors des différentes opérations.

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ée afin d'aller lire et écrire sur des variables utilisées par la dSpace.

===Semaine 19 (08/02/2016)===
=====Localisation=====
Afin de pouvoir observer le modèle du robuCAR et réaliser des tests en simulation, nous avons inversé notre modèle. Ainsi on exprime les angles et les vitesses des roues en fonction des vitesses suivant x, y et theta. Les tests ont confirmé la validité de notre modèle inverse. Nous pouvons voir ci-dessous que les écarts en position entre le modèle et le modèle faisant suite au modèle inverse sont très faibles (jamais supérieur à 1 cm).
[[Fichier:CaptureEcartSystemeInverse.png|center]]
=====PURE=====
Afin d’améliorer la gestion réception/émission, un thread est mis en place pour assurer l'appel périodique à la fonction de gestion des notifications sortantes.
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 disponibles, il faut passer par des CRITICAL_SECTION afin de verrouiller et de mettre en attente l’accès à certaines portions de code.
Après quelques ajustements sur des formats de variables dans les buffers des messages sortants, des tests concluants ont eu lieu sur le serveur local avec des clients PURE windows développés auparavant.
Leur implémentation impose d'ouvrir un client par service voulu. Le programme de test ouvre donc un client Directory, un client Car et un client Localization. Le service Notification est aussi testé puisqu'un abonnement est automatiquement effectué par le client Car et le client Localization. Un affichage est effectué avec les données reçues, puis une boucle permet de recevoir les notifications et d'en envoyer afin de simuler une boucle de régulation.
{|align=center
|[[Fichier:P25_2015_UMLServeur_PURE.PNG|380px|thumb|Schema UML des différentes classes]]
|[[Fichier:P25_2015capture_serveur_PURE.PNG|700px|thumb|Test Serveur-Client en local]]
|}

=====Suivi de trajectoire=====

Afin de faciliter les test, des nœuds ROS de développement ont été réalisés. Ils permettent de simuler le comportement physique du robuCAR ou d'un autre véhicule suite à l'envoi de commande, et publie des informations de localisation.
Ainsi, le développement du suivi de chemin est possible sans risquer de détériorer le véhicule. Celui-ci symbolise le véhicule avec une flèche sur la carte déjà utilisée lors de la recherche de chemin.
Plusieurs types d'algorithmes de suivi de trajectoire ont été essayés, puis une adaptation de plusieurs méthodes a été choisi. La position de la flèche est actualisée au fur et à mesure de la progression (virtuelle) du véhicule, et nous a permis d’identifier phénomènes d'oscillation et de lenteur de convergence lors de certaines régulations.

===Semaine 20 (15/02/2016)===
Après avoir intégré la librairie Clib permettant de modifier les valeurs de la dSpace dans le code du serveur PURE, des tests ont été tentés sur le PC du robuCAR. Malheureusement, le développement ayant été effectué sous Visual C++ 2010 (une version présente sur le pc robuCAR, mais non utilisé par les projets précédemment réalisés), nous avons rencontré une grande liste de soucis avec la librairie Clib.
Celle ci était en effet livrée pré-compilée et sans les sources. Il y a donc incompatibilité avec les librairies standards de Visual c++ 2010 et celles utilisées dans Clib.
Il a donc fallu modifier le projet contenant le serveur PURE afin de le faire passer sous visual c++ 2005. Lors de ce passage, l’installation et l’utilisation la librairie boost a été nécessaire, car les objets de type shared pointers ne sont pas disponibles avec Vc++2005. De plus l’initialisation de l’objet critical section a aussi du être modifiée.
Une fois le programme adapté, une correspondance entre les valeurs à lire et écrire par le serveur et les emplacements mémoire de la dSpace a été effectuée grâce au fichier de configuration de la bibliothèque clibClient, développé auparavant.
Un autre souci est alors apparu : la bibliothèque Clib ne fonctionne pas lors d’un appel via le thread. Les outils de débogage n’ont pas indiqué de différences des données lors de l’appel aux fonctions, mais le problème reste entier.
Le fonctionnement du serveur est donc modifié afin de n’avoir qu’une boucle principale avec la réception de paquets (avec timeOut) puis l’appel aux notifications sortantes.

Le nœud du suivi de trajectoire a lui été modifié afin d’être compatible avec les données fournies par le nœud PURE-ROS.

Et le 17/02, dans l’après-midi, VICTOIRE. La communication est fonctionnelle, et un test de suivi de chemin a été effectué avec succès, sur le parking de Polytech.

Par la suite, des améliorations sur le simulateur de suivi de trajectoire ont été effectuées. Celui-ci est maintenant capable de recevoir des ordres manuels, puis de reprendre un suivi de trajectoire normal.
Sur le serveur PURE, le timeOut appliqué directement sur la socket winsock2 ne donnait pas satisfaction, car il n’était pas capable de descendre en dessous de 500 ms environ. Un select a donc été mis en place afin d’améliorer les performances. Le select permet en effet d’aller scruter des modifications sur la socket, et donc de gérer plus finement le timeOut.

===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==

Fichier:CaptureEcartSystemeInverse.png

2016-02-23T13:35:07Z

Csmagghe :

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-02-21T17:06:07Z

Csmagghe : /* Semaine 20 (15/02/2016) */

==Cahier des charges==
===Présentation générale du projet===
[[Fichier:P25_2015_RobuCar_det.png|150px|thumb|right|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 [http://www.intrade-nwe.eu/fr/ 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++)
<br>

==Étapes du projet==

<b>Partie 1 : Adaptation des codes existants</b>
<br>
*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)
<br>
<b>Partie 2 : Automatisation du déplacement du véhicule dans Lille 1</b>
<br>
*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
<br>
<b>Partie 3 : Interaction homme-machine</b>
<br>
*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
<br>

==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)===
[[Fichier:P25_2015_first_schem.png|400px|thumb|right|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 :<br> 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. <div style="clear: both"></div>

===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)===
[[Fichier:P25_2015_ConsigneTractionFreinage.PNG|400px|thumb|right|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é.
<div style="clear: both"></div>

===Semaine 6 (26/10/2015)===
[[Fichier:P25_2015Pure_protocol.png|thumbs|400px|right]]
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).

<div style="clear: both"></div>

===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.
[[Fichier:architecture_restante.png|center]]
=====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.<br>
=====Laser=====
[[Fichier:laser_sick.jpg|thumb|200px|left|Laser Sick]]
[[Fichier:Capture_rviz.png|thumb|200px|right|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.<br>
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.<br>
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. <div style="clear: both"></div>

===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 [https://www.youtube.com/watch?v=9DunFgo-5iY 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.<br/>
<center>[[Fichier:Osmcampuslille1.png|400px]] [[Fichier:Campusrvizosm2.png|420px]]</center>
<div style="clear: both"></div>

===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 ([https://en.wikipedia.org/wiki/Universally_unique_identifier 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 [https://fr.wikipedia.org/wiki/Transverse_Universelle_de_Mercator 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'[https://fr.wikipedia.org/wiki/Algorithme_A* 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.
<center>[[Fichier:Osmrondpoint.png|650px]] [[Fichier:grapherondpoint.png|80px]] [[Fichier:Rvizrondpoint.png|300px]] </center>

===Semaine 12 (07/12/2015)===
=====Path finding=====
[[Fichier:cheminpolytechgalois.png|right|300px]]
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.
<div style="clear: both"></div>

===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
[[Fichier:Capture_GPS_parking.PNG|thumb|right]]
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
<div style="clear: both"></div>

===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 a repris.
Il s'articulera autour d'une classe de gestion du protocole UDP, (principalement les envois et réceptions) 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 développer la classe souhaitée en redéfinissant uniquement les fonctions correspondantes aux actions du service.
Si une fonction n'a pas été redéfinie mais se retrouve appelée, on aura alors le code de la classe mère qui effectuera un retour a 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 gestionnaire UDP, puis envoient les réponses tels qu'elles sont codifiées par le protocole PURE. Afin de faire les envois, les services doivent faire un appel à la fonction send(&buffer) du gestionnaire UDP. Petite difficulté donc, les classes Service et udpManager doivent être "entrelacées". (Il aurait pu être envisageable de passer un buffer de sortie lors de l'appel à la fonction du service, mais le comportement (présence 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 a 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 contrôler le robuCAR. Cette classe contient donc tous les éléments nécessaires à la gestion UDP, ainsi qu'un shared pointer d'un vecteur de Service*. Cet élément sera initialisé dans le programme principal (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 réception 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és 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 aux services codés par la suite. Elle possède aussi une définition pour chacune des actions et notifications (entrantes/sortantes) possibles par le protocole pure. Ces fonctions sont définies de façon virtuelle et retourneront une sortie textuelle si jamais elle sont appelées (donc non redéclarée par la classe fille).

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

Service : 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 Notification 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 peut 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 abonnements 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ée dans la classe sous forme d'un set. Ainsi des opérations d'insert ou d'erase sur ce set pourront être effectué après recherche via un itérateur sur les éléments lors des différentes opérations.

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ée 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 réception/émission, un thread est mis en place pour assurer l'appel périodique à la fonction de gestion des notifications sortantes.
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 disponibles, il faut passer par des CRITICAL_SECTION afin de verrouiller et de mettre en attente l’accès à certaines portions de code.
Après quelques ajustements sur des formats de variables dans les buffers des messages sortants, des tests concluants ont eu lieu sur le serveur local avec des clients PURE windows développés auparavant.
Leur implémentation impose d'ouvrir un client par service voulu. Le programme de test ouvre donc un client Directory, un client Car et un client Localization. Le service Notification est aussi testé puisqu'un abonnement est automatiquement effectué par le client Car et le client Localization. Un affichage est effectué avec les données reçues, puis une boucle permet de recevoir les notifications et d'en envoyer afin de simuler une boucle de régulation.
{|align=center
|[[Fichier:P25_2015_UMLServeur_PURE.PNG|380px|thumb|Schema UML des différentes classes]]
|[[Fichier:P25_2015capture_serveur_PURE.PNG|700px|thumb|Test Serveur-Client en local]]
|}

=====Suivi de trajectoire=====

Afin de faciliter les test, des nœuds ROS de développement ont été réalisés. Ils permettent de simuler le comportement physique du robuCAR ou d'un autre véhicule suite à l'envoi de commande, et publie des informations de localisation.
Ainsi, le développement du suivi de chemin est possible sans risquer de détériorer le véhicule. Celui-ci symbolise le véhicule avec une flèche sur la carte déjà utilisée lors de la recherche de chemin.
Plusieurs types d'algorithmes de suivi de trajectoire ont été essayés, puis une adaptation de plusieurs méthodes a été choisi. La position de la flèche est actualisée au fur et à mesure de la progression (virtuelle) du véhicule, et nous a permis d’identifier phénomènes d'oscillation et de lenteur de convergence lors de certaines régulations.

===Semaine 20 (15/02/2016)===
Après avoir intégré la librairie Clib permettant de modifier les valeurs de la dSpace dans le code du serveur PURE, des tests ont été tentés sur le PC du robuCAR. Malheureusement, le développement ayant été effectué sous Visual C++ 2010 (une version présente sur le pc robuCAR, mais non utilisé par les projets précédemment réalisés), nous avons rencontré une grande liste de soucis avec la librairie Clib.
Celle ci était en effet livrée pré-compilée et sans les sources. Il y a donc incompatibilité avec les librairies standards de Visual c++ 2010 et celles utilisées dans Clib.
Il a donc fallu modifier le projet contenant le serveur PURE afin de le faire passer sous visual c++ 2005. Lors de ce passage, l'installation et l'utilisation la librairie boost a été nécessaire, car les objets de type shared pointers ne sont pas disponibles avec Vc++2005. De plus l'initialisation de l'objet critical section a aussi du être modifiée.
Une fois le programme adapté, une correspondance entre les valeurs à lire et écrire par le serveur et les emplacements mémoire de la dSpace a été effectué grâce au fichier de configuration de la bibliothèque clibClient, développé auparavant.
Un autre soucis est alors apparu : la bibliothèque Clib ne fonctionne pas lors d'un appel via le thread. Les outils de débogage n'ont pas indiqué de différences des données lors de l'appel aux fonctions, mais le problème reste entier.
Le fonctionnement du serveur est donc modifié afin de n'avoir qu'une boucle principale avec la réception de paquets (avec timeOut) puis l'appel aux notifications sortantes.

Le nœud du suivi de trajectoire a lui été modifié afin d’être compatible avec les données fournies par le nœud PURE-ROS.

Et le 17/02, dans l'après midi, VICTOIRE. La communication est fonctionnelle, et un test de suivi de chemin a été effectué avec succès, sur le parking de Polytech.

===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-02-21T17:01:49Z

Csmagghe : /* Path Tracker */

==Cahier des charges==
===Présentation générale du projet===
[[Fichier:P25_2015_RobuCar_det.png|150px|thumb|right|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 [http://www.intrade-nwe.eu/fr/ 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++)
<br>

==Étapes du projet==

<b>Partie 1 : Adaptation des codes existants</b>
<br>
*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)
<br>
<b>Partie 2 : Automatisation du déplacement du véhicule dans Lille 1</b>
<br>
*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
<br>
<b>Partie 3 : Interaction homme-machine</b>
<br>
*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
<br>

==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)===
[[Fichier:P25_2015_first_schem.png|400px|thumb|right|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 :<br> 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. <div style="clear: both"></div>

===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)===
[[Fichier:P25_2015_ConsigneTractionFreinage.PNG|400px|thumb|right|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é.
<div style="clear: both"></div>

===Semaine 6 (26/10/2015)===
[[Fichier:P25_2015Pure_protocol.png|thumbs|400px|right]]
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).

<div style="clear: both"></div>

===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.
[[Fichier:architecture_restante.png|center]]
=====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.<br>
=====Laser=====
[[Fichier:laser_sick.jpg|thumb|200px|left|Laser Sick]]
[[Fichier:Capture_rviz.png|thumb|200px|right|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.<br>
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.<br>
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. <div style="clear: both"></div>

===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 [https://www.youtube.com/watch?v=9DunFgo-5iY 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.<br/>
<center>[[Fichier:Osmcampuslille1.png|400px]] [[Fichier:Campusrvizosm2.png|420px]]</center>
<div style="clear: both"></div>

===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 ([https://en.wikipedia.org/wiki/Universally_unique_identifier 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 [https://fr.wikipedia.org/wiki/Transverse_Universelle_de_Mercator 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'[https://fr.wikipedia.org/wiki/Algorithme_A* 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.
<center>[[Fichier:Osmrondpoint.png|650px]] [[Fichier:grapherondpoint.png|80px]] [[Fichier:Rvizrondpoint.png|300px]] </center>

===Semaine 12 (07/12/2015)===
=====Path finding=====
[[Fichier:cheminpolytechgalois.png|right|300px]]
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.
<div style="clear: both"></div>

===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
[[Fichier:Capture_GPS_parking.PNG|thumb|right]]
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
<div style="clear: both"></div>

===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 a repris.
Il s'articulera autour d'une classe de gestion du protocole UDP, (principalement les envois et réceptions) 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 développer la classe souhaitée en redéfinissant uniquement les fonctions correspondantes aux actions du service.
Si une fonction n'a pas été redéfinie mais se retrouve appelée, on aura alors le code de la classe mère qui effectuera un retour a 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 gestionnaire UDP, puis envoient les réponses tels qu'elles sont codifiées par le protocole PURE. Afin de faire les envois, les services doivent faire un appel à la fonction send(&buffer) du gestionnaire UDP. Petite difficulté donc, les classes Service et udpManager doivent être "entrelacées". (Il aurait pu être envisageable de passer un buffer de sortie lors de l'appel à la fonction du service, mais le comportement (présence 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 a 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 contrôler le robuCAR. Cette classe contient donc tous les éléments nécessaires à la gestion UDP, ainsi qu'un shared pointer d'un vecteur de Service*. Cet élément sera initialisé dans le programme principal (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 réception 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és 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 aux services codés par la suite. Elle possède aussi une définition pour chacune des actions et notifications (entrantes/sortantes) possibles par le protocole pure. Ces fonctions sont définies de façon virtuelle et retourneront une sortie textuelle si jamais elle sont appelées (donc non redéclarée par la classe fille).

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

Service : 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 Notification 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 peut 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 abonnements 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ée dans la classe sous forme d'un set. Ainsi des opérations d'insert ou d'erase sur ce set pourront être effectué après recherche via un itérateur sur les éléments lors des différentes opérations.

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ée 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 réception/émission, un thread est mis en place pour assurer l'appel périodique à la fonction de gestion des notifications sortantes.
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 disponibles, il faut passer par des CRITICAL_SECTION afin de verrouiller et de mettre en attente l’accès à certaines portions de code.
Après quelques ajustements sur des formats de variables dans les buffers des messages sortants, des tests concluants ont eu lieu sur le serveur local avec des clients PURE windows développés auparavant.
Leur implémentation impose d'ouvrir un client par service voulu. Le programme de test ouvre donc un client Directory, un client Car et un client Localization. Le service Notification est aussi testé puisqu'un abonnement est automatiquement effectué par le client Car et le client Localization. Un affichage est effectué avec les données reçues, puis une boucle permet de recevoir les notifications et d'en envoyer afin de simuler une boucle de régulation.
{|align=center
|[[Fichier:P25_2015_UMLServeur_PURE.PNG|380px|thumb|Schema UML des différentes classes]]
|[[Fichier:P25_2015capture_serveur_PURE.PNG|700px|thumb|Test Serveur-Client en local]]
|}

=====Suivi de trajectoire=====

Afin de faciliter les test, des nœuds ROS de développement ont été réalisés. Ils permettent de simuler le comportement physique du robuCAR ou d'un autre véhicule suite à l'envoi de commande, et publie des informations de localisation.
Ainsi, le développement du suivi de chemin est possible sans risquer de détériorer le véhicule. Celui-ci symbolise le véhicule avec une flèche sur la carte déjà utilisée lors de la recherche de chemin.
Plusieurs types d'algorithmes de suivi de trajectoire ont été essayés, puis une adaptation de plusieurs méthodes a été choisi. La position de la flèche est actualisée au fur et à mesure de la progression (virtuelle) du véhicule, et nous a permis d’identifier phénomènes d'oscillation et de lenteur de convergence lors de certaines régulations.

===Semaine 20 (15/02/2016)===
Après avoir intégré la librairie Clib permettant de modifier les valeurs de la dSpace dans le code du serveur PURE, des tests ont été tentés sur le pc du robuCAR. Malheureusement, le développement ayant été effectué sous Visual C++ 2010 (une version présente sur le pc robuCAR, mais non utilisé par les projets précédemment réalisés), nous avons rencontré une grande liste de soucis avec la librairie Clib.
Celle ci était en effet livrée pré-compilée et sans les sources. Il y'a donc incompatibilité avec les librairies standards de Visual c++ 2010 et celles utilisées dans Clib.
Il a donc fallu modifier le projet contenant le serveur PURE afin de le faire passer sous visual c++ 2005. Lors de ce passage, l'installation et l'utilisation la librairie boost à été nécessaire, car les objets de type shared pointers ne sont plus disponibles avec Vc++2005. De plus l'initialisation de l'objet critical section a aussi du être modifié.
Une fois le programme adapté, une correspondance entre les valeurs à lire et écrire par le serveur et les emplacements mémoire de la dSpace à été effectué grace au fichier de config de la lib clibClient, développé auparavant.
Un autre soucis est alors apparu : la lib Clib ne fonctionne pas lors d'un appel via le thread. Les outils de deboggage n'ont pas indiqué de differences des données lors de l'appel aux fonctions, mais le problème reste entier.
Le fonctionnement du serveur est donc modifié afin de n'avoir qu'une boucle principale avec la reception de paquets (avec timeOut) puis l'appel aux notifications sortantes.

Le Noeud du path tracking à lui été modifié afin d'etre compatible avec les données fourni par le noeud PURE-ROS.

Et le 17/02, dans l'après midi, VICTOIRE. La communication est fonctionnelle, et un test de suivi de chemin à été effectué avec succès, sur le parking de polytech.

===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-02-21T16:59:09Z

Csmagghe : /* PURE */

==Cahier des charges==
===Présentation générale du projet===
[[Fichier:P25_2015_RobuCar_det.png|150px|thumb|right|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 [http://www.intrade-nwe.eu/fr/ 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++)
<br>

==Étapes du projet==

<b>Partie 1 : Adaptation des codes existants</b>
<br>
*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)
<br>
<b>Partie 2 : Automatisation du déplacement du véhicule dans Lille 1</b>
<br>
*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
<br>
<b>Partie 3 : Interaction homme-machine</b>
<br>
*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
<br>

==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)===
[[Fichier:P25_2015_first_schem.png|400px|thumb|right|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 :<br> 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. <div style="clear: both"></div>

===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)===
[[Fichier:P25_2015_ConsigneTractionFreinage.PNG|400px|thumb|right|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é.
<div style="clear: both"></div>

===Semaine 6 (26/10/2015)===
[[Fichier:P25_2015Pure_protocol.png|thumbs|400px|right]]
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).

<div style="clear: both"></div>

===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.
[[Fichier:architecture_restante.png|center]]
=====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.<br>
=====Laser=====
[[Fichier:laser_sick.jpg|thumb|200px|left|Laser Sick]]
[[Fichier:Capture_rviz.png|thumb|200px|right|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.<br>
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.<br>
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. <div style="clear: both"></div>

===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 [https://www.youtube.com/watch?v=9DunFgo-5iY 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.<br/>
<center>[[Fichier:Osmcampuslille1.png|400px]] [[Fichier:Campusrvizosm2.png|420px]]</center>
<div style="clear: both"></div>

===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 ([https://en.wikipedia.org/wiki/Universally_unique_identifier 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 [https://fr.wikipedia.org/wiki/Transverse_Universelle_de_Mercator 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'[https://fr.wikipedia.org/wiki/Algorithme_A* 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.
<center>[[Fichier:Osmrondpoint.png|650px]] [[Fichier:grapherondpoint.png|80px]] [[Fichier:Rvizrondpoint.png|300px]] </center>

===Semaine 12 (07/12/2015)===
=====Path finding=====
[[Fichier:cheminpolytechgalois.png|right|300px]]
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.
<div style="clear: both"></div>

===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
[[Fichier:Capture_GPS_parking.PNG|thumb|right]]
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
<div style="clear: both"></div>

===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 a repris.
Il s'articulera autour d'une classe de gestion du protocole UDP, (principalement les envois et réceptions) 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 développer la classe souhaitée en redéfinissant uniquement les fonctions correspondantes aux actions du service.
Si une fonction n'a pas été redéfinie mais se retrouve appelée, on aura alors le code de la classe mère qui effectuera un retour a 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 gestionnaire UDP, puis envoient les réponses tels qu'elles sont codifiées par le protocole PURE. Afin de faire les envois, les services doivent faire un appel à la fonction send(&buffer) du gestionnaire UDP. Petite difficulté donc, les classes Service et udpManager doivent être "entrelacées". (Il aurait pu être envisageable de passer un buffer de sortie lors de l'appel à la fonction du service, mais le comportement (présence 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 a 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 contrôler le robuCAR. Cette classe contient donc tous les éléments nécessaires à la gestion UDP, ainsi qu'un shared pointer d'un vecteur de Service*. Cet élément sera initialisé dans le programme principal (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 réception 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és 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 aux services codés par la suite. Elle possède aussi une définition pour chacune des actions et notifications (entrantes/sortantes) possibles par le protocole pure. Ces fonctions sont définies de façon virtuelle et retourneront une sortie textuelle si jamais elle sont appelées (donc non redéclarée par la classe fille).

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

Service : 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 Notification 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 peut 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 abonnements 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ée dans la classe sous forme d'un set. Ainsi des opérations d'insert ou d'erase sur ce set pourront être effectué après recherche via un itérateur sur les éléments lors des différentes opérations.

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ée 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 réception/émission, un thread est mis en place pour assurer l'appel périodique à la fonction de gestion des notifications sortantes.
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 disponibles, il faut passer par des CRITICAL_SECTION afin de verrouiller et de mettre en attente l’accès à certaines portions de code.
Après quelques ajustements sur des formats de variables dans les buffers des messages sortants, des tests concluants ont eu lieu sur le serveur local avec des clients PURE windows développés auparavant.
Leur implémentation impose d'ouvrir un client par service voulu. Le programme de test ouvre donc un client Directory, un client Car et un client Localization. Le service Notification est aussi testé puisqu'un abonnement est automatiquement effectué par le client Car et le client Localization. Un affichage est effectué avec les données reçues, puis une boucle permet de recevoir les notifications et d'en envoyer afin de simuler une boucle de régulation.
{|align=center
|[[Fichier:P25_2015_UMLServeur_PURE.PNG|380px|thumb|Schema UML des différentes classes]]
|[[Fichier:P25_2015capture_serveur_PURE.PNG|700px|thumb|Test Serveur-Client en local]]
|}

=====Path Tracker=====

Afin de faciliter les test, des nœuds ROS de développement ont été réalisés. Il permettent de simuler le comportement physique du robuCAR ou d'un autre véhicule suite à l'envoi de commande, et publie des informations de localisations.
Ainsi, le développement du path tracker est possible. Celui ci symbolise le véhicule avec une flèche sur la carte déjà utilisé lors du path finding.
Plusieurs types d'algorithmes de suivi de trajectoire ont été essayés, puis une adaptation de plusieurs méthodes à été choisi. La position de la flèche est actualisé au fur et à mesure de la progression (virtuelle) du véhicule, et nous a permis d’identifier phénomènes d'oscillation et de lenteur de convergence lors d'une telle regulation.

===Semaine 20 (15/02/2016)===
Après avoir intégré la librairie Clib permettant de modifier les valeurs de la dSpace dans le code du serveur PURE, des tests ont été tentés sur le pc du robuCAR. Malheureusement, le développement ayant été effectué sous Visual C++ 2010 (une version présente sur le pc robuCAR, mais non utilisé par les projets précédemment réalisés), nous avons rencontré une grande liste de soucis avec la librairie Clib.
Celle ci était en effet livrée pré-compilée et sans les sources. Il y'a donc incompatibilité avec les librairies standards de Visual c++ 2010 et celles utilisées dans Clib.
Il a donc fallu modifier le projet contenant le serveur PURE afin de le faire passer sous visual c++ 2005. Lors de ce passage, l'installation et l'utilisation la librairie boost à été nécessaire, car les objets de type shared pointers ne sont plus disponibles avec Vc++2005. De plus l'initialisation de l'objet critical section a aussi du être modifié.
Une fois le programme adapté, une correspondance entre les valeurs à lire et écrire par le serveur et les emplacements mémoire de la dSpace à été effectué grace au fichier de config de la lib clibClient, développé auparavant.
Un autre soucis est alors apparu : la lib Clib ne fonctionne pas lors d'un appel via le thread. Les outils de deboggage n'ont pas indiqué de differences des données lors de l'appel aux fonctions, mais le problème reste entier.
Le fonctionnement du serveur est donc modifié afin de n'avoir qu'une boucle principale avec la reception de paquets (avec timeOut) puis l'appel aux notifications sortantes.

Le Noeud du path tracking à lui été modifié afin d'etre compatible avec les données fourni par le noeud PURE-ROS.

Et le 17/02, dans l'après midi, VICTOIRE. La communication est fonctionnelle, et un test de suivi de chemin à été effectué avec succès, sur le parking de polytech.

===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-02-21T16:57:21Z

Csmagghe : /* PURE */

==Cahier des charges==
===Présentation générale du projet===
[[Fichier:P25_2015_RobuCar_det.png|150px|thumb|right|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 [http://www.intrade-nwe.eu/fr/ 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++)
<br>

==Étapes du projet==

<b>Partie 1 : Adaptation des codes existants</b>
<br>
*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)
<br>
<b>Partie 2 : Automatisation du déplacement du véhicule dans Lille 1</b>
<br>
*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
<br>
<b>Partie 3 : Interaction homme-machine</b>
<br>
*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
<br>

==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)===
[[Fichier:P25_2015_first_schem.png|400px|thumb|right|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 :<br> 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. <div style="clear: both"></div>

===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)===
[[Fichier:P25_2015_ConsigneTractionFreinage.PNG|400px|thumb|right|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é.
<div style="clear: both"></div>

===Semaine 6 (26/10/2015)===
[[Fichier:P25_2015Pure_protocol.png|thumbs|400px|right]]
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).

<div style="clear: both"></div>

===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.
[[Fichier:architecture_restante.png|center]]
=====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.<br>
=====Laser=====
[[Fichier:laser_sick.jpg|thumb|200px|left|Laser Sick]]
[[Fichier:Capture_rviz.png|thumb|200px|right|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.<br>
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.<br>
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. <div style="clear: both"></div>

===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 [https://www.youtube.com/watch?v=9DunFgo-5iY 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.<br/>
<center>[[Fichier:Osmcampuslille1.png|400px]] [[Fichier:Campusrvizosm2.png|420px]]</center>
<div style="clear: both"></div>

===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 ([https://en.wikipedia.org/wiki/Universally_unique_identifier 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 [https://fr.wikipedia.org/wiki/Transverse_Universelle_de_Mercator 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'[https://fr.wikipedia.org/wiki/Algorithme_A* 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.
<center>[[Fichier:Osmrondpoint.png|650px]] [[Fichier:grapherondpoint.png|80px]] [[Fichier:Rvizrondpoint.png|300px]] </center>

===Semaine 12 (07/12/2015)===
=====Path finding=====
[[Fichier:cheminpolytechgalois.png|right|300px]]
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.
<div style="clear: both"></div>

===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
[[Fichier:Capture_GPS_parking.PNG|thumb|right]]
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
<div style="clear: both"></div>

===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 a repris.
Il s'articulera autour d'une classe de gestion du protocole UDP, (principalement les envois et réceptions) 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 développer la classe souhaitée en redéfinissant uniquement les fonctions correspondantes aux actions du service.
Si une fonction n'a pas été redéfinie mais se retrouve appelée, on aura alors le code de la classe mère qui effectuera un retour a 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 gestionnaire UDP, puis envoient les réponses tels qu'elles sont codifiées par le protocole PURE. Afin de faire les envois, les services doivent faire un appel à la fonction send(&buffer) du gestionnaire UDP. Petite difficulté donc, les classes Service et udpManager doivent être "entrelacées". (Il aurait pu être envisageable de passer un buffer de sortie lors de l'appel à la fonction du service, mais le comportement (présence 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 a 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 contrôler le robuCAR. Cette classe contient donc tous les éléments nécessaires à la gestion UDP, ainsi qu'un shared pointer d'un vecteur de Service*. Cet élément sera initialisé dans le programme principal (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 réception 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és 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 aux services codés par la suite. Elle possède aussi une définition pour chacune des actions et notifications (entrantes/sortantes) possibles par le protocole pure. Ces fonctions sont définies de façon virtuelle et retourneront une sortie textuelle si jamais elle sont appelées (donc non redéclarée par la classe fille).

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

Service : 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 Notification 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 peut 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 abonnements 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ée dans la classe sous forme d'un set. Ainsi des opérations d'insert ou d'erase sur ce set pourront être effectué après recherche via un itérateur sur les éléments lors des différentes opérations.

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ée 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 est mis en place pour assurer l'appel périodique à la fonction de gestion des notifications sortantes.
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 à 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. Le service Notification est aussi testé puisqu'un abonnement est automatiquement effectué par le client Car et le client Localization. Un affichage est effectué avec les données reçues, puis une boucle permet de recevoir les notifications et d'en envoyer afin de simuler une boucle de régulation.
{|align=center
|[[Fichier:P25_2015_UMLServeur_PURE.PNG|380px|thumb|Schema UML des différentes classes]]
|[[Fichier:P25_2015capture_serveur_PURE.PNG|700px|thumb|Test Serveur-Client en local]]
|}
=====Path Tracker=====

Afin de faciliter les test, des nœuds ROS de développement ont été réalisés. Il permettent de simuler le comportement physique du robuCAR ou d'un autre véhicule suite à l'envoi de commande, et publie des informations de localisations.
Ainsi, le développement du path tracker est possible. Celui ci symbolise le véhicule avec une flèche sur la carte déjà utilisé lors du path finding.
Plusieurs types d'algorithmes de suivi de trajectoire ont été essayés, puis une adaptation de plusieurs méthodes à été choisi. La position de la flèche est actualisé au fur et à mesure de la progression (virtuelle) du véhicule, et nous a permis d’identifier phénomènes d'oscillation et de lenteur de convergence lors d'une telle regulation.

===Semaine 20 (15/02/2016)===
Après avoir intégré la librairie Clib permettant de modifier les valeurs de la dSpace dans le code du serveur PURE, des tests ont été tentés sur le pc du robuCAR. Malheureusement, le développement ayant été effectué sous Visual C++ 2010 (une version présente sur le pc robuCAR, mais non utilisé par les projets précédemment réalisés), nous avons rencontré une grande liste de soucis avec la librairie Clib.
Celle ci était en effet livrée pré-compilée et sans les sources. Il y'a donc incompatibilité avec les librairies standards de Visual c++ 2010 et celles utilisées dans Clib.
Il a donc fallu modifier le projet contenant le serveur PURE afin de le faire passer sous visual c++ 2005. Lors de ce passage, l'installation et l'utilisation la librairie boost à été nécessaire, car les objets de type shared pointers ne sont plus disponibles avec Vc++2005. De plus l'initialisation de l'objet critical section a aussi du être modifié.
Une fois le programme adapté, une correspondance entre les valeurs à lire et écrire par le serveur et les emplacements mémoire de la dSpace à été effectué grace au fichier de config de la lib clibClient, développé auparavant.
Un autre soucis est alors apparu : la lib Clib ne fonctionne pas lors d'un appel via le thread. Les outils de deboggage n'ont pas indiqué de differences des données lors de l'appel aux fonctions, mais le problème reste entier.
Le fonctionnement du serveur est donc modifié afin de n'avoir qu'une boucle principale avec la reception de paquets (avec timeOut) puis l'appel aux notifications sortantes.

Le Noeud du path tracking à lui été modifié afin d'etre compatible avec les données fourni par le noeud PURE-ROS.

Et le 17/02, dans l'après midi, VICTOIRE. La communication est fonctionnelle, et un test de suivi de chemin à été effectué avec succès, sur le parking de polytech.

===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-02-21T16:55:04Z

Csmagghe : /* PURE */

==Cahier des charges==
===Présentation générale du projet===
[[Fichier:P25_2015_RobuCar_det.png|150px|thumb|right|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 [http://www.intrade-nwe.eu/fr/ 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++)
<br>

==Étapes du projet==

<b>Partie 1 : Adaptation des codes existants</b>
<br>
*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)
<br>
<b>Partie 2 : Automatisation du déplacement du véhicule dans Lille 1</b>
<br>
*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
<br>
<b>Partie 3 : Interaction homme-machine</b>
<br>
*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
<br>

==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)===
[[Fichier:P25_2015_first_schem.png|400px|thumb|right|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 :<br> 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. <div style="clear: both"></div>

===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)===
[[Fichier:P25_2015_ConsigneTractionFreinage.PNG|400px|thumb|right|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é.
<div style="clear: both"></div>

===Semaine 6 (26/10/2015)===
[[Fichier:P25_2015Pure_protocol.png|thumbs|400px|right]]
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).

<div style="clear: both"></div>

===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.
[[Fichier:architecture_restante.png|center]]
=====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.<br>
=====Laser=====
[[Fichier:laser_sick.jpg|thumb|200px|left|Laser Sick]]
[[Fichier:Capture_rviz.png|thumb|200px|right|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.<br>
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.<br>
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. <div style="clear: both"></div>

===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 [https://www.youtube.com/watch?v=9DunFgo-5iY 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.<br/>
<center>[[Fichier:Osmcampuslille1.png|400px]] [[Fichier:Campusrvizosm2.png|420px]]</center>
<div style="clear: both"></div>

===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 ([https://en.wikipedia.org/wiki/Universally_unique_identifier 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 [https://fr.wikipedia.org/wiki/Transverse_Universelle_de_Mercator 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'[https://fr.wikipedia.org/wiki/Algorithme_A* 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.
<center>[[Fichier:Osmrondpoint.png|650px]] [[Fichier:grapherondpoint.png|80px]] [[Fichier:Rvizrondpoint.png|300px]] </center>

===Semaine 12 (07/12/2015)===
=====Path finding=====
[[Fichier:cheminpolytechgalois.png|right|300px]]
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.
<div style="clear: both"></div>

===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
[[Fichier:Capture_GPS_parking.PNG|thumb|right]]
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
<div style="clear: both"></div>

===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 a repris.
Il s'articulera autour d'une classe de gestion du protocole UDP, (principalement les envois et réceptions) 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 développer la classe souhaitée en redéfinissant uniquement les fonctions correspondantes aux actions du service.
Si une fonction n'a pas été redéfinie mais se retrouve appelée, on aura alors le code de la classe mère qui effectuera un retour a 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 gestionnaire UDP, puis envoient les réponses tels qu'elles sont codifiées par le protocole PURE. Afin de faire les envois, les services doivent faire un appel à la fonction send(&buffer) du gestionnaire UDP. Petite difficulté donc, les classes Service et udpManager doivent être "entrelacées". (Il aurait pu être envisageable de passer un buffer de sortie lors de l'appel à la fonction du service, mais le comportement (présence 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 a 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 contrôler le robuCAR. Cette classe contient donc tous les éléments nécessaires à la gestion UDP, ainsi qu'un shared pointer d'un vecteur de Service*. Cet élément sera initialisé dans le programme principal (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 réception 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és 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 aux services codés par la suite. Elle possède aussi une définition pour chacune des actions et notifications (entrantes/sortantes) possibles par le protocole pure. Ces fonctions sont définies de façon virtuelle et retourneront une sortie textuelle si jamais elle sont appelées (donc non redéclarée par la classe fille).

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

Service : 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ée 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 via iterator 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 est mis en place pour assurer l'appel périodique à la fonction de gestion des notifications sortantes.
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 à 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. Le service Notification est aussi testé puisqu'un abonnement est automatiquement effectué par le client Car et le client Localization. Un affichage est effectué avec les données reçues, puis une boucle permet de recevoir les notifications et d'en envoyer afin de simuler une boucle de régulation.
{|align=center
|[[Fichier:P25_2015_UMLServeur_PURE.PNG|380px|thumb|Schema UML des différentes classes]]
|[[Fichier:P25_2015capture_serveur_PURE.PNG|700px|thumb|Test Serveur-Client en local]]
|}
=====Path Tracker=====

Afin de faciliter les test, des nœuds ROS de développement ont été réalisés. Il permettent de simuler le comportement physique du robuCAR ou d'un autre véhicule suite à l'envoi de commande, et publie des informations de localisations.
Ainsi, le développement du path tracker est possible. Celui ci symbolise le véhicule avec une flèche sur la carte déjà utilisé lors du path finding.
Plusieurs types d'algorithmes de suivi de trajectoire ont été essayés, puis une adaptation de plusieurs méthodes à été choisi. La position de la flèche est actualisé au fur et à mesure de la progression (virtuelle) du véhicule, et nous a permis d’identifier phénomènes d'oscillation et de lenteur de convergence lors d'une telle regulation.

===Semaine 20 (15/02/2016)===
Après avoir intégré la librairie Clib permettant de modifier les valeurs de la dSpace dans le code du serveur PURE, des tests ont été tentés sur le pc du robuCAR. Malheureusement, le développement ayant été effectué sous Visual C++ 2010 (une version présente sur le pc robuCAR, mais non utilisé par les projets précédemment réalisés), nous avons rencontré une grande liste de soucis avec la librairie Clib.
Celle ci était en effet livrée pré-compilée et sans les sources. Il y'a donc incompatibilité avec les librairies standards de Visual c++ 2010 et celles utilisées dans Clib.
Il a donc fallu modifier le projet contenant le serveur PURE afin de le faire passer sous visual c++ 2005. Lors de ce passage, l'installation et l'utilisation la librairie boost à été nécessaire, car les objets de type shared pointers ne sont plus disponibles avec Vc++2005. De plus l'initialisation de l'objet critical section a aussi du être modifié.
Une fois le programme adapté, une correspondance entre les valeurs à lire et écrire par le serveur et les emplacements mémoire de la dSpace à été effectué grace au fichier de config de la lib clibClient, développé auparavant.
Un autre soucis est alors apparu : la lib Clib ne fonctionne pas lors d'un appel via le thread. Les outils de deboggage n'ont pas indiqué de differences des données lors de l'appel aux fonctions, mais le problème reste entier.
Le fonctionnement du serveur est donc modifié afin de n'avoir qu'une boucle principale avec la reception de paquets (avec timeOut) puis l'appel aux notifications sortantes.

Le Noeud du path tracking à lui été modifié afin d'etre compatible avec les données fourni par le noeud PURE-ROS.

Et le 17/02, dans l'après midi, VICTOIRE. La communication est fonctionnelle, et un test de suivi de chemin à été effectué avec succès, sur le parking de polytech.

===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-02-10T17:20:56Z

Csmagghe : /* PURE */

==Cahier des charges==
===Présentation générale du projet===
[[Fichier:P25_2015_RobuCar_det.png|150px|thumb|right|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 [http://www.intrade-nwe.eu/fr/ 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++)
<br>

==Étapes du projet==

<b>Partie 1 : Adaptation des codes existants</b>
<br>
*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)
<br>
<b>Partie 2 : Automatisation du déplacement du véhicule dans Lille 1</b>
<br>
*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
<br>
<b>Partie 3 : Interaction homme-machine</b>
<br>
*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
<br>

==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)===
[[Fichier:P25_2015_first_schem.png|400px|thumb|right|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 :<br> 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. <div style="clear: both"></div>

===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)===
[[Fichier:P25_2015_ConsigneTractionFreinage.PNG|400px|thumb|right|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é.
<div style="clear: both"></div>

===Semaine 6 (26/10/2015)===
[[Fichier:P25_2015Pure_protocol.png|thumbs|400px|right]]
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).

<div style="clear: both"></div>

===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.
[[Fichier:architecture_restante.png|center]]
=====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.<br>
=====Laser=====
[[Fichier:laser_sick.jpg|thumb|200px|left|Laser Sick]]
[[Fichier:Capture_rviz.png|thumb|200px|right|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.<br>
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.<br>
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. <div style="clear: both"></div>

===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 [https://www.youtube.com/watch?v=9DunFgo-5iY 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.<br/>
<center>[[Fichier:Osmcampuslille1.png|400px]] [[Fichier:Campusrvizosm2.png|420px]]</center>
<div style="clear: both"></div>

===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 ([https://en.wikipedia.org/wiki/Universally_unique_identifier 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 [https://fr.wikipedia.org/wiki/Transverse_Universelle_de_Mercator 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'[https://fr.wikipedia.org/wiki/Algorithme_A* 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.
<center>[[Fichier:Osmrondpoint.png|650px]] [[Fichier:grapherondpoint.png|80px]] [[Fichier:Rvizrondpoint.png|300px]] </center>

===Semaine 12 (07/12/2015)===
=====Path finding=====
[[Fichier:cheminpolytechgalois.png|right|300px]]
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.
<div style="clear: both"></div>

===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
[[Fichier:Capture_GPS_parking.PNG|thumb|right]]
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
<div style="clear: both"></div>

===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 a repris.
Il s'articulera autour d'une classe de gestion du protocole UDP, (principalement les envois et réceptions) 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 développer la classe souhaitée en redéfinissant uniquement les fonctions correspondantes aux actions du service.
Si une fonction n'a pas été redéfinie mais se 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 gestionnaire UDP, puis envoient les réponses tels qu'elles sont codifiées par le protocole PURE. Afin de faire les envois, les services doivent faire un appel à la fonction send(&buffer) du gestionnaire UDP. Petite difficulté donc, les classes Service et udpManager doivent être "entrelacées". (Il aurait pu être envisageable de passer un buffer de sortie lors de l'appel à la fonction du service, mais le comportement (présence 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 a 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 contrôler le robuCAR. Cette classe contient donc tous les éléments nécessaire à la gestion UDP, ainsi qu'un shared pointer d'un vecteur de Service*. Cet élément sera initialisé dans le programme principal (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 réception 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 définition pour chacune des actions et notifications (entrantes/sortantes) possibles par le protocole pure. Ces fonctions sont définies de façon virtuelle et retourneront une sortie textuelle si jamais elle sont appelées (donc non redéclarée par la classe fille).

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

Service : 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.
{|align=center
|[[Fichier:P25_2015_UMLServeur_PURE.PNG|380px|thumb|Schema UML des différentes classes]]
|[[Fichier:P25_2015capture_serveur_PURE.PNG|700px|thumb|Test Serveur-Client en local]]
|}

===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-02-10T17:08:57Z

Csmagghe : /* PURE */

==Cahier des charges==
===Présentation générale du projet===
[[Fichier:P25_2015_RobuCar_det.png|150px|thumb|right|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 [http://www.intrade-nwe.eu/fr/ 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++)
<br>

==Étapes du projet==

<b>Partie 1 : Adaptation des codes existants</b>
<br>
*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)
<br>
<b>Partie 2 : Automatisation du déplacement du véhicule dans Lille 1</b>
<br>
*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
<br>
<b>Partie 3 : Interaction homme-machine</b>
<br>
*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
<br>

==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)===
[[Fichier:P25_2015_first_schem.png|400px|thumb|right|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 :<br> 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. <div style="clear: both"></div>

===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)===
[[Fichier:P25_2015_ConsigneTractionFreinage.PNG|400px|thumb|right|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é.
<div style="clear: both"></div>

===Semaine 6 (26/10/2015)===
[[Fichier:P25_2015Pure_protocol.png|thumbs|400px|right]]
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).

<div style="clear: both"></div>

===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.
[[Fichier:architecture_restante.png|center]]
=====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.<br>
=====Laser=====
[[Fichier:laser_sick.jpg|thumb|200px|left|Laser Sick]]
[[Fichier:Capture_rviz.png|thumb|200px|right|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.<br>
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.<br>
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. <div style="clear: both"></div>

===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 [https://www.youtube.com/watch?v=9DunFgo-5iY 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.<br/>
<center>[[Fichier:Osmcampuslille1.png|400px]] [[Fichier:Campusrvizosm2.png|420px]]</center>
<div style="clear: both"></div>

===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 ([https://en.wikipedia.org/wiki/Universally_unique_identifier 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 [https://fr.wikipedia.org/wiki/Transverse_Universelle_de_Mercator 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'[https://fr.wikipedia.org/wiki/Algorithme_A* 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.
<center>[[Fichier:Osmrondpoint.png|650px]] [[Fichier:grapherondpoint.png|80px]] [[Fichier:Rvizrondpoint.png|300px]] </center>

===Semaine 12 (07/12/2015)===
=====Path finding=====
[[Fichier:cheminpolytechgalois.png|right|300px]]
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.
<div style="clear: both"></div>

===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
[[Fichier:Capture_GPS_parking.PNG|thumb|right]]
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
<div style="clear: both"></div>

===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 a repris.
Il s'articulera autour d'une classe de gestion du protocole UDP, (principalement les envois et réceptions) 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 développer la classe souhaitée en redéfinissant uniquement les fonctions correspondantes aux actions du service.
Si une fonction n'a pas été redéfinie mais se 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 gestionnaire UDP, puis envoient les réponses tels qu'elles sont codifiées par le protocole PURE. Afin de faire les envois, les services doivent faire un appel à la fonction send(&buffer) du gestionnaire UDP. Petite difficulté donc, les classes Service et udpManager doivent être "entrelacées". (Il aurait pu être envisageable de passer un buffer de sortie lors de l'appel à la fonction du service, mais le comportement (présence 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.
{|align=center
|[[Fichier:P25_2015_UMLServeur_PURE.PNG|380px|thumb|Schema UML des différentes classes]]
|[[Fichier:P25_2015capture_serveur_PURE.PNG|700px|thumb|Test Serveur-Client en local]]
|}

===Semaine 20 (15/02/2016)===
===Semaine 21 (22/02/2016)===

== Fichiers Rendus ==

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-02-03T17:24:24Z

Csmagghe : /* Semaine 18 (01/02/2016) */

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-02-03T13:09:33Z

Csmagghe : /* Localisation */

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-01-28T22:31:58Z

Csmagghe : /* Semaine 17 (25/01/2016) */

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-01-28T21:44:35Z

Csmagghe : /* Semaine 16 (18/01/2016) */

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-01-16T18:33:10Z

Csmagghe : /* Semaine 15 (11/01/2016) */

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-01-16T18:26:30Z

Csmagghe : /* Semaine 14 (04/01/2016) */

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-01-06T17:03:41Z

Csmagghe : /* Semaine 14 (04/01/2016) */

Fichier:Capture GPS parking.PNG

2016-01-06T16:42:33Z

Csmagghe :

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-01-06T14:40:21Z

Csmagghe : /* Semaine 14 (04/01/2016) */

P25 Architecture ROS pour des véhicules autonomes intelligents

2016-01-06T13:32:38Z

Csmagghe : /* Semaine 13 (14/12/2015) */

P25 Architecture ROS pour des véhicules autonomes intelligents

2015-12-08T21:08:29Z

Csmagghe : /* Semaine 12 (07/12/2015) */

P25 Architecture ROS pour des véhicules autonomes intelligents

2015-12-08T20:53:41Z

Csmagghe : /* Laser */

P25 Architecture ROS pour des véhicules autonomes intelligents

2015-12-07T17:13:03Z

Csmagghe : /* Path finding */

P25 Architecture ROS pour des véhicules autonomes intelligents

2015-12-07T17:04:20Z

Csmagghe : /* Semaine 7 (02/11/2015) */

P25 Architecture ROS pour des véhicules autonomes intelligents

2015-12-07T17:02:42Z

Csmagghe : /* Semaine 12 (07/12/2015) */

Fichier:Cheminpolytechgalois.png

2015-12-07T17:00:25Z

Csmagghe :

P25 Architecture ROS pour des véhicules autonomes intelligents

2015-12-07T15:19:22Z

Csmagghe : /* Semaine 11 (30/11/2015) */

Fichier:Grapherondpoint.png

2015-12-07T15:03:04Z

Csmagghe :

Fichier:Rvizrondpoint.png

2015-12-07T15:01:52Z

Csmagghe :

Fichier:Osmrondpoint.png

2015-12-07T14:59:50Z

Csmagghe :

P25 Architecture ROS pour des véhicules autonomes intelligents

2015-12-07T14:51:38Z

Csmagghe :

P25 Architecture ROS pour des véhicules autonomes intelligents

2015-12-07T14:48:53Z

Csmagghe : /* Map */

P25 Architecture ROS pour des véhicules autonomes intelligents

2015-12-07T14:43:18Z

Csmagghe : /* Semaine 7 (02/11/2015) */

P25 Architecture ROS pour des véhicules autonomes intelligents

2015-12-07T14:42:34Z

Csmagghe : /* Path finding */

P25 Architecture ROS pour des véhicules autonomes intelligents

2015-12-07T14:42:12Z

Csmagghe : /* Path finding */

P25 Architecture ROS pour des véhicules autonomes intelligents

2015-12-07T14:36:12Z

Csmagghe : /* Map */

P25 Architecture ROS pour des véhicules autonomes intelligents

2015-12-07T14:28:38Z

Csmagghe : /* Semaine 10 (23/11/2015) */

P25 Architecture ROS pour des véhicules autonomes intelligents

2015-12-07T14:19:55Z

Csmagghe : /* Semaine 9 (16/11/2015) */

Fichier:Osmcampuslille1.png

2015-12-07T14:14:13Z

Csmagghe :

Fichier:Campusrvizosm2.png

2015-12-07T14:08:40Z

Csmagghe :

P25 Architecture ROS pour des véhicules autonomes intelligents

2015-12-07T14:03:35Z

Csmagghe : /* Localisation */

P25 Architecture ROS pour des véhicules autonomes intelligents

2015-12-07T13:50:13Z

Csmagghe : /* Semaine 8 (09/11/2015) */

Cahier groupe n°8

2015-12-03T10:43:37Z

Csmagghe : /* Semaine 8 */

=== Présentation de la tâche particulière ===
Nous avons la responsabilité de configurer un pont pour les IMA5sc et les IMA5sa sur le serveur de virtualisation Xen ainsi que sur les différentes machines prénommées ZabethXX.

=== Matériel utilisé pour la tâche particulière ===

== Suivi de l'avancement du TP ==
=== Semaine 1 ===
Nous avons essayé de configurer un bridge sur l'une des Zabeth. Nous nous sommes heurtés au fait que le bridge prend l'adresse MAC la plus basse des deux interfaces Ethernet. Or eth0 (carte mère) a l'adresse MAC la plus haute. Donc on n'arrivait pas à accéder au net en DHCP.
=== Semaine 2 ===
*Une configuration a été réussie sur une Zabeth avec l'aide de M. Redon. Cependant, cela nécessite de forcer l'adresse MAC du bridge à être identique à celle de l'interface eth0. Cette configuration n'est pas souhaitable après discussion avec l'enseignant. Alternative proposée : réaliser une mascarade permettant aux périphériques connectés à eth1 de ne pas apparaître sur le réseau mais de quand même pouvoir y accéder via modification des paquets et passage via eth0.
[[Fichier:Pra_Xen.png|300px|thumb|right|Équivalence ports physiques interfaces]]
*On a également recherché sur le serveur Xen les ports eth grâce à ifconfig et mii-tool. Ceci était nécessaire pour pouvoir connecter les équipements au bridge IMA5sc créé, ainsi que d'indiquer aux IMA2a5 les ports de leur bridge. Le schéma suivant permet de donc retrouver la localisation physique des ports concernés sur la machine.
*L'installation de la machine virtuelle Xen a aussi été réalisée avec pour :
**hostname : KEKETTE
**nameserver : 93.48.57.48
**ip : 193.48.57.168
**netmask : 255.255.255.240
**password : ********

<br>

*Afin de mettre en place la mascarade, la méthode suivante à été appliquée : [[Fichier:MasqueradeE304-6.png|150px|thumb|right|Schéma de principe de la mascarade]]
**Adressage manuel d'eth1 en 192.168.10.1/24 via /etc/network/interfaces pour une modification permanente.
**Modification de l'iptable avec les commandes fournies dans le cours et adaptées pour une telle utilisation, placée dans /sbin/iptables-restore avec le fichier /etc/network/if-pre-up.d/iptables. Ceci à été fait en partie en suivant la [http://wiki.debian.org/iptables procédure suivante]
**Activation l'IPv4 packet forwarding en de-commentant la ligne appropriée dans le fichier /etc/sysctl.conf
**Installation et configuration d'un serveur dhcp, avec le paquet isc-dhcp-server et en le configurant sur le réseau 192.168.10.0. Ceci à été fait en partie en suivant la [http://wiki.debian.org/fr/DHCP_Server procédure suivante]

Par la suite un script de déploiement sur les autres machines à partir d'une zabeth correctement configuré à été mis en place. Le script ainsi que le fichier de configurations sont disponibles en annexe.
Le déploiement et le fonctionnement à été testé et validé à ce jour. Il suffit donc pour accéder au réseau de venir ce relier physiquement avec la carte réseau additionnelle d'une machine, de laisser la procédure dhcp s'effectuer, et d'ajouter le proxy polytech aux paramètres de connexion.

===Semaine 3===
On a effectué le premier lancement de la machine virtuelle. On y a rajouté la passerelle nécessaire (193.48.57.174) ainsi que le nom du bridge afin de récupérer un accès internet. On a installé les paquets ssh, apache2 et bind. Puis demande du nom de domaine sur Gandi.net, ainsi que la création des clés sur la VM afin de demander la génération du certificat SSL.

===Semaine 4===
====Services internet====
On a configuré apache et bind à l'aide d'un tutoriel disponible sur la documentation Ubuntu. Après cela, on a réalisé les fichiers de zones pour notre zone kekette.lol et la zone inverse. On a sécurisé le DNS avec DNSsec. Pour cela, il a fallu générer la clé KSK privée et publique et la ZSK privée et publique. On donne à Gandi les deux clés publiques. Ensuite, il faut signer les enregistrements de la zone à l'aide de dnssec-signzone. A la suite de cela, un fichier kekette.lol.signed est généré, c'est pourquoi il faut ensuite modifier le fichier /etc/bind/named.conf.local afin qu'il prenne en compte le fichier kekette.lol.signed au lieu de kekette.lol. Après quelques corrections, nous arrivons à avoir notre dnssec fonctionnel, en effet, sur ce [http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=kekette.lol lien], chacun peut constater que notre domaine ne cause aucune erreur. Cependant, deux warnings restent présents mais ils sont sans importance. Le premier warning indique juste qu'il n'y a pas de glue pour le DNS de Gandi. Le deuxième indique juste que les versions des serveurs de noms sont différentes.
====Réalisations====
=====Cryptage de données=====
A l'aide de GParted, une unique partition avec pour système de fichiers ext3 est créée sur la carte SD. On a encrypté la partition /dev/sdb1.
On initialisé le volume et un nom de mapping apparaît dans /dev/mapper/. On a créé un système de fichiers au format ext4. On a monté le système de fichiers. On y a inséré un fichier quelconque. On l'a démonté. Puis on a demandé au binôme de Jean et Flavien de vérifier qu'il est impossible d'accéder au fichier inséré précédemment sans la clé de cryptage.

=== Semaine 5 ===
=====Sécurisation de données=====
Après la création des trois partitions, nous avons créé le RAID 5 logiciel à l'aide de mdadm. Nous avons un léger soucis : le volume md0 s'est transformé en md127 pour une raison obscure. Nous avons édité le fichier /etc/mdadm/mdadm.conf. Après un redémarrage de la VM, en regardant le contenu du fichier /proc/mdstat, nous avons bien notre RAID actif :
md127 : active raid5 xvdd[0] xvdf[2] xvde[1]
Nous avons testé ensuite la perte d'une partition. Nous remarquons dans le fichier /proc/mdstat que le RAID 5 est toujours actif mais qu'il ne dispose que de seulement deux partitions actives.
md127 : active raid5 xvde[1] xvdf[2] xvdd[0](F)
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]

=====Crackage WEP=====
Nous avons réalisé cette semaine le craquage de clé wep, en même temps que tout le monde.
On lance donc successivement, après avoir désactivé les gestionnaires de reseaux :
airmon-ng start wlan-0
airodump-ng --encrypt wep wlan0 //recherche de cracotte08, son bssid son canal
airodump-ng -w out -c 7 --bssid 00:23:5e:1e:005:47 wlan0 //creation du fichier *.cap
aircrack-ng out-01.cap // une fois assez de d'ivs collectés

on obtient alors :<br>
[[Fichier:TP2015_aircrack_cracotte08.PNG|300px|la fenêtre offrant la clé]]
=== Semaine 6 ===
Réalisation en même temps que les autres groupes du cassage de clé WPA.
Récupération d'un hash avec airodump-ng, puis réalisation d'un dictionnaire réalisé simplement avec un code C affichant sur la sortie standard les nombres de 00000000 à 99999999. La sortie standard est redirigée dans un fichier texte, puis les test sont effectués sur deux pc en parallèle, en commençant à deux endroits différents. Après de longues minutes, on obtient enfin : <br>
[[Fichier:Capturewpa08.png|300px]]

=== Semaine 7 ===

Nous avons tout d'abords mis a jour le serial du fichier de zone de dns, afin de ne pas obtenir d'erreur sur notre certification après un délai de plus de 30 jours.

Par la suite, nous avons procédé à l’installation de freeradius, sa configuration avec l'ajout des deux bornes wifi (10.10.10.1 et .2) et de deux "secret" différents dans client.conf, le choix de la méthode peap dans le fichier eap.conf, et enfin l'ajout d'utilisateurs/mdp dans le fichier user.

Par la suite la configuration du sous reseau et SSID des bornes wifi à été réalisé. Les commandes présentes dans le sujet, agrémentés de quelques suppléments afin de rendre le SSID visible, et de faire le lien entre l'interface gigabits et le sous reseau wifi permettent d'obtenir une config fonctionnelle.

Enfin, la configuration du /etc/network/interfaces afin de pouvoir se connecter au réseau wifi fraîchement mis en place. La config est donc fonctionnelle une fois un ifup wlan0 lancé.
L'installation du paquet isc-dhcp-server à aussi été effectué, suivi d'une configuration.
[[Fichier:2015-8-wifi-analyser.png|150px]]<div style="clear: both"></div>

=== Semaine 8 ===
[[Fichier:2015-8-connexion-kekette.png|150px]][[Fichier:2015-8-kekette-ip-addr.png|150px]]

=== Semaine 9 ===

== Annexes ==
[[Média:Masquerade.zip]]

Cahier groupe n°8

2015-12-03T10:43:14Z

Csmagghe : /* Semaine 7 */

=== Présentation de la tâche particulière ===
Nous avons la responsabilité de configurer un pont pour les IMA5sc et les IMA5sa sur le serveur de virtualisation Xen ainsi que sur les différentes machines prénommées ZabethXX.

=== Matériel utilisé pour la tâche particulière ===

== Suivi de l'avancement du TP ==
=== Semaine 1 ===
Nous avons essayé de configurer un bridge sur l'une des Zabeth. Nous nous sommes heurtés au fait que le bridge prend l'adresse MAC la plus basse des deux interfaces Ethernet. Or eth0 (carte mère) a l'adresse MAC la plus haute. Donc on n'arrivait pas à accéder au net en DHCP.
=== Semaine 2 ===
*Une configuration a été réussie sur une Zabeth avec l'aide de M. Redon. Cependant, cela nécessite de forcer l'adresse MAC du bridge à être identique à celle de l'interface eth0. Cette configuration n'est pas souhaitable après discussion avec l'enseignant. Alternative proposée : réaliser une mascarade permettant aux périphériques connectés à eth1 de ne pas apparaître sur le réseau mais de quand même pouvoir y accéder via modification des paquets et passage via eth0.
[[Fichier:Pra_Xen.png|300px|thumb|right|Équivalence ports physiques interfaces]]
*On a également recherché sur le serveur Xen les ports eth grâce à ifconfig et mii-tool. Ceci était nécessaire pour pouvoir connecter les équipements au bridge IMA5sc créé, ainsi que d'indiquer aux IMA2a5 les ports de leur bridge. Le schéma suivant permet de donc retrouver la localisation physique des ports concernés sur la machine.
*L'installation de la machine virtuelle Xen a aussi été réalisée avec pour :
**hostname : KEKETTE
**nameserver : 93.48.57.48
**ip : 193.48.57.168
**netmask : 255.255.255.240
**password : ********

<br>

*Afin de mettre en place la mascarade, la méthode suivante à été appliquée : [[Fichier:MasqueradeE304-6.png|150px|thumb|right|Schéma de principe de la mascarade]]
**Adressage manuel d'eth1 en 192.168.10.1/24 via /etc/network/interfaces pour une modification permanente.
**Modification de l'iptable avec les commandes fournies dans le cours et adaptées pour une telle utilisation, placée dans /sbin/iptables-restore avec le fichier /etc/network/if-pre-up.d/iptables. Ceci à été fait en partie en suivant la [http://wiki.debian.org/iptables procédure suivante]
**Activation l'IPv4 packet forwarding en de-commentant la ligne appropriée dans le fichier /etc/sysctl.conf
**Installation et configuration d'un serveur dhcp, avec le paquet isc-dhcp-server et en le configurant sur le réseau 192.168.10.0. Ceci à été fait en partie en suivant la [http://wiki.debian.org/fr/DHCP_Server procédure suivante]

Par la suite un script de déploiement sur les autres machines à partir d'une zabeth correctement configuré à été mis en place. Le script ainsi que le fichier de configurations sont disponibles en annexe.
Le déploiement et le fonctionnement à été testé et validé à ce jour. Il suffit donc pour accéder au réseau de venir ce relier physiquement avec la carte réseau additionnelle d'une machine, de laisser la procédure dhcp s'effectuer, et d'ajouter le proxy polytech aux paramètres de connexion.

===Semaine 3===
On a effectué le premier lancement de la machine virtuelle. On y a rajouté la passerelle nécessaire (193.48.57.174) ainsi que le nom du bridge afin de récupérer un accès internet. On a installé les paquets ssh, apache2 et bind. Puis demande du nom de domaine sur Gandi.net, ainsi que la création des clés sur la VM afin de demander la génération du certificat SSL.

===Semaine 4===
====Services internet====
On a configuré apache et bind à l'aide d'un tutoriel disponible sur la documentation Ubuntu. Après cela, on a réalisé les fichiers de zones pour notre zone kekette.lol et la zone inverse. On a sécurisé le DNS avec DNSsec. Pour cela, il a fallu générer la clé KSK privée et publique et la ZSK privée et publique. On donne à Gandi les deux clés publiques. Ensuite, il faut signer les enregistrements de la zone à l'aide de dnssec-signzone. A la suite de cela, un fichier kekette.lol.signed est généré, c'est pourquoi il faut ensuite modifier le fichier /etc/bind/named.conf.local afin qu'il prenne en compte le fichier kekette.lol.signed au lieu de kekette.lol. Après quelques corrections, nous arrivons à avoir notre dnssec fonctionnel, en effet, sur ce [http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=kekette.lol lien], chacun peut constater que notre domaine ne cause aucune erreur. Cependant, deux warnings restent présents mais ils sont sans importance. Le premier warning indique juste qu'il n'y a pas de glue pour le DNS de Gandi. Le deuxième indique juste que les versions des serveurs de noms sont différentes.
====Réalisations====
=====Cryptage de données=====
A l'aide de GParted, une unique partition avec pour système de fichiers ext3 est créée sur la carte SD. On a encrypté la partition /dev/sdb1.
On initialisé le volume et un nom de mapping apparaît dans /dev/mapper/. On a créé un système de fichiers au format ext4. On a monté le système de fichiers. On y a inséré un fichier quelconque. On l'a démonté. Puis on a demandé au binôme de Jean et Flavien de vérifier qu'il est impossible d'accéder au fichier inséré précédemment sans la clé de cryptage.

=== Semaine 5 ===
=====Sécurisation de données=====
Après la création des trois partitions, nous avons créé le RAID 5 logiciel à l'aide de mdadm. Nous avons un léger soucis : le volume md0 s'est transformé en md127 pour une raison obscure. Nous avons édité le fichier /etc/mdadm/mdadm.conf. Après un redémarrage de la VM, en regardant le contenu du fichier /proc/mdstat, nous avons bien notre RAID actif :
md127 : active raid5 xvdd[0] xvdf[2] xvde[1]
Nous avons testé ensuite la perte d'une partition. Nous remarquons dans le fichier /proc/mdstat que le RAID 5 est toujours actif mais qu'il ne dispose que de seulement deux partitions actives.
md127 : active raid5 xvde[1] xvdf[2] xvdd[0](F)
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]

=====Crackage WEP=====
Nous avons réalisé cette semaine le craquage de clé wep, en même temps que tout le monde.
On lance donc successivement, après avoir désactivé les gestionnaires de reseaux :
airmon-ng start wlan-0
airodump-ng --encrypt wep wlan0 //recherche de cracotte08, son bssid son canal
airodump-ng -w out -c 7 --bssid 00:23:5e:1e:005:47 wlan0 //creation du fichier *.cap
aircrack-ng out-01.cap // une fois assez de d'ivs collectés

on obtient alors :<br>
[[Fichier:TP2015_aircrack_cracotte08.PNG|300px|la fenêtre offrant la clé]]
=== Semaine 6 ===
Réalisation en même temps que les autres groupes du cassage de clé WPA.
Récupération d'un hash avec airodump-ng, puis réalisation d'un dictionnaire réalisé simplement avec un code C affichant sur la sortie standard les nombres de 00000000 à 99999999. La sortie standard est redirigée dans un fichier texte, puis les test sont effectués sur deux pc en parallèle, en commençant à deux endroits différents. Après de longues minutes, on obtient enfin : <br>
[[Fichier:Capturewpa08.png|300px]]

=== Semaine 7 ===

Nous avons tout d'abords mis a jour le serial du fichier de zone de dns, afin de ne pas obtenir d'erreur sur notre certification après un délai de plus de 30 jours.

Par la suite, nous avons procédé à l’installation de freeradius, sa configuration avec l'ajout des deux bornes wifi (10.10.10.1 et .2) et de deux "secret" différents dans client.conf, le choix de la méthode peap dans le fichier eap.conf, et enfin l'ajout d'utilisateurs/mdp dans le fichier user.

Par la suite la configuration du sous reseau et SSID des bornes wifi à été réalisé. Les commandes présentes dans le sujet, agrémentés de quelques suppléments afin de rendre le SSID visible, et de faire le lien entre l'interface gigabits et le sous reseau wifi permettent d'obtenir une config fonctionnelle.

Enfin, la configuration du /etc/network/interfaces afin de pouvoir se connecter au réseau wifi fraîchement mis en place. La config est donc fonctionnelle une fois un ifup wlan0 lancé.
L'installation du paquet isc-dhcp-server à aussi été effectué, suivi d'une configuration.
[[Fichier:2015-8-wifi-analyser.png|150px]]<div style="clear: both"></div>

=== Semaine 8 ===
[[Fichier:2015-8-connexion-kekette.png|300px]][[Fichier:2015-8-kekette-ip-addr.png|300px]]
=== Semaine 9 ===

== Annexes ==
[[Média:Masquerade.zip]]

Cahier groupe n°8

2015-12-03T10:42:03Z

Csmagghe : /* Semaine 7 */

=== Présentation de la tâche particulière ===
Nous avons la responsabilité de configurer un pont pour les IMA5sc et les IMA5sa sur le serveur de virtualisation Xen ainsi que sur les différentes machines prénommées ZabethXX.

=== Matériel utilisé pour la tâche particulière ===

== Suivi de l'avancement du TP ==
=== Semaine 1 ===
Nous avons essayé de configurer un bridge sur l'une des Zabeth. Nous nous sommes heurtés au fait que le bridge prend l'adresse MAC la plus basse des deux interfaces Ethernet. Or eth0 (carte mère) a l'adresse MAC la plus haute. Donc on n'arrivait pas à accéder au net en DHCP.
=== Semaine 2 ===
*Une configuration a été réussie sur une Zabeth avec l'aide de M. Redon. Cependant, cela nécessite de forcer l'adresse MAC du bridge à être identique à celle de l'interface eth0. Cette configuration n'est pas souhaitable après discussion avec l'enseignant. Alternative proposée : réaliser une mascarade permettant aux périphériques connectés à eth1 de ne pas apparaître sur le réseau mais de quand même pouvoir y accéder via modification des paquets et passage via eth0.
[[Fichier:Pra_Xen.png|300px|thumb|right|Équivalence ports physiques interfaces]]
*On a également recherché sur le serveur Xen les ports eth grâce à ifconfig et mii-tool. Ceci était nécessaire pour pouvoir connecter les équipements au bridge IMA5sc créé, ainsi que d'indiquer aux IMA2a5 les ports de leur bridge. Le schéma suivant permet de donc retrouver la localisation physique des ports concernés sur la machine.
*L'installation de la machine virtuelle Xen a aussi été réalisée avec pour :
**hostname : KEKETTE
**nameserver : 93.48.57.48
**ip : 193.48.57.168
**netmask : 255.255.255.240
**password : ********

<br>

*Afin de mettre en place la mascarade, la méthode suivante à été appliquée : [[Fichier:MasqueradeE304-6.png|150px|thumb|right|Schéma de principe de la mascarade]]
**Adressage manuel d'eth1 en 192.168.10.1/24 via /etc/network/interfaces pour une modification permanente.
**Modification de l'iptable avec les commandes fournies dans le cours et adaptées pour une telle utilisation, placée dans /sbin/iptables-restore avec le fichier /etc/network/if-pre-up.d/iptables. Ceci à été fait en partie en suivant la [http://wiki.debian.org/iptables procédure suivante]
**Activation l'IPv4 packet forwarding en de-commentant la ligne appropriée dans le fichier /etc/sysctl.conf
**Installation et configuration d'un serveur dhcp, avec le paquet isc-dhcp-server et en le configurant sur le réseau 192.168.10.0. Ceci à été fait en partie en suivant la [http://wiki.debian.org/fr/DHCP_Server procédure suivante]

Par la suite un script de déploiement sur les autres machines à partir d'une zabeth correctement configuré à été mis en place. Le script ainsi que le fichier de configurations sont disponibles en annexe.
Le déploiement et le fonctionnement à été testé et validé à ce jour. Il suffit donc pour accéder au réseau de venir ce relier physiquement avec la carte réseau additionnelle d'une machine, de laisser la procédure dhcp s'effectuer, et d'ajouter le proxy polytech aux paramètres de connexion.

===Semaine 3===
On a effectué le premier lancement de la machine virtuelle. On y a rajouté la passerelle nécessaire (193.48.57.174) ainsi que le nom du bridge afin de récupérer un accès internet. On a installé les paquets ssh, apache2 et bind. Puis demande du nom de domaine sur Gandi.net, ainsi que la création des clés sur la VM afin de demander la génération du certificat SSL.

===Semaine 4===
====Services internet====
On a configuré apache et bind à l'aide d'un tutoriel disponible sur la documentation Ubuntu. Après cela, on a réalisé les fichiers de zones pour notre zone kekette.lol et la zone inverse. On a sécurisé le DNS avec DNSsec. Pour cela, il a fallu générer la clé KSK privée et publique et la ZSK privée et publique. On donne à Gandi les deux clés publiques. Ensuite, il faut signer les enregistrements de la zone à l'aide de dnssec-signzone. A la suite de cela, un fichier kekette.lol.signed est généré, c'est pourquoi il faut ensuite modifier le fichier /etc/bind/named.conf.local afin qu'il prenne en compte le fichier kekette.lol.signed au lieu de kekette.lol. Après quelques corrections, nous arrivons à avoir notre dnssec fonctionnel, en effet, sur ce [http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=kekette.lol lien], chacun peut constater que notre domaine ne cause aucune erreur. Cependant, deux warnings restent présents mais ils sont sans importance. Le premier warning indique juste qu'il n'y a pas de glue pour le DNS de Gandi. Le deuxième indique juste que les versions des serveurs de noms sont différentes.
====Réalisations====
=====Cryptage de données=====
A l'aide de GParted, une unique partition avec pour système de fichiers ext3 est créée sur la carte SD. On a encrypté la partition /dev/sdb1.
On initialisé le volume et un nom de mapping apparaît dans /dev/mapper/. On a créé un système de fichiers au format ext4. On a monté le système de fichiers. On y a inséré un fichier quelconque. On l'a démonté. Puis on a demandé au binôme de Jean et Flavien de vérifier qu'il est impossible d'accéder au fichier inséré précédemment sans la clé de cryptage.

=== Semaine 5 ===
=====Sécurisation de données=====
Après la création des trois partitions, nous avons créé le RAID 5 logiciel à l'aide de mdadm. Nous avons un léger soucis : le volume md0 s'est transformé en md127 pour une raison obscure. Nous avons édité le fichier /etc/mdadm/mdadm.conf. Après un redémarrage de la VM, en regardant le contenu du fichier /proc/mdstat, nous avons bien notre RAID actif :
md127 : active raid5 xvdd[0] xvdf[2] xvde[1]
Nous avons testé ensuite la perte d'une partition. Nous remarquons dans le fichier /proc/mdstat que le RAID 5 est toujours actif mais qu'il ne dispose que de seulement deux partitions actives.
md127 : active raid5 xvde[1] xvdf[2] xvdd[0](F)
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]

=====Crackage WEP=====
Nous avons réalisé cette semaine le craquage de clé wep, en même temps que tout le monde.
On lance donc successivement, après avoir désactivé les gestionnaires de reseaux :
airmon-ng start wlan-0
airodump-ng --encrypt wep wlan0 //recherche de cracotte08, son bssid son canal
airodump-ng -w out -c 7 --bssid 00:23:5e:1e:005:47 wlan0 //creation du fichier *.cap
aircrack-ng out-01.cap // une fois assez de d'ivs collectés

on obtient alors :<br>
[[Fichier:TP2015_aircrack_cracotte08.PNG|300px|la fenêtre offrant la clé]]
=== Semaine 6 ===
Réalisation en même temps que les autres groupes du cassage de clé WPA.
Récupération d'un hash avec airodump-ng, puis réalisation d'un dictionnaire réalisé simplement avec un code C affichant sur la sortie standard les nombres de 00000000 à 99999999. La sortie standard est redirigée dans un fichier texte, puis les test sont effectués sur deux pc en parallèle, en commençant à deux endroits différents. Après de longues minutes, on obtient enfin : <br>
[[Fichier:Capturewpa08.png|300px]]

=== Semaine 7 ===

Nous avons tout d'abords mis a jour le serial du fichier de zone de dns, afin de ne pas obtenir d'erreur sur notre certification après un délai de plus de 30 jours.

Par la suite, nous avons procédé à l’installation de freeradius, sa configuration avec l'ajout des deux bornes wifi (10.10.10.1 et .2) et de deux "secret" différents dans client.conf, le choix de la méthode peap dans le fichier eap.conf, et enfin l'ajout d'utilisateurs/mdp dans le fichier user.

Par la suite la configuration du sous reseau et SSID des bornes wifi à été réalisé. Les commandes présentes dans le sujet, agrémentés de quelques suppléments afin de rendre le SSID visible, et de faire le lien entre l'interface gigabits et le sous reseau wifi permettent d'obtenir une config fonctionnelle.

Enfin, la configuration du /etc/network/interfaces afin de pouvoir se connecter au réseau wifi fraîchement mis en place. La config est donc fonctionnelle une fois un ifup wlan0 lancé.
L'installation du paquet isc-dhcp-server à aussi été effectué, suivi d'une configuration.
[[Fichier:2015-8-wifi-analyser.png|300px]]<div style="clear: both"></div>

=== Semaine 8 ===
[[Fichier:2015-8-connexion-kekette.png|300px]][[Fichier:2015-8-kekette-ip-addr.png|300px]]
=== Semaine 9 ===

== Annexes ==
[[Média:Masquerade.zip]]

Cahier groupe n°8

2015-12-03T10:40:37Z

Csmagghe : /* Semaine 7 */

=== Présentation de la tâche particulière ===
Nous avons la responsabilité de configurer un pont pour les IMA5sc et les IMA5sa sur le serveur de virtualisation Xen ainsi que sur les différentes machines prénommées ZabethXX.

=== Matériel utilisé pour la tâche particulière ===

== Suivi de l'avancement du TP ==
=== Semaine 1 ===
Nous avons essayé de configurer un bridge sur l'une des Zabeth. Nous nous sommes heurtés au fait que le bridge prend l'adresse MAC la plus basse des deux interfaces Ethernet. Or eth0 (carte mère) a l'adresse MAC la plus haute. Donc on n'arrivait pas à accéder au net en DHCP.
=== Semaine 2 ===
*Une configuration a été réussie sur une Zabeth avec l'aide de M. Redon. Cependant, cela nécessite de forcer l'adresse MAC du bridge à être identique à celle de l'interface eth0. Cette configuration n'est pas souhaitable après discussion avec l'enseignant. Alternative proposée : réaliser une mascarade permettant aux périphériques connectés à eth1 de ne pas apparaître sur le réseau mais de quand même pouvoir y accéder via modification des paquets et passage via eth0.
[[Fichier:Pra_Xen.png|300px|thumb|right|Équivalence ports physiques interfaces]]
*On a également recherché sur le serveur Xen les ports eth grâce à ifconfig et mii-tool. Ceci était nécessaire pour pouvoir connecter les équipements au bridge IMA5sc créé, ainsi que d'indiquer aux IMA2a5 les ports de leur bridge. Le schéma suivant permet de donc retrouver la localisation physique des ports concernés sur la machine.
*L'installation de la machine virtuelle Xen a aussi été réalisée avec pour :
**hostname : KEKETTE
**nameserver : 93.48.57.48
**ip : 193.48.57.168
**netmask : 255.255.255.240
**password : ********

<br>

*Afin de mettre en place la mascarade, la méthode suivante à été appliquée : [[Fichier:MasqueradeE304-6.png|150px|thumb|right|Schéma de principe de la mascarade]]
**Adressage manuel d'eth1 en 192.168.10.1/24 via /etc/network/interfaces pour une modification permanente.
**Modification de l'iptable avec les commandes fournies dans le cours et adaptées pour une telle utilisation, placée dans /sbin/iptables-restore avec le fichier /etc/network/if-pre-up.d/iptables. Ceci à été fait en partie en suivant la [http://wiki.debian.org/iptables procédure suivante]
**Activation l'IPv4 packet forwarding en de-commentant la ligne appropriée dans le fichier /etc/sysctl.conf
**Installation et configuration d'un serveur dhcp, avec le paquet isc-dhcp-server et en le configurant sur le réseau 192.168.10.0. Ceci à été fait en partie en suivant la [http://wiki.debian.org/fr/DHCP_Server procédure suivante]

Par la suite un script de déploiement sur les autres machines à partir d'une zabeth correctement configuré à été mis en place. Le script ainsi que le fichier de configurations sont disponibles en annexe.
Le déploiement et le fonctionnement à été testé et validé à ce jour. Il suffit donc pour accéder au réseau de venir ce relier physiquement avec la carte réseau additionnelle d'une machine, de laisser la procédure dhcp s'effectuer, et d'ajouter le proxy polytech aux paramètres de connexion.

===Semaine 3===
On a effectué le premier lancement de la machine virtuelle. On y a rajouté la passerelle nécessaire (193.48.57.174) ainsi que le nom du bridge afin de récupérer un accès internet. On a installé les paquets ssh, apache2 et bind. Puis demande du nom de domaine sur Gandi.net, ainsi que la création des clés sur la VM afin de demander la génération du certificat SSL.

===Semaine 4===
====Services internet====
On a configuré apache et bind à l'aide d'un tutoriel disponible sur la documentation Ubuntu. Après cela, on a réalisé les fichiers de zones pour notre zone kekette.lol et la zone inverse. On a sécurisé le DNS avec DNSsec. Pour cela, il a fallu générer la clé KSK privée et publique et la ZSK privée et publique. On donne à Gandi les deux clés publiques. Ensuite, il faut signer les enregistrements de la zone à l'aide de dnssec-signzone. A la suite de cela, un fichier kekette.lol.signed est généré, c'est pourquoi il faut ensuite modifier le fichier /etc/bind/named.conf.local afin qu'il prenne en compte le fichier kekette.lol.signed au lieu de kekette.lol. Après quelques corrections, nous arrivons à avoir notre dnssec fonctionnel, en effet, sur ce [http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=kekette.lol lien], chacun peut constater que notre domaine ne cause aucune erreur. Cependant, deux warnings restent présents mais ils sont sans importance. Le premier warning indique juste qu'il n'y a pas de glue pour le DNS de Gandi. Le deuxième indique juste que les versions des serveurs de noms sont différentes.
====Réalisations====
=====Cryptage de données=====
A l'aide de GParted, une unique partition avec pour système de fichiers ext3 est créée sur la carte SD. On a encrypté la partition /dev/sdb1.
On initialisé le volume et un nom de mapping apparaît dans /dev/mapper/. On a créé un système de fichiers au format ext4. On a monté le système de fichiers. On y a inséré un fichier quelconque. On l'a démonté. Puis on a demandé au binôme de Jean et Flavien de vérifier qu'il est impossible d'accéder au fichier inséré précédemment sans la clé de cryptage.

=== Semaine 5 ===
=====Sécurisation de données=====
Après la création des trois partitions, nous avons créé le RAID 5 logiciel à l'aide de mdadm. Nous avons un léger soucis : le volume md0 s'est transformé en md127 pour une raison obscure. Nous avons édité le fichier /etc/mdadm/mdadm.conf. Après un redémarrage de la VM, en regardant le contenu du fichier /proc/mdstat, nous avons bien notre RAID actif :
md127 : active raid5 xvdd[0] xvdf[2] xvde[1]
Nous avons testé ensuite la perte d'une partition. Nous remarquons dans le fichier /proc/mdstat que le RAID 5 est toujours actif mais qu'il ne dispose que de seulement deux partitions actives.
md127 : active raid5 xvde[1] xvdf[2] xvdd[0](F)
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]

=====Crackage WEP=====
Nous avons réalisé cette semaine le craquage de clé wep, en même temps que tout le monde.
On lance donc successivement, après avoir désactivé les gestionnaires de reseaux :
airmon-ng start wlan-0
airodump-ng --encrypt wep wlan0 //recherche de cracotte08, son bssid son canal
airodump-ng -w out -c 7 --bssid 00:23:5e:1e:005:47 wlan0 //creation du fichier *.cap
aircrack-ng out-01.cap // une fois assez de d'ivs collectés

on obtient alors :<br>
[[Fichier:TP2015_aircrack_cracotte08.PNG|300px|la fenêtre offrant la clé]]
=== Semaine 6 ===
Réalisation en même temps que les autres groupes du cassage de clé WPA.
Récupération d'un hash avec airodump-ng, puis réalisation d'un dictionnaire réalisé simplement avec un code C affichant sur la sortie standard les nombres de 00000000 à 99999999. La sortie standard est redirigée dans un fichier texte, puis les test sont effectués sur deux pc en parallèle, en commençant à deux endroits différents. Après de longues minutes, on obtient enfin : <br>
[[Fichier:Capturewpa08.png|300px]]

=== Semaine 7 ===

Nous avons tout d'abords mis a jour le serial du fichier de zone de dns, afin de ne pas obtenir d'erreur sur notre certification après un délai de plus de 30 jours.

Par la suite, nous avons procédé à l’installation de freeradius, sa configuration avec l'ajout des deux bornes wifi (10.10.10.1 et .2) et de deux "secret" différents dans client.conf, le choix de la méthode peap dans le fichier eap.conf, et enfin l'ajout d'utilisateurs/mdp dans le fichier user.

Par la suite la configuration du sous reseau et SSID des bornes wifi à été réalisé. Les commandes présentes dans le sujet, agrémentés de quelques suppléments afin de rendre le SSID visible, et de faire le lien entre l'interface gigabits et le sous reseau wifi permettent d'obtenir une config fonctionnelle.

Enfin, la configuration du /etc/network/interfaces afin de pouvoir se connecter au réseau wifi fraîchement mis en place. La config est donc fonctionnelle une fois un ifup wlan0 lancé.
L'installation du paquet isc-dhcp-server à aussi été effectué, suivi d'une configuration.
[[Fichier:2015-8-wifi-analyser.png|300px]]

=== Semaine 8 ===
[[Fichier:2015-8-connexion-kekette.png|300px]][[Fichier:2015-8-kekette-ip-addr.png|300px]]
=== Semaine 9 ===

== Annexes ==
[[Média:Masquerade.zip]]

Cahier groupe n°8

2015-12-03T10:40:10Z

Csmagghe : /* Suivi de l'avancement du TP */

=== Présentation de la tâche particulière ===
Nous avons la responsabilité de configurer un pont pour les IMA5sc et les IMA5sa sur le serveur de virtualisation Xen ainsi que sur les différentes machines prénommées ZabethXX.

=== Matériel utilisé pour la tâche particulière ===

== Suivi de l'avancement du TP ==
=== Semaine 1 ===
Nous avons essayé de configurer un bridge sur l'une des Zabeth. Nous nous sommes heurtés au fait que le bridge prend l'adresse MAC la plus basse des deux interfaces Ethernet. Or eth0 (carte mère) a l'adresse MAC la plus haute. Donc on n'arrivait pas à accéder au net en DHCP.
=== Semaine 2 ===
*Une configuration a été réussie sur une Zabeth avec l'aide de M. Redon. Cependant, cela nécessite de forcer l'adresse MAC du bridge à être identique à celle de l'interface eth0. Cette configuration n'est pas souhaitable après discussion avec l'enseignant. Alternative proposée : réaliser une mascarade permettant aux périphériques connectés à eth1 de ne pas apparaître sur le réseau mais de quand même pouvoir y accéder via modification des paquets et passage via eth0.
[[Fichier:Pra_Xen.png|300px|thumb|right|Équivalence ports physiques interfaces]]
*On a également recherché sur le serveur Xen les ports eth grâce à ifconfig et mii-tool. Ceci était nécessaire pour pouvoir connecter les équipements au bridge IMA5sc créé, ainsi que d'indiquer aux IMA2a5 les ports de leur bridge. Le schéma suivant permet de donc retrouver la localisation physique des ports concernés sur la machine.
*L'installation de la machine virtuelle Xen a aussi été réalisée avec pour :
**hostname : KEKETTE
**nameserver : 93.48.57.48
**ip : 193.48.57.168
**netmask : 255.255.255.240
**password : ********

<br>

*Afin de mettre en place la mascarade, la méthode suivante à été appliquée : [[Fichier:MasqueradeE304-6.png|150px|thumb|right|Schéma de principe de la mascarade]]
**Adressage manuel d'eth1 en 192.168.10.1/24 via /etc/network/interfaces pour une modification permanente.
**Modification de l'iptable avec les commandes fournies dans le cours et adaptées pour une telle utilisation, placée dans /sbin/iptables-restore avec le fichier /etc/network/if-pre-up.d/iptables. Ceci à été fait en partie en suivant la [http://wiki.debian.org/iptables procédure suivante]
**Activation l'IPv4 packet forwarding en de-commentant la ligne appropriée dans le fichier /etc/sysctl.conf
**Installation et configuration d'un serveur dhcp, avec le paquet isc-dhcp-server et en le configurant sur le réseau 192.168.10.0. Ceci à été fait en partie en suivant la [http://wiki.debian.org/fr/DHCP_Server procédure suivante]

Par la suite un script de déploiement sur les autres machines à partir d'une zabeth correctement configuré à été mis en place. Le script ainsi que le fichier de configurations sont disponibles en annexe.
Le déploiement et le fonctionnement à été testé et validé à ce jour. Il suffit donc pour accéder au réseau de venir ce relier physiquement avec la carte réseau additionnelle d'une machine, de laisser la procédure dhcp s'effectuer, et d'ajouter le proxy polytech aux paramètres de connexion.

===Semaine 3===
On a effectué le premier lancement de la machine virtuelle. On y a rajouté la passerelle nécessaire (193.48.57.174) ainsi que le nom du bridge afin de récupérer un accès internet. On a installé les paquets ssh, apache2 et bind. Puis demande du nom de domaine sur Gandi.net, ainsi que la création des clés sur la VM afin de demander la génération du certificat SSL.

===Semaine 4===
====Services internet====
On a configuré apache et bind à l'aide d'un tutoriel disponible sur la documentation Ubuntu. Après cela, on a réalisé les fichiers de zones pour notre zone kekette.lol et la zone inverse. On a sécurisé le DNS avec DNSsec. Pour cela, il a fallu générer la clé KSK privée et publique et la ZSK privée et publique. On donne à Gandi les deux clés publiques. Ensuite, il faut signer les enregistrements de la zone à l'aide de dnssec-signzone. A la suite de cela, un fichier kekette.lol.signed est généré, c'est pourquoi il faut ensuite modifier le fichier /etc/bind/named.conf.local afin qu'il prenne en compte le fichier kekette.lol.signed au lieu de kekette.lol. Après quelques corrections, nous arrivons à avoir notre dnssec fonctionnel, en effet, sur ce [http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=kekette.lol lien], chacun peut constater que notre domaine ne cause aucune erreur. Cependant, deux warnings restent présents mais ils sont sans importance. Le premier warning indique juste qu'il n'y a pas de glue pour le DNS de Gandi. Le deuxième indique juste que les versions des serveurs de noms sont différentes.
====Réalisations====
=====Cryptage de données=====
A l'aide de GParted, une unique partition avec pour système de fichiers ext3 est créée sur la carte SD. On a encrypté la partition /dev/sdb1.
On initialisé le volume et un nom de mapping apparaît dans /dev/mapper/. On a créé un système de fichiers au format ext4. On a monté le système de fichiers. On y a inséré un fichier quelconque. On l'a démonté. Puis on a demandé au binôme de Jean et Flavien de vérifier qu'il est impossible d'accéder au fichier inséré précédemment sans la clé de cryptage.

=== Semaine 5 ===
=====Sécurisation de données=====
Après la création des trois partitions, nous avons créé le RAID 5 logiciel à l'aide de mdadm. Nous avons un léger soucis : le volume md0 s'est transformé en md127 pour une raison obscure. Nous avons édité le fichier /etc/mdadm/mdadm.conf. Après un redémarrage de la VM, en regardant le contenu du fichier /proc/mdstat, nous avons bien notre RAID actif :
md127 : active raid5 xvdd[0] xvdf[2] xvde[1]
Nous avons testé ensuite la perte d'une partition. Nous remarquons dans le fichier /proc/mdstat que le RAID 5 est toujours actif mais qu'il ne dispose que de seulement deux partitions actives.
md127 : active raid5 xvde[1] xvdf[2] xvdd[0](F)
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]

=====Crackage WEP=====
Nous avons réalisé cette semaine le craquage de clé wep, en même temps que tout le monde.
On lance donc successivement, après avoir désactivé les gestionnaires de reseaux :
airmon-ng start wlan-0
airodump-ng --encrypt wep wlan0 //recherche de cracotte08, son bssid son canal
airodump-ng -w out -c 7 --bssid 00:23:5e:1e:005:47 wlan0 //creation du fichier *.cap
aircrack-ng out-01.cap // une fois assez de d'ivs collectés

on obtient alors :<br>
[[Fichier:TP2015_aircrack_cracotte08.PNG|300px|la fenêtre offrant la clé]]
=== Semaine 6 ===
Réalisation en même temps que les autres groupes du cassage de clé WPA.
Récupération d'un hash avec airodump-ng, puis réalisation d'un dictionnaire réalisé simplement avec un code C affichant sur la sortie standard les nombres de 00000000 à 99999999. La sortie standard est redirigée dans un fichier texte, puis les test sont effectués sur deux pc en parallèle, en commençant à deux endroits différents. Après de longues minutes, on obtient enfin : <br>
[[Fichier:Capturewpa08.png|300px]]

=== Semaine 7 ===

Nous avons tout d'abords mis a jour le serial du fichier de zone de dns, afin de ne pas obtenir d'erreur sur notre certification après un délai de plus de 30 jours.

Par la suite, nous avons procédé à l’installation de freeradius, sa configuration avec l'ajout des deux bornes wifi (10.10.10.1 et .2) et de deux "secret" différents dans client.conf, le choix de la méthode peap dans le fichier eap.conf, et enfin l'ajout d'utilisateurs/mdp dans le fichier user.

Par la suite la configuration du sous reseau et SSID des bornes wifi à été réalisé. Les commandes présentes dans le sujet, agrémentés de quelques suppléments afin de rendre le SSID visible, et de faire le lien entre l'interface gigabits et le sous reseau wifi permettent d'obtenir une config fonctionnelle.

Enfin, la configuration du /etc/network/interfaces afin de pouvoir se connecter au réseau wifi fraîchement mis en place. La config est donc fonctionnelle une fois un ifup wlan0 lancé.
L'installation du paquet isc-dhcp-server à aussi été effectué, suivi d'une configuration.
[[2015-8-wifi-analyser.png|300px]]

=== Semaine 8 ===
[[Fichier:2015-8-connexion-kekette.png|300px]][[Fichier:2015-8-kekette-ip-addr.png|300px]]
=== Semaine 9 ===

== Annexes ==
[[Média:Masquerade.zip]]

Fichier:2015-8-kekette-ip-addr.png

2015-12-03T10:39:44Z

Csmagghe :