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

IMA4 2016/2017 P20

2017-05-10T11:23:32Z

Mbutaye : /* Description du projet */

__TOC__
 
==Cahier des charges==

Ce cahier des charges a pour objectif de définir le projet, ce qui est attendu ainsi que les contraintes de conception qui lui sont associées.

===Présentation générale du projet===

Le projet consiste à concevoir et développer un environnement virtuel de test pour l'Association de Robotique de Polytech Lille (ARPL). Ce simulateur doit reproduire les conditions de participation à la Logistic League de manière à pouvoir obtenir rapidement des données et tester le code ainsi que les stratégies de jeu utilisés par les robots.

====Contexte====
Ce simulateur est un outil développé dans le cadre de la RoboCup et plus particulièrement de la Logistic League. La RoboCup est une compétition internationale de robotique dans laquelle on voit beaucoup d'entreprises et de robots connus tel que NAO. Cette compétition a pour but de mettre en avant les évolutions en matière de robotique ainsi que les qualités des organismes participants.

La Logistic League est une des différentes épreuves proposées. L'objectif est de repérer le terrain puis de produire des objets avec différents éléments fournis par des machines et à livrer dans des plages de temps données. Une RefereeBox ou boîte arbitre sert à la coordination ainsi qu'à l'arbitrage. C'est cette boite qui va informer le robots des différents objets à construire avec la date de livraison demandée. Elle va également donner leur rôles aux machines présentes sur le terrain. L'arbitre va enregistrer les horaires de dépôt des objets et la position de chacune des machines lors de la compétition.

Celle-ci se déroule sur une piste de la taille d'une salle moyenne. Chaque équipe peut utiliser jusqu'à trois robots Robotino 3 pour réaliser les tâches demandées. Sur la piste, à part les robots, se trouvent seulement des machines dites de production ou de livraison. Elles vont servir soit à se procurer un élément nécessaire à la production de l'objet final soit à livrer celui-ci lorsqu'il est terminé.

====Objectif du projet====

Ce projet va permettre de fournir à l'équipe de l'ARPL un simulateur léger et complet, leur permettant de simuler en un court laps de temps un match entier ou partiel et de tester leur code et leur stratégie. Cela leur permettra de développer plus rapidement et efficacement.

====Description du projet====

Le simulateur devra répondre à un certain nombre de critères. Tout d'abord il lui faudra pouvoir simuler toutes les entités présentes sur la piste lors d'un match. Nous parlons des robots et des machines mais également des capteurs et des conditions de jeu.

Nous devrons faire en sorte que le simulateur puisse facilement intégrer le code de contrôle des robots afin de le tester. De plus il faut permettre à l'utilisateur de gérer les parties du code à tester ainsi que de changer les conditions et paramètres de simulation afin de ne tester que certaines parties du code (par exemple en excluant la gestion des collisions). Nous inclurons une gestion des phases de jeu (Découverte et Production) dans ce but. De ce point de vue l'idéal serait de générer un launchfile et de permettre à l'utilisateur de gérer l'utilisation des nœuds un par un.

En sus, le simulateur gérant les robots de l'équipe adverse, il aura une fonctionnalité de sauvegarde des configurations que ce soit pour le code ou les stratégies afin de comparer l'évolution des performances.

Le simulateur a certaines contraintes afin d'être utilisable et utile. Il doit opérer une compression du temps c'est à dire réaliser la simulation d'un match en moins de temps qu'une durée normale de match. Il s'agit d'obtenir des données représentant la réalité en un cours laps de temps. La communication avec la RefereeBox est indispensable. Celle-ci étant fourni par les organisateurs de la compétition nous n'avons pas à la simuler mais nous devons communiquer avec elle pour rendre la simulation plus réaliste.

====Choix techniques : matériel et logiciel====

Nous n'avons pas besoin de matériel hormis d'ordinateurs afin de programmer.

Dû à la compétition et aux choix de développement de l'équipe de l'ARPL, nous allons programmer en C++ avec les bibliothèques QT ainsi que le middleware ROS, une surcouche de programmation destinée à la programmation de robots.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

*Simuler les différentes entités
** les Robotinos ;
** les machines ;
** l'environnement.

*Gérer l'interfaçage entre le simulateur et le code des Robots
** lire et lancer le méta-paquet ;
** identifier les différents parties du code ;
** proposer l'activation/désactivation de ces parties et créer un launchfile en conséquence ;
** créer un système de sauvegarde de tout code interfacé permettant sa réutilisation.

*Simuler un match
** communiquer avec la RefereeBox et recevoir les différents ordres de celle-ci ;
** gérer les machines et la communication avec la RefereeBox ;
** gérer l'équipe de l'utilisateur et son interaction avec le reste de la simulation ;
** gérer l'équipe adverse et son interaction avec le reste de la simulation.

*Paramétrage avancé de la simulation
** proposer différents modes de simulations ;
** activation/désactivation des paramètres de la simulation ;
** gestion des phases.

*Interface utilisateur
** fournir des données utilisables et intéressantes sur la simulation ;
** créer une GUI ergonomique ;
** importer les données de la simulation sur la GUI pour une meilleure analyse de celle-ci.

====Calendrier====

Répartition du temps consacré au projet (120h/personne) :

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures supplémentaires !! Total
|-
| Définition cahier des charges
| 2
|
|
|
|
|
|
|
|
|
|
|
|2
|-
|Mise à niveau matérielle et intellectuelle
|
|13
|
|
|
|1
|
|
|
|
|
|
|14
|-
|Conception théorique
|
|5
|7
|4
|2
|
|
|0,5
|
|13
|2
|
|33.5
|-
|Programmation de la simulation
|
|
|8
|15
|16
|4
|8
|6
|10
|6
|10
|18
|101
|-
|Programmation de l'affichage avec rviz
|
|
|
|
|
|5
|8
|13
|6
|
|
|5
|37
|-
|Wiki
|
|
|0,5
|1,5
|1,5
|0,5
|2
|0,5
|3
|0,5
|0,5
|2
|12,5
|-
|Réunions tuteurs
|2
|
|
|
|2
|2
|
|
|
|
|
|
|6
|-
|Total
|4
|18
|15,5
|20,5
|21,5
|12,5
|18
|20
|19
|19,5
|12,5
|25
|206
|}

==Planning des tâches==

{| class="wikitable"
!Tâche !! Date prévue !! Avancement !! Commentaires
|-
| Affichage des formes avec Rviz
| 01/03/2017
| Terminé
| Cercle & Rectangle
|-
| Affichage d'un robot
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Affichage d'une machine
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Gestion du temps
| 08/03/2017
| Terminé
| Bornes de facteurs possibles à déterminer
|-
| Déplacement d'un robot
| 22/03/2017
| Terminé
| Vitesse et déplacement au point; Besoin d'interfaçage sur le code ARPL
|-
| Affichage de l'orientation de l'entité
| 13/03/2017
| Terminé
| Affichage d'une forme Flèche dont l'orientation change avec celle de l'entité. Grise. Orientation en degrés.
|-
| Lecture et affichage de la map
| 19/03/2017
| Terminé
| Affichage de la map, des murs et des zones interdites.
|-
| Communication RefBox
| 01/04/2017
| Inachevé
| Communication en place pour l'affichage des machines à leur position de départ.
|-
| Gestion Collision
| 01/04/2017
| Inachevé
| Implémentation de la fonction de regroupement
|}

==Avancement du Projet==

===Semaine 1===
Nous avons commencé par installer ROS et tout ce dont nous avons besoin pour travailler correctement. Nous avons également suivi des [http://wiki.ros.org/ROS/Tutorials tutoriels] pour apprendre à utiliser ROS.

Pour pouvoir travailler en binôme sans problèmes et pour que nos encadrants puissent suivre notre avancement et tester le logiciel, nous avons utilisé le logiciel de gestion de versions Git, sur lequel on publie notre code au fur et à mesure.

Nous n'avions pas encore de dépôt sur celui-ci, donc nous avons commencé par réfléchir à la structure de notre projet.
Nous commencerons par implémenter la phase d'exploration, ce qui comprend aussi le déplacement du robot, la détection de machines et de feux ainsi qu'une interface utilisateur basique.

En effet, le match oppose deux équipes ayant jusque trois robotinos qui s'affrontent lors de deux phases. La première est la phase d'exploration, durant laquelle les robots doivent trouver les machines de leur équipe en explorant le terrain. Ils doivent annoncer la position des machines et les signaux des feux de celles-ci : chaque machine, peu importe son type, possède un feu tricolore (rouge, jaune, vert) qui durant la phase d'exploration aura une combinaison de lumières allumées aléatoirement (au moins une doit l'être).

La création d'un simulateur passe par la réflexion sur les besoins en conception du simulateur (décris en partie ci-dessus). Nous avons donc passé un certain temps à schématiser la structure de notre simulateur et à en assimiler les besoins et l'ordre de création.

===Semaine 2===
Nous avons récupéré un dépôt Git (nommé ''logistic-sim'') sur lequel travailler auprès de nos encadrants, nous pouvons donc commencer la programmation cette semaine.

Ceci étant notre premier projet mêlant ROS et Git, nous avons tenté de créer la structure du projet mais avons vite rencontré quelques difficultés.
Nous avons ensuite compris qu'il était nécessaire de d'abord créer un environnement de travail ROS pour le projet, dans lequel on clône ensuite le dépôt Git localement.

Nous obtenons ainsi la structure de projet suivante :
* Workspace ROS
** build
** devel
** src
*** CMakeLists.txt
*** logistic-sim

Les dossiers build, devel, src et CMakeList.txt sont des fichiers et dossiers générés par ''Catkin'', un outil permettant de créer des paquets ROS facilement.

Nous avons ensuite décidé de séparer le code du projet en différents dossiers en fonction des tâches à effectuer :
* '''Entites''' pour simuler les différentes entités (Robotinos, machines, environnement...)
* '''Gestion_Code''' pour gérer l'interfaçage entre le simulateur et le code des robots
* '''Match''' pour simuler le déroulement d'un match
* '''GUI''' pour l'interface utilisateur avec le framework Qt

Dans chacun de ces dossiers, nous créerons des ''packages'' contenant les différentes fonctionnalités du projet.

Chaque ''package'' a la structure suivante :
* CMakeLists.txt
* include pour les fichiers .h
* package.xml
* README.md
* src pour les classes et nodes .cpp
* launch pour les launchfiles

Dans un premier temps, on commence par la gestion de la position du robot et la reconnaissance des feux.

===Semaine 3===

Nous avons avancé sur la programmation de la gestion de la position du robot et de la reconnaissance des feux.

Nous avons décrit nos classes par des schémas UML avec l'outil gratuit ''Modélio'' pour créer une documentation facilement accessible. Les commentaires des fonctions, classes et fichiers au format ''Doxygen'' nous permettront également de générer une documentation du projet sous format HTML notamment.

Nous suivons aussi la normalisation du code donnée par l'ARPL pour avoir les mêmes conventions de nommage partout.

Nous avons décidé de créer un nouveau package ''match'' qui contiendra les nœuds correspondants aux différentes phases de jeu, et avons donc par conséquent commencé par créer un nœud pour la phase d'exploration.

Nous avons également commencé à réfléchir à la façon dont les informations sont communiquées dans le match : il y a un arbitre, la ''Referee Box'' qui permet de faire communiquer le simulateur et les robots jouant le match. En effet, l'arbitre prend les décisions importantes (placement des machines au début du jeu etc.) et c'est à lui que les robots s'adressent. Nous devons donc aussi communiquer avec lui pour recevoir certaines informations (par exemple les informations de base de la phase d'exploration) et les retransmettre dans le simulateur aux nœuds qui en auront besoin.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v1.png|Schéma UML du package ''machine''
Fichier:Formes_package_Class_diagram_v1.png|Schéma UML du package ''formes''
</gallery>

===Semaine 4===

Cette semaine, nous avons créé plusieurs nouveaux packages et modifié ceux qui avaient déjà été créés.

Nous avons créé la classe Cercle dans le package ''formes'', nous pouvons donc maintenant utiliser deux formes différentes, le rectangle et le cercle.
La classe Entite a elle aussi été rajoutée. En effet, certains attributs des machines sont communs avec ceux des robots; cette classe nous permet de les rassembler et les classes Machine et Robot hériteront ainsi de Entite.

Un nouveau package ''management'' a également fait son apparition. Il contiendra les classes Equipe et Manager. Le Manager sera chargé de créer les équipes et permettra d'y accéder partout dans le code, mais aussi de procéder aux différentes initialisations lors du démarrage d'une nouvelle phase.

Au package ''management'' s'ajoute le nouveau package ''robot'' dont le rôle est de simuler les robotinos lors du match.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v2.png|Schéma UML du package ''machine''
Fichier:Robot_package_Class_diagram_v1.png|Schéma UML du package ''robot''
Fichier:Formes_package_Class_diagram_v2.png|Schéma UML du package ''formes''
Fichier:Management_package_Class_diagram_v1.png|Schéma UML du package ''management''
</gallery>

Nous avons également rendu visite à l'un de nos tuteurs de stage pendant la semaine dans le but d'obtenir un premier retour sur notre travail et l'avancement du projet.

Nous avons pu effectuer immédiatement quelques modifications nécessaires suite aux commentaires de notre tuteur. Nous avons dû, par exemple, clôner leur projet dans le même espace de travail que le notre pour pouvoir réutiliser certains paquets de messages déjà créés. Cela permettra une meilleure compatibilité. D'autres modifications concernaient entre autres les conventions de nommage de certaines classes et l'ajout d'un dossier supplémentaire dans le dossier include de chaque package portant le nom de celui-ci, pour ne pas avoir de conflits quant au nommage des fichiers.

Une réunion avec toute l'équipe des tuteurs a été prévue pour la semaine 5.

===Semaine 5===

La semaine a commencé par une réunion avec l'équipe de l'ARPL se chargeant d'encadrer notre projet, c'est-à-dire Vincent et Thomas. Nous avons discuté ensemble de l'avancement du simulateur et de l'ordre dans lequel effectuer les tâches. Ils nous également demandé de créer un planning de nos tâches avec la date prévue pour chacune; ils auront en effet besoin de modifier leur code à certains endroits pour pouvoir utiliser le simulateur (nous n'aurons pas besoin de tous les nœuds, certains comme la détection Laser nous étant inutiles) et souhaiteraient savoir lorsque nous seront prêt à tester de nouvelles fonctionnalités.

Nous nous sommes lancés dans l'affichage des formes avec l'outil ''rviz'', qui permet de visualiser en 3D les messages de type ''visualisation_msgs'' qui lui sont envoyés sur le topic associé. Ces messages sont disponibles en différents types. Pour afficher les formes nous utiliseront le format ''Marker'' qui permet d'afficher un objet en 3D (cubes, sphères, flèches, cylindres) ou en 2D en lui donnant un z de 0.

Nous avons donc commencé par faire les tutoriels sur l'utilisation de rviz puis par ajouter le code nécessaire à l'affichage des formes. Nous avons ainsi décidé d'ajouter la variable du message de type ''Marker'' dans la classe Forme; celle-ci sera accessible par toutes les classes filles de Forme, notamment Cercle et Rectangle. Nous avons également créé une méthode ''display'' qui sera chargée de mettre à jour la position de la forme et de publier le message. Les différents ''setters'' des classes filles modifieront également le message pour qu'il soit à jour lors de l'envoi.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_rectangle.png|Affichage de la forme ''Rectangle'' dans Rviz
Fichier:Rviz_screenshot_cercle.png|Affichage de la forme ''Cercle'' dans Rviz
</gallery>

===Semaine 6===

Cette semaine, nous continuons d'améliorer l'affichage en programmant cette fois-ci la classe ''Robot'' (qui possède une forme, étant une Entité) pour pouvoir visualiser le robot avec rviz. Nous avons donc ajouté une fonction ''display'' à ''Entite'', faisant elle-même appel à la fonction ''display'' de sa forme; ce qui permettra un affichage plus facile de l'objet.

Nous avons également ajouté une forme ''Texte'' pour afficher du texte informatif sur les formes (par exemple, une lettre et un id pour une entité, "R1" dans le cas du premier robot de chaque équipe). Ce texte est affiché en cyan ou en magenta, en fonction de la couleur de l'équipe. Les noms des ''markers'' de la forme et du texte eux aussi dépendent du type de l'entité.

Enfin, nous avons permis au entités de type Machine de gérer leur affichage. Pour cela, nous avons dû créer une classe fille de cette entité pour pouvoir tester son affichage. Le choix s'est porté sur les machines de type BS (Base Station).

En cours de route, nous avons été confrontés à un problème au niveau de l'affichage en 2D. Il semblait logique que la hauteur des objets (en z) soit égale à 0 pour un affichage 2D, mais il s'est avéré que la couleur de l'objet était alors imprévisible (plus souvent noir que de la bonne couleur). Il en fait fallu laisser une légère épaisseur (0.001 mètres dans notre cas) pour que la couleur s'affiche correctement.

Un de nos objectifs était aussi de gérer l'affichage de l'orientation de nos entités. En effet, cela semble essentiel pour les robots par exemple, représentés par des ronds et pouvant se déplacer. Nous avons ainsi créé un nouveau marker ''Fleche''; il était également possible de changer le type de marker en ''interactive marker'' ce qui aurait permis l'affichage de flèches de direction, mais celles-ci permettaient de modifier la position de l'objet et n'étaient disponibles qu'en multiple de 2 (déplacement sur un axe). Le choix s'est donc porté sur l'utilisation d'un marker classique dont on change l'orientation en même temps que celle de l'entité.
Nous avons rencontré quelques soucis quant à la gestion de l'orientation du marker, celle-ci étant un ''quaternion'' (x, y, z, w) alors que nous souhaitons donner l'angle en degrés (ou en radians éventuellement); la documentation n'est pas forcément facile à trouver pour ROS.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_robot.png|Affichage de l'entité ''Robot'' dans Rviz
Fichier:Rviz_screenshot_machine.png|Affichage de l'entité ''BaseStation'' dans Rviz
Fichier:Rviz_screenshot_fleche.png|Affichage de l'entité ''Robot'' avec une forme ''Fleche'' dans Rviz
</gallery>

Nous avons dû corriger nos constructeurs pour être le plus efficace possible et remplir au maximum les besoins des futurs fonctions.

La problématique rendant nécessaire une gestion du temps vient du besoin de l'ARPL de pouvoir contrôler la vitesse de simulation et donc de pouvoir jouer un match très rapidement afin d'observer le comportement de leur code.
Nous avons commencé et fini la gestion du temps. ROS intègre une interface de temps qui se cale sur la machine qui lance ROS.
Pour que plusieurs machines suivent le même temps il faut opérer une synchronisation des temps. Cependant lors de la simulation tous les robots auront leur référentiel temporel sur la même machine ce qui rend une synchronisation inutile.

Il existe un topic ''clock'' qui sert pour les simulations. En forçant nos nœuds à utiliser le temps de simulation, nous avons une échelle temporelle utilisable et synchronisée. Nous avons donc un nœud qui va publier sur ce topic le temps qui sera initialisé à 0 en début de match.

Un paramètre d'environnement ROS sert à régler le facteur d'accélération de la simulation par rapport au temps réel. Il est modifiable à tout instant et est initialisé en premier dans le launchfile.

===Semaine 7===

Nous nous sommes attaqués à l'affichage du terrain dans rviz.

Pour cela, nous pouvions nous inspirer de code écrit par l'ARPL permettant de charger une carte depuis un fichier ''.yaml''. Certains de leurs packages nous ont été utiles, mais d'autres se sont avérés inutilisables tels quels à cause d'erreurs tantôt de "référence indéfinie" à un fichier, tantôt de "redéfinition" du même fichier (la cause de ces erreurs reste pour le moment toujours un mystère).
Nous avons donc opté, pour pouvoir avancer rapidement sur le projet, d'utiliser tel quel ce qu'il était possible d'utiliser, et sinon de recopier les fonctions nécessaires dans notre package. Certaines fonctions nécessitaient d'ailleurs de toute façon des modifications, car dans notre simulateur nous gérons aussi l'affichage de la carte alors qu'eux ne faisaient que la charger.

Un fichier ''.yaml'' a la syntaxe suivante :
field:
name: robocup_simulator
size: [14, 9, 0.0]
gradient:
distance: 0.35
minValue: 0
walls:
bottom1:
start: [-6, 0, 0.0]
end: [-4, 0, 0.0]

Nous avons donc commencé par charger le fichier en mémoire en le passant en paramètre à un ''launchfile'' lançant le nœud chargé de lire et d'afficher la carte. Ensuite, en faisant appel à des ''param'' (paramètres) du nœud actuel et en leur donnant le nom du champs (''name'' par exemple), on peut récupérer les valeurs du fichiers voulues.

Nous avons ainsi créé une classe ''Carte'' pour gérer le chargement des données depuis le fichier et toutes les fonctions utilitaires associées, mais permettant aussi d'afficher la carte grâce à une fonction ''display'' de même fonctionnement que celles créées précédemment pour les entités.

Pour l'affichage sur rviz, nous nous sommes servis du type d'objet ''Map'' pour visualiser le sol du terrain (en blanc ci-dessous). Nous avons également créé un vecteur de Rectangles pour afficher les murs (en bleu foncé ci-dessous) et un vecteur de Rectangles pour les zones interdites au robot (en noir).

Nous aurions aimé mettre à jour la taille de la grille affichée en fonction de la taille de la carte, mais il s'avère que c'est impossible, la grille ne provenant pas d'un message publié.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_map.png|Affichage du terrain de jeu dans Rviz
</gallery>

===Semaine 8===

Nous avons complété la fonction de gestion de la vitesse. Il n'y a plus de nœud pour gérer les déplacements au profit d'un nœud gérant chaque robot.
Les robots envoient un vecteur "twist" pour donner leur commande vitesse, soit deux vecteurs vitesse 3D, l'un pour la vitesse linéaire et l'autre pour la vitesse angulaire.
Cependant ce vecteur vitesse est paramétré dans le repère du robot, c'est-à-dire avec le vecteur x dirigé dans la direction de l'orientation du robot.
Pour nos calculs nous nous servons du repère originel, que ce soit pour placer les entités ou les déplacer. Cela facilite les calculs dans la simulation.
Ainsi nous devons transposer les vecteurs vitesse reçus pour les appliquer à notre repère.

La simulation fonctionnant en 2D nous simplifions les données en utilisant un seul vecteur 3D (x et y pour le déplacement linéaire et z pour le changement d'orientation soit la vitesse angulaire autour de l'axe z).
La transposition n'est nécessaire que pour les déplacements linéaires, donc nous utilisons de la trigonométrie simple et nous ajoutons le déplacement ainsi obtenu à la position actuelle, ce qui donne :

v_x = v_x1*cos(orientation_radian) - v_y1*sin(orientation_radian)

v_y = v_x1*sin(orientation_radian) + v_y1*sin(orientation_radian)

x_new = v_x *delta_t + x

y_new = v_y *delta_t + y

orientation_new = (v_angulaire*delta_t + orientation) [360]

Nous avons également apporté des modifications aux flèches et textes; en effet, maintenant que le déplacement des robots est possible, nous pouvons effectuer des tests.
Il s'avère que nous ne modifions pas la position des flèches et textes, le robot s'éloignait alors d'eux lorsqu'il se déplaçait.
Nous avons donc ajouté les quelques modifications nécessaires pour que ces formes suivent l'entité en déplacement.

Nous avons aussi commencé à compléter le package ''machine'' pour lui ajouter les sous-classes de Machine représentant les différentes machines (MPS) du jeu (BaseStation, CapStation, RingStation, DeliveryStation).
La BaseStation permettra au robot de récupérer un objet de type base, la RingStation d'y empiler des anneaux de couleurs différentes en fonction des commandes reçues, la CapStation de déposer un chapeau au sommet de l'objet et enfin on l'apporte à la DeliveryStation.

Nous avons complété ci-dessous les schémas UML du projet dans son état actuel :

<gallery style="margin: 0 auto;">
Fichier:Formes_package_Class_diagram_v3.png|Schéma UML du package ''formes''
Fichier:Machine_package_Class_diagram_v3.png|Schéma UML du package ''machine''
Fichier:Management_package_Class_diagram_v2.png|Schéma UML du package ''management''
Fichier:Robot_package_Class_diagram_v2.png|Schéma UML du package ''robot''
</gallery>

===Semaine 9===

Nous avons dû concevoir une fonction de récupération de distance entre deux entités.
Les robots étant les seules entités mobiles, nous ne calculons que la distance entre un robot et une autre entité.
La distance entre deux robots, soit deux cercles, est facile à déterminer. Nous récupérons les points des deux cercles étant sur la droite passant par les centres des dits cercles. Puis nous appliquons le calcul de distance.

Lorsqu'il s'agit de calculer la distance la plus courte avec un rectangle, c'est un peu plus compliqué et très rapidement le nombre de calculs devient très grand. Nous avons choisi une stratégie calculatoire réduisant le nombre de calculs avec les conseils de Mme Nathalie Delfosse.

Le problème est de trouver la distance la plus courte entre les deux formes ainsi que les points concernés.

[[Fichier:GD_1.png|500px|center|texte descriptif]]

Nous pouvons facilement tracer la zone de collision, soit la zone qui permet de dire qu'il y a une collision si le centre du robot est dessus.

[[Fichier:GD_2.png|500px|center|texte descriptif]]

Ensuite on découpe l'espace en 8 zones en prolongeant les cotés du rectangle pour en faire des droites.

[[Fichier:GD_3.png|500px|center|texte descriptif]]

Lorsqu'un robot se situe en zone n°1 alors la distance la plus proche est celle qui sépare le cercle de l'angle le plus proche du rectangle. Donc (S2) est cette distance avec la résolution du système composé de la droite par le centre du cercle et l'angle, et le cercle. Nous obtenons alors le point du cercle le plus proche du rectangle.

(S2)
(x−xc)²+(y−yc)²==R²
y= ax+b

Dans la zone n°2, la distance la plus courte est une droite verticale, ce qui nous donne facilement le point du cercle et le point du rectangle.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Dans la zone n°3, on observe le même comportement qu'avec la zone n°2 mais cette fois-ci à l'horizontal, les équations sont donc les mêmes avec une inversion des x en y et inversement.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Cette semaine nous avons aussi travaillé sur la production elle-même en complétant les classes du package ''machine''. Nous avons ainsi ajouté à chaque sous-classe une fonction ''setup'' qui permet d'initialiser la machine, la plupart du temps avec une couleur d'anneau ou de base, et pour la ''DeliveryStation'' avec un numéro de porte.

Ces fonctions seront ensuite appelées dans un nœud ''machines_node'' du package ''management''.

===Semaine 10===

Cette semaine, nous avons avancé sur la simulation en permettant à une 'Equipe' d'afficher ses six machines et ses trois robots. Le ''Manager'', lui, affiche les deux équipes; nous avons ainsi tous les acteurs d'un match sur le même terrain.

Nous avons également installé la Referee Box, dans la prévision du travail sur la communication entre simulation et celle-ci, mais aussi pour pouvoir utiliser des types de messages particuliers du package ''llsf_msgs'' inclus avec la Referee Box.

En effet, les machines changent d'état en fonction des commandes qu'elles reçoivent. En effet, les équipes doivent remplir des commandes tout au long du match, et les robots ordonnent ainsi aux machines de produire des types de pièces particuliers.
Ils commencent par envoyer un message de ''setup'' qui va indiquer à la machine quel type de pièce préparer. À ce moment là la machine change d'état (état occupé) et ceci est reflété dans la couleur de son feu.
Lorsque la pièce est disponible, la machine rechange d'état pour être de nouveau disponible.

Il existe également d'autres types d'états, comme lorsque la machine est ''down'' lors d'une maintenance programmée décidée par la Referee Box au début du match, lorsque la machine vient de recevoir un ordre ou encore lorsqu'un robot tente de l'utiliser sans lui envoyer de message de ''setup'', elle est alors hors-service pendant un certain moment.

Lié à la Referee Box, nous avons dû chercher à synchroniser le temps de celle-ci avec le simulateur. Cependant, en observant le code du simulateur Gazebo (actuellement non fonctionnel) et la manière de communiquer avec l'arbitre, nous avons conclu que nous n'avions pas le temps de le faire.

Nous avons dû implémenter le système de gestion de collisions. Graphiquement et avec les équations, il est simple pour un être humain de comprendre le fonctionnement. Cependant le code impose plus de restriction. Nous avons donc décomposé la théorie en plusieurs morceaux. Une fonction pour obtenir la distance entre deux points, plusieurs fonctions permettant de déterminer les points les plus proches entre chaque structure, et enfin une fonction déterminant s'il y a collision.

Pour les cercles, il faut déterminer l'équation de la droite qui passe par le centre des deux cercles puis résoudre le système correspondant à l'intersection de la droite et du cercle qui nous donne une équation du second degré. On choisit alors le point le plus proche de l'autre cercle.

Pour un cercle et un rectangle, on teste zone par zone. Nous ne sommes pas obligés de nous placer dans le référentiel du rectangle. Au lieu de cela, nous allons vérifier zone par zone l'appartenance du cercle à celles-ci grâce aux systèmes composés de trois droites (les cotés du rectangles) pour les zones latérales et de deux pour les zones d'angles. Ces systèmes s'excluent les uns les autres. Si le cercle n'est dans aucune zone alors il est à l'intérieur du rectangle. Ce qui est soit une situation impossible, soit une collision. Lorsque l'on a la zone, on résout le système correspondant (décrit lors de la semaine 9). Cette implémentation n'a pas été faite entièrement durant cette semaine. Nous l'avons continué lors du temps supplémentaire.

===Heures supplémentaires===

Nous avons commencé par ajouter l'affichage des feux (composés d'un rectangle et de trois cercles rouge, jaune, vert).
En fonction de l'état de la machine à laquelle ils appartiennent, les couleurs affichés changent. D'après le règlement, si tout va bien le feu sera vert fixe, si la machine est occupée il sera jaune fixe et si la machine est en maintenance programmée il sera rouge fixe. Si la machine vient de recevoir un ordre, il sera vert clignotant et si elle est hors-service il sera clignotant jaune et rouge.

C'est pourquoi nous avons aussi implémenté le clignotement de celui-ci qu'il est possible de voir dans la vidéo ci-dessous.

Enfin, les machines seront positionnées de différentes manières au début d'un match, il est donc nécessaire que le feu associé ait la même rotation que sa machine.
Nous avons ainsi commencé par permettre aux cercles du haut et du bas d'effectuer un rotation autour du cercle central. Une fois la chose faite, nous avons modifié la rotation d'une machine. En effet, jusque là elle était implémentée de la même manière que pour les robots, or ceux-ci se déplacent et pas notre machine. Il n'est donc pas nécessaire que la flèche soit en rotation mais plutôt qu'elle soit positionnée de manière fixe (mais cela reste modifiable dans le code) et que ce soit le rectangle de la machine qui effectue une rotation sur lui-même. Il en va de même pour le rectangle du feu.

Enfin, nous avons dû gérer le positionnement du feu par rapport au rectangle : il faut, lorsque la machine effectue une rotation, calculer la position de son coin inférieur gauche et positionner le feu par rapport à celui-ci.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_feu_45_degres.png|Feu en rotation
Fichier:Rviz_screenshot_machine_135_degres.png|Machine et son feu en rotation
Fichier:Rviz_screenshot_machine_state_down.png|Machine en état de maintenance programmée
Fichier:Rviz_screenshot_machine_state_busy.png|Machine occupée
Fichier:Rviz_screenshot_machine_state_ok.png|Machine disponible
Fichier:Feu_clignotant.mp4|Vidéo du feu qui clignote
</gallery>

La classe Manager a été transformée en Singleton. C'est un ''pattern'' de programmation permettant de n'instancier une classe qu'en un seul exemplaire unique accessible partout dans le programme. Dans notre cas, cela est particulièrement utile car le Manager permet de gérer les équipes et leurs états. On a seulement besoin d'instancier les équipes du Manager une seule fois au début du Match, et pas à chaque fois qu'on souhaite y accéder.

Nous avons aussi débuté la communication avec la RefereeBox. Il y a trois modes de communication avec celle-ci : en tant que "pair" (communication UDP) sur un canal public, idem sur un canal privé ou en tant que "contrôleur" (communication TCP).
Dans notre cas, c'est le mode "contrôleur" qui nous intéresse : en effet, nous devons avoir accès à toutes les informations de l'arbitre pour pouvoir réaliser une simulation correcte, et seul la communication en TCP le permet. En UDP sur canal public, seul un nombre très limité d'informations est disponible et sur canal privé les informations sont cryptées pour les cacher à l'autre équipe.

Nous avons donc pour cela, après avoir réalisé l'installation de la RefereeBox avec le projet ''llsf-refbox'' dont nous avons parlé semaine 10, créé une classe ''ClientTCP'' d'après un exemple inclus dans le projet installé. Le client s'inscrit comme devant recevoir certains types de messages, par exemple le message de type ''llsf_msgs::MachineInfo'', qui permet d'obtenir les positions des machines et leur état. Ensuite, lorsqu'il reçoit un nouveau message, on vérifie de quel type il s'agit et on agit en conséquence. Dans l'exemple précédent, on appelle ainsi une fonction d'initialisation de la position des machines une unique fois après la réception d'un message de type MachineInfo, lorsque le Manager est initialisé mais que les positions des machines ne le sont pas. Cette fonction prenant en paramètre le message reçu, on n'a plus qu'à changer les différentes valeurs nécessaires.

Pour tester cela, nous avons utilisé la Refbox. Pour la démarrer, il faut se trouver dans le dossier ''llsf-refbox/bin'' et exécuter deux scripts; d'abord
''llsf-refbox'' pour la démarrer puis ''llsf-refbox-shell'' pour voir une interface graphique de gestion apparaître dans le terminal.

De la façon dont nous avons réalisé le projet, il est nécessaire de créer dans son ''bashrc'' une variable d'environnement ROBOCUP_DIR qui correspond au répertoire ROS qui contient le projet et la Referee Box. Celle-ci permet d'utiliser les messages du package ''llsf_msgs''.

== Fichiers Rendus ==

IMA4 2016/2017 P20

2017-05-10T11:23:00Z

Mbutaye : /* Liste des tâches à effectuer */

__TOC__
 
==Cahier des charges==

Ce cahier des charges a pour objectif de définir le projet, ce qui est attendu ainsi que les contraintes de conception qui lui sont associées.

===Présentation générale du projet===

Le projet consiste à concevoir et développer un environnement virtuel de test pour l'Association de Robotique de Polytech Lille (ARPL). Ce simulateur doit reproduire les conditions de participation à la Logistic League de manière à pouvoir obtenir rapidement des données et tester le code ainsi que les stratégies de jeu utilisés par les robots.

====Contexte====
Ce simulateur est un outil développé dans le cadre de la RoboCup et plus particulièrement de la Logistic League. La RoboCup est une compétition internationale de robotique dans laquelle on voit beaucoup d'entreprises et de robots connus tel que NAO. Cette compétition a pour but de mettre en avant les évolutions en matière de robotique ainsi que les qualités des organismes participants.

La Logistic League est une des différentes épreuves proposées. L'objectif est de repérer le terrain puis de produire des objets avec différents éléments fournis par des machines et à livrer dans des plages de temps données. Une RefereeBox ou boîte arbitre sert à la coordination ainsi qu'à l'arbitrage. C'est cette boite qui va informer le robots des différents objets à construire avec la date de livraison demandée. Elle va également donner leur rôles aux machines présentes sur le terrain. L'arbitre va enregistrer les horaires de dépôt des objets et la position de chacune des machines lors de la compétition.

Celle-ci se déroule sur une piste de la taille d'une salle moyenne. Chaque équipe peut utiliser jusqu'à trois robots Robotino 3 pour réaliser les tâches demandées. Sur la piste, à part les robots, se trouvent seulement des machines dites de production ou de livraison. Elles vont servir soit à se procurer un élément nécessaire à la production de l'objet final soit à livrer celui-ci lorsqu'il est terminé.

====Objectif du projet====

Ce projet va permettre de fournir à l'équipe de l'ARPL un simulateur léger et complet, leur permettant de simuler en un court laps de temps un match entier ou partiel et de tester leur code et leur stratégie. Cela leur permettra de développer plus rapidement et efficacement.

====Description du projet====

Le simulateur devra répondre à un certain nombre de critères. Tout d'abord il lui faudra pouvoir simuler toutes les entités présentes sur la piste lors d'un match. Nous parlons des robots et des machines mais également des capteurs et des conditions de jeu.

Nous devrons faire en sorte que le simulateur puisse facilement intégrer le code de contrôle des robots afin de le tester. De plus il faut permettre à l'utilisateur de gérer les parties du code à tester ainsi que de changer les conditions et paramètres de simulation afin de ne tester que certaines partie du code (par exemple en excluant la gestion des collisions). Nous inclurons une gestion des phases de jeu (Découverte et Production) dans ce but. De ce point de vue l'idéal serait de générer un launchfile et de permettre à l'utilisateur de gérer l'utilisation des nœuds un par un.

En sus, le simulateur gérant les robots de l'équipe adverse, il aura une fonctionnalité de sauvegarde des configurations que ce soit pour le code ou les stratégies afin de comparer l'évolution des performances.

Le simulateur a certaines contraintes afin d'être utilisable et utile. Il doit opérer une compression du temps c'est à dire réaliser la simulation d'un match en moins de temps qu'une durée normale de match. Il s'agit d'obtenir des données représentant la réalité en un cours laps de temps. La communication avec la RefereeBox est indispensable. Celle-ci étant fourni par les organisateurs de la compétition nous n'avons pas à la simuler mais nous devons communiquer avec elle pour rendre la simulation plus réaliste.

====Choix techniques : matériel et logiciel====

Nous n'avons pas besoin de matériel hormis d'ordinateurs afin de programmer.

Dû à la compétition et aux choix de développement de l'équipe de l'ARPL, nous allons programmer en C++ avec les bibliothèques QT ainsi que le middleware ROS, une surcouche de programmation destinée à la programmation de robots.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

*Simuler les différentes entités
** les Robotinos ;
** les machines ;
** l'environnement.

*Gérer l'interfaçage entre le simulateur et le code des Robots
** lire et lancer le méta-paquet ;
** identifier les différents parties du code ;
** proposer l'activation/désactivation de ces parties et créer un launchfile en conséquence ;
** créer un système de sauvegarde de tout code interfacé permettant sa réutilisation.

*Simuler un match
** communiquer avec la RefereeBox et recevoir les différents ordres de celle-ci ;
** gérer les machines et la communication avec la RefereeBox ;
** gérer l'équipe de l'utilisateur et son interaction avec le reste de la simulation ;
** gérer l'équipe adverse et son interaction avec le reste de la simulation.

*Paramétrage avancé de la simulation
** proposer différents modes de simulations ;
** activation/désactivation des paramètres de la simulation ;
** gestion des phases.

*Interface utilisateur
** fournir des données utilisables et intéressantes sur la simulation ;
** créer une GUI ergonomique ;
** importer les données de la simulation sur la GUI pour une meilleure analyse de celle-ci.

====Calendrier====

Répartition du temps consacré au projet (120h/personne) :

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures supplémentaires !! Total
|-
| Définition cahier des charges
| 2
|
|
|
|
|
|
|
|
|
|
|
|2
|-
|Mise à niveau matérielle et intellectuelle
|
|13
|
|
|
|1
|
|
|
|
|
|
|14
|-
|Conception théorique
|
|5
|7
|4
|2
|
|
|0,5
|
|13
|2
|
|33.5
|-
|Programmation de la simulation
|
|
|8
|15
|16
|4
|8
|6
|10
|6
|10
|18
|101
|-
|Programmation de l'affichage avec rviz
|
|
|
|
|
|5
|8
|13
|6
|
|
|5
|37
|-
|Wiki
|
|
|0,5
|1,5
|1,5
|0,5
|2
|0,5
|3
|0,5
|0,5
|2
|12,5
|-
|Réunions tuteurs
|2
|
|
|
|2
|2
|
|
|
|
|
|
|6
|-
|Total
|4
|18
|15,5
|20,5
|21,5
|12,5
|18
|20
|19
|19,5
|12,5
|25
|206
|}

==Planning des tâches==

{| class="wikitable"
!Tâche !! Date prévue !! Avancement !! Commentaires
|-
| Affichage des formes avec Rviz
| 01/03/2017
| Terminé
| Cercle & Rectangle
|-
| Affichage d'un robot
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Affichage d'une machine
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Gestion du temps
| 08/03/2017
| Terminé
| Bornes de facteurs possibles à déterminer
|-
| Déplacement d'un robot
| 22/03/2017
| Terminé
| Vitesse et déplacement au point; Besoin d'interfaçage sur le code ARPL
|-
| Affichage de l'orientation de l'entité
| 13/03/2017
| Terminé
| Affichage d'une forme Flèche dont l'orientation change avec celle de l'entité. Grise. Orientation en degrés.
|-
| Lecture et affichage de la map
| 19/03/2017
| Terminé
| Affichage de la map, des murs et des zones interdites.
|-
| Communication RefBox
| 01/04/2017
| Inachevé
| Communication en place pour l'affichage des machines à leur position de départ.
|-
| Gestion Collision
| 01/04/2017
| Inachevé
| Implémentation de la fonction de regroupement
|}

==Avancement du Projet==

===Semaine 1===
Nous avons commencé par installer ROS et tout ce dont nous avons besoin pour travailler correctement. Nous avons également suivi des [http://wiki.ros.org/ROS/Tutorials tutoriels] pour apprendre à utiliser ROS.

Pour pouvoir travailler en binôme sans problèmes et pour que nos encadrants puissent suivre notre avancement et tester le logiciel, nous avons utilisé le logiciel de gestion de versions Git, sur lequel on publie notre code au fur et à mesure.

Nous n'avions pas encore de dépôt sur celui-ci, donc nous avons commencé par réfléchir à la structure de notre projet.
Nous commencerons par implémenter la phase d'exploration, ce qui comprend aussi le déplacement du robot, la détection de machines et de feux ainsi qu'une interface utilisateur basique.

En effet, le match oppose deux équipes ayant jusque trois robotinos qui s'affrontent lors de deux phases. La première est la phase d'exploration, durant laquelle les robots doivent trouver les machines de leur équipe en explorant le terrain. Ils doivent annoncer la position des machines et les signaux des feux de celles-ci : chaque machine, peu importe son type, possède un feu tricolore (rouge, jaune, vert) qui durant la phase d'exploration aura une combinaison de lumières allumées aléatoirement (au moins une doit l'être).

La création d'un simulateur passe par la réflexion sur les besoins en conception du simulateur (décris en partie ci-dessus). Nous avons donc passé un certain temps à schématiser la structure de notre simulateur et à en assimiler les besoins et l'ordre de création.

===Semaine 2===
Nous avons récupéré un dépôt Git (nommé ''logistic-sim'') sur lequel travailler auprès de nos encadrants, nous pouvons donc commencer la programmation cette semaine.

Ceci étant notre premier projet mêlant ROS et Git, nous avons tenté de créer la structure du projet mais avons vite rencontré quelques difficultés.
Nous avons ensuite compris qu'il était nécessaire de d'abord créer un environnement de travail ROS pour le projet, dans lequel on clône ensuite le dépôt Git localement.

Nous obtenons ainsi la structure de projet suivante :
* Workspace ROS
** build
** devel
** src
*** CMakeLists.txt
*** logistic-sim

Les dossiers build, devel, src et CMakeList.txt sont des fichiers et dossiers générés par ''Catkin'', un outil permettant de créer des paquets ROS facilement.

Nous avons ensuite décidé de séparer le code du projet en différents dossiers en fonction des tâches à effectuer :
* '''Entites''' pour simuler les différentes entités (Robotinos, machines, environnement...)
* '''Gestion_Code''' pour gérer l'interfaçage entre le simulateur et le code des robots
* '''Match''' pour simuler le déroulement d'un match
* '''GUI''' pour l'interface utilisateur avec le framework Qt

Dans chacun de ces dossiers, nous créerons des ''packages'' contenant les différentes fonctionnalités du projet.

Chaque ''package'' a la structure suivante :
* CMakeLists.txt
* include pour les fichiers .h
* package.xml
* README.md
* src pour les classes et nodes .cpp
* launch pour les launchfiles

Dans un premier temps, on commence par la gestion de la position du robot et la reconnaissance des feux.

===Semaine 3===

Nous avons avancé sur la programmation de la gestion de la position du robot et de la reconnaissance des feux.

Nous avons décrit nos classes par des schémas UML avec l'outil gratuit ''Modélio'' pour créer une documentation facilement accessible. Les commentaires des fonctions, classes et fichiers au format ''Doxygen'' nous permettront également de générer une documentation du projet sous format HTML notamment.

Nous suivons aussi la normalisation du code donnée par l'ARPL pour avoir les mêmes conventions de nommage partout.

Nous avons décidé de créer un nouveau package ''match'' qui contiendra les nœuds correspondants aux différentes phases de jeu, et avons donc par conséquent commencé par créer un nœud pour la phase d'exploration.

Nous avons également commencé à réfléchir à la façon dont les informations sont communiquées dans le match : il y a un arbitre, la ''Referee Box'' qui permet de faire communiquer le simulateur et les robots jouant le match. En effet, l'arbitre prend les décisions importantes (placement des machines au début du jeu etc.) et c'est à lui que les robots s'adressent. Nous devons donc aussi communiquer avec lui pour recevoir certaines informations (par exemple les informations de base de la phase d'exploration) et les retransmettre dans le simulateur aux nœuds qui en auront besoin.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v1.png|Schéma UML du package ''machine''
Fichier:Formes_package_Class_diagram_v1.png|Schéma UML du package ''formes''
</gallery>

===Semaine 4===

Cette semaine, nous avons créé plusieurs nouveaux packages et modifié ceux qui avaient déjà été créés.

Nous avons créé la classe Cercle dans le package ''formes'', nous pouvons donc maintenant utiliser deux formes différentes, le rectangle et le cercle.
La classe Entite a elle aussi été rajoutée. En effet, certains attributs des machines sont communs avec ceux des robots; cette classe nous permet de les rassembler et les classes Machine et Robot hériteront ainsi de Entite.

Un nouveau package ''management'' a également fait son apparition. Il contiendra les classes Equipe et Manager. Le Manager sera chargé de créer les équipes et permettra d'y accéder partout dans le code, mais aussi de procéder aux différentes initialisations lors du démarrage d'une nouvelle phase.

Au package ''management'' s'ajoute le nouveau package ''robot'' dont le rôle est de simuler les robotinos lors du match.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v2.png|Schéma UML du package ''machine''
Fichier:Robot_package_Class_diagram_v1.png|Schéma UML du package ''robot''
Fichier:Formes_package_Class_diagram_v2.png|Schéma UML du package ''formes''
Fichier:Management_package_Class_diagram_v1.png|Schéma UML du package ''management''
</gallery>

Nous avons également rendu visite à l'un de nos tuteurs de stage pendant la semaine dans le but d'obtenir un premier retour sur notre travail et l'avancement du projet.

Nous avons pu effectuer immédiatement quelques modifications nécessaires suite aux commentaires de notre tuteur. Nous avons dû, par exemple, clôner leur projet dans le même espace de travail que le notre pour pouvoir réutiliser certains paquets de messages déjà créés. Cela permettra une meilleure compatibilité. D'autres modifications concernaient entre autres les conventions de nommage de certaines classes et l'ajout d'un dossier supplémentaire dans le dossier include de chaque package portant le nom de celui-ci, pour ne pas avoir de conflits quant au nommage des fichiers.

Une réunion avec toute l'équipe des tuteurs a été prévue pour la semaine 5.

===Semaine 5===

La semaine a commencé par une réunion avec l'équipe de l'ARPL se chargeant d'encadrer notre projet, c'est-à-dire Vincent et Thomas. Nous avons discuté ensemble de l'avancement du simulateur et de l'ordre dans lequel effectuer les tâches. Ils nous également demandé de créer un planning de nos tâches avec la date prévue pour chacune; ils auront en effet besoin de modifier leur code à certains endroits pour pouvoir utiliser le simulateur (nous n'aurons pas besoin de tous les nœuds, certains comme la détection Laser nous étant inutiles) et souhaiteraient savoir lorsque nous seront prêt à tester de nouvelles fonctionnalités.

Nous nous sommes lancés dans l'affichage des formes avec l'outil ''rviz'', qui permet de visualiser en 3D les messages de type ''visualisation_msgs'' qui lui sont envoyés sur le topic associé. Ces messages sont disponibles en différents types. Pour afficher les formes nous utiliseront le format ''Marker'' qui permet d'afficher un objet en 3D (cubes, sphères, flèches, cylindres) ou en 2D en lui donnant un z de 0.

Nous avons donc commencé par faire les tutoriels sur l'utilisation de rviz puis par ajouter le code nécessaire à l'affichage des formes. Nous avons ainsi décidé d'ajouter la variable du message de type ''Marker'' dans la classe Forme; celle-ci sera accessible par toutes les classes filles de Forme, notamment Cercle et Rectangle. Nous avons également créé une méthode ''display'' qui sera chargée de mettre à jour la position de la forme et de publier le message. Les différents ''setters'' des classes filles modifieront également le message pour qu'il soit à jour lors de l'envoi.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_rectangle.png|Affichage de la forme ''Rectangle'' dans Rviz
Fichier:Rviz_screenshot_cercle.png|Affichage de la forme ''Cercle'' dans Rviz
</gallery>

===Semaine 6===

Cette semaine, nous continuons d'améliorer l'affichage en programmant cette fois-ci la classe ''Robot'' (qui possède une forme, étant une Entité) pour pouvoir visualiser le robot avec rviz. Nous avons donc ajouté une fonction ''display'' à ''Entite'', faisant elle-même appel à la fonction ''display'' de sa forme; ce qui permettra un affichage plus facile de l'objet.

Nous avons également ajouté une forme ''Texte'' pour afficher du texte informatif sur les formes (par exemple, une lettre et un id pour une entité, "R1" dans le cas du premier robot de chaque équipe). Ce texte est affiché en cyan ou en magenta, en fonction de la couleur de l'équipe. Les noms des ''markers'' de la forme et du texte eux aussi dépendent du type de l'entité.

Enfin, nous avons permis au entités de type Machine de gérer leur affichage. Pour cela, nous avons dû créer une classe fille de cette entité pour pouvoir tester son affichage. Le choix s'est porté sur les machines de type BS (Base Station).

En cours de route, nous avons été confrontés à un problème au niveau de l'affichage en 2D. Il semblait logique que la hauteur des objets (en z) soit égale à 0 pour un affichage 2D, mais il s'est avéré que la couleur de l'objet était alors imprévisible (plus souvent noir que de la bonne couleur). Il en fait fallu laisser une légère épaisseur (0.001 mètres dans notre cas) pour que la couleur s'affiche correctement.

Un de nos objectifs était aussi de gérer l'affichage de l'orientation de nos entités. En effet, cela semble essentiel pour les robots par exemple, représentés par des ronds et pouvant se déplacer. Nous avons ainsi créé un nouveau marker ''Fleche''; il était également possible de changer le type de marker en ''interactive marker'' ce qui aurait permis l'affichage de flèches de direction, mais celles-ci permettaient de modifier la position de l'objet et n'étaient disponibles qu'en multiple de 2 (déplacement sur un axe). Le choix s'est donc porté sur l'utilisation d'un marker classique dont on change l'orientation en même temps que celle de l'entité.
Nous avons rencontré quelques soucis quant à la gestion de l'orientation du marker, celle-ci étant un ''quaternion'' (x, y, z, w) alors que nous souhaitons donner l'angle en degrés (ou en radians éventuellement); la documentation n'est pas forcément facile à trouver pour ROS.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_robot.png|Affichage de l'entité ''Robot'' dans Rviz
Fichier:Rviz_screenshot_machine.png|Affichage de l'entité ''BaseStation'' dans Rviz
Fichier:Rviz_screenshot_fleche.png|Affichage de l'entité ''Robot'' avec une forme ''Fleche'' dans Rviz
</gallery>

Nous avons dû corriger nos constructeurs pour être le plus efficace possible et remplir au maximum les besoins des futurs fonctions.

La problématique rendant nécessaire une gestion du temps vient du besoin de l'ARPL de pouvoir contrôler la vitesse de simulation et donc de pouvoir jouer un match très rapidement afin d'observer le comportement de leur code.
Nous avons commencé et fini la gestion du temps. ROS intègre une interface de temps qui se cale sur la machine qui lance ROS.
Pour que plusieurs machines suivent le même temps il faut opérer une synchronisation des temps. Cependant lors de la simulation tous les robots auront leur référentiel temporel sur la même machine ce qui rend une synchronisation inutile.

Il existe un topic ''clock'' qui sert pour les simulations. En forçant nos nœuds à utiliser le temps de simulation, nous avons une échelle temporelle utilisable et synchronisée. Nous avons donc un nœud qui va publier sur ce topic le temps qui sera initialisé à 0 en début de match.

Un paramètre d'environnement ROS sert à régler le facteur d'accélération de la simulation par rapport au temps réel. Il est modifiable à tout instant et est initialisé en premier dans le launchfile.

===Semaine 7===

Nous nous sommes attaqués à l'affichage du terrain dans rviz.

Pour cela, nous pouvions nous inspirer de code écrit par l'ARPL permettant de charger une carte depuis un fichier ''.yaml''. Certains de leurs packages nous ont été utiles, mais d'autres se sont avérés inutilisables tels quels à cause d'erreurs tantôt de "référence indéfinie" à un fichier, tantôt de "redéfinition" du même fichier (la cause de ces erreurs reste pour le moment toujours un mystère).
Nous avons donc opté, pour pouvoir avancer rapidement sur le projet, d'utiliser tel quel ce qu'il était possible d'utiliser, et sinon de recopier les fonctions nécessaires dans notre package. Certaines fonctions nécessitaient d'ailleurs de toute façon des modifications, car dans notre simulateur nous gérons aussi l'affichage de la carte alors qu'eux ne faisaient que la charger.

Un fichier ''.yaml'' a la syntaxe suivante :
field:
name: robocup_simulator
size: [14, 9, 0.0]
gradient:
distance: 0.35
minValue: 0
walls:
bottom1:
start: [-6, 0, 0.0]
end: [-4, 0, 0.0]

Nous avons donc commencé par charger le fichier en mémoire en le passant en paramètre à un ''launchfile'' lançant le nœud chargé de lire et d'afficher la carte. Ensuite, en faisant appel à des ''param'' (paramètres) du nœud actuel et en leur donnant le nom du champs (''name'' par exemple), on peut récupérer les valeurs du fichiers voulues.

Nous avons ainsi créé une classe ''Carte'' pour gérer le chargement des données depuis le fichier et toutes les fonctions utilitaires associées, mais permettant aussi d'afficher la carte grâce à une fonction ''display'' de même fonctionnement que celles créées précédemment pour les entités.

Pour l'affichage sur rviz, nous nous sommes servis du type d'objet ''Map'' pour visualiser le sol du terrain (en blanc ci-dessous). Nous avons également créé un vecteur de Rectangles pour afficher les murs (en bleu foncé ci-dessous) et un vecteur de Rectangles pour les zones interdites au robot (en noir).

Nous aurions aimé mettre à jour la taille de la grille affichée en fonction de la taille de la carte, mais il s'avère que c'est impossible, la grille ne provenant pas d'un message publié.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_map.png|Affichage du terrain de jeu dans Rviz
</gallery>

===Semaine 8===

Nous avons complété la fonction de gestion de la vitesse. Il n'y a plus de nœud pour gérer les déplacements au profit d'un nœud gérant chaque robot.
Les robots envoient un vecteur "twist" pour donner leur commande vitesse, soit deux vecteurs vitesse 3D, l'un pour la vitesse linéaire et l'autre pour la vitesse angulaire.
Cependant ce vecteur vitesse est paramétré dans le repère du robot, c'est-à-dire avec le vecteur x dirigé dans la direction de l'orientation du robot.
Pour nos calculs nous nous servons du repère originel, que ce soit pour placer les entités ou les déplacer. Cela facilite les calculs dans la simulation.
Ainsi nous devons transposer les vecteurs vitesse reçus pour les appliquer à notre repère.

La simulation fonctionnant en 2D nous simplifions les données en utilisant un seul vecteur 3D (x et y pour le déplacement linéaire et z pour le changement d'orientation soit la vitesse angulaire autour de l'axe z).
La transposition n'est nécessaire que pour les déplacements linéaires, donc nous utilisons de la trigonométrie simple et nous ajoutons le déplacement ainsi obtenu à la position actuelle, ce qui donne :

v_x = v_x1*cos(orientation_radian) - v_y1*sin(orientation_radian)

v_y = v_x1*sin(orientation_radian) + v_y1*sin(orientation_radian)

x_new = v_x *delta_t + x

y_new = v_y *delta_t + y

orientation_new = (v_angulaire*delta_t + orientation) [360]

Nous avons également apporté des modifications aux flèches et textes; en effet, maintenant que le déplacement des robots est possible, nous pouvons effectuer des tests.
Il s'avère que nous ne modifions pas la position des flèches et textes, le robot s'éloignait alors d'eux lorsqu'il se déplaçait.
Nous avons donc ajouté les quelques modifications nécessaires pour que ces formes suivent l'entité en déplacement.

Nous avons aussi commencé à compléter le package ''machine'' pour lui ajouter les sous-classes de Machine représentant les différentes machines (MPS) du jeu (BaseStation, CapStation, RingStation, DeliveryStation).
La BaseStation permettra au robot de récupérer un objet de type base, la RingStation d'y empiler des anneaux de couleurs différentes en fonction des commandes reçues, la CapStation de déposer un chapeau au sommet de l'objet et enfin on l'apporte à la DeliveryStation.

Nous avons complété ci-dessous les schémas UML du projet dans son état actuel :

<gallery style="margin: 0 auto;">
Fichier:Formes_package_Class_diagram_v3.png|Schéma UML du package ''formes''
Fichier:Machine_package_Class_diagram_v3.png|Schéma UML du package ''machine''
Fichier:Management_package_Class_diagram_v2.png|Schéma UML du package ''management''
Fichier:Robot_package_Class_diagram_v2.png|Schéma UML du package ''robot''
</gallery>

===Semaine 9===

Nous avons dû concevoir une fonction de récupération de distance entre deux entités.
Les robots étant les seules entités mobiles, nous ne calculons que la distance entre un robot et une autre entité.
La distance entre deux robots, soit deux cercles, est facile à déterminer. Nous récupérons les points des deux cercles étant sur la droite passant par les centres des dits cercles. Puis nous appliquons le calcul de distance.

Lorsqu'il s'agit de calculer la distance la plus courte avec un rectangle, c'est un peu plus compliqué et très rapidement le nombre de calculs devient très grand. Nous avons choisi une stratégie calculatoire réduisant le nombre de calculs avec les conseils de Mme Nathalie Delfosse.

Le problème est de trouver la distance la plus courte entre les deux formes ainsi que les points concernés.

[[Fichier:GD_1.png|500px|center|texte descriptif]]

Nous pouvons facilement tracer la zone de collision, soit la zone qui permet de dire qu'il y a une collision si le centre du robot est dessus.

[[Fichier:GD_2.png|500px|center|texte descriptif]]

Ensuite on découpe l'espace en 8 zones en prolongeant les cotés du rectangle pour en faire des droites.

[[Fichier:GD_3.png|500px|center|texte descriptif]]

Lorsqu'un robot se situe en zone n°1 alors la distance la plus proche est celle qui sépare le cercle de l'angle le plus proche du rectangle. Donc (S2) est cette distance avec la résolution du système composé de la droite par le centre du cercle et l'angle, et le cercle. Nous obtenons alors le point du cercle le plus proche du rectangle.

(S2)
(x−xc)²+(y−yc)²==R²
y= ax+b

Dans la zone n°2, la distance la plus courte est une droite verticale, ce qui nous donne facilement le point du cercle et le point du rectangle.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Dans la zone n°3, on observe le même comportement qu'avec la zone n°2 mais cette fois-ci à l'horizontal, les équations sont donc les mêmes avec une inversion des x en y et inversement.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Cette semaine nous avons aussi travaillé sur la production elle-même en complétant les classes du package ''machine''. Nous avons ainsi ajouté à chaque sous-classe une fonction ''setup'' qui permet d'initialiser la machine, la plupart du temps avec une couleur d'anneau ou de base, et pour la ''DeliveryStation'' avec un numéro de porte.

Ces fonctions seront ensuite appelées dans un nœud ''machines_node'' du package ''management''.

===Semaine 10===

Cette semaine, nous avons avancé sur la simulation en permettant à une 'Equipe' d'afficher ses six machines et ses trois robots. Le ''Manager'', lui, affiche les deux équipes; nous avons ainsi tous les acteurs d'un match sur le même terrain.

Nous avons également installé la Referee Box, dans la prévision du travail sur la communication entre simulation et celle-ci, mais aussi pour pouvoir utiliser des types de messages particuliers du package ''llsf_msgs'' inclus avec la Referee Box.

En effet, les machines changent d'état en fonction des commandes qu'elles reçoivent. En effet, les équipes doivent remplir des commandes tout au long du match, et les robots ordonnent ainsi aux machines de produire des types de pièces particuliers.
Ils commencent par envoyer un message de ''setup'' qui va indiquer à la machine quel type de pièce préparer. À ce moment là la machine change d'état (état occupé) et ceci est reflété dans la couleur de son feu.
Lorsque la pièce est disponible, la machine rechange d'état pour être de nouveau disponible.

Il existe également d'autres types d'états, comme lorsque la machine est ''down'' lors d'une maintenance programmée décidée par la Referee Box au début du match, lorsque la machine vient de recevoir un ordre ou encore lorsqu'un robot tente de l'utiliser sans lui envoyer de message de ''setup'', elle est alors hors-service pendant un certain moment.

Lié à la Referee Box, nous avons dû chercher à synchroniser le temps de celle-ci avec le simulateur. Cependant, en observant le code du simulateur Gazebo (actuellement non fonctionnel) et la manière de communiquer avec l'arbitre, nous avons conclu que nous n'avions pas le temps de le faire.

Nous avons dû implémenter le système de gestion de collisions. Graphiquement et avec les équations, il est simple pour un être humain de comprendre le fonctionnement. Cependant le code impose plus de restriction. Nous avons donc décomposé la théorie en plusieurs morceaux. Une fonction pour obtenir la distance entre deux points, plusieurs fonctions permettant de déterminer les points les plus proches entre chaque structure, et enfin une fonction déterminant s'il y a collision.

Pour les cercles, il faut déterminer l'équation de la droite qui passe par le centre des deux cercles puis résoudre le système correspondant à l'intersection de la droite et du cercle qui nous donne une équation du second degré. On choisit alors le point le plus proche de l'autre cercle.

Pour un cercle et un rectangle, on teste zone par zone. Nous ne sommes pas obligés de nous placer dans le référentiel du rectangle. Au lieu de cela, nous allons vérifier zone par zone l'appartenance du cercle à celles-ci grâce aux systèmes composés de trois droites (les cotés du rectangles) pour les zones latérales et de deux pour les zones d'angles. Ces systèmes s'excluent les uns les autres. Si le cercle n'est dans aucune zone alors il est à l'intérieur du rectangle. Ce qui est soit une situation impossible, soit une collision. Lorsque l'on a la zone, on résout le système correspondant (décrit lors de la semaine 9). Cette implémentation n'a pas été faite entièrement durant cette semaine. Nous l'avons continué lors du temps supplémentaire.

===Heures supplémentaires===

Nous avons commencé par ajouter l'affichage des feux (composés d'un rectangle et de trois cercles rouge, jaune, vert).
En fonction de l'état de la machine à laquelle ils appartiennent, les couleurs affichés changent. D'après le règlement, si tout va bien le feu sera vert fixe, si la machine est occupée il sera jaune fixe et si la machine est en maintenance programmée il sera rouge fixe. Si la machine vient de recevoir un ordre, il sera vert clignotant et si elle est hors-service il sera clignotant jaune et rouge.

C'est pourquoi nous avons aussi implémenté le clignotement de celui-ci qu'il est possible de voir dans la vidéo ci-dessous.

Enfin, les machines seront positionnées de différentes manières au début d'un match, il est donc nécessaire que le feu associé ait la même rotation que sa machine.
Nous avons ainsi commencé par permettre aux cercles du haut et du bas d'effectuer un rotation autour du cercle central. Une fois la chose faite, nous avons modifié la rotation d'une machine. En effet, jusque là elle était implémentée de la même manière que pour les robots, or ceux-ci se déplacent et pas notre machine. Il n'est donc pas nécessaire que la flèche soit en rotation mais plutôt qu'elle soit positionnée de manière fixe (mais cela reste modifiable dans le code) et que ce soit le rectangle de la machine qui effectue une rotation sur lui-même. Il en va de même pour le rectangle du feu.

Enfin, nous avons dû gérer le positionnement du feu par rapport au rectangle : il faut, lorsque la machine effectue une rotation, calculer la position de son coin inférieur gauche et positionner le feu par rapport à celui-ci.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_feu_45_degres.png|Feu en rotation
Fichier:Rviz_screenshot_machine_135_degres.png|Machine et son feu en rotation
Fichier:Rviz_screenshot_machine_state_down.png|Machine en état de maintenance programmée
Fichier:Rviz_screenshot_machine_state_busy.png|Machine occupée
Fichier:Rviz_screenshot_machine_state_ok.png|Machine disponible
Fichier:Feu_clignotant.mp4|Vidéo du feu qui clignote
</gallery>

La classe Manager a été transformée en Singleton. C'est un ''pattern'' de programmation permettant de n'instancier une classe qu'en un seul exemplaire unique accessible partout dans le programme. Dans notre cas, cela est particulièrement utile car le Manager permet de gérer les équipes et leurs états. On a seulement besoin d'instancier les équipes du Manager une seule fois au début du Match, et pas à chaque fois qu'on souhaite y accéder.

Nous avons aussi débuté la communication avec la RefereeBox. Il y a trois modes de communication avec celle-ci : en tant que "pair" (communication UDP) sur un canal public, idem sur un canal privé ou en tant que "contrôleur" (communication TCP).
Dans notre cas, c'est le mode "contrôleur" qui nous intéresse : en effet, nous devons avoir accès à toutes les informations de l'arbitre pour pouvoir réaliser une simulation correcte, et seul la communication en TCP le permet. En UDP sur canal public, seul un nombre très limité d'informations est disponible et sur canal privé les informations sont cryptées pour les cacher à l'autre équipe.

Nous avons donc pour cela, après avoir réalisé l'installation de la RefereeBox avec le projet ''llsf-refbox'' dont nous avons parlé semaine 10, créé une classe ''ClientTCP'' d'après un exemple inclus dans le projet installé. Le client s'inscrit comme devant recevoir certains types de messages, par exemple le message de type ''llsf_msgs::MachineInfo'', qui permet d'obtenir les positions des machines et leur état. Ensuite, lorsqu'il reçoit un nouveau message, on vérifie de quel type il s'agit et on agit en conséquence. Dans l'exemple précédent, on appelle ainsi une fonction d'initialisation de la position des machines une unique fois après la réception d'un message de type MachineInfo, lorsque le Manager est initialisé mais que les positions des machines ne le sont pas. Cette fonction prenant en paramètre le message reçu, on n'a plus qu'à changer les différentes valeurs nécessaires.

Pour tester cela, nous avons utilisé la Refbox. Pour la démarrer, il faut se trouver dans le dossier ''llsf-refbox/bin'' et exécuter deux scripts; d'abord
''llsf-refbox'' pour la démarrer puis ''llsf-refbox-shell'' pour voir une interface graphique de gestion apparaître dans le terminal.

De la façon dont nous avons réalisé le projet, il est nécessaire de créer dans son ''bashrc'' une variable d'environnement ROBOCUP_DIR qui correspond au répertoire ROS qui contient le projet et la Referee Box. Celle-ci permet d'utiliser les messages du package ''llsf_msgs''.

== Fichiers Rendus ==

IMA4 2016/2017 P20

2017-05-09T22:01:00Z

Mbutaye : /* Semaine 10 */

__TOC__
 
==Cahier des charges==

Ce cahier des charges a pour objectif de définir le projet, ce qui est attendu ainsi que les contraintes de conception qui lui sont associées.

===Présentation générale du projet===

Le projet consiste à concevoir et développer un environnement virtuel de test pour l'Association de Robotique de Polytech Lille (ARPL). Ce simulateur doit reproduire les conditions de participation à la Logistic League de manière à pouvoir obtenir rapidement des données et tester le code ainsi que les stratégies de jeu utilisés par les robots.

====Contexte====
Ce simulateur est un outil développé dans le cadre de la RoboCup et plus particulièrement de la Logistic League. La RoboCup est une compétition internationale de robotique dans laquelle on voit beaucoup d'entreprises et de robots connus tel que NAO. Cette compétition a pour but de mettre en avant les évolutions en matière de robotique ainsi que les qualités des organismes participants.

La Logistic League est une des différentes épreuves proposées. L'objectif est de repérer le terrain puis de produire des objets avec différents éléments fournis par des machines et à livrer dans des plages de temps données. Une RefereeBox ou boîte arbitre sert à la coordination ainsi qu'à l'arbitrage. C'est cette boite qui va informer le robots des différents objets à construire avec la date de livraison demandée. Elle va également donner leur rôles aux machines présentes sur le terrain. L'arbitre va enregistrer les horaires de dépôt des objets et la position de chacune des machines lors de la compétition.

Celle-ci se déroule sur une piste de la taille d'une salle moyenne. Chaque équipe peut utiliser jusqu'à trois robots Robotino 3 pour réaliser les tâches demandées. Sur la piste, à part les robots, se trouvent seulement des machines dites de production ou de livraison. Elles vont servir soit à se procurer un élément nécessaire à la production de l'objet final soit à livrer celui-ci lorsqu'il est terminé.

====Objectif du projet====

Ce projet va permettre de fournir à l'équipe de l'ARPL un simulateur léger et complet, leur permettant de simuler en un court laps de temps un match entier ou partiel et de tester leur code et leur stratégie. Cela leur permettra de développer plus rapidement et efficacement.

====Description du projet====

Le simulateur devra répondre à un certain nombre de critères. Tout d'abord il lui faudra pouvoir simuler toutes les entités présentes sur la piste lors d'un match. Nous parlons des robots et des machines mais également des capteurs et des conditions de jeu.

Nous devrons faire en sorte que le simulateur puisse facilement intégrer le code de contrôle des robots afin de le tester. De plus il faut permettre à l'utilisateur de gérer les parties du code à tester ainsi que de changer les conditions et paramètres de simulation afin de ne tester que certaines partie du code (par exemple en excluant la gestion des collisions). Nous inclurons une gestion des phases de jeu (Découverte et Production) dans ce but. De ce point de vue l'idéal serait de générer un launchfile et de permettre à l'utilisateur de gérer l'utilisation des nœuds un par un.

En sus, le simulateur gérant les robots de l'équipe adverse, il aura une fonctionnalité de sauvegarde des configurations que ce soit pour le code ou les stratégies afin de comparer l'évolution des performances.

Le simulateur a certaines contraintes afin d'être utilisable et utile. Il doit opérer une compression du temps c'est à dire réaliser la simulation d'un match en moins de temps qu'une durée normale de match. Il s'agit d'obtenir des données représentant la réalité en un cours laps de temps. La communication avec la RefereeBox est indispensable. Celle-ci étant fourni par les organisateurs de la compétition nous n'avons pas à la simuler mais nous devons communiquer avec elle pour rendre la simulation plus réaliste.

====Choix techniques : matériel et logiciel====

Nous n'avons pas besoin de matériel hormis d'ordinateurs afin de programmer.

Dû à la compétition et aux choix de développement de l'équipe de l'ARPL, nous allons programmer en C++ avec les bibliothèques QT ainsi que le middleware ROS, une surcouche de programmation destinée à la programmation de robots.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

*Simuler les différentes entités
** les Robotinos ;
** les machines ;
** l'environnement.

*Gérer l'interfaçage entre le simulateur et le code des Robots
** lire et lancer le méta-paquet ;
** identifier les différents parties du code ;
** proposer l'activation/désactivation de ces parties et créer un launchfile en conséquence ;
** créer un système de sauvegarde de tout code interfacé permettant sa réutilisation.

*Simuler un match
** communiquer avec la RefereeBox et recevoir les différents ordres de celle-ci ;
** gérer les machines et la communication avec la RefereeBox ;
** gérer l'équipe de l'utilisateur et son interaction avec le reste de la simulation ;
** gérer l'équipe adverse et son interaction avec le reste de la simulation.

*Paramétrage avancé de la simulation
** proposer différents modes de simulations ;
** activation/déssactivation des paramètres de la simulation ;
** gestion des phases.

*Interface utilisateur
** fournir des données utilisables et intéressantes sur la simulation ;
** créer une GUI ergonomique ;
** importer les données de la simulation sur la GUI pour une meilleure analyse de celle-ci.

====Calendrier====

Répartition du temps consacré au projet (120h/personne) :

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures supplémentaires !! Total
|-
| Définition cahier des charges
| 2
|
|
|
|
|
|
|
|
|
|
|
|2
|-
|Mise à niveau matérielle et intellectuelle
|
|13
|
|
|
|1
|
|
|
|
|
|
|14
|-
|Conception théorique
|
|5
|7
|4
|2
|
|
|0,5
|
|13
|2
|
|33.5
|-
|Programmation de la simulation
|
|
|8
|15
|16
|4
|8
|6
|10
|6
|10
|18
|101
|-
|Programmation de l'affichage avec rviz
|
|
|
|
|
|5
|8
|13
|6
|
|
|5
|37
|-
|Wiki
|
|
|0,5
|1,5
|1,5
|0,5
|2
|0,5
|3
|0,5
|0,5
|2
|12,5
|-
|Réunions tuteurs
|2
|
|
|
|2
|2
|
|
|
|
|
|
|6
|-
|Total
|4
|18
|15,5
|20,5
|21,5
|12,5
|18
|20
|19
|19,5
|12,5
|25
|206
|}

==Planning des tâches==

{| class="wikitable"
!Tâche !! Date prévue !! Avancement !! Commentaires
|-
| Affichage des formes avec Rviz
| 01/03/2017
| Terminé
| Cercle & Rectangle
|-
| Affichage d'un robot
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Affichage d'une machine
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Gestion du temps
| 08/03/2017
| Terminé
| Bornes de facteurs possibles à déterminer
|-
| Déplacement d'un robot
| 22/03/2017
| Terminé
| Vitesse et déplacement au point; Besoin d'interfaçage sur le code ARPL
|-
| Affichage de l'orientation de l'entité
| 13/03/2017
| Terminé
| Affichage d'une forme Flèche dont l'orientation change avec celle de l'entité. Grise. Orientation en degrés.
|-
| Lecture et affichage de la map
| 19/03/2017
| Terminé
| Affichage de la map, des murs et des zones interdites.
|-
| Communication RefBox
| 01/04/2017
| Inachevé
| Communication en place pour l'affichage des machines à leur position de départ.
|-
| Gestion Collision
| 01/04/2017
| Inachevé
| Implémentation de la fonction de regroupement
|}

==Avancement du Projet==

===Semaine 1===
Nous avons commencé par installer ROS et tout ce dont nous avons besoin pour travailler correctement. Nous avons également suivi des [http://wiki.ros.org/ROS/Tutorials tutoriels] pour apprendre à utiliser ROS.

Pour pouvoir travailler en binôme sans problèmes et pour que nos encadrants puissent suivre notre avancement et tester le logiciel, nous avons utilisé le logiciel de gestion de versions Git, sur lequel on publie notre code au fur et à mesure.

Nous n'avions pas encore de dépôt sur celui-ci, donc nous avons commencé par réfléchir à la structure de notre projet.
Nous commencerons par implémenter la phase d'exploration, ce qui comprend aussi le déplacement du robot, la détection de machines et de feux ainsi qu'une interface utilisateur basique.

En effet, le match oppose deux équipes ayant jusque trois robotinos qui s'affrontent lors de deux phases. La première est la phase d'exploration, durant laquelle les robots doivent trouver les machines de leur équipe en explorant le terrain. Ils doivent annoncer la position des machines et les signaux des feux de celles-ci : chaque machine, peu importe son type, possède un feu tricolore (rouge, jaune, vert) qui durant la phase d'exploration aura une combinaison de lumières allumées aléatoirement (au moins une doit l'être).

La création d'un simulateur passe par la réflexion sur les besoins en conception du simulateur (décris en partie ci-dessus). Nous avons donc passé un certain temps à schématiser la structure de notre simulateur et à en assimiler les besoins et l'ordre de création.

===Semaine 2===
Nous avons récupéré un dépôt Git (nommé ''logistic-sim'') sur lequel travailler auprès de nos encadrants, nous pouvons donc commencer la programmation cette semaine.

Ceci étant notre premier projet mêlant ROS et Git, nous avons tenté de créer la structure du projet mais avons vite rencontré quelques difficultés.
Nous avons ensuite compris qu'il était nécessaire de d'abord créer un environnement de travail ROS pour le projet, dans lequel on clône ensuite le dépôt Git localement.

Nous obtenons ainsi la structure de projet suivante :
* Workspace ROS
** build
** devel
** src
*** CMakeLists.txt
*** logistic-sim

Les dossiers build, devel, src et CMakeList.txt sont des fichiers et dossiers générés par ''Catkin'', un outil permettant de créer des paquets ROS facilement.

Nous avons ensuite décidé de séparer le code du projet en différents dossiers en fonction des tâches à effectuer :
* '''Entites''' pour simuler les différentes entités (Robotinos, machines, environnement...)
* '''Gestion_Code''' pour gérer l'interfaçage entre le simulateur et le code des robots
* '''Match''' pour simuler le déroulement d'un match
* '''GUI''' pour l'interface utilisateur avec le framework Qt

Dans chacun de ces dossiers, nous créerons des ''packages'' contenant les différentes fonctionnalités du projet.

Chaque ''package'' a la structure suivante :
* CMakeLists.txt
* include pour les fichiers .h
* package.xml
* README.md
* src pour les classes et nodes .cpp
* launch pour les launchfiles

Dans un premier temps, on commence par la gestion de la position du robot et la reconnaissance des feux.

===Semaine 3===

Nous avons avancé sur la programmation de la gestion de la position du robot et de la reconnaissance des feux.

Nous avons décrit nos classes par des schémas UML avec l'outil gratuit ''Modélio'' pour créer une documentation facilement accessible. Les commentaires des fonctions, classes et fichiers au format ''Doxygen'' nous permettront également de générer une documentation du projet sous format HTML notamment.

Nous suivons aussi la normalisation du code donnée par l'ARPL pour avoir les mêmes conventions de nommage partout.

Nous avons décidé de créer un nouveau package ''match'' qui contiendra les nœuds correspondants aux différentes phases de jeu, et avons donc par conséquent commencé par créer un nœud pour la phase d'exploration.

Nous avons également commencé à réfléchir à la façon dont les informations sont communiquées dans le match : il y a un arbitre, la ''Referee Box'' qui permet de faire communiquer le simulateur et les robots jouant le match. En effet, l'arbitre prend les décisions importantes (placement des machines au début du jeu etc.) et c'est à lui que les robots s'adressent. Nous devons donc aussi communiquer avec lui pour recevoir certaines informations (par exemple les informations de base de la phase d'exploration) et les retransmettre dans le simulateur aux nœuds qui en auront besoin.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v1.png|Schéma UML du package ''machine''
Fichier:Formes_package_Class_diagram_v1.png|Schéma UML du package ''formes''
</gallery>

===Semaine 4===

Cette semaine, nous avons créé plusieurs nouveaux packages et modifié ceux qui avaient déjà été créés.

Nous avons créé la classe Cercle dans le package ''formes'', nous pouvons donc maintenant utiliser deux formes différentes, le rectangle et le cercle.
La classe Entite a elle aussi été rajoutée. En effet, certains attributs des machines sont communs avec ceux des robots; cette classe nous permet de les rassembler et les classes Machine et Robot hériteront ainsi de Entite.

Un nouveau package ''management'' a également fait son apparition. Il contiendra les classes Equipe et Manager. Le Manager sera chargé de créer les équipes et permettra d'y accéder partout dans le code, mais aussi de procéder aux différentes initialisations lors du démarrage d'une nouvelle phase.

Au package ''management'' s'ajoute le nouveau package ''robot'' dont le rôle est de simuler les robotinos lors du match.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v2.png|Schéma UML du package ''machine''
Fichier:Robot_package_Class_diagram_v1.png|Schéma UML du package ''robot''
Fichier:Formes_package_Class_diagram_v2.png|Schéma UML du package ''formes''
Fichier:Management_package_Class_diagram_v1.png|Schéma UML du package ''management''
</gallery>

Nous avons également rendu visite à l'un de nos tuteurs de stage pendant la semaine dans le but d'obtenir un premier retour sur notre travail et l'avancement du projet.

Nous avons pu effectuer immédiatement quelques modifications nécessaires suite aux commentaires de notre tuteur. Nous avons dû, par exemple, clôner leur projet dans le même espace de travail que le notre pour pouvoir réutiliser certains paquets de messages déjà créés. Cela permettra une meilleure compatibilité. D'autres modifications concernaient entre autres les conventions de nommage de certaines classes et l'ajout d'un dossier supplémentaire dans le dossier include de chaque package portant le nom de celui-ci, pour ne pas avoir de conflits quant au nommage des fichiers.

Une réunion avec toute l'équipe des tuteurs a été prévue pour la semaine 5.

===Semaine 5===

La semaine a commencé par une réunion avec l'équipe de l'ARPL se chargeant d'encadrer notre projet, c'est-à-dire Vincent et Thomas. Nous avons discuté ensemble de l'avancement du simulateur et de l'ordre dans lequel effectuer les tâches. Ils nous également demandé de créer un planning de nos tâches avec la date prévue pour chacune; ils auront en effet besoin de modifier leur code à certains endroits pour pouvoir utiliser le simulateur (nous n'aurons pas besoin de tous les nœuds, certains comme la détection Laser nous étant inutiles) et souhaiteraient savoir lorsque nous seront prêt à tester de nouvelles fonctionnalités.

Nous nous sommes lancés dans l'affichage des formes avec l'outil ''rviz'', qui permet de visualiser en 3D les messages de type ''visualisation_msgs'' qui lui sont envoyés sur le topic associé. Ces messages sont disponibles en différents types. Pour afficher les formes nous utiliseront le format ''Marker'' qui permet d'afficher un objet en 3D (cubes, sphères, flèches, cylindres) ou en 2D en lui donnant un z de 0.

Nous avons donc commencé par faire les tutoriels sur l'utilisation de rviz puis par ajouter le code nécessaire à l'affichage des formes. Nous avons ainsi décidé d'ajouter la variable du message de type ''Marker'' dans la classe Forme; celle-ci sera accessible par toutes les classes filles de Forme, notamment Cercle et Rectangle. Nous avons également créé une méthode ''display'' qui sera chargée de mettre à jour la position de la forme et de publier le message. Les différents ''setters'' des classes filles modifieront également le message pour qu'il soit à jour lors de l'envoi.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_rectangle.png|Affichage de la forme ''Rectangle'' dans Rviz
Fichier:Rviz_screenshot_cercle.png|Affichage de la forme ''Cercle'' dans Rviz
</gallery>

===Semaine 6===

Cette semaine, nous continuons d'améliorer l'affichage en programmant cette fois-ci la classe ''Robot'' (qui possède une forme, étant une Entité) pour pouvoir visualiser le robot avec rviz. Nous avons donc ajouté une fonction ''display'' à ''Entite'', faisant elle-même appel à la fonction ''display'' de sa forme; ce qui permettra un affichage plus facile de l'objet.

Nous avons également ajouté une forme ''Texte'' pour afficher du texte informatif sur les formes (par exemple, une lettre et un id pour une entité, "R1" dans le cas du premier robot de chaque équipe). Ce texte est affiché en cyan ou en magenta, en fonction de la couleur de l'équipe. Les noms des ''markers'' de la forme et du texte eux aussi dépendent du type de l'entité.

Enfin, nous avons permis au entités de type Machine de gérer leur affichage. Pour cela, nous avons dû créer une classe fille de cette entité pour pouvoir tester son affichage. Le choix s'est porté sur les machines de type BS (Base Station).

En cours de route, nous avons été confrontés à un problème au niveau de l'affichage en 2D. Il semblait logique que la hauteur des objets (en z) soit égale à 0 pour un affichage 2D, mais il s'est avéré que la couleur de l'objet était alors imprévisible (plus souvent noir que de la bonne couleur). Il en fait fallu laisser une légère épaisseur (0.001 mètres dans notre cas) pour que la couleur s'affiche correctement.

Un de nos objectifs était aussi de gérer l'affichage de l'orientation de nos entités. En effet, cela semble essentiel pour les robots par exemple, représentés par des ronds et pouvant se déplacer. Nous avons ainsi créé un nouveau marker ''Fleche''; il était également possible de changer le type de marker en ''interactive marker'' ce qui aurait permis l'affichage de flèches de direction, mais celles-ci permettaient de modifier la position de l'objet et n'étaient disponibles qu'en multiple de 2 (déplacement sur un axe). Le choix s'est donc porté sur l'utilisation d'un marker classique dont on change l'orientation en même temps que celle de l'entité.
Nous avons rencontré quelques soucis quant à la gestion de l'orientation du marker, celle-ci étant un ''quaternion'' (x, y, z, w) alors que nous souhaitons donner l'angle en degrés (ou en radians éventuellement); la documentation n'est pas forcément facile à trouver pour ROS.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_robot.png|Affichage de l'entité ''Robot'' dans Rviz
Fichier:Rviz_screenshot_machine.png|Affichage de l'entité ''BaseStation'' dans Rviz
Fichier:Rviz_screenshot_fleche.png|Affichage de l'entité ''Robot'' avec une forme ''Fleche'' dans Rviz
</gallery>

Nous avons dû corriger nos constructeurs pour être le plus efficace possible et remplir au maximum les besoins des futurs fonctions.

La problématique rendant nécessaire une gestion du temps vient du besoin de l'ARPL de pouvoir contrôler la vitesse de simulation et donc de pouvoir jouer un match très rapidement afin d'observer le comportement de leur code.
Nous avons commencé et fini la gestion du temps. ROS intègre une interface de temps qui se cale sur la machine qui lance ROS.
Pour que plusieurs machines suivent le même temps il faut opérer une synchronisation des temps. Cependant lors de la simulation tous les robots auront leur référentiel temporel sur la même machine ce qui rend une synchronisation inutile.

Il existe un topic ''clock'' qui sert pour les simulations. En forçant nos nœuds à utiliser le temps de simulation, nous avons une échelle temporelle utilisable et synchronisée. Nous avons donc un nœud qui va publier sur ce topic le temps qui sera initialisé à 0 en début de match.

Un paramètre d'environnement ROS sert à régler le facteur d'accélération de la simulation par rapport au temps réel. Il est modifiable à tout instant et est initialisé en premier dans le launchfile.

===Semaine 7===

Nous nous sommes attaqués à l'affichage du terrain dans rviz.

Pour cela, nous pouvions nous inspirer de code écrit par l'ARPL permettant de charger une carte depuis un fichier ''.yaml''. Certains de leurs packages nous ont été utiles, mais d'autres se sont avérés inutilisables tels quels à cause d'erreurs tantôt de "référence indéfinie" à un fichier, tantôt de "redéfinition" du même fichier (la cause de ces erreurs reste pour le moment toujours un mystère).
Nous avons donc opté, pour pouvoir avancer rapidement sur le projet, d'utiliser tel quel ce qu'il était possible d'utiliser, et sinon de recopier les fonctions nécessaires dans notre package. Certaines fonctions nécessitaient d'ailleurs de toute façon des modifications, car dans notre simulateur nous gérons aussi l'affichage de la carte alors qu'eux ne faisaient que la charger.

Un fichier ''.yaml'' a la syntaxe suivante :
field:
name: robocup_simulator
size: [14, 9, 0.0]
gradient:
distance: 0.35
minValue: 0
walls:
bottom1:
start: [-6, 0, 0.0]
end: [-4, 0, 0.0]

Nous avons donc commencé par charger le fichier en mémoire en le passant en paramètre à un ''launchfile'' lançant le nœud chargé de lire et d'afficher la carte. Ensuite, en faisant appel à des ''param'' (paramètres) du nœud actuel et en leur donnant le nom du champs (''name'' par exemple), on peut récupérer les valeurs du fichiers voulues.

Nous avons ainsi créé une classe ''Carte'' pour gérer le chargement des données depuis le fichier et toutes les fonctions utilitaires associées, mais permettant aussi d'afficher la carte grâce à une fonction ''display'' de même fonctionnement que celles créées précédemment pour les entités.

Pour l'affichage sur rviz, nous nous sommes servis du type d'objet ''Map'' pour visualiser le sol du terrain (en blanc ci-dessous). Nous avons également créé un vecteur de Rectangles pour afficher les murs (en bleu foncé ci-dessous) et un vecteur de Rectangles pour les zones interdites au robot (en noir).

Nous aurions aimé mettre à jour la taille de la grille affichée en fonction de la taille de la carte, mais il s'avère que c'est impossible, la grille ne provenant pas d'un message publié.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_map.png|Affichage du terrain de jeu dans Rviz
</gallery>

===Semaine 8===

Nous avons complété la fonction de gestion de la vitesse. Il n'y a plus de nœud pour gérer les déplacements au profit d'un nœud gérant chaque robot.
Les robots envoient un vecteur "twist" pour donner leur commande vitesse, soit deux vecteurs vitesse 3D, l'un pour la vitesse linéaire et l'autre pour la vitesse angulaire.
Cependant ce vecteur vitesse est paramétré dans le repère du robot, c'est-à-dire avec le vecteur x dirigé dans la direction de l'orientation du robot.
Pour nos calculs nous nous servons du repère originel, que ce soit pour placer les entités ou les déplacer. Cela facilite les calculs dans la simulation.
Ainsi nous devons transposer les vecteurs vitesse reçus pour les appliquer à notre repère.

La simulation fonctionnant en 2D nous simplifions les données en utilisant un seul vecteur 3D (x et y pour le déplacement linéaire et z pour le changement d'orientation soit la vitesse angulaire autour de l'axe z).
La transposition n'est nécessaire que pour les déplacements linéaires, donc nous utilisons de la trigonométrie simple et nous ajoutons le déplacement ainsi obtenu à la position actuelle, ce qui donne :

v_x = v_x1*cos(orientation_radian) - v_y1*sin(orientation_radian)

v_y = v_x1*sin(orientation_radian) + v_y1*sin(orientation_radian)

x_new = v_x *delta_t + x

y_new = v_y *delta_t + y

orientation_new = (v_angulaire*delta_t + orientation) [360]

Nous avons également apporté des modifications aux flèches et textes; en effet, maintenant que le déplacement des robots est possible, nous pouvons effectuer des tests.
Il s'avère que nous ne modifions pas la position des flèches et textes, le robot s'éloignait alors d'eux lorsqu'il se déplaçait.
Nous avons donc ajouté les quelques modifications nécessaires pour que ces formes suivent l'entité en déplacement.

Nous avons aussi commencé à compléter le package ''machine'' pour lui ajouter les sous-classes de Machine représentant les différentes machines (MPS) du jeu (BaseStation, CapStation, RingStation, DeliveryStation).
La BaseStation permettra au robot de récupérer un objet de type base, la RingStation d'y empiler des anneaux de couleurs différentes en fonction des commandes reçues, la CapStation de déposer un chapeau au sommet de l'objet et enfin on l'apporte à la DeliveryStation.

Nous avons complété ci-dessous les schémas UML du projet dans son état actuel :

<gallery style="margin: 0 auto;">
Fichier:Formes_package_Class_diagram_v3.png|Schéma UML du package ''formes''
Fichier:Machine_package_Class_diagram_v3.png|Schéma UML du package ''machine''
Fichier:Management_package_Class_diagram_v2.png|Schéma UML du package ''management''
Fichier:Robot_package_Class_diagram_v2.png|Schéma UML du package ''robot''
</gallery>

===Semaine 9===

Nous avons dû concevoir une fonction de récupération de distance entre deux entités.
Les robots étant les seules entités mobiles, nous ne calculons que la distance entre un robot et une autre entité.
La distance entre deux robots, soit deux cercles, est facile à déterminer. Nous récupérons les points des deux cercles étant sur la droite passant par les centres des dits cercles. Puis nous appliquons le calcul de distance.

Lorsqu'il s'agit de calculer la distance la plus courte avec un rectangle, c'est un peu plus compliqué et très rapidement le nombre de calculs devient très grand. Nous avons choisi une stratégie calculatoire réduisant le nombre de calculs avec les conseils de Mme Nathalie Delfosse.

Le problème est de trouver la distance la plus courte entre les deux formes ainsi que les points concernés.

[[Fichier:GD_1.png|500px|center|texte descriptif]]

Nous pouvons facilement tracer la zone de collision, soit la zone qui permet de dire qu'il y a une collision si le centre du robot est dessus.

[[Fichier:GD_2.png|500px|center|texte descriptif]]

Ensuite on découpe l'espace en 8 zones en prolongeant les cotés du rectangle pour en faire des droites.

[[Fichier:GD_3.png|500px|center|texte descriptif]]

Lorsqu'un robot se situe en zone n°1 alors la distance la plus proche est celle qui sépare le cercle de l'angle le plus proche du rectangle. Donc (S2) est cette distance avec la résolution du système composé de la droite par le centre du cercle et l'angle, et le cercle. Nous obtenons alors le point du cercle le plus proche du rectangle.

(S2)
(x−xc)²+(y−yc)²==R²
y= ax+b

Dans la zone n°2, la distance la plus courte est une droite verticale, ce qui nous donne facilement le point du cercle et le point du rectangle.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Dans la zone n°3, on observe le même comportement qu'avec la zone n°2 mais cette fois-ci à l'horizontal, les équations sont donc les mêmes avec une inversion des x en y et inversement.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Cette semaine nous avons aussi travaillé sur la production elle-même en complétant les classes du package ''machine''. Nous avons ainsi ajouté à chaque sous-classe une fonction ''setup'' qui permet d'initialiser la machine, la plupart du temps avec une couleur d'anneau ou de base, et pour la ''DeliveryStation'' avec un numéro de porte.

Ces fonctions seront ensuite appelées dans un nœud ''machines_node'' du package ''management''.

===Semaine 10===

Cette semaine, nous avons avancé sur la simulation en permettant à une 'Equipe' d'afficher ses six machines et ses trois robots. Le ''Manager'', lui, affiche les deux équipes; nous avons ainsi tous les acteurs d'un match sur le même terrain.

Nous avons également installé la Referee Box, dans la prévision du travail sur la communication entre simulation et celle-ci, mais aussi pour pouvoir utiliser des types de messages particuliers du package ''llsf_msgs'' inclus avec la Referee Box.

En effet, les machines changent d'état en fonction des commandes qu'elles reçoivent. En effet, les équipes doivent remplir des commandes tout au long du match, et les robots ordonnent ainsi aux machines de produire des types de pièces particuliers.
Ils commencent par envoyer un message de ''setup'' qui va indiquer à la machine quel type de pièce préparer. À ce moment là la machine change d'état (état occupé) et ceci est reflété dans la couleur de son feu.
Lorsque la pièce est disponible, la machine rechange d'état pour être de nouveau disponible.

Il existe également d'autres types d'états, comme lorsque la machine est ''down'' lors d'une maintenance programmée décidée par la Referee Box au début du match, lorsque la machine vient de recevoir un ordre ou encore lorsqu'un robot tente de l'utiliser sans lui envoyer de message de ''setup'', elle est alors hors-service pendant un certain moment.

Lié à la Referee Box, nous avons dû chercher à synchroniser le temps de celle-ci avec le simulateur. Cependant, en observant le code du simulateur Gazebo (actuellement non fonctionnel) et la manière de communiquer avec l'arbitre, nous avons conclu que nous n'avions pas le temps de le faire.

Nous avons dû implémenter le système de gestion de collisions. Graphiquement et avec les équations, il est simple pour un être humain de comprendre le fonctionnement. Cependant le code impose plus de restriction. Nous avons donc décomposé la théorie en plusieurs morceaux. Une fonction pour obtenir la distance entre deux points, plusieurs fonctions permettant de déterminer les points les plus proches entre chaque structure, et enfin une fonction déterminant s'il y a collision.

Pour les cercles, il faut déterminer l'équation de la droite qui passe par le centre des deux cercles puis résoudre le système correspondant à l'intersection de la droite et du cercle qui nous donne une équation du second degré. On choisit alors le point le plus proche de l'autre cercle.

Pour un cercle et un rectangle, on teste zone par zone. Nous ne sommes pas obligés de nous placer dans le référentiel du rectangle. Au lieu de cela, nous allons vérifier zone par zone l'appartenance du cercle à celles-ci grâce aux systèmes composés de trois droites (les cotés du rectangles) pour les zones latérales et de deux pour les zones d'angles. Ces systèmes s'excluent les uns les autres. Si le cercle n'est dans aucune zone alors il est à l'intérieur du rectangle. Ce qui est soit une situation impossible, soit une collision. Lorsque l'on a la zone, on résout le système correspondant (décrit lors de la semaine 9). Cette implémentation n'a pas été faite entièrement durant cette semaine. Nous l'avons continué lors du temps supplémentaire.

===Heures supplémentaires===

Nous avons commencé par ajouter l'affichage des feux (composés d'un rectangle et de trois cercles rouge, jaune, vert).
En fonction de l'état de la machine à laquelle ils appartiennent, les couleurs affichés changent. D'après le règlement, si tout va bien le feu sera vert fixe, si la machine est occupée il sera jaune fixe et si la machine est en maintenance programmée il sera rouge fixe. Si la machine vient de recevoir un ordre, il sera vert clignotant et si elle est hors-service il sera clignotant jaune et rouge.

C'est pourquoi nous avons aussi implémenté le clignotement de celui-ci qu'il est possible de voir dans la vidéo ci-dessous.

Enfin, les machines seront positionnées de différentes manières au début d'un match, il est donc nécessaire que le feu associé ait la même rotation que sa machine.
Nous avons ainsi commencé par permettre aux cercles du haut et du bas d'effectuer un rotation autour du cercle central. Une fois la chose faite, nous avons modifié la rotation d'une machine. En effet, jusque là elle était implémentée de la même manière que pour les robots, or ceux-ci se déplacent et pas notre machine. Il n'est donc pas nécessaire que la flèche soit en rotation mais plutôt qu'elle soit positionnée de manière fixe (mais cela reste modifiable dans le code) et que ce soit le rectangle de la machine qui effectue une rotation sur lui-même. Il en va de même pour le rectangle du feu.

Enfin, nous avons dû gérer le positionnement du feu par rapport au rectangle : il faut, lorsque la machine effectue une rotation, calculer la position de son coin inférieur gauche et positionner le feu par rapport à celui-ci.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_feu_45_degres.png|Feu en rotation
Fichier:Rviz_screenshot_machine_135_degres.png|Machine et son feu en rotation
Fichier:Rviz_screenshot_machine_state_down.png|Machine en état de maintenance programmée
Fichier:Rviz_screenshot_machine_state_busy.png|Machine occupée
Fichier:Rviz_screenshot_machine_state_ok.png|Machine disponible
Fichier:Feu_clignotant.mp4|Vidéo du feu qui clignote
</gallery>

La classe Manager a été transformée en Singleton. C'est un ''pattern'' de programmation permettant de n'instancier une classe qu'en un seul exemplaire unique accessible partout dans le programme. Dans notre cas, cela est particulièrement utile car le Manager permet de gérer les équipes et leurs états. On a seulement besoin d'instancier les équipes du Manager une seule fois au début du Match, et pas à chaque fois qu'on souhaite y accéder.

Nous avons aussi débuté la communication avec la RefereeBox. Il y a trois modes de communication avec celle-ci : en tant que "pair" (communication UDP) sur un canal public, idem sur un canal privé ou en tant que "contrôleur" (communication TCP).
Dans notre cas, c'est le mode "contrôleur" qui nous intéresse : en effet, nous devons avoir accès à toutes les informations de l'arbitre pour pouvoir réaliser une simulation correcte, et seul la communication en TCP le permet. En UDP sur canal public, seul un nombre très limité d'informations est disponible et sur canal privé les informations sont cryptées pour les cacher à l'autre équipe.

Nous avons donc pour cela, après avoir réalisé l'installation de la RefereeBox avec le projet ''llsf-refbox'' dont nous avons parlé semaine 10, créé une classe ''ClientTCP'' d'après un exemple inclus dans le projet installé. Le client s'inscrit comme devant recevoir certains types de messages, par exemple le message de type ''llsf_msgs::MachineInfo'', qui permet d'obtenir les positions des machines et leur état. Ensuite, lorsqu'il reçoit un nouveau message, on vérifie de quel type il s'agit et on agit en conséquence. Dans l'exemple précédent, on appelle ainsi une fonction d'initialisation de la position des machines une unique fois après la réception d'un message de type MachineInfo, lorsque le Manager est initialisé mais que les positions des machines ne le sont pas. Cette fonction prenant en paramètre le message reçu, on n'a plus qu'à changer les différentes valeurs nécessaires.

Pour tester cela, nous avons utilisé la Refbox. Pour la démarrer, il faut se trouver dans le dossier ''llsf-refbox/bin'' et exécuter deux scripts; d'abord
''llsf-refbox'' pour la démarrer puis ''llsf-refbox-shell'' pour voir une interface graphique de gestion apparaître dans le terminal.

De la façon dont nous avons réalisé le projet, il est nécessaire de créer dans son ''bashrc'' une variable d'environnement ROBOCUP_DIR qui correspond au répertoire ROS qui contient le projet et la Referee Box. Celle-ci permet d'utiliser les messages du package ''llsf_msgs''.

== Fichiers Rendus ==

IMA4 2016/2017 P20

2017-05-09T21:56:25Z

Mbutaye : /* Heures supplémentaires */

__TOC__
 
==Cahier des charges==

Ce cahier des charges a pour objectif de définir le projet, ce qui est attendu ainsi que les contraintes de conception qui lui sont associées.

===Présentation générale du projet===

Le projet consiste à concevoir et développer un environnement virtuel de test pour l'Association de Robotique de Polytech Lille (ARPL). Ce simulateur doit reproduire les conditions de participation à la Logistic League de manière à pouvoir obtenir rapidement des données et tester le code ainsi que les stratégies de jeu utilisés par les robots.

====Contexte====
Ce simulateur est un outil développé dans le cadre de la RoboCup et plus particulièrement de la Logistic League. La RoboCup est une compétition internationale de robotique dans laquelle on voit beaucoup d'entreprises et de robots connus tel que NAO. Cette compétition a pour but de mettre en avant les évolutions en matière de robotique ainsi que les qualités des organismes participants.

La Logistic League est une des différentes épreuves proposées. L'objectif est de repérer le terrain puis de produire des objets avec différents éléments fournis par des machines et à livrer dans des plages de temps données. Une RefereeBox ou boîte arbitre sert à la coordination ainsi qu'à l'arbitrage. C'est cette boite qui va informer le robots des différents objets à construire avec la date de livraison demandée. Elle va également donner leur rôles aux machines présentes sur le terrain. L'arbitre va enregistrer les horaires de dépôt des objets et la position de chacune des machines lors de la compétition.

Celle-ci se déroule sur une piste de la taille d'une salle moyenne. Chaque équipe peut utiliser jusqu'à trois robots Robotino 3 pour réaliser les tâches demandées. Sur la piste, à part les robots, se trouvent seulement des machines dites de production ou de livraison. Elles vont servir soit à se procurer un élément nécessaire à la production de l'objet final soit à livrer celui-ci lorsqu'il est terminé.

====Objectif du projet====

Ce projet va permettre de fournir à l'équipe de l'ARPL un simulateur léger et complet, leur permettant de simuler en un court laps de temps un match entier ou partiel et de tester leur code et leur stratégie. Cela leur permettra de développer plus rapidement et efficacement.

====Description du projet====

Le simulateur devra répondre à un certain nombre de critères. Tout d'abord il lui faudra pouvoir simuler toutes les entités présentes sur la piste lors d'un match. Nous parlons des robots et des machines mais également des capteurs et des conditions de jeu.

Nous devrons faire en sorte que le simulateur puisse facilement intégrer le code de contrôle des robots afin de le tester. De plus il faut permettre à l'utilisateur de gérer les parties du code à tester ainsi que de changer les conditions et paramètres de simulation afin de ne tester que certaines partie du code (par exemple en excluant la gestion des collisions). Nous inclurons une gestion des phases de jeu (Découverte et Production) dans ce but. De ce point de vue l'idéal serait de générer un launchfile et de permettre à l'utilisateur de gérer l'utilisation des nœuds un par un.

En sus, le simulateur gérant les robots de l'équipe adverse, il aura une fonctionnalité de sauvegarde des configurations que ce soit pour le code ou les stratégies afin de comparer l'évolution des performances.

Le simulateur a certaines contraintes afin d'être utilisable et utile. Il doit opérer une compression du temps c'est à dire réaliser la simulation d'un match en moins de temps qu'une durée normale de match. Il s'agit d'obtenir des données représentant la réalité en un cours laps de temps. La communication avec la RefereeBox est indispensable. Celle-ci étant fourni par les organisateurs de la compétition nous n'avons pas à la simuler mais nous devons communiquer avec elle pour rendre la simulation plus réaliste.

====Choix techniques : matériel et logiciel====

Nous n'avons pas besoin de matériel hormis d'ordinateurs afin de programmer.

Dû à la compétition et aux choix de développement de l'équipe de l'ARPL, nous allons programmer en C++ avec les bibliothèques QT ainsi que le middleware ROS, une surcouche de programmation destinée à la programmation de robots.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

*Simuler les différentes entités
** les Robotinos ;
** les machines ;
** l'environnement.

*Gérer l'interfaçage entre le simulateur et le code des Robots
** lire et lancer le méta-paquet ;
** identifier les différents parties du code ;
** proposer l'activation/désactivation de ces parties et créer un launchfile en conséquence ;
** créer un système de sauvegarde de tout code interfacé permettant sa réutilisation.

*Simuler un match
** communiquer avec la RefereeBox et recevoir les différents ordres de celle-ci ;
** gérer les machines et la communication avec la RefereeBox ;
** gérer l'équipe de l'utilisateur et son interaction avec le reste de la simulation ;
** gérer l'équipe adverse et son interaction avec le reste de la simulation.

*Paramétrage avancé de la simulation
** proposer différents modes de simulations ;
** activation/déssactivation des paramètres de la simulation ;
** gestion des phases.

*Interface utilisateur
** fournir des données utilisables et intéressantes sur la simulation ;
** créer une GUI ergonomique ;
** importer les données de la simulation sur la GUI pour une meilleure analyse de celle-ci.

====Calendrier====

Répartition du temps consacré au projet (120h/personne) :

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures supplémentaires !! Total
|-
| Définition cahier des charges
| 2
|
|
|
|
|
|
|
|
|
|
|
|2
|-
|Mise à niveau matérielle et intellectuelle
|
|13
|
|
|
|1
|
|
|
|
|
|
|14
|-
|Conception théorique
|
|5
|7
|4
|2
|
|
|0,5
|
|13
|2
|
|33.5
|-
|Programmation de la simulation
|
|
|8
|15
|16
|4
|8
|6
|10
|6
|10
|18
|101
|-
|Programmation de l'affichage avec rviz
|
|
|
|
|
|5
|8
|13
|6
|
|
|5
|37
|-
|Wiki
|
|
|0,5
|1,5
|1,5
|0,5
|2
|0,5
|3
|0,5
|0,5
|2
|12,5
|-
|Réunions tuteurs
|2
|
|
|
|2
|2
|
|
|
|
|
|
|6
|-
|Total
|4
|18
|15,5
|20,5
|21,5
|12,5
|18
|20
|19
|19,5
|12,5
|25
|206
|}

==Planning des tâches==

{| class="wikitable"
!Tâche !! Date prévue !! Avancement !! Commentaires
|-
| Affichage des formes avec Rviz
| 01/03/2017
| Terminé
| Cercle & Rectangle
|-
| Affichage d'un robot
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Affichage d'une machine
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Gestion du temps
| 08/03/2017
| Terminé
| Bornes de facteurs possibles à déterminer
|-
| Déplacement d'un robot
| 22/03/2017
| Terminé
| Vitesse et déplacement au point; Besoin d'interfaçage sur le code ARPL
|-
| Affichage de l'orientation de l'entité
| 13/03/2017
| Terminé
| Affichage d'une forme Flèche dont l'orientation change avec celle de l'entité. Grise. Orientation en degrés.
|-
| Lecture et affichage de la map
| 19/03/2017
| Terminé
| Affichage de la map, des murs et des zones interdites.
|-
| Communication RefBox
| 01/04/2017
| Inachevé
| Communication en place pour l'affichage des machines à leur position de départ.
|-
| Gestion Collision
| 01/04/2017
| Inachevé
| Implémentation de la fonction de regroupement
|}

==Avancement du Projet==

===Semaine 1===
Nous avons commencé par installer ROS et tout ce dont nous avons besoin pour travailler correctement. Nous avons également suivi des [http://wiki.ros.org/ROS/Tutorials tutoriels] pour apprendre à utiliser ROS.

Pour pouvoir travailler en binôme sans problèmes et pour que nos encadrants puissent suivre notre avancement et tester le logiciel, nous avons utilisé le logiciel de gestion de versions Git, sur lequel on publie notre code au fur et à mesure.

Nous n'avions pas encore de dépôt sur celui-ci, donc nous avons commencé par réfléchir à la structure de notre projet.
Nous commencerons par implémenter la phase d'exploration, ce qui comprend aussi le déplacement du robot, la détection de machines et de feux ainsi qu'une interface utilisateur basique.

En effet, le match oppose deux équipes ayant jusque trois robotinos qui s'affrontent lors de deux phases. La première est la phase d'exploration, durant laquelle les robots doivent trouver les machines de leur équipe en explorant le terrain. Ils doivent annoncer la position des machines et les signaux des feux de celles-ci : chaque machine, peu importe son type, possède un feu tricolore (rouge, jaune, vert) qui durant la phase d'exploration aura une combinaison de lumières allumées aléatoirement (au moins une doit l'être).

La création d'un simulateur passe par la réflexion sur les besoins en conception du simulateur (décris en partie ci-dessus). Nous avons donc passé un certain temps à schématiser la structure de notre simulateur et à en assimiler les besoins et l'ordre de création.

===Semaine 2===
Nous avons récupéré un dépôt Git (nommé ''logistic-sim'') sur lequel travailler auprès de nos encadrants, nous pouvons donc commencer la programmation cette semaine.

Ceci étant notre premier projet mêlant ROS et Git, nous avons tenté de créer la structure du projet mais avons vite rencontré quelques difficultés.
Nous avons ensuite compris qu'il était nécessaire de d'abord créer un environnement de travail ROS pour le projet, dans lequel on clône ensuite le dépôt Git localement.

Nous obtenons ainsi la structure de projet suivante :
* Workspace ROS
** build
** devel
** src
*** CMakeLists.txt
*** logistic-sim

Les dossiers build, devel, src et CMakeList.txt sont des fichiers et dossiers générés par ''Catkin'', un outil permettant de créer des paquets ROS facilement.

Nous avons ensuite décidé de séparer le code du projet en différents dossiers en fonction des tâches à effectuer :
* '''Entites''' pour simuler les différentes entités (Robotinos, machines, environnement...)
* '''Gestion_Code''' pour gérer l'interfaçage entre le simulateur et le code des robots
* '''Match''' pour simuler le déroulement d'un match
* '''GUI''' pour l'interface utilisateur avec le framework Qt

Dans chacun de ces dossiers, nous créerons des ''packages'' contenant les différentes fonctionnalités du projet.

Chaque ''package'' a la structure suivante :
* CMakeLists.txt
* include pour les fichiers .h
* package.xml
* README.md
* src pour les classes et nodes .cpp
* launch pour les launchfiles

Dans un premier temps, on commence par la gestion de la position du robot et la reconnaissance des feux.

===Semaine 3===

Nous avons avancé sur la programmation de la gestion de la position du robot et de la reconnaissance des feux.

Nous avons décrit nos classes par des schémas UML avec l'outil gratuit ''Modélio'' pour créer une documentation facilement accessible. Les commentaires des fonctions, classes et fichiers au format ''Doxygen'' nous permettront également de générer une documentation du projet sous format HTML notamment.

Nous suivons aussi la normalisation du code donnée par l'ARPL pour avoir les mêmes conventions de nommage partout.

Nous avons décidé de créer un nouveau package ''match'' qui contiendra les nœuds correspondants aux différentes phases de jeu, et avons donc par conséquent commencé par créer un nœud pour la phase d'exploration.

Nous avons également commencé à réfléchir à la façon dont les informations sont communiquées dans le match : il y a un arbitre, la ''Referee Box'' qui permet de faire communiquer le simulateur et les robots jouant le match. En effet, l'arbitre prend les décisions importantes (placement des machines au début du jeu etc.) et c'est à lui que les robots s'adressent. Nous devons donc aussi communiquer avec lui pour recevoir certaines informations (par exemple les informations de base de la phase d'exploration) et les retransmettre dans le simulateur aux nœuds qui en auront besoin.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v1.png|Schéma UML du package ''machine''
Fichier:Formes_package_Class_diagram_v1.png|Schéma UML du package ''formes''
</gallery>

===Semaine 4===

Cette semaine, nous avons créé plusieurs nouveaux packages et modifié ceux qui avaient déjà été créés.

Nous avons créé la classe Cercle dans le package ''formes'', nous pouvons donc maintenant utiliser deux formes différentes, le rectangle et le cercle.
La classe Entite a elle aussi été rajoutée. En effet, certains attributs des machines sont communs avec ceux des robots; cette classe nous permet de les rassembler et les classes Machine et Robot hériteront ainsi de Entite.

Un nouveau package ''management'' a également fait son apparition. Il contiendra les classes Equipe et Manager. Le Manager sera chargé de créer les équipes et permettra d'y accéder partout dans le code, mais aussi de procéder aux différentes initialisations lors du démarrage d'une nouvelle phase.

Au package ''management'' s'ajoute le nouveau package ''robot'' dont le rôle est de simuler les robotinos lors du match.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v2.png|Schéma UML du package ''machine''
Fichier:Robot_package_Class_diagram_v1.png|Schéma UML du package ''robot''
Fichier:Formes_package_Class_diagram_v2.png|Schéma UML du package ''formes''
Fichier:Management_package_Class_diagram_v1.png|Schéma UML du package ''management''
</gallery>

Nous avons également rendu visite à l'un de nos tuteurs de stage pendant la semaine dans le but d'obtenir un premier retour sur notre travail et l'avancement du projet.

Nous avons pu effectuer immédiatement quelques modifications nécessaires suite aux commentaires de notre tuteur. Nous avons dû, par exemple, clôner leur projet dans le même espace de travail que le notre pour pouvoir réutiliser certains paquets de messages déjà créés. Cela permettra une meilleure compatibilité. D'autres modifications concernaient entre autres les conventions de nommage de certaines classes et l'ajout d'un dossier supplémentaire dans le dossier include de chaque package portant le nom de celui-ci, pour ne pas avoir de conflits quant au nommage des fichiers.

Une réunion avec toute l'équipe des tuteurs a été prévue pour la semaine 5.

===Semaine 5===

La semaine a commencé par une réunion avec l'équipe de l'ARPL se chargeant d'encadrer notre projet, c'est-à-dire Vincent et Thomas. Nous avons discuté ensemble de l'avancement du simulateur et de l'ordre dans lequel effectuer les tâches. Ils nous également demandé de créer un planning de nos tâches avec la date prévue pour chacune; ils auront en effet besoin de modifier leur code à certains endroits pour pouvoir utiliser le simulateur (nous n'aurons pas besoin de tous les nœuds, certains comme la détection Laser nous étant inutiles) et souhaiteraient savoir lorsque nous seront prêt à tester de nouvelles fonctionnalités.

Nous nous sommes lancés dans l'affichage des formes avec l'outil ''rviz'', qui permet de visualiser en 3D les messages de type ''visualisation_msgs'' qui lui sont envoyés sur le topic associé. Ces messages sont disponibles en différents types. Pour afficher les formes nous utiliseront le format ''Marker'' qui permet d'afficher un objet en 3D (cubes, sphères, flèches, cylindres) ou en 2D en lui donnant un z de 0.

Nous avons donc commencé par faire les tutoriels sur l'utilisation de rviz puis par ajouter le code nécessaire à l'affichage des formes. Nous avons ainsi décidé d'ajouter la variable du message de type ''Marker'' dans la classe Forme; celle-ci sera accessible par toutes les classes filles de Forme, notamment Cercle et Rectangle. Nous avons également créé une méthode ''display'' qui sera chargée de mettre à jour la position de la forme et de publier le message. Les différents ''setters'' des classes filles modifieront également le message pour qu'il soit à jour lors de l'envoi.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_rectangle.png|Affichage de la forme ''Rectangle'' dans Rviz
Fichier:Rviz_screenshot_cercle.png|Affichage de la forme ''Cercle'' dans Rviz
</gallery>

===Semaine 6===

Cette semaine, nous continuons d'améliorer l'affichage en programmant cette fois-ci la classe ''Robot'' (qui possède une forme, étant une Entité) pour pouvoir visualiser le robot avec rviz. Nous avons donc ajouté une fonction ''display'' à ''Entite'', faisant elle-même appel à la fonction ''display'' de sa forme; ce qui permettra un affichage plus facile de l'objet.

Nous avons également ajouté une forme ''Texte'' pour afficher du texte informatif sur les formes (par exemple, une lettre et un id pour une entité, "R1" dans le cas du premier robot de chaque équipe). Ce texte est affiché en cyan ou en magenta, en fonction de la couleur de l'équipe. Les noms des ''markers'' de la forme et du texte eux aussi dépendent du type de l'entité.

Enfin, nous avons permis au entités de type Machine de gérer leur affichage. Pour cela, nous avons dû créer une classe fille de cette entité pour pouvoir tester son affichage. Le choix s'est porté sur les machines de type BS (Base Station).

En cours de route, nous avons été confrontés à un problème au niveau de l'affichage en 2D. Il semblait logique que la hauteur des objets (en z) soit égale à 0 pour un affichage 2D, mais il s'est avéré que la couleur de l'objet était alors imprévisible (plus souvent noir que de la bonne couleur). Il en fait fallu laisser une légère épaisseur (0.001 mètres dans notre cas) pour que la couleur s'affiche correctement.

Un de nos objectifs était aussi de gérer l'affichage de l'orientation de nos entités. En effet, cela semble essentiel pour les robots par exemple, représentés par des ronds et pouvant se déplacer. Nous avons ainsi créé un nouveau marker ''Fleche''; il était également possible de changer le type de marker en ''interactive marker'' ce qui aurait permis l'affichage de flèches de direction, mais celles-ci permettaient de modifier la position de l'objet et n'étaient disponibles qu'en multiple de 2 (déplacement sur un axe). Le choix s'est donc porté sur l'utilisation d'un marker classique dont on change l'orientation en même temps que celle de l'entité.
Nous avons rencontré quelques soucis quant à la gestion de l'orientation du marker, celle-ci étant un ''quaternion'' (x, y, z, w) alors que nous souhaitons donner l'angle en degrés (ou en radians éventuellement); la documentation n'est pas forcément facile à trouver pour ROS.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_robot.png|Affichage de l'entité ''Robot'' dans Rviz
Fichier:Rviz_screenshot_machine.png|Affichage de l'entité ''BaseStation'' dans Rviz
Fichier:Rviz_screenshot_fleche.png|Affichage de l'entité ''Robot'' avec une forme ''Fleche'' dans Rviz
</gallery>

Nous avons dû corriger nos constructeurs pour être le plus efficace possible et remplir au maximum les besoins des futurs fonctions.

La problématique rendant nécessaire une gestion du temps vient du besoin de l'ARPL de pouvoir contrôler la vitesse de simulation et donc de pouvoir jouer un match très rapidement afin d'observer le comportement de leur code.
Nous avons commencé et fini la gestion du temps. ROS intègre une interface de temps qui se cale sur la machine qui lance ROS.
Pour que plusieurs machines suivent le même temps il faut opérer une synchronisation des temps. Cependant lors de la simulation tous les robots auront leur référentiel temporel sur la même machine ce qui rend une synchronisation inutile.

Il existe un topic ''clock'' qui sert pour les simulations. En forçant nos nœuds à utiliser le temps de simulation, nous avons une échelle temporelle utilisable et synchronisée. Nous avons donc un nœud qui va publier sur ce topic le temps qui sera initialisé à 0 en début de match.

Un paramètre d'environnement ROS sert à régler le facteur d'accélération de la simulation par rapport au temps réel. Il est modifiable à tout instant et est initialisé en premier dans le launchfile.

===Semaine 7===

Nous nous sommes attaqués à l'affichage du terrain dans rviz.

Pour cela, nous pouvions nous inspirer de code écrit par l'ARPL permettant de charger une carte depuis un fichier ''.yaml''. Certains de leurs packages nous ont été utiles, mais d'autres se sont avérés inutilisables tels quels à cause d'erreurs tantôt de "référence indéfinie" à un fichier, tantôt de "redéfinition" du même fichier (la cause de ces erreurs reste pour le moment toujours un mystère).
Nous avons donc opté, pour pouvoir avancer rapidement sur le projet, d'utiliser tel quel ce qu'il était possible d'utiliser, et sinon de recopier les fonctions nécessaires dans notre package. Certaines fonctions nécessitaient d'ailleurs de toute façon des modifications, car dans notre simulateur nous gérons aussi l'affichage de la carte alors qu'eux ne faisaient que la charger.

Un fichier ''.yaml'' a la syntaxe suivante :
field:
name: robocup_simulator
size: [14, 9, 0.0]
gradient:
distance: 0.35
minValue: 0
walls:
bottom1:
start: [-6, 0, 0.0]
end: [-4, 0, 0.0]

Nous avons donc commencé par charger le fichier en mémoire en le passant en paramètre à un ''launchfile'' lançant le nœud chargé de lire et d'afficher la carte. Ensuite, en faisant appel à des ''param'' (paramètres) du nœud actuel et en leur donnant le nom du champs (''name'' par exemple), on peut récupérer les valeurs du fichiers voulues.

Nous avons ainsi créé une classe ''Carte'' pour gérer le chargement des données depuis le fichier et toutes les fonctions utilitaires associées, mais permettant aussi d'afficher la carte grâce à une fonction ''display'' de même fonctionnement que celles créées précédemment pour les entités.

Pour l'affichage sur rviz, nous nous sommes servis du type d'objet ''Map'' pour visualiser le sol du terrain (en blanc ci-dessous). Nous avons également créé un vecteur de Rectangles pour afficher les murs (en bleu foncé ci-dessous) et un vecteur de Rectangles pour les zones interdites au robot (en noir).

Nous aurions aimé mettre à jour la taille de la grille affichée en fonction de la taille de la carte, mais il s'avère que c'est impossible, la grille ne provenant pas d'un message publié.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_map.png|Affichage du terrain de jeu dans Rviz
</gallery>

===Semaine 8===

Nous avons complété la fonction de gestion de la vitesse. Il n'y a plus de nœud pour gérer les déplacements au profit d'un nœud gérant chaque robot.
Les robots envoient un vecteur "twist" pour donner leur commande vitesse, soit deux vecteurs vitesse 3D, l'un pour la vitesse linéaire et l'autre pour la vitesse angulaire.
Cependant ce vecteur vitesse est paramétré dans le repère du robot, c'est-à-dire avec le vecteur x dirigé dans la direction de l'orientation du robot.
Pour nos calculs nous nous servons du repère originel, que ce soit pour placer les entités ou les déplacer. Cela facilite les calculs dans la simulation.
Ainsi nous devons transposer les vecteurs vitesse reçus pour les appliquer à notre repère.

La simulation fonctionnant en 2D nous simplifions les données en utilisant un seul vecteur 3D (x et y pour le déplacement linéaire et z pour le changement d'orientation soit la vitesse angulaire autour de l'axe z).
La transposition n'est nécessaire que pour les déplacements linéaires, donc nous utilisons de la trigonométrie simple et nous ajoutons le déplacement ainsi obtenu à la position actuelle, ce qui donne :

v_x = v_x1*cos(orientation_radian) - v_y1*sin(orientation_radian)

v_y = v_x1*sin(orientation_radian) + v_y1*sin(orientation_radian)

x_new = v_x *delta_t + x

y_new = v_y *delta_t + y

orientation_new = (v_angulaire*delta_t + orientation) [360]

Nous avons également apporté des modifications aux flèches et textes; en effet, maintenant que le déplacement des robots est possible, nous pouvons effectuer des tests.
Il s'avère que nous ne modifions pas la position des flèches et textes, le robot s'éloignait alors d'eux lorsqu'il se déplaçait.
Nous avons donc ajouté les quelques modifications nécessaires pour que ces formes suivent l'entité en déplacement.

Nous avons aussi commencé à compléter le package ''machine'' pour lui ajouter les sous-classes de Machine représentant les différentes machines (MPS) du jeu (BaseStation, CapStation, RingStation, DeliveryStation).
La BaseStation permettra au robot de récupérer un objet de type base, la RingStation d'y empiler des anneaux de couleurs différentes en fonction des commandes reçues, la CapStation de déposer un chapeau au sommet de l'objet et enfin on l'apporte à la DeliveryStation.

Nous avons complété ci-dessous les schémas UML du projet dans son état actuel :

<gallery style="margin: 0 auto;">
Fichier:Formes_package_Class_diagram_v3.png|Schéma UML du package ''formes''
Fichier:Machine_package_Class_diagram_v3.png|Schéma UML du package ''machine''
Fichier:Management_package_Class_diagram_v2.png|Schéma UML du package ''management''
Fichier:Robot_package_Class_diagram_v2.png|Schéma UML du package ''robot''
</gallery>

===Semaine 9===

Nous avons dû concevoir une fonction de récupération de distance entre deux entités.
Les robots étant les seules entités mobiles, nous ne calculons que la distance entre un robot et une autre entité.
La distance entre deux robots, soit deux cercles, est facile à déterminer. Nous récupérons les points des deux cercles étant sur la droite passant par les centres des dits cercles. Puis nous appliquons le calcul de distance.

Lorsqu'il s'agit de calculer la distance la plus courte avec un rectangle, c'est un peu plus compliqué et très rapidement le nombre de calculs devient très grand. Nous avons choisi une stratégie calculatoire réduisant le nombre de calculs avec les conseils de Mme Nathalie Delfosse.

Le problème est de trouver la distance la plus courte entre les deux formes ainsi que les points concernés.

[[Fichier:GD_1.png|500px|center|texte descriptif]]

Nous pouvons facilement tracer la zone de collision, soit la zone qui permet de dire qu'il y a une collision si le centre du robot est dessus.

[[Fichier:GD_2.png|500px|center|texte descriptif]]

Ensuite on découpe l'espace en 8 zones en prolongeant les cotés du rectangle pour en faire des droites.

[[Fichier:GD_3.png|500px|center|texte descriptif]]

Lorsqu'un robot se situe en zone n°1 alors la distance la plus proche est celle qui sépare le cercle de l'angle le plus proche du rectangle. Donc (S2) est cette distance avec la résolution du système composé de la droite par le centre du cercle et l'angle, et le cercle. Nous obtenons alors le point du cercle le plus proche du rectangle.

(S2)
(x−xc)²+(y−yc)²==R²
y= ax+b

Dans la zone n°2, la distance la plus courte est une droite verticale, ce qui nous donne facilement le point du cercle et le point du rectangle.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Dans la zone n°3, on observe le même comportement qu'avec la zone n°2 mais cette fois-ci à l'horizontal, les équations sont donc les mêmes avec une inversion des x en y et inversement.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Cette semaine nous avons aussi travaillé sur la production elle-même en complétant les classes du package ''machine''. Nous avons ainsi ajouté à chaque sous-classe une fonction ''setup'' qui permet d'initialiser la machine, la plupart du temps avec une couleur d'anneau ou de base, et pour la ''DeliveryStation'' avec un numéro de porte.

Ces fonctions seront ensuite appelées dans un nœud ''machines_node'' du package ''management''.

===Semaine 10===

Cette semaine, nous avons avancé sur la simulation en permettant à une 'Equipe' d'afficher ses six machines et ses trois robots. Le 'Manager', lui, affiche les deux équipes; nous avons ainsi tous les acteurs d'un match sur le même terrain.

Nous avons également installé la Referee Box, dans la prévision du travail sur la communication entre simulation et celle-ci, mais aussi pour pouvoir utiliser des types de messages particuliers du package 'llsf_msgs' inclus avec la Referee Box.

En effet, les machines changent d'état en fonction des commandes qu'elles reçoivent. En effet, les équipes doivent remplir des commandes tout au long du match, et les robots ordonnent ainsi aux machines de produire des types de pièces particuliers.
Ils commencent par envoyer un message de 'setup' qui va indiquer à la machine quel type de pièce préparer. À ce moment là la machine change d'état (état occupé) et ceci est reflété dans la couleur de son feu.
Lorsque la pièce est disponible, la machine rechange d'état pour être de nouveau disponible.

Il existe également d'autres types d'états, comme lorsque la machine est 'down' lors d'une maintenance programmée décidée par la Referee Box au début du match, lorsque la machine vient de recevoir un ordre ou encore lorsqu'un robot tente de l'utiliser sans lui envoyer de message de 'setup, elle est alors hors-service pendant un certain moment.

Lié à la Referee Box, nous avons du chercher à synchroniser le temps de celle-ci avec le simulateur. Cependant en observant le code du simulateur Gazebo (actuellement non fonctionnel) et la manière de communiquer avec l'arbitre, nous avons conclu que nous n'avions pas le temps de le faire.

Nous avons du implémenter le système de gestion de collision. Graphiquement et avec les équations, il est simple pour un être humain de comprendre le fonctionnement. Cependant le code impose plus de restriction. Nous avons donc décomposer la théorie en plusieurs. Une fonction pour obtenir la distance entre deux points, plusieurs fonctions permettant de déterminer les points les plus proche entre chaque structure. Et enfin une fonction déterminant si il y a collision.

Pour les cercle, il faut déterminer l'équation de la droite qui passe par le centre des deux cercles. Puis résoudre le système correspondant à l'intersection de la droite et du cercle qui nous odnne une équation du second degré. On choisit alors le point le plus proche de l'autre cercle.

Pour un cercle et un rectangle, on test zone par zone. Nous ne sommes pas obligés de nous placer dans le référentiel du rectangle. Au lieu de ça nous allons vérifier zone par zone l'appartenance du cercle à celles-ci grâce aux systèmes composés de trois droites (les cotés du rectangles) pour les zones latérales et de deux pour les zones d'angles. Ces systèmes s'excluent les uns les autres. Si le cercle n'est dans aucune zone alors il est à l'intérieur du rectangle. Ce qui est soit une situation impossible soit une collision. Lorsque l'on à la zone on résout le système correspondant (décrit lors de la semaine 9). Cette implémentation n'a pas été faite entièrement durant cette semaine. Nous l'avons continué lors du temps supplémentaire.

===Heures supplémentaires===

Nous avons commencé par ajouter l'affichage des feux (composés d'un rectangle et de trois cercles rouge, jaune, vert).
En fonction de l'état de la machine à laquelle ils appartiennent, les couleurs affichés changent. D'après le règlement, si tout va bien le feu sera vert fixe, si la machine est occupée il sera jaune fixe et si la machine est en maintenance programmée il sera rouge fixe. Si la machine vient de recevoir un ordre, il sera vert clignotant et si elle est hors-service il sera clignotant jaune et rouge.

C'est pourquoi nous avons aussi implémenté le clignotement de celui-ci qu'il est possible de voir dans la vidéo ci-dessous.

Enfin, les machines seront positionnées de différentes manières au début d'un match, il est donc nécessaire que le feu associé ait la même rotation que sa machine.
Nous avons ainsi commencé par permettre aux cercles du haut et du bas d'effectuer un rotation autour du cercle central. Une fois la chose faite, nous avons modifié la rotation d'une machine. En effet, jusque là elle était implémentée de la même manière que pour les robots, or ceux-ci se déplacent et pas notre machine. Il n'est donc pas nécessaire que la flèche soit en rotation mais plutôt qu'elle soit positionnée de manière fixe (mais cela reste modifiable dans le code) et que ce soit le rectangle de la machine qui effectue une rotation sur lui-même. Il en va de même pour le rectangle du feu.

Enfin, nous avons dû gérer le positionnement du feu par rapport au rectangle : il faut, lorsque la machine effectue une rotation, calculer la position de son coin inférieur gauche et positionner le feu par rapport à celui-ci.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_feu_45_degres.png|Feu en rotation
Fichier:Rviz_screenshot_machine_135_degres.png|Machine et son feu en rotation
Fichier:Rviz_screenshot_machine_state_down.png|Machine en état de maintenance programmée
Fichier:Rviz_screenshot_machine_state_busy.png|Machine occupée
Fichier:Rviz_screenshot_machine_state_ok.png|Machine disponible
Fichier:Feu_clignotant.mp4|Vidéo du feu qui clignote
</gallery>

La classe Manager a été transformée en Singleton. C'est un ''pattern'' de programmation permettant de n'instancier une classe qu'en un seul exemplaire unique accessible partout dans le programme. Dans notre cas, cela est particulièrement utile car le Manager permet de gérer les équipes et leurs états. On a seulement besoin d'instancier les équipes du Manager une seule fois au début du Match, et pas à chaque fois qu'on souhaite y accéder.

Nous avons aussi débuté la communication avec la RefereeBox. Il y a trois modes de communication avec celle-ci : en tant que "pair" (communication UDP) sur un canal public, idem sur un canal privé ou en tant que "contrôleur" (communication TCP).
Dans notre cas, c'est le mode "contrôleur" qui nous intéresse : en effet, nous devons avoir accès à toutes les informations de l'arbitre pour pouvoir réaliser une simulation correcte, et seul la communication en TCP le permet. En UDP sur canal public, seul un nombre très limité d'informations est disponible et sur canal privé les informations sont cryptées pour les cacher à l'autre équipe.

Nous avons donc pour cela, après avoir réalisé l'installation de la RefereeBox avec le projet ''llsf-refbox'' dont nous avons parlé semaine 10, créé une classe ''ClientTCP'' d'après un exemple inclus dans le projet installé. Le client s'inscrit comme devant recevoir certains types de messages, par exemple le message de type ''llsf_msgs::MachineInfo'', qui permet d'obtenir les positions des machines et leur état. Ensuite, lorsqu'il reçoit un nouveau message, on vérifie de quel type il s'agit et on agit en conséquence. Dans l'exemple précédent, on appelle ainsi une fonction d'initialisation de la position des machines une unique fois après la réception d'un message de type MachineInfo, lorsque le Manager est initialisé mais que les positions des machines ne le sont pas. Cette fonction prenant en paramètre le message reçu, on n'a plus qu'à changer les différentes valeurs nécessaires.

Pour tester cela, nous avons utilisé la Refbox. Pour la démarrer, il faut se trouver dans le dossier ''llsf-refbox/bin'' et exécuter deux scripts; d'abord
''llsf-refbox'' pour la démarrer puis ''llsf-refbox-shell'' pour voir une interface graphique de gestion apparaître dans le terminal.

De la façon dont nous avons réalisé le projet, il est nécessaire de créer dans son ''bashrc'' une variable d'environnement ROBOCUP_DIR qui correspond au répertoire ROS qui contient le projet et la Referee Box. Celle-ci permet d'utiliser les messages du package ''llsf_msgs''.

== Fichiers Rendus ==

IMA4 2016/2017 P20

2017-05-09T21:34:26Z

Mbutaye : /* Planning des tâches */

__TOC__
 
==Cahier des charges==

Ce cahier des charges a pour objectif de définir le projet, ce qui est attendu ainsi que les contraintes de conception qui lui sont associées.

===Présentation générale du projet===

Le projet consiste à concevoir et développer un environnement virtuel de test pour l'Association de Robotique de Polytech Lille (ARPL). Ce simulateur doit reproduire les conditions de participation à la Logistic League de manière à pouvoir obtenir rapidement des données et tester le code ainsi que les stratégies de jeu utilisés par les robots.

====Contexte====
Ce simulateur est un outil développé dans le cadre de la RoboCup et plus particulièrement de la Logistic League. La RoboCup est une compétition internationale de robotique dans laquelle on voit beaucoup d'entreprises et de robots connus tel que NAO. Cette compétition a pour but de mettre en avant les évolutions en matière de robotique ainsi que les qualités des organismes participants.

La Logistic League est une des différentes épreuves proposées. L'objectif est de repérer le terrain puis de produire des objets avec différents éléments fournis par des machines et à livrer dans des plages de temps données. Une RefereeBox ou boîte arbitre sert à la coordination ainsi qu'à l'arbitrage. C'est cette boite qui va informer le robots des différents objets à construire avec la date de livraison demandée. Elle va également donner leur rôles aux machines présentes sur le terrain. L'arbitre va enregistrer les horaires de dépôt des objets et la position de chacune des machines lors de la compétition.

Celle-ci se déroule sur une piste de la taille d'une salle moyenne. Chaque équipe peut utiliser jusqu'à trois robots Robotino 3 pour réaliser les tâches demandées. Sur la piste, à part les robots, se trouvent seulement des machines dites de production ou de livraison. Elles vont servir soit à se procurer un élément nécessaire à la production de l'objet final soit à livrer celui-ci lorsqu'il est terminé.

====Objectif du projet====

Ce projet va permettre de fournir à l'équipe de l'ARPL un simulateur léger et complet, leur permettant de simuler en un court laps de temps un match entier ou partiel et de tester leur code et leur stratégie. Cela leur permettra de développer plus rapidement et efficacement.

====Description du projet====

Le simulateur devra répondre à un certain nombre de critères. Tout d'abord il lui faudra pouvoir simuler toutes les entités présentes sur la piste lors d'un match. Nous parlons des robots et des machines mais également des capteurs et des conditions de jeu.

Nous devrons faire en sorte que le simulateur puisse facilement intégrer le code de contrôle des robots afin de le tester. De plus il faut permettre à l'utilisateur de gérer les parties du code à tester ainsi que de changer les conditions et paramètres de simulation afin de ne tester que certaines partie du code (par exemple en excluant la gestion des collisions). Nous inclurons une gestion des phases de jeu (Découverte et Production) dans ce but. De ce point de vue l'idéal serait de générer un launchfile et de permettre à l'utilisateur de gérer l'utilisation des nœuds un par un.

En sus, le simulateur gérant les robots de l'équipe adverse, il aura une fonctionnalité de sauvegarde des configurations que ce soit pour le code ou les stratégies afin de comparer l'évolution des performances.

Le simulateur a certaines contraintes afin d'être utilisable et utile. Il doit opérer une compression du temps c'est à dire réaliser la simulation d'un match en moins de temps qu'une durée normale de match. Il s'agit d'obtenir des données représentant la réalité en un cours laps de temps. La communication avec la RefereeBox est indispensable. Celle-ci étant fourni par les organisateurs de la compétition nous n'avons pas à la simuler mais nous devons communiquer avec elle pour rendre la simulation plus réaliste.

====Choix techniques : matériel et logiciel====

Nous n'avons pas besoin de matériel hormis d'ordinateurs afin de programmer.

Dû à la compétition et aux choix de développement de l'équipe de l'ARPL, nous allons programmer en C++ avec les bibliothèques QT ainsi que le middleware ROS, une surcouche de programmation destinée à la programmation de robots.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

*Simuler les différentes entités
** les Robotinos ;
** les machines ;
** l'environnement.

*Gérer l'interfaçage entre le simulateur et le code des Robots
** lire et lancer le méta-paquet ;
** identifier les différents parties du code ;
** proposer l'activation/désactivation de ces parties et créer un launchfile en conséquence ;
** créer un système de sauvegarde de tout code interfacé permettant sa réutilisation.

*Simuler un match
** communiquer avec la RefereeBox et recevoir les différents ordres de celle-ci ;
** gérer les machines et la communication avec la RefereeBox ;
** gérer l'équipe de l'utilisateur et son interaction avec le reste de la simulation ;
** gérer l'équipe adverse et son interaction avec le reste de la simulation.

*Paramétrage avancé de la simulation
** proposer différents modes de simulations ;
** activation/déssactivation des paramètres de la simulation ;
** gestion des phases.

*Interface utilisateur
** fournir des données utilisables et intéressantes sur la simulation ;
** créer une GUI ergonomique ;
** importer les données de la simulation sur la GUI pour une meilleure analyse de celle-ci.

====Calendrier====

Répartition du temps consacré au projet (120h/personne) :

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures supplémentaires !! Total
|-
| Définition cahier des charges
| 2
|
|
|
|
|
|
|
|
|
|
|
|2
|-
|Mise à niveau matérielle et intellectuelle
|
|13
|
|
|
|1
|
|
|
|
|
|
|14
|-
|Conception théorique
|
|5
|7
|4
|2
|
|
|0,5
|
|13
|2
|
|33.5
|-
|Programmation de la simulation
|
|
|8
|15
|16
|4
|8
|6
|10
|6
|10
|18
|101
|-
|Programmation de l'affichage avec rviz
|
|
|
|
|
|5
|8
|13
|6
|
|
|5
|37
|-
|Wiki
|
|
|0,5
|1,5
|1,5
|0,5
|2
|0,5
|3
|0,5
|0,5
|2
|12,5
|-
|Réunions tuteurs
|2
|
|
|
|2
|2
|
|
|
|
|
|
|6
|-
|Total
|4
|18
|15,5
|20,5
|21,5
|12,5
|18
|20
|19
|19,5
|12,5
|25
|206
|}

==Planning des tâches==

{| class="wikitable"
!Tâche !! Date prévue !! Avancement !! Commentaires
|-
| Affichage des formes avec Rviz
| 01/03/2017
| Terminé
| Cercle & Rectangle
|-
| Affichage d'un robot
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Affichage d'une machine
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Gestion du temps
| 08/03/2017
| Terminé
| Bornes de facteurs possibles à déterminer
|-
| Déplacement d'un robot
| 22/03/2017
| Terminé
| Vitesse et déplacement au point; Besoin d'interfaçage sur le code ARPL
|-
| Affichage de l'orientation de l'entité
| 13/03/2017
| Terminé
| Affichage d'une forme Flèche dont l'orientation change avec celle de l'entité. Grise. Orientation en degrés.
|-
| Lecture et affichage de la map
| 19/03/2017
| Terminé
| Affichage de la map, des murs et des zones interdites.
|-
| Communication RefBox
| 01/04/2017
| Inachevé
| Communication en place pour l'affichage des machines à leur position de départ.
|-
| Gestion Collision
| 01/04/2017
| Inachevé
| Implémentation de la fonction de regroupement
|}

==Avancement du Projet==

===Semaine 1===
Nous avons commencé par installer ROS et tout ce dont nous avons besoin pour travailler correctement. Nous avons également suivi des [http://wiki.ros.org/ROS/Tutorials tutoriels] pour apprendre à utiliser ROS.

Pour pouvoir travailler en binôme sans problèmes et pour que nos encadrants puissent suivre notre avancement et tester le logiciel, nous avons utilisé le logiciel de gestion de versions Git, sur lequel on publie notre code au fur et à mesure.

Nous n'avions pas encore de dépôt sur celui-ci, donc nous avons commencé par réfléchir à la structure de notre projet.
Nous commencerons par implémenter la phase d'exploration, ce qui comprend aussi le déplacement du robot, la détection de machines et de feux ainsi qu'une interface utilisateur basique.

En effet, le match oppose deux équipes ayant jusque trois robotinos qui s'affrontent lors de deux phases. La première est la phase d'exploration, durant laquelle les robots doivent trouver les machines de leur équipe en explorant le terrain. Ils doivent annoncer la position des machines et les signaux des feux de celles-ci : chaque machine, peu importe son type, possède un feu tricolore (rouge, jaune, vert) qui durant la phase d'exploration aura une combinaison de lumières allumées aléatoirement (au moins une doit l'être).

La création d'un simulateur passe par la réflexion sur les besoins en conception du simulateur (décris en partie ci-dessus). Nous avons donc passé un certain temps à schématiser la structure de notre simulateur et à en assimiler les besoins et l'ordre de création.

===Semaine 2===
Nous avons récupéré un dépôt Git (nommé ''logistic-sim'') sur lequel travailler auprès de nos encadrants, nous pouvons donc commencer la programmation cette semaine.

Ceci étant notre premier projet mêlant ROS et Git, nous avons tenté de créer la structure du projet mais avons vite rencontré quelques difficultés.
Nous avons ensuite compris qu'il était nécessaire de d'abord créer un environnement de travail ROS pour le projet, dans lequel on clône ensuite le dépôt Git localement.

Nous obtenons ainsi la structure de projet suivante :
* Workspace ROS
** build
** devel
** src
*** CMakeLists.txt
*** logistic-sim

Les dossiers build, devel, src et CMakeList.txt sont des fichiers et dossiers générés par ''Catkin'', un outil permettant de créer des paquets ROS facilement.

Nous avons ensuite décidé de séparer le code du projet en différents dossiers en fonction des tâches à effectuer :
* '''Entites''' pour simuler les différentes entités (Robotinos, machines, environnement...)
* '''Gestion_Code''' pour gérer l'interfaçage entre le simulateur et le code des robots
* '''Match''' pour simuler le déroulement d'un match
* '''GUI''' pour l'interface utilisateur avec le framework Qt

Dans chacun de ces dossiers, nous créerons des ''packages'' contenant les différentes fonctionnalités du projet.

Chaque ''package'' a la structure suivante :
* CMakeLists.txt
* include pour les fichiers .h
* package.xml
* README.md
* src pour les classes et nodes .cpp
* launch pour les launchfiles

Dans un premier temps, on commence par la gestion de la position du robot et la reconnaissance des feux.

===Semaine 3===

Nous avons avancé sur la programmation de la gestion de la position du robot et de la reconnaissance des feux.

Nous avons décrit nos classes par des schémas UML avec l'outil gratuit ''Modélio'' pour créer une documentation facilement accessible. Les commentaires des fonctions, classes et fichiers au format ''Doxygen'' nous permettront également de générer une documentation du projet sous format HTML notamment.

Nous suivons aussi la normalisation du code donnée par l'ARPL pour avoir les mêmes conventions de nommage partout.

Nous avons décidé de créer un nouveau package ''match'' qui contiendra les nœuds correspondants aux différentes phases de jeu, et avons donc par conséquent commencé par créer un nœud pour la phase d'exploration.

Nous avons également commencé à réfléchir à la façon dont les informations sont communiquées dans le match : il y a un arbitre, la ''Referee Box'' qui permet de faire communiquer le simulateur et les robots jouant le match. En effet, l'arbitre prend les décisions importantes (placement des machines au début du jeu etc.) et c'est à lui que les robots s'adressent. Nous devons donc aussi communiquer avec lui pour recevoir certaines informations (par exemple les informations de base de la phase d'exploration) et les retransmettre dans le simulateur aux nœuds qui en auront besoin.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v1.png|Schéma UML du package ''machine''
Fichier:Formes_package_Class_diagram_v1.png|Schéma UML du package ''formes''
</gallery>

===Semaine 4===

Cette semaine, nous avons créé plusieurs nouveaux packages et modifié ceux qui avaient déjà été créés.

Nous avons créé la classe Cercle dans le package ''formes'', nous pouvons donc maintenant utiliser deux formes différentes, le rectangle et le cercle.
La classe Entite a elle aussi été rajoutée. En effet, certains attributs des machines sont communs avec ceux des robots; cette classe nous permet de les rassembler et les classes Machine et Robot hériteront ainsi de Entite.

Un nouveau package ''management'' a également fait son apparition. Il contiendra les classes Equipe et Manager. Le Manager sera chargé de créer les équipes et permettra d'y accéder partout dans le code, mais aussi de procéder aux différentes initialisations lors du démarrage d'une nouvelle phase.

Au package ''management'' s'ajoute le nouveau package ''robot'' dont le rôle est de simuler les robotinos lors du match.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v2.png|Schéma UML du package ''machine''
Fichier:Robot_package_Class_diagram_v1.png|Schéma UML du package ''robot''
Fichier:Formes_package_Class_diagram_v2.png|Schéma UML du package ''formes''
Fichier:Management_package_Class_diagram_v1.png|Schéma UML du package ''management''
</gallery>

Nous avons également rendu visite à l'un de nos tuteurs de stage pendant la semaine dans le but d'obtenir un premier retour sur notre travail et l'avancement du projet.

Nous avons pu effectuer immédiatement quelques modifications nécessaires suite aux commentaires de notre tuteur. Nous avons dû, par exemple, clôner leur projet dans le même espace de travail que le notre pour pouvoir réutiliser certains paquets de messages déjà créés. Cela permettra une meilleure compatibilité. D'autres modifications concernaient entre autres les conventions de nommage de certaines classes et l'ajout d'un dossier supplémentaire dans le dossier include de chaque package portant le nom de celui-ci, pour ne pas avoir de conflits quant au nommage des fichiers.

Une réunion avec toute l'équipe des tuteurs a été prévue pour la semaine 5.

===Semaine 5===

La semaine a commencé par une réunion avec l'équipe de l'ARPL se chargeant d'encadrer notre projet, c'est-à-dire Vincent et Thomas. Nous avons discuté ensemble de l'avancement du simulateur et de l'ordre dans lequel effectuer les tâches. Ils nous également demandé de créer un planning de nos tâches avec la date prévue pour chacune; ils auront en effet besoin de modifier leur code à certains endroits pour pouvoir utiliser le simulateur (nous n'aurons pas besoin de tous les nœuds, certains comme la détection Laser nous étant inutiles) et souhaiteraient savoir lorsque nous seront prêt à tester de nouvelles fonctionnalités.

Nous nous sommes lancés dans l'affichage des formes avec l'outil ''rviz'', qui permet de visualiser en 3D les messages de type ''visualisation_msgs'' qui lui sont envoyés sur le topic associé. Ces messages sont disponibles en différents types. Pour afficher les formes nous utiliseront le format ''Marker'' qui permet d'afficher un objet en 3D (cubes, sphères, flèches, cylindres) ou en 2D en lui donnant un z de 0.

Nous avons donc commencé par faire les tutoriels sur l'utilisation de rviz puis par ajouter le code nécessaire à l'affichage des formes. Nous avons ainsi décidé d'ajouter la variable du message de type ''Marker'' dans la classe Forme; celle-ci sera accessible par toutes les classes filles de Forme, notamment Cercle et Rectangle. Nous avons également créé une méthode ''display'' qui sera chargée de mettre à jour la position de la forme et de publier le message. Les différents ''setters'' des classes filles modifieront également le message pour qu'il soit à jour lors de l'envoi.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_rectangle.png|Affichage de la forme ''Rectangle'' dans Rviz
Fichier:Rviz_screenshot_cercle.png|Affichage de la forme ''Cercle'' dans Rviz
</gallery>

===Semaine 6===

Cette semaine, nous continuons d'améliorer l'affichage en programmant cette fois-ci la classe ''Robot'' (qui possède une forme, étant une Entité) pour pouvoir visualiser le robot avec rviz. Nous avons donc ajouté une fonction ''display'' à ''Entite'', faisant elle-même appel à la fonction ''display'' de sa forme; ce qui permettra un affichage plus facile de l'objet.

Nous avons également ajouté une forme ''Texte'' pour afficher du texte informatif sur les formes (par exemple, une lettre et un id pour une entité, "R1" dans le cas du premier robot de chaque équipe). Ce texte est affiché en cyan ou en magenta, en fonction de la couleur de l'équipe. Les noms des ''markers'' de la forme et du texte eux aussi dépendent du type de l'entité.

Enfin, nous avons permis au entités de type Machine de gérer leur affichage. Pour cela, nous avons dû créer une classe fille de cette entité pour pouvoir tester son affichage. Le choix s'est porté sur les machines de type BS (Base Station).

En cours de route, nous avons été confrontés à un problème au niveau de l'affichage en 2D. Il semblait logique que la hauteur des objets (en z) soit égale à 0 pour un affichage 2D, mais il s'est avéré que la couleur de l'objet était alors imprévisible (plus souvent noir que de la bonne couleur). Il en fait fallu laisser une légère épaisseur (0.001 mètres dans notre cas) pour que la couleur s'affiche correctement.

Un de nos objectifs était aussi de gérer l'affichage de l'orientation de nos entités. En effet, cela semble essentiel pour les robots par exemple, représentés par des ronds et pouvant se déplacer. Nous avons ainsi créé un nouveau marker ''Fleche''; il était également possible de changer le type de marker en ''interactive marker'' ce qui aurait permis l'affichage de flèches de direction, mais celles-ci permettaient de modifier la position de l'objet et n'étaient disponibles qu'en multiple de 2 (déplacement sur un axe). Le choix s'est donc porté sur l'utilisation d'un marker classique dont on change l'orientation en même temps que celle de l'entité.
Nous avons rencontré quelques soucis quant à la gestion de l'orientation du marker, celle-ci étant un ''quaternion'' (x, y, z, w) alors que nous souhaitons donner l'angle en degrés (ou en radians éventuellement); la documentation n'est pas forcément facile à trouver pour ROS.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_robot.png|Affichage de l'entité ''Robot'' dans Rviz
Fichier:Rviz_screenshot_machine.png|Affichage de l'entité ''BaseStation'' dans Rviz
Fichier:Rviz_screenshot_fleche.png|Affichage de l'entité ''Robot'' avec une forme ''Fleche'' dans Rviz
</gallery>

Nous avons dû corriger nos constructeurs pour être le plus efficace possible et remplir au maximum les besoins des futurs fonctions.

La problématique rendant nécessaire une gestion du temps vient du besoin de l'ARPL de pouvoir contrôler la vitesse de simulation et donc de pouvoir jouer un match très rapidement afin d'observer le comportement de leur code.
Nous avons commencé et fini la gestion du temps. ROS intègre une interface de temps qui se cale sur la machine qui lance ROS.
Pour que plusieurs machines suivent le même temps il faut opérer une synchronisation des temps. Cependant lors de la simulation tous les robots auront leur référentiel temporel sur la même machine ce qui rend une synchronisation inutile.

Il existe un topic ''clock'' qui sert pour les simulations. En forçant nos nœuds à utiliser le temps de simulation, nous avons une échelle temporelle utilisable et synchronisée. Nous avons donc un nœud qui va publier sur ce topic le temps qui sera initialisé à 0 en début de match.

Un paramètre d'environnement ROS sert à régler le facteur d'accélération de la simulation par rapport au temps réel. Il est modifiable à tout instant et est initialisé en premier dans le launchfile.

===Semaine 7===

Nous nous sommes attaqués à l'affichage du terrain dans rviz.

Pour cela, nous pouvions nous inspirer de code écrit par l'ARPL permettant de charger une carte depuis un fichier ''.yaml''. Certains de leurs packages nous ont été utiles, mais d'autres se sont avérés inutilisables tels quels à cause d'erreurs tantôt de "référence indéfinie" à un fichier, tantôt de "redéfinition" du même fichier (la cause de ces erreurs reste pour le moment toujours un mystère).
Nous avons donc opté, pour pouvoir avancer rapidement sur le projet, d'utiliser tel quel ce qu'il était possible d'utiliser, et sinon de recopier les fonctions nécessaires dans notre package. Certaines fonctions nécessitaient d'ailleurs de toute façon des modifications, car dans notre simulateur nous gérons aussi l'affichage de la carte alors qu'eux ne faisaient que la charger.

Un fichier ''.yaml'' a la syntaxe suivante :
field:
name: robocup_simulator
size: [14, 9, 0.0]
gradient:
distance: 0.35
minValue: 0
walls:
bottom1:
start: [-6, 0, 0.0]
end: [-4, 0, 0.0]

Nous avons donc commencé par charger le fichier en mémoire en le passant en paramètre à un ''launchfile'' lançant le nœud chargé de lire et d'afficher la carte. Ensuite, en faisant appel à des ''param'' (paramètres) du nœud actuel et en leur donnant le nom du champs (''name'' par exemple), on peut récupérer les valeurs du fichiers voulues.

Nous avons ainsi créé une classe ''Carte'' pour gérer le chargement des données depuis le fichier et toutes les fonctions utilitaires associées, mais permettant aussi d'afficher la carte grâce à une fonction ''display'' de même fonctionnement que celles créées précédemment pour les entités.

Pour l'affichage sur rviz, nous nous sommes servis du type d'objet ''Map'' pour visualiser le sol du terrain (en blanc ci-dessous). Nous avons également créé un vecteur de Rectangles pour afficher les murs (en bleu foncé ci-dessous) et un vecteur de Rectangles pour les zones interdites au robot (en noir).

Nous aurions aimé mettre à jour la taille de la grille affichée en fonction de la taille de la carte, mais il s'avère que c'est impossible, la grille ne provenant pas d'un message publié.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_map.png|Affichage du terrain de jeu dans Rviz
</gallery>

===Semaine 8===

Nous avons complété la fonction de gestion de la vitesse. Il n'y a plus de nœud pour gérer les déplacements au profit d'un nœud gérant chaque robot.
Les robots envoient un vecteur "twist" pour donner leur commande vitesse, soit deux vecteurs vitesse 3D, l'un pour la vitesse linéaire et l'autre pour la vitesse angulaire.
Cependant ce vecteur vitesse est paramétré dans le repère du robot, c'est-à-dire avec le vecteur x dirigé dans la direction de l'orientation du robot.
Pour nos calculs nous nous servons du repère originel, que ce soit pour placer les entités ou les déplacer. Cela facilite les calculs dans la simulation.
Ainsi nous devons transposer les vecteurs vitesse reçus pour les appliquer à notre repère.

La simulation fonctionnant en 2D nous simplifions les données en utilisant un seul vecteur 3D (x et y pour le déplacement linéaire et z pour le changement d'orientation soit la vitesse angulaire autour de l'axe z).
La transposition n'est nécessaire que pour les déplacements linéaires, donc nous utilisons de la trigonométrie simple et nous ajoutons le déplacement ainsi obtenu à la position actuelle, ce qui donne :

v_x = v_x1*cos(orientation_radian) - v_y1*sin(orientation_radian)

v_y = v_x1*sin(orientation_radian) + v_y1*sin(orientation_radian)

x_new = v_x *delta_t + x

y_new = v_y *delta_t + y

orientation_new = (v_angulaire*delta_t + orientation) [360]

Nous avons également apporté des modifications aux flèches et textes; en effet, maintenant que le déplacement des robots est possible, nous pouvons effectuer des tests.
Il s'avère que nous ne modifions pas la position des flèches et textes, le robot s'éloignait alors d'eux lorsqu'il se déplaçait.
Nous avons donc ajouté les quelques modifications nécessaires pour que ces formes suivent l'entité en déplacement.

Nous avons aussi commencé à compléter le package ''machine'' pour lui ajouter les sous-classes de Machine représentant les différentes machines (MPS) du jeu (BaseStation, CapStation, RingStation, DeliveryStation).
La BaseStation permettra au robot de récupérer un objet de type base, la RingStation d'y empiler des anneaux de couleurs différentes en fonction des commandes reçues, la CapStation de déposer un chapeau au sommet de l'objet et enfin on l'apporte à la DeliveryStation.

Nous avons complété ci-dessous les schémas UML du projet dans son état actuel :

<gallery style="margin: 0 auto;">
Fichier:Formes_package_Class_diagram_v3.png|Schéma UML du package ''formes''
Fichier:Machine_package_Class_diagram_v3.png|Schéma UML du package ''machine''
Fichier:Management_package_Class_diagram_v2.png|Schéma UML du package ''management''
Fichier:Robot_package_Class_diagram_v2.png|Schéma UML du package ''robot''
</gallery>

===Semaine 9===

Nous avons dû concevoir une fonction de récupération de distance entre deux entités.
Les robots étant les seules entités mobiles, nous ne calculons que la distance entre un robot et une autre entité.
La distance entre deux robots, soit deux cercles, est facile à déterminer. Nous récupérons les points des deux cercles étant sur la droite passant par les centres des dits cercles. Puis nous appliquons le calcul de distance.

Lorsqu'il s'agit de calculer la distance la plus courte avec un rectangle, c'est un peu plus compliqué et très rapidement le nombre de calculs devient très grand. Nous avons choisi une stratégie calculatoire réduisant le nombre de calculs avec les conseils de Mme Nathalie Delfosse.

Le problème est de trouver la distance la plus courte entre les deux formes ainsi que les points concernés.

[[Fichier:GD_1.png|500px|center|texte descriptif]]

Nous pouvons facilement tracer la zone de collision, soit la zone qui permet de dire qu'il y a une collision si le centre du robot est dessus.

[[Fichier:GD_2.png|500px|center|texte descriptif]]

Ensuite on découpe l'espace en 8 zones en prolongeant les cotés du rectangle pour en faire des droites.

[[Fichier:GD_3.png|500px|center|texte descriptif]]

Lorsqu'un robot se situe en zone n°1 alors la distance la plus proche est celle qui sépare le cercle de l'angle le plus proche du rectangle. Donc (S2) est cette distance avec la résolution du système composé de la droite par le centre du cercle et l'angle, et le cercle. Nous obtenons alors le point du cercle le plus proche du rectangle.

(S2)
(x−xc)²+(y−yc)²==R²
y= ax+b

Dans la zone n°2, la distance la plus courte est une droite verticale, ce qui nous donne facilement le point du cercle et le point du rectangle.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Dans la zone n°3, on observe le même comportement qu'avec la zone n°2 mais cette fois-ci à l'horizontal, les équations sont donc les mêmes avec une inversion des x en y et inversement.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Cette semaine nous avons aussi travaillé sur la production elle-même en complétant les classes du package ''machine''. Nous avons ainsi ajouté à chaque sous-classe une fonction ''setup'' qui permet d'initialiser la machine, la plupart du temps avec une couleur d'anneau ou de base, et pour la ''DeliveryStation'' avec un numéro de porte.

Ces fonctions seront ensuite appelées dans un nœud ''machines_node'' du package ''management''.

===Semaine 10===

Cette semaine, nous avons avancé sur la simulation en permettant à une 'Equipe' d'afficher ses six machines et ses trois robots. Le 'Manager', lui, affiche les deux équipes; nous avons ainsi tous les acteurs d'un match sur le même terrain.

Nous avons également installé la Referee Box, dans la prévision du travail sur la communication entre simulation et celle-ci, mais aussi pour pouvoir utiliser des types de messages particuliers du package 'llsf_msgs' inclus avec la Referee Box.

En effet, les machines changent d'état en fonction des commandes qu'elles reçoivent. En effet, les équipes doivent remplir des commandes tout au long du match, et les robots ordonnent ainsi aux machines de produire des types de pièces particuliers.
Ils commencent par envoyer un message de 'setup' qui va indiquer à la machine quel type de pièce préparer. À ce moment là la machine change d'état (état occupé) et ceci est reflété dans la couleur de son feu.
Lorsque la pièce est disponible, la machine rechange d'état pour être de nouveau disponible.

Il existe également d'autres types d'états, comme lorsque la machine est 'down' lors d'une maintenance programmée décidée par la Referee Box au début du match, lorsque la machine vient de recevoir un ordre ou encore lorsqu'un robot tente de l'utiliser sans lui envoyer de message de 'setup, elle est alors hors-service pendant un certain moment.

Lié à la Referee Box, nous avons du chercher à synchroniser le temps de celle-ci avec le simulateur. Cependant en observant le code du simulateur Gazebo (actuellement non fonctionnel) et la manière de communiquer avec l'arbitre, nous avons conclu que nous n'avions pas le temps de le faire.

Nous avons du implémenter le système de gestion de collision. Graphiquement et avec les équations, il est simple pour un être humain de comprendre le fonctionnement. Cependant le code impose plus de restriction. Nous avons donc décomposer la théorie en plusieurs. Une fonction pour obtenir la distance entre deux points, plusieurs fonctions permettant de déterminer les points les plus proche entre chaque structure. Et enfin une fonction déterminant si il y a collision.

Pour les cercle, il faut déterminer l'équation de la droite qui passe par le centre des deux cercles. Puis résoudre le système correspondant à l'intersection de la droite et du cercle qui nous odnne une équation du second degré. On choisit alors le point le plus proche de l'autre cercle.

Pour un cercle et un rectangle, on test zone par zone. Nous ne sommes pas obligés de nous placer dans le référentiel du rectangle. Au lieu de ça nous allons vérifier zone par zone l'appartenance du cercle à celles-ci grâce aux systèmes composés de trois droites (les cotés du rectangles) pour les zones latérales et de deux pour les zones d'angles. Ces systèmes s'excluent les uns les autres. Si le cercle n'est dans aucune zone alors il est à l'intérieur du rectangle. Ce qui est soit une situation impossible soit une collision. Lorsque l'on à la zone on résout le système correspondant (décrit lors de la semaine 9). Cette implémentation n'a pas été faite entièrement durant cette semaine. Nous l'avons continué lors du temps supplémentaire.

===Heures supplémentaires===

Nous avons commencé par ajouter l'affichage des feux (composés d'un rectangle et de trois cercles rouge, jaune, vert).
En fonction de l'état de la machine à laquelle ils appartiennent, les couleurs affichés changent. D'après le règlement, si tout va bien le feu sera vert fixe, si la machine est occupée il sera jaune fixe et si la machine est en maintenance programmée il sera rouge fixe. Si la machine vient de recevoir un ordre, il sera vert clignotant et si elle est hors-service il sera clignotant jaune et rouge.

C'est pourquoi nous avons aussi implémenté le clignotement de celui-ci qu'il est possible de voir dans la vidéo ci-dessous.

Enfin, les machines seront positionnées de différentes manières au début d'un match, il est donc nécessaire que le feu associé ait la même rotation que sa machine.
Nous avons ainsi commencé par permettre aux cercles du haut et du bas d'effectuer un rotation autour du cercle central. Une fois la chose faite, nous avons modifié la rotation d'une machine. En effet, jusque là elle était implémentée de la même manière que pour les robots, or ceux-ci se déplacent et pas notre machine. Il n'est donc pas nécessaire que la flèche soit en rotation mais plutôt qu'elle soit positionnée de manière fixe (mais cela reste modifiable dans le code) et que ce soit le rectangle de la machine qui effectue une rotation sur lui-même. Il en va de même pour le rectangle du feu.

Enfin, nous avons dû gérer le positionnement du feu par rapport au rectangle : il faut, lorsque la machine effectue une rotation, calculer la position de son coin inférieur gauche et positionner le feu par rapport à celui-ci.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_feu_45_degres.png|Feu en rotation
Fichier:Rviz_screenshot_machine_135_degres.png|Machine et son feu en rotation
Fichier:Rviz_screenshot_machine_state_down.png|Machine en état de maintenance programmée
Fichier:Rviz_screenshot_machine_state_busy.png|Machine occupée
Fichier:Rviz_screenshot_machine_state_ok.png|Machine disponible
Fichier:Feu_clignotant.mp4|Vidéo du feu qui clignote
</gallery>

== Fichiers Rendus ==

IMA4 2016/2017 P20

2017-05-09T21:34:08Z

Mbutaye : /* Planning des tâches */

__TOC__
 
==Cahier des charges==

Ce cahier des charges a pour objectif de définir le projet, ce qui est attendu ainsi que les contraintes de conception qui lui sont associées.

===Présentation générale du projet===

Le projet consiste à concevoir et développer un environnement virtuel de test pour l'Association de Robotique de Polytech Lille (ARPL). Ce simulateur doit reproduire les conditions de participation à la Logistic League de manière à pouvoir obtenir rapidement des données et tester le code ainsi que les stratégies de jeu utilisés par les robots.

====Contexte====
Ce simulateur est un outil développé dans le cadre de la RoboCup et plus particulièrement de la Logistic League. La RoboCup est une compétition internationale de robotique dans laquelle on voit beaucoup d'entreprises et de robots connus tel que NAO. Cette compétition a pour but de mettre en avant les évolutions en matière de robotique ainsi que les qualités des organismes participants.

La Logistic League est une des différentes épreuves proposées. L'objectif est de repérer le terrain puis de produire des objets avec différents éléments fournis par des machines et à livrer dans des plages de temps données. Une RefereeBox ou boîte arbitre sert à la coordination ainsi qu'à l'arbitrage. C'est cette boite qui va informer le robots des différents objets à construire avec la date de livraison demandée. Elle va également donner leur rôles aux machines présentes sur le terrain. L'arbitre va enregistrer les horaires de dépôt des objets et la position de chacune des machines lors de la compétition.

Celle-ci se déroule sur une piste de la taille d'une salle moyenne. Chaque équipe peut utiliser jusqu'à trois robots Robotino 3 pour réaliser les tâches demandées. Sur la piste, à part les robots, se trouvent seulement des machines dites de production ou de livraison. Elles vont servir soit à se procurer un élément nécessaire à la production de l'objet final soit à livrer celui-ci lorsqu'il est terminé.

====Objectif du projet====

Ce projet va permettre de fournir à l'équipe de l'ARPL un simulateur léger et complet, leur permettant de simuler en un court laps de temps un match entier ou partiel et de tester leur code et leur stratégie. Cela leur permettra de développer plus rapidement et efficacement.

====Description du projet====

Le simulateur devra répondre à un certain nombre de critères. Tout d'abord il lui faudra pouvoir simuler toutes les entités présentes sur la piste lors d'un match. Nous parlons des robots et des machines mais également des capteurs et des conditions de jeu.

Nous devrons faire en sorte que le simulateur puisse facilement intégrer le code de contrôle des robots afin de le tester. De plus il faut permettre à l'utilisateur de gérer les parties du code à tester ainsi que de changer les conditions et paramètres de simulation afin de ne tester que certaines partie du code (par exemple en excluant la gestion des collisions). Nous inclurons une gestion des phases de jeu (Découverte et Production) dans ce but. De ce point de vue l'idéal serait de générer un launchfile et de permettre à l'utilisateur de gérer l'utilisation des nœuds un par un.

En sus, le simulateur gérant les robots de l'équipe adverse, il aura une fonctionnalité de sauvegarde des configurations que ce soit pour le code ou les stratégies afin de comparer l'évolution des performances.

Le simulateur a certaines contraintes afin d'être utilisable et utile. Il doit opérer une compression du temps c'est à dire réaliser la simulation d'un match en moins de temps qu'une durée normale de match. Il s'agit d'obtenir des données représentant la réalité en un cours laps de temps. La communication avec la RefereeBox est indispensable. Celle-ci étant fourni par les organisateurs de la compétition nous n'avons pas à la simuler mais nous devons communiquer avec elle pour rendre la simulation plus réaliste.

====Choix techniques : matériel et logiciel====

Nous n'avons pas besoin de matériel hormis d'ordinateurs afin de programmer.

Dû à la compétition et aux choix de développement de l'équipe de l'ARPL, nous allons programmer en C++ avec les bibliothèques QT ainsi que le middleware ROS, une surcouche de programmation destinée à la programmation de robots.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

*Simuler les différentes entités
** les Robotinos ;
** les machines ;
** l'environnement.

*Gérer l'interfaçage entre le simulateur et le code des Robots
** lire et lancer le méta-paquet ;
** identifier les différents parties du code ;
** proposer l'activation/désactivation de ces parties et créer un launchfile en conséquence ;
** créer un système de sauvegarde de tout code interfacé permettant sa réutilisation.

*Simuler un match
** communiquer avec la RefereeBox et recevoir les différents ordres de celle-ci ;
** gérer les machines et la communication avec la RefereeBox ;
** gérer l'équipe de l'utilisateur et son interaction avec le reste de la simulation ;
** gérer l'équipe adverse et son interaction avec le reste de la simulation.

*Paramétrage avancé de la simulation
** proposer différents modes de simulations ;
** activation/déssactivation des paramètres de la simulation ;
** gestion des phases.

*Interface utilisateur
** fournir des données utilisables et intéressantes sur la simulation ;
** créer une GUI ergonomique ;
** importer les données de la simulation sur la GUI pour une meilleure analyse de celle-ci.

====Calendrier====

Répartition du temps consacré au projet (120h/personne) :

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures supplémentaires !! Total
|-
| Définition cahier des charges
| 2
|
|
|
|
|
|
|
|
|
|
|
|2
|-
|Mise à niveau matérielle et intellectuelle
|
|13
|
|
|
|1
|
|
|
|
|
|
|14
|-
|Conception théorique
|
|5
|7
|4
|2
|
|
|0,5
|
|13
|2
|
|33.5
|-
|Programmation de la simulation
|
|
|8
|15
|16
|4
|8
|6
|10
|6
|10
|18
|101
|-
|Programmation de l'affichage avec rviz
|
|
|
|
|
|5
|8
|13
|6
|
|
|5
|37
|-
|Wiki
|
|
|0,5
|1,5
|1,5
|0,5
|2
|0,5
|3
|0,5
|0,5
|2
|12,5
|-
|Réunions tuteurs
|2
|
|
|
|2
|2
|
|
|
|
|
|
|6
|-
|Total
|4
|18
|15,5
|20,5
|21,5
|12,5
|18
|20
|19
|19,5
|12,5
|25
|206
|}

==Planning des tâches==

{| class="wikitable"
!Tâche !! Date prévue !! Avancement !! Commentaires
|-
| Affichage des formes avec Rviz
| 01/03/2017
| Terminé
| Cercle & Rectangle
|-
| Affichage d'un robot
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Affichage d'une machine
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Gestion du temps
| 08/03/2017
| Terminé
| Bornes de facteurs possibles à déterminer
|-
| Déplacement d'un robot
| 22/03/2017
| Terminé
| Vitesse et déplacement au point; Besoin d'interfaçage sur le code ARPL
|-
| Affichage de l'orientation de l'entité
| 13/03/2017
| Terminé
| Affichage d'une forme Flèche dont l'orientation change avec celle de l'entité. Grise. Orientation en degrés.
|-
| Lecture et affichage de la map
| 19/03/2017
| Terminé
| Affichage de la map, des murs et des zones interdites.
|-
| Communication RefBox
| 01/04/2017
| Débuté
| Communication en place pour l'affichage des machines à leur position de départ.
|-
| Gestion Collision
| 01/04/2017
| Inachevé
| Implémentation de la fonction de regroupement
|}

==Avancement du Projet==

===Semaine 1===
Nous avons commencé par installer ROS et tout ce dont nous avons besoin pour travailler correctement. Nous avons également suivi des [http://wiki.ros.org/ROS/Tutorials tutoriels] pour apprendre à utiliser ROS.

Pour pouvoir travailler en binôme sans problèmes et pour que nos encadrants puissent suivre notre avancement et tester le logiciel, nous avons utilisé le logiciel de gestion de versions Git, sur lequel on publie notre code au fur et à mesure.

Nous n'avions pas encore de dépôt sur celui-ci, donc nous avons commencé par réfléchir à la structure de notre projet.
Nous commencerons par implémenter la phase d'exploration, ce qui comprend aussi le déplacement du robot, la détection de machines et de feux ainsi qu'une interface utilisateur basique.

En effet, le match oppose deux équipes ayant jusque trois robotinos qui s'affrontent lors de deux phases. La première est la phase d'exploration, durant laquelle les robots doivent trouver les machines de leur équipe en explorant le terrain. Ils doivent annoncer la position des machines et les signaux des feux de celles-ci : chaque machine, peu importe son type, possède un feu tricolore (rouge, jaune, vert) qui durant la phase d'exploration aura une combinaison de lumières allumées aléatoirement (au moins une doit l'être).

La création d'un simulateur passe par la réflexion sur les besoins en conception du simulateur (décris en partie ci-dessus). Nous avons donc passé un certain temps à schématiser la structure de notre simulateur et à en assimiler les besoins et l'ordre de création.

===Semaine 2===
Nous avons récupéré un dépôt Git (nommé ''logistic-sim'') sur lequel travailler auprès de nos encadrants, nous pouvons donc commencer la programmation cette semaine.

Ceci étant notre premier projet mêlant ROS et Git, nous avons tenté de créer la structure du projet mais avons vite rencontré quelques difficultés.
Nous avons ensuite compris qu'il était nécessaire de d'abord créer un environnement de travail ROS pour le projet, dans lequel on clône ensuite le dépôt Git localement.

Nous obtenons ainsi la structure de projet suivante :
* Workspace ROS
** build
** devel
** src
*** CMakeLists.txt
*** logistic-sim

Les dossiers build, devel, src et CMakeList.txt sont des fichiers et dossiers générés par ''Catkin'', un outil permettant de créer des paquets ROS facilement.

Nous avons ensuite décidé de séparer le code du projet en différents dossiers en fonction des tâches à effectuer :
* '''Entites''' pour simuler les différentes entités (Robotinos, machines, environnement...)
* '''Gestion_Code''' pour gérer l'interfaçage entre le simulateur et le code des robots
* '''Match''' pour simuler le déroulement d'un match
* '''GUI''' pour l'interface utilisateur avec le framework Qt

Dans chacun de ces dossiers, nous créerons des ''packages'' contenant les différentes fonctionnalités du projet.

Chaque ''package'' a la structure suivante :
* CMakeLists.txt
* include pour les fichiers .h
* package.xml
* README.md
* src pour les classes et nodes .cpp
* launch pour les launchfiles

Dans un premier temps, on commence par la gestion de la position du robot et la reconnaissance des feux.

===Semaine 3===

Nous avons avancé sur la programmation de la gestion de la position du robot et de la reconnaissance des feux.

Nous avons décrit nos classes par des schémas UML avec l'outil gratuit ''Modélio'' pour créer une documentation facilement accessible. Les commentaires des fonctions, classes et fichiers au format ''Doxygen'' nous permettront également de générer une documentation du projet sous format HTML notamment.

Nous suivons aussi la normalisation du code donnée par l'ARPL pour avoir les mêmes conventions de nommage partout.

Nous avons décidé de créer un nouveau package ''match'' qui contiendra les nœuds correspondants aux différentes phases de jeu, et avons donc par conséquent commencé par créer un nœud pour la phase d'exploration.

Nous avons également commencé à réfléchir à la façon dont les informations sont communiquées dans le match : il y a un arbitre, la ''Referee Box'' qui permet de faire communiquer le simulateur et les robots jouant le match. En effet, l'arbitre prend les décisions importantes (placement des machines au début du jeu etc.) et c'est à lui que les robots s'adressent. Nous devons donc aussi communiquer avec lui pour recevoir certaines informations (par exemple les informations de base de la phase d'exploration) et les retransmettre dans le simulateur aux nœuds qui en auront besoin.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v1.png|Schéma UML du package ''machine''
Fichier:Formes_package_Class_diagram_v1.png|Schéma UML du package ''formes''
</gallery>

===Semaine 4===

Cette semaine, nous avons créé plusieurs nouveaux packages et modifié ceux qui avaient déjà été créés.

Nous avons créé la classe Cercle dans le package ''formes'', nous pouvons donc maintenant utiliser deux formes différentes, le rectangle et le cercle.
La classe Entite a elle aussi été rajoutée. En effet, certains attributs des machines sont communs avec ceux des robots; cette classe nous permet de les rassembler et les classes Machine et Robot hériteront ainsi de Entite.

Un nouveau package ''management'' a également fait son apparition. Il contiendra les classes Equipe et Manager. Le Manager sera chargé de créer les équipes et permettra d'y accéder partout dans le code, mais aussi de procéder aux différentes initialisations lors du démarrage d'une nouvelle phase.

Au package ''management'' s'ajoute le nouveau package ''robot'' dont le rôle est de simuler les robotinos lors du match.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v2.png|Schéma UML du package ''machine''
Fichier:Robot_package_Class_diagram_v1.png|Schéma UML du package ''robot''
Fichier:Formes_package_Class_diagram_v2.png|Schéma UML du package ''formes''
Fichier:Management_package_Class_diagram_v1.png|Schéma UML du package ''management''
</gallery>

Nous avons également rendu visite à l'un de nos tuteurs de stage pendant la semaine dans le but d'obtenir un premier retour sur notre travail et l'avancement du projet.

Nous avons pu effectuer immédiatement quelques modifications nécessaires suite aux commentaires de notre tuteur. Nous avons dû, par exemple, clôner leur projet dans le même espace de travail que le notre pour pouvoir réutiliser certains paquets de messages déjà créés. Cela permettra une meilleure compatibilité. D'autres modifications concernaient entre autres les conventions de nommage de certaines classes et l'ajout d'un dossier supplémentaire dans le dossier include de chaque package portant le nom de celui-ci, pour ne pas avoir de conflits quant au nommage des fichiers.

Une réunion avec toute l'équipe des tuteurs a été prévue pour la semaine 5.

===Semaine 5===

La semaine a commencé par une réunion avec l'équipe de l'ARPL se chargeant d'encadrer notre projet, c'est-à-dire Vincent et Thomas. Nous avons discuté ensemble de l'avancement du simulateur et de l'ordre dans lequel effectuer les tâches. Ils nous également demandé de créer un planning de nos tâches avec la date prévue pour chacune; ils auront en effet besoin de modifier leur code à certains endroits pour pouvoir utiliser le simulateur (nous n'aurons pas besoin de tous les nœuds, certains comme la détection Laser nous étant inutiles) et souhaiteraient savoir lorsque nous seront prêt à tester de nouvelles fonctionnalités.

Nous nous sommes lancés dans l'affichage des formes avec l'outil ''rviz'', qui permet de visualiser en 3D les messages de type ''visualisation_msgs'' qui lui sont envoyés sur le topic associé. Ces messages sont disponibles en différents types. Pour afficher les formes nous utiliseront le format ''Marker'' qui permet d'afficher un objet en 3D (cubes, sphères, flèches, cylindres) ou en 2D en lui donnant un z de 0.

Nous avons donc commencé par faire les tutoriels sur l'utilisation de rviz puis par ajouter le code nécessaire à l'affichage des formes. Nous avons ainsi décidé d'ajouter la variable du message de type ''Marker'' dans la classe Forme; celle-ci sera accessible par toutes les classes filles de Forme, notamment Cercle et Rectangle. Nous avons également créé une méthode ''display'' qui sera chargée de mettre à jour la position de la forme et de publier le message. Les différents ''setters'' des classes filles modifieront également le message pour qu'il soit à jour lors de l'envoi.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_rectangle.png|Affichage de la forme ''Rectangle'' dans Rviz
Fichier:Rviz_screenshot_cercle.png|Affichage de la forme ''Cercle'' dans Rviz
</gallery>

===Semaine 6===

Cette semaine, nous continuons d'améliorer l'affichage en programmant cette fois-ci la classe ''Robot'' (qui possède une forme, étant une Entité) pour pouvoir visualiser le robot avec rviz. Nous avons donc ajouté une fonction ''display'' à ''Entite'', faisant elle-même appel à la fonction ''display'' de sa forme; ce qui permettra un affichage plus facile de l'objet.

Nous avons également ajouté une forme ''Texte'' pour afficher du texte informatif sur les formes (par exemple, une lettre et un id pour une entité, "R1" dans le cas du premier robot de chaque équipe). Ce texte est affiché en cyan ou en magenta, en fonction de la couleur de l'équipe. Les noms des ''markers'' de la forme et du texte eux aussi dépendent du type de l'entité.

Enfin, nous avons permis au entités de type Machine de gérer leur affichage. Pour cela, nous avons dû créer une classe fille de cette entité pour pouvoir tester son affichage. Le choix s'est porté sur les machines de type BS (Base Station).

En cours de route, nous avons été confrontés à un problème au niveau de l'affichage en 2D. Il semblait logique que la hauteur des objets (en z) soit égale à 0 pour un affichage 2D, mais il s'est avéré que la couleur de l'objet était alors imprévisible (plus souvent noir que de la bonne couleur). Il en fait fallu laisser une légère épaisseur (0.001 mètres dans notre cas) pour que la couleur s'affiche correctement.

Un de nos objectifs était aussi de gérer l'affichage de l'orientation de nos entités. En effet, cela semble essentiel pour les robots par exemple, représentés par des ronds et pouvant se déplacer. Nous avons ainsi créé un nouveau marker ''Fleche''; il était également possible de changer le type de marker en ''interactive marker'' ce qui aurait permis l'affichage de flèches de direction, mais celles-ci permettaient de modifier la position de l'objet et n'étaient disponibles qu'en multiple de 2 (déplacement sur un axe). Le choix s'est donc porté sur l'utilisation d'un marker classique dont on change l'orientation en même temps que celle de l'entité.
Nous avons rencontré quelques soucis quant à la gestion de l'orientation du marker, celle-ci étant un ''quaternion'' (x, y, z, w) alors que nous souhaitons donner l'angle en degrés (ou en radians éventuellement); la documentation n'est pas forcément facile à trouver pour ROS.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_robot.png|Affichage de l'entité ''Robot'' dans Rviz
Fichier:Rviz_screenshot_machine.png|Affichage de l'entité ''BaseStation'' dans Rviz
Fichier:Rviz_screenshot_fleche.png|Affichage de l'entité ''Robot'' avec une forme ''Fleche'' dans Rviz
</gallery>

Nous avons dû corriger nos constructeurs pour être le plus efficace possible et remplir au maximum les besoins des futurs fonctions.

La problématique rendant nécessaire une gestion du temps vient du besoin de l'ARPL de pouvoir contrôler la vitesse de simulation et donc de pouvoir jouer un match très rapidement afin d'observer le comportement de leur code.
Nous avons commencé et fini la gestion du temps. ROS intègre une interface de temps qui se cale sur la machine qui lance ROS.
Pour que plusieurs machines suivent le même temps il faut opérer une synchronisation des temps. Cependant lors de la simulation tous les robots auront leur référentiel temporel sur la même machine ce qui rend une synchronisation inutile.

Il existe un topic ''clock'' qui sert pour les simulations. En forçant nos nœuds à utiliser le temps de simulation, nous avons une échelle temporelle utilisable et synchronisée. Nous avons donc un nœud qui va publier sur ce topic le temps qui sera initialisé à 0 en début de match.

Un paramètre d'environnement ROS sert à régler le facteur d'accélération de la simulation par rapport au temps réel. Il est modifiable à tout instant et est initialisé en premier dans le launchfile.

===Semaine 7===

Nous nous sommes attaqués à l'affichage du terrain dans rviz.

Pour cela, nous pouvions nous inspirer de code écrit par l'ARPL permettant de charger une carte depuis un fichier ''.yaml''. Certains de leurs packages nous ont été utiles, mais d'autres se sont avérés inutilisables tels quels à cause d'erreurs tantôt de "référence indéfinie" à un fichier, tantôt de "redéfinition" du même fichier (la cause de ces erreurs reste pour le moment toujours un mystère).
Nous avons donc opté, pour pouvoir avancer rapidement sur le projet, d'utiliser tel quel ce qu'il était possible d'utiliser, et sinon de recopier les fonctions nécessaires dans notre package. Certaines fonctions nécessitaient d'ailleurs de toute façon des modifications, car dans notre simulateur nous gérons aussi l'affichage de la carte alors qu'eux ne faisaient que la charger.

Un fichier ''.yaml'' a la syntaxe suivante :
field:
name: robocup_simulator
size: [14, 9, 0.0]
gradient:
distance: 0.35
minValue: 0
walls:
bottom1:
start: [-6, 0, 0.0]
end: [-4, 0, 0.0]

Nous avons donc commencé par charger le fichier en mémoire en le passant en paramètre à un ''launchfile'' lançant le nœud chargé de lire et d'afficher la carte. Ensuite, en faisant appel à des ''param'' (paramètres) du nœud actuel et en leur donnant le nom du champs (''name'' par exemple), on peut récupérer les valeurs du fichiers voulues.

Nous avons ainsi créé une classe ''Carte'' pour gérer le chargement des données depuis le fichier et toutes les fonctions utilitaires associées, mais permettant aussi d'afficher la carte grâce à une fonction ''display'' de même fonctionnement que celles créées précédemment pour les entités.

Pour l'affichage sur rviz, nous nous sommes servis du type d'objet ''Map'' pour visualiser le sol du terrain (en blanc ci-dessous). Nous avons également créé un vecteur de Rectangles pour afficher les murs (en bleu foncé ci-dessous) et un vecteur de Rectangles pour les zones interdites au robot (en noir).

Nous aurions aimé mettre à jour la taille de la grille affichée en fonction de la taille de la carte, mais il s'avère que c'est impossible, la grille ne provenant pas d'un message publié.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_map.png|Affichage du terrain de jeu dans Rviz
</gallery>

===Semaine 8===

Nous avons complété la fonction de gestion de la vitesse. Il n'y a plus de nœud pour gérer les déplacements au profit d'un nœud gérant chaque robot.
Les robots envoient un vecteur "twist" pour donner leur commande vitesse, soit deux vecteurs vitesse 3D, l'un pour la vitesse linéaire et l'autre pour la vitesse angulaire.
Cependant ce vecteur vitesse est paramétré dans le repère du robot, c'est-à-dire avec le vecteur x dirigé dans la direction de l'orientation du robot.
Pour nos calculs nous nous servons du repère originel, que ce soit pour placer les entités ou les déplacer. Cela facilite les calculs dans la simulation.
Ainsi nous devons transposer les vecteurs vitesse reçus pour les appliquer à notre repère.

La simulation fonctionnant en 2D nous simplifions les données en utilisant un seul vecteur 3D (x et y pour le déplacement linéaire et z pour le changement d'orientation soit la vitesse angulaire autour de l'axe z).
La transposition n'est nécessaire que pour les déplacements linéaires, donc nous utilisons de la trigonométrie simple et nous ajoutons le déplacement ainsi obtenu à la position actuelle, ce qui donne :

v_x = v_x1*cos(orientation_radian) - v_y1*sin(orientation_radian)

v_y = v_x1*sin(orientation_radian) + v_y1*sin(orientation_radian)

x_new = v_x *delta_t + x

y_new = v_y *delta_t + y

orientation_new = (v_angulaire*delta_t + orientation) [360]

Nous avons également apporté des modifications aux flèches et textes; en effet, maintenant que le déplacement des robots est possible, nous pouvons effectuer des tests.
Il s'avère que nous ne modifions pas la position des flèches et textes, le robot s'éloignait alors d'eux lorsqu'il se déplaçait.
Nous avons donc ajouté les quelques modifications nécessaires pour que ces formes suivent l'entité en déplacement.

Nous avons aussi commencé à compléter le package ''machine'' pour lui ajouter les sous-classes de Machine représentant les différentes machines (MPS) du jeu (BaseStation, CapStation, RingStation, DeliveryStation).
La BaseStation permettra au robot de récupérer un objet de type base, la RingStation d'y empiler des anneaux de couleurs différentes en fonction des commandes reçues, la CapStation de déposer un chapeau au sommet de l'objet et enfin on l'apporte à la DeliveryStation.

Nous avons complété ci-dessous les schémas UML du projet dans son état actuel :

<gallery style="margin: 0 auto;">
Fichier:Formes_package_Class_diagram_v3.png|Schéma UML du package ''formes''
Fichier:Machine_package_Class_diagram_v3.png|Schéma UML du package ''machine''
Fichier:Management_package_Class_diagram_v2.png|Schéma UML du package ''management''
Fichier:Robot_package_Class_diagram_v2.png|Schéma UML du package ''robot''
</gallery>

===Semaine 9===

Nous avons dû concevoir une fonction de récupération de distance entre deux entités.
Les robots étant les seules entités mobiles, nous ne calculons que la distance entre un robot et une autre entité.
La distance entre deux robots, soit deux cercles, est facile à déterminer. Nous récupérons les points des deux cercles étant sur la droite passant par les centres des dits cercles. Puis nous appliquons le calcul de distance.

Lorsqu'il s'agit de calculer la distance la plus courte avec un rectangle, c'est un peu plus compliqué et très rapidement le nombre de calculs devient très grand. Nous avons choisi une stratégie calculatoire réduisant le nombre de calculs avec les conseils de Mme Nathalie Delfosse.

Le problème est de trouver la distance la plus courte entre les deux formes ainsi que les points concernés.

[[Fichier:GD_1.png|500px|center|texte descriptif]]

Nous pouvons facilement tracer la zone de collision, soit la zone qui permet de dire qu'il y a une collision si le centre du robot est dessus.

[[Fichier:GD_2.png|500px|center|texte descriptif]]

Ensuite on découpe l'espace en 8 zones en prolongeant les cotés du rectangle pour en faire des droites.

[[Fichier:GD_3.png|500px|center|texte descriptif]]

Lorsqu'un robot se situe en zone n°1 alors la distance la plus proche est celle qui sépare le cercle de l'angle le plus proche du rectangle. Donc (S2) est cette distance avec la résolution du système composé de la droite par le centre du cercle et l'angle, et le cercle. Nous obtenons alors le point du cercle le plus proche du rectangle.

(S2)
(x−xc)²+(y−yc)²==R²
y= ax+b

Dans la zone n°2, la distance la plus courte est une droite verticale, ce qui nous donne facilement le point du cercle et le point du rectangle.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Dans la zone n°3, on observe le même comportement qu'avec la zone n°2 mais cette fois-ci à l'horizontal, les équations sont donc les mêmes avec une inversion des x en y et inversement.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Cette semaine nous avons aussi travaillé sur la production elle-même en complétant les classes du package ''machine''. Nous avons ainsi ajouté à chaque sous-classe une fonction ''setup'' qui permet d'initialiser la machine, la plupart du temps avec une couleur d'anneau ou de base, et pour la ''DeliveryStation'' avec un numéro de porte.

Ces fonctions seront ensuite appelées dans un nœud ''machines_node'' du package ''management''.

===Semaine 10===

Cette semaine, nous avons avancé sur la simulation en permettant à une 'Equipe' d'afficher ses six machines et ses trois robots. Le 'Manager', lui, affiche les deux équipes; nous avons ainsi tous les acteurs d'un match sur le même terrain.

Nous avons également installé la Referee Box, dans la prévision du travail sur la communication entre simulation et celle-ci, mais aussi pour pouvoir utiliser des types de messages particuliers du package 'llsf_msgs' inclus avec la Referee Box.

En effet, les machines changent d'état en fonction des commandes qu'elles reçoivent. En effet, les équipes doivent remplir des commandes tout au long du match, et les robots ordonnent ainsi aux machines de produire des types de pièces particuliers.
Ils commencent par envoyer un message de 'setup' qui va indiquer à la machine quel type de pièce préparer. À ce moment là la machine change d'état (état occupé) et ceci est reflété dans la couleur de son feu.
Lorsque la pièce est disponible, la machine rechange d'état pour être de nouveau disponible.

Il existe également d'autres types d'états, comme lorsque la machine est 'down' lors d'une maintenance programmée décidée par la Referee Box au début du match, lorsque la machine vient de recevoir un ordre ou encore lorsqu'un robot tente de l'utiliser sans lui envoyer de message de 'setup, elle est alors hors-service pendant un certain moment.

Lié à la Referee Box, nous avons du chercher à synchroniser le temps de celle-ci avec le simulateur. Cependant en observant le code du simulateur Gazebo (actuellement non fonctionnel) et la manière de communiquer avec l'arbitre, nous avons conclu que nous n'avions pas le temps de le faire.

Nous avons du implémenter le système de gestion de collision. Graphiquement et avec les équations, il est simple pour un être humain de comprendre le fonctionnement. Cependant le code impose plus de restriction. Nous avons donc décomposer la théorie en plusieurs. Une fonction pour obtenir la distance entre deux points, plusieurs fonctions permettant de déterminer les points les plus proche entre chaque structure. Et enfin une fonction déterminant si il y a collision.

Pour les cercle, il faut déterminer l'équation de la droite qui passe par le centre des deux cercles. Puis résoudre le système correspondant à l'intersection de la droite et du cercle qui nous odnne une équation du second degré. On choisit alors le point le plus proche de l'autre cercle.

Pour un cercle et un rectangle, on test zone par zone. Nous ne sommes pas obligés de nous placer dans le référentiel du rectangle. Au lieu de ça nous allons vérifier zone par zone l'appartenance du cercle à celles-ci grâce aux systèmes composés de trois droites (les cotés du rectangles) pour les zones latérales et de deux pour les zones d'angles. Ces systèmes s'excluent les uns les autres. Si le cercle n'est dans aucune zone alors il est à l'intérieur du rectangle. Ce qui est soit une situation impossible soit une collision. Lorsque l'on à la zone on résout le système correspondant (décrit lors de la semaine 9). Cette implémentation n'a pas été faite entièrement durant cette semaine. Nous l'avons continué lors du temps supplémentaire.

===Heures supplémentaires===

Nous avons commencé par ajouter l'affichage des feux (composés d'un rectangle et de trois cercles rouge, jaune, vert).
En fonction de l'état de la machine à laquelle ils appartiennent, les couleurs affichés changent. D'après le règlement, si tout va bien le feu sera vert fixe, si la machine est occupée il sera jaune fixe et si la machine est en maintenance programmée il sera rouge fixe. Si la machine vient de recevoir un ordre, il sera vert clignotant et si elle est hors-service il sera clignotant jaune et rouge.

C'est pourquoi nous avons aussi implémenté le clignotement de celui-ci qu'il est possible de voir dans la vidéo ci-dessous.

Enfin, les machines seront positionnées de différentes manières au début d'un match, il est donc nécessaire que le feu associé ait la même rotation que sa machine.
Nous avons ainsi commencé par permettre aux cercles du haut et du bas d'effectuer un rotation autour du cercle central. Une fois la chose faite, nous avons modifié la rotation d'une machine. En effet, jusque là elle était implémentée de la même manière que pour les robots, or ceux-ci se déplacent et pas notre machine. Il n'est donc pas nécessaire que la flèche soit en rotation mais plutôt qu'elle soit positionnée de manière fixe (mais cela reste modifiable dans le code) et que ce soit le rectangle de la machine qui effectue une rotation sur lui-même. Il en va de même pour le rectangle du feu.

Enfin, nous avons dû gérer le positionnement du feu par rapport au rectangle : il faut, lorsque la machine effectue une rotation, calculer la position de son coin inférieur gauche et positionner le feu par rapport à celui-ci.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_feu_45_degres.png|Feu en rotation
Fichier:Rviz_screenshot_machine_135_degres.png|Machine et son feu en rotation
Fichier:Rviz_screenshot_machine_state_down.png|Machine en état de maintenance programmée
Fichier:Rviz_screenshot_machine_state_busy.png|Machine occupée
Fichier:Rviz_screenshot_machine_state_ok.png|Machine disponible
Fichier:Feu_clignotant.mp4|Vidéo du feu qui clignote
</gallery>

== Fichiers Rendus ==

IMA4 2016/2017 P20

2017-05-09T21:33:04Z

Mbutaye : /* Feuille d'heures */

__TOC__
 
==Cahier des charges==

Ce cahier des charges a pour objectif de définir le projet, ce qui est attendu ainsi que les contraintes de conception qui lui sont associées.

===Présentation générale du projet===

Le projet consiste à concevoir et développer un environnement virtuel de test pour l'Association de Robotique de Polytech Lille (ARPL). Ce simulateur doit reproduire les conditions de participation à la Logistic League de manière à pouvoir obtenir rapidement des données et tester le code ainsi que les stratégies de jeu utilisés par les robots.

====Contexte====
Ce simulateur est un outil développé dans le cadre de la RoboCup et plus particulièrement de la Logistic League. La RoboCup est une compétition internationale de robotique dans laquelle on voit beaucoup d'entreprises et de robots connus tel que NAO. Cette compétition a pour but de mettre en avant les évolutions en matière de robotique ainsi que les qualités des organismes participants.

La Logistic League est une des différentes épreuves proposées. L'objectif est de repérer le terrain puis de produire des objets avec différents éléments fournis par des machines et à livrer dans des plages de temps données. Une RefereeBox ou boîte arbitre sert à la coordination ainsi qu'à l'arbitrage. C'est cette boite qui va informer le robots des différents objets à construire avec la date de livraison demandée. Elle va également donner leur rôles aux machines présentes sur le terrain. L'arbitre va enregistrer les horaires de dépôt des objets et la position de chacune des machines lors de la compétition.

Celle-ci se déroule sur une piste de la taille d'une salle moyenne. Chaque équipe peut utiliser jusqu'à trois robots Robotino 3 pour réaliser les tâches demandées. Sur la piste, à part les robots, se trouvent seulement des machines dites de production ou de livraison. Elles vont servir soit à se procurer un élément nécessaire à la production de l'objet final soit à livrer celui-ci lorsqu'il est terminé.

====Objectif du projet====

Ce projet va permettre de fournir à l'équipe de l'ARPL un simulateur léger et complet, leur permettant de simuler en un court laps de temps un match entier ou partiel et de tester leur code et leur stratégie. Cela leur permettra de développer plus rapidement et efficacement.

====Description du projet====

Le simulateur devra répondre à un certain nombre de critères. Tout d'abord il lui faudra pouvoir simuler toutes les entités présentes sur la piste lors d'un match. Nous parlons des robots et des machines mais également des capteurs et des conditions de jeu.

Nous devrons faire en sorte que le simulateur puisse facilement intégrer le code de contrôle des robots afin de le tester. De plus il faut permettre à l'utilisateur de gérer les parties du code à tester ainsi que de changer les conditions et paramètres de simulation afin de ne tester que certaines partie du code (par exemple en excluant la gestion des collisions). Nous inclurons une gestion des phases de jeu (Découverte et Production) dans ce but. De ce point de vue l'idéal serait de générer un launchfile et de permettre à l'utilisateur de gérer l'utilisation des nœuds un par un.

En sus, le simulateur gérant les robots de l'équipe adverse, il aura une fonctionnalité de sauvegarde des configurations que ce soit pour le code ou les stratégies afin de comparer l'évolution des performances.

Le simulateur a certaines contraintes afin d'être utilisable et utile. Il doit opérer une compression du temps c'est à dire réaliser la simulation d'un match en moins de temps qu'une durée normale de match. Il s'agit d'obtenir des données représentant la réalité en un cours laps de temps. La communication avec la RefereeBox est indispensable. Celle-ci étant fourni par les organisateurs de la compétition nous n'avons pas à la simuler mais nous devons communiquer avec elle pour rendre la simulation plus réaliste.

====Choix techniques : matériel et logiciel====

Nous n'avons pas besoin de matériel hormis d'ordinateurs afin de programmer.

Dû à la compétition et aux choix de développement de l'équipe de l'ARPL, nous allons programmer en C++ avec les bibliothèques QT ainsi que le middleware ROS, une surcouche de programmation destinée à la programmation de robots.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

*Simuler les différentes entités
** les Robotinos ;
** les machines ;
** l'environnement.

*Gérer l'interfaçage entre le simulateur et le code des Robots
** lire et lancer le méta-paquet ;
** identifier les différents parties du code ;
** proposer l'activation/désactivation de ces parties et créer un launchfile en conséquence ;
** créer un système de sauvegarde de tout code interfacé permettant sa réutilisation.

*Simuler un match
** communiquer avec la RefereeBox et recevoir les différents ordres de celle-ci ;
** gérer les machines et la communication avec la RefereeBox ;
** gérer l'équipe de l'utilisateur et son interaction avec le reste de la simulation ;
** gérer l'équipe adverse et son interaction avec le reste de la simulation.

*Paramétrage avancé de la simulation
** proposer différents modes de simulations ;
** activation/déssactivation des paramètres de la simulation ;
** gestion des phases.

*Interface utilisateur
** fournir des données utilisables et intéressantes sur la simulation ;
** créer une GUI ergonomique ;
** importer les données de la simulation sur la GUI pour une meilleure analyse de celle-ci.

====Calendrier====

Répartition du temps consacré au projet (120h/personne) :

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures supplémentaires !! Total
|-
| Définition cahier des charges
| 2
|
|
|
|
|
|
|
|
|
|
|
|2
|-
|Mise à niveau matérielle et intellectuelle
|
|13
|
|
|
|1
|
|
|
|
|
|
|14
|-
|Conception théorique
|
|5
|7
|4
|2
|
|
|0,5
|
|13
|2
|
|33.5
|-
|Programmation de la simulation
|
|
|8
|15
|16
|4
|8
|6
|10
|6
|10
|18
|101
|-
|Programmation de l'affichage avec rviz
|
|
|
|
|
|5
|8
|13
|6
|
|
|5
|37
|-
|Wiki
|
|
|0,5
|1,5
|1,5
|0,5
|2
|0,5
|3
|0,5
|0,5
|2
|12,5
|-
|Réunions tuteurs
|2
|
|
|
|2
|2
|
|
|
|
|
|
|6
|-
|Total
|4
|18
|15,5
|20,5
|21,5
|12,5
|18
|20
|19
|19,5
|12,5
|25
|206
|}

==Planning des tâches==

{| class="wikitable"
!Tâche !! Date prévue !! Avancement !! Commentaires
|-
| Affichage des formes avec Rviz
| 01/03/2017
| Terminé
| Cercle & Rectangle
|-
| Affichage d'un robot
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Affichage d'une machine
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Gestion du temps
| 08/03/2017
| Terminé
| Bornes de facteurs possibles à déterminer
|-
| Déplacement d'un robot
| 22/03/2017
| Terminé
| Vitesse et déplacement au point; Besoin d'interfaçage sur le code ARPL
|-
| Affichage de l'orientation de l'entité
| 13/03/2017
| Terminé
| Affichage d'une forme Flèche dont l'orientation change avec celle de l'entité. Grise. Orientation en degrés.
|-
| Lecture et affichage de la map
| 19/03/2017
| Terminé
| Affichage de la map, des murs et des zones interdites.
|-
| Communication RefBox
| 01/04/2017
| Débuté
| Prise d'information sur le système
|-
| Gestion Collision
| 01/04/2017
| Inachevé
| Implémentation de la fonction de regroupement
|}

==Avancement du Projet==

===Semaine 1===
Nous avons commencé par installer ROS et tout ce dont nous avons besoin pour travailler correctement. Nous avons également suivi des [http://wiki.ros.org/ROS/Tutorials tutoriels] pour apprendre à utiliser ROS.

Pour pouvoir travailler en binôme sans problèmes et pour que nos encadrants puissent suivre notre avancement et tester le logiciel, nous avons utilisé le logiciel de gestion de versions Git, sur lequel on publie notre code au fur et à mesure.

Nous n'avions pas encore de dépôt sur celui-ci, donc nous avons commencé par réfléchir à la structure de notre projet.
Nous commencerons par implémenter la phase d'exploration, ce qui comprend aussi le déplacement du robot, la détection de machines et de feux ainsi qu'une interface utilisateur basique.

En effet, le match oppose deux équipes ayant jusque trois robotinos qui s'affrontent lors de deux phases. La première est la phase d'exploration, durant laquelle les robots doivent trouver les machines de leur équipe en explorant le terrain. Ils doivent annoncer la position des machines et les signaux des feux de celles-ci : chaque machine, peu importe son type, possède un feu tricolore (rouge, jaune, vert) qui durant la phase d'exploration aura une combinaison de lumières allumées aléatoirement (au moins une doit l'être).

La création d'un simulateur passe par la réflexion sur les besoins en conception du simulateur (décris en partie ci-dessus). Nous avons donc passé un certain temps à schématiser la structure de notre simulateur et à en assimiler les besoins et l'ordre de création.

===Semaine 2===
Nous avons récupéré un dépôt Git (nommé ''logistic-sim'') sur lequel travailler auprès de nos encadrants, nous pouvons donc commencer la programmation cette semaine.

Ceci étant notre premier projet mêlant ROS et Git, nous avons tenté de créer la structure du projet mais avons vite rencontré quelques difficultés.
Nous avons ensuite compris qu'il était nécessaire de d'abord créer un environnement de travail ROS pour le projet, dans lequel on clône ensuite le dépôt Git localement.

Nous obtenons ainsi la structure de projet suivante :
* Workspace ROS
** build
** devel
** src
*** CMakeLists.txt
*** logistic-sim

Les dossiers build, devel, src et CMakeList.txt sont des fichiers et dossiers générés par ''Catkin'', un outil permettant de créer des paquets ROS facilement.

Nous avons ensuite décidé de séparer le code du projet en différents dossiers en fonction des tâches à effectuer :
* '''Entites''' pour simuler les différentes entités (Robotinos, machines, environnement...)
* '''Gestion_Code''' pour gérer l'interfaçage entre le simulateur et le code des robots
* '''Match''' pour simuler le déroulement d'un match
* '''GUI''' pour l'interface utilisateur avec le framework Qt

Dans chacun de ces dossiers, nous créerons des ''packages'' contenant les différentes fonctionnalités du projet.

Chaque ''package'' a la structure suivante :
* CMakeLists.txt
* include pour les fichiers .h
* package.xml
* README.md
* src pour les classes et nodes .cpp
* launch pour les launchfiles

Dans un premier temps, on commence par la gestion de la position du robot et la reconnaissance des feux.

===Semaine 3===

Nous avons avancé sur la programmation de la gestion de la position du robot et de la reconnaissance des feux.

Nous avons décrit nos classes par des schémas UML avec l'outil gratuit ''Modélio'' pour créer une documentation facilement accessible. Les commentaires des fonctions, classes et fichiers au format ''Doxygen'' nous permettront également de générer une documentation du projet sous format HTML notamment.

Nous suivons aussi la normalisation du code donnée par l'ARPL pour avoir les mêmes conventions de nommage partout.

Nous avons décidé de créer un nouveau package ''match'' qui contiendra les nœuds correspondants aux différentes phases de jeu, et avons donc par conséquent commencé par créer un nœud pour la phase d'exploration.

Nous avons également commencé à réfléchir à la façon dont les informations sont communiquées dans le match : il y a un arbitre, la ''Referee Box'' qui permet de faire communiquer le simulateur et les robots jouant le match. En effet, l'arbitre prend les décisions importantes (placement des machines au début du jeu etc.) et c'est à lui que les robots s'adressent. Nous devons donc aussi communiquer avec lui pour recevoir certaines informations (par exemple les informations de base de la phase d'exploration) et les retransmettre dans le simulateur aux nœuds qui en auront besoin.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v1.png|Schéma UML du package ''machine''
Fichier:Formes_package_Class_diagram_v1.png|Schéma UML du package ''formes''
</gallery>

===Semaine 4===

Cette semaine, nous avons créé plusieurs nouveaux packages et modifié ceux qui avaient déjà été créés.

Nous avons créé la classe Cercle dans le package ''formes'', nous pouvons donc maintenant utiliser deux formes différentes, le rectangle et le cercle.
La classe Entite a elle aussi été rajoutée. En effet, certains attributs des machines sont communs avec ceux des robots; cette classe nous permet de les rassembler et les classes Machine et Robot hériteront ainsi de Entite.

Un nouveau package ''management'' a également fait son apparition. Il contiendra les classes Equipe et Manager. Le Manager sera chargé de créer les équipes et permettra d'y accéder partout dans le code, mais aussi de procéder aux différentes initialisations lors du démarrage d'une nouvelle phase.

Au package ''management'' s'ajoute le nouveau package ''robot'' dont le rôle est de simuler les robotinos lors du match.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v2.png|Schéma UML du package ''machine''
Fichier:Robot_package_Class_diagram_v1.png|Schéma UML du package ''robot''
Fichier:Formes_package_Class_diagram_v2.png|Schéma UML du package ''formes''
Fichier:Management_package_Class_diagram_v1.png|Schéma UML du package ''management''
</gallery>

Nous avons également rendu visite à l'un de nos tuteurs de stage pendant la semaine dans le but d'obtenir un premier retour sur notre travail et l'avancement du projet.

Nous avons pu effectuer immédiatement quelques modifications nécessaires suite aux commentaires de notre tuteur. Nous avons dû, par exemple, clôner leur projet dans le même espace de travail que le notre pour pouvoir réutiliser certains paquets de messages déjà créés. Cela permettra une meilleure compatibilité. D'autres modifications concernaient entre autres les conventions de nommage de certaines classes et l'ajout d'un dossier supplémentaire dans le dossier include de chaque package portant le nom de celui-ci, pour ne pas avoir de conflits quant au nommage des fichiers.

Une réunion avec toute l'équipe des tuteurs a été prévue pour la semaine 5.

===Semaine 5===

La semaine a commencé par une réunion avec l'équipe de l'ARPL se chargeant d'encadrer notre projet, c'est-à-dire Vincent et Thomas. Nous avons discuté ensemble de l'avancement du simulateur et de l'ordre dans lequel effectuer les tâches. Ils nous également demandé de créer un planning de nos tâches avec la date prévue pour chacune; ils auront en effet besoin de modifier leur code à certains endroits pour pouvoir utiliser le simulateur (nous n'aurons pas besoin de tous les nœuds, certains comme la détection Laser nous étant inutiles) et souhaiteraient savoir lorsque nous seront prêt à tester de nouvelles fonctionnalités.

Nous nous sommes lancés dans l'affichage des formes avec l'outil ''rviz'', qui permet de visualiser en 3D les messages de type ''visualisation_msgs'' qui lui sont envoyés sur le topic associé. Ces messages sont disponibles en différents types. Pour afficher les formes nous utiliseront le format ''Marker'' qui permet d'afficher un objet en 3D (cubes, sphères, flèches, cylindres) ou en 2D en lui donnant un z de 0.

Nous avons donc commencé par faire les tutoriels sur l'utilisation de rviz puis par ajouter le code nécessaire à l'affichage des formes. Nous avons ainsi décidé d'ajouter la variable du message de type ''Marker'' dans la classe Forme; celle-ci sera accessible par toutes les classes filles de Forme, notamment Cercle et Rectangle. Nous avons également créé une méthode ''display'' qui sera chargée de mettre à jour la position de la forme et de publier le message. Les différents ''setters'' des classes filles modifieront également le message pour qu'il soit à jour lors de l'envoi.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_rectangle.png|Affichage de la forme ''Rectangle'' dans Rviz
Fichier:Rviz_screenshot_cercle.png|Affichage de la forme ''Cercle'' dans Rviz
</gallery>

===Semaine 6===

Cette semaine, nous continuons d'améliorer l'affichage en programmant cette fois-ci la classe ''Robot'' (qui possède une forme, étant une Entité) pour pouvoir visualiser le robot avec rviz. Nous avons donc ajouté une fonction ''display'' à ''Entite'', faisant elle-même appel à la fonction ''display'' de sa forme; ce qui permettra un affichage plus facile de l'objet.

Nous avons également ajouté une forme ''Texte'' pour afficher du texte informatif sur les formes (par exemple, une lettre et un id pour une entité, "R1" dans le cas du premier robot de chaque équipe). Ce texte est affiché en cyan ou en magenta, en fonction de la couleur de l'équipe. Les noms des ''markers'' de la forme et du texte eux aussi dépendent du type de l'entité.

Enfin, nous avons permis au entités de type Machine de gérer leur affichage. Pour cela, nous avons dû créer une classe fille de cette entité pour pouvoir tester son affichage. Le choix s'est porté sur les machines de type BS (Base Station).

En cours de route, nous avons été confrontés à un problème au niveau de l'affichage en 2D. Il semblait logique que la hauteur des objets (en z) soit égale à 0 pour un affichage 2D, mais il s'est avéré que la couleur de l'objet était alors imprévisible (plus souvent noir que de la bonne couleur). Il en fait fallu laisser une légère épaisseur (0.001 mètres dans notre cas) pour que la couleur s'affiche correctement.

Un de nos objectifs était aussi de gérer l'affichage de l'orientation de nos entités. En effet, cela semble essentiel pour les robots par exemple, représentés par des ronds et pouvant se déplacer. Nous avons ainsi créé un nouveau marker ''Fleche''; il était également possible de changer le type de marker en ''interactive marker'' ce qui aurait permis l'affichage de flèches de direction, mais celles-ci permettaient de modifier la position de l'objet et n'étaient disponibles qu'en multiple de 2 (déplacement sur un axe). Le choix s'est donc porté sur l'utilisation d'un marker classique dont on change l'orientation en même temps que celle de l'entité.
Nous avons rencontré quelques soucis quant à la gestion de l'orientation du marker, celle-ci étant un ''quaternion'' (x, y, z, w) alors que nous souhaitons donner l'angle en degrés (ou en radians éventuellement); la documentation n'est pas forcément facile à trouver pour ROS.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_robot.png|Affichage de l'entité ''Robot'' dans Rviz
Fichier:Rviz_screenshot_machine.png|Affichage de l'entité ''BaseStation'' dans Rviz
Fichier:Rviz_screenshot_fleche.png|Affichage de l'entité ''Robot'' avec une forme ''Fleche'' dans Rviz
</gallery>

Nous avons dû corriger nos constructeurs pour être le plus efficace possible et remplir au maximum les besoins des futurs fonctions.

La problématique rendant nécessaire une gestion du temps vient du besoin de l'ARPL de pouvoir contrôler la vitesse de simulation et donc de pouvoir jouer un match très rapidement afin d'observer le comportement de leur code.
Nous avons commencé et fini la gestion du temps. ROS intègre une interface de temps qui se cale sur la machine qui lance ROS.
Pour que plusieurs machines suivent le même temps il faut opérer une synchronisation des temps. Cependant lors de la simulation tous les robots auront leur référentiel temporel sur la même machine ce qui rend une synchronisation inutile.

Il existe un topic ''clock'' qui sert pour les simulations. En forçant nos nœuds à utiliser le temps de simulation, nous avons une échelle temporelle utilisable et synchronisée. Nous avons donc un nœud qui va publier sur ce topic le temps qui sera initialisé à 0 en début de match.

Un paramètre d'environnement ROS sert à régler le facteur d'accélération de la simulation par rapport au temps réel. Il est modifiable à tout instant et est initialisé en premier dans le launchfile.

===Semaine 7===

Nous nous sommes attaqués à l'affichage du terrain dans rviz.

Pour cela, nous pouvions nous inspirer de code écrit par l'ARPL permettant de charger une carte depuis un fichier ''.yaml''. Certains de leurs packages nous ont été utiles, mais d'autres se sont avérés inutilisables tels quels à cause d'erreurs tantôt de "référence indéfinie" à un fichier, tantôt de "redéfinition" du même fichier (la cause de ces erreurs reste pour le moment toujours un mystère).
Nous avons donc opté, pour pouvoir avancer rapidement sur le projet, d'utiliser tel quel ce qu'il était possible d'utiliser, et sinon de recopier les fonctions nécessaires dans notre package. Certaines fonctions nécessitaient d'ailleurs de toute façon des modifications, car dans notre simulateur nous gérons aussi l'affichage de la carte alors qu'eux ne faisaient que la charger.

Un fichier ''.yaml'' a la syntaxe suivante :
field:
name: robocup_simulator
size: [14, 9, 0.0]
gradient:
distance: 0.35
minValue: 0
walls:
bottom1:
start: [-6, 0, 0.0]
end: [-4, 0, 0.0]

Nous avons donc commencé par charger le fichier en mémoire en le passant en paramètre à un ''launchfile'' lançant le nœud chargé de lire et d'afficher la carte. Ensuite, en faisant appel à des ''param'' (paramètres) du nœud actuel et en leur donnant le nom du champs (''name'' par exemple), on peut récupérer les valeurs du fichiers voulues.

Nous avons ainsi créé une classe ''Carte'' pour gérer le chargement des données depuis le fichier et toutes les fonctions utilitaires associées, mais permettant aussi d'afficher la carte grâce à une fonction ''display'' de même fonctionnement que celles créées précédemment pour les entités.

Pour l'affichage sur rviz, nous nous sommes servis du type d'objet ''Map'' pour visualiser le sol du terrain (en blanc ci-dessous). Nous avons également créé un vecteur de Rectangles pour afficher les murs (en bleu foncé ci-dessous) et un vecteur de Rectangles pour les zones interdites au robot (en noir).

Nous aurions aimé mettre à jour la taille de la grille affichée en fonction de la taille de la carte, mais il s'avère que c'est impossible, la grille ne provenant pas d'un message publié.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_map.png|Affichage du terrain de jeu dans Rviz
</gallery>

===Semaine 8===

Nous avons complété la fonction de gestion de la vitesse. Il n'y a plus de nœud pour gérer les déplacements au profit d'un nœud gérant chaque robot.
Les robots envoient un vecteur "twist" pour donner leur commande vitesse, soit deux vecteurs vitesse 3D, l'un pour la vitesse linéaire et l'autre pour la vitesse angulaire.
Cependant ce vecteur vitesse est paramétré dans le repère du robot, c'est-à-dire avec le vecteur x dirigé dans la direction de l'orientation du robot.
Pour nos calculs nous nous servons du repère originel, que ce soit pour placer les entités ou les déplacer. Cela facilite les calculs dans la simulation.
Ainsi nous devons transposer les vecteurs vitesse reçus pour les appliquer à notre repère.

La simulation fonctionnant en 2D nous simplifions les données en utilisant un seul vecteur 3D (x et y pour le déplacement linéaire et z pour le changement d'orientation soit la vitesse angulaire autour de l'axe z).
La transposition n'est nécessaire que pour les déplacements linéaires, donc nous utilisons de la trigonométrie simple et nous ajoutons le déplacement ainsi obtenu à la position actuelle, ce qui donne :

v_x = v_x1*cos(orientation_radian) - v_y1*sin(orientation_radian)

v_y = v_x1*sin(orientation_radian) + v_y1*sin(orientation_radian)

x_new = v_x *delta_t + x

y_new = v_y *delta_t + y

orientation_new = (v_angulaire*delta_t + orientation) [360]

Nous avons également apporté des modifications aux flèches et textes; en effet, maintenant que le déplacement des robots est possible, nous pouvons effectuer des tests.
Il s'avère que nous ne modifions pas la position des flèches et textes, le robot s'éloignait alors d'eux lorsqu'il se déplaçait.
Nous avons donc ajouté les quelques modifications nécessaires pour que ces formes suivent l'entité en déplacement.

Nous avons aussi commencé à compléter le package ''machine'' pour lui ajouter les sous-classes de Machine représentant les différentes machines (MPS) du jeu (BaseStation, CapStation, RingStation, DeliveryStation).
La BaseStation permettra au robot de récupérer un objet de type base, la RingStation d'y empiler des anneaux de couleurs différentes en fonction des commandes reçues, la CapStation de déposer un chapeau au sommet de l'objet et enfin on l'apporte à la DeliveryStation.

Nous avons complété ci-dessous les schémas UML du projet dans son état actuel :

<gallery style="margin: 0 auto;">
Fichier:Formes_package_Class_diagram_v3.png|Schéma UML du package ''formes''
Fichier:Machine_package_Class_diagram_v3.png|Schéma UML du package ''machine''
Fichier:Management_package_Class_diagram_v2.png|Schéma UML du package ''management''
Fichier:Robot_package_Class_diagram_v2.png|Schéma UML du package ''robot''
</gallery>

===Semaine 9===

Nous avons dû concevoir une fonction de récupération de distance entre deux entités.
Les robots étant les seules entités mobiles, nous ne calculons que la distance entre un robot et une autre entité.
La distance entre deux robots, soit deux cercles, est facile à déterminer. Nous récupérons les points des deux cercles étant sur la droite passant par les centres des dits cercles. Puis nous appliquons le calcul de distance.

Lorsqu'il s'agit de calculer la distance la plus courte avec un rectangle, c'est un peu plus compliqué et très rapidement le nombre de calculs devient très grand. Nous avons choisi une stratégie calculatoire réduisant le nombre de calculs avec les conseils de Mme Nathalie Delfosse.

Le problème est de trouver la distance la plus courte entre les deux formes ainsi que les points concernés.

[[Fichier:GD_1.png|500px|center|texte descriptif]]

Nous pouvons facilement tracer la zone de collision, soit la zone qui permet de dire qu'il y a une collision si le centre du robot est dessus.

[[Fichier:GD_2.png|500px|center|texte descriptif]]

Ensuite on découpe l'espace en 8 zones en prolongeant les cotés du rectangle pour en faire des droites.

[[Fichier:GD_3.png|500px|center|texte descriptif]]

Lorsqu'un robot se situe en zone n°1 alors la distance la plus proche est celle qui sépare le cercle de l'angle le plus proche du rectangle. Donc (S2) est cette distance avec la résolution du système composé de la droite par le centre du cercle et l'angle, et le cercle. Nous obtenons alors le point du cercle le plus proche du rectangle.

(S2)
(x−xc)²+(y−yc)²==R²
y= ax+b

Dans la zone n°2, la distance la plus courte est une droite verticale, ce qui nous donne facilement le point du cercle et le point du rectangle.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Dans la zone n°3, on observe le même comportement qu'avec la zone n°2 mais cette fois-ci à l'horizontal, les équations sont donc les mêmes avec une inversion des x en y et inversement.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Cette semaine nous avons aussi travaillé sur la production elle-même en complétant les classes du package ''machine''. Nous avons ainsi ajouté à chaque sous-classe une fonction ''setup'' qui permet d'initialiser la machine, la plupart du temps avec une couleur d'anneau ou de base, et pour la ''DeliveryStation'' avec un numéro de porte.

Ces fonctions seront ensuite appelées dans un nœud ''machines_node'' du package ''management''.

===Semaine 10===

Cette semaine, nous avons avancé sur la simulation en permettant à une 'Equipe' d'afficher ses six machines et ses trois robots. Le 'Manager', lui, affiche les deux équipes; nous avons ainsi tous les acteurs d'un match sur le même terrain.

Nous avons également installé la Referee Box, dans la prévision du travail sur la communication entre simulation et celle-ci, mais aussi pour pouvoir utiliser des types de messages particuliers du package 'llsf_msgs' inclus avec la Referee Box.

En effet, les machines changent d'état en fonction des commandes qu'elles reçoivent. En effet, les équipes doivent remplir des commandes tout au long du match, et les robots ordonnent ainsi aux machines de produire des types de pièces particuliers.
Ils commencent par envoyer un message de 'setup' qui va indiquer à la machine quel type de pièce préparer. À ce moment là la machine change d'état (état occupé) et ceci est reflété dans la couleur de son feu.
Lorsque la pièce est disponible, la machine rechange d'état pour être de nouveau disponible.

Il existe également d'autres types d'états, comme lorsque la machine est 'down' lors d'une maintenance programmée décidée par la Referee Box au début du match, lorsque la machine vient de recevoir un ordre ou encore lorsqu'un robot tente de l'utiliser sans lui envoyer de message de 'setup, elle est alors hors-service pendant un certain moment.

Lié à la Referee Box, nous avons du chercher à synchroniser le temps de celle-ci avec le simulateur. Cependant en observant le code du simulateur Gazebo (actuellement non fonctionnel) et la manière de communiquer avec l'arbitre, nous avons conclu que nous n'avions pas le temps de le faire.

Nous avons du implémenter le système de gestion de collision. Graphiquement et avec les équations, il est simple pour un être humain de comprendre le fonctionnement. Cependant le code impose plus de restriction. Nous avons donc décomposer la théorie en plusieurs. Une fonction pour obtenir la distance entre deux points, plusieurs fonctions permettant de déterminer les points les plus proche entre chaque structure. Et enfin une fonction déterminant si il y a collision.

Pour les cercle, il faut déterminer l'équation de la droite qui passe par le centre des deux cercles. Puis résoudre le système correspondant à l'intersection de la droite et du cercle qui nous odnne une équation du second degré. On choisit alors le point le plus proche de l'autre cercle.

Pour un cercle et un rectangle, on test zone par zone. Nous ne sommes pas obligés de nous placer dans le référentiel du rectangle. Au lieu de ça nous allons vérifier zone par zone l'appartenance du cercle à celles-ci grâce aux systèmes composés de trois droites (les cotés du rectangles) pour les zones latérales et de deux pour les zones d'angles. Ces systèmes s'excluent les uns les autres. Si le cercle n'est dans aucune zone alors il est à l'intérieur du rectangle. Ce qui est soit une situation impossible soit une collision. Lorsque l'on à la zone on résout le système correspondant (décrit lors de la semaine 9). Cette implémentation n'a pas été faite entièrement durant cette semaine. Nous l'avons continué lors du temps supplémentaire.

===Heures supplémentaires===

Nous avons commencé par ajouter l'affichage des feux (composés d'un rectangle et de trois cercles rouge, jaune, vert).
En fonction de l'état de la machine à laquelle ils appartiennent, les couleurs affichés changent. D'après le règlement, si tout va bien le feu sera vert fixe, si la machine est occupée il sera jaune fixe et si la machine est en maintenance programmée il sera rouge fixe. Si la machine vient de recevoir un ordre, il sera vert clignotant et si elle est hors-service il sera clignotant jaune et rouge.

C'est pourquoi nous avons aussi implémenté le clignotement de celui-ci qu'il est possible de voir dans la vidéo ci-dessous.

Enfin, les machines seront positionnées de différentes manières au début d'un match, il est donc nécessaire que le feu associé ait la même rotation que sa machine.
Nous avons ainsi commencé par permettre aux cercles du haut et du bas d'effectuer un rotation autour du cercle central. Une fois la chose faite, nous avons modifié la rotation d'une machine. En effet, jusque là elle était implémentée de la même manière que pour les robots, or ceux-ci se déplacent et pas notre machine. Il n'est donc pas nécessaire que la flèche soit en rotation mais plutôt qu'elle soit positionnée de manière fixe (mais cela reste modifiable dans le code) et que ce soit le rectangle de la machine qui effectue une rotation sur lui-même. Il en va de même pour le rectangle du feu.

Enfin, nous avons dû gérer le positionnement du feu par rapport au rectangle : il faut, lorsque la machine effectue une rotation, calculer la position de son coin inférieur gauche et positionner le feu par rapport à celui-ci.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_feu_45_degres.png|Feu en rotation
Fichier:Rviz_screenshot_machine_135_degres.png|Machine et son feu en rotation
Fichier:Rviz_screenshot_machine_state_down.png|Machine en état de maintenance programmée
Fichier:Rviz_screenshot_machine_state_busy.png|Machine occupée
Fichier:Rviz_screenshot_machine_state_ok.png|Machine disponible
Fichier:Feu_clignotant.mp4|Vidéo du feu qui clignote
</gallery>

== Fichiers Rendus ==

IMA4 2016/2017 P20

2017-04-27T07:29:37Z

Mbutaye : /* Feuille d'heures */

__TOC__
 
==Cahier des charges==

Ce cahier des charges a pour objectif de définir le projet, ce qui est attendu ainsi que les contraintes de conception qui lui sont associées.

===Présentation générale du projet===

Le projet consiste à concevoir et développer un environnement virtuel de test pour l'Association de Robotique de Polytech Lille (ARPL). Ce simulateur doit reproduire les conditions de participation à la Logistic League de manière à pouvoir obtenir rapidement des données et tester le code ainsi que les stratégies de jeu utilisés par les robots.

====Contexte====
Ce simulateur est un outil développé dans le cadre de la RoboCup et plus particulièrement de la Logistic League. La RoboCup est une compétition internationale de robotique dans laquelle on voit beaucoup d'entreprises et de robots connus tel que NAO. Cette compétition a pour but de mettre en avant les évolutions en matière de robotique ainsi que les qualités des organismes participants.

La Logistic League est une des différentes épreuves proposées. L'objectif est de repérer le terrain puis de produire des objets avec différents éléments fournis par des machines et à livrer dans des plages de temps données. Une RefereeBox ou boîte arbitre sert à la coordination ainsi qu'à l'arbitrage. C'est cette boite qui va informer le robots des différents objets à construire avec la date de livraison demandée. Elle va également donner leur rôles aux machines présentes sur le terrain. L'arbitre va enregistrer les horaires de dépôt des objets et la position de chacune des machines lors de la compétition.

Celle-ci se déroule sur une piste de la taille d'une salle moyenne. Chaque équipe peut utiliser jusqu'à trois robots Robotino 3 pour réaliser les tâches demandées. Sur la piste, à part les robots, se trouvent seulement des machines dites de production ou de livraison. Elles vont servir soit à se procurer un élément nécessaire à la production de l'objet final soit à livrer celui-ci lorsqu'il est terminé.

====Objectif du projet====

Ce projet va permettre de fournir à l'équipe de l'ARPL un simulateur léger et complet, leur permettant de simuler en un court laps de temps un match entier ou partiel et de tester leur code et leur stratégie. Cela leur permettra de développer plus rapidement et efficacement.

====Description du projet====

Le simulateur devra répondre à un certain nombre de critères. Tout d'abord il lui faudra pouvoir simuler toutes les entités présentes sur la piste lors d'un match. Nous parlons des robots et des machines mais également des capteurs et des conditions de jeu.

Nous devrons faire en sorte que le simulateur puisse facilement intégrer le code de contrôle des robots afin de le tester. De plus il faut permettre à l'utilisateur de gérer les parties du code à tester ainsi que de changer les conditions et paramètres de simulation afin de ne tester que certaines partie du code (par exemple en excluant la gestion des collisions). Nous inclurons une gestion des phases de jeu (Découverte et Production) dans ce but. De ce point de vue l'idéal serait de générer un launchfile et de permettre à l'utilisateur de gérer l'utilisation des nœuds un par un.

En sus, le simulateur gérant les robots de l'équipe adverse, il aura une fonctionnalité de sauvegarde des configurations que ce soit pour le code ou les stratégies afin de comparer l'évolution des performances.

Le simulateur a certaines contraintes afin d'être utilisable et utile. Il doit opérer une compression du temps c'est à dire réaliser la simulation d'un match en moins de temps qu'une durée normale de match. Il s'agit d'obtenir des données représentant la réalité en un cours laps de temps. La communication avec la RefereeBox est indispensable. Celle-ci étant fourni par les organisateurs de la compétition nous n'avons pas à la simuler mais nous devons communiquer avec elle pour rendre la simulation plus réaliste.

====Choix techniques : matériel et logiciel====

Nous n'avons pas besoin de matériel hormis d'ordinateurs afin de programmer.

Dû à la compétition et aux choix de développement de l'équipe de l'ARPL, nous allons programmer en C++ avec les bibliothèques QT ainsi que le middleware ROS, une surcouche de programmation destinée à la programmation de robots.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

*Simuler les différentes entités
** les Robotinos ;
** les machines ;
** l'environnement.

*Gérer l'interfaçage entre le simulateur et le code des Robots
** lire et lancer le méta-paquet ;
** identifier les différents parties du code ;
** proposer l'activation/désactivation de ces parties et créer un launchfile en conséquence ;
** créer un système de sauvegarde de tout code interfacé permettant sa réutilisation.

*Simuler un match
** communiquer avec la RefereeBox et recevoir les différents ordres de celle-ci ;
** gérer les machines et la communication avec la RefereeBox ;
** gérer l'équipe de l'utilisateur et son interaction avec le reste de la simulation ;
** gérer l'équipe adverse et son interaction avec le reste de la simulation.

*Paramétrage avancé de la simulation
** proposer différents modes de simulations ;
** activation/déssactivation des paramètres de la simulation ;
** gestion des phases.

*Interface utilisateur
** fournir des données utilisables et intéressantes sur la simulation ;
** créer une GUI ergonomique ;
** importer les données de la simulation sur la GUI pour une meilleure analyse de celle-ci.

====Calendrier====

Répartition du temps consacré au projet (120h/personne) :

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures supplémentaires !! Total
|-
| Définition cahier des charges
| 2
|
|
|
|
|
|
|
|
|
|
|
|2
|-
|Mise à niveau matérielle et intellectuelle
|
|13
|
|
|
|1
|
|
|
|
|
|
|14
|-
|Conception théorique
|
|5
|7
|4
|2
|
|
|0,5
|
|13
|2
|
|33.5
|-
|Programmation de la simulation
|
|
|8
|15
|16
|4
|8
|6
|10
|6
|10
|7
|90
|-
|Programmation de l'affichage avec rviz
|
|
|
|
|
|5
|8
|13
|6
|
|
|5
|37
|-
|Wiki
|
|
|0,5
|1,5
|1,5
|0,5
|2
|0,5
|3
|0,5
|0,5
|2
|12,5
|-
|Réunions tuteurs
|2
|
|
|
|2
|2
|
|
|
|
|
|
|6
|-
|Total
|4
|18
|15,5
|20,5
|21,5
|12,5
|18
|20
|19
|19,5
|12,5
|14
|195
|}

==Planning des tâches==

{| class="wikitable"
!Tâche !! Date prévue !! Avancement !! Commentaires
|-
| Affichage des formes avec Rviz
| 01/03/2017
| Terminé
| Cercle & Rectangle
|-
| Affichage d'un robot
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Affichage d'une machine
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Gestion du temps
| 08/03/2017
| Terminé
| Bornes de facteurs possibles à déterminer
|-
| Déplacement d'un robot
| 22/03/2017
| Terminé
| Vitesse et déplacement au point; Besoin d'interfaçage sur le code ARPL
|-
| Affichage de l'orientation de l'entité
| 13/03/2017
| Terminé
| Affichage d'une forme Flèche dont l'orientation change avec celle de l'entité. Grise. Orientation en degrés.
|-
| Lecture et affichage de la map
| 19/03/2017
| Terminé
| Affichage de la map, des murs et des zones interdites.
|-
| Communication RefBox
| 01/04/2017
| Débuté
| Prise d'information sur le système
|-
| Gestion Collision
| 01/04/2017
| Débuté
| Prise d'information sur le système
|}

==Avancement du Projet==

===Semaine 1===
Nous avons commencé par installer ROS et tout ce dont nous avons besoin pour travailler correctement. Nous avons également suivi des [http://wiki.ros.org/ROS/Tutorials tutoriels] pour apprendre à utiliser ROS.

Pour pouvoir travailler en binôme sans problèmes et pour que nos encadrants puissent suivre notre avancement et tester le logiciel, nous avons utilisé le logiciel de gestion de versions Git, sur lequel on publie notre code au fur et à mesure.

Nous n'avions pas encore de dépôt sur celui-ci, donc nous avons commencé par réfléchir à la structure de notre projet.
Nous commencerons par implémenter la phase d'exploration, ce qui comprend aussi le déplacement du robot, la détection de machines et de feux ainsi qu'une interface utilisateur basique.

En effet, le match oppose deux équipes ayant jusque trois robotinos qui s'affrontent lors de deux phases. La première est la phase d'exploration, durant laquelle les robots doivent trouver les machines de leur équipe en explorant le terrain. Ils doivent annoncer la position des machines et les signaux des feux de celles-ci : chaque machine, peu importe son type, possède un feu tricolore (rouge, jaune, vert) qui durant la phase d'exploration aura une combinaison de lumières allumées aléatoirement (au moins une doit l'être).

La création d'un simulateur passe par la réflexion sur les besoins en conception du simulateur (décris en partie ci-dessus). Nous avons donc passé un certain temps à schématiser la structure de notre simulateur et à en assimiler les besoins et l'ordre de création.

===Semaine 2===
Nous avons récupéré un dépôt Git (nommé ''logistic-sim'') sur lequel travailler auprès de nos encadrants, nous pouvons donc commencer la programmation cette semaine.

Ceci étant notre premier projet mêlant ROS et Git, nous avons tenté de créer la structure du projet mais avons vite rencontré quelques difficultés.
Nous avons ensuite compris qu'il était nécessaire de d'abord créer un environnement de travail ROS pour le projet, dans lequel on clône ensuite le dépôt Git localement.

Nous obtenons ainsi la structure de projet suivante :
* Workspace ROS
** build
** devel
** src
*** CMakeLists.txt
*** logistic-sim

Les dossiers build, devel, src et CMakeList.txt sont des fichiers et dossiers générés par ''Catkin'', un outil permettant de créer des paquets ROS facilement.

Nous avons ensuite décidé de séparer le code du projet en différents dossiers en fonction des tâches à effectuer :
* '''Entites''' pour simuler les différentes entités (Robotinos, machines, environnement...)
* '''Gestion_Code''' pour gérer l'interfaçage entre le simulateur et le code des robots
* '''Match''' pour simuler le déroulement d'un match
* '''GUI''' pour l'interface utilisateur avec le framework Qt

Dans chacun de ces dossiers, nous créerons des ''packages'' contenant les différentes fonctionnalités du projet.

Chaque ''package'' a la structure suivante :
* CMakeLists.txt
* include pour les fichiers .h
* package.xml
* README.md
* src pour les classes et nodes .cpp
* launch pour les launchfiles

Dans un premier temps, on commence par la gestion de la position du robot et la reconnaissance des feux.

===Semaine 3===

Nous avons avancé sur la programmation de la gestion de la position du robot et de la reconnaissance des feux.

Nous avons décrit nos classes par des schémas UML avec l'outil gratuit ''Modélio'' pour créer une documentation facilement accessible. Les commentaires des fonctions, classes et fichiers au format ''Doxygen'' nous permettront également de générer une documentation du projet sous format HTML notamment.

Nous suivons aussi la normalisation du code donnée par l'ARPL pour avoir les mêmes conventions de nommage partout.

Nous avons décidé de créer un nouveau package ''match'' qui contiendra les nœuds correspondants aux différentes phases de jeu, et avons donc par conséquent commencé par créer un nœud pour la phase d'exploration.

Nous avons également commencé à réfléchir à la façon dont les informations sont communiquées dans le match : il y a un arbitre, la ''Referee Box'' qui permet de faire communiquer le simulateur et les robots jouant le match. En effet, l'arbitre prend les décisions importantes (placement des machines au début du jeu etc.) et c'est à lui que les robots s'adressent. Nous devons donc aussi communiquer avec lui pour recevoir certaines informations (par exemple les informations de base de la phase d'exploration) et les retransmettre dans le simulateur aux nœuds qui en auront besoin.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v1.png|Schéma UML du package ''machine''
Fichier:Formes_package_Class_diagram_v1.png|Schéma UML du package ''formes''
</gallery>

===Semaine 4===

Cette semaine, nous avons créé plusieurs nouveaux packages et modifié ceux qui avaient déjà été créés.

Nous avons créé la classe Cercle dans le package ''formes'', nous pouvons donc maintenant utiliser deux formes différentes, le rectangle et le cercle.
La classe Entite a elle aussi été rajoutée. En effet, certains attributs des machines sont communs avec ceux des robots; cette classe nous permet de les rassembler et les classes Machine et Robot hériteront ainsi de Entite.

Un nouveau package ''management'' a également fait son apparition. Il contiendra les classes Equipe et Manager. Le Manager sera chargé de créer les équipes et permettra d'y accéder partout dans le code, mais aussi de procéder aux différentes initialisations lors du démarrage d'une nouvelle phase.

Au package ''management'' s'ajoute le nouveau package ''robot'' dont le rôle est de simuler les robotinos lors du match.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v2.png|Schéma UML du package ''machine''
Fichier:Robot_package_Class_diagram_v1.png|Schéma UML du package ''robot''
Fichier:Formes_package_Class_diagram_v2.png|Schéma UML du package ''formes''
Fichier:Management_package_Class_diagram_v1.png|Schéma UML du package ''management''
</gallery>

Nous avons également rendu visite à l'un de nos tuteurs de stage pendant la semaine dans le but d'obtenir un premier retour sur notre travail et l'avancement du projet.

Nous avons pu effectuer immédiatement quelques modifications nécessaires suite aux commentaires de notre tuteur. Nous avons dû, par exemple, clôner leur projet dans le même espace de travail que le notre pour pouvoir réutiliser certains paquets de messages déjà créés. Cela permettra une meilleure compatibilité. D'autres modifications concernaient entre autres les conventions de nommage de certaines classes et l'ajout d'un dossier supplémentaire dans le dossier include de chaque package portant le nom de celui-ci, pour ne pas avoir de conflits quant au nommage des fichiers.

Une réunion avec toute l'équipe des tuteurs a été prévue pour la semaine 5.

===Semaine 5===

La semaine a commencé par une réunion avec l'équipe de l'ARPL se chargeant d'encadrer notre projet, c'est-à-dire Vincent et Thomas. Nous avons discuté ensemble de l'avancement du simulateur et de l'ordre dans lequel effectuer les tâches. Ils nous également demandé de créer un planning de nos tâches avec la date prévue pour chacune; ils auront en effet besoin de modifier leur code à certains endroits pour pouvoir utiliser le simulateur (nous n'aurons pas besoin de tous les nœuds, certains comme la détection Laser nous étant inutiles) et souhaiteraient savoir lorsque nous seront prêt à tester de nouvelles fonctionnalités.

Nous nous sommes lancés dans l'affichage des formes avec l'outil ''rviz'', qui permet de visualiser en 3D les messages de type ''visualisation_msgs'' qui lui sont envoyés sur le topic associé. Ces messages sont disponibles en différents types. Pour afficher les formes nous utiliseront le format ''Marker'' qui permet d'afficher un objet en 3D (cubes, sphères, flèches, cylindres) ou en 2D en lui donnant un z de 0.

Nous avons donc commencé par faire les tutoriels sur l'utilisation de rviz puis par ajouter le code nécessaire à l'affichage des formes. Nous avons ainsi décidé d'ajouter la variable du message de type ''Marker'' dans la classe Forme; celle-ci sera accessible par toutes les classes filles de Forme, notamment Cercle et Rectangle. Nous avons également créé une méthode ''display'' qui sera chargée de mettre à jour la position de la forme et de publier le message. Les différents ''setters'' des classes filles modifieront également le message pour qu'il soit à jour lors de l'envoi.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_rectangle.png|Affichage de la forme ''Rectangle'' dans Rviz
Fichier:Rviz_screenshot_cercle.png|Affichage de la forme ''Cercle'' dans Rviz
</gallery>

===Semaine 6===

Cette semaine, nous continuons d'améliorer l'affichage en programmant cette fois-ci la classe ''Robot'' (qui possède une forme, étant une Entité) pour pouvoir visualiser le robot avec rviz. Nous avons donc ajouté une fonction ''display'' à ''Entite'', faisant elle-même appel à la fonction ''display'' de sa forme; ce qui permettra un affichage plus facile de l'objet.

Nous avons également ajouté une forme ''Texte'' pour afficher du texte informatif sur les formes (par exemple, une lettre et un id pour une entité, "R1" dans le cas du premier robot de chaque équipe). Ce texte est affiché en cyan ou en magenta, en fonction de la couleur de l'équipe. Les noms des ''markers'' de la forme et du texte eux aussi dépendent du type de l'entité.

Enfin, nous avons permis au entités de type Machine de gérer leur affichage. Pour cela, nous avons dû créer une classe fille de cette entité pour pouvoir tester son affichage. Le choix s'est porté sur les machines de type BS (Base Station).

En cours de route, nous avons été confrontés à un problème au niveau de l'affichage en 2D. Il semblait logique que la hauteur des objets (en z) soit égale à 0 pour un affichage 2D, mais il s'est avéré que la couleur de l'objet était alors imprévisible (plus souvent noir que de la bonne couleur). Il en fait fallu laisser une légère épaisseur (0.001 mètres dans notre cas) pour que la couleur s'affiche correctement.

Un de nos objectifs était aussi de gérer l'affichage de l'orientation de nos entités. En effet, cela semble essentiel pour les robots par exemple, représentés par des ronds et pouvant se déplacer. Nous avons ainsi créé un nouveau marker ''Fleche''; il était également possible de changer le type de marker en ''interactive marker'' ce qui aurait permis l'affichage de flèches de direction, mais celles-ci permettaient de modifier la position de l'objet et n'étaient disponibles qu'en multiple de 2 (déplacement sur un axe). Le choix s'est donc porté sur l'utilisation d'un marker classique dont on change l'orientation en même temps que celle de l'entité.
Nous avons rencontré quelques soucis quant à la gestion de l'orientation du marker, celle-ci étant un ''quaternion'' (x, y, z, w) alors que nous souhaitons donner l'angle en degrés (ou en radians éventuellement); la documentation n'est pas forcément facile à trouver pour ROS.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_robot.png|Affichage de l'entité ''Robot'' dans Rviz
Fichier:Rviz_screenshot_machine.png|Affichage de l'entité ''BaseStation'' dans Rviz
Fichier:Rviz_screenshot_fleche.png|Affichage de l'entité ''Robot'' avec une forme ''Fleche'' dans Rviz
</gallery>

Nous avons dû corriger nos constructeurs pour être le plus efficace possible et remplir au maximum les besoins des futurs fonctions.

La problématique rendant nécessaire une gestion du temps vient du besoin de l'ARPL de pouvoir contrôler la vitesse de simulation et donc de pouvoir jouer un match très rapidement afin d'observer le comportement de leur code.
Nous avons commencé et fini la gestion du temps. ROS intègre une interface de temps qui se cale sur la machine qui lance ROS.
Pour que plusieurs machines suivent le même temps il faut opérer une synchronisation des temps. Cependant lors de la simulation tous les robots auront leur référentiel temporel sur la même machine ce qui rend une synchronisation inutile.

Il existe un topic ''clock'' qui sert pour les simulations. En forçant nos nœuds à utiliser le temps de simulation, nous avons une échelle temporelle utilisable et synchronisée. Nous avons donc un nœud qui va publier sur ce topic le temps qui sera initialisé à 0 en début de match.

Un paramètre d'environnement ROS sert à régler le facteur d'accélération de la simulation par rapport au temps réel. Il est modifiable à tout instant et est initialisé en premier dans le launchfile.

===Semaine 7===

Nous nous sommes attaqués à l'affichage du terrain dans rviz.

Pour cela, nous pouvions nous inspirer de code écrit par l'ARPL permettant de charger une carte depuis un fichier ''.yaml''. Certains de leurs packages nous ont été utiles, mais d'autres se sont avérés inutilisables tels quels à cause d'erreurs tantôt de "référence indéfinie" à un fichier, tantôt de "redéfinition" du même fichier (la cause de ces erreurs reste pour le moment toujours un mystère).
Nous avons donc opté, pour pouvoir avancer rapidement sur le projet, d'utiliser tel quel ce qu'il était possible d'utiliser, et sinon de recopier les fonctions nécessaires dans notre package. Certaines fonctions nécessitaient d'ailleurs de toute façon des modifications, car dans notre simulateur nous gérons aussi l'affichage de la carte alors qu'eux ne faisaient que la charger.

Un fichier ''.yaml'' a la syntaxe suivante :
field:
name: robocup_simulator
size: [14, 9, 0.0]
gradient:
distance: 0.35
minValue: 0
walls:
bottom1:
start: [-6, 0, 0.0]
end: [-4, 0, 0.0]

Nous avons donc commencé par charger le fichier en mémoire en le passant en paramètre à un ''launchfile'' lançant le nœud chargé de lire et d'afficher la carte. Ensuite, en faisant appel à des ''param'' (paramètres) du nœud actuel et en leur donnant le nom du champs (''name'' par exemple), on peut récupérer les valeurs du fichiers voulues.

Nous avons ainsi créé une classe ''Carte'' pour gérer le chargement des données depuis le fichier et toutes les fonctions utilitaires associées, mais permettant aussi d'afficher la carte grâce à une fonction ''display'' de même fonctionnement que celles créées précédemment pour les entités.

Pour l'affichage sur rviz, nous nous sommes servis du type d'objet ''Map'' pour visualiser le sol du terrain (en blanc ci-dessous). Nous avons également créé un vecteur de Rectangles pour afficher les murs (en bleu foncé ci-dessous) et un vecteur de Rectangles pour les zones interdites au robot (en noir).

Nous aurions aimé mettre à jour la taille de la grille affichée en fonction de la taille de la carte, mais il s'avère que c'est impossible, la grille ne provenant pas d'un message publié.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_map.png|Affichage du terrain de jeu dans Rviz
</gallery>

===Semaine 8===

Nous avons complété la fonction de gestion de la vitesse. Il n'y a plus de nœud pour gérer les déplacements au profit d'un nœud gérant chaque robot.
Les robots envoient un vecteur "twist" pour donner leur commande vitesse, soit deux vecteurs vitesse 3D, l'un pour la vitesse linéaire et l'autre pour la vitesse angulaire.
Cependant ce vecteur vitesse est paramétré dans le repère du robot, c'est-à-dire avec le vecteur x dirigé dans la direction de l'orientation du robot.
Pour nos calculs nous nous servons du repère originel, que ce soit pour placer les entités ou les déplacer. Cela facilite les calculs dans la simulation.
Ainsi nous devons transposer les vecteurs vitesse reçus pour les appliquer à notre repère.

La simulation fonctionnant en 2D nous simplifions les données en utilisant un seul vecteur 3D (x et y pour le déplacement linéaire et z pour le changement d'orientation soit la vitesse angulaire autour de l'axe z).
La transposition n'est nécessaire que pour les déplacements linéaires, donc nous utilisons de la trigonométrie simple et nous ajoutons le déplacement ainsi obtenu à la position actuelle, ce qui donne :

v_x = v_x1*cos(orientation_radian) - v_y1*sin(orientation_radian)

v_y = v_x1*sin(orientation_radian) + v_y1*sin(orientation_radian)

x_new = v_x *delta_t + x

y_new = v_y *delta_t + y

orientation_new = (v_angulaire*delta_t + orientation) [360]

Nous avons également apporté des modifications aux flèches et textes; en effet, maintenant que le déplacement des robots est possible, nous pouvons effectuer des tests.
Il s'avère que nous ne modifions pas la position des flèches et textes, le robot s'éloignait alors d'eux lorsqu'il se déplaçait.
Nous avons donc ajouté les quelques modifications nécessaires pour que ces formes suivent l'entité en déplacement.

Nous avons aussi commencé à compléter le package ''machine'' pour lui ajouter les sous-classes de Machine représentant les différentes machines (MPS) du jeu (BaseStation, CapStation, RingStation, DeliveryStation).
La BaseStation permettra au robot de récupérer un objet de type base, la RingStation d'y empiler des anneaux de couleurs différentes en fonction des commandes reçues, la CapStation de déposer un chapeau au sommet de l'objet et enfin on l'apporte à la DeliveryStation.

Nous avons complété ci-dessous les schémas UML du projet dans son état actuel :

<gallery style="margin: 0 auto;">
Fichier:Formes_package_Class_diagram_v3.png|Schéma UML du package ''formes''
Fichier:Machine_package_Class_diagram_v3.png|Schéma UML du package ''machine''
Fichier:Management_package_Class_diagram_v2.png|Schéma UML du package ''management''
Fichier:Robot_package_Class_diagram_v2.png|Schéma UML du package ''robot''
</gallery>

===Semaine 9===

Nous avons dû concevoir une fonction de récupération de distance entre deux entités.
Les robots étant les seules entités mobiles, nous ne calculons que la distance entre un robot et une autre entité.
La distance entre deux robots, soit deux cercles, est facile à déterminer. Nous récupérons les points des deux cercles étant sur la droite passant par les centres des dits cercles. Puis nous appliquons le calcul de distance.

Lorsqu'il s'agit de calculer la distance la plus courte avec un rectangle, c'est un peu plus compliqué et très rapidement le nombre de calculs devient très grand. Nous avons choisi une stratégie calculatoire réduisant le nombre de calculs avec les conseils de Mme Nathalie Delfosse.

Le problème est de trouver la distance la plus courte entre les deux formes ainsi que les points concernés.

[[Fichier:GD_1.png|500px|center|texte descriptif]]

Nous pouvons facilement tracer la zone de collision, soit la zone qui permet de dire qu'il y a une collision si le centre du robot est dessus.

[[Fichier:GD_2.png|500px|center|texte descriptif]]

Ensuite on découpe l'espace en 8 zones en prolongeant les cotés du rectangle pour en faire des droites.

[[Fichier:GD_3.png|500px|center|texte descriptif]]

Lorsqu'un robot se situe en zone n°1 alors la distance la plus proche est celle qui sépare le cercle de l'angle le plus proche du rectangle. Donc (S2) est cette distance avec la résolution du système composé de la droite par le centre du cercle et l'angle, et le cercle. Nous obtenons alors le point du cercle le plus proche du rectangle.

(S2)
(x−xc)²+(y−yc)²==R²
y= ax+b

Dans la zone n°2, la distance la plus courte est une droite verticale, ce qui nous donne facilement le point du cercle et le point du rectangle.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Cette semaine nous avons aussi travaillé sur la production elle-même en complétant les classes du package ''machine''. Nous avons ainsi ajouté à chaque sous-classe une fonction ''setup'' qui permet d'initialiser la machine, la plupart du temps avec une couleur d'anneau ou de base, et pour la ''DeliveryStation'' avec un numéro de porte.

Ces fonctions seront ensuite appelées dans un nœud ''machines_node'' du package ''management''.

===Semaine 10===

Cette semaine, nous avons avancé sur la simulation en permettant à une 'Equipe' d'afficher ses six machines et ses trois robots. Le 'Manager', lui, affiche les deux équipes; nous avons ainsi tous les acteurs d'un match sur le même terrain.

Nous avons également installé la Referee Box, dans la prévision du travail sur la communication entre simulation et celle-ci, mais aussi pour pouvoir utiliser des types de messages particuliers du package 'llsf_msgs' inclus avec la Referee Box.

En effet, les machines changent d'état en fonction des commandes qu'elles reçoivent. En effet, les équipes doivent remplir des commandes tout au long du match, et les robots ordonnent ainsi aux machines de produire des types de pièces particuliers.
Ils commencent par envoyer un message de 'setup' qui va indiquer à la machine quel type de pièce préparer. À ce moment là la machine change d'état (état occupé) et ceci est reflété dans la couleur de son feu.
Lorsque la pièce est disponible, la machine rechange d'état pour être de nouveau disponible.

Il existe également d'autres types d'états, comme lorsque la machine est 'down' lors d'une maintenance programmée décidée par la Referee Box au début du match, lorsque la machine vient de recevoir un ordre ou encore lorsqu'un robot tente de l'utiliser sans lui envoyer de message de 'setup, elle est alors hors-service pendant un certain moment.

===Heures supplémentaires===

Nous avons commencé par ajouter l'affichage des feux (composés d'un rectangle et de trois cercles rouge, jaune, vert).
En fonction de l'état de la machine à laquelle ils appartiennent, les couleurs affichés changent. D'après le règlement, si tout va bien le feu sera vert fixe, si la machine est occupée il sera jaune fixe et si la machine est en maintenance programmée il sera rouge fixe. Si la machine vient de recevoir un ordre, il sera vert clignotant et si elle est hors-service il sera clignotant jaune et rouge.

C'est pourquoi nous avons aussi implémenté le clignotement de celui-ci qu'il est possible de voir dans la vidéo ci-dessous.

Enfin, les machines seront positionnées de différentes manières au début d'un match, il est donc nécessaire que le feu associé ait la même rotation que sa machine.
Nous avons ainsi commencé par permettre aux cercles du haut et du bas d'effectuer un rotation autour du cercle central. Une fois la chose faite, nous avons modifié la rotation d'une machine. En effet, jusque là elle était implémentée de la même manière que pour les robots, or ceux-ci se déplacent et pas notre machine. Il n'est donc pas nécessaire que la flèche soit en rotation mais plutôt qu'elle soit positionnée de manière fixe (mais cela reste modifiable dans le code) et que ce soit le rectangle de la machine qui effectue une rotation sur lui-même. Il en va de même pour le rectangle du feu.

Enfin, nous avons dû gérer le positionnement du feu par rapport au rectangle : il faut, lorsque la machine effectue une rotation, calculer la position de son coin inférieur gauche et positionner le feu par rapport à celui-ci.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_feu_45_degres.png|Feu en rotation
Fichier:Rviz_screenshot_machine_135_degres.png|Machine et son feu en rotation
Fichier:Rviz_screenshot_machine_state_down.png|Machine en état de maintenance programmée
Fichier:Rviz_screenshot_machine_state_busy.png|Machine occupée
Fichier:Rviz_screenshot_machine_state_ok.png|Machine disponible
Fichier:Feu_clignotant.mp4|Vidéo du feu qui clignote
</gallery>

== Fichiers Rendus ==

IMA4 2016/2017 P20

2017-04-27T07:29:18Z

Mbutaye : /* Feuille d'heures */

__TOC__
 
==Cahier des charges==

Ce cahier des charges a pour objectif de définir le projet, ce qui est attendu ainsi que les contraintes de conception qui lui sont associées.

===Présentation générale du projet===

Le projet consiste à concevoir et développer un environnement virtuel de test pour l'Association de Robotique de Polytech Lille (ARPL). Ce simulateur doit reproduire les conditions de participation à la Logistic League de manière à pouvoir obtenir rapidement des données et tester le code ainsi que les stratégies de jeu utilisés par les robots.

====Contexte====
Ce simulateur est un outil développé dans le cadre de la RoboCup et plus particulièrement de la Logistic League. La RoboCup est une compétition internationale de robotique dans laquelle on voit beaucoup d'entreprises et de robots connus tel que NAO. Cette compétition a pour but de mettre en avant les évolutions en matière de robotique ainsi que les qualités des organismes participants.

La Logistic League est une des différentes épreuves proposées. L'objectif est de repérer le terrain puis de produire des objets avec différents éléments fournis par des machines et à livrer dans des plages de temps données. Une RefereeBox ou boîte arbitre sert à la coordination ainsi qu'à l'arbitrage. C'est cette boite qui va informer le robots des différents objets à construire avec la date de livraison demandée. Elle va également donner leur rôles aux machines présentes sur le terrain. L'arbitre va enregistrer les horaires de dépôt des objets et la position de chacune des machines lors de la compétition.

Celle-ci se déroule sur une piste de la taille d'une salle moyenne. Chaque équipe peut utiliser jusqu'à trois robots Robotino 3 pour réaliser les tâches demandées. Sur la piste, à part les robots, se trouvent seulement des machines dites de production ou de livraison. Elles vont servir soit à se procurer un élément nécessaire à la production de l'objet final soit à livrer celui-ci lorsqu'il est terminé.

====Objectif du projet====

Ce projet va permettre de fournir à l'équipe de l'ARPL un simulateur léger et complet, leur permettant de simuler en un court laps de temps un match entier ou partiel et de tester leur code et leur stratégie. Cela leur permettra de développer plus rapidement et efficacement.

====Description du projet====

Le simulateur devra répondre à un certain nombre de critères. Tout d'abord il lui faudra pouvoir simuler toutes les entités présentes sur la piste lors d'un match. Nous parlons des robots et des machines mais également des capteurs et des conditions de jeu.

Nous devrons faire en sorte que le simulateur puisse facilement intégrer le code de contrôle des robots afin de le tester. De plus il faut permettre à l'utilisateur de gérer les parties du code à tester ainsi que de changer les conditions et paramètres de simulation afin de ne tester que certaines partie du code (par exemple en excluant la gestion des collisions). Nous inclurons une gestion des phases de jeu (Découverte et Production) dans ce but. De ce point de vue l'idéal serait de générer un launchfile et de permettre à l'utilisateur de gérer l'utilisation des nœuds un par un.

En sus, le simulateur gérant les robots de l'équipe adverse, il aura une fonctionnalité de sauvegarde des configurations que ce soit pour le code ou les stratégies afin de comparer l'évolution des performances.

Le simulateur a certaines contraintes afin d'être utilisable et utile. Il doit opérer une compression du temps c'est à dire réaliser la simulation d'un match en moins de temps qu'une durée normale de match. Il s'agit d'obtenir des données représentant la réalité en un cours laps de temps. La communication avec la RefereeBox est indispensable. Celle-ci étant fourni par les organisateurs de la compétition nous n'avons pas à la simuler mais nous devons communiquer avec elle pour rendre la simulation plus réaliste.

====Choix techniques : matériel et logiciel====

Nous n'avons pas besoin de matériel hormis d'ordinateurs afin de programmer.

Dû à la compétition et aux choix de développement de l'équipe de l'ARPL, nous allons programmer en C++ avec les bibliothèques QT ainsi que le middleware ROS, une surcouche de programmation destinée à la programmation de robots.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

*Simuler les différentes entités
** les Robotinos ;
** les machines ;
** l'environnement.

*Gérer l'interfaçage entre le simulateur et le code des Robots
** lire et lancer le méta-paquet ;
** identifier les différents parties du code ;
** proposer l'activation/désactivation de ces parties et créer un launchfile en conséquence ;
** créer un système de sauvegarde de tout code interfacé permettant sa réutilisation.

*Simuler un match
** communiquer avec la RefereeBox et recevoir les différents ordres de celle-ci ;
** gérer les machines et la communication avec la RefereeBox ;
** gérer l'équipe de l'utilisateur et son interaction avec le reste de la simulation ;
** gérer l'équipe adverse et son interaction avec le reste de la simulation.

*Paramétrage avancé de la simulation
** proposer différents modes de simulations ;
** activation/déssactivation des paramètres de la simulation ;
** gestion des phases.

*Interface utilisateur
** fournir des données utilisables et intéressantes sur la simulation ;
** créer une GUI ergonomique ;
** importer les données de la simulation sur la GUI pour une meilleure analyse de celle-ci.

====Calendrier====

Répartition du temps consacré au projet (120h/personne) :

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures supplémentaires !! Total
|-
| Définition cahier des charges
| 2
|
|
|
|
|
|
|
|
|
|
|
|2
|-
|Mise à niveau matérielle et intellectuelle
|
|13
|
|
|
|1
|
|
|
|
|
|
|14
|-
|Conception théorique
|
|5
|7
|4
|2
|
|
|0,5
|
|13
|2
|
|33.5
|-
|Programmation de la simulation
|
|
|8
|15
|16
|4
|8
|6
|10
|6
|10
|7
|90
|-
|Programmation de l'affichage avec rviz
|
|
|
|
|
|5
|8
|13
|6
|
|
|5
|37
|-
|Wiki
|
|
|0,5
|1,5
|1,5
|0,5
|2
|0,5
|3
|0,5
|0,5
|2
|12,5
|-
|Réunions tuteurs
|2
|
|
|
|2
|2
|
|
|
|
|
|
|6
|-
|Total
|4
|18
|15,5
|20,5
|21,5
|12,5
|18
|20
|19
|19,5
|12,5
|14
|193
|}

==Planning des tâches==

{| class="wikitable"
!Tâche !! Date prévue !! Avancement !! Commentaires
|-
| Affichage des formes avec Rviz
| 01/03/2017
| Terminé
| Cercle & Rectangle
|-
| Affichage d'un robot
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Affichage d'une machine
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Gestion du temps
| 08/03/2017
| Terminé
| Bornes de facteurs possibles à déterminer
|-
| Déplacement d'un robot
| 22/03/2017
| Terminé
| Vitesse et déplacement au point; Besoin d'interfaçage sur le code ARPL
|-
| Affichage de l'orientation de l'entité
| 13/03/2017
| Terminé
| Affichage d'une forme Flèche dont l'orientation change avec celle de l'entité. Grise. Orientation en degrés.
|-
| Lecture et affichage de la map
| 19/03/2017
| Terminé
| Affichage de la map, des murs et des zones interdites.
|-
| Communication RefBox
| 01/04/2017
| Débuté
| Prise d'information sur le système
|-
| Gestion Collision
| 01/04/2017
| Débuté
| Prise d'information sur le système
|}

==Avancement du Projet==

===Semaine 1===
Nous avons commencé par installer ROS et tout ce dont nous avons besoin pour travailler correctement. Nous avons également suivi des [http://wiki.ros.org/ROS/Tutorials tutoriels] pour apprendre à utiliser ROS.

Pour pouvoir travailler en binôme sans problèmes et pour que nos encadrants puissent suivre notre avancement et tester le logiciel, nous avons utilisé le logiciel de gestion de versions Git, sur lequel on publie notre code au fur et à mesure.

Nous n'avions pas encore de dépôt sur celui-ci, donc nous avons commencé par réfléchir à la structure de notre projet.
Nous commencerons par implémenter la phase d'exploration, ce qui comprend aussi le déplacement du robot, la détection de machines et de feux ainsi qu'une interface utilisateur basique.

En effet, le match oppose deux équipes ayant jusque trois robotinos qui s'affrontent lors de deux phases. La première est la phase d'exploration, durant laquelle les robots doivent trouver les machines de leur équipe en explorant le terrain. Ils doivent annoncer la position des machines et les signaux des feux de celles-ci : chaque machine, peu importe son type, possède un feu tricolore (rouge, jaune, vert) qui durant la phase d'exploration aura une combinaison de lumières allumées aléatoirement (au moins une doit l'être).

La création d'un simulateur passe par la réflexion sur les besoins en conception du simulateur (décris en partie ci-dessus). Nous avons donc passé un certain temps à schématiser la structure de notre simulateur et à en assimiler les besoins et l'ordre de création.

===Semaine 2===
Nous avons récupéré un dépôt Git (nommé ''logistic-sim'') sur lequel travailler auprès de nos encadrants, nous pouvons donc commencer la programmation cette semaine.

Ceci étant notre premier projet mêlant ROS et Git, nous avons tenté de créer la structure du projet mais avons vite rencontré quelques difficultés.
Nous avons ensuite compris qu'il était nécessaire de d'abord créer un environnement de travail ROS pour le projet, dans lequel on clône ensuite le dépôt Git localement.

Nous obtenons ainsi la structure de projet suivante :
* Workspace ROS
** build
** devel
** src
*** CMakeLists.txt
*** logistic-sim

Les dossiers build, devel, src et CMakeList.txt sont des fichiers et dossiers générés par ''Catkin'', un outil permettant de créer des paquets ROS facilement.

Nous avons ensuite décidé de séparer le code du projet en différents dossiers en fonction des tâches à effectuer :
* '''Entites''' pour simuler les différentes entités (Robotinos, machines, environnement...)
* '''Gestion_Code''' pour gérer l'interfaçage entre le simulateur et le code des robots
* '''Match''' pour simuler le déroulement d'un match
* '''GUI''' pour l'interface utilisateur avec le framework Qt

Dans chacun de ces dossiers, nous créerons des ''packages'' contenant les différentes fonctionnalités du projet.

Chaque ''package'' a la structure suivante :
* CMakeLists.txt
* include pour les fichiers .h
* package.xml
* README.md
* src pour les classes et nodes .cpp
* launch pour les launchfiles

Dans un premier temps, on commence par la gestion de la position du robot et la reconnaissance des feux.

===Semaine 3===

Nous avons avancé sur la programmation de la gestion de la position du robot et de la reconnaissance des feux.

Nous avons décrit nos classes par des schémas UML avec l'outil gratuit ''Modélio'' pour créer une documentation facilement accessible. Les commentaires des fonctions, classes et fichiers au format ''Doxygen'' nous permettront également de générer une documentation du projet sous format HTML notamment.

Nous suivons aussi la normalisation du code donnée par l'ARPL pour avoir les mêmes conventions de nommage partout.

Nous avons décidé de créer un nouveau package ''match'' qui contiendra les nœuds correspondants aux différentes phases de jeu, et avons donc par conséquent commencé par créer un nœud pour la phase d'exploration.

Nous avons également commencé à réfléchir à la façon dont les informations sont communiquées dans le match : il y a un arbitre, la ''Referee Box'' qui permet de faire communiquer le simulateur et les robots jouant le match. En effet, l'arbitre prend les décisions importantes (placement des machines au début du jeu etc.) et c'est à lui que les robots s'adressent. Nous devons donc aussi communiquer avec lui pour recevoir certaines informations (par exemple les informations de base de la phase d'exploration) et les retransmettre dans le simulateur aux nœuds qui en auront besoin.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v1.png|Schéma UML du package ''machine''
Fichier:Formes_package_Class_diagram_v1.png|Schéma UML du package ''formes''
</gallery>

===Semaine 4===

Cette semaine, nous avons créé plusieurs nouveaux packages et modifié ceux qui avaient déjà été créés.

Nous avons créé la classe Cercle dans le package ''formes'', nous pouvons donc maintenant utiliser deux formes différentes, le rectangle et le cercle.
La classe Entite a elle aussi été rajoutée. En effet, certains attributs des machines sont communs avec ceux des robots; cette classe nous permet de les rassembler et les classes Machine et Robot hériteront ainsi de Entite.

Un nouveau package ''management'' a également fait son apparition. Il contiendra les classes Equipe et Manager. Le Manager sera chargé de créer les équipes et permettra d'y accéder partout dans le code, mais aussi de procéder aux différentes initialisations lors du démarrage d'une nouvelle phase.

Au package ''management'' s'ajoute le nouveau package ''robot'' dont le rôle est de simuler les robotinos lors du match.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v2.png|Schéma UML du package ''machine''
Fichier:Robot_package_Class_diagram_v1.png|Schéma UML du package ''robot''
Fichier:Formes_package_Class_diagram_v2.png|Schéma UML du package ''formes''
Fichier:Management_package_Class_diagram_v1.png|Schéma UML du package ''management''
</gallery>

Nous avons également rendu visite à l'un de nos tuteurs de stage pendant la semaine dans le but d'obtenir un premier retour sur notre travail et l'avancement du projet.

Nous avons pu effectuer immédiatement quelques modifications nécessaires suite aux commentaires de notre tuteur. Nous avons dû, par exemple, clôner leur projet dans le même espace de travail que le notre pour pouvoir réutiliser certains paquets de messages déjà créés. Cela permettra une meilleure compatibilité. D'autres modifications concernaient entre autres les conventions de nommage de certaines classes et l'ajout d'un dossier supplémentaire dans le dossier include de chaque package portant le nom de celui-ci, pour ne pas avoir de conflits quant au nommage des fichiers.

Une réunion avec toute l'équipe des tuteurs a été prévue pour la semaine 5.

===Semaine 5===

La semaine a commencé par une réunion avec l'équipe de l'ARPL se chargeant d'encadrer notre projet, c'est-à-dire Vincent et Thomas. Nous avons discuté ensemble de l'avancement du simulateur et de l'ordre dans lequel effectuer les tâches. Ils nous également demandé de créer un planning de nos tâches avec la date prévue pour chacune; ils auront en effet besoin de modifier leur code à certains endroits pour pouvoir utiliser le simulateur (nous n'aurons pas besoin de tous les nœuds, certains comme la détection Laser nous étant inutiles) et souhaiteraient savoir lorsque nous seront prêt à tester de nouvelles fonctionnalités.

Nous nous sommes lancés dans l'affichage des formes avec l'outil ''rviz'', qui permet de visualiser en 3D les messages de type ''visualisation_msgs'' qui lui sont envoyés sur le topic associé. Ces messages sont disponibles en différents types. Pour afficher les formes nous utiliseront le format ''Marker'' qui permet d'afficher un objet en 3D (cubes, sphères, flèches, cylindres) ou en 2D en lui donnant un z de 0.

Nous avons donc commencé par faire les tutoriels sur l'utilisation de rviz puis par ajouter le code nécessaire à l'affichage des formes. Nous avons ainsi décidé d'ajouter la variable du message de type ''Marker'' dans la classe Forme; celle-ci sera accessible par toutes les classes filles de Forme, notamment Cercle et Rectangle. Nous avons également créé une méthode ''display'' qui sera chargée de mettre à jour la position de la forme et de publier le message. Les différents ''setters'' des classes filles modifieront également le message pour qu'il soit à jour lors de l'envoi.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_rectangle.png|Affichage de la forme ''Rectangle'' dans Rviz
Fichier:Rviz_screenshot_cercle.png|Affichage de la forme ''Cercle'' dans Rviz
</gallery>

===Semaine 6===

Cette semaine, nous continuons d'améliorer l'affichage en programmant cette fois-ci la classe ''Robot'' (qui possède une forme, étant une Entité) pour pouvoir visualiser le robot avec rviz. Nous avons donc ajouté une fonction ''display'' à ''Entite'', faisant elle-même appel à la fonction ''display'' de sa forme; ce qui permettra un affichage plus facile de l'objet.

Nous avons également ajouté une forme ''Texte'' pour afficher du texte informatif sur les formes (par exemple, une lettre et un id pour une entité, "R1" dans le cas du premier robot de chaque équipe). Ce texte est affiché en cyan ou en magenta, en fonction de la couleur de l'équipe. Les noms des ''markers'' de la forme et du texte eux aussi dépendent du type de l'entité.

Enfin, nous avons permis au entités de type Machine de gérer leur affichage. Pour cela, nous avons dû créer une classe fille de cette entité pour pouvoir tester son affichage. Le choix s'est porté sur les machines de type BS (Base Station).

En cours de route, nous avons été confrontés à un problème au niveau de l'affichage en 2D. Il semblait logique que la hauteur des objets (en z) soit égale à 0 pour un affichage 2D, mais il s'est avéré que la couleur de l'objet était alors imprévisible (plus souvent noir que de la bonne couleur). Il en fait fallu laisser une légère épaisseur (0.001 mètres dans notre cas) pour que la couleur s'affiche correctement.

Un de nos objectifs était aussi de gérer l'affichage de l'orientation de nos entités. En effet, cela semble essentiel pour les robots par exemple, représentés par des ronds et pouvant se déplacer. Nous avons ainsi créé un nouveau marker ''Fleche''; il était également possible de changer le type de marker en ''interactive marker'' ce qui aurait permis l'affichage de flèches de direction, mais celles-ci permettaient de modifier la position de l'objet et n'étaient disponibles qu'en multiple de 2 (déplacement sur un axe). Le choix s'est donc porté sur l'utilisation d'un marker classique dont on change l'orientation en même temps que celle de l'entité.
Nous avons rencontré quelques soucis quant à la gestion de l'orientation du marker, celle-ci étant un ''quaternion'' (x, y, z, w) alors que nous souhaitons donner l'angle en degrés (ou en radians éventuellement); la documentation n'est pas forcément facile à trouver pour ROS.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_robot.png|Affichage de l'entité ''Robot'' dans Rviz
Fichier:Rviz_screenshot_machine.png|Affichage de l'entité ''BaseStation'' dans Rviz
Fichier:Rviz_screenshot_fleche.png|Affichage de l'entité ''Robot'' avec une forme ''Fleche'' dans Rviz
</gallery>

Nous avons dû corriger nos constructeurs pour être le plus efficace possible et remplir au maximum les besoins des futurs fonctions.

La problématique rendant nécessaire une gestion du temps vient du besoin de l'ARPL de pouvoir contrôler la vitesse de simulation et donc de pouvoir jouer un match très rapidement afin d'observer le comportement de leur code.
Nous avons commencé et fini la gestion du temps. ROS intègre une interface de temps qui se cale sur la machine qui lance ROS.
Pour que plusieurs machines suivent le même temps il faut opérer une synchronisation des temps. Cependant lors de la simulation tous les robots auront leur référentiel temporel sur la même machine ce qui rend une synchronisation inutile.

Il existe un topic ''clock'' qui sert pour les simulations. En forçant nos nœuds à utiliser le temps de simulation, nous avons une échelle temporelle utilisable et synchronisée. Nous avons donc un nœud qui va publier sur ce topic le temps qui sera initialisé à 0 en début de match.

Un paramètre d'environnement ROS sert à régler le facteur d'accélération de la simulation par rapport au temps réel. Il est modifiable à tout instant et est initialisé en premier dans le launchfile.

===Semaine 7===

Nous nous sommes attaqués à l'affichage du terrain dans rviz.

Pour cela, nous pouvions nous inspirer de code écrit par l'ARPL permettant de charger une carte depuis un fichier ''.yaml''. Certains de leurs packages nous ont été utiles, mais d'autres se sont avérés inutilisables tels quels à cause d'erreurs tantôt de "référence indéfinie" à un fichier, tantôt de "redéfinition" du même fichier (la cause de ces erreurs reste pour le moment toujours un mystère).
Nous avons donc opté, pour pouvoir avancer rapidement sur le projet, d'utiliser tel quel ce qu'il était possible d'utiliser, et sinon de recopier les fonctions nécessaires dans notre package. Certaines fonctions nécessitaient d'ailleurs de toute façon des modifications, car dans notre simulateur nous gérons aussi l'affichage de la carte alors qu'eux ne faisaient que la charger.

Un fichier ''.yaml'' a la syntaxe suivante :
field:
name: robocup_simulator
size: [14, 9, 0.0]
gradient:
distance: 0.35
minValue: 0
walls:
bottom1:
start: [-6, 0, 0.0]
end: [-4, 0, 0.0]

Nous avons donc commencé par charger le fichier en mémoire en le passant en paramètre à un ''launchfile'' lançant le nœud chargé de lire et d'afficher la carte. Ensuite, en faisant appel à des ''param'' (paramètres) du nœud actuel et en leur donnant le nom du champs (''name'' par exemple), on peut récupérer les valeurs du fichiers voulues.

Nous avons ainsi créé une classe ''Carte'' pour gérer le chargement des données depuis le fichier et toutes les fonctions utilitaires associées, mais permettant aussi d'afficher la carte grâce à une fonction ''display'' de même fonctionnement que celles créées précédemment pour les entités.

Pour l'affichage sur rviz, nous nous sommes servis du type d'objet ''Map'' pour visualiser le sol du terrain (en blanc ci-dessous). Nous avons également créé un vecteur de Rectangles pour afficher les murs (en bleu foncé ci-dessous) et un vecteur de Rectangles pour les zones interdites au robot (en noir).

Nous aurions aimé mettre à jour la taille de la grille affichée en fonction de la taille de la carte, mais il s'avère que c'est impossible, la grille ne provenant pas d'un message publié.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_map.png|Affichage du terrain de jeu dans Rviz
</gallery>

===Semaine 8===

Nous avons complété la fonction de gestion de la vitesse. Il n'y a plus de nœud pour gérer les déplacements au profit d'un nœud gérant chaque robot.
Les robots envoient un vecteur "twist" pour donner leur commande vitesse, soit deux vecteurs vitesse 3D, l'un pour la vitesse linéaire et l'autre pour la vitesse angulaire.
Cependant ce vecteur vitesse est paramétré dans le repère du robot, c'est-à-dire avec le vecteur x dirigé dans la direction de l'orientation du robot.
Pour nos calculs nous nous servons du repère originel, que ce soit pour placer les entités ou les déplacer. Cela facilite les calculs dans la simulation.
Ainsi nous devons transposer les vecteurs vitesse reçus pour les appliquer à notre repère.

La simulation fonctionnant en 2D nous simplifions les données en utilisant un seul vecteur 3D (x et y pour le déplacement linéaire et z pour le changement d'orientation soit la vitesse angulaire autour de l'axe z).
La transposition n'est nécessaire que pour les déplacements linéaires, donc nous utilisons de la trigonométrie simple et nous ajoutons le déplacement ainsi obtenu à la position actuelle, ce qui donne :

v_x = v_x1*cos(orientation_radian) - v_y1*sin(orientation_radian)

v_y = v_x1*sin(orientation_radian) + v_y1*sin(orientation_radian)

x_new = v_x *delta_t + x

y_new = v_y *delta_t + y

orientation_new = (v_angulaire*delta_t + orientation) [360]

Nous avons également apporté des modifications aux flèches et textes; en effet, maintenant que le déplacement des robots est possible, nous pouvons effectuer des tests.
Il s'avère que nous ne modifions pas la position des flèches et textes, le robot s'éloignait alors d'eux lorsqu'il se déplaçait.
Nous avons donc ajouté les quelques modifications nécessaires pour que ces formes suivent l'entité en déplacement.

Nous avons aussi commencé à compléter le package ''machine'' pour lui ajouter les sous-classes de Machine représentant les différentes machines (MPS) du jeu (BaseStation, CapStation, RingStation, DeliveryStation).
La BaseStation permettra au robot de récupérer un objet de type base, la RingStation d'y empiler des anneaux de couleurs différentes en fonction des commandes reçues, la CapStation de déposer un chapeau au sommet de l'objet et enfin on l'apporte à la DeliveryStation.

Nous avons complété ci-dessous les schémas UML du projet dans son état actuel :

<gallery style="margin: 0 auto;">
Fichier:Formes_package_Class_diagram_v3.png|Schéma UML du package ''formes''
Fichier:Machine_package_Class_diagram_v3.png|Schéma UML du package ''machine''
Fichier:Management_package_Class_diagram_v2.png|Schéma UML du package ''management''
Fichier:Robot_package_Class_diagram_v2.png|Schéma UML du package ''robot''
</gallery>

===Semaine 9===

Nous avons dû concevoir une fonction de récupération de distance entre deux entités.
Les robots étant les seules entités mobiles, nous ne calculons que la distance entre un robot et une autre entité.
La distance entre deux robots, soit deux cercles, est facile à déterminer. Nous récupérons les points des deux cercles étant sur la droite passant par les centres des dits cercles. Puis nous appliquons le calcul de distance.

Lorsqu'il s'agit de calculer la distance la plus courte avec un rectangle, c'est un peu plus compliqué et très rapidement le nombre de calculs devient très grand. Nous avons choisi une stratégie calculatoire réduisant le nombre de calculs avec les conseils de Mme Nathalie Delfosse.

Le problème est de trouver la distance la plus courte entre les deux formes ainsi que les points concernés.

[[Fichier:GD_1.png|500px|center|texte descriptif]]

Nous pouvons facilement tracer la zone de collision, soit la zone qui permet de dire qu'il y a une collision si le centre du robot est dessus.

[[Fichier:GD_2.png|500px|center|texte descriptif]]

Ensuite on découpe l'espace en 8 zones en prolongeant les cotés du rectangle pour en faire des droites.

[[Fichier:GD_3.png|500px|center|texte descriptif]]

Lorsqu'un robot se situe en zone n°1 alors la distance la plus proche est celle qui sépare le cercle de l'angle le plus proche du rectangle. Donc (S2) est cette distance avec la résolution du système composé de la droite par le centre du cercle et l'angle, et le cercle. Nous obtenons alors le point du cercle le plus proche du rectangle.

(S2)
(x−xc)²+(y−yc)²==R²
y= ax+b

Dans la zone n°2, la distance la plus courte est une droite verticale, ce qui nous donne facilement le point du cercle et le point du rectangle.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Cette semaine nous avons aussi travaillé sur la production elle-même en complétant les classes du package ''machine''. Nous avons ainsi ajouté à chaque sous-classe une fonction ''setup'' qui permet d'initialiser la machine, la plupart du temps avec une couleur d'anneau ou de base, et pour la ''DeliveryStation'' avec un numéro de porte.

Ces fonctions seront ensuite appelées dans un nœud ''machines_node'' du package ''management''.

===Semaine 10===

Cette semaine, nous avons avancé sur la simulation en permettant à une 'Equipe' d'afficher ses six machines et ses trois robots. Le 'Manager', lui, affiche les deux équipes; nous avons ainsi tous les acteurs d'un match sur le même terrain.

Nous avons également installé la Referee Box, dans la prévision du travail sur la communication entre simulation et celle-ci, mais aussi pour pouvoir utiliser des types de messages particuliers du package 'llsf_msgs' inclus avec la Referee Box.

En effet, les machines changent d'état en fonction des commandes qu'elles reçoivent. En effet, les équipes doivent remplir des commandes tout au long du match, et les robots ordonnent ainsi aux machines de produire des types de pièces particuliers.
Ils commencent par envoyer un message de 'setup' qui va indiquer à la machine quel type de pièce préparer. À ce moment là la machine change d'état (état occupé) et ceci est reflété dans la couleur de son feu.
Lorsque la pièce est disponible, la machine rechange d'état pour être de nouveau disponible.

Il existe également d'autres types d'états, comme lorsque la machine est 'down' lors d'une maintenance programmée décidée par la Referee Box au début du match, lorsque la machine vient de recevoir un ordre ou encore lorsqu'un robot tente de l'utiliser sans lui envoyer de message de 'setup, elle est alors hors-service pendant un certain moment.

===Heures supplémentaires===

Nous avons commencé par ajouter l'affichage des feux (composés d'un rectangle et de trois cercles rouge, jaune, vert).
En fonction de l'état de la machine à laquelle ils appartiennent, les couleurs affichés changent. D'après le règlement, si tout va bien le feu sera vert fixe, si la machine est occupée il sera jaune fixe et si la machine est en maintenance programmée il sera rouge fixe. Si la machine vient de recevoir un ordre, il sera vert clignotant et si elle est hors-service il sera clignotant jaune et rouge.

C'est pourquoi nous avons aussi implémenté le clignotement de celui-ci qu'il est possible de voir dans la vidéo ci-dessous.

Enfin, les machines seront positionnées de différentes manières au début d'un match, il est donc nécessaire que le feu associé ait la même rotation que sa machine.
Nous avons ainsi commencé par permettre aux cercles du haut et du bas d'effectuer un rotation autour du cercle central. Une fois la chose faite, nous avons modifié la rotation d'une machine. En effet, jusque là elle était implémentée de la même manière que pour les robots, or ceux-ci se déplacent et pas notre machine. Il n'est donc pas nécessaire que la flèche soit en rotation mais plutôt qu'elle soit positionnée de manière fixe (mais cela reste modifiable dans le code) et que ce soit le rectangle de la machine qui effectue une rotation sur lui-même. Il en va de même pour le rectangle du feu.

Enfin, nous avons dû gérer le positionnement du feu par rapport au rectangle : il faut, lorsque la machine effectue une rotation, calculer la position de son coin inférieur gauche et positionner le feu par rapport à celui-ci.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_feu_45_degres.png|Feu en rotation
Fichier:Rviz_screenshot_machine_135_degres.png|Machine et son feu en rotation
Fichier:Rviz_screenshot_machine_state_down.png|Machine en état de maintenance programmée
Fichier:Rviz_screenshot_machine_state_busy.png|Machine occupée
Fichier:Rviz_screenshot_machine_state_ok.png|Machine disponible
Fichier:Feu_clignotant.mp4|Vidéo du feu qui clignote
</gallery>

== Fichiers Rendus ==

IMA4 2016/2017 P20

2017-04-27T07:28:27Z

Mbutaye : /* Semaine 10 */

__TOC__
 
==Cahier des charges==

Ce cahier des charges a pour objectif de définir le projet, ce qui est attendu ainsi que les contraintes de conception qui lui sont associées.

===Présentation générale du projet===

Le projet consiste à concevoir et développer un environnement virtuel de test pour l'Association de Robotique de Polytech Lille (ARPL). Ce simulateur doit reproduire les conditions de participation à la Logistic League de manière à pouvoir obtenir rapidement des données et tester le code ainsi que les stratégies de jeu utilisés par les robots.

====Contexte====
Ce simulateur est un outil développé dans le cadre de la RoboCup et plus particulièrement de la Logistic League. La RoboCup est une compétition internationale de robotique dans laquelle on voit beaucoup d'entreprises et de robots connus tel que NAO. Cette compétition a pour but de mettre en avant les évolutions en matière de robotique ainsi que les qualités des organismes participants.

La Logistic League est une des différentes épreuves proposées. L'objectif est de repérer le terrain puis de produire des objets avec différents éléments fournis par des machines et à livrer dans des plages de temps données. Une RefereeBox ou boîte arbitre sert à la coordination ainsi qu'à l'arbitrage. C'est cette boite qui va informer le robots des différents objets à construire avec la date de livraison demandée. Elle va également donner leur rôles aux machines présentes sur le terrain. L'arbitre va enregistrer les horaires de dépôt des objets et la position de chacune des machines lors de la compétition.

Celle-ci se déroule sur une piste de la taille d'une salle moyenne. Chaque équipe peut utiliser jusqu'à trois robots Robotino 3 pour réaliser les tâches demandées. Sur la piste, à part les robots, se trouvent seulement des machines dites de production ou de livraison. Elles vont servir soit à se procurer un élément nécessaire à la production de l'objet final soit à livrer celui-ci lorsqu'il est terminé.

====Objectif du projet====

Ce projet va permettre de fournir à l'équipe de l'ARPL un simulateur léger et complet, leur permettant de simuler en un court laps de temps un match entier ou partiel et de tester leur code et leur stratégie. Cela leur permettra de développer plus rapidement et efficacement.

====Description du projet====

Le simulateur devra répondre à un certain nombre de critères. Tout d'abord il lui faudra pouvoir simuler toutes les entités présentes sur la piste lors d'un match. Nous parlons des robots et des machines mais également des capteurs et des conditions de jeu.

Nous devrons faire en sorte que le simulateur puisse facilement intégrer le code de contrôle des robots afin de le tester. De plus il faut permettre à l'utilisateur de gérer les parties du code à tester ainsi que de changer les conditions et paramètres de simulation afin de ne tester que certaines partie du code (par exemple en excluant la gestion des collisions). Nous inclurons une gestion des phases de jeu (Découverte et Production) dans ce but. De ce point de vue l'idéal serait de générer un launchfile et de permettre à l'utilisateur de gérer l'utilisation des nœuds un par un.

En sus, le simulateur gérant les robots de l'équipe adverse, il aura une fonctionnalité de sauvegarde des configurations que ce soit pour le code ou les stratégies afin de comparer l'évolution des performances.

Le simulateur a certaines contraintes afin d'être utilisable et utile. Il doit opérer une compression du temps c'est à dire réaliser la simulation d'un match en moins de temps qu'une durée normale de match. Il s'agit d'obtenir des données représentant la réalité en un cours laps de temps. La communication avec la RefereeBox est indispensable. Celle-ci étant fourni par les organisateurs de la compétition nous n'avons pas à la simuler mais nous devons communiquer avec elle pour rendre la simulation plus réaliste.

====Choix techniques : matériel et logiciel====

Nous n'avons pas besoin de matériel hormis d'ordinateurs afin de programmer.

Dû à la compétition et aux choix de développement de l'équipe de l'ARPL, nous allons programmer en C++ avec les bibliothèques QT ainsi que le middleware ROS, une surcouche de programmation destinée à la programmation de robots.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

*Simuler les différentes entités
** les Robotinos ;
** les machines ;
** l'environnement.

*Gérer l'interfaçage entre le simulateur et le code des Robots
** lire et lancer le méta-paquet ;
** identifier les différents parties du code ;
** proposer l'activation/désactivation de ces parties et créer un launchfile en conséquence ;
** créer un système de sauvegarde de tout code interfacé permettant sa réutilisation.

*Simuler un match
** communiquer avec la RefereeBox et recevoir les différents ordres de celle-ci ;
** gérer les machines et la communication avec la RefereeBox ;
** gérer l'équipe de l'utilisateur et son interaction avec le reste de la simulation ;
** gérer l'équipe adverse et son interaction avec le reste de la simulation.

*Paramétrage avancé de la simulation
** proposer différents modes de simulations ;
** activation/déssactivation des paramètres de la simulation ;
** gestion des phases.

*Interface utilisateur
** fournir des données utilisables et intéressantes sur la simulation ;
** créer une GUI ergonomique ;
** importer les données de la simulation sur la GUI pour une meilleure analyse de celle-ci.

====Calendrier====

Répartition du temps consacré au projet (120h/personne) :

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures supplémentaires !! Total
|-
| Définition cahier des charges
| 2
|
|
|
|
|
|
|
|
|
|
|
|2
|-
|Mise à niveau matérielle et intellectuelle
|
|13
|
|
|
|1
|
|
|
|
|
|
|14
|-
|Conception théorique
|
|5
|7
|4
|2
|
|
|0,5
|
|13
|2
|
|33.5
|-
|Programmation de la simulation
|
|
|8
|15
|16
|4
|8
|6
|10
|6
|10
|7
|90
|-
|Programmation de l'affichage avec rviz
|
|
|
|
|
|5
|8
|13
|6
|
|
|5
|37
|-
|Wiki
|
|
|0,5
|1,5
|1,5
|0,5
|2
|0,5
|3
|0,5
|0,5
|
|10,5
|-
|Réunions tuteurs
|2
|
|
|
|2
|2
|
|
|
|
|
|
|6
|-
|Total
|4
|18
|15,5
|20,5
|21,5
|12,5
|18
|20
|19
|19,5
|12,5
|12
|193
|}

==Planning des tâches==

{| class="wikitable"
!Tâche !! Date prévue !! Avancement !! Commentaires
|-
| Affichage des formes avec Rviz
| 01/03/2017
| Terminé
| Cercle & Rectangle
|-
| Affichage d'un robot
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Affichage d'une machine
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Gestion du temps
| 08/03/2017
| Terminé
| Bornes de facteurs possibles à déterminer
|-
| Déplacement d'un robot
| 22/03/2017
| Terminé
| Vitesse et déplacement au point; Besoin d'interfaçage sur le code ARPL
|-
| Affichage de l'orientation de l'entité
| 13/03/2017
| Terminé
| Affichage d'une forme Flèche dont l'orientation change avec celle de l'entité. Grise. Orientation en degrés.
|-
| Lecture et affichage de la map
| 19/03/2017
| Terminé
| Affichage de la map, des murs et des zones interdites.
|-
| Communication RefBox
| 01/04/2017
| Débuté
| Prise d'information sur le système
|-
| Gestion Collision
| 01/04/2017
| Débuté
| Prise d'information sur le système
|}

==Avancement du Projet==

===Semaine 1===
Nous avons commencé par installer ROS et tout ce dont nous avons besoin pour travailler correctement. Nous avons également suivi des [http://wiki.ros.org/ROS/Tutorials tutoriels] pour apprendre à utiliser ROS.

Pour pouvoir travailler en binôme sans problèmes et pour que nos encadrants puissent suivre notre avancement et tester le logiciel, nous avons utilisé le logiciel de gestion de versions Git, sur lequel on publie notre code au fur et à mesure.

Nous n'avions pas encore de dépôt sur celui-ci, donc nous avons commencé par réfléchir à la structure de notre projet.
Nous commencerons par implémenter la phase d'exploration, ce qui comprend aussi le déplacement du robot, la détection de machines et de feux ainsi qu'une interface utilisateur basique.

En effet, le match oppose deux équipes ayant jusque trois robotinos qui s'affrontent lors de deux phases. La première est la phase d'exploration, durant laquelle les robots doivent trouver les machines de leur équipe en explorant le terrain. Ils doivent annoncer la position des machines et les signaux des feux de celles-ci : chaque machine, peu importe son type, possède un feu tricolore (rouge, jaune, vert) qui durant la phase d'exploration aura une combinaison de lumières allumées aléatoirement (au moins une doit l'être).

La création d'un simulateur passe par la réflexion sur les besoins en conception du simulateur (décris en partie ci-dessus). Nous avons donc passé un certain temps à schématiser la structure de notre simulateur et à en assimiler les besoins et l'ordre de création.

===Semaine 2===
Nous avons récupéré un dépôt Git (nommé ''logistic-sim'') sur lequel travailler auprès de nos encadrants, nous pouvons donc commencer la programmation cette semaine.

Ceci étant notre premier projet mêlant ROS et Git, nous avons tenté de créer la structure du projet mais avons vite rencontré quelques difficultés.
Nous avons ensuite compris qu'il était nécessaire de d'abord créer un environnement de travail ROS pour le projet, dans lequel on clône ensuite le dépôt Git localement.

Nous obtenons ainsi la structure de projet suivante :
* Workspace ROS
** build
** devel
** src
*** CMakeLists.txt
*** logistic-sim

Les dossiers build, devel, src et CMakeList.txt sont des fichiers et dossiers générés par ''Catkin'', un outil permettant de créer des paquets ROS facilement.

Nous avons ensuite décidé de séparer le code du projet en différents dossiers en fonction des tâches à effectuer :
* '''Entites''' pour simuler les différentes entités (Robotinos, machines, environnement...)
* '''Gestion_Code''' pour gérer l'interfaçage entre le simulateur et le code des robots
* '''Match''' pour simuler le déroulement d'un match
* '''GUI''' pour l'interface utilisateur avec le framework Qt

Dans chacun de ces dossiers, nous créerons des ''packages'' contenant les différentes fonctionnalités du projet.

Chaque ''package'' a la structure suivante :
* CMakeLists.txt
* include pour les fichiers .h
* package.xml
* README.md
* src pour les classes et nodes .cpp
* launch pour les launchfiles

Dans un premier temps, on commence par la gestion de la position du robot et la reconnaissance des feux.

===Semaine 3===

Nous avons avancé sur la programmation de la gestion de la position du robot et de la reconnaissance des feux.

Nous avons décrit nos classes par des schémas UML avec l'outil gratuit ''Modélio'' pour créer une documentation facilement accessible. Les commentaires des fonctions, classes et fichiers au format ''Doxygen'' nous permettront également de générer une documentation du projet sous format HTML notamment.

Nous suivons aussi la normalisation du code donnée par l'ARPL pour avoir les mêmes conventions de nommage partout.

Nous avons décidé de créer un nouveau package ''match'' qui contiendra les nœuds correspondants aux différentes phases de jeu, et avons donc par conséquent commencé par créer un nœud pour la phase d'exploration.

Nous avons également commencé à réfléchir à la façon dont les informations sont communiquées dans le match : il y a un arbitre, la ''Referee Box'' qui permet de faire communiquer le simulateur et les robots jouant le match. En effet, l'arbitre prend les décisions importantes (placement des machines au début du jeu etc.) et c'est à lui que les robots s'adressent. Nous devons donc aussi communiquer avec lui pour recevoir certaines informations (par exemple les informations de base de la phase d'exploration) et les retransmettre dans le simulateur aux nœuds qui en auront besoin.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v1.png|Schéma UML du package ''machine''
Fichier:Formes_package_Class_diagram_v1.png|Schéma UML du package ''formes''
</gallery>

===Semaine 4===

Cette semaine, nous avons créé plusieurs nouveaux packages et modifié ceux qui avaient déjà été créés.

Nous avons créé la classe Cercle dans le package ''formes'', nous pouvons donc maintenant utiliser deux formes différentes, le rectangle et le cercle.
La classe Entite a elle aussi été rajoutée. En effet, certains attributs des machines sont communs avec ceux des robots; cette classe nous permet de les rassembler et les classes Machine et Robot hériteront ainsi de Entite.

Un nouveau package ''management'' a également fait son apparition. Il contiendra les classes Equipe et Manager. Le Manager sera chargé de créer les équipes et permettra d'y accéder partout dans le code, mais aussi de procéder aux différentes initialisations lors du démarrage d'une nouvelle phase.

Au package ''management'' s'ajoute le nouveau package ''robot'' dont le rôle est de simuler les robotinos lors du match.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v2.png|Schéma UML du package ''machine''
Fichier:Robot_package_Class_diagram_v1.png|Schéma UML du package ''robot''
Fichier:Formes_package_Class_diagram_v2.png|Schéma UML du package ''formes''
Fichier:Management_package_Class_diagram_v1.png|Schéma UML du package ''management''
</gallery>

Nous avons également rendu visite à l'un de nos tuteurs de stage pendant la semaine dans le but d'obtenir un premier retour sur notre travail et l'avancement du projet.

Nous avons pu effectuer immédiatement quelques modifications nécessaires suite aux commentaires de notre tuteur. Nous avons dû, par exemple, clôner leur projet dans le même espace de travail que le notre pour pouvoir réutiliser certains paquets de messages déjà créés. Cela permettra une meilleure compatibilité. D'autres modifications concernaient entre autres les conventions de nommage de certaines classes et l'ajout d'un dossier supplémentaire dans le dossier include de chaque package portant le nom de celui-ci, pour ne pas avoir de conflits quant au nommage des fichiers.

Une réunion avec toute l'équipe des tuteurs a été prévue pour la semaine 5.

===Semaine 5===

La semaine a commencé par une réunion avec l'équipe de l'ARPL se chargeant d'encadrer notre projet, c'est-à-dire Vincent et Thomas. Nous avons discuté ensemble de l'avancement du simulateur et de l'ordre dans lequel effectuer les tâches. Ils nous également demandé de créer un planning de nos tâches avec la date prévue pour chacune; ils auront en effet besoin de modifier leur code à certains endroits pour pouvoir utiliser le simulateur (nous n'aurons pas besoin de tous les nœuds, certains comme la détection Laser nous étant inutiles) et souhaiteraient savoir lorsque nous seront prêt à tester de nouvelles fonctionnalités.

Nous nous sommes lancés dans l'affichage des formes avec l'outil ''rviz'', qui permet de visualiser en 3D les messages de type ''visualisation_msgs'' qui lui sont envoyés sur le topic associé. Ces messages sont disponibles en différents types. Pour afficher les formes nous utiliseront le format ''Marker'' qui permet d'afficher un objet en 3D (cubes, sphères, flèches, cylindres) ou en 2D en lui donnant un z de 0.

Nous avons donc commencé par faire les tutoriels sur l'utilisation de rviz puis par ajouter le code nécessaire à l'affichage des formes. Nous avons ainsi décidé d'ajouter la variable du message de type ''Marker'' dans la classe Forme; celle-ci sera accessible par toutes les classes filles de Forme, notamment Cercle et Rectangle. Nous avons également créé une méthode ''display'' qui sera chargée de mettre à jour la position de la forme et de publier le message. Les différents ''setters'' des classes filles modifieront également le message pour qu'il soit à jour lors de l'envoi.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_rectangle.png|Affichage de la forme ''Rectangle'' dans Rviz
Fichier:Rviz_screenshot_cercle.png|Affichage de la forme ''Cercle'' dans Rviz
</gallery>

===Semaine 6===

Cette semaine, nous continuons d'améliorer l'affichage en programmant cette fois-ci la classe ''Robot'' (qui possède une forme, étant une Entité) pour pouvoir visualiser le robot avec rviz. Nous avons donc ajouté une fonction ''display'' à ''Entite'', faisant elle-même appel à la fonction ''display'' de sa forme; ce qui permettra un affichage plus facile de l'objet.

Nous avons également ajouté une forme ''Texte'' pour afficher du texte informatif sur les formes (par exemple, une lettre et un id pour une entité, "R1" dans le cas du premier robot de chaque équipe). Ce texte est affiché en cyan ou en magenta, en fonction de la couleur de l'équipe. Les noms des ''markers'' de la forme et du texte eux aussi dépendent du type de l'entité.

Enfin, nous avons permis au entités de type Machine de gérer leur affichage. Pour cela, nous avons dû créer une classe fille de cette entité pour pouvoir tester son affichage. Le choix s'est porté sur les machines de type BS (Base Station).

En cours de route, nous avons été confrontés à un problème au niveau de l'affichage en 2D. Il semblait logique que la hauteur des objets (en z) soit égale à 0 pour un affichage 2D, mais il s'est avéré que la couleur de l'objet était alors imprévisible (plus souvent noir que de la bonne couleur). Il en fait fallu laisser une légère épaisseur (0.001 mètres dans notre cas) pour que la couleur s'affiche correctement.

Un de nos objectifs était aussi de gérer l'affichage de l'orientation de nos entités. En effet, cela semble essentiel pour les robots par exemple, représentés par des ronds et pouvant se déplacer. Nous avons ainsi créé un nouveau marker ''Fleche''; il était également possible de changer le type de marker en ''interactive marker'' ce qui aurait permis l'affichage de flèches de direction, mais celles-ci permettaient de modifier la position de l'objet et n'étaient disponibles qu'en multiple de 2 (déplacement sur un axe). Le choix s'est donc porté sur l'utilisation d'un marker classique dont on change l'orientation en même temps que celle de l'entité.
Nous avons rencontré quelques soucis quant à la gestion de l'orientation du marker, celle-ci étant un ''quaternion'' (x, y, z, w) alors que nous souhaitons donner l'angle en degrés (ou en radians éventuellement); la documentation n'est pas forcément facile à trouver pour ROS.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_robot.png|Affichage de l'entité ''Robot'' dans Rviz
Fichier:Rviz_screenshot_machine.png|Affichage de l'entité ''BaseStation'' dans Rviz
Fichier:Rviz_screenshot_fleche.png|Affichage de l'entité ''Robot'' avec une forme ''Fleche'' dans Rviz
</gallery>

Nous avons dû corriger nos constructeurs pour être le plus efficace possible et remplir au maximum les besoins des futurs fonctions.

La problématique rendant nécessaire une gestion du temps vient du besoin de l'ARPL de pouvoir contrôler la vitesse de simulation et donc de pouvoir jouer un match très rapidement afin d'observer le comportement de leur code.
Nous avons commencé et fini la gestion du temps. ROS intègre une interface de temps qui se cale sur la machine qui lance ROS.
Pour que plusieurs machines suivent le même temps il faut opérer une synchronisation des temps. Cependant lors de la simulation tous les robots auront leur référentiel temporel sur la même machine ce qui rend une synchronisation inutile.

Il existe un topic ''clock'' qui sert pour les simulations. En forçant nos nœuds à utiliser le temps de simulation, nous avons une échelle temporelle utilisable et synchronisée. Nous avons donc un nœud qui va publier sur ce topic le temps qui sera initialisé à 0 en début de match.

Un paramètre d'environnement ROS sert à régler le facteur d'accélération de la simulation par rapport au temps réel. Il est modifiable à tout instant et est initialisé en premier dans le launchfile.

===Semaine 7===

Nous nous sommes attaqués à l'affichage du terrain dans rviz.

Pour cela, nous pouvions nous inspirer de code écrit par l'ARPL permettant de charger une carte depuis un fichier ''.yaml''. Certains de leurs packages nous ont été utiles, mais d'autres se sont avérés inutilisables tels quels à cause d'erreurs tantôt de "référence indéfinie" à un fichier, tantôt de "redéfinition" du même fichier (la cause de ces erreurs reste pour le moment toujours un mystère).
Nous avons donc opté, pour pouvoir avancer rapidement sur le projet, d'utiliser tel quel ce qu'il était possible d'utiliser, et sinon de recopier les fonctions nécessaires dans notre package. Certaines fonctions nécessitaient d'ailleurs de toute façon des modifications, car dans notre simulateur nous gérons aussi l'affichage de la carte alors qu'eux ne faisaient que la charger.

Un fichier ''.yaml'' a la syntaxe suivante :
field:
name: robocup_simulator
size: [14, 9, 0.0]
gradient:
distance: 0.35
minValue: 0
walls:
bottom1:
start: [-6, 0, 0.0]
end: [-4, 0, 0.0]

Nous avons donc commencé par charger le fichier en mémoire en le passant en paramètre à un ''launchfile'' lançant le nœud chargé de lire et d'afficher la carte. Ensuite, en faisant appel à des ''param'' (paramètres) du nœud actuel et en leur donnant le nom du champs (''name'' par exemple), on peut récupérer les valeurs du fichiers voulues.

Nous avons ainsi créé une classe ''Carte'' pour gérer le chargement des données depuis le fichier et toutes les fonctions utilitaires associées, mais permettant aussi d'afficher la carte grâce à une fonction ''display'' de même fonctionnement que celles créées précédemment pour les entités.

Pour l'affichage sur rviz, nous nous sommes servis du type d'objet ''Map'' pour visualiser le sol du terrain (en blanc ci-dessous). Nous avons également créé un vecteur de Rectangles pour afficher les murs (en bleu foncé ci-dessous) et un vecteur de Rectangles pour les zones interdites au robot (en noir).

Nous aurions aimé mettre à jour la taille de la grille affichée en fonction de la taille de la carte, mais il s'avère que c'est impossible, la grille ne provenant pas d'un message publié.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_map.png|Affichage du terrain de jeu dans Rviz
</gallery>

===Semaine 8===

Nous avons complété la fonction de gestion de la vitesse. Il n'y a plus de nœud pour gérer les déplacements au profit d'un nœud gérant chaque robot.
Les robots envoient un vecteur "twist" pour donner leur commande vitesse, soit deux vecteurs vitesse 3D, l'un pour la vitesse linéaire et l'autre pour la vitesse angulaire.
Cependant ce vecteur vitesse est paramétré dans le repère du robot, c'est-à-dire avec le vecteur x dirigé dans la direction de l'orientation du robot.
Pour nos calculs nous nous servons du repère originel, que ce soit pour placer les entités ou les déplacer. Cela facilite les calculs dans la simulation.
Ainsi nous devons transposer les vecteurs vitesse reçus pour les appliquer à notre repère.

La simulation fonctionnant en 2D nous simplifions les données en utilisant un seul vecteur 3D (x et y pour le déplacement linéaire et z pour le changement d'orientation soit la vitesse angulaire autour de l'axe z).
La transposition n'est nécessaire que pour les déplacements linéaires, donc nous utilisons de la trigonométrie simple et nous ajoutons le déplacement ainsi obtenu à la position actuelle, ce qui donne :

v_x = v_x1*cos(orientation_radian) - v_y1*sin(orientation_radian)

v_y = v_x1*sin(orientation_radian) + v_y1*sin(orientation_radian)

x_new = v_x *delta_t + x

y_new = v_y *delta_t + y

orientation_new = (v_angulaire*delta_t + orientation) [360]

Nous avons également apporté des modifications aux flèches et textes; en effet, maintenant que le déplacement des robots est possible, nous pouvons effectuer des tests.
Il s'avère que nous ne modifions pas la position des flèches et textes, le robot s'éloignait alors d'eux lorsqu'il se déplaçait.
Nous avons donc ajouté les quelques modifications nécessaires pour que ces formes suivent l'entité en déplacement.

Nous avons aussi commencé à compléter le package ''machine'' pour lui ajouter les sous-classes de Machine représentant les différentes machines (MPS) du jeu (BaseStation, CapStation, RingStation, DeliveryStation).
La BaseStation permettra au robot de récupérer un objet de type base, la RingStation d'y empiler des anneaux de couleurs différentes en fonction des commandes reçues, la CapStation de déposer un chapeau au sommet de l'objet et enfin on l'apporte à la DeliveryStation.

Nous avons complété ci-dessous les schémas UML du projet dans son état actuel :

<gallery style="margin: 0 auto;">
Fichier:Formes_package_Class_diagram_v3.png|Schéma UML du package ''formes''
Fichier:Machine_package_Class_diagram_v3.png|Schéma UML du package ''machine''
Fichier:Management_package_Class_diagram_v2.png|Schéma UML du package ''management''
Fichier:Robot_package_Class_diagram_v2.png|Schéma UML du package ''robot''
</gallery>

===Semaine 9===

Nous avons dû concevoir une fonction de récupération de distance entre deux entités.
Les robots étant les seules entités mobiles, nous ne calculons que la distance entre un robot et une autre entité.
La distance entre deux robots, soit deux cercles, est facile à déterminer. Nous récupérons les points des deux cercles étant sur la droite passant par les centres des dits cercles. Puis nous appliquons le calcul de distance.

Lorsqu'il s'agit de calculer la distance la plus courte avec un rectangle, c'est un peu plus compliqué et très rapidement le nombre de calculs devient très grand. Nous avons choisi une stratégie calculatoire réduisant le nombre de calculs avec les conseils de Mme Nathalie Delfosse.

Le problème est de trouver la distance la plus courte entre les deux formes ainsi que les points concernés.

[[Fichier:GD_1.png|500px|center|texte descriptif]]

Nous pouvons facilement tracer la zone de collision, soit la zone qui permet de dire qu'il y a une collision si le centre du robot est dessus.

[[Fichier:GD_2.png|500px|center|texte descriptif]]

Ensuite on découpe l'espace en 8 zones en prolongeant les cotés du rectangle pour en faire des droites.

[[Fichier:GD_3.png|500px|center|texte descriptif]]

Lorsqu'un robot se situe en zone n°1 alors la distance la plus proche est celle qui sépare le cercle de l'angle le plus proche du rectangle. Donc (S2) est cette distance avec la résolution du système composé de la droite par le centre du cercle et l'angle, et le cercle. Nous obtenons alors le point du cercle le plus proche du rectangle.

(S2)
(x−xc)²+(y−yc)²==R²
y= ax+b

Dans la zone n°2, la distance la plus courte est une droite verticale, ce qui nous donne facilement le point du cercle et le point du rectangle.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Cette semaine nous avons aussi travaillé sur la production elle-même en complétant les classes du package ''machine''. Nous avons ainsi ajouté à chaque sous-classe une fonction ''setup'' qui permet d'initialiser la machine, la plupart du temps avec une couleur d'anneau ou de base, et pour la ''DeliveryStation'' avec un numéro de porte.

Ces fonctions seront ensuite appelées dans un nœud ''machines_node'' du package ''management''.

===Semaine 10===

Cette semaine, nous avons avancé sur la simulation en permettant à une 'Equipe' d'afficher ses six machines et ses trois robots. Le 'Manager', lui, affiche les deux équipes; nous avons ainsi tous les acteurs d'un match sur le même terrain.

Nous avons également installé la Referee Box, dans la prévision du travail sur la communication entre simulation et celle-ci, mais aussi pour pouvoir utiliser des types de messages particuliers du package 'llsf_msgs' inclus avec la Referee Box.

En effet, les machines changent d'état en fonction des commandes qu'elles reçoivent. En effet, les équipes doivent remplir des commandes tout au long du match, et les robots ordonnent ainsi aux machines de produire des types de pièces particuliers.
Ils commencent par envoyer un message de 'setup' qui va indiquer à la machine quel type de pièce préparer. À ce moment là la machine change d'état (état occupé) et ceci est reflété dans la couleur de son feu.
Lorsque la pièce est disponible, la machine rechange d'état pour être de nouveau disponible.

Il existe également d'autres types d'états, comme lorsque la machine est 'down' lors d'une maintenance programmée décidée par la Referee Box au début du match, lorsque la machine vient de recevoir un ordre ou encore lorsqu'un robot tente de l'utiliser sans lui envoyer de message de 'setup, elle est alors hors-service pendant un certain moment.

===Heures supplémentaires===

Nous avons commencé par ajouter l'affichage des feux (composés d'un rectangle et de trois cercles rouge, jaune, vert).
En fonction de l'état de la machine à laquelle ils appartiennent, les couleurs affichés changent. D'après le règlement, si tout va bien le feu sera vert fixe, si la machine est occupée il sera jaune fixe et si la machine est en maintenance programmée il sera rouge fixe. Si la machine vient de recevoir un ordre, il sera vert clignotant et si elle est hors-service il sera clignotant jaune et rouge.

C'est pourquoi nous avons aussi implémenté le clignotement de celui-ci qu'il est possible de voir dans la vidéo ci-dessous.

Enfin, les machines seront positionnées de différentes manières au début d'un match, il est donc nécessaire que le feu associé ait la même rotation que sa machine.
Nous avons ainsi commencé par permettre aux cercles du haut et du bas d'effectuer un rotation autour du cercle central. Une fois la chose faite, nous avons modifié la rotation d'une machine. En effet, jusque là elle était implémentée de la même manière que pour les robots, or ceux-ci se déplacent et pas notre machine. Il n'est donc pas nécessaire que la flèche soit en rotation mais plutôt qu'elle soit positionnée de manière fixe (mais cela reste modifiable dans le code) et que ce soit le rectangle de la machine qui effectue une rotation sur lui-même. Il en va de même pour le rectangle du feu.

Enfin, nous avons dû gérer le positionnement du feu par rapport au rectangle : il faut, lorsque la machine effectue une rotation, calculer la position de son coin inférieur gauche et positionner le feu par rapport à celui-ci.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_feu_45_degres.png|Feu en rotation
Fichier:Rviz_screenshot_machine_135_degres.png|Machine et son feu en rotation
Fichier:Rviz_screenshot_machine_state_down.png|Machine en état de maintenance programmée
Fichier:Rviz_screenshot_machine_state_busy.png|Machine occupée
Fichier:Rviz_screenshot_machine_state_ok.png|Machine disponible
Fichier:Feu_clignotant.mp4|Vidéo du feu qui clignote
</gallery>

== Fichiers Rendus ==

Fichier:Rviz screenshot machine 135 degres.png

2017-04-27T06:48:00Z

Mbutaye : Affichage d'un feu de machine sur une machine en rotation dans RViz (heures supplémentaires) pour le projet P20 de 2016/17.

Affichage d'un feu de machine sur une machine en rotation dans RViz (heures supplémentaires) pour le projet P20 de 2016/17.

Fichier:Rviz screenshot feu 45 degres.png

2017-04-27T06:47:21Z

Mbutaye : Affichage d'un feu de machine en rotation dans RViz (heures supplémentaires) pour le projet P20 de 2016/17.

Affichage d'un feu de machine en rotation dans RViz (heures supplémentaires) pour le projet P20 de 2016/17.

Fichier:Rviz screenshot machine state down.png

2017-04-27T06:45:27Z

Mbutaye : Affichage d'un feu de machine dans l'état 'Down' dans RViz (heures supplémentaires) pour le projet P20 de 2016/17.

Affichage d'un feu de machine dans l'état 'Down' dans RViz (heures supplémentaires) pour le projet P20 de 2016/17.

Fichier:Rviz screenshot machine state ok.png

2017-04-27T06:45:05Z

Mbutaye : Affichage d'un feu de machine dans l'état 'Ok' dans RViz (heures supplémentaires) pour le projet P20 de 2016/17.

Affichage d'un feu de machine dans l'état 'Ok' dans RViz (heures supplémentaires) pour le projet P20 de 2016/17.

Fichier:Rviz screenshot machine state busy.png

2017-04-27T06:44:41Z

Mbutaye : Affichage d'un feu de machine dans l'état 'Busy' dans RViz (heures supplémentaires) pour le projet P20 de 2016/17.

Affichage d'un feu de machine dans l'état 'Busy' dans RViz (heures supplémentaires) pour le projet P20 de 2016/17.

Fichier:Feu clignotant.mp4

2017-04-27T06:41:15Z

Mbutaye : Vidéo de l'affichage d'un feu de machine clignotant dans RViz (heures supplémentaires) pour le projet P20 de 2016/17.

Vidéo de l'affichage d'un feu de machine clignotant dans RViz (heures supplémentaires) pour le projet P20 de 2016/17.

IMA4 2016/2017 P20

2017-04-27T06:19:51Z

Mbutaye : /* Feuille d'heures */

__TOC__
 
==Cahier des charges==

Ce cahier des charges a pour objectif de définir le projet, ce qui est attendu ainsi que les contraintes de conception qui lui sont associées.

===Présentation générale du projet===

Le projet consiste à concevoir et développer un environnement virtuel de test pour l'Association de Robotique de Polytech Lille (ARPL). Ce simulateur doit reproduire les conditions de participation à la Logistic League de manière à pouvoir obtenir rapidement des données et tester le code ainsi que les stratégies de jeu utilisés par les robots.

====Contexte====
Ce simulateur est un outil développé dans le cadre de la RoboCup et plus particulièrement de la Logistic League. La RoboCup est une compétition internationale de robotique dans laquelle on voit beaucoup d'entreprises et de robots connus tel que NAO. Cette compétition a pour but de mettre en avant les évolutions en matière de robotique ainsi que les qualités des organismes participants.

La Logistic League est une des différentes épreuves proposées. L'objectif est de repérer le terrain puis de produire des objets avec différents éléments fournis par des machines et à livrer dans des plages de temps données. Une RefereeBox ou boîte arbitre sert à la coordination ainsi qu'à l'arbitrage. C'est cette boite qui va informer le robots des différents objets à construire avec la date de livraison demandée. Elle va également donner leur rôles aux machines présentes sur le terrain. L'arbitre va enregistrer les horaires de dépôt des objets et la position de chacune des machines lors de la compétition.

Celle-ci se déroule sur une piste de la taille d'une salle moyenne. Chaque équipe peut utiliser jusqu'à trois robots Robotino 3 pour réaliser les tâches demandées. Sur la piste, à part les robots, se trouvent seulement des machines dites de production ou de livraison. Elles vont servir soit à se procurer un élément nécessaire à la production de l'objet final soit à livrer celui-ci lorsqu'il est terminé.

====Objectif du projet====

Ce projet va permettre de fournir à l'équipe de l'ARPL un simulateur léger et complet, leur permettant de simuler en un court laps de temps un match entier ou partiel et de tester leur code et leur stratégie. Cela leur permettra de développer plus rapidement et efficacement.

====Description du projet====

Le simulateur devra répondre à un certain nombre de critères. Tout d'abord il lui faudra pouvoir simuler toutes les entités présentes sur la piste lors d'un match. Nous parlons des robots et des machines mais également des capteurs et des conditions de jeu.

Nous devrons faire en sorte que le simulateur puisse facilement intégrer le code de contrôle des robots afin de le tester. De plus il faut permettre à l'utilisateur de gérer les parties du code à tester ainsi que de changer les conditions et paramètres de simulation afin de ne tester que certaines partie du code (par exemple en excluant la gestion des collisions). Nous inclurons une gestion des phases de jeu (Découverte et Production) dans ce but. De ce point de vue l'idéal serait de générer un launchfile et de permettre à l'utilisateur de gérer l'utilisation des nœuds un par un.

En sus, le simulateur gérant les robots de l'équipe adverse, il aura une fonctionnalité de sauvegarde des configurations que ce soit pour le code ou les stratégies afin de comparer l'évolution des performances.

Le simulateur a certaines contraintes afin d'être utilisable et utile. Il doit opérer une compression du temps c'est à dire réaliser la simulation d'un match en moins de temps qu'une durée normale de match. Il s'agit d'obtenir des données représentant la réalité en un cours laps de temps. La communication avec la RefereeBox est indispensable. Celle-ci étant fourni par les organisateurs de la compétition nous n'avons pas à la simuler mais nous devons communiquer avec elle pour rendre la simulation plus réaliste.

====Choix techniques : matériel et logiciel====

Nous n'avons pas besoin de matériel hormis d'ordinateurs afin de programmer.

Dû à la compétition et aux choix de développement de l'équipe de l'ARPL, nous allons programmer en C++ avec les bibliothèques QT ainsi que le middleware ROS, une surcouche de programmation destinée à la programmation de robots.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

*Simuler les différentes entités
** les Robotinos ;
** les machines ;
** l'environnement.

*Gérer l'interfaçage entre le simulateur et le code des Robots
** lire et lancer le méta-paquet ;
** identifier les différents parties du code ;
** proposer l'activation/désactivation de ces parties et créer un launchfile en conséquence ;
** créer un système de sauvegarde de tout code interfacé permettant sa réutilisation.

*Simuler un match
** communiquer avec la RefereeBox et recevoir les différents ordres de celle-ci ;
** gérer les machines et la communication avec la RefereeBox ;
** gérer l'équipe de l'utilisateur et son interaction avec le reste de la simulation ;
** gérer l'équipe adverse et son interaction avec le reste de la simulation.

*Paramétrage avancé de la simulation
** proposer différents modes de simulations ;
** activation/déssactivation des paramètres de la simulation ;
** gestion des phases.

*Interface utilisateur
** fournir des données utilisables et intéressantes sur la simulation ;
** créer une GUI ergonomique ;
** importer les données de la simulation sur la GUI pour une meilleure analyse de celle-ci.

====Calendrier====

Répartition du temps consacré au projet (120h/personne) :

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures supplémentaires !! Total
|-
| Définition cahier des charges
| 2
|
|
|
|
|
|
|
|
|
|
|
|2
|-
|Mise à niveau matérielle et intellectuelle
|
|13
|
|
|
|1
|
|
|
|
|
|
|14
|-
|Conception théorique
|
|5
|7
|4
|2
|
|
|0,5
|
|13
|2
|
|33.5
|-
|Programmation de la simulation
|
|
|8
|15
|16
|4
|8
|6
|10
|6
|10
|7
|90
|-
|Programmation de l'affichage avec rviz
|
|
|
|
|
|5
|8
|13
|6
|
|
|5
|37
|-
|Wiki
|
|
|0,5
|1,5
|1,5
|0,5
|2
|0,5
|3
|0,5
|0,5
|
|10,5
|-
|Réunions tuteurs
|2
|
|
|
|2
|2
|
|
|
|
|
|
|6
|-
|Total
|4
|18
|15,5
|20,5
|21,5
|12,5
|18
|20
|19
|19,5
|12,5
|12
|193
|}

==Planning des tâches==

{| class="wikitable"
!Tâche !! Date prévue !! Avancement !! Commentaires
|-
| Affichage des formes avec Rviz
| 01/03/2017
| Terminé
| Cercle & Rectangle
|-
| Affichage d'un robot
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Affichage d'une machine
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Gestion du temps
| 08/03/2017
| Terminé
| Bornes de facteurs possibles à déterminer
|-
| Déplacement d'un robot
| 22/03/2017
| Terminé
| Vitesse et déplacement au point; Besoin d'interfaçage sur le code ARPL
|-
| Affichage de l'orientation de l'entité
| 13/03/2017
| Terminé
| Affichage d'une forme Flèche dont l'orientation change avec celle de l'entité. Grise. Orientation en degrés.
|-
| Lecture et affichage de la map
| 19/03/2017
| Terminé
| Affichage de la map, des murs et des zones interdites.
|-
| Communication RefBox
| 01/04/2017
| Débuté
| Prise d'information sur le système
|-
| Gestion Collision
| 01/04/2017
| Débuté
| Prise d'information sur le système
|}

==Avancement du Projet==

===Semaine 1===
Nous avons commencé par installer ROS et tout ce dont nous avons besoin pour travailler correctement. Nous avons également suivi des [http://wiki.ros.org/ROS/Tutorials tutoriels] pour apprendre à utiliser ROS.

Pour pouvoir travailler en binôme sans problèmes et pour que nos encadrants puissent suivre notre avancement et tester le logiciel, nous avons utilisé le logiciel de gestion de versions Git, sur lequel on publie notre code au fur et à mesure.

Nous n'avions pas encore de dépôt sur celui-ci, donc nous avons commencé par réfléchir à la structure de notre projet.
Nous commencerons par implémenter la phase d'exploration, ce qui comprend aussi le déplacement du robot, la détection de machines et de feux ainsi qu'une interface utilisateur basique.

En effet, le match oppose deux équipes ayant jusque trois robotinos qui s'affrontent lors de deux phases. La première est la phase d'exploration, durant laquelle les robots doivent trouver les machines de leur équipe en explorant le terrain. Ils doivent annoncer la position des machines et les signaux des feux de celles-ci : chaque machine, peu importe son type, possède un feu tricolore (rouge, jaune, vert) qui durant la phase d'exploration aura une combinaison de lumières allumées aléatoirement (au moins une doit l'être).

La création d'un simulateur passe par la réflexion sur les besoins en conception du simulateur (décris en partie ci-dessus). Nous avons donc passé un certain temps à schématiser la structure de notre simulateur et à en assimiler les besoins et l'ordre de création.

===Semaine 2===
Nous avons récupéré un dépôt Git (nommé ''logistic-sim'') sur lequel travailler auprès de nos encadrants, nous pouvons donc commencer la programmation cette semaine.

Ceci étant notre premier projet mêlant ROS et Git, nous avons tenté de créer la structure du projet mais avons vite rencontré quelques difficultés.
Nous avons ensuite compris qu'il était nécessaire de d'abord créer un environnement de travail ROS pour le projet, dans lequel on clône ensuite le dépôt Git localement.

Nous obtenons ainsi la structure de projet suivante :
* Workspace ROS
** build
** devel
** src
*** CMakeLists.txt
*** logistic-sim

Les dossiers build, devel, src et CMakeList.txt sont des fichiers et dossiers générés par ''Catkin'', un outil permettant de créer des paquets ROS facilement.

Nous avons ensuite décidé de séparer le code du projet en différents dossiers en fonction des tâches à effectuer :
* '''Entites''' pour simuler les différentes entités (Robotinos, machines, environnement...)
* '''Gestion_Code''' pour gérer l'interfaçage entre le simulateur et le code des robots
* '''Match''' pour simuler le déroulement d'un match
* '''GUI''' pour l'interface utilisateur avec le framework Qt

Dans chacun de ces dossiers, nous créerons des ''packages'' contenant les différentes fonctionnalités du projet.

Chaque ''package'' a la structure suivante :
* CMakeLists.txt
* include pour les fichiers .h
* package.xml
* README.md
* src pour les classes et nodes .cpp
* launch pour les launchfiles

Dans un premier temps, on commence par la gestion de la position du robot et la reconnaissance des feux.

===Semaine 3===

Nous avons avancé sur la programmation de la gestion de la position du robot et de la reconnaissance des feux.

Nous avons décrit nos classes par des schémas UML avec l'outil gratuit ''Modélio'' pour créer une documentation facilement accessible. Les commentaires des fonctions, classes et fichiers au format ''Doxygen'' nous permettront également de générer une documentation du projet sous format HTML notamment.

Nous suivons aussi la normalisation du code donnée par l'ARPL pour avoir les mêmes conventions de nommage partout.

Nous avons décidé de créer un nouveau package ''match'' qui contiendra les nœuds correspondants aux différentes phases de jeu, et avons donc par conséquent commencé par créer un nœud pour la phase d'exploration.

Nous avons également commencé à réfléchir à la façon dont les informations sont communiquées dans le match : il y a un arbitre, la ''Referee Box'' qui permet de faire communiquer le simulateur et les robots jouant le match. En effet, l'arbitre prend les décisions importantes (placement des machines au début du jeu etc.) et c'est à lui que les robots s'adressent. Nous devons donc aussi communiquer avec lui pour recevoir certaines informations (par exemple les informations de base de la phase d'exploration) et les retransmettre dans le simulateur aux nœuds qui en auront besoin.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v1.png|Schéma UML du package ''machine''
Fichier:Formes_package_Class_diagram_v1.png|Schéma UML du package ''formes''
</gallery>

===Semaine 4===

Cette semaine, nous avons créé plusieurs nouveaux packages et modifié ceux qui avaient déjà été créés.

Nous avons créé la classe Cercle dans le package ''formes'', nous pouvons donc maintenant utiliser deux formes différentes, le rectangle et le cercle.
La classe Entite a elle aussi été rajoutée. En effet, certains attributs des machines sont communs avec ceux des robots; cette classe nous permet de les rassembler et les classes Machine et Robot hériteront ainsi de Entite.

Un nouveau package ''management'' a également fait son apparition. Il contiendra les classes Equipe et Manager. Le Manager sera chargé de créer les équipes et permettra d'y accéder partout dans le code, mais aussi de procéder aux différentes initialisations lors du démarrage d'une nouvelle phase.

Au package ''management'' s'ajoute le nouveau package ''robot'' dont le rôle est de simuler les robotinos lors du match.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v2.png|Schéma UML du package ''machine''
Fichier:Robot_package_Class_diagram_v1.png|Schéma UML du package ''robot''
Fichier:Formes_package_Class_diagram_v2.png|Schéma UML du package ''formes''
Fichier:Management_package_Class_diagram_v1.png|Schéma UML du package ''management''
</gallery>

Nous avons également rendu visite à l'un de nos tuteurs de stage pendant la semaine dans le but d'obtenir un premier retour sur notre travail et l'avancement du projet.

Nous avons pu effectuer immédiatement quelques modifications nécessaires suite aux commentaires de notre tuteur. Nous avons dû, par exemple, clôner leur projet dans le même espace de travail que le notre pour pouvoir réutiliser certains paquets de messages déjà créés. Cela permettra une meilleure compatibilité. D'autres modifications concernaient entre autres les conventions de nommage de certaines classes et l'ajout d'un dossier supplémentaire dans le dossier include de chaque package portant le nom de celui-ci, pour ne pas avoir de conflits quant au nommage des fichiers.

Une réunion avec toute l'équipe des tuteurs a été prévue pour la semaine 5.

===Semaine 5===

La semaine a commencé par une réunion avec l'équipe de l'ARPL se chargeant d'encadrer notre projet, c'est-à-dire Vincent et Thomas. Nous avons discuté ensemble de l'avancement du simulateur et de l'ordre dans lequel effectuer les tâches. Ils nous également demandé de créer un planning de nos tâches avec la date prévue pour chacune; ils auront en effet besoin de modifier leur code à certains endroits pour pouvoir utiliser le simulateur (nous n'aurons pas besoin de tous les nœuds, certains comme la détection Laser nous étant inutiles) et souhaiteraient savoir lorsque nous seront prêt à tester de nouvelles fonctionnalités.

Nous nous sommes lancés dans l'affichage des formes avec l'outil ''rviz'', qui permet de visualiser en 3D les messages de type ''visualisation_msgs'' qui lui sont envoyés sur le topic associé. Ces messages sont disponibles en différents types. Pour afficher les formes nous utiliseront le format ''Marker'' qui permet d'afficher un objet en 3D (cubes, sphères, flèches, cylindres) ou en 2D en lui donnant un z de 0.

Nous avons donc commencé par faire les tutoriels sur l'utilisation de rviz puis par ajouter le code nécessaire à l'affichage des formes. Nous avons ainsi décidé d'ajouter la variable du message de type ''Marker'' dans la classe Forme; celle-ci sera accessible par toutes les classes filles de Forme, notamment Cercle et Rectangle. Nous avons également créé une méthode ''display'' qui sera chargée de mettre à jour la position de la forme et de publier le message. Les différents ''setters'' des classes filles modifieront également le message pour qu'il soit à jour lors de l'envoi.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_rectangle.png|Affichage de la forme ''Rectangle'' dans Rviz
Fichier:Rviz_screenshot_cercle.png|Affichage de la forme ''Cercle'' dans Rviz
</gallery>

===Semaine 6===

Cette semaine, nous continuons d'améliorer l'affichage en programmant cette fois-ci la classe ''Robot'' (qui possède une forme, étant une Entité) pour pouvoir visualiser le robot avec rviz. Nous avons donc ajouté une fonction ''display'' à ''Entite'', faisant elle-même appel à la fonction ''display'' de sa forme; ce qui permettra un affichage plus facile de l'objet.

Nous avons également ajouté une forme ''Texte'' pour afficher du texte informatif sur les formes (par exemple, une lettre et un id pour une entité, "R1" dans le cas du premier robot de chaque équipe). Ce texte est affiché en cyan ou en magenta, en fonction de la couleur de l'équipe. Les noms des ''markers'' de la forme et du texte eux aussi dépendent du type de l'entité.

Enfin, nous avons permis au entités de type Machine de gérer leur affichage. Pour cela, nous avons dû créer une classe fille de cette entité pour pouvoir tester son affichage. Le choix s'est porté sur les machines de type BS (Base Station).

En cours de route, nous avons été confrontés à un problème au niveau de l'affichage en 2D. Il semblait logique que la hauteur des objets (en z) soit égale à 0 pour un affichage 2D, mais il s'est avéré que la couleur de l'objet était alors imprévisible (plus souvent noir que de la bonne couleur). Il en fait fallu laisser une légère épaisseur (0.001 mètres dans notre cas) pour que la couleur s'affiche correctement.

Un de nos objectifs était aussi de gérer l'affichage de l'orientation de nos entités. En effet, cela semble essentiel pour les robots par exemple, représentés par des ronds et pouvant se déplacer. Nous avons ainsi créé un nouveau marker ''Fleche''; il était également possible de changer le type de marker en ''interactive marker'' ce qui aurait permis l'affichage de flèches de direction, mais celles-ci permettaient de modifier la position de l'objet et n'étaient disponibles qu'en multiple de 2 (déplacement sur un axe). Le choix s'est donc porté sur l'utilisation d'un marker classique dont on change l'orientation en même temps que celle de l'entité.
Nous avons rencontré quelques soucis quant à la gestion de l'orientation du marker, celle-ci étant un ''quaternion'' (x, y, z, w) alors que nous souhaitons donner l'angle en degrés (ou en radians éventuellement); la documentation n'est pas forcément facile à trouver pour ROS.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_robot.png|Affichage de l'entité ''Robot'' dans Rviz
Fichier:Rviz_screenshot_machine.png|Affichage de l'entité ''BaseStation'' dans Rviz
Fichier:Rviz_screenshot_fleche.png|Affichage de l'entité ''Robot'' avec une forme ''Fleche'' dans Rviz
</gallery>

Nous avons dû corriger nos constructeurs pour être le plus efficace possible et remplir au maximum les besoins des futurs fonctions.

La problématique rendant nécessaire une gestion du temps vient du besoin de l'ARPL de pouvoir contrôler la vitesse de simulation et donc de pouvoir jouer un match très rapidement afin d'observer le comportement de leur code.
Nous avons commencé et fini la gestion du temps. ROS intègre une interface de temps qui se cale sur la machine qui lance ROS.
Pour que plusieurs machines suivent le même temps il faut opérer une synchronisation des temps. Cependant lors de la simulation tous les robots auront leur référentiel temporel sur la même machine ce qui rend une synchronisation inutile.

Il existe un topic ''clock'' qui sert pour les simulations. En forçant nos nœuds à utiliser le temps de simulation, nous avons une échelle temporelle utilisable et synchronisée. Nous avons donc un nœud qui va publier sur ce topic le temps qui sera initialisé à 0 en début de match.

Un paramètre d'environnement ROS sert à régler le facteur d'accélération de la simulation par rapport au temps réel. Il est modifiable à tout instant et est initialisé en premier dans le launchfile.

===Semaine 7===

Nous nous sommes attaqués à l'affichage du terrain dans rviz.

Pour cela, nous pouvions nous inspirer de code écrit par l'ARPL permettant de charger une carte depuis un fichier ''.yaml''. Certains de leurs packages nous ont été utiles, mais d'autres se sont avérés inutilisables tels quels à cause d'erreurs tantôt de "référence indéfinie" à un fichier, tantôt de "redéfinition" du même fichier (la cause de ces erreurs reste pour le moment toujours un mystère).
Nous avons donc opté, pour pouvoir avancer rapidement sur le projet, d'utiliser tel quel ce qu'il était possible d'utiliser, et sinon de recopier les fonctions nécessaires dans notre package. Certaines fonctions nécessitaient d'ailleurs de toute façon des modifications, car dans notre simulateur nous gérons aussi l'affichage de la carte alors qu'eux ne faisaient que la charger.

Un fichier ''.yaml'' a la syntaxe suivante :
field:
name: robocup_simulator
size: [14, 9, 0.0]
gradient:
distance: 0.35
minValue: 0
walls:
bottom1:
start: [-6, 0, 0.0]
end: [-4, 0, 0.0]

Nous avons donc commencé par charger le fichier en mémoire en le passant en paramètre à un ''launchfile'' lançant le nœud chargé de lire et d'afficher la carte. Ensuite, en faisant appel à des ''param'' (paramètres) du nœud actuel et en leur donnant le nom du champs (''name'' par exemple), on peut récupérer les valeurs du fichiers voulues.

Nous avons ainsi créé une classe ''Carte'' pour gérer le chargement des données depuis le fichier et toutes les fonctions utilitaires associées, mais permettant aussi d'afficher la carte grâce à une fonction ''display'' de même fonctionnement que celles créées précédemment pour les entités.

Pour l'affichage sur rviz, nous nous sommes servis du type d'objet ''Map'' pour visualiser le sol du terrain (en blanc ci-dessous). Nous avons également créé un vecteur de Rectangles pour afficher les murs (en bleu foncé ci-dessous) et un vecteur de Rectangles pour les zones interdites au robot (en noir).

Nous aurions aimé mettre à jour la taille de la grille affichée en fonction de la taille de la carte, mais il s'avère que c'est impossible, la grille ne provenant pas d'un message publié.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_map.png|Affichage du terrain de jeu dans Rviz
</gallery>

===Semaine 8===

Nous avons complété la fonction de gestion de la vitesse. Il n'y a plus de nœud pour gérer les déplacements au profit d'un nœud gérant chaque robot.
Les robots envoient un vecteur "twist" pour donner leur commande vitesse, soit deux vecteurs vitesse 3D, l'un pour la vitesse linéaire et l'autre pour la vitesse angulaire.
Cependant ce vecteur vitesse est paramétré dans le repère du robot, c'est-à-dire avec le vecteur x dirigé dans la direction de l'orientation du robot.
Pour nos calculs nous nous servons du repère originel, que ce soit pour placer les entités ou les déplacer. Cela facilite les calculs dans la simulation.
Ainsi nous devons transposer les vecteurs vitesse reçus pour les appliquer à notre repère.

La simulation fonctionnant en 2D nous simplifions les données en utilisant un seul vecteur 3D (x et y pour le déplacement linéaire et z pour le changement d'orientation soit la vitesse angulaire autour de l'axe z).
La transposition n'est nécessaire que pour les déplacements linéaires, donc nous utilisons de la trigonométrie simple et nous ajoutons le déplacement ainsi obtenu à la position actuelle, ce qui donne :

v_x = v_x1*cos(orientation_radian) - v_y1*sin(orientation_radian)

v_y = v_x1*sin(orientation_radian) + v_y1*sin(orientation_radian)

x_new = v_x *delta_t + x

y_new = v_y *delta_t + y

orientation_new = (v_angulaire*delta_t + orientation) [360]

Nous avons également apporté des modifications aux flèches et textes; en effet, maintenant que le déplacement des robots est possible, nous pouvons effectuer des tests.
Il s'avère que nous ne modifions pas la position des flèches et textes, le robot s'éloignait alors d'eux lorsqu'il se déplaçait.
Nous avons donc ajouté les quelques modifications nécessaires pour que ces formes suivent l'entité en déplacement.

Nous avons aussi commencé à compléter le package ''machine'' pour lui ajouter les sous-classes de Machine représentant les différentes machines (MPS) du jeu (BaseStation, CapStation, RingStation, DeliveryStation).
La BaseStation permettra au robot de récupérer un objet de type base, la RingStation d'y empiler des anneaux de couleurs différentes en fonction des commandes reçues, la CapStation de déposer un chapeau au sommet de l'objet et enfin on l'apporte à la DeliveryStation.

Nous avons complété ci-dessous les schémas UML du projet dans son état actuel :

<gallery style="margin: 0 auto;">
Fichier:Formes_package_Class_diagram_v3.png|Schéma UML du package ''formes''
Fichier:Machine_package_Class_diagram_v3.png|Schéma UML du package ''machine''
Fichier:Management_package_Class_diagram_v2.png|Schéma UML du package ''management''
Fichier:Robot_package_Class_diagram_v2.png|Schéma UML du package ''robot''
</gallery>

===Semaine 9===

Nous avons dû concevoir une fonction de récupération de distance entre deux entités.
Les robots étant les seules entités mobiles, nous ne calculons que la distance entre un robot et une autre entité.
La distance entre deux robots, soit deux cercles, est facile à déterminer. Nous récupérons les points des deux cercles étant sur la droite passant par les centres des dits cercles. Puis nous appliquons le calcul de distance.

Lorsqu'il s'agit de calculer la distance la plus courte avec un rectangle, c'est un peu plus compliqué et très rapidement le nombre de calculs devient très grand. Nous avons choisi une stratégie calculatoire réduisant le nombre de calculs avec les conseils de Mme Nathalie Delfosse.

Le problème est de trouver la distance la plus courte entre les deux formes ainsi que les points concernés.

[[Fichier:GD_1.png|500px|center|texte descriptif]]

Nous pouvons facilement tracer la zone de collision, soit la zone qui permet de dire qu'il y a une collision si le centre du robot est dessus.

[[Fichier:GD_2.png|500px|center|texte descriptif]]

Ensuite on découpe l'espace en 8 zones en prolongeant les cotés du rectangle pour en faire des droites.

[[Fichier:GD_3.png|500px|center|texte descriptif]]

Lorsqu'un robot se situe en zone n°1 alors la distance la plus proche est celle qui sépare le cercle de l'angle le plus proche du rectangle. Donc (S2) est cette distance avec la résolution du système composé de la droite par le centre du cercle et l'angle, et le cercle. Nous obtenons alors le point du cercle le plus proche du rectangle.

(S2)
(x−xc)²+(y−yc)²==R²
y= ax+b

Dans la zone n°2, la distance la plus courte est une droite verticale, ce qui nous donne facilement le point du cercle et le point du rectangle.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Cette semaine nous avons aussi travaillé sur la production elle-même en complétant les classes du package ''machine''. Nous avons ainsi ajouté à chaque sous-classe une fonction ''setup'' qui permet d'initialiser la machine, la plupart du temps avec une couleur d'anneau ou de base, et pour la ''DeliveryStation'' avec un numéro de porte.

Ces fonctions seront ensuite appelées dans un nœud ''machines_node'' du package ''management''.

===Semaine 10===

== Fichiers Rendus ==

IMA4 2016/2017 P20

2017-04-05T15:39:28Z

Mbutaye : /* Semaine 9 */

__TOC__
 
==Cahier des charges==

Ce cahier des charges a pour objectif de définir le projet, ce qui est attendu ainsi que les contraintes de conception qui lui sont associées.

===Présentation générale du projet===

Le projet consiste à concevoir et développer un environnement virtuel de test pour l'Association de Robotique de Polytech Lille (ARPL). Ce simulateur doit reproduire les conditions de participation à la Logistic League de manière à pouvoir obtenir rapidement des données et tester le code ainsi que les stratégies de jeu utilisés par les robots.

====Contexte====
Ce simulateur est un outil développé dans le cadre de la RoboCup et plus particulièrement de la Logistic League. La RoboCup est une compétition internationale de robotique dans laquelle on voit beaucoup d'entreprises et de robots connus tel que NAO. Cette compétition a pour but de mettre en avant les évolutions en matière de robotique ainsi que les qualités des organismes participants.

La Logistic League est une des différentes épreuves proposées. L'objectif est de repérer le terrain puis de produire des objets avec différents éléments fournis par des machines et à livrer dans des plages de temps données. Une RefereeBox ou boîte arbitre sert à la coordination ainsi qu'à l'arbitrage. C'est cette boite qui va informer le robots des différents objets à construire avec la date de livraison demandée. Elle va également donner leur rôles aux machines présentes sur le terrain. L'arbitre va enregistrer les horaires de dépôt des objets et la position de chacune des machines lors de la compétition.

Celle-ci se déroule sur une piste de la taille d'une salle moyenne. Chaque équipe peut utiliser jusqu'à trois robots Robotino 3 pour réaliser les tâches demandées. Sur la piste, à part les robots, se trouvent seulement des machines dites de production ou de livraison. Elles vont servir soit à se procurer un élément nécessaire à la production de l'objet final soit à livrer celui-ci lorsqu'il est terminé.

====Objectif du projet====

Ce projet va permettre de fournir à l'équipe de l'ARPL un simulateur léger et complet, leur permettant de simuler en un court laps de temps un match entier ou partiel et de tester leur code et leur stratégie. Cela leur permettra de développer plus rapidement et efficacement.

====Description du projet====

Le simulateur devra répondre à un certain nombre de critères. Tout d'abord il lui faudra pouvoir simuler toutes les entités présentes sur la piste lors d'un match. Nous parlons des robots et des machines mais également des capteurs et des conditions de jeu.

Nous devrons faire en sorte que le simulateur puisse facilement intégrer le code de contrôle des robots afin de le tester. De plus il faut permettre à l'utilisateur de gérer les parties du code à tester ainsi que de changer les conditions et paramètres de simulation afin de ne tester que certaines partie du code (par exemple en excluant la gestion des collisions). Nous inclurons une gestion des phases de jeu (Découverte et Production) dans ce but. De ce point de vue l'idéal serait de générer un launchfile et de permettre à l'utilisateur de gérer l'utilisation des nœuds un par un.

En sus, le simulateur gérant les robots de l'équipe adverse, il aura une fonctionnalité de sauvegarde des configurations que ce soit pour le code ou les stratégies afin de comparer l'évolution des performances.

Le simulateur a certaines contraintes afin d'être utilisable et utile. Il doit opérer une compression du temps c'est à dire réaliser la simulation d'un match en moins de temps qu'une durée normale de match. Il s'agit d'obtenir des données représentant la réalité en un cours laps de temps. La communication avec la RefereeBox est indispensable. Celle-ci étant fourni par les organisateurs de la compétition nous n'avons pas à la simuler mais nous devons communiquer avec elle pour rendre la simulation plus réaliste.

====Choix techniques : matériel et logiciel====

Nous n'avons pas besoin de matériel hormis d'ordinateurs afin de programmer.

Dû à la compétition et aux choix de développement de l'équipe de l'ARPL, nous allons programmer en C++ avec les bibliothèques QT ainsi que le middleware ROS, une surcouche de programmation destinée à la programmation de robots.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

*Simuler les différentes entités
** les Robotinos ;
** les machines ;
** l'environnement.

*Gérer l'interfaçage entre le simulateur et le code des Robots
** lire et lancer le méta-paquet ;
** identifier les différents parties du code ;
** proposer l'activation/désactivation de ces parties et créer un launchfile en conséquence ;
** créer un système de sauvegarde de tout code interfacé permettant sa réutilisation.

*Simuler un match
** communiquer avec la RefereeBox et recevoir les différents ordres de celle-ci ;
** gérer les machines et la communication avec la RefereeBox ;
** gérer l'équipe de l'utilisateur et son interaction avec le reste de la simulation ;
** gérer l'équipe adverse et son interaction avec le reste de la simulation.

*Paramétrage avancé de la simulation
** proposer différents modes de simulations ;
** activation/déssactivation des paramètres de la simulation ;
** gestion des phases.

*Interface utilisateur
** fournir des données utilisables et intéressantes sur la simulation ;
** créer une GUI ergonomique ;
** importer les données de la simulation sur la GUI pour une meilleure analyse de celle-ci.

====Calendrier====

Répartition du temps consacré au projet (120h/personne) :

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 2
|
|
|
|
|
|
|
|
|
|
|
|-
|Mise à niveau matérielle et intellectuelle
|
|13
|
|
|
|1
|
|
|
|
|
|
|-
|Conception théorique
|
|5
|7
|4
|2
|
|
|0,5
|
|13
|
|
|-
|Programmation de la simulation
|
|
|8
|15
|16
|4
|8
|6
|10
|6
|
|
|-
|Programmation de l'affichage avec rviz
|
|
|
|
|
|5
|8
|13
|6
|
|
|
|-
|Wiki
|
|
|0,5
|1,5
|1,5
|0,5
|2
|0,5
|3
|0,5
|
|
|-
|Réunions tuteurs
|2
|
|
|
|2
|2
|
|
|
|
|
|
|}

==Planning des tâches==

{| class="wikitable"
!Tâche !! Date prévue !! Avancement !! Commentaires
|-
| Affichage des formes avec Rviz
| 01/03/2017
| Terminé
| Cercle & Rectangle
|-
| Affichage d'un robot
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Affichage d'une machine
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Gestion du temps
| 08/03/2017
| Terminé
| Bornes de facteurs possibles à déterminer
|-
| Déplacement d'un robot
| 22/03/2017
| Terminé
| Vitesse et déplacement au point; Besoin d'interfaçage sur le code ARPL
|-
| Affichage de l'orientation de l'entité
| 13/03/2017
| Terminé
| Affichage d'une forme Flèche dont l'orientation change avec celle de l'entité. Grise. Orientation en degrés.
|-
| Lecture et affichage de la map
| 19/03/2017
| Terminé
| Affichage de la map, des murs et des zones interdites.
|-
| Communication RefBox
| 01/04/2017
| Débuté
| Prise d'information sur le système
|-
| Gestion Collision
| 01/04/2017
| Débuté
| Prise d'information sur le système
|}

==Avancement du Projet==

===Semaine 1===
Nous avons commencé par installer ROS et tout ce dont nous avons besoin pour travailler correctement. Nous avons également suivi des [http://wiki.ros.org/ROS/Tutorials tutoriels] pour apprendre à utiliser ROS.

Pour pouvoir travailler en binôme sans problèmes et pour que nos encadrants puissent suivre notre avancement et tester le logiciel, nous avons utilisé le logiciel de gestion de versions Git, sur lequel on publie notre code au fur et à mesure.

Nous n'avions pas encore de dépôt sur celui-ci, donc nous avons commencé par réfléchir à la structure de notre projet.
Nous commencerons par implémenter la phase d'exploration, ce qui comprend aussi le déplacement du robot, la détection de machines et de feux ainsi qu'une interface utilisateur basique.

En effet, le match oppose deux équipes ayant jusque trois robotinos qui s'affrontent lors de deux phases. La première est la phase d'exploration, durant laquelle les robots doivent trouver les machines de leur équipe en explorant le terrain. Ils doivent annoncer la position des machines et les signaux des feux de celles-ci : chaque machine, peu importe son type, possède un feu tricolore (rouge, jaune, vert) qui durant la phase d'exploration aura une combinaison de lumières allumées aléatoirement (au moins une doit l'être).

La création d'un simulateur passe par la réflexion sur les besoins en conception du simulateur (décris en partie ci-dessus). Nous avons donc passé un certain temps à schématiser la structure de notre simulateur et à en assimiler les besoins et l'ordre de création.

===Semaine 2===
Nous avons récupéré un dépôt Git (nommé ''logistic-sim'') sur lequel travailler auprès de nos encadrants, nous pouvons donc commencer la programmation cette semaine.

Ceci étant notre premier projet mêlant ROS et Git, nous avons tenté de créer la structure du projet mais avons vite rencontré quelques difficultés.
Nous avons ensuite compris qu'il était nécessaire de d'abord créer un environnement de travail ROS pour le projet, dans lequel on clône ensuite le dépôt Git localement.

Nous obtenons ainsi la structure de projet suivante :
* Workspace ROS
** build
** devel
** src
*** CMakeLists.txt
*** logistic-sim

Les dossiers build, devel, src et CMakeList.txt sont des fichiers et dossiers générés par ''Catkin'', un outil permettant de créer des paquets ROS facilement.

Nous avons ensuite décidé de séparer le code du projet en différents dossiers en fonction des tâches à effectuer :
* '''Entites''' pour simuler les différentes entités (Robotinos, machines, environnement...)
* '''Gestion_Code''' pour gérer l'interfaçage entre le simulateur et le code des robots
* '''Match''' pour simuler le déroulement d'un match
* '''GUI''' pour l'interface utilisateur avec le framework Qt

Dans chacun de ces dossiers, nous créerons des ''packages'' contenant les différentes fonctionnalités du projet.

Chaque ''package'' a la structure suivante :
* CMakeLists.txt
* include pour les fichiers .h
* package.xml
* README.md
* src pour les classes et nodes .cpp
* launch pour les launchfiles

Dans un premier temps, on commence par la gestion de la position du robot et la reconnaissance des feux.

===Semaine 3===

Nous avons avancé sur la programmation de la gestion de la position du robot et de la reconnaissance des feux.

Nous avons décrit nos classes par des schémas UML avec l'outil gratuit ''Modélio'' pour créer une documentation facilement accessible. Les commentaires des fonctions, classes et fichiers au format ''Doxygen'' nous permettront également de générer une documentation du projet sous format HTML notamment.

Nous suivons aussi la normalisation du code donnée par l'ARPL pour avoir les mêmes conventions de nommage partout.

Nous avons décidé de créer un nouveau package ''match'' qui contiendra les nœuds correspondants aux différentes phases de jeu, et avons donc par conséquent commencé par créer un nœud pour la phase d'exploration.

Nous avons également commencé à réfléchir à la façon dont les informations sont communiquées dans le match : il y a un arbitre, la ''Referee Box'' qui permet de faire communiquer le simulateur et les robots jouant le match. En effet, l'arbitre prend les décisions importantes (placement des machines au début du jeu etc.) et c'est à lui que les robots s'adressent. Nous devons donc aussi communiquer avec lui pour recevoir certaines informations (par exemple les informations de base de la phase d'exploration) et les retransmettre dans le simulateur aux nœuds qui en auront besoin.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v1.png|Schéma UML du package ''machine''
Fichier:Formes_package_Class_diagram_v1.png|Schéma UML du package ''formes''
</gallery>

===Semaine 4===

Cette semaine, nous avons créé plusieurs nouveaux packages et modifié ceux qui avaient déjà été créés.

Nous avons créé la classe Cercle dans le package ''formes'', nous pouvons donc maintenant utiliser deux formes différentes, le rectangle et le cercle.
La classe Entite a elle aussi été rajoutée. En effet, certains attributs des machines sont communs avec ceux des robots; cette classe nous permet de les rassembler et les classes Machine et Robot hériteront ainsi de Entite.

Un nouveau package ''management'' a également fait son apparition. Il contiendra les classes Equipe et Manager. Le Manager sera chargé de créer les équipes et permettra d'y accéder partout dans le code, mais aussi de procéder aux différentes initialisations lors du démarrage d'une nouvelle phase.

Au package ''management'' s'ajoute le nouveau package ''robot'' dont le rôle est de simuler les robotinos lors du match.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v2.png|Schéma UML du package ''machine''
Fichier:Robot_package_Class_diagram_v1.png|Schéma UML du package ''robot''
Fichier:Formes_package_Class_diagram_v2.png|Schéma UML du package ''formes''
Fichier:Management_package_Class_diagram_v1.png|Schéma UML du package ''management''
</gallery>

Nous avons également rendu visite à l'un de nos tuteurs de stage pendant la semaine dans le but d'obtenir un premier retour sur notre travail et l'avancement du projet.

Nous avons pu effectuer immédiatement quelques modifications nécessaires suite aux commentaires de notre tuteur. Nous avons dû, par exemple, clôner leur projet dans le même espace de travail que le notre pour pouvoir réutiliser certains paquets de messages déjà créés. Cela permettra une meilleure compatibilité. D'autres modifications concernaient entre autres les conventions de nommage de certaines classes et l'ajout d'un dossier supplémentaire dans le dossier include de chaque package portant le nom de celui-ci, pour ne pas avoir de conflits quant au nommage des fichiers.

Une réunion avec toute l'équipe des tuteurs a été prévue pour la semaine 5.

===Semaine 5===

La semaine a commencé par une réunion avec l'équipe de l'ARPL se chargeant d'encadrer notre projet, c'est-à-dire Vincent et Thomas. Nous avons discuté ensemble de l'avancement du simulateur et de l'ordre dans lequel effectuer les tâches. Ils nous également demandé de créer un planning de nos tâches avec la date prévue pour chacune; ils auront en effet besoin de modifier leur code à certains endroits pour pouvoir utiliser le simulateur (nous n'aurons pas besoin de tous les nœuds, certains comme la détection Laser nous étant inutiles) et souhaiteraient savoir lorsque nous seront prêt à tester de nouvelles fonctionnalités.

Nous nous sommes lancés dans l'affichage des formes avec l'outil ''rviz'', qui permet de visualiser en 3D les messages de type ''visualisation_msgs'' qui lui sont envoyés sur le topic associé. Ces messages sont disponibles en différents types. Pour afficher les formes nous utiliseront le format ''Marker'' qui permet d'afficher un objet en 3D (cubes, sphères, flèches, cylindres) ou en 2D en lui donnant un z de 0.

Nous avons donc commencé par faire les tutoriels sur l'utilisation de rviz puis par ajouter le code nécessaire à l'affichage des formes. Nous avons ainsi décidé d'ajouter la variable du message de type ''Marker'' dans la classe Forme; celle-ci sera accessible par toutes les classes filles de Forme, notamment Cercle et Rectangle. Nous avons également créé une méthode ''display'' qui sera chargée de mettre à jour la position de la forme et de publier le message. Les différents ''setters'' des classes filles modifieront également le message pour qu'il soit à jour lors de l'envoi.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_rectangle.png|Affichage de la forme ''Rectangle'' dans Rviz
Fichier:Rviz_screenshot_cercle.png|Affichage de la forme ''Cercle'' dans Rviz
</gallery>

===Semaine 6===

Cette semaine, nous continuons d'améliorer l'affichage en programmant cette fois-ci la classe ''Robot'' (qui possède une forme, étant une Entité) pour pouvoir visualiser le robot avec rviz. Nous avons donc ajouté une fonction ''display'' à ''Entite'', faisant elle-même appel à la fonction ''display'' de sa forme; ce qui permettra un affichage plus facile de l'objet.

Nous avons également ajouté une forme ''Texte'' pour afficher du texte informatif sur les formes (par exemple, une lettre et un id pour une entité, "R1" dans le cas du premier robot de chaque équipe). Ce texte est affiché en cyan ou en magenta, en fonction de la couleur de l'équipe. Les noms des ''markers'' de la forme et du texte eux aussi dépendent du type de l'entité.

Enfin, nous avons permis au entités de type Machine de gérer leur affichage. Pour cela, nous avons dû créer une classe fille de cette entité pour pouvoir tester son affichage. Le choix s'est porté sur les machines de type BS (Base Station).

En cours de route, nous avons été confrontés à un problème au niveau de l'affichage en 2D. Il semblait logique que la hauteur des objets (en z) soit égale à 0 pour un affichage 2D, mais il s'est avéré que la couleur de l'objet était alors imprévisible (plus souvent noir que de la bonne couleur). Il en fait fallu laisser une légère épaisseur (0.001 mètres dans notre cas) pour que la couleur s'affiche correctement.

Un de nos objectifs était aussi de gérer l'affichage de l'orientation de nos entités. En effet, cela semble essentiel pour les robots par exemple, représentés par des ronds et pouvant se déplacer. Nous avons ainsi créé un nouveau marker ''Fleche''; il était également possible de changer le type de marker en ''interactive marker'' ce qui aurait permis l'affichage de flèches de direction, mais celles-ci permettaient de modifier la position de l'objet et n'étaient disponibles qu'en multiple de 2 (déplacement sur un axe). Le choix s'est donc porté sur l'utilisation d'un marker classique dont on change l'orientation en même temps que celle de l'entité.
Nous avons rencontré quelques soucis quant à la gestion de l'orientation du marker, celle-ci étant un ''quaternion'' (x, y, z, w) alors que nous souhaitons donner l'angle en degrés (ou en radians éventuellement); la documentation n'est pas forcément facile à trouver pour ROS.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_robot.png|Affichage de l'entité ''Robot'' dans Rviz
Fichier:Rviz_screenshot_machine.png|Affichage de l'entité ''BaseStation'' dans Rviz
Fichier:Rviz_screenshot_fleche.png|Affichage de l'entité ''Robot'' avec une forme ''Fleche'' dans Rviz
</gallery>

Nous avons dû corriger nos constructeurs pour être le plus efficace possible et remplir au maximum les besoins des futurs fonctions.

La problématique rendant nécessaire une gestion du temps vient du besoin de l'ARPL de pouvoir contrôler la vitesse de simulation et donc de pouvoir jouer un match très rapidement afin d'observer le comportement de leur code.
Nous avons commencé et fini la gestion du temps. ROS intègre une interface de temps qui se cale sur la machine qui lance ROS.
Pour que plusieurs machines suivent le même temps il faut opérer une synchronisation des temps. Cependant lors de la simulation tous les robots auront leur référentiel temporel sur la même machine ce qui rend une synchronisation inutile.

Il existe un topic ''clock'' qui sert pour les simulations. En forçant nos nœuds à utiliser le temps de simulation, nous avons une échelle temporelle utilisable et synchronisée. Nous avons donc un nœud qui va publier sur ce topic le temps qui sera initialisé à 0 en début de match.

Un paramètre d'environnement ROS sert à régler le facteur d'accélération de la simulation par rapport au temps réel. Il est modifiable à tout instant et est initialisé en premier dans le launchfile.

===Semaine 7===

Nous nous sommes attaqués à l'affichage du terrain dans rviz.

Pour cela, nous pouvions nous inspirer de code écrit par l'ARPL permettant de charger une carte depuis un fichier ''.yaml''. Certains de leurs packages nous ont été utiles, mais d'autres se sont avérés inutilisables tels quels à cause d'erreurs tantôt de "référence indéfinie" à un fichier, tantôt de "redéfinition" du même fichier (la cause de ces erreurs reste pour le moment toujours un mystère).
Nous avons donc opté, pour pouvoir avancer rapidement sur le projet, d'utiliser tel quel ce qu'il était possible d'utiliser, et sinon de recopier les fonctions nécessaires dans notre package. Certaines fonctions nécessitaient d'ailleurs de toute façon des modifications, car dans notre simulateur nous gérons aussi l'affichage de la carte alors qu'eux ne faisaient que la charger.

Un fichier ''.yaml'' a la syntaxe suivante :
field:
name: robocup_simulator
size: [14, 9, 0.0]
gradient:
distance: 0.35
minValue: 0
walls:
bottom1:
start: [-6, 0, 0.0]
end: [-4, 0, 0.0]

Nous avons donc commencé par charger le fichier en mémoire en le passant en paramètre à un ''launchfile'' lançant le nœud chargé de lire et d'afficher la carte. Ensuite, en faisant appel à des ''param'' (paramètres) du nœud actuel et en leur donnant le nom du champs (''name'' par exemple), on peut récupérer les valeurs du fichiers voulues.

Nous avons ainsi créé une classe ''Carte'' pour gérer le chargement des données depuis le fichier et toutes les fonctions utilitaires associées, mais permettant aussi d'afficher la carte grâce à une fonction ''display'' de même fonctionnement que celles créées précédemment pour les entités.

Pour l'affichage sur rviz, nous nous sommes servis du type d'objet ''Map'' pour visualiser le sol du terrain (en blanc ci-dessous). Nous avons également créé un vecteur de Rectangles pour afficher les murs (en bleu foncé ci-dessous) et un vecteur de Rectangles pour les zones interdites au robot (en noir).

Nous aurions aimé mettre à jour la taille de la grille affichée en fonction de la taille de la carte, mais il s'avère que c'est impossible, la grille ne provenant pas d'un message publié.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_map.png|Affichage du terrain de jeu dans Rviz
</gallery>

===Semaine 8===

Nous avons complété la fonction de gestion de la vitesse. Il n'y a plus de nœud pour gérer les déplacements au profit d'un nœud gérant chaque robot.
Les robots envoient un vecteur "twist" pour donner leur commande vitesse, soit deux vecteurs vitesse 3D, l'un pour la vitesse linéaire et l'autre pour la vitesse angulaire.
Cependant ce vecteur vitesse est paramétré dans le repère du robot, c'est-à-dire avec le vecteur x dirigé dans la direction de l'orientation du robot.
Pour nos calculs nous nous servons du repère originel, que ce soit pour placer les entités ou les déplacer. Cela facilite les calculs dans la simulation.
Ainsi nous devons transposer les vecteurs vitesse reçus pour les appliquer à notre repère.

La simulation fonctionnant en 2D nous simplifions les données en utilisant un seul vecteur 3D (x et y pour le déplacement linéaire et z pour le changement d'orientation soit la vitesse angulaire autour de l'axe z).
La transposition n'est nécessaire que pour les déplacements linéaires, donc nous utilisons de la trigonométrie simple et nous ajoutons le déplacement ainsi obtenu à la position actuelle, ce qui donne :

v_x = v_x1*cos(orientation_radian) - v_y1*sin(orientation_radian)

v_y = v_x1*sin(orientation_radian) + v_y1*sin(orientation_radian)

x_new = v_x *delta_t + x

y_new = v_y *delta_t + y

orientation_new = (v_angulaire*delta_t + orientation) [360]

Nous avons également apporté des modifications aux flèches et textes; en effet, maintenant que le déplacement des robots est possible, nous pouvons effectuer des tests.
Il s'avère que nous ne modifions pas la position des flèches et textes, le robot s'éloignait alors d'eux lorsqu'il se déplaçait.
Nous avons donc ajouté les quelques modifications nécessaires pour que ces formes suivent l'entité en déplacement.

Nous avons aussi commencé à compléter le package ''machine'' pour lui ajouter les sous-classes de Machine représentant les différentes machines (MPS) du jeu (BaseStation, CapStation, RingStation, DeliveryStation).
La BaseStation permettra au robot de récupérer un objet de type base, la RingStation d'y empiler des anneaux de couleurs différentes en fonction des commandes reçues, la CapStation de déposer un chapeau au sommet de l'objet et enfin on l'apporte à la DeliveryStation.

Nous avons complété ci-dessous les schémas UML du projet dans son état actuel :

<gallery style="margin: 0 auto;">
Fichier:Formes_package_Class_diagram_v3.png|Schéma UML du package ''formes''
Fichier:Machine_package_Class_diagram_v3.png|Schéma UML du package ''machine''
Fichier:Management_package_Class_diagram_v2.png|Schéma UML du package ''management''
Fichier:Robot_package_Class_diagram_v2.png|Schéma UML du package ''robot''
</gallery>

===Semaine 9===

Nous avons dû concevoir une fonction de récupération de distance entre deux entités.
Les robots étant les seules entités mobiles, nous ne calculons que la distance entre un robot et une autre entité.
La distance entre deux robots, soit deux cercles, est facile à déterminer. Nous récupérons les points des deux cercles étant sur la droite passant par les centres des dits cercles. Puis nous appliquons le calcul de distance.

Lorsqu'il s'agit de calculer la distance la plus courte avec un rectangle, c'est un peu plus compliqué et très rapidement le nombre de calculs devient très grand. Nous avons choisi une stratégie calculatoire réduisant le nombre de calculs avec les conseils de Mme Nathalie Delfosse.

Le problème est de trouver la distance la plus courte entre les deux formes ainsi que les points concernés.

[[Fichier:GD_1.png|500px|center|texte descriptif]]

Nous pouvons facilement tracer la zone de collision, soit la zone qui permet de dire qu'il y a une collision si le centre du robot est dessus.

[[Fichier:GD_2.png|500px|center|texte descriptif]]

Ensuite on découpe l'espace en 8 zones en prolongeant les cotés du rectangle pour en faire des droites.

[[Fichier:GD_3.png|500px|center|texte descriptif]]

Lorsqu'un robot se situe en zone n°1 alors la distance la plus proche est celle qui sépare le cercle de l'angle le plus proche du rectangle. Donc (S2) est cette distance avec la résolution du système composé de la droite par le centre du cercle et l'angle, et le cercle. Nous obtenons alors le point du cercle le plus proche du rectangle.

(S2)

Dans la zone n°2, la distance la plus courte est une droite verticale, ce qui nous donne facilement le point du cercle et le point du rectangle.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

Cette semaine nous avons aussi travaillé sur la production elle-même en complétant les classes du package ''machine''. Nous avons ainsi ajouté à chaque sous-classe une fonction ''setup'' qui permet d'initialiser la machine, la plupart du temps avec une couleur d'anneau ou de base, et pour la ''DeliveryStation'' avec un numéro de porte.

Ces fonctions seront ensuite appelées dans un nœud ''machines_node'' du package ''management''.

===Semaine 10===

== Fichiers Rendus ==

IMA4 2016/2017 P20

2017-04-05T14:14:24Z

Mbutaye : /* Feuille d'heures */

__TOC__
 
==Cahier des charges==

Ce cahier des charges a pour objectif de définir le projet, ce qui est attendu ainsi que les contraintes de conception qui lui sont associées.

===Présentation générale du projet===

Le projet consiste à concevoir et développer un environnement virtuel de test pour l'Association de Robotique de Polytech Lille (ARPL). Ce simulateur doit reproduire les conditions de participation à la Logistic League de manière à pouvoir obtenir rapidement des données et tester le code ainsi que les stratégies de jeu utilisés par les robots.

====Contexte====
Ce simulateur est un outil développé dans le cadre de la RoboCup et plus particulièrement de la Logistic League. La RoboCup est une compétition internationale de robotique dans laquelle on voit beaucoup d'entreprises et de robots connus tel que NAO. Cette compétition a pour but de mettre en avant les évolutions en matière de robotique ainsi que les qualités des organismes participants.

La Logistic League est une des différentes épreuves proposées. L'objectif est de repérer le terrain puis de produire des objets avec différents éléments fournis par des machines et à livrer dans des plages de temps données. Une RefereeBox ou boîte arbitre sert à la coordination ainsi qu'à l'arbitrage. C'est cette boite qui va informer le robots des différents objets à construire avec la date de livraison demandée. Elle va également donner leur rôles aux machines présentes sur le terrain. L'arbitre va enregistrer les horaires de dépôt des objets et la position de chacune des machines lors de la compétition.

Celle-ci se déroule sur une piste de la taille d'une salle moyenne. Chaque équipe peut utiliser jusqu'à trois robots Robotino 3 pour réaliser les tâches demandées. Sur la piste, à part les robots, se trouvent seulement des machines dites de production ou de livraison. Elles vont servir soit à se procurer un élément nécessaire à la production de l'objet final soit à livrer celui-ci lorsqu'il est terminé.

====Objectif du projet====

Ce projet va permettre de fournir à l'équipe de l'ARPL un simulateur léger et complet, leur permettant de simuler en un court laps de temps un match entier ou partiel et de tester leur code et leur stratégie. Cela leur permettra de développer plus rapidement et efficacement.

====Description du projet====

Le simulateur devra répondre à un certain nombre de critères. Tout d'abord il lui faudra pouvoir simuler toutes les entités présentes sur la piste lors d'un match. Nous parlons des robots et des machines mais également des capteurs et des conditions de jeu.

Nous devrons faire en sorte que le simulateur puisse facilement intégrer le code de contrôle des robots afin de le tester. De plus il faut permettre à l'utilisateur de gérer les parties du code à tester ainsi que de changer les conditions et paramètres de simulation afin de ne tester que certaines partie du code (par exemple en excluant la gestion des collisions). Nous inclurons une gestion des phases de jeu (Découverte et Production) dans ce but. De ce point de vue l'idéal serait de générer un launchfile et de permettre à l'utilisateur de gérer l'utilisation des nœuds un par un.

En sus, le simulateur gérant les robots de l'équipe adverse, il aura une fonctionnalité de sauvegarde des configurations que ce soit pour le code ou les stratégies afin de comparer l'évolution des performances.

Le simulateur a certaines contraintes afin d'être utilisable et utile. Il doit opérer une compression du temps c'est à dire réaliser la simulation d'un match en moins de temps qu'une durée normale de match. Il s'agit d'obtenir des données représentant la réalité en un cours laps de temps. La communication avec la RefereeBox est indispensable. Celle-ci étant fourni par les organisateurs de la compétition nous n'avons pas à la simuler mais nous devons communiquer avec elle pour rendre la simulation plus réaliste.

====Choix techniques : matériel et logiciel====

Nous n'avons pas besoin de matériel hormis d'ordinateurs afin de programmer.

Dû à la compétition et aux choix de développement de l'équipe de l'ARPL, nous allons programmer en C++ avec les bibliothèques QT ainsi que le middleware ROS, une surcouche de programmation destinée à la programmation de robots.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

*Simuler les différentes entités
** les Robotinos ;
** les machines ;
** l'environnement.

*Gérer l'interfaçage entre le simulateur et le code des Robots
** lire et lancer le méta-paquet ;
** identifier les différents parties du code ;
** proposer l'activation/désactivation de ces parties et créer un launchfile en conséquence ;
** créer un système de sauvegarde de tout code interfacé permettant sa réutilisation.

*Simuler un match
** communiquer avec la RefereeBox et recevoir les différents ordres de celle-ci ;
** gérer les machines et la communication avec la RefereeBox ;
** gérer l'équipe de l'utilisateur et son interaction avec le reste de la simulation ;
** gérer l'équipe adverse et son interaction avec le reste de la simulation.

*Paramétrage avancé de la simulation
** proposer différents modes de simulations ;
** activation/déssactivation des paramètres de la simulation ;
** gestion des phases.

*Interface utilisateur
** fournir des données utilisables et intéressantes sur la simulation ;
** créer une GUI ergonomique ;
** importer les données de la simulation sur la GUI pour une meilleure analyse de celle-ci.

====Calendrier====

Répartition du temps consacré au projet (120h/personne) :

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 2
|
|
|
|
|
|
|
|
|
|
|
|-
|Mise à niveau matérielle et intellectuelle
|
|13
|
|
|
|1
|
|
|
|
|
|
|-
|Conception théorique
|
|5
|7
|4
|2
|
|
|0,5
|
|13
|
|
|-
|Programmation de la simulation
|
|
|8
|15
|16
|4
|8
|6
|10
|6
|
|
|-
|Programmation de l'affichage avec rviz
|
|
|
|
|
|5
|8
|13
|6
|
|
|
|-
|Wiki
|
|
|0,5
|1,5
|1,5
|0,5
|2
|0,5
|3
|0,5
|
|
|-
|Réunions tuteurs
|2
|
|
|
|2
|2
|
|
|
|
|
|
|}

==Planning des tâches==

{| class="wikitable"
!Tâche !! Date prévue !! Avancement !! Commentaires
|-
| Affichage des formes avec Rviz
| 01/03/2017
| Terminé
| Cercle & Rectangle
|-
| Affichage d'un robot
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Affichage d'une machine
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Gestion du temps
| 08/03/2017
| Terminé
| Bornes de facteurs possibles à déterminer
|-
| Déplacement d'un robot
| 22/03/2017
| Terminé
| Vitesse et déplacement au point; Besoin d'interfaçage sur le code ARPL
|-
| Affichage de l'orientation de l'entité
| 13/03/2017
| Terminé
| Affichage d'une forme Flèche dont l'orientation change avec celle de l'entité. Grise. Orientation en degrés.
|-
| Lecture et affichage de la map
| 19/03/2017
| Terminé
| Affichage de la map, des murs et des zones interdites.
|-
| Communication RefBox
| 01/04/2017
| Débuté
| Prise d'information sur le système
|-
| Gestion Collision
| 01/04/2017
| Débuté
| Prise d'information sur le système
|}

==Avancement du Projet==

===Semaine 1===
Nous avons commencé par installer ROS et tout ce dont nous avons besoin pour travailler correctement. Nous avons également suivi des [http://wiki.ros.org/ROS/Tutorials tutoriels] pour apprendre à utiliser ROS.

Pour pouvoir travailler en binôme sans problèmes et pour que nos encadrants puissent suivre notre avancement et tester le logiciel, nous avons utilisé le logiciel de gestion de versions Git, sur lequel on publie notre code au fur et à mesure.

Nous n'avions pas encore de dépôt sur celui-ci, donc nous avons commencé par réfléchir à la structure de notre projet.
Nous commencerons par implémenter la phase d'exploration, ce qui comprend aussi le déplacement du robot, la détection de machines et de feux ainsi qu'une interface utilisateur basique.

En effet, le match oppose deux équipes ayant jusque trois robotinos qui s'affrontent lors de deux phases. La première est la phase d'exploration, durant laquelle les robots doivent trouver les machines de leur équipe en explorant le terrain. Ils doivent annoncer la position des machines et les signaux des feux de celles-ci : chaque machine, peu importe son type, possède un feu tricolore (rouge, jaune, vert) qui durant la phase d'exploration aura une combinaison de lumières allumées aléatoirement (au moins une doit l'être).

La création d'un simulateur passe par la réflexion sur les besoins en conception du simulateur (décris en partie ci-dessus). Nous avons donc passé un certain temps à schématiser la structure de notre simulateur et à en assimiler les besoins et l'ordre de création.

===Semaine 2===
Nous avons récupéré un dépôt Git (nommé ''logistic-sim'') sur lequel travailler auprès de nos encadrants, nous pouvons donc commencer la programmation cette semaine.

Ceci étant notre premier projet mêlant ROS et Git, nous avons tenté de créer la structure du projet mais avons vite rencontré quelques difficultés.
Nous avons ensuite compris qu'il était nécessaire de d'abord créer un environnement de travail ROS pour le projet, dans lequel on clône ensuite le dépôt Git localement.

Nous obtenons ainsi la structure de projet suivante :
* Workspace ROS
** build
** devel
** src
*** CMakeLists.txt
*** logistic-sim

Les dossiers build, devel, src et CMakeList.txt sont des fichiers et dossiers générés par ''Catkin'', un outil permettant de créer des paquets ROS facilement.

Nous avons ensuite décidé de séparer le code du projet en différents dossiers en fonction des tâches à effectuer :
* '''Entites''' pour simuler les différentes entités (Robotinos, machines, environnement...)
* '''Gestion_Code''' pour gérer l'interfaçage entre le simulateur et le code des robots
* '''Match''' pour simuler le déroulement d'un match
* '''GUI''' pour l'interface utilisateur avec le framework Qt

Dans chacun de ces dossiers, nous créerons des ''packages'' contenant les différentes fonctionnalités du projet.

Chaque ''package'' a la structure suivante :
* CMakeLists.txt
* include pour les fichiers .h
* package.xml
* README.md
* src pour les classes et nodes .cpp
* launch pour les launchfiles

Dans un premier temps, on commence par la gestion de la position du robot et la reconnaissance des feux.

===Semaine 3===

Nous avons avancé sur la programmation de la gestion de la position du robot et de la reconnaissance des feux.

Nous avons décrit nos classes par des schémas UML avec l'outil gratuit ''Modélio'' pour créer une documentation facilement accessible. Les commentaires des fonctions, classes et fichiers au format ''Doxygen'' nous permettront également de générer une documentation du projet sous format HTML notamment.

Nous suivons aussi la normalisation du code donnée par l'ARPL pour avoir les mêmes conventions de nommage partout.

Nous avons décidé de créer un nouveau package ''match'' qui contiendra les nœuds correspondants aux différentes phases de jeu, et avons donc par conséquent commencé par créer un nœud pour la phase d'exploration.

Nous avons également commencé à réfléchir à la façon dont les informations sont communiquées dans le match : il y a un arbitre, la ''Referee Box'' qui permet de faire communiquer le simulateur et les robots jouant le match. En effet, l'arbitre prend les décisions importantes (placement des machines au début du jeu etc.) et c'est à lui que les robots s'adressent. Nous devons donc aussi communiquer avec lui pour recevoir certaines informations (par exemple les informations de base de la phase d'exploration) et les retransmettre dans le simulateur aux nœuds qui en auront besoin.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v1.png|Schéma UML du package ''machine''
Fichier:Formes_package_Class_diagram_v1.png|Schéma UML du package ''formes''
</gallery>

===Semaine 4===

Cette semaine, nous avons créé plusieurs nouveaux packages et modifié ceux qui avaient déjà été créés.

Nous avons créé la classe Cercle dans le package ''formes'', nous pouvons donc maintenant utiliser deux formes différentes, le rectangle et le cercle.
La classe Entite a elle aussi été rajoutée. En effet, certains attributs des machines sont communs avec ceux des robots; cette classe nous permet de les rassembler et les classes Machine et Robot hériteront ainsi de Entite.

Un nouveau package ''management'' a également fait son apparition. Il contiendra les classes Equipe et Manager. Le Manager sera chargé de créer les équipes et permettra d'y accéder partout dans le code, mais aussi de procéder aux différentes initialisations lors du démarrage d'une nouvelle phase.

Au package ''management'' s'ajoute le nouveau package ''robot'' dont le rôle est de simuler les robotinos lors du match.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v2.png|Schéma UML du package ''machine''
Fichier:Robot_package_Class_diagram_v1.png|Schéma UML du package ''robot''
Fichier:Formes_package_Class_diagram_v2.png|Schéma UML du package ''formes''
Fichier:Management_package_Class_diagram_v1.png|Schéma UML du package ''management''
</gallery>

Nous avons également rendu visite à l'un de nos tuteurs de stage pendant la semaine dans le but d'obtenir un premier retour sur notre travail et l'avancement du projet.

Nous avons pu effectuer immédiatement quelques modifications nécessaires suite aux commentaires de notre tuteur. Nous avons dû, par exemple, clôner leur projet dans le même espace de travail que le notre pour pouvoir réutiliser certains paquets de messages déjà créés. Cela permettra une meilleure compatibilité. D'autres modifications concernaient entre autres les conventions de nommage de certaines classes et l'ajout d'un dossier supplémentaire dans le dossier include de chaque package portant le nom de celui-ci, pour ne pas avoir de conflits quant au nommage des fichiers.

Une réunion avec toute l'équipe des tuteurs a été prévue pour la semaine 5.

===Semaine 5===

La semaine a commencé par une réunion avec l'équipe de l'ARPL se chargeant d'encadrer notre projet, c'est-à-dire Vincent et Thomas. Nous avons discuté ensemble de l'avancement du simulateur et de l'ordre dans lequel effectuer les tâches. Ils nous également demandé de créer un planning de nos tâches avec la date prévue pour chacune; ils auront en effet besoin de modifier leur code à certains endroits pour pouvoir utiliser le simulateur (nous n'aurons pas besoin de tous les nœuds, certains comme la détection Laser nous étant inutiles) et souhaiteraient savoir lorsque nous seront prêt à tester de nouvelles fonctionnalités.

Nous nous sommes lancés dans l'affichage des formes avec l'outil ''rviz'', qui permet de visualiser en 3D les messages de type ''visualisation_msgs'' qui lui sont envoyés sur le topic associé. Ces messages sont disponibles en différents types. Pour afficher les formes nous utiliseront le format ''Marker'' qui permet d'afficher un objet en 3D (cubes, sphères, flèches, cylindres) ou en 2D en lui donnant un z de 0.

Nous avons donc commencé par faire les tutoriels sur l'utilisation de rviz puis par ajouter le code nécessaire à l'affichage des formes. Nous avons ainsi décidé d'ajouter la variable du message de type ''Marker'' dans la classe Forme; celle-ci sera accessible par toutes les classes filles de Forme, notamment Cercle et Rectangle. Nous avons également créé une méthode ''display'' qui sera chargée de mettre à jour la position de la forme et de publier le message. Les différents ''setters'' des classes filles modifieront également le message pour qu'il soit à jour lors de l'envoi.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_rectangle.png|Affichage de la forme ''Rectangle'' dans Rviz
Fichier:Rviz_screenshot_cercle.png|Affichage de la forme ''Cercle'' dans Rviz
</gallery>

===Semaine 6===

Cette semaine, nous continuons d'améliorer l'affichage en programmant cette fois-ci la classe ''Robot'' (qui possède une forme, étant une Entité) pour pouvoir visualiser le robot avec rviz. Nous avons donc ajouté une fonction ''display'' à ''Entite'', faisant elle-même appel à la fonction ''display'' de sa forme; ce qui permettra un affichage plus facile de l'objet.

Nous avons également ajouté une forme ''Texte'' pour afficher du texte informatif sur les formes (par exemple, une lettre et un id pour une entité, "R1" dans le cas du premier robot de chaque équipe). Ce texte est affiché en cyan ou en magenta, en fonction de la couleur de l'équipe. Les noms des ''markers'' de la forme et du texte eux aussi dépendent du type de l'entité.

Enfin, nous avons permis au entités de type Machine de gérer leur affichage. Pour cela, nous avons dû créer une classe fille de cette entité pour pouvoir tester son affichage. Le choix s'est porté sur les machines de type BS (Base Station).

En cours de route, nous avons été confrontés à un problème au niveau de l'affichage en 2D. Il semblait logique que la hauteur des objets (en z) soit égale à 0 pour un affichage 2D, mais il s'est avéré que la couleur de l'objet était alors imprévisible (plus souvent noir que de la bonne couleur). Il en fait fallu laisser une légère épaisseur (0.001 mètres dans notre cas) pour que la couleur s'affiche correctement.

Un de nos objectifs était aussi de gérer l'affichage de l'orientation de nos entités. En effet, cela semble essentiel pour les robots par exemple, représentés par des ronds et pouvant se déplacer. Nous avons ainsi créé un nouveau marker ''Fleche''; il était également possible de changer le type de marker en ''interactive marker'' ce qui aurait permis l'affichage de flèches de direction, mais celles-ci permettaient de modifier la position de l'objet et n'étaient disponibles qu'en multiple de 2 (déplacement sur un axe). Le choix s'est donc porté sur l'utilisation d'un marker classique dont on change l'orientation en même temps que celle de l'entité.
Nous avons rencontré quelques soucis quant à la gestion de l'orientation du marker, celle-ci étant un ''quaternion'' (x, y, z, w) alors que nous souhaitons donner l'angle en degrés (ou en radians éventuellement); la documentation n'est pas forcément facile à trouver pour ROS.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_robot.png|Affichage de l'entité ''Robot'' dans Rviz
Fichier:Rviz_screenshot_machine.png|Affichage de l'entité ''BaseStation'' dans Rviz
Fichier:Rviz_screenshot_fleche.png|Affichage de l'entité ''Robot'' avec une forme ''Fleche'' dans Rviz
</gallery>

Nous avons dû corriger nos constructeurs pour être le plus efficace possible et remplir au maximum les besoins des futurs fonctions.

La problématique rendant nécessaire une gestion du temps vient du besoin de l'ARPL de pouvoir contrôler la vitesse de simulation et donc de pouvoir jouer un match très rapidement afin d'observer le comportement de leur code.
Nous avons commencé et fini la gestion du temps. ROS intègre une interface de temps qui se cale sur la machine qui lance ROS.
Pour que plusieurs machines suivent le même temps il faut opérer une synchronisation des temps. Cependant lors de la simulation tous les robots auront leur référentiel temporel sur la même machine ce qui rend une synchronisation inutile.

Il existe un topic ''clock'' qui sert pour les simulations. En forçant nos nœuds à utiliser le temps de simulation, nous avons une échelle temporelle utilisable et synchronisée. Nous avons donc un nœud qui va publier sur ce topic le temps qui sera initialisé à 0 en début de match.

Un paramètre d'environnement ROS sert à régler le facteur d'accélération de la simulation par rapport au temps réel. Il est modifiable à tout instant et est initialisé en premier dans le launchfile.

===Semaine 7===

Nous nous sommes attaqués à l'affichage du terrain dans rviz.

Pour cela, nous pouvions nous inspirer de code écrit par l'ARPL permettant de charger une carte depuis un fichier ''.yaml''. Certains de leurs packages nous ont été utiles, mais d'autres se sont avérés inutilisables tels quels à cause d'erreurs tantôt de "référence indéfinie" à un fichier, tantôt de "redéfinition" du même fichier (la cause de ces erreurs reste pour le moment toujours un mystère).
Nous avons donc opté, pour pouvoir avancer rapidement sur le projet, d'utiliser tel quel ce qu'il était possible d'utiliser, et sinon de recopier les fonctions nécessaires dans notre package. Certaines fonctions nécessitaient d'ailleurs de toute façon des modifications, car dans notre simulateur nous gérons aussi l'affichage de la carte alors qu'eux ne faisaient que la charger.

Un fichier ''.yaml'' a la syntaxe suivante :
field:
name: robocup_simulator
size: [14, 9, 0.0]
gradient:
distance: 0.35
minValue: 0
walls:
bottom1:
start: [-6, 0, 0.0]
end: [-4, 0, 0.0]

Nous avons donc commencé par charger le fichier en mémoire en le passant en paramètre à un ''launchfile'' lançant le nœud chargé de lire et d'afficher la carte. Ensuite, en faisant appel à des ''param'' (paramètres) du nœud actuel et en leur donnant le nom du champs (''name'' par exemple), on peut récupérer les valeurs du fichiers voulues.

Nous avons ainsi créé une classe ''Carte'' pour gérer le chargement des données depuis le fichier et toutes les fonctions utilitaires associées, mais permettant aussi d'afficher la carte grâce à une fonction ''display'' de même fonctionnement que celles créées précédemment pour les entités.

Pour l'affichage sur rviz, nous nous sommes servis du type d'objet ''Map'' pour visualiser le sol du terrain (en blanc ci-dessous). Nous avons également créé un vecteur de Rectangles pour afficher les murs (en bleu foncé ci-dessous) et un vecteur de Rectangles pour les zones interdites au robot (en noir).

Nous aurions aimé mettre à jour la taille de la grille affichée en fonction de la taille de la carte, mais il s'avère que c'est impossible, la grille ne provenant pas d'un message publié.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_map.png|Affichage du terrain de jeu dans Rviz
</gallery>

===Semaine 8===

Nous avons complété la fonction de gestion de la vitesse. Il n'y a plus de nœud pour gérer les déplacements au profit d'un nœud gérant chaque robot.
Les robots envoient un vecteur "twist" pour donner leur commande vitesse, soit deux vecteurs vitesse 3D, l'un pour la vitesse linéaire et l'autre pour la vitesse angulaire.
Cependant ce vecteur vitesse est paramétré dans le repère du robot, c'est-à-dire avec le vecteur x dirigé dans la direction de l'orientation du robot.
Pour nos calculs nous nous servons du repère originel, que ce soit pour placer les entités ou les déplacer. Cela facilite les calculs dans la simulation.
Ainsi nous devons transposer les vecteurs vitesse reçus pour les appliquer à notre repère.

La simulation fonctionnant en 2D nous simplifions les données en utilisant un seul vecteur 3D (x et y pour le déplacement linéaire et z pour le changement d'orientation soit la vitesse angulaire autour de l'axe z).
La transposition n'est nécessaire que pour les déplacements linéaires, donc nous utilisons de la trigonométrie simple et nous ajoutons le déplacement ainsi obtenu à la position actuelle, ce qui donne :

v_x = v_x1*cos(orientation_radian) - v_y1*sin(orientation_radian)

v_y = v_x1*sin(orientation_radian) + v_y1*sin(orientation_radian)

x_new = v_x *delta_t + x

y_new = v_y *delta_t + y

orientation_new = (v_angulaire*delta_t + orientation) [360]

Nous avons également apporté des modifications aux flèches et textes; en effet, maintenant que le déplacement des robots est possible, nous pouvons effectuer des tests.
Il s'avère que nous ne modifions pas la position des flèches et textes, le robot s'éloignait alors d'eux lorsqu'il se déplaçait.
Nous avons donc ajouté les quelques modifications nécessaires pour que ces formes suivent l'entité en déplacement.

Nous avons aussi commencé à compléter le package ''machine'' pour lui ajouter les sous-classes de Machine représentant les différentes machines (MPS) du jeu (BaseStation, CapStation, RingStation, DeliveryStation).
La BaseStation permettra au robot de récupérer un objet de type base, la RingStation d'y empiler des anneaux de couleurs différentes en fonction des commandes reçues, la CapStation de déposer un chapeau au sommet de l'objet et enfin on l'apporte à la DeliveryStation.

Nous avons complété ci-dessous les schémas UML du projet dans son état actuel :

<gallery style="margin: 0 auto;">
Fichier:Formes_package_Class_diagram_v3.png|Schéma UML du package ''formes''
Fichier:Machine_package_Class_diagram_v3.png|Schéma UML du package ''machine''
Fichier:Management_package_Class_diagram_v2.png|Schéma UML du package ''management''
Fichier:Robot_package_Class_diagram_v2.png|Schéma UML du package ''robot''
</gallery>

===Semaine 9===

Nous avons du concevoir une fonction de récupération de distance entre deux entités.
Les robots étant les seules entités mobiles, nous ne calculons que la distance entre un robot et une autre entité.
La distance entre deux robots soit deux cercles est facile à déterminer. Nous récupérons les points des deux cercles étant sur la droite passant par les centres des dits cercles. Puis nous appliquons le calcul de distance.

Lorsqu'il s'agit de calculer la distance la plus courte avec un rectangle, c'est un peu plus compliqué et très rapidement le nombre de calculs devient rapidement très grands. Nous avons choisi une stratégie calculatoire réduisant le nombre de calculs avec les conseils de Mme Nathalie Delfosse.

Le problème est de trouver la distance la plus courte entre les deux formes ainsi que les points concernés.

[[Fichier:GD_1.png|500px|center|texte descriptif]]

Nous pouvons facilement tracer la Zone de collision, soit la zone qui permet de dire qu'il y a une collision si le centre du robot est dessus.

[[Fichier:GD_2.png|500px|center|texte descriptif]]

Ensuite on découpe l'espace en 8 zones en prolongeant les cotés du rectangle pour en faire des droites.
[[Fichier:GD_3.png|500px|center|texte descriptif]]

Lorsqu'un robot se situe en zone n°1 alors la distance la plus proche est celle qui sépare le cercle de l'angle le plus proche du rectangle. Donc (S2) est cette distance avec la résolution du système composé de la droite par le centre du cercle et l'angle, et le cercle. Nous obtenons alors le point du cercle le plus proche du rectangle.

(S2)

Dans la zone n°2, la distance la plus courte est une droite verticale, ce qui nous donne facilement le point du cercle et le point du rectangle.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

===Semaine 10===

== Fichiers Rendus ==

IMA4 2016/2017 P20

2017-04-05T14:14:03Z

Mbutaye : /* Feuille d'heures */

__TOC__
 
==Cahier des charges==

Ce cahier des charges a pour objectif de définir le projet, ce qui est attendu ainsi que les contraintes de conception qui lui sont associées.

===Présentation générale du projet===

Le projet consiste à concevoir et développer un environnement virtuel de test pour l'Association de Robotique de Polytech Lille (ARPL). Ce simulateur doit reproduire les conditions de participation à la Logistic League de manière à pouvoir obtenir rapidement des données et tester le code ainsi que les stratégies de jeu utilisés par les robots.

====Contexte====
Ce simulateur est un outil développé dans le cadre de la RoboCup et plus particulièrement de la Logistic League. La RoboCup est une compétition internationale de robotique dans laquelle on voit beaucoup d'entreprises et de robots connus tel que NAO. Cette compétition a pour but de mettre en avant les évolutions en matière de robotique ainsi que les qualités des organismes participants.

La Logistic League est une des différentes épreuves proposées. L'objectif est de repérer le terrain puis de produire des objets avec différents éléments fournis par des machines et à livrer dans des plages de temps données. Une RefereeBox ou boîte arbitre sert à la coordination ainsi qu'à l'arbitrage. C'est cette boite qui va informer le robots des différents objets à construire avec la date de livraison demandée. Elle va également donner leur rôles aux machines présentes sur le terrain. L'arbitre va enregistrer les horaires de dépôt des objets et la position de chacune des machines lors de la compétition.

Celle-ci se déroule sur une piste de la taille d'une salle moyenne. Chaque équipe peut utiliser jusqu'à trois robots Robotino 3 pour réaliser les tâches demandées. Sur la piste, à part les robots, se trouvent seulement des machines dites de production ou de livraison. Elles vont servir soit à se procurer un élément nécessaire à la production de l'objet final soit à livrer celui-ci lorsqu'il est terminé.

====Objectif du projet====

Ce projet va permettre de fournir à l'équipe de l'ARPL un simulateur léger et complet, leur permettant de simuler en un court laps de temps un match entier ou partiel et de tester leur code et leur stratégie. Cela leur permettra de développer plus rapidement et efficacement.

====Description du projet====

Le simulateur devra répondre à un certain nombre de critères. Tout d'abord il lui faudra pouvoir simuler toutes les entités présentes sur la piste lors d'un match. Nous parlons des robots et des machines mais également des capteurs et des conditions de jeu.

Nous devrons faire en sorte que le simulateur puisse facilement intégrer le code de contrôle des robots afin de le tester. De plus il faut permettre à l'utilisateur de gérer les parties du code à tester ainsi que de changer les conditions et paramètres de simulation afin de ne tester que certaines partie du code (par exemple en excluant la gestion des collisions). Nous inclurons une gestion des phases de jeu (Découverte et Production) dans ce but. De ce point de vue l'idéal serait de générer un launchfile et de permettre à l'utilisateur de gérer l'utilisation des nœuds un par un.

En sus, le simulateur gérant les robots de l'équipe adverse, il aura une fonctionnalité de sauvegarde des configurations que ce soit pour le code ou les stratégies afin de comparer l'évolution des performances.

Le simulateur a certaines contraintes afin d'être utilisable et utile. Il doit opérer une compression du temps c'est à dire réaliser la simulation d'un match en moins de temps qu'une durée normale de match. Il s'agit d'obtenir des données représentant la réalité en un cours laps de temps. La communication avec la RefereeBox est indispensable. Celle-ci étant fourni par les organisateurs de la compétition nous n'avons pas à la simuler mais nous devons communiquer avec elle pour rendre la simulation plus réaliste.

====Choix techniques : matériel et logiciel====

Nous n'avons pas besoin de matériel hormis d'ordinateurs afin de programmer.

Dû à la compétition et aux choix de développement de l'équipe de l'ARPL, nous allons programmer en C++ avec les bibliothèques QT ainsi que le middleware ROS, une surcouche de programmation destinée à la programmation de robots.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

*Simuler les différentes entités
** les Robotinos ;
** les machines ;
** l'environnement.

*Gérer l'interfaçage entre le simulateur et le code des Robots
** lire et lancer le méta-paquet ;
** identifier les différents parties du code ;
** proposer l'activation/désactivation de ces parties et créer un launchfile en conséquence ;
** créer un système de sauvegarde de tout code interfacé permettant sa réutilisation.

*Simuler un match
** communiquer avec la RefereeBox et recevoir les différents ordres de celle-ci ;
** gérer les machines et la communication avec la RefereeBox ;
** gérer l'équipe de l'utilisateur et son interaction avec le reste de la simulation ;
** gérer l'équipe adverse et son interaction avec le reste de la simulation.

*Paramétrage avancé de la simulation
** proposer différents modes de simulations ;
** activation/déssactivation des paramètres de la simulation ;
** gestion des phases.

*Interface utilisateur
** fournir des données utilisables et intéressantes sur la simulation ;
** créer une GUI ergonomique ;
** importer les données de la simulation sur la GUI pour une meilleure analyse de celle-ci.

====Calendrier====

Répartition du temps consacré au projet (120h/personne) :

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 2
|
|
|
|
|
|
|
|
|
|
|
|-
|Mise à niveau matérielle et intellectuelle
|
|13
|
|
|
|1
|
|
|
|
|
|
|-
|Conception théorique
|
|5
|7
|4
|2
|
|
|0,5
|
|13
|
|
|-
|Programmation de la simulation
|
|
|8
|15
|16
|4
|8
|6
|10
|6
|
|
|-
|Programmation de l'affichage avec rviz
|
|
|
|
|
|5
|8
|13
|6
|
|
|
|-
|Wiki
|
|
|0,5
|1,5
|1,5
|0,5
|2
|0,5
|3
|
|
|
|-
|Réunions tuteurs
|2
|
|
|
|2
|2
|
|
|
|
|
|
|}

==Planning des tâches==

{| class="wikitable"
!Tâche !! Date prévue !! Avancement !! Commentaires
|-
| Affichage des formes avec Rviz
| 01/03/2017
| Terminé
| Cercle & Rectangle
|-
| Affichage d'un robot
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Affichage d'une machine
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Gestion du temps
| 08/03/2017
| Terminé
| Bornes de facteurs possibles à déterminer
|-
| Déplacement d'un robot
| 22/03/2017
| Terminé
| Vitesse et déplacement au point; Besoin d'interfaçage sur le code ARPL
|-
| Affichage de l'orientation de l'entité
| 13/03/2017
| Terminé
| Affichage d'une forme Flèche dont l'orientation change avec celle de l'entité. Grise. Orientation en degrés.
|-
| Lecture et affichage de la map
| 19/03/2017
| Terminé
| Affichage de la map, des murs et des zones interdites.
|-
| Communication RefBox
| 01/04/2017
| Débuté
| Prise d'information sur le système
|-
| Gestion Collision
| 01/04/2017
| Débuté
| Prise d'information sur le système
|}

==Avancement du Projet==

===Semaine 1===
Nous avons commencé par installer ROS et tout ce dont nous avons besoin pour travailler correctement. Nous avons également suivi des [http://wiki.ros.org/ROS/Tutorials tutoriels] pour apprendre à utiliser ROS.

Pour pouvoir travailler en binôme sans problèmes et pour que nos encadrants puissent suivre notre avancement et tester le logiciel, nous avons utilisé le logiciel de gestion de versions Git, sur lequel on publie notre code au fur et à mesure.

Nous n'avions pas encore de dépôt sur celui-ci, donc nous avons commencé par réfléchir à la structure de notre projet.
Nous commencerons par implémenter la phase d'exploration, ce qui comprend aussi le déplacement du robot, la détection de machines et de feux ainsi qu'une interface utilisateur basique.

En effet, le match oppose deux équipes ayant jusque trois robotinos qui s'affrontent lors de deux phases. La première est la phase d'exploration, durant laquelle les robots doivent trouver les machines de leur équipe en explorant le terrain. Ils doivent annoncer la position des machines et les signaux des feux de celles-ci : chaque machine, peu importe son type, possède un feu tricolore (rouge, jaune, vert) qui durant la phase d'exploration aura une combinaison de lumières allumées aléatoirement (au moins une doit l'être).

La création d'un simulateur passe par la réflexion sur les besoins en conception du simulateur (décris en partie ci-dessus). Nous avons donc passé un certain temps à schématiser la structure de notre simulateur et à en assimiler les besoins et l'ordre de création.

===Semaine 2===
Nous avons récupéré un dépôt Git (nommé ''logistic-sim'') sur lequel travailler auprès de nos encadrants, nous pouvons donc commencer la programmation cette semaine.

Ceci étant notre premier projet mêlant ROS et Git, nous avons tenté de créer la structure du projet mais avons vite rencontré quelques difficultés.
Nous avons ensuite compris qu'il était nécessaire de d'abord créer un environnement de travail ROS pour le projet, dans lequel on clône ensuite le dépôt Git localement.

Nous obtenons ainsi la structure de projet suivante :
* Workspace ROS
** build
** devel
** src
*** CMakeLists.txt
*** logistic-sim

Les dossiers build, devel, src et CMakeList.txt sont des fichiers et dossiers générés par ''Catkin'', un outil permettant de créer des paquets ROS facilement.

Nous avons ensuite décidé de séparer le code du projet en différents dossiers en fonction des tâches à effectuer :
* '''Entites''' pour simuler les différentes entités (Robotinos, machines, environnement...)
* '''Gestion_Code''' pour gérer l'interfaçage entre le simulateur et le code des robots
* '''Match''' pour simuler le déroulement d'un match
* '''GUI''' pour l'interface utilisateur avec le framework Qt

Dans chacun de ces dossiers, nous créerons des ''packages'' contenant les différentes fonctionnalités du projet.

Chaque ''package'' a la structure suivante :
* CMakeLists.txt
* include pour les fichiers .h
* package.xml
* README.md
* src pour les classes et nodes .cpp
* launch pour les launchfiles

Dans un premier temps, on commence par la gestion de la position du robot et la reconnaissance des feux.

===Semaine 3===

Nous avons avancé sur la programmation de la gestion de la position du robot et de la reconnaissance des feux.

Nous avons décrit nos classes par des schémas UML avec l'outil gratuit ''Modélio'' pour créer une documentation facilement accessible. Les commentaires des fonctions, classes et fichiers au format ''Doxygen'' nous permettront également de générer une documentation du projet sous format HTML notamment.

Nous suivons aussi la normalisation du code donnée par l'ARPL pour avoir les mêmes conventions de nommage partout.

Nous avons décidé de créer un nouveau package ''match'' qui contiendra les nœuds correspondants aux différentes phases de jeu, et avons donc par conséquent commencé par créer un nœud pour la phase d'exploration.

Nous avons également commencé à réfléchir à la façon dont les informations sont communiquées dans le match : il y a un arbitre, la ''Referee Box'' qui permet de faire communiquer le simulateur et les robots jouant le match. En effet, l'arbitre prend les décisions importantes (placement des machines au début du jeu etc.) et c'est à lui que les robots s'adressent. Nous devons donc aussi communiquer avec lui pour recevoir certaines informations (par exemple les informations de base de la phase d'exploration) et les retransmettre dans le simulateur aux nœuds qui en auront besoin.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v1.png|Schéma UML du package ''machine''
Fichier:Formes_package_Class_diagram_v1.png|Schéma UML du package ''formes''
</gallery>

===Semaine 4===

Cette semaine, nous avons créé plusieurs nouveaux packages et modifié ceux qui avaient déjà été créés.

Nous avons créé la classe Cercle dans le package ''formes'', nous pouvons donc maintenant utiliser deux formes différentes, le rectangle et le cercle.
La classe Entite a elle aussi été rajoutée. En effet, certains attributs des machines sont communs avec ceux des robots; cette classe nous permet de les rassembler et les classes Machine et Robot hériteront ainsi de Entite.

Un nouveau package ''management'' a également fait son apparition. Il contiendra les classes Equipe et Manager. Le Manager sera chargé de créer les équipes et permettra d'y accéder partout dans le code, mais aussi de procéder aux différentes initialisations lors du démarrage d'une nouvelle phase.

Au package ''management'' s'ajoute le nouveau package ''robot'' dont le rôle est de simuler les robotinos lors du match.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v2.png|Schéma UML du package ''machine''
Fichier:Robot_package_Class_diagram_v1.png|Schéma UML du package ''robot''
Fichier:Formes_package_Class_diagram_v2.png|Schéma UML du package ''formes''
Fichier:Management_package_Class_diagram_v1.png|Schéma UML du package ''management''
</gallery>

Nous avons également rendu visite à l'un de nos tuteurs de stage pendant la semaine dans le but d'obtenir un premier retour sur notre travail et l'avancement du projet.

Nous avons pu effectuer immédiatement quelques modifications nécessaires suite aux commentaires de notre tuteur. Nous avons dû, par exemple, clôner leur projet dans le même espace de travail que le notre pour pouvoir réutiliser certains paquets de messages déjà créés. Cela permettra une meilleure compatibilité. D'autres modifications concernaient entre autres les conventions de nommage de certaines classes et l'ajout d'un dossier supplémentaire dans le dossier include de chaque package portant le nom de celui-ci, pour ne pas avoir de conflits quant au nommage des fichiers.

Une réunion avec toute l'équipe des tuteurs a été prévue pour la semaine 5.

===Semaine 5===

La semaine a commencé par une réunion avec l'équipe de l'ARPL se chargeant d'encadrer notre projet, c'est-à-dire Vincent et Thomas. Nous avons discuté ensemble de l'avancement du simulateur et de l'ordre dans lequel effectuer les tâches. Ils nous également demandé de créer un planning de nos tâches avec la date prévue pour chacune; ils auront en effet besoin de modifier leur code à certains endroits pour pouvoir utiliser le simulateur (nous n'aurons pas besoin de tous les nœuds, certains comme la détection Laser nous étant inutiles) et souhaiteraient savoir lorsque nous seront prêt à tester de nouvelles fonctionnalités.

Nous nous sommes lancés dans l'affichage des formes avec l'outil ''rviz'', qui permet de visualiser en 3D les messages de type ''visualisation_msgs'' qui lui sont envoyés sur le topic associé. Ces messages sont disponibles en différents types. Pour afficher les formes nous utiliseront le format ''Marker'' qui permet d'afficher un objet en 3D (cubes, sphères, flèches, cylindres) ou en 2D en lui donnant un z de 0.

Nous avons donc commencé par faire les tutoriels sur l'utilisation de rviz puis par ajouter le code nécessaire à l'affichage des formes. Nous avons ainsi décidé d'ajouter la variable du message de type ''Marker'' dans la classe Forme; celle-ci sera accessible par toutes les classes filles de Forme, notamment Cercle et Rectangle. Nous avons également créé une méthode ''display'' qui sera chargée de mettre à jour la position de la forme et de publier le message. Les différents ''setters'' des classes filles modifieront également le message pour qu'il soit à jour lors de l'envoi.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_rectangle.png|Affichage de la forme ''Rectangle'' dans Rviz
Fichier:Rviz_screenshot_cercle.png|Affichage de la forme ''Cercle'' dans Rviz
</gallery>

===Semaine 6===

Cette semaine, nous continuons d'améliorer l'affichage en programmant cette fois-ci la classe ''Robot'' (qui possède une forme, étant une Entité) pour pouvoir visualiser le robot avec rviz. Nous avons donc ajouté une fonction ''display'' à ''Entite'', faisant elle-même appel à la fonction ''display'' de sa forme; ce qui permettra un affichage plus facile de l'objet.

Nous avons également ajouté une forme ''Texte'' pour afficher du texte informatif sur les formes (par exemple, une lettre et un id pour une entité, "R1" dans le cas du premier robot de chaque équipe). Ce texte est affiché en cyan ou en magenta, en fonction de la couleur de l'équipe. Les noms des ''markers'' de la forme et du texte eux aussi dépendent du type de l'entité.

Enfin, nous avons permis au entités de type Machine de gérer leur affichage. Pour cela, nous avons dû créer une classe fille de cette entité pour pouvoir tester son affichage. Le choix s'est porté sur les machines de type BS (Base Station).

En cours de route, nous avons été confrontés à un problème au niveau de l'affichage en 2D. Il semblait logique que la hauteur des objets (en z) soit égale à 0 pour un affichage 2D, mais il s'est avéré que la couleur de l'objet était alors imprévisible (plus souvent noir que de la bonne couleur). Il en fait fallu laisser une légère épaisseur (0.001 mètres dans notre cas) pour que la couleur s'affiche correctement.

Un de nos objectifs était aussi de gérer l'affichage de l'orientation de nos entités. En effet, cela semble essentiel pour les robots par exemple, représentés par des ronds et pouvant se déplacer. Nous avons ainsi créé un nouveau marker ''Fleche''; il était également possible de changer le type de marker en ''interactive marker'' ce qui aurait permis l'affichage de flèches de direction, mais celles-ci permettaient de modifier la position de l'objet et n'étaient disponibles qu'en multiple de 2 (déplacement sur un axe). Le choix s'est donc porté sur l'utilisation d'un marker classique dont on change l'orientation en même temps que celle de l'entité.
Nous avons rencontré quelques soucis quant à la gestion de l'orientation du marker, celle-ci étant un ''quaternion'' (x, y, z, w) alors que nous souhaitons donner l'angle en degrés (ou en radians éventuellement); la documentation n'est pas forcément facile à trouver pour ROS.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_robot.png|Affichage de l'entité ''Robot'' dans Rviz
Fichier:Rviz_screenshot_machine.png|Affichage de l'entité ''BaseStation'' dans Rviz
Fichier:Rviz_screenshot_fleche.png|Affichage de l'entité ''Robot'' avec une forme ''Fleche'' dans Rviz
</gallery>

Nous avons dû corriger nos constructeurs pour être le plus efficace possible et remplir au maximum les besoins des futurs fonctions.

La problématique rendant nécessaire une gestion du temps vient du besoin de l'ARPL de pouvoir contrôler la vitesse de simulation et donc de pouvoir jouer un match très rapidement afin d'observer le comportement de leur code.
Nous avons commencé et fini la gestion du temps. ROS intègre une interface de temps qui se cale sur la machine qui lance ROS.
Pour que plusieurs machines suivent le même temps il faut opérer une synchronisation des temps. Cependant lors de la simulation tous les robots auront leur référentiel temporel sur la même machine ce qui rend une synchronisation inutile.

Il existe un topic ''clock'' qui sert pour les simulations. En forçant nos nœuds à utiliser le temps de simulation, nous avons une échelle temporelle utilisable et synchronisée. Nous avons donc un nœud qui va publier sur ce topic le temps qui sera initialisé à 0 en début de match.

Un paramètre d'environnement ROS sert à régler le facteur d'accélération de la simulation par rapport au temps réel. Il est modifiable à tout instant et est initialisé en premier dans le launchfile.

===Semaine 7===

Nous nous sommes attaqués à l'affichage du terrain dans rviz.

Pour cela, nous pouvions nous inspirer de code écrit par l'ARPL permettant de charger une carte depuis un fichier ''.yaml''. Certains de leurs packages nous ont été utiles, mais d'autres se sont avérés inutilisables tels quels à cause d'erreurs tantôt de "référence indéfinie" à un fichier, tantôt de "redéfinition" du même fichier (la cause de ces erreurs reste pour le moment toujours un mystère).
Nous avons donc opté, pour pouvoir avancer rapidement sur le projet, d'utiliser tel quel ce qu'il était possible d'utiliser, et sinon de recopier les fonctions nécessaires dans notre package. Certaines fonctions nécessitaient d'ailleurs de toute façon des modifications, car dans notre simulateur nous gérons aussi l'affichage de la carte alors qu'eux ne faisaient que la charger.

Un fichier ''.yaml'' a la syntaxe suivante :
field:
name: robocup_simulator
size: [14, 9, 0.0]
gradient:
distance: 0.35
minValue: 0
walls:
bottom1:
start: [-6, 0, 0.0]
end: [-4, 0, 0.0]

Nous avons donc commencé par charger le fichier en mémoire en le passant en paramètre à un ''launchfile'' lançant le nœud chargé de lire et d'afficher la carte. Ensuite, en faisant appel à des ''param'' (paramètres) du nœud actuel et en leur donnant le nom du champs (''name'' par exemple), on peut récupérer les valeurs du fichiers voulues.

Nous avons ainsi créé une classe ''Carte'' pour gérer le chargement des données depuis le fichier et toutes les fonctions utilitaires associées, mais permettant aussi d'afficher la carte grâce à une fonction ''display'' de même fonctionnement que celles créées précédemment pour les entités.

Pour l'affichage sur rviz, nous nous sommes servis du type d'objet ''Map'' pour visualiser le sol du terrain (en blanc ci-dessous). Nous avons également créé un vecteur de Rectangles pour afficher les murs (en bleu foncé ci-dessous) et un vecteur de Rectangles pour les zones interdites au robot (en noir).

Nous aurions aimé mettre à jour la taille de la grille affichée en fonction de la taille de la carte, mais il s'avère que c'est impossible, la grille ne provenant pas d'un message publié.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_map.png|Affichage du terrain de jeu dans Rviz
</gallery>

===Semaine 8===

Nous avons complété la fonction de gestion de la vitesse. Il n'y a plus de nœud pour gérer les déplacements au profit d'un nœud gérant chaque robot.
Les robots envoient un vecteur "twist" pour donner leur commande vitesse, soit deux vecteurs vitesse 3D, l'un pour la vitesse linéaire et l'autre pour la vitesse angulaire.
Cependant ce vecteur vitesse est paramétré dans le repère du robot, c'est-à-dire avec le vecteur x dirigé dans la direction de l'orientation du robot.
Pour nos calculs nous nous servons du repère originel, que ce soit pour placer les entités ou les déplacer. Cela facilite les calculs dans la simulation.
Ainsi nous devons transposer les vecteurs vitesse reçus pour les appliquer à notre repère.

La simulation fonctionnant en 2D nous simplifions les données en utilisant un seul vecteur 3D (x et y pour le déplacement linéaire et z pour le changement d'orientation soit la vitesse angulaire autour de l'axe z).
La transposition n'est nécessaire que pour les déplacements linéaires, donc nous utilisons de la trigonométrie simple et nous ajoutons le déplacement ainsi obtenu à la position actuelle, ce qui donne :

v_x = v_x1*cos(orientation_radian) - v_y1*sin(orientation_radian)

v_y = v_x1*sin(orientation_radian) + v_y1*sin(orientation_radian)

x_new = v_x *delta_t + x

y_new = v_y *delta_t + y

orientation_new = (v_angulaire*delta_t + orientation) [360]

Nous avons également apporté des modifications aux flèches et textes; en effet, maintenant que le déplacement des robots est possible, nous pouvons effectuer des tests.
Il s'avère que nous ne modifions pas la position des flèches et textes, le robot s'éloignait alors d'eux lorsqu'il se déplaçait.
Nous avons donc ajouté les quelques modifications nécessaires pour que ces formes suivent l'entité en déplacement.

Nous avons aussi commencé à compléter le package ''machine'' pour lui ajouter les sous-classes de Machine représentant les différentes machines (MPS) du jeu (BaseStation, CapStation, RingStation, DeliveryStation).
La BaseStation permettra au robot de récupérer un objet de type base, la RingStation d'y empiler des anneaux de couleurs différentes en fonction des commandes reçues, la CapStation de déposer un chapeau au sommet de l'objet et enfin on l'apporte à la DeliveryStation.

Nous avons complété ci-dessous les schémas UML du projet dans son état actuel :

<gallery style="margin: 0 auto;">
Fichier:Formes_package_Class_diagram_v3.png|Schéma UML du package ''formes''
Fichier:Machine_package_Class_diagram_v3.png|Schéma UML du package ''machine''
Fichier:Management_package_Class_diagram_v2.png|Schéma UML du package ''management''
Fichier:Robot_package_Class_diagram_v2.png|Schéma UML du package ''robot''
</gallery>

===Semaine 9===

Nous avons du concevoir une fonction de récupération de distance entre deux entités.
Les robots étant les seules entités mobiles, nous ne calculons que la distance entre un robot et une autre entité.
La distance entre deux robots soit deux cercles est facile à déterminer. Nous récupérons les points des deux cercles étant sur la droite passant par les centres des dits cercles. Puis nous appliquons le calcul de distance.

Lorsqu'il s'agit de calculer la distance la plus courte avec un rectangle, c'est un peu plus compliqué et très rapidement le nombre de calculs devient rapidement très grands. Nous avons choisi une stratégie calculatoire réduisant le nombre de calculs avec les conseils de Mme Nathalie Delfosse.

Le problème est de trouver la distance la plus courte entre les deux formes ainsi que les points concernés.

[[Fichier:GD_1.png|500px|center|texte descriptif]]

Nous pouvons facilement tracer la Zone de collision, soit la zone qui permet de dire qu'il y a une collision si le centre du robot est dessus.

[[Fichier:GD_2.png|500px|center|texte descriptif]]

Ensuite on découpe l'espace en 8 zones en prolongeant les cotés du rectangle pour en faire des droites.
[[Fichier:GD_3.png|500px|center|texte descriptif]]

Lorsqu'un robot se situe en zone n°1 alors la distance la plus proche est celle qui sépare le cercle de l'angle le plus proche du rectangle. Donc (S2) est cette distance avec la résolution du système composé de la droite par le centre du cercle et l'angle, et le cercle. Nous obtenons alors le point du cercle le plus proche du rectangle.

(S2)

Dans la zone n°2, la distance la plus courte est une droite verticale, ce qui nous donne facilement le point du cercle et le point du rectangle.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

===Semaine 10===

== Fichiers Rendus ==

IMA4 2016/2017 P20

2017-04-05T14:11:50Z

Mbutaye : /* Feuille d'heures */

__TOC__
 
==Cahier des charges==

Ce cahier des charges a pour objectif de définir le projet, ce qui est attendu ainsi que les contraintes de conception qui lui sont associées.

===Présentation générale du projet===

Le projet consiste à concevoir et développer un environnement virtuel de test pour l'Association de Robotique de Polytech Lille (ARPL). Ce simulateur doit reproduire les conditions de participation à la Logistic League de manière à pouvoir obtenir rapidement des données et tester le code ainsi que les stratégies de jeu utilisés par les robots.

====Contexte====
Ce simulateur est un outil développé dans le cadre de la RoboCup et plus particulièrement de la Logistic League. La RoboCup est une compétition internationale de robotique dans laquelle on voit beaucoup d'entreprises et de robots connus tel que NAO. Cette compétition a pour but de mettre en avant les évolutions en matière de robotique ainsi que les qualités des organismes participants.

La Logistic League est une des différentes épreuves proposées. L'objectif est de repérer le terrain puis de produire des objets avec différents éléments fournis par des machines et à livrer dans des plages de temps données. Une RefereeBox ou boîte arbitre sert à la coordination ainsi qu'à l'arbitrage. C'est cette boite qui va informer le robots des différents objets à construire avec la date de livraison demandée. Elle va également donner leur rôles aux machines présentes sur le terrain. L'arbitre va enregistrer les horaires de dépôt des objets et la position de chacune des machines lors de la compétition.

Celle-ci se déroule sur une piste de la taille d'une salle moyenne. Chaque équipe peut utiliser jusqu'à trois robots Robotino 3 pour réaliser les tâches demandées. Sur la piste, à part les robots, se trouvent seulement des machines dites de production ou de livraison. Elles vont servir soit à se procurer un élément nécessaire à la production de l'objet final soit à livrer celui-ci lorsqu'il est terminé.

====Objectif du projet====

Ce projet va permettre de fournir à l'équipe de l'ARPL un simulateur léger et complet, leur permettant de simuler en un court laps de temps un match entier ou partiel et de tester leur code et leur stratégie. Cela leur permettra de développer plus rapidement et efficacement.

====Description du projet====

Le simulateur devra répondre à un certain nombre de critères. Tout d'abord il lui faudra pouvoir simuler toutes les entités présentes sur la piste lors d'un match. Nous parlons des robots et des machines mais également des capteurs et des conditions de jeu.

Nous devrons faire en sorte que le simulateur puisse facilement intégrer le code de contrôle des robots afin de le tester. De plus il faut permettre à l'utilisateur de gérer les parties du code à tester ainsi que de changer les conditions et paramètres de simulation afin de ne tester que certaines partie du code (par exemple en excluant la gestion des collisions). Nous inclurons une gestion des phases de jeu (Découverte et Production) dans ce but. De ce point de vue l'idéal serait de générer un launchfile et de permettre à l'utilisateur de gérer l'utilisation des nœuds un par un.

En sus, le simulateur gérant les robots de l'équipe adverse, il aura une fonctionnalité de sauvegarde des configurations que ce soit pour le code ou les stratégies afin de comparer l'évolution des performances.

Le simulateur a certaines contraintes afin d'être utilisable et utile. Il doit opérer une compression du temps c'est à dire réaliser la simulation d'un match en moins de temps qu'une durée normale de match. Il s'agit d'obtenir des données représentant la réalité en un cours laps de temps. La communication avec la RefereeBox est indispensable. Celle-ci étant fourni par les organisateurs de la compétition nous n'avons pas à la simuler mais nous devons communiquer avec elle pour rendre la simulation plus réaliste.

====Choix techniques : matériel et logiciel====

Nous n'avons pas besoin de matériel hormis d'ordinateurs afin de programmer.

Dû à la compétition et aux choix de développement de l'équipe de l'ARPL, nous allons programmer en C++ avec les bibliothèques QT ainsi que le middleware ROS, une surcouche de programmation destinée à la programmation de robots.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

*Simuler les différentes entités
** les Robotinos ;
** les machines ;
** l'environnement.

*Gérer l'interfaçage entre le simulateur et le code des Robots
** lire et lancer le méta-paquet ;
** identifier les différents parties du code ;
** proposer l'activation/désactivation de ces parties et créer un launchfile en conséquence ;
** créer un système de sauvegarde de tout code interfacé permettant sa réutilisation.

*Simuler un match
** communiquer avec la RefereeBox et recevoir les différents ordres de celle-ci ;
** gérer les machines et la communication avec la RefereeBox ;
** gérer l'équipe de l'utilisateur et son interaction avec le reste de la simulation ;
** gérer l'équipe adverse et son interaction avec le reste de la simulation.

*Paramétrage avancé de la simulation
** proposer différents modes de simulations ;
** activation/déssactivation des paramètres de la simulation ;
** gestion des phases.

*Interface utilisateur
** fournir des données utilisables et intéressantes sur la simulation ;
** créer une GUI ergonomique ;
** importer les données de la simulation sur la GUI pour une meilleure analyse de celle-ci.

====Calendrier====

Répartition du temps consacré au projet (120h/personne) :

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 2
|
|
|
|
|
|
|
|
|
|
|
|-
|Mise à niveau matérielle et intellectuelle
|
|13
|
|
|
|1
|
|
|
|
|
|
|-
|Conception théorique
|
|5
|7
|4
|2
|
|
|0,5
|
|
|
|
|-
|Programmation de la simulation
|
|
|8
|15
|16
|4
|8
|6
|10
|
|
|
|-
|Programmation de l'affichage avec rviz
|
|
|
|
|
|5
|8
|13
|6
|
|
|
|-
|Wiki
|
|
|0,5
|1,5
|1,5
|0,5
|2
|0,5
|3
|
|
|
|-
|Réunions tuteurs
|2
|
|
|
|2
|2
|
|
|
|
|
|
|}

==Planning des tâches==

{| class="wikitable"
!Tâche !! Date prévue !! Avancement !! Commentaires
|-
| Affichage des formes avec Rviz
| 01/03/2017
| Terminé
| Cercle & Rectangle
|-
| Affichage d'un robot
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Affichage d'une machine
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Gestion du temps
| 08/03/2017
| Terminé
| Bornes de facteurs possibles à déterminer
|-
| Déplacement d'un robot
| 22/03/2017
| Terminé
| Vitesse et déplacement au point; Besoin d'interfaçage sur le code ARPL
|-
| Affichage de l'orientation de l'entité
| 13/03/2017
| Terminé
| Affichage d'une forme Flèche dont l'orientation change avec celle de l'entité. Grise. Orientation en degrés.
|-
| Lecture et affichage de la map
| 19/03/2017
| Terminé
| Affichage de la map, des murs et des zones interdites.
|-
| Communication RefBox
| 01/04/2017
| Débuté
| Prise d'information sur le système
|-
| Gestion Collision
| 01/04/2017
| Débuté
| Prise d'information sur le système
|}

==Avancement du Projet==

===Semaine 1===
Nous avons commencé par installer ROS et tout ce dont nous avons besoin pour travailler correctement. Nous avons également suivi des [http://wiki.ros.org/ROS/Tutorials tutoriels] pour apprendre à utiliser ROS.

Pour pouvoir travailler en binôme sans problèmes et pour que nos encadrants puissent suivre notre avancement et tester le logiciel, nous avons utilisé le logiciel de gestion de versions Git, sur lequel on publie notre code au fur et à mesure.

Nous n'avions pas encore de dépôt sur celui-ci, donc nous avons commencé par réfléchir à la structure de notre projet.
Nous commencerons par implémenter la phase d'exploration, ce qui comprend aussi le déplacement du robot, la détection de machines et de feux ainsi qu'une interface utilisateur basique.

En effet, le match oppose deux équipes ayant jusque trois robotinos qui s'affrontent lors de deux phases. La première est la phase d'exploration, durant laquelle les robots doivent trouver les machines de leur équipe en explorant le terrain. Ils doivent annoncer la position des machines et les signaux des feux de celles-ci : chaque machine, peu importe son type, possède un feu tricolore (rouge, jaune, vert) qui durant la phase d'exploration aura une combinaison de lumières allumées aléatoirement (au moins une doit l'être).

La création d'un simulateur passe par la réflexion sur les besoins en conception du simulateur (décris en partie ci-dessus). Nous avons donc passé un certain temps à schématiser la structure de notre simulateur et à en assimiler les besoins et l'ordre de création.

===Semaine 2===
Nous avons récupéré un dépôt Git (nommé ''logistic-sim'') sur lequel travailler auprès de nos encadrants, nous pouvons donc commencer la programmation cette semaine.

Ceci étant notre premier projet mêlant ROS et Git, nous avons tenté de créer la structure du projet mais avons vite rencontré quelques difficultés.
Nous avons ensuite compris qu'il était nécessaire de d'abord créer un environnement de travail ROS pour le projet, dans lequel on clône ensuite le dépôt Git localement.

Nous obtenons ainsi la structure de projet suivante :
* Workspace ROS
** build
** devel
** src
*** CMakeLists.txt
*** logistic-sim

Les dossiers build, devel, src et CMakeList.txt sont des fichiers et dossiers générés par ''Catkin'', un outil permettant de créer des paquets ROS facilement.

Nous avons ensuite décidé de séparer le code du projet en différents dossiers en fonction des tâches à effectuer :
* '''Entites''' pour simuler les différentes entités (Robotinos, machines, environnement...)
* '''Gestion_Code''' pour gérer l'interfaçage entre le simulateur et le code des robots
* '''Match''' pour simuler le déroulement d'un match
* '''GUI''' pour l'interface utilisateur avec le framework Qt

Dans chacun de ces dossiers, nous créerons des ''packages'' contenant les différentes fonctionnalités du projet.

Chaque ''package'' a la structure suivante :
* CMakeLists.txt
* include pour les fichiers .h
* package.xml
* README.md
* src pour les classes et nodes .cpp
* launch pour les launchfiles

Dans un premier temps, on commence par la gestion de la position du robot et la reconnaissance des feux.

===Semaine 3===

Nous avons avancé sur la programmation de la gestion de la position du robot et de la reconnaissance des feux.

Nous avons décrit nos classes par des schémas UML avec l'outil gratuit ''Modélio'' pour créer une documentation facilement accessible. Les commentaires des fonctions, classes et fichiers au format ''Doxygen'' nous permettront également de générer une documentation du projet sous format HTML notamment.

Nous suivons aussi la normalisation du code donnée par l'ARPL pour avoir les mêmes conventions de nommage partout.

Nous avons décidé de créer un nouveau package ''match'' qui contiendra les nœuds correspondants aux différentes phases de jeu, et avons donc par conséquent commencé par créer un nœud pour la phase d'exploration.

Nous avons également commencé à réfléchir à la façon dont les informations sont communiquées dans le match : il y a un arbitre, la ''Referee Box'' qui permet de faire communiquer le simulateur et les robots jouant le match. En effet, l'arbitre prend les décisions importantes (placement des machines au début du jeu etc.) et c'est à lui que les robots s'adressent. Nous devons donc aussi communiquer avec lui pour recevoir certaines informations (par exemple les informations de base de la phase d'exploration) et les retransmettre dans le simulateur aux nœuds qui en auront besoin.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v1.png|Schéma UML du package ''machine''
Fichier:Formes_package_Class_diagram_v1.png|Schéma UML du package ''formes''
</gallery>

===Semaine 4===

Cette semaine, nous avons créé plusieurs nouveaux packages et modifié ceux qui avaient déjà été créés.

Nous avons créé la classe Cercle dans le package ''formes'', nous pouvons donc maintenant utiliser deux formes différentes, le rectangle et le cercle.
La classe Entite a elle aussi été rajoutée. En effet, certains attributs des machines sont communs avec ceux des robots; cette classe nous permet de les rassembler et les classes Machine et Robot hériteront ainsi de Entite.

Un nouveau package ''management'' a également fait son apparition. Il contiendra les classes Equipe et Manager. Le Manager sera chargé de créer les équipes et permettra d'y accéder partout dans le code, mais aussi de procéder aux différentes initialisations lors du démarrage d'une nouvelle phase.

Au package ''management'' s'ajoute le nouveau package ''robot'' dont le rôle est de simuler les robotinos lors du match.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v2.png|Schéma UML du package ''machine''
Fichier:Robot_package_Class_diagram_v1.png|Schéma UML du package ''robot''
Fichier:Formes_package_Class_diagram_v2.png|Schéma UML du package ''formes''
Fichier:Management_package_Class_diagram_v1.png|Schéma UML du package ''management''
</gallery>

Nous avons également rendu visite à l'un de nos tuteurs de stage pendant la semaine dans le but d'obtenir un premier retour sur notre travail et l'avancement du projet.

Nous avons pu effectuer immédiatement quelques modifications nécessaires suite aux commentaires de notre tuteur. Nous avons dû, par exemple, clôner leur projet dans le même espace de travail que le notre pour pouvoir réutiliser certains paquets de messages déjà créés. Cela permettra une meilleure compatibilité. D'autres modifications concernaient entre autres les conventions de nommage de certaines classes et l'ajout d'un dossier supplémentaire dans le dossier include de chaque package portant le nom de celui-ci, pour ne pas avoir de conflits quant au nommage des fichiers.

Une réunion avec toute l'équipe des tuteurs a été prévue pour la semaine 5.

===Semaine 5===

La semaine a commencé par une réunion avec l'équipe de l'ARPL se chargeant d'encadrer notre projet, c'est-à-dire Vincent et Thomas. Nous avons discuté ensemble de l'avancement du simulateur et de l'ordre dans lequel effectuer les tâches. Ils nous également demandé de créer un planning de nos tâches avec la date prévue pour chacune; ils auront en effet besoin de modifier leur code à certains endroits pour pouvoir utiliser le simulateur (nous n'aurons pas besoin de tous les nœuds, certains comme la détection Laser nous étant inutiles) et souhaiteraient savoir lorsque nous seront prêt à tester de nouvelles fonctionnalités.

Nous nous sommes lancés dans l'affichage des formes avec l'outil ''rviz'', qui permet de visualiser en 3D les messages de type ''visualisation_msgs'' qui lui sont envoyés sur le topic associé. Ces messages sont disponibles en différents types. Pour afficher les formes nous utiliseront le format ''Marker'' qui permet d'afficher un objet en 3D (cubes, sphères, flèches, cylindres) ou en 2D en lui donnant un z de 0.

Nous avons donc commencé par faire les tutoriels sur l'utilisation de rviz puis par ajouter le code nécessaire à l'affichage des formes. Nous avons ainsi décidé d'ajouter la variable du message de type ''Marker'' dans la classe Forme; celle-ci sera accessible par toutes les classes filles de Forme, notamment Cercle et Rectangle. Nous avons également créé une méthode ''display'' qui sera chargée de mettre à jour la position de la forme et de publier le message. Les différents ''setters'' des classes filles modifieront également le message pour qu'il soit à jour lors de l'envoi.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_rectangle.png|Affichage de la forme ''Rectangle'' dans Rviz
Fichier:Rviz_screenshot_cercle.png|Affichage de la forme ''Cercle'' dans Rviz
</gallery>

===Semaine 6===

Cette semaine, nous continuons d'améliorer l'affichage en programmant cette fois-ci la classe ''Robot'' (qui possède une forme, étant une Entité) pour pouvoir visualiser le robot avec rviz. Nous avons donc ajouté une fonction ''display'' à ''Entite'', faisant elle-même appel à la fonction ''display'' de sa forme; ce qui permettra un affichage plus facile de l'objet.

Nous avons également ajouté une forme ''Texte'' pour afficher du texte informatif sur les formes (par exemple, une lettre et un id pour une entité, "R1" dans le cas du premier robot de chaque équipe). Ce texte est affiché en cyan ou en magenta, en fonction de la couleur de l'équipe. Les noms des ''markers'' de la forme et du texte eux aussi dépendent du type de l'entité.

Enfin, nous avons permis au entités de type Machine de gérer leur affichage. Pour cela, nous avons dû créer une classe fille de cette entité pour pouvoir tester son affichage. Le choix s'est porté sur les machines de type BS (Base Station).

En cours de route, nous avons été confrontés à un problème au niveau de l'affichage en 2D. Il semblait logique que la hauteur des objets (en z) soit égale à 0 pour un affichage 2D, mais il s'est avéré que la couleur de l'objet était alors imprévisible (plus souvent noir que de la bonne couleur). Il en fait fallu laisser une légère épaisseur (0.001 mètres dans notre cas) pour que la couleur s'affiche correctement.

Un de nos objectifs était aussi de gérer l'affichage de l'orientation de nos entités. En effet, cela semble essentiel pour les robots par exemple, représentés par des ronds et pouvant se déplacer. Nous avons ainsi créé un nouveau marker ''Fleche''; il était également possible de changer le type de marker en ''interactive marker'' ce qui aurait permis l'affichage de flèches de direction, mais celles-ci permettaient de modifier la position de l'objet et n'étaient disponibles qu'en multiple de 2 (déplacement sur un axe). Le choix s'est donc porté sur l'utilisation d'un marker classique dont on change l'orientation en même temps que celle de l'entité.
Nous avons rencontré quelques soucis quant à la gestion de l'orientation du marker, celle-ci étant un ''quaternion'' (x, y, z, w) alors que nous souhaitons donner l'angle en degrés (ou en radians éventuellement); la documentation n'est pas forcément facile à trouver pour ROS.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_robot.png|Affichage de l'entité ''Robot'' dans Rviz
Fichier:Rviz_screenshot_machine.png|Affichage de l'entité ''BaseStation'' dans Rviz
Fichier:Rviz_screenshot_fleche.png|Affichage de l'entité ''Robot'' avec une forme ''Fleche'' dans Rviz
</gallery>

Nous avons dû corriger nos constructeurs pour être le plus efficace possible et remplir au maximum les besoins des futurs fonctions.

La problématique rendant nécessaire une gestion du temps vient du besoin de l'ARPL de pouvoir contrôler la vitesse de simulation et donc de pouvoir jouer un match très rapidement afin d'observer le comportement de leur code.
Nous avons commencé et fini la gestion du temps. ROS intègre une interface de temps qui se cale sur la machine qui lance ROS.
Pour que plusieurs machines suivent le même temps il faut opérer une synchronisation des temps. Cependant lors de la simulation tous les robots auront leur référentiel temporel sur la même machine ce qui rend une synchronisation inutile.

Il existe un topic ''clock'' qui sert pour les simulations. En forçant nos nœuds à utiliser le temps de simulation, nous avons une échelle temporelle utilisable et synchronisée. Nous avons donc un nœud qui va publier sur ce topic le temps qui sera initialisé à 0 en début de match.

Un paramètre d'environnement ROS sert à régler le facteur d'accélération de la simulation par rapport au temps réel. Il est modifiable à tout instant et est initialisé en premier dans le launchfile.

===Semaine 7===

Nous nous sommes attaqués à l'affichage du terrain dans rviz.

Pour cela, nous pouvions nous inspirer de code écrit par l'ARPL permettant de charger une carte depuis un fichier ''.yaml''. Certains de leurs packages nous ont été utiles, mais d'autres se sont avérés inutilisables tels quels à cause d'erreurs tantôt de "référence indéfinie" à un fichier, tantôt de "redéfinition" du même fichier (la cause de ces erreurs reste pour le moment toujours un mystère).
Nous avons donc opté, pour pouvoir avancer rapidement sur le projet, d'utiliser tel quel ce qu'il était possible d'utiliser, et sinon de recopier les fonctions nécessaires dans notre package. Certaines fonctions nécessitaient d'ailleurs de toute façon des modifications, car dans notre simulateur nous gérons aussi l'affichage de la carte alors qu'eux ne faisaient que la charger.

Un fichier ''.yaml'' a la syntaxe suivante :
field:
name: robocup_simulator
size: [14, 9, 0.0]
gradient:
distance: 0.35
minValue: 0
walls:
bottom1:
start: [-6, 0, 0.0]
end: [-4, 0, 0.0]

Nous avons donc commencé par charger le fichier en mémoire en le passant en paramètre à un ''launchfile'' lançant le nœud chargé de lire et d'afficher la carte. Ensuite, en faisant appel à des ''param'' (paramètres) du nœud actuel et en leur donnant le nom du champs (''name'' par exemple), on peut récupérer les valeurs du fichiers voulues.

Nous avons ainsi créé une classe ''Carte'' pour gérer le chargement des données depuis le fichier et toutes les fonctions utilitaires associées, mais permettant aussi d'afficher la carte grâce à une fonction ''display'' de même fonctionnement que celles créées précédemment pour les entités.

Pour l'affichage sur rviz, nous nous sommes servis du type d'objet ''Map'' pour visualiser le sol du terrain (en blanc ci-dessous). Nous avons également créé un vecteur de Rectangles pour afficher les murs (en bleu foncé ci-dessous) et un vecteur de Rectangles pour les zones interdites au robot (en noir).

Nous aurions aimé mettre à jour la taille de la grille affichée en fonction de la taille de la carte, mais il s'avère que c'est impossible, la grille ne provenant pas d'un message publié.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_map.png|Affichage du terrain de jeu dans Rviz
</gallery>

===Semaine 8===

Nous avons complété la fonction de gestion de la vitesse. Il n'y a plus de nœud pour gérer les déplacements au profit d'un nœud gérant chaque robot.
Les robots envoient un vecteur "twist" pour donner leur commande vitesse, soit deux vecteurs vitesse 3D, l'un pour la vitesse linéaire et l'autre pour la vitesse angulaire.
Cependant ce vecteur vitesse est paramétré dans le repère du robot, c'est-à-dire avec le vecteur x dirigé dans la direction de l'orientation du robot.
Pour nos calculs nous nous servons du repère originel, que ce soit pour placer les entités ou les déplacer. Cela facilite les calculs dans la simulation.
Ainsi nous devons transposer les vecteurs vitesse reçus pour les appliquer à notre repère.

La simulation fonctionnant en 2D nous simplifions les données en utilisant un seul vecteur 3D (x et y pour le déplacement linéaire et z pour le changement d'orientation soit la vitesse angulaire autour de l'axe z).
La transposition n'est nécessaire que pour les déplacements linéaires, donc nous utilisons de la trigonométrie simple et nous ajoutons le déplacement ainsi obtenu à la position actuelle, ce qui donne :

v_x = v_x1*cos(orientation_radian) - v_y1*sin(orientation_radian)

v_y = v_x1*sin(orientation_radian) + v_y1*sin(orientation_radian)

x_new = v_x *delta_t + x

y_new = v_y *delta_t + y

orientation_new = (v_angulaire*delta_t + orientation) [360]

Nous avons également apporté des modifications aux flèches et textes; en effet, maintenant que le déplacement des robots est possible, nous pouvons effectuer des tests.
Il s'avère que nous ne modifions pas la position des flèches et textes, le robot s'éloignait alors d'eux lorsqu'il se déplaçait.
Nous avons donc ajouté les quelques modifications nécessaires pour que ces formes suivent l'entité en déplacement.

Nous avons aussi commencé à compléter le package ''machine'' pour lui ajouter les sous-classes de Machine représentant les différentes machines (MPS) du jeu (BaseStation, CapStation, RingStation, DeliveryStation).
La BaseStation permettra au robot de récupérer un objet de type base, la RingStation d'y empiler des anneaux de couleurs différentes en fonction des commandes reçues, la CapStation de déposer un chapeau au sommet de l'objet et enfin on l'apporte à la DeliveryStation.

Nous avons complété ci-dessous les schémas UML du projet dans son état actuel :

<gallery style="margin: 0 auto;">
Fichier:Formes_package_Class_diagram_v3.png|Schéma UML du package ''formes''
Fichier:Machine_package_Class_diagram_v3.png|Schéma UML du package ''machine''
Fichier:Management_package_Class_diagram_v2.png|Schéma UML du package ''management''
Fichier:Robot_package_Class_diagram_v2.png|Schéma UML du package ''robot''
</gallery>

===Semaine 9===

Nous avons du concevoir une fonction de récupération de distance entre deux entités.
Les robots étant les seules entités mobiles, nous ne calculons que la distance entre un robot et une autre entité.
La distance entre deux robots soit deux cercles est facile à déterminer. Nous récupérons les points des deux cercles étant sur la droite passant par les centres des dits cercles. Puis nous appliquons le calcul de distance.

Lorsqu'il s'agit de calculer la distance la plus courte avec un rectangle, c'est un peu plus compliqué et très rapidement le nombre de calculs devient rapidement très grands. Nous avons choisi une stratégie calculatoire réduisant le nombre de calculs avec les conseils de Mme Nathalie Delfosse.

Le problème est de trouver la distance la plus courte entre les deux formes ainsi que les points concernés.

[[Fichier:GD_1.png|500px|center|texte descriptif]]

Nous pouvons facilement tracer la Zone de collision, soit la zone qui permet de dire qu'il y a une collision si le centre du robot est dessus.

[[Fichier:GD_2.png|500px|center|texte descriptif]]

Ensuite on découpe l'espace en 8 zones en prolongeant les cotés du rectangle pour en faire des droites.
[[Fichier:GD_3.png|500px|center|texte descriptif]]

Lorsqu'un robot se situe en zone n°1 alors la distance la plus proche est celle qui sépare le cercle de l'angle le plus proche du rectangle. Donc (S2) est cette distance avec la résolution du système composé de la droite par le centre du cercle et l'angle, et le cercle. Nous obtenons alors le point du cercle le plus proche du rectangle.

(S2)

Dans la zone n°2, la distance la plus courte est une droite verticale, ce qui nous donne facilement le point du cercle et le point du rectangle.

(S1)
xpc = xpr= xc
ypc = yc +/- r
ypr = yr +/- (l/2)

===Semaine 10===

== Fichiers Rendus ==

Discussion:Projets IMA4 SC & SA 2016/2017

2017-04-05T14:05:40Z

Mbutaye : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Mini-cahier des charges || Mi-parcours || Fin de parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Cahier des charges conforme à la discussion avec l'encadrant. Présentation propre avec un effort d'illustration. Pas de liste des tâches ou de calendrier prévisionnel. Quelques coquilles corrigées.
| Abandon constaté
| 
| 
| 
| Pas de vidéo
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Cahier des charges succinct. Attention à la rédaction en français. Un effort d'illustration avec un schéma global. Une liste des tâches, sans chiffrage pour l'instant.
| Mauvaise utilisation de la feuille d'heures.De gros problèmes de rédaction en français bien compréhensibles.Un Wiki très bien tenu et très bien illustré, une avancée du travail parfaitement expliquée, continuez ainsi !
| 
| 
| 
| Vidéo plutôt conseillée
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Cahier des charges assez précis. Pas trop de coquilles. Une liste des tâches un peu succincte. Réfléchissez bien à la structure du programme pour la mise à jour simplifiée des fiches sur l'application.
| Feuille d'heures non utilisée, Wiki non mis à jour.Pour les 4 premières semaine, des paragraphes correctement rédigés et bien illustré, il était possible de se faire une idée de l'avancée du projet.
| 
| 
| 
| Vidéo conseillée
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Cahier des charges précis. Forme très correcte. Une liste des tâches réfléchie. Il y a même un calendrier prévisionnel.
| Aucune utilisation de la feuille d'heures.Un excellent Wiki, très complet, très bien illustré, le travail est parfaitement décrit !
| 
| 
| 
| Vidéo conseillée
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Cahier des charges très précis. De même pour la liste des tâches. L'utilisation de bioloïds ne semble pas justifiée. Pourquoi ne parlez-vous de capteurs que dans le cadre d'un seul des deux appareils ?
| Feuille d'heures très bien exploitée.Wiki très bien rédigé mais absolument pas illustré, un peu court peut être.
| 
| 
| 
| Vidéo conseillée
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Pas mal de coquilles corrigées. Une certaine imprécision (confusion Arduino Mega et ATMEGA, flou dans la liste des tâches). Cela dit un cahier des charges et une liste des tâches sont présentés. Pensez aux problèmes de calibration du système et à la transmission des données vers un smartphone par exemple.
| Mauvaise utilisation de la feuille d'heures.Quelques coquilles, le Wiki est un peu vide, pas totalement à jour, dommage que le cahier des charges joint ne soit pas intégré directement au Wiki.
| 
| 
| 
| Vidéo plutôt conseillée
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Synthèse correcte de l'entretien avec l'encadrant. Le cahier des charges est correct mais moins précis que le sujet. Le découpage en tâche est un peu rapide : l'analyse des fichiers MIDI devrait être sous-découpée. Presque pas de coquilles.
| Très bonne utilisation de la feuille d'heures.Wiki très synthétique dans un français très correct, à jour, travail sur l'imprimante bien décrit, pas beaucoup d'information sur l'analyse du fichier MIDI.
| 
| 
| 
| Vidéo conseillée
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Très bonne prise en main du sujet. Cahier des charges très précis. Liste des tâches bien détaillée. Orthographe irréprochable.
| Feuille d'heures bien exploitée, Wiki très bien rédigé, illustré, l'avancé du travail est bien présenté.
| 
| 
| 
| Vidéo conseillée
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Une grande partie du cahier des charges est une copie du sujet. Définissez ce qu'est une Referee Box. D'un autre coté, le cahier des charges est précis. La liste des tâches est correcte. Cependant elle semble omettre la partie mécanique de la MPS ? Pas de coquilles.
| Pas d'utilisation de la feuille d'heures.Wiki bien rédigé et très bien illustré, le travail effectué est présenté. Il serait bien d'avoir une carte rapidement.
| 
| 
| 
| Vidéo plutôt déconseillée
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Des imprécisions dans la transcription de la réunion avec l'encadrant. Voire des contre-sens. Le cahier des charges est assez complet. Pas de liste des tâches. Vous avez vraiment passé 3h sur la rédaction du cahier des charges ? (edit d'Alex : certainement pas)Une liste des tâches ajoutée.
| Pas d'utilisation de la feuille d'heures.Le Wiki est principalement constitué des schématiques et des PCB des différentes cartes. Après tout c'est un point important de votre travail mais le soin apporté à ces productions, s'il s'améliore était initialement assez faible. La rédaction est presque absente ou d'un niveau faible. Vous devriez déjà avoir des cartes en production.
| 
| 
| 
| Vidéo déconseillée
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Le texte a été modifié pour être compréhensible mais le problème n'est pas là. Vous n'avez pas du tout transcrit les demandes de l'encadrant mais donné le sujet du projet de l'an passé. Cette année vous devez améliorer l'aspect esthétique des robots, construire le quatrième robot et améliorer la détection infra-rouge en utilisant le protocole utilisé par les télécommandes infra-rouges classiques. Vous n'avez pas, non plus, donné une liste précise des tâches à réaliser.Cahier des charges révisé avec l'encadrant. La listes des tâches à réaliser est à préciser.
| Pas d'utilisation de la feuille d'heures.Wiki assez vide, le seul élément probant est la présentation de la nouvelle version de la carte des robots suiveurs. Des coquilles, ce que l'on peut difficilement vous reprocher. Il faudrait maintenant avoir un code pour le protocole RC5, utilisez deux Arduinos pour avoir un prototype de démonstration.
| 
| 
| 
| Vidéo déconseillée
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| La restitution de la discussion avec l'encadrant est très correcte et le cahier des charge est précisément décrit. Par contre la liste des tâches à effectuer n'est pas dressée en commençant par l'étude des conditions à respecter pour lancer un tel ballon.
| Pratiquement pas d'utilisation de la feuille d'heures.Wiki un peu rapide, illustré, quelques coquilles. Peu de résultats à ce jour, vous devriez avoir votre carte et avoir conduit un test de communication avec les capteurs et les modules LoRa.
| 
| 
| 
| Vidéo déconseillée
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Assimilation très correcte des demandes faites par les encadrants. Un cahier des charges précis. De même pour la liste des tâches. Un effort de présentation sans trop de coquilles. Cependant quelques erreurs relevées par M. Dhaussy, merci de corriger le CdC au vu des remarques transmises.
| Pas d'utilisation de la feuille d'heures.Wiki à l'abandon, impossible de savoir où vous en êtes dans le travail. Réagissez immédiatement !
| 
| 
| 
| Vidéo déconseillée
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| Le cahier des charges est une recopie du sujet, avec des passages soulignés, certes. Une liste des tâches très précise mais uniquement orientée développement Web. Il manque toute la partie étude et utilisation des éco-systèmes d'isolation.Cahier des charges plus précis, vous pouvez vous lancer.
| Pas d'utilisation de la feuille d'heures.Partie travail du Wiki presque vide, pas d'illustration, il est à craindre que le travail ne soit pas plus avancé que le Wiki.
| 
| 
| 
| Vidéo déconseillée
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Cahier des charges très précis avec déjà des idées pour la réalisation. Liste des tâches à effectuer très détaillée.
| Pas d'utilisation de la feuille d'heures.Très bon Wiki, bien illustré, travail bien décrit.
| 
| 
| 
| Vidéo conseillée
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Très peu d'apport par rapport au sujet qui est lui même assez bref. Il ne semble pas y avoir eu de rencontre avec l'encadrant dans les temps impartis ? Pas de liste des tâches. Cahier des charges révisés sous la direction de deux encadrants.
| Mauvaise utilisation de la feuille d'heures.Wiki vide, rien de concret semble avoir été réalisé, aucune illustration. Il va falloir mettre les bouchées quadruples ...
| 
| 
| 
| Vidéo plutôt déconseillée
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Le cahier des charges est une paraphrase du sujet. Dans la liste des tâches il semble curieux de ne pas commencer par l'étude des brouilleurs. Avez-vous échangé avec vos encadrants ?Cahier des charges plus précis.
| Tentative d'utilisation de la feuille d'heures, definissez au préalable les lignes dans ce tableau.Un Wiki trop rapidement rédigé en style télégraphique avec des coquilles, à la lecture du Wiki il est difficile de croire que vous avez passé le nombre d'heures annoncées pour si peu de résultats.
| 
| 
| 
| Vidéo plutôt conseillée
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Une simple paraphrase du sujet. Pas de liste des tâches à réaliser. Il semble que vous n'avez pas réussi à échanger avec vos encadrants dans les temps impartis. Des coquilles (corrigées).
| Mauvaise utilisation de la feuille d'heures.Wiki pratiquement vide, l'image n'apporte rien, le Wiki ne reflète que peu de travail.
| 
| 
| 
| Vidéo déconseillée
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Une rencontre avec les encadrants. Un cahier des charges assez précis. Pas de section "tâches à réaliser" mais une section "notre travail" qui pourrait en tenir lieu avec un effort de structuration.
| Utilisation de la feuille d'heure.Un Wiki trop synthétique, des illustrations à venir ?
| 
| 
| 
| Vidéo plutôt déconseillée
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Présentez les objectifs généraux pour commencer. Un cahier des charges très précis mais il manque la liste des tâches à effectuer. Débutez la par l'état de l'art sur les produits déjà commercialisés.
| Bonne utilisation de la fichier d'heures.Excellent Wiki mais non mis à jour ; il s'arrête à la semaine 4.
| 
| 
| 
| Vidéo conseillée
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Le sujet du projet à été recopié. Les deux sections personnelles sont assez mal rédigées. Un contre-sens sur le mode de connexion du prototype actuel : la veilleuse est configurée en point d'accès. Parlez plutôt de "Précisions sur le cahier des charges" plutôt que de "Problèmes rencontrés sur l'étude du projet". Renommez aussi "Nouveau cahier des charges" en "Tâches à réaliser" et ajouter les autres tâches demandées dans le sujet.Cahier des charges et listes des tâches finalement validés par deux encadrants.
| Bonne utilisation de la feuille d'heures.Bon Wiki, correctement illustré. Par contre faudrait arriver à présenter une réalisation, vous prenez du retard.
| 
| 
| 
| Vidéo plutôt déconseillée
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Uniquement une recopie du sujet.Un cahier des charges et une liste de tâches corrects après discussion avec deux encadrants.
| Mauvaise utilisation de la feuille d'heures.Le Wiki n'est pas à jour, il s'arrête à la semaine 4. Bien illustré. Le travail se concentre sur la partie logicielle, en particulier avec un traitement d'image non demandé mais intéressant. Il faudrait se pencher très vite sur le contrôle des lasers.
| 
| 
| 
| Vidéo conseillée
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Un très bon cahier des charges. Le sujet semble être bien assimilé. Une liste des tâches correcte (il faudrait peut-être détailler la programmation du proxy).
| Un Wiki tout simplement parfait.
| 
| 
| 
| Vidéo conseillée
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Un excellent cahier des charges. Liste des tâches très détaillée. Parfait.
| Pas d'utilisation de la feuille d'heures.Wiki très détaillé, correctement illustré, le travail effectué est présenté correctement.
| 
| 
| 
| Vidéo plutôt conseillée
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Vous n'avez pas su vous adapter à la syntaxe mediawiki. Correction pour obtenir un CdC lisible. Une recopie intégrale du sujet. Un cahier des charges qui ressemble plus à une liste des tâches à effectuer.Vous utilisez bien la syntaxe mediawiki maintenant. Par contre il n'y a toujours pas de cahier des charges.
| Feuille d'heures utilisée. Un Wiki mis à jour. Il est très difficile de se faire une idée de votre travail. Il semble que vous soyez actuellement plutôt en TP qu'en projet ?
| 
| 
| 
| Vidéo déconseillée
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Un cahier des charges en 4 lignes, c'est trop court. En particulier rien sur le contexte du projet à savoir le matériel ou le simulateur sur lequel les tests seront effectués. Une liste des tâches, cette liste est-elle avalisé par l'encadrant ?Toujours pas de cahier des charges.
| Feuille d'heures correctement remplie. Wiki plutôt vide. Il est difficile de se faire une idée du travail réalisé, vous semblez bloqué à l'étape bibliographie.
| 
| 
| 
| Vidéo plutôt déconseillée
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (25/01) !! Séance 2 (01/02) !! Séance 3 (08/02) !! Séance 4 (15/02) !! Séance 5 (01/03) !! Séance 6 (08/03) !! Séance 7 !! Séance 8 !! Séance 9 !! Séance 10
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Haroun Abdelali
| 
| Absent
| Absent
| D317 
| D309 
| D309 
| 
| 
| 
| 
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Wenyu sun / Xinyue xu
| E304 Presentes
| C201 Présentes
| C201Présentes
| C201Présentes
| E304&C201
| E304Présentes
| 
| 
| Présentes
| 
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Martin Rohmer / Kévin Godesence
| E306 
| E303 Présents
| E301 Présents
| E305
| E303
| E305
| E305
| E305 Présents
| E305
| 
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Robin Cavalieri / Edmur Lopes
| E305 
| E305 Présents
| E305Présents
| E305
| E305
| E305
| E305
| E305 Présents
| E305
| E303
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Cedric Roussel / Thomas Stievenard
| 
| E303 Présents
| Présents
| E305
| E303
| E305
| E305
| E303/E305 Présents
| E303
| E303
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Mame Arame Diop / Amina Fahem
| 
| E303 Présentes
| E304 Présents
| E304
| E304
| E304
| E306
| E304 Présentes
| E306
| 
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Antoine Arnaudet / Vivian Senaffe
| E304 
| E305 Arnaudet présent Senaffe absent
| E304
| E304Présents
| E304
| E304
| E304
| E304 Présents
| E304
| 
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Butaye Marianne / François Duport
| E304 
| E304 Présents
| E303 Présents
| E305
| E305
| E305
| E305
| E306 Présents
| E306
| E305
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Samy Belhouachi / François Xavier Cockenpot
| 
| E305 Présents
| E301 Présents
| E305 
| E303 et E305
| E303 et E305
| E305
| E305 Présents
| C002
| C002
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Cheikh Said Ahmed / Khadija El Messnaoui
| 
| E305 Said-Ahmed présent El Messnaoui absente
| Présents
| E303 
| E305
| 
| 
| E305 Said-Ahmed présent
| 
| 
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Manlu Luo / Xinyi Wang
| E305 
| E304 Présentes
| E304 Présentes
| E304 
| E304 
| E304 
| E304 
| E304 Présentes
| E304 
| 
| 
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| Olivier Mahieux / Grillère Baptiste
| E306 
| E305 Présents
| Présents
| 
| 
| 
| 
| Présents
| 
| 
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Rodolphe Toin
| E305 
| E305 Présent
| E305/301 Présents
| E305 
| E305 
| E305 
| E305 
| E305 Présent
| 
| E305 
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| | E304 
| Rattrapage DS
| absente
| Malade
| Malade
| Malade
| E303
| E303
| E303
| Malade
|
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Thomas Gosse / Bacem Hagui
| 
| E304 Gosse présent Hagui absent
| Présents
| 
| 
| 
| 
| Présents
| 
| 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Tristan Hart / Etienne Profit
| 
| E304 Présents
| E304Présents
| E304
| E304
| E304
| E304
| E304 Présents
| 
| 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Nicky Ung / Alexis Macherez
| E304 
| E304 Présents
| E304/301 Présents
| E305
| E304
| E304
| E304/C205
| E305 Présents
| 
| 
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Oumaima Naanaa
| 
| Absente
| E301Présente
| E301
| E301
| E306
| E306 C205
| E306 C205 Présente
| 
| 
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Alice Coffin / Diana Marrucho
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Lutecia Damiens / Alexis Dorian
| E306 
| E303 Présents
| E303 Présents
| Fabricarium
| E303
| E306
| E306
| E306 Présents
| Alexis : fabricarium - Lutecia : E306
| E306
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Hugo Delatte
| 
| E304 Présent
| E304 
| E304 Présent
| C201
| C201
| C201
| C201/E304 Présent
| C201/E304
| C201
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Loïc Tombazzi / Marius Trimbur
| E304 
| E303 Présents
| E303 Présents
| E304 
| E303 
| E304 
| E304 
| E303 
| E303 
| 
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Marouan Mcharfi / Tristan lopez
| E304 
| E304 Présents
| E304 Présents
| E304 
| E304 
| E304 
| E304 
| E304 Présent
| 
| 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Alexandre Huet / François Lefevre
| E306
| E306 Présents
| E304 Présents
| E304
| E304
| E304
| E304
| E304 Présents
| 
| 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Djamil Mohamed / Hamza Kerroum
| C305/D306A 
| C305/D306A Présents
| C305/D306A Présents
| C305/D306A 
| C305/D306A 
| C305/D306A 
| C305/D306A 
| C305/D306A 
| C305/D306A Présents
| C305/D306A
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Jean-Baptiste Saison
| C305/D306A 
| C305/D306A Présent
| D306A Présent
| D306A/C305 
| D306A/D322 
| D306A/D322 
| D306A 
| D306A 
| D306A Présent
| D306A/C305
|}

IMA4 2016/2017 P20

2017-03-29T12:21:24Z

Mbutaye : /* Semaine 8 */

__TOC__
 
==Cahier des charges==

Ce cahier des charges a pour objectif de définir le projet, ce qui est attendu ainsi que les contraintes de conception qui lui sont associées.

===Présentation générale du projet===

Le projet consiste à concevoir et développer un environnement virtuel de test pour l'Association de Robotique de Polytech Lille (ARPL). Ce simulateur doit reproduire les conditions de participation à la Logistic League de manière à pouvoir obtenir rapidement des données et tester le code ainsi que les stratégies de jeu utilisés par les robots.

====Contexte====
Ce simulateur est un outil développé dans le cadre de la RoboCup et plus particulièrement de la Logistic League. La RoboCup est une compétition internationale de robotique dans laquelle on voit beaucoup d'entreprises et de robots connus tel que NAO. Cette compétition a pour but de mettre en avant les évolutions en matière de robotique ainsi que les qualités des organismes participants.

La Logistic League est une des différentes épreuves proposées. L'objectif est de repérer le terrain puis de produire des objets avec différents éléments fournis par des machines et à livrer dans des plages de temps données. Une RefereeBox ou boîte arbitre sert à la coordination ainsi qu'à l'arbitrage. C'est cette boite qui va informer le robots des différents objets à construire avec la date de livraison demandée. Elle va également donner leur rôles aux machines présentes sur le terrain. L'arbitre va enregistrer les horaires de dépôt des objets et la position de chacune des machines lors de la compétition.

Celle-ci se déroule sur une piste de la taille d'une salle moyenne. Chaque équipe peut utiliser jusqu'à trois robots Robotino 3 pour réaliser les tâches demandées. Sur la piste, à part les robots, se trouvent seulement des machines dites de production ou de livraison. Elles vont servir soit à se procurer un élément nécessaire à la production de l'objet final soit à livrer celui-ci lorsqu'il est terminé.

====Objectif du projet====

Ce projet va permettre de fournir à l'équipe de l'ARPL un simulateur léger et complet, leur permettant de simuler en un court laps de temps un match entier ou partiel et de tester leur code et leur stratégie. Cela leur permettra de développer plus rapidement et efficacement.

====Description du projet====

Le simulateur devra répondre à un certain nombre de critères. Tout d'abord il lui faudra pouvoir simuler toutes les entités présentes sur la piste lors d'un match. Nous parlons des robots et des machines mais également des capteurs et des conditions de jeu.

Nous devrons faire en sorte que le simulateur puisse facilement intégrer le code de contrôle des robots afin de le tester. De plus il faut permettre à l'utilisateur de gérer les parties du code à tester ainsi que de changer les conditions et paramètres de simulation afin de ne tester que certaines partie du code (par exemple en excluant la gestion des collisions). Nous inclurons une gestion des phases de jeu (Découverte et Production) dans ce but. De ce point de vue l'idéal serait de générer un launchfile et de permettre à l'utilisateur de gérer l'utilisation des nœuds un par un.

En sus, le simulateur gérant les robots de l'équipe adverse, il aura une fonctionnalité de sauvegarde des configurations que ce soit pour le code ou les stratégies afin de comparer l'évolution des performances.

Le simulateur a certaines contraintes afin d'être utilisable et utile. Il doit opérer une compression du temps c'est à dire réaliser la simulation d'un match en moins de temps qu'une durée normale de match. Il s'agit d'obtenir des données représentant la réalité en un cours laps de temps. La communication avec la RefereeBox est indispensable. Celle-ci étant fourni par les organisateurs de la compétition nous n'avons pas à la simuler mais nous devons communiquer avec elle pour rendre la simulation plus réaliste.

====Choix techniques : matériel et logiciel====

Nous n'avons pas besoin de matériel hormis d'ordinateurs afin de programmer.

Dû à la compétition et aux choix de développement de l'équipe de l'ARPL, nous allons programmer en C++ avec les bibliothèques QT ainsi que le middleware ROS, une surcouche de programmation destinée à la programmation de robots.

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

*Simuler les différentes entités
** les Robotinos ;
** les machines ;
** l'environnement.

*Gérer l'interfaçage entre le simulateur et le code des Robots
** lire et lancer le méta-paquet ;
** identifier les différents parties du code ;
** proposer l'activation/désactivation de ces parties et créer un launchfile en conséquence ;
** créer un système de sauvegarde de tout code interfacé permettant sa réutilisation.

*Simuler un match
** communiquer avec la RefereeBox et recevoir les différents ordres de celle-ci ;
** gérer les machines et la communication avec la RefereeBox ;
** gérer l'équipe de l'utilisateur et son interaction avec le reste de la simulation ;
** gérer l'équipe adverse et son interaction avec le reste de la simulation.

*Paramétrage avancé de la simulation
** proposer différents modes de simulations ;
** activation/déssactivation des paramètres de la simulation ;
** gestion des phases.

*Interface utilisateur
** fournir des données utilisables et intéressantes sur la simulation ;
** créer une GUI ergonomique ;
** importer les données de la simulation sur la GUI pour une meilleure analyse de celle-ci.

====Calendrier====

Répartition du temps consacré au projet (120h/personne) :

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 2
|
|
|
|
|
|
|
|
|
|
|
|-
|Mise à niveau matérielle et intellectuelle
|
|13
|
|
|
|1
|
|
|
|
|
|
|-
|Conception théorique
|
|5
|7
|4
|2
|
|
|0,5
|
|
|
|
|-
|Programmation de la simulation
|
|
|8
|15
|16
|4
|8
|6
|
|
|
|
|-
|Programmation de l'affichage avec rviz
|
|
|
|
|
|5
|8
|13
|
|
|
|
|-
|Wiki
|
|
|0,5
|1,5
|1,5
|0,5
|2
|0,5
|
|
|
|
|-
|Réunions tuteurs
|2
|
|
|
|2
|2
|
|
|
|
|
|
|}

==Planning des tâches==

{| class="wikitable"
!Tâche !! Date prévue !! Avancement !! Commentaires
|-
| Affichage des formes avec Rviz
| 01/03/2017
| Terminé
| Cercle & Rectangle
|-
| Affichage d'un robot
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Affichage d'une machine
| 08/03/2017
| Terminé
| Avec "R" + id en affichage texte de la couleur de l'équipe
|-
| Gestion du temps
| 08/03/2017
| Terminé
| Bornes de facteurs possibles à déterminer
|-
| Déplacement d'un robot
| 22/03/2017
| Terminé
| Vitesse et déplacement au point; Besoin d'interfaçage sur le code ARPL
|-
| Affichage de l'orientation de l'entité
| 13/03/2017
| Terminé
| Affichage d'une forme Flèche dont l'orientation change avec celle de l'entité. Grise. Orientation en degrés.
|-
| Lecture et affichage de la map
| 19/03/2017
| Terminé
| Affichage de la map, des murs et des zones interdites.
|-
| Communication RefBox
| 01/04/2017
| Débuté
| Prise d'information sur le système
|-
| Gestion Collision
| 01/04/2017
| Débuté
| Prise d'information sur le système
|}

==Avancement du Projet==

===Semaine 1===
Nous avons commencé par installer ROS et tout ce dont nous avons besoin pour travailler correctement. Nous avons également suivi des [http://wiki.ros.org/ROS/Tutorials tutoriels] pour apprendre à utiliser ROS.

Pour pouvoir travailler en binôme sans problèmes et pour que nos encadrants puissent suivre notre avancement et tester le logiciel, nous avons utilisé le logiciel de gestion de versions Git, sur lequel on publie notre code au fur et à mesure.

Nous n'avions pas encore de dépôt sur celui-ci, donc nous avons commencé par réfléchir à la structure de notre projet.
Nous commencerons par implémenter la phase d'exploration, ce qui comprend aussi le déplacement du robot, la détection de machines et de feux ainsi qu'une interface utilisateur basique.

En effet, le match oppose deux équipes ayant jusque trois robotinos qui s'affrontent lors de deux phases. La première est la phase d'exploration, durant laquelle les robots doivent trouver les machines de leur équipe en explorant le terrain. Ils doivent annoncer la position des machines et les signaux des feux de celles-ci : chaque machine, peu importe son type, possède un feu tricolore (rouge, jaune, vert) qui durant la phase d'exploration aura une combinaison de lumières allumées aléatoirement (au moins une doit l'être).

La création d'un simulateur passe par la réflexion sur les besoins en conception du simulateur (décris en partie ci-dessus). Nous avons donc passé un certain temps à schématiser la structure de notre simulateur et à en assimiler les besoins et l'ordre de création.

===Semaine 2===
Nous avons récupéré un dépôt Git (nommé ''logistic-sim'') sur lequel travailler auprès de nos encadrants, nous pouvons donc commencer la programmation cette semaine.

Ceci étant notre premier projet mêlant ROS et Git, nous avons tenté de créer la structure du projet mais avons vite rencontré quelques difficultés.
Nous avons ensuite compris qu'il était nécessaire de d'abord créer un environnement de travail ROS pour le projet, dans lequel on clône ensuite le dépôt Git localement.

Nous obtenons ainsi la structure de projet suivante :
* Workspace ROS
** build
** devel
** src
*** CMakeLists.txt
*** logistic-sim

Les dossiers build, devel, src et CMakeList.txt sont des fichiers et dossiers générés par ''Catkin'', un outil permettant de créer des paquets ROS facilement.

Nous avons ensuite décidé de séparer le code du projet en différents dossiers en fonction des tâches à effectuer :
* '''Entites''' pour simuler les différentes entités (Robotinos, machines, environnement...)
* '''Gestion_Code''' pour gérer l'interfaçage entre le simulateur et le code des robots
* '''Match''' pour simuler le déroulement d'un match
* '''GUI''' pour l'interface utilisateur avec le framework Qt

Dans chacun de ces dossiers, nous créerons des ''packages'' contenant les différentes fonctionnalités du projet.

Chaque ''package'' a la structure suivante :
* CMakeLists.txt
* include pour les fichiers .h
* package.xml
* README.md
* src pour les classes et nodes .cpp
* launch pour les launchfiles

Dans un premier temps, on commence par la gestion de la position du robot et la reconnaissance des feux.

===Semaine 3===

Nous avons avancé sur la programmation de la gestion de la position du robot et de la reconnaissance des feux.

Nous avons décrit nos classes par des schémas UML avec l'outil gratuit ''Modélio'' pour créer une documentation facilement accessible. Les commentaires des fonctions, classes et fichiers au format ''Doxygen'' nous permettront également de générer une documentation du projet sous format HTML notamment.

Nous suivons aussi la normalisation du code donnée par l'ARPL pour avoir les mêmes conventions de nommage partout.

Nous avons décidé de créer un nouveau package ''match'' qui contiendra les nœuds correspondants aux différentes phases de jeu, et avons donc par conséquent commencé par créer un nœud pour la phase d'exploration.

Nous avons également commencé à réfléchir à la façon dont les informations sont communiquées dans le match : il y a un arbitre, la ''Referee Box'' qui permet de faire communiquer le simulateur et les robots jouant le match. En effet, l'arbitre prend les décisions importantes (placement des machines au début du jeu etc.) et c'est à lui que les robots s'adressent. Nous devons donc aussi communiquer avec lui pour recevoir certaines informations (par exemple les informations de base de la phase d'exploration) et les retransmettre dans le simulateur aux nœuds qui en auront besoin.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v1.png|Schéma UML du package ''machine''
Fichier:Formes_package_Class_diagram_v1.png|Schéma UML du package ''formes''
</gallery>

===Semaine 4===

Cette semaine, nous avons créé plusieurs nouveaux packages et modifié ceux qui avaient déjà été créés.

Nous avons créé la classe Cercle dans le package ''formes'', nous pouvons donc maintenant utiliser deux formes différentes, le rectangle et le cercle.
La classe Entite a elle aussi été rajoutée. En effet, certains attributs des machines sont communs avec ceux des robots; cette classe nous permet de les rassembler et les classes Machine et Robot hériteront ainsi de Entite.

Un nouveau package ''management'' a également fait son apparition. Il contiendra les classes Equipe et Manager. Le Manager sera chargé de créer les équipes et permettra d'y accéder partout dans le code, mais aussi de procéder aux différentes initialisations lors du démarrage d'une nouvelle phase.

Au package ''management'' s'ajoute le nouveau package ''robot'' dont le rôle est de simuler les robotinos lors du match.

<gallery style="margin: 0 auto;">
Fichier:Machine_package_Class_diagram_v2.png|Schéma UML du package ''machine''
Fichier:Robot_package_Class_diagram_v1.png|Schéma UML du package ''robot''
Fichier:Formes_package_Class_diagram_v2.png|Schéma UML du package ''formes''
Fichier:Management_package_Class_diagram_v1.png|Schéma UML du package ''management''
</gallery>

Nous avons également rendu visite à l'un de nos tuteurs de stage pendant la semaine dans le but d'obtenir un premier retour sur notre travail et l'avancement du projet.

Nous avons pu effectuer immédiatement quelques modifications nécessaires suite aux commentaires de notre tuteur. Nous avons dû, par exemple, clôner leur projet dans le même espace de travail que le notre pour pouvoir réutiliser certains paquets de messages déjà créés. Cela permettra une meilleure compatibilité. D'autres modifications concernaient entre autres les conventions de nommage de certaines classes et l'ajout d'un dossier supplémentaire dans le dossier include de chaque package portant le nom de celui-ci, pour ne pas avoir de conflits quant au nommage des fichiers.

Une réunion avec toute l'équipe des tuteurs a été prévue pour la semaine 5.

===Semaine 5===

La semaine a commencé par une réunion avec l'équipe de l'ARPL se chargeant d'encadrer notre projet, c'est-à-dire Vincent et Thomas. Nous avons discuté ensemble de l'avancement du simulateur et de l'ordre dans lequel effectuer les tâches. Ils nous également demandé de créer un planning de nos tâches avec la date prévue pour chacune; ils auront en effet besoin de modifier leur code à certains endroits pour pouvoir utiliser le simulateur (nous n'aurons pas besoin de tous les nœuds, certains comme la détection Laser nous étant inutiles) et souhaiteraient savoir lorsque nous seront prêt à tester de nouvelles fonctionnalités.

Nous nous sommes lancés dans l'affichage des formes avec l'outil ''rviz'', qui permet de visualiser en 3D les messages de type ''visualisation_msgs'' qui lui sont envoyés sur le topic associé. Ces messages sont disponibles en différents types. Pour afficher les formes nous utiliseront le format ''Marker'' qui permet d'afficher un objet en 3D (cubes, sphères, flèches, cylindres) ou en 2D en lui donnant un z de 0.

Nous avons donc commencé par faire les tutoriels sur l'utilisation de rviz puis par ajouter le code nécessaire à l'affichage des formes. Nous avons ainsi décidé d'ajouter la variable du message de type ''Marker'' dans la classe Forme; celle-ci sera accessible par toutes les classes filles de Forme, notamment Cercle et Rectangle. Nous avons également créé une méthode ''display'' qui sera chargée de mettre à jour la position de la forme et de publier le message. Les différents ''setters'' des classes filles modifieront également le message pour qu'il soit à jour lors de l'envoi.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_rectangle.png|Affichage de la forme ''Rectangle'' dans Rviz
Fichier:Rviz_screenshot_cercle.png|Affichage de la forme ''Cercle'' dans Rviz
</gallery>

===Semaine 6===

Cette semaine, nous continuons d'améliorer l'affichage en programmant cette fois-ci la classe ''Robot'' (qui possède une forme, étant une Entité) pour pouvoir visualiser le robot avec rviz. Nous avons donc ajouté une fonction ''display'' à ''Entite'', faisant elle-même appel à la fonction ''display'' de sa forme; ce qui permettra un affichage plus facile de l'objet.

Nous avons également ajouté une forme ''Texte'' pour afficher du texte informatif sur les formes (par exemple, une lettre et un id pour une entité, "R1" dans le cas du premier robot de chaque équipe). Ce texte est affiché en cyan ou en magenta, en fonction de la couleur de l'équipe. Les noms des ''markers'' de la forme et du texte eux aussi dépendent du type de l'entité.

Enfin, nous avons permis au entités de type Machine de gérer leur affichage. Pour cela, nous avons dû créer une classe fille de cette entité pour pouvoir tester son affichage. Le choix s'est porté sur les machines de type BS (Base Station).

En cours de route, nous avons été confrontés à un problème au niveau de l'affichage en 2D. Il semblait logique que la hauteur des objets (en z) soit égale à 0 pour un affichage 2D, mais il s'est avéré que la couleur de l'objet était alors imprévisible (plus souvent noir que de la bonne couleur). Il en fait fallu laisser une légère épaisseur (0.001 mètres dans notre cas) pour que la couleur s'affiche correctement.

Un de nos objectifs était aussi de gérer l'affichage de l'orientation de nos entités. En effet, cela semble essentiel pour les robots par exemple, représentés par des ronds et pouvant se déplacer. Nous avons ainsi créé un nouveau marker ''Fleche''; il était également possible de changer le type de marker en ''interactive marker'' ce qui aurait permis l'affichage de flèches de direction, mais celles-ci permettaient de modifier la position de l'objet et n'étaient disponibles qu'en multiple de 2 (déplacement sur un axe). Le choix s'est donc porté sur l'utilisation d'un marker classique dont on change l'orientation en même temps que celle de l'entité.
Nous avons rencontré quelques soucis quant à la gestion de l'orientation du marker, celle-ci étant un ''quaternion'' (x, y, z, w) alors que nous souhaitons donner l'angle en degrés (ou en radians éventuellement); la documentation n'est pas forcément facile à trouver pour ROS.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_robot.png|Affichage de l'entité ''Robot'' dans Rviz
Fichier:Rviz_screenshot_machine.png|Affichage de l'entité ''BaseStation'' dans Rviz
Fichier:Rviz_screenshot_fleche.png|Affichage de l'entité ''Robot'' avec une forme ''Fleche'' dans Rviz
</gallery>

Nous avons dû corriger nos constructeurs pour être le plus efficace possible et remplir au maximum les besoins des futurs fonctions.

La problématique rendant nécessaire une gestion du temps vient du besoin de l'ARPL de pouvoir contrôler la vitesse de simulation et donc de pouvoir jouer un match très rapidement afin d'observer le comportement de leur code.
Nous avons commencé et fini la gestion du temps. ROS intègre une interface de temps qui se cale sur la machine qui lance ROS.
Pour que plusieurs machines suivent le même temps il faut opérer une synchronisation des temps. Cependant lors de la simulation tous les robots auront leur référentiel temporel sur la même machine ce qui rend une synchronisation inutile.

Il existe un topic ''clock'' qui sert pour les simulations. En forçant nos nœuds à utiliser le temps de simulation, nous avons une échelle temporelle utilisable et synchronisée. Nous avons donc un nœud qui va publier sur ce topic le temps qui sera initialisé à 0 en début de match.

Un paramètre d'environnement ROS sert à régler le facteur d'accélération de la simulation par rapport au temps réel. Il est modifiable à tout instant et est initialisé en premier dans le launchfile.

===Semaine 7===

Nous nous sommes attaqués à l'affichage du terrain dans rviz.

Pour cela, nous pouvions nous inspirer de code écrit par l'ARPL permettant de charger une carte depuis un fichier ''.yaml''. Certains de leurs packages nous ont été utiles, mais d'autres se sont avérés inutilisables tels quels à cause d'erreurs tantôt de "référence indéfinie" à un fichier, tantôt de "redéfinition" du même fichier (la cause de ces erreurs reste pour le moment toujours un mystère).
Nous avons donc opté, pour pouvoir avancer rapidement sur le projet, d'utiliser tel quel ce qu'il était possible d'utiliser, et sinon de recopier les fonctions nécessaires dans notre package. Certaines fonctions nécessitaient d'ailleurs de toute façon des modifications, car dans notre simulateur nous gérons aussi l'affichage de la carte alors qu'eux ne faisaient que la charger.

Un fichier ''.yaml'' a la syntaxe suivante :
field:
name: robocup_simulator
size: [14, 9, 0.0]
gradient:
distance: 0.35
minValue: 0
walls:
bottom1:
start: [-6, 0, 0.0]
end: [-4, 0, 0.0]

Nous avons donc commencé par charger le fichier en mémoire en le passant en paramètre à un ''launchfile'' lançant le nœud chargé de lire et d'afficher la carte. Ensuite, en faisant appel à des ''param'' (paramètres) du nœud actuel et en leur donnant le nom du champs (''name'' par exemple), on peut récupérer les valeurs du fichiers voulues.

Nous avons ainsi créé une classe ''Carte'' pour gérer le chargement des données depuis le fichier et toutes les fonctions utilitaires associées, mais permettant aussi d'afficher la carte grâce à une fonction ''display'' de même fonctionnement que celles créées précédemment pour les entités.

Pour l'affichage sur rviz, nous nous sommes servis du type d'objet ''Map'' pour visualiser le sol du terrain (en blanc ci-dessous). Nous avons également créé un vecteur de Rectangles pour afficher les murs (en bleu foncé ci-dessous) et un vecteur de Rectangles pour les zones interdites au robot (en noir).

Nous aurions aimé mettre à jour la taille de la grille affichée en fonction de la taille de la carte, mais il s'avère que c'est impossible, la grille ne provenant pas d'un message publié.

<gallery style="margin: 0 auto;">
Fichier:Rviz_screenshot_map.png|Affichage du terrain de jeu dans Rviz
</gallery>

===Semaine 8===

Nous avons complété la fonction de gestion de la vitesse. Il n'y a plus de nœud pour gérer les déplacements au profit d'un nœud gérant chaque robot.
Les robots envoient un vecteur "twist" pour donner leur commande vitesse, soit deux vecteurs vitesse 3D, l'un pour la vitesse linéaire et l'autre pour la vitesse angulaire.
Cependant ce vecteur vitesse est paramétré dans le repère du robot, c'est-à-dire avec le vecteur x dirigé dans la direction de l'orientation du robot.
Pour nos calculs nous nous servons du repère originel, que ce soit pour placer les entités ou les déplacer. Cela facilite les calculs dans la simulation.
Ainsi nous devons transposer les vecteurs vitesse reçus pour les appliquer à notre repère.

La simulation fonctionnant en 2D nous simplifions les données en utilisant un seul vecteur 3D (x et y pour le déplacement linéaire et z pour le changement d'orientation soit la vitesse angulaire autour de l'axe z).
La transposition n'est nécessaire que pour les déplacements linéaires, donc nous utilisons de la trigonométrie simple et nous ajoutons le déplacement ainsi obtenu à la position actuelle, ce qui donne :

v_x = v_x1*cos(orientation_radian) - v_y1*sin(orientation_radian)

v_y = v_x1*sin(orientation_radian) + v_y1*sin(orientation_radian)

x_new = v_x *delta_t + x

y_new = v_y *delta_t + y

orientation_new = (v_angulaire*delta_t + orientation) [360]

Nous avons également apporté des modifications aux flèches et textes; en effet, maintenant que le déplacement des robots est possible, nous pouvons effectuer des tests.
Il s'avère que nous ne modifions pas la position des flèches et textes, le robot s'éloignait alors d'eux lorsqu'il se déplaçait.
Nous avons donc ajouté les quelques modifications nécessaires pour que ces formes suivent l'entité en déplacement.

Nous avons aussi commencé à compléter le package ''machine'' pour lui ajouter les sous-classes de Machine représentant les différentes machines (MPS) du jeu (BaseStation, CapStation, RingStation, DeliveryStation).
La BaseStation permettra au robot de récupérer un objet de type base, la RingStation d'y empiler des anneaux de couleurs différentes en fonction des commandes reçues, la CapStation de déposer un chapeau au sommet de l'objet et enfin on l'apporte à la DeliveryStation.

Nous avons complété ci-dessous les schémas UML du projet dans son état actuel :

<gallery style="margin: 0 auto;">
Fichier:Formes_package_Class_diagram_v3.png|Schéma UML du package ''formes''
Fichier:Machine_package_Class_diagram_v3.png|Schéma UML du package ''machine''
Fichier:Management_package_Class_diagram_v2.png|Schéma UML du package ''management''
Fichier:Robot_package_Class_diagram_v2.png|Schéma UML du package ''robot''
</gallery>

===Semaine 9===

===Semaine 10===

== Fichiers Rendus ==

Discussion:Projets IMA4 SC & SA 2016/2017

2017-03-29T12:04:15Z

Mbutaye : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Mini-cahier des charges || Mi-parcours || Fin de parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Cahier des charges conforme à la discussion avec l'encadrant. Présentation propre avec un effort d'illustration. Pas de liste des tâches ou de calendrier prévisionnel. Quelques coquilles corrigées.
| Abandon constaté
| 
| 
| 
| 
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Cahier des charges succinct. Attention à la rédaction en français. Un effort d'illustration avec un schéma global. Une liste des tâches, sans chiffrage pour l'instant.
| Mauvaise utilisation de la feuille d'heures.De gros problèmes de rédaction en français bien compréhensibles.Un Wiki très bien tenu et très bien illustré, une avancée du travail parfaitement expliquée, continuez ainsi !
| 
| 
| 
| 
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Cahier des charges assez précis. Pas trop de coquilles. Une liste des tâches un peu succincte. Réfléchissez bien à la structure du programme pour la mise à jour simplifiée des fiches sur l'application.
| Feuille d'heures non utilisée, Wiki non mis à jour.Pour les 4 premières semaine, des paragraphes correctement rédigés et bien illustré, il était possible de se faire une idée de l'avancée du projet.
| 
| 
| 
| 
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Cahier des charges précis. Forme très correcte. Une liste des tâches réfléchie. Il y a même un calendrier prévisionnel.
| Aucune utilisation de la feuille d'heures.Un excellent Wiki, très complet, très bien illustré, le travail est parfaitement décrit !
| 
| 
| 
| 
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Cahier des charges très précis. De même pour la liste des tâches. L'utilisation de bioloïds ne semble pas justifiée. Pourquoi ne parlez-vous de capteurs que dans le cadre d'un seul des deux appareils ?
| Feuille d'heures très bien exploitée.Wiki très bien rédigé mais absolument pas illustré, un peu court peut être.
| 
| 
| 
| 
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Pas mal de coquilles corrigées. Une certaine imprécision (confusion Arduino Mega et ATMEGA, flou dans la liste des tâches). Cela dit un cahier des charges et une liste des tâches sont présentés. Pensez aux problèmes de calibration du système et à la transmission des données vers un smartphone par exemple.
| Mauvaise utilisation de la feuille d'heures.Quelques coquilles, le Wiki est un peu vide, pas totalement à jour, dommage que le cahier des charges joint ne soit pas intégré directement au Wiki.
| 
| 
| 
| 
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Synthèse correcte de l'entretien avec l'encadrant. Le cahier des charges est correct mais moins précis que le sujet. Le découpage en tâche est un peu rapide : l'analyse des fichiers MIDI devrait être sous-découpée. Presque pas de coquilles.
| Très bonne utilisation de la feuille d'heures.Wiki très synthétique dans un français très correct, à jour, travail sur l'imprimante bien décrit, pas beaucoup d'information sur l'analyse du fichier MIDI.
| 
| 
| 
| 
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Très bonne prise en main du sujet. Cahier des charges très précis. Liste des tâches bien détaillée. Orthographe irréprochable.
| Feuille d'heures bien exploitée, Wiki très bien rédigé, illustré, l'avancé du travail est bien présenté.
| 
| 
| 
| 
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Une grande partie du cahier des charges est une copie du sujet. Définissez ce qu'est une Referee Box. D'un autre coté, le cahier des charges est précis. La liste des tâches est correcte. Cependant elle semble omettre la partie mécanique de la MPS ? Pas de coquilles.
| Pas d'utilisation de la feuille d'heures.Wiki bien rédigé et très bien illustré, le travail effectué est présenté. Il serait bien d'avoir une carte rapidement.
| 
| 
| 
| 
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Des imprécisions dans la transcription de la réunion avec l'encadrant. Voire des contre-sens. Le cahier des charges est assez complet. Pas de liste des tâches. Vous avez vraiment passé 3h sur la rédaction du cahier des charges ? (edit d'Alex : certainement pas)Une liste des tâches ajoutée.
| Pas d'utilisation de la feuille d'heures.Le Wiki est principalement constitué des schématiques et des PCB des différentes cartes. Après tout c'est un point important de votre travail mais le soin apporté à ces productions, s'il s'améliore était initialement assez faible. La rédaction est presque absente ou d'un niveau faible. Vous devriez déjà avoir des cartes en production.
| 
| 
| 
| 
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Le texte a été modifié pour être compréhensible mais le problème n'est pas là. Vous n'avez pas du tout transcrit les demandes de l'encadrant mais donné le sujet du projet de l'an passé. Cette année vous devez améliorer l'aspect esthétique des robots, construire le quatrième robot et améliorer la détection infra-rouge en utilisant le protocole utilisé par les télécommandes infra-rouges classiques. Vous n'avez pas, non plus, donné une liste précise des tâches à réaliser.Cahier des charges révisé avec l'encadrant. La listes des tâches à réaliser est à préciser.
| Pas d'utilisation de la feuille d'heures.Wiki assez vide, le seul élément probant est la présentation de la nouvelle version de la carte des robots suiveurs. Des coquilles, ce que l'on peut difficilement vous reprocher. Il faudrait maintenant avoir un code pour le protocole RC5, utilisez deux Arduinos pour avoir un prototype de démonstration.
| 
| 
| 
| 
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| La restitution de la discussion avec l'encadrant est très correcte et le cahier des charge est précisément décrit. Par contre la liste des tâches à effectuer n'est pas dressée en commençant par l'étude des conditions à respecter pour lancer un tel ballon.
| Pratiquement pas d'utilisation de la feuille d'heures.Wiki un peu rapide, illustré, quelques coquilles. Peu de résultats à ce jour, vous devriez avoir votre carte et avoir conduit un test de communication avec les capteurs et les modules LoRa.
| 
| 
| 
| 
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Assimilation très correcte des demandes faites par les encadrants. Un cahier des charges précis. De même pour la liste des tâches. Un effort de présentation sans trop de coquilles. Cependant quelques erreurs relevées par M. Dhaussy, merci de corriger le CdC au vu des remarques transmises.
| Pas d'utilisation de la feuille d'heures.Wiki à l'abandon, impossible de savoir où vous en êtes dans le travail. Réagissez immédiatement !
| 
| 
| 
| 
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| Le cahier des charges est une recopie du sujet, avec des passages soulignés, certes. Une liste des tâches très précise mais uniquement orientée développement Web. Il manque toute la partie étude et utilisation des éco-systèmes d'isolation.Cahier des charges plus précis, vous pouvez vous lancer.
| Pas d'utilisation de la feuille d'heures.Partie travail du Wiki presque vide, pas d'illustration, il est à craindre que le travail ne soit pas plus avancé que le Wiki.
| 
| 
| 
| 
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Cahier des charges très précis avec déjà des idées pour la réalisation. Liste des tâches à effectuer très détaillée.
| Pas d'utilisation de la feuille d'heures.Très bon Wiki, bien illustré, travail bien décrit.
| 
| 
| 
| 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Très peu d'apport par rapport au sujet qui est lui même assez bref. Il ne semble pas y avoir eu de rencontre avec l'encadrant dans les temps impartis ? Pas de liste des tâches. Cahier des charges révisés sous la direction de deux encadrants.
| Mauvaise utilisation de la feuille d'heures.Wiki vide, rien de concret semble avoir été réalisé, aucune illustration. Il va falloir mettre les bouchées quadruples ...
| 
| 
| 
| 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Le cahier des charges est une paraphrase du sujet. Dans la liste des tâches il semble curieux de ne pas commencer par l'étude des brouilleurs. Avez-vous échangé avec vos encadrants ?Cahier des charges plus précis.
| Tentative d'utilisation de la feuille d'heures, definissez au préalable les lignes dans ce tableau.Un Wiki trop rapidement rédigé en style télégraphique avec des coquilles, à la lecture du Wiki il est difficile de croire que vous avez passé le nombre d'heures annoncées pour si peu de résultats.
| 
| 
| 
| 
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Une simple paraphrase du sujet. Pas de liste des tâches à réaliser. Il semble que vous n'avez pas réussi à échanger avec vos encadrants dans les temps impartis. Des coquilles (corrigées).
| Mauvaise utilisation de la feuille d'heures.Wiki pratiquement vide, l'image n'apporte rien, le Wiki ne reflète que peu de travail.
| 
| 
| 
| 
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Une rencontre avec les encadrants. Un cahier des charges assez précis. Pas de section "tâches à réaliser" mais une section "notre travail" qui pourrait en tenir lieu avec un effort de structuration.
| Utilisation de la feuille d'heure.Un Wiki trop synthétique, des illustrations à venir ?
| 
| 
| 
| 
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Présentez les objectifs généraux pour commencer. Un cahier des charges très précis mais il manque la liste des tâches à effectuer. Débutez la par l'état de l'art sur les produits déjà commercialisés.
| Bonne utilisation de la fichier d'heures.Excellent Wiki mais non mis à jour ; il s'arrête à la semaine 4.
| 
| 
| 
| 
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Le sujet du projet à été recopié. Les deux sections personnelles sont assez mal rédigées. Un contre-sens sur le mode de connexion du prototype actuel : la veilleuse est configurée en point d'accès. Parlez plutôt de "Précisions sur le cahier des charges" plutôt que de "Problèmes rencontrés sur l'étude du projet". Renommez aussi "Nouveau cahier des charges" en "Tâches à réaliser" et ajouter les autres tâches demandées dans le sujet.Cahier des charges et listes des tâches finalement validés par deux encadrants.
| Bonne utilisation de la feuille d'heures.Bon Wiki, correctement illustré. Par contre faudrait arriver à présenter une réalisation, vous prenez du retard.
| 
| 
| 
| 
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Uniquement une recopie du sujet.Un cahier des charges et une liste de tâches corrects après discussion avec deux encadrants.
| Mauvaise utilisation de la feuille d'heures.Le Wiki n'est pas à jour, il s'arrête à la semaine 4. Bien illustré. Le travail se concentre sur la partie logicielle, en particulier avec un traitement d'image non demandé mais intéressant. Il faudrait se pencher très vite sur le contrôle des lasers.
| 
| 
| 
| 
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Un très bon cahier des charges. Le sujet semble être bien assimilé. Une liste des tâches correcte (il faudrait peut-être détailler la programmation du proxy).
| Un Wiki tout simplement parfait.
| 
| 
| 
| 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Un excellent cahier des charges. Liste des tâches très détaillée. Parfait.
| Pas d'utilisation de la feuille d'heures.Wiki très détaillé, correctement illustré, le travail effectué est présenté correctement.
| 
| 
| 
| 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Vous n'avez pas su vous adapter à la syntaxe mediawiki. Correction pour obtenir un CdC lisible. Une recopie intégrale du sujet. Un cahier des charges qui ressemble plus à une liste des tâches à effectuer.Vous utilisez bien la syntaxe mediawiki maintenant. Par contre il n'y a toujours pas de cahier des charges.
| Feuille d'heures utilisée. Un Wiki mis à jour. Il est très difficile de se faire une idée de votre travail. Il semble que vous soyez actuellement plutôt en TP qu'en projet ?
| 
| 
| 
| 
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Un cahier des charges en 4 lignes, c'est trop court. En particulier rien sur le contexte du projet à savoir le matériel ou le simulateur sur lequel les tests seront effectués. Une liste des tâches, cette liste est-elle avalisé par l'encadrant ?Toujours pas de cahier des charges.
| Feuille d'heures correctement remplie. Wiki plutôt vide. Il est difficile de se faire une idée du travail réalisé, vous semblez bloqué à l'étape bibliographie.
| 
| 
| 
| 
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (25/01) !! Séance 2 (01/02) !! Séance 3 (08/02) !! Séance 4 (15/02) !! Séance 5 (01/03) !! Séance 6 (08/03) !! Séance 7 !! Séance 8 !! Séance 9 !! Séance 10
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Haroun Abdelali
| 
| Absent
| Absent
| D317 
| D309 
| D309 
| 
| 
| 
| 
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Wenyu sun / Xinyue xu
| E304 Presentes
| C201 Présentes
| C201Présentes
| C201Présentes
| E304&C201
| E304Présentes
| 
| 
| 
| 
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Martin Rohmer / Kévin Godesence
| E306 
| E303 Présents
| E301 Présents
| E305
| E303
| E305
| E305
| E305 Présents
| 
| 
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Robin Cavalieri / Edmur Lopes
| E305 
| E305 Présents
| E305Présents
| E305
| E305
| E305
| E305
| E305 Présents
| E305
| 
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Cedric Roussel / Thomas Stievenard
| 
| E303 Présents
| Présents
| E305
| E303
| E305
| E305
| E303/E305 Présents
| 
| 
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Mame Arame Diop / Amina Fahem
| 
| E303 Présentes
| E304 Présents
| E304
| E304
| E304
| E306
| E304 Présentes
| E306
| 
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Antoine Arnaudet / Vivian Senaffe
| E304 
| E305 Arnaudet présent Senaffe absent
| E304
| E304Présents
| E304
| E304
| E304
| E304 Présents
| 
| 
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Butaye Marianne / François Duport
| E304 
| E304 Présents
| E303 Présents
| E305
| E305
| E305
| E305
| E306 Présents
| E306
| 
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Samy Belhouachi / François Xavier Cockenpot
| 
| E305 Présents
| E301 Présents
| E305 
| E303 et E305
| E303 et E305
| E305
| E305 Présents
| 
| 
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Cheikh Said Ahmed / Khadija El Messnaoui
| 
| E305 Said-Ahmed présent El Messnaoui absente
| Présents
| E303 
| E305
| 
| 
| E305 Said-Ahmed présent
| 
| 
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Manlu Luo / Xinyi Wang
| E305 
| E304 Présentes
| E304 Présentes
| E304 
| E304 
| E304 
| E304 
| E304 Présentes
| 
| 
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| Olivier Mahieux / Grillère Baptiste
| E306 
| E305 Présents
| Présents
| 
| 
| 
| 
| Présents
| 
| 
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Rodolphe Toin
| E305 
| E305 Présent
| E305/301 Présents
| E305 
| E305 
| E305 
| E305 
| E305 Présent
| 
| 
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| | E304 
| Rattrapage DS
| Abs
| Malade
| Malade
| Malade
| E303
| E303
| E303
| ABS
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Thomas Gosse / Bacem Hagui
| 
| E304 Gosse présent Hagui absent
| Présents
| 
| 
| 
| 
| Présents
| 
| 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Tristan Hart / Etienne Profit
| 
| E304 Présents
| E304Présents
| E304
| E304
| E304
| E304
| E304 Présents
| 
| 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Nicky Ung / Alexis Macherez
| E304 
| E304 Présents
| E304/301 Présents
| E305
| E304
| E304
| E304/C205
| E305 Présents
| 
| 
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Oumaima Naanaa
| 
| Absente
| E301Présente
| E301
| E301
| E306
| E306 C205
| E306 C205 Présente
| 
| 
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Alice Coffin / Diana Marrucho
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Lutecia Damiens / Alexis Dorian
| E306 
| E303 Présents
| E303 Présents
| Fabricarium
| E303
| E306
| E306
| E306 Présents
| 
| 
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Hugo Delatte
| 
| E304 Présent
| E304 
| E304 Présent
| C201
| C201
| C201
| C201/E304Présent
| C201/E304
| C201
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Loïc Tombazzi / Marius Trimbur
| E304 
| E303 Présents
| E303 Présents
| E304 
| E303 
| E304 
| E304 
| E303 
| 
| 
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Marouan Mcharfi / Tristan lopez
| E304 
| E304 Présents
| E304 Présents
| E304 
| E304 
| E304 
| E304 
| E304 Présent
| 
| 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Alexandre Huet / François Lefevre
| E306
| E306 Présents
| E304 Présents
| E304
| E304
| E304
| E304
| E304 Présents
| 
| 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Djamil Mohamed / Hamza Kerroum
| C305/D306A 
| C305/D306A Présents
| C305/D306A Présents
| C305/D306A 
| C305/D306A 
| C305/D306A 
| C305/D306A 
| C305/D306A 
| 
| 
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Jean-Baptiste Saison
| C305/D306A 
| C305/D306A Présent
| D306A Présent
| D306A/C305 
| D306A/D322 
| D306A/D322 
| D306A 
| D306A 
| 
| 
|}

IMA4 2016/2017 P20

2017-03-27T14:38:40Z

Mbutaye : /* Semaine 8 */

Fichier:Robot package Class diagram v2.png

2017-03-27T14:37:40Z

Mbutaye : 2eme version (semaine 8) du package Robot pour le projet P20 de 2016/17.

2eme version (semaine 8) du package Robot pour le projet P20 de 2016/17.

Fichier:Management package Class diagram v2.png

2017-03-27T14:37:15Z

Mbutaye : 2eme version (semaine 8) du package Management pour le projet P20 de 2016/17.

2eme version (semaine 8) du package Management pour le projet P20 de 2016/17.

Fichier:Machine package Class diagram v3.png

2017-03-27T14:36:39Z

Mbutaye : 3eme version (semaine 8) du package Machine pour le projet P20 de 2016/17.

3eme version (semaine 8) du package Machine pour le projet P20 de 2016/17.

Fichier:Formes package Class diagram v3.png

2017-03-27T14:34:49Z

Mbutaye : 3eme version (semaine 8) du package Formes pour le projet P20 de 2016/17.

3eme version (semaine 8) du package Formes pour le projet P20 de 2016/17.

Discussion:Projets IMA4 SC & SA 2016/2017

2017-03-22T13:18:37Z

Mbutaye : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Mini-cahier des charges || Mi-parcours || Fin de parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Cahier des charges conforme à la discussion avec l'encadrant. Présentation propre avec un effort d'illustration. Pas de liste des tâches ou de calendrier prévisionnel. Quelques coquilles corrigées.
| Abandon constaté
| 
| 
| 
| 
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Cahier des charges succinct. Attention à la rédaction en français. Un effort d'illustration avec un schéma global. Une liste des tâches, sans chiffrage pour l'instant.
| Mauvaise utilisation de la feuille d'heures.De gros problèmes de rédaction en français bien compréhensibles.Un Wiki très bien tenu et très bien illustré, une avancée du travail parfaitement expliquée, continuez ainsi !
| 
| 
| 
| 
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Cahier des charges assez précis. Pas trop de coquilles. Une liste des tâches un peu succincte. Réfléchissez bien à la structure du programme pour la mise à jour simplifiée des fiches sur l'application.
| Feuille d'heures non utilisée, Wiki non mis à jour.Pour les 4 premières semaine, des paragraphes correctement rédigés et bien illustré, il était possible de se faire une idée de l'avancée du projet.
| 
| 
| 
| 
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Cahier des charges précis. Forme très correcte. Une liste des tâches réfléchie. Il y a même un calendrier prévisionnel.
| Aucune utilisation de la feuille d'heures.Un excellent Wiki, très complet, très bien illustré, le travail est parfaitement décrit !
| 
| 
| 
| 
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Cahier des charges très précis. De même pour la liste des tâches. L'utilisation de bioloïds ne semble pas justifiée. Pourquoi ne parlez-vous de capteurs que dans le cadre d'un seul des deux appareils ?
| Feuille d'heures très bien exploitée.Wiki très bien rédigé mais absolument pas illustré, un peu court peut être.
| 
| 
| 
| 
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Pas mal de coquilles corrigées. Une certaine imprécision (confusion Arduino Mega et ATMEGA, flou dans la liste des tâches). Cela dit un cahier des charges et une liste des tâches sont présentés. Pensez aux problèmes de calibration du système et à la transmission des données vers un smartphone par exemple.
| Mauvaise utilisation de la feuille d'heures.Quelques coquilles, le Wiki est un peu vide, pas totalement à jour, dommage que le cahier des charges joint ne soit pas intégré directement au Wiki.
| 
| 
| 
| 
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Synthèse correcte de l'entretien avec l'encadrant. Le cahier des charges est correct mais moins précis que le sujet. Le découpage en tâche est un peu rapide : l'analyse des fichiers MIDI devrait être sous-découpée. Presque pas de coquilles.
| Très bonne utilisation de la feuille d'heures.Wiki très synthétique dans un français très correct, à jour, travail sur l'imprimante bien décrit, pas beaucoup d'information sur l'analyse du fichier MIDI.
| 
| 
| 
| 
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Très bonne prise en main du sujet. Cahier des charges très précis. Liste des tâches bien détaillée. Orthographe irréprochable.
| Feuille d'heures bien exploitée, Wiki très bien rédigé, illustré, l'avancé du travail est bien présenté.
| 
| 
| 
| 
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Une grande partie du cahier des charges est une copie du sujet. Définissez ce qu'est une Referee Box. D'un autre coté, le cahier des charges est précis. La liste des tâches est correcte. Cependant elle semble omettre la partie mécanique de la MPS ? Pas de coquilles.
| Pas d'utilisation de la feuille d'heures.Wiki bien rédigé et très bien illustré, le travail effectué est présenté. Il serait bien d'avoir une carte rapidement.
| 
| 
| 
| 
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Des imprécisions dans la transcription de la réunion avec l'encadrant. Voire des contre-sens. Le cahier des charges est assez complet. Pas de liste des tâches. Vous avez vraiment passé 3h sur la rédaction du cahier des charges ? (edit d'Alex : certainement pas)Une liste des tâches ajoutée.
| Pas d'utilisation de la feuille d'heures.Le Wiki est principalement constitué des schématiques et des PCB des différentes cartes. Après tout c'est un point important de votre travail mais le soin apporté à ces productions, s'il s'améliore était initialement assez faible. La rédaction est presque absente ou d'un niveau faible. Vous devriez déjà avoir des cartes en production.
| 
| 
| 
| 
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Le texte a été modifié pour être compréhensible mais le problème n'est pas là. Vous n'avez pas du tout transcrit les demandes de l'encadrant mais donné le sujet du projet de l'an passé. Cette année vous devez améliorer l'aspect esthétique des robots, construire le quatrième robot et améliorer la détection infra-rouge en utilisant le protocole utilisé par les télécommandes infra-rouges classiques. Vous n'avez pas, non plus, donné une liste précise des tâches à réaliser.Cahier des charges révisé avec l'encadrant. La listes des tâches à réaliser est à préciser.
| Pas d'utilisation de la feuille d'heures.Wiki assez vide, le seul élément probant est la présentation de la nouvelle version de la carte des robots suiveurs. Des coquilles, ce que l'on peut difficilement vous reprocher. Il faudrait maintenant avoir un code pour le protocole RC5, utilisez deux Arduinos pour avoir un prototype de démonstration.
| 
| 
| 
| 
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| La restitution de la discussion avec l'encadrant est très correcte et le cahier des charge est précisément décrit. Par contre la liste des tâches à effectuer n'est pas dressée en commençant par l'étude des conditions à respecter pour lancer un tel ballon.
| Pratiquement pas d'utilisation de la feuille d'heures.Wiki un peu rapide, illustré, quelques coquilles. Peu de résultats à ce jour, vous devriez avoir votre carte et avoir conduit un test de communication avec les capteurs et les modules LoRa.
| 
| 
| 
| 
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Assimilation très correcte des demandes faites par les encadrants. Un cahier des charges précis. De même pour la liste des tâches. Un effort de présentation sans trop de coquilles. Cependant quelques erreurs relevées par M. Dhaussy, merci de corriger le CdC au vu des remarques transmises.
| Pas d'utilisation de la feuille d'heures.Wiki à l'abandon, impossible de savoir où vous en êtes dans le travail. Réagissez immédiatement !
| 
| 
| 
| 
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| Le cahier des charges est une recopie du sujet, avec des passages soulignés, certes. Une liste des tâches très précise mais uniquement orientée développement Web. Il manque toute la partie étude et utilisation des éco-systèmes d'isolation.Cahier des charges plus précis, vous pouvez vous lancer.
| Pas d'utilisation de la feuille d'heures.Partie travail du Wiki presque vide, pas d'illustration, il est à craindre que le travail ne soit pas plus avancé que le Wiki.
| 
| 
| 
| 
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Cahier des charges très précis avec déjà des idées pour la réalisation. Liste des tâches à effectuer très détaillée.
| Pas d'utilisation de la feuille d'heures.Très bon Wiki, bien illustré, travail bien décrit.
| 
| 
| 
| 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Très peu d'apport par rapport au sujet qui est lui même assez bref. Il ne semble pas y avoir eu de rencontre avec l'encadrant dans les temps impartis ? Pas de liste des tâches. Cahier des charges révisés sous la direction de deux encadrants.
| Mauvaise utilisation de la feuille d'heures.Wiki vide, rien de concret semble avoir été réalisé, aucune illustration. Il va falloir mettre les bouchées quadruples ...
| 
| 
| 
| 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Le cahier des charges est une paraphrase du sujet. Dans la liste des tâches il semble curieux de ne pas commencer par l'étude des brouilleurs. Avez-vous échangé avec vos encadrants ?Cahier des charges plus précis.
| Tentative d'utilisation de la feuille d'heures, definissez au préalable les lignes dans ce tableau.Un Wiki trop rapidement rédigé en style télégraphique avec des coquilles, à la lecture du Wiki il est difficile de croire que vous avez passé le nombre d'heures annoncées pour si peu de résultats.
| 
| 
| 
| 
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Une simple paraphrase du sujet. Pas de liste des tâches à réaliser. Il semble que vous n'avez pas réussi à échanger avec vos encadrants dans les temps impartis. Des coquilles (corrigées).
| Mauvaise utilisation de la feuille d'heures.Wiki pratiquement vide, l'image n'apporte rien, le Wiki ne reflète que peu de travail.
| 
| 
| 
| 
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Une rencontre avec les encadrants. Un cahier des charges assez précis. Pas de section "tâches à réaliser" mais une section "notre travail" qui pourrait en tenir lieu avec un effort de structuration.
| Utilisation de la feuille d'heure.Un Wiki trop synthétique, des illustrations à venir ?
| 
| 
| 
| 
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Présentez les objectifs généraux pour commencer. Un cahier des charges très précis mais il manque la liste des tâches à effectuer. Débutez la par l'état de l'art sur les produits déjà commercialisés.
| Bonne utilisation de la fichier d'heures.Excellent Wiki mais non mis à jour ; il s'arrête à la semaine 4.
| 
| 
| 
| 
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Le sujet du projet à été recopié. Les deux sections personnelles sont assez mal rédigées. Un contre-sens sur le mode de connexion du prototype actuel : la veilleuse est configurée en point d'accès. Parlez plutôt de "Précisions sur le cahier des charges" plutôt que de "Problèmes rencontrés sur l'étude du projet". Renommez aussi "Nouveau cahier des charges" en "Tâches à réaliser" et ajouter les autres tâches demandées dans le sujet.Cahier des charges et listes des tâches finalement validés par deux encadrants.
| Bonne utilisation de la feuille d'heures.Bon Wiki, correctement illustré. Par contre faudrait arriver à présenter une réalisation, vous prenez du retard.
| 
| 
| 
| 
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Uniquement une recopie du sujet.Un cahier des charges et une liste de tâches corrects après discussion avec deux encadrants.
| Mauvaise utilisation de la feuille d'heures.Le Wiki n'est pas à jour, il s'arrête à la semaine 4. Bien illustré. Le travail se concentre sur la partie logicielle, en particulier avec un traitement d'image non demandé mais intéressant. Il faudrait se pencher très vite sur le contrôle des lasers.
| 
| 
| 
| 
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Un très bon cahier des charges. Le sujet semble être bien assimilé. Une liste des tâches correcte (il faudrait peut-être détailler la programmation du proxy).
| Un Wiki tout simplement parfait.
| 
| 
| 
| 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Un excellent cahier des charges. Liste des tâches très détaillée. Parfait.
| Pas d'utilisation de la feuille d'heures.Wiki très détaillé, correctement illustré, le travail effectué est présenté correctement.
| 
| 
| 
| 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Vous n'avez pas su vous adapter à la syntaxe mediawiki. Correction pour obtenir un CdC lisible. Une recopie intégrale du sujet. Un cahier des charges qui ressemble plus à une liste des tâches à effectuer.Vous utilisez bien la syntaxe mediawiki maintenant. Par contre il n'y a toujours pas de cahier des charges.
| Feuille d'heures utilisée. Un Wiki mis à jour. Il est très difficile de se faire une idée de votre travail. Il semble que vous soyez actuellement plutôt en TP qu'en projet ?
| 
| 
| 
| 
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Un cahier des charges en 4 lignes, c'est trop court. En particulier rien sur le contexte du projet à savoir le matériel ou le simulateur sur lequel les tests seront effectués. Une liste des tâches, cette liste est-elle avalisé par l'encadrant ?Toujours pas de cahier des charges.
| Feuille d'heures correctement remplie. Wiki plutôt vide. Il est difficile de se faire une idée du travail réalisé, vous semblez bloqué à l'étape bibliographie.
| 
| 
| 
| 
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (25/01) !! Séance 2 (01/02) !! Séance 3 (08/02) !! Séance 4 (15/02) !! Séance 5 (01/03) !! Séance 6 (08/03) !! Séance 7 !! Séance 8 !! Séance 9 !! Séance 10
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Haroun Abdelali
| 
| Absent
| Absent
| D317 
| D309 
| D309 
| 
| 
| 
| 
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Wenyu sun / Xinyue xu
| E304 Presentes
| C201 Présentes
| C201Présentes
| C201Présentes
| E304&C201
| E304
| 
| 
| 
| 
| 
| 
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Martin Rohmer / Kévin Godesence
| E306 
| E303 Présents
| E301 Présents
| E305
| E303
| E305
| E305
| 
| 
| 
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Robin Cavalieri / Edmur Lopes
| E305 
| E305 Présents
| E305Présents
| E305
| E305
| E305
| E305
| E305
| 
| 
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Cedric Roussel / Thomas Stievenard
| 
| E303 Présents
| Présents
| E305
| E303
| E305
| E305
| 
| 
| 
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Mame Arame Diop / Amina Fahem
| 
| E303 Présentes
| E304 Présents
| E304
| E304
| E304
| E306
| E304
| 
| 
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Antoine Arnaudet / Vivian Senaffe
| E304 
| E305 Arnaudet présent Senaffe absent
| E304
| E304Présents
| E304
| E304
| E304
| E304
| 
| 
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Butaye Marianne / François Duport
| E304 
| E304 Présents
| E303 Présents
| E305
| E305
| E305
| E305
| E306
| 
| 
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Samy Belhouachi / François Xavier Cockenpot
| 
| E305 Présents
| E301 Présents
| E305 
| E303 et E305
| E303 et E305
| E305
| 
| 
| 
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Cheikh Said Ahmed / Khadija El Messnaoui
| 
| E305 Said-Ahmed présent El Messnaoui absente
| Présents
| E303 
| E305
| 
| 
| 
| 
| 
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Manlu Luo / Xinyi Wang
| E305 
| E304 Présentes
| E304 Présentes
| E304 
| E304 
| 
| 
| 
| 
| 
| 
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| Olivier Mahieux / Grillère Baptiste
| E306 
| E305 Présents
| Présents
| 
| 
| 
| 
| 
| 
| 
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Rodolphe Toin
| E305 
| E305 Présent
| E305/301 Présents
| E305 
| E305 
| E305 
| E305 
| E305 
| 
| 
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| | E304 
| Rattrapage DS
| Abs
| Malade
| Malade
| Malade
| E303
| E303
| 
| 
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Thomas Gosse / Bacem Hagui
| 
| E304 Gosse présent Hagui absent
| Présents
| 
| 
| 
| 
| 
| 
| 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Tristan Hart / Etienne Profit
| 
| E304 Présents
| E304Présents
| E304
| E304
| E304
| E304
| 
| 
| 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Nicky Ung / Alexis Macherez
| E304 
| E304 Présents
| E304/301 Présents
| E305
| E304
| E304
| E304/C205
| 
| 
| 
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Oumaima Naanaa
| 
| Absente
| E301Présente
| E301
| E301
| E306
| 
| 
| 
| 
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Alice Coffin / Diana Marrucho
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Lutecia Damiens / Alexis Dorian
| E306 
| E303 Présents
| E303 Présents
| Fabricarium
| E303
| E306
| E306
| 
| 
| 
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Hugo Delatte
| 
| E304 Présents
| E304 
| E304 Présents
| 
| 
| 
| 
| 
| 
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Loïc Tombazzi / Marius Trimbur
| E304 
| E303 Présents
| E303 Présents
| E304 
| E303 
| E304 
| E304 
| 
| 
| 
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Marouan Mcharfi / Tristan lopez
| E304 
| E304 Présents
| E304 Présents
| E304 
| E304 
| E304 
| E304 
| 
| 
| 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Alexandre Huet / François Lefevre
| E306
| E306 Présents
| E304 Présents
| E304
| E304
| E304
| E304
| 
| 
| 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Djamil Mohamed / Hamza Kerroum
| C305/D306A 
| C305/D306A Présents
| C305/D306A Présents
| C305/D306A 
| C305/D306A 
| C305/D306A
| C305/D306A
| 
| 
| 
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Jean-Baptiste Saison
| C305/D306A 
| C305/D306A Présent
| D306A Présent
| D306A/C305 
| D306A/D322 
| D306A/D322 
| D306A 
| 
| 
| 
|}

IMA4 2016/2017 P20

2017-03-20T16:42:40Z

Mbutaye : /* Semaine 7 */

Fichier:Rviz screenshot map.png

2017-03-20T16:22:50Z

Mbutaye : Screenshot de l'affichage de la carte dans RViz (semaine 7) pour le projet P20 de 2016/17.

Screenshot de l'affichage de la carte dans RViz (semaine 7) pour le projet P20 de 2016/17.

IMA4 2016/2017 P20

2017-03-20T16:09:44Z

Mbutaye : /* Planning des tâches */

IMA4 2016/2017 P20

2017-03-20T16:08:15Z

Mbutaye : /* Feuille d'heures */

IMA4 2016/2017 P20

2017-03-20T16:07:49Z

Mbutaye : /* Feuille d'heures */

IMA4 2016/2017 P20

2017-03-15T13:22:55Z

Mbutaye : /* Semaine 6 */

Fichier:Rviz screenshot fleche.png

2017-03-15T13:22:20Z

Mbutaye : Screenshot de l'affichage de l'entité Robot avec une flèche pour l'orientation dans RViz (semaine 6) pour le projet P20 de 2016/17.

Screenshot de l'affichage de l'entité Robot avec une flèche pour l'orientation dans RViz (semaine 6) pour le projet P20 de 2016/17.

IMA4 2016/2017 P20

2017-03-15T13:06:40Z

Mbutaye : /* Feuille d'heures */

Discussion:Projets IMA4 SC & SA 2016/2017

2017-03-15T12:58:17Z

Mbutaye : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Mini-cahier des charges || Mi-parcours || Fin de parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Cahier des charges conforme à la discussion avec l'encadrant. Présentation propre avec un effort d'illustration. Pas de liste des tâches ou de calendrier prévisionnel. Quelques coquilles corrigées.
| Abandon constaté
| 
| 
| 
| 
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Cahier des charges succinct. Attention à la rédaction en français. Un effort d'illustration avec un schéma global. Une liste des tâches, sans chiffrage pour l'instant.
| Mauvaise utilisation de la feuille d'heures.De gros problèmes de rédaction en français bien compréhensibles.Un Wiki très bien tenu et très bien illustré, une avancée du travail parfaitement expliquée, continuez ainsi !
| 
| 
| 
| 
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Cahier des charges assez précis. Pas trop de coquilles. Une liste des tâches un peu succincte. Réfléchissez bien à la structure du programme pour la mise à jour simplifiée des fiches sur l'application.
| Feuille d'heures non utilisée, Wiki non mis à jour.Pour les 4 premières semaine, des paragraphes correctement rédigés et bien illustré, il était possible de se faire une idée de l'avancée du projet.
| 
| 
| 
| 
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Cahier des charges précis. Forme très correcte. Une liste des tâches réfléchie. Il y a même un calendrier prévisionnel.
| Aucune utilisation de la feuille d'heures.Un excellent Wiki, très complet, très bien illustré, le travail est parfaitement décrit !
| 
| 
| 
| 
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Cahier des charges très précis. De même pour la liste des tâches. L'utilisation de bioloïds ne semble pas justifiée. Pourquoi ne parlez-vous de capteurs que dans le cadre d'un seul des deux appareils ?
| Feuille d'heures très bien exploitée.Wiki très bien rédigé mais absolument pas illustré, un peu court peut être.
| 
| 
| 
| 
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Pas mal de coquilles corrigées. Une certaine imprécision (confusion Arduino Mega et ATMEGA, flou dans la liste des tâches). Cela dit un cahier des charges et une liste des tâches sont présentés. Pensez aux problèmes de calibration du système et à la transmission des données vers un smartphone par exemple.
| Mauvaise utilisation de la feuille d'heures.Quelques coquilles, le Wiki est un peu vide, pas totalement à jour, dommage que le cahier des charges joint ne soit pas intégré directement au Wiki.
| 
| 
| 
| 
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Synthèse correcte de l'entretien avec l'encadrant. Le cahier des charges est correct mais moins précis que le sujet. Le découpage en tâche est un peu rapide : l'analyse des fichiers MIDI devrait être sous-découpée. Presque pas de coquilles.
| Très bonne utilisation de la feuille d'heures.Wiki très synthétique dans un français très correct, à jour, travail sur l'imprimante bien décrit, pas beaucoup d'information sur l'analyse du fichier MIDI.
| 
| 
| 
| 
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Très bonne prise en main du sujet. Cahier des charges très précis. Liste des tâches bien détaillée. Orthographe irréprochable.
| Feuille d'heures bien exploitée, Wiki très bien rédigé, illustré, l'avancé du travail est bien présenté.
| 
| 
| 
| 
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Une grande partie du cahier des charges est une copie du sujet. Définissez ce qu'est une Referee Box. D'un autre coté, le cahier des charges est précis. La liste des tâches est correcte. Cependant elle semble omettre la partie mécanique de la MPS ? Pas de coquilles.
| Pas d'utilisation de la feuille d'heures.Wiki bien rédigé et très bien illustré, le travail effectué est présenté. Il serait bien d'avoir une carte rapidement.
| 
| 
| 
| 
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Des imprécisions dans la transcription de la réunion avec l'encadrant. Voire des contre-sens. Le cahier des charges est assez complet. Pas de liste des tâches. Vous avez vraiment passé 3h sur la rédaction du cahier des charges ? (edit d'Alex : certainement pas)Une liste des tâches ajoutée.
| Pas d'utilisation de la feuille d'heures.Le Wiki est principalement constitué des schématiques et des PCB des différentes cartes. Après tout c'est un point important de votre travail mais le soin apporté à ces productions, s'il s'améliore était initialement assez faible. La rédaction est presque absente ou d'un niveau faible. Vous devriez déjà avoir des cartes en production.
| 
| 
| 
| 
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Le texte a été modifié pour être compréhensible mais le problème n'est pas là. Vous n'avez pas du tout transcrit les demandes de l'encadrant mais donné le sujet du projet de l'an passé. Cette année vous devez améliorer l'aspect esthétique des robots, construire le quatrième robot et améliorer la détection infra-rouge en utilisant le protocole utilisé par les télécommandes infra-rouges classiques. Vous n'avez pas, non plus, donné une liste précise des tâches à réaliser.Cahier des charges révisé avec l'encadrant. La listes des tâches à réaliser est à préciser.
| Pas d'utilisation de la feuille d'heures.Wiki assez vide, le seul élément probant est la présentation de la nouvelle version de la carte des robots suiveurs. Des coquilles, ce que l'on peut difficilement vous reprocher. Il faudrait maintenant avoir un code pour le protocole RC5, utilisez deux Arduinos pour avoir un prototype de démonstration.
| 
| 
| 
| 
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| La restitution de la discussion avec l'encadrant est très correcte et le cahier des charge est précisément décrit. Par contre la liste des tâches à effectuer n'est pas dressée en commençant par l'étude des conditions à respecter pour lancer un tel ballon.
| Pratiquement pas d'utilisation de la feuille d'heures.Wiki un peu rapide, illustré, quelques coquilles. Peu de résultats à ce jour, vous devriez avoir votre carte et avoir conduit un test de communication avec les capteurs et les modules LoRa.
| 
| 
| 
| 
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Assimilation très correcte des demandes faites par les encadrants. Un cahier des charges précis. De même pour la liste des tâches. Un effort de présentation sans trop de coquilles. Cependant quelques erreurs relevées par M. Dhaussy, merci de corriger le CdC au vu des remarques transmises.
| Pas d'utilisation de la feuille d'heures.Wiki à l'abandon, impossible de savoir où vous en êtes dans le travail. Réagissez immédiatement !
| 
| 
| 
| 
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| Le cahier des charges est une recopie du sujet, avec des passages soulignés, certes. Une liste des tâches très précise mais uniquement orientée développement Web. Il manque toute la partie étude et utilisation des éco-systèmes d'isolation.Cahier des charges plus précis, vous pouvez vous lancer.
| Pas d'utilisation de la feuille d'heures.Partie travail du Wiki presque vide, pas d'illustration, il est à craindre que le travail ne soit pas plus avancé que le Wiki.
| 
| 
| 
| 
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Cahier des charges très précis avec déjà des idées pour la réalisation. Liste des tâches à effectuer très détaillée.
| Pas d'utilisation de la feuille d'heures.Très bon Wiki, bien illustré, travail bien décrit.
| 
| 
| 
| 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Très peu d'apport par rapport au sujet qui est lui même assez bref. Il ne semble pas y avoir eu de rencontre avec l'encadrant dans les temps impartis ? Pas de liste des tâches. Cahier des charges révisés sous la direction de deux encadrants.
| Mauvaise utilisation de la feuille d'heures.Wiki vide, rien de concret semble avoir été réalisé, aucune illustration. Il va falloir mettre les bouchées quadruples ...
| 
| 
| 
| 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Le cahier des charges est une paraphrase du sujet. Dans la liste des tâches il semble curieux de ne pas commencer par l'étude des brouilleurs. Avez-vous échangé avec vos encadrants ?Cahier des charges plus précis.
| Tentative d'utilisation de la feuille d'heures, definissez au préalable les lignes dans ce tableau.Un Wiki trop rapidement rédigé en style télégraphique avec des coquilles, à la lecture du Wiki il est difficile de croire que vous avez passé le nombre d'heures annoncées pour si peu de résultats.
| 
| 
| 
| 
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Une simple paraphrase du sujet. Pas de liste des tâches à réaliser. Il semble que vous n'avez pas réussi à échanger avec vos encadrants dans les temps impartis. Des coquilles (corrigées).
| Mauvaise utilisation de la feuille d'heures.Wiki pratiquement vide, l'image n'apporte rien, le Wiki ne reflète que peu de travail.
| 
| 
| 
| 
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Une rencontre avec les encadrants. Un cahier des charges assez précis. Pas de section "tâches à réaliser" mais une section "notre travail" qui pourrait en tenir lieu avec un effort de structuration.
| 
| 
| 
| 
| 
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Présentez les objectifs généraux pour commencer. Un cahier des charges très précis mais il manque la liste des tâches à effectuer. Débutez la par l'état de l'art sur les produits déjà commercialisés.
| 
| 
| 
| 
| 
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Le sujet du projet à été recopié. Les deux sections personnelles sont assez mal rédigées. Un contre-sens sur le mode de connexion du prototype actuel : la veilleuse est configurée en point d'accès. Parlez plutôt de "Précisions sur le cahier des charges" plutôt que de "Problèmes rencontrés sur l'étude du projet". Renommez aussi "Nouveau cahier des charges" en "Tâches à réaliser" et ajouter les autres tâches demandées dans le sujet.Cahier des charges et listes des tâches finalement validés par deux encadrants.
| 
| 
| 
| 
| 
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Uniquement une recopie du sujet.Un cahier des charges et une liste de tâches corrects après discussion avec deux encadrants.
| 
| 
| 
| 
| 
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Un très bon cahier des charges. Le sujet semble être bien assimilé. Une liste des tâches correcte (il faudrait peut-être détailler la programmation du proxy).
| 
| 
| 
| 
| 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Un excellent cahier des charges. Liste des tâches très détaillée. Parfait.
| 
| 
| 
| 
| 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Vous n'avez pas su vous adapter à la syntaxe mediawiki. Correction pour obtenir un CdC lisible. Une recopie intégrale du sujet. Un cahier des charges qui ressemble plus à une liste des tâches à effectuer.Vous utilisez bien la syntaxe mediawiki maintenant. Par contre il n'y a toujours pas de cahier des charges.
| 
| 
| 
| 
| 
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Un cahier des charges en 4 lignes, c'est trop court. En particulier rien sur le contexte du projet à savoir le matériel ou le simulateur sur lequel les tests seront effectués. Une liste des tâches, cette liste est-elle avalisé par l'encadrant ?Toujours pas de cahier des charges.
| 
| 
| 
| 
| 
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (25/01) !! Séance 2 (01/02) !! Séance 3 (08/02) !! Séance 4 (15/02) !! Séance 5 (01/03) !! Séance 6 (08/03) !! Séance 7 !! Séance 8 !! Séance 9 !! Séance 10
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Haroun Abdelali
| 
| Absent
| Absent
| D317 
| D309 
| D309 
| 
| 
| 
| 
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Wenyu sun / Xinyue xu
| E304 Presentes
| C201 Présentes
| C201Présentes
| C201Présentes
| E304&C201
| E304
| 
| 
| 
| 
| 
| 
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Martin Rohmer / Kévin Godesence
| E306 
| E303 Présents
| E301 Présents
| E305
| E303
| E305
| 
| 
| 
| 
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Robin Cavalieri / Edmur Lopes
| E305 
| E305 Présents
| E305Présents
| E305
| E305
| E305
| 
| 
| 
| 
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Cedric Roussel / Thomas Stievenard
| 
| E303 Présents
| Présents
| E305
| E303
| E305
| 
| 
| 
| 
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Mame Arame Diop / Amina Fahem
| 
| E303 Présentes
| E304 Présents
| E304
| E304
| E304
| 
| 
| 
| 
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Antoine Arnaudet / Vivian Senaffe
| E304 
| E305 Arnaudet présent Senaffe absent
| E304
| E304Présents
| E304
| E304
| 
| 
| 
| 
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Butaye Marianne / François Duport
| E304 
| E304 Présents
| E303 Présents
| E305
| E305
| E305
| E305
| 
| 
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Samy Belhouachi / François Xavier Cockenpot
| 
| E305 Présents
| E301 Présents
| E305 
| E303 et E305
| E303 et E305
| 
| 
| 
| 
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Cheikh Said Ahmed / Khadija El Messnaoui
| 
| E305 Said-Ahmed présent El Messnaoui absente
| Présents
| E303 
| E305
| 
| 
| 
| 
| 
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Manlu Luo / Xinyi Wang
| E305 
| E304 Présentes
| E304 Présentes
| E304 
| E304 
| 
| 
| 
| 
| 
| 
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| Olivier Mahieux / Grillère Baptiste
| E306 
| E305 Présents
| Présents
| 
| 
| 
| 
| 
| 
| 
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Rodolphe Toin
| E305 
| E305 Présent
| E305/301 Présents
| E305 
| E305 
| E305 
| 
| 
| 
| 
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| | E304 
| Rattrapage DS
| Abs
| Malade
| Malade
| Malade
| E303
| 
| 
| 
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Thomas Gosse / Bacem Hagui
| 
| E304 Gosse présent Hagui absent
| Présents
| 
| 
| 
| 
| 
| 
| 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Tristan Hart / Etienne Profit
| 
| E304 Présents
| E304Présents
| E304
| E304
| E304
| E304
| 
| 
| 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Nicky Ung / Alexis Macherez
| E304 
| E304 Présents
| E304/301 Présents
| E305
| E304
| 
| 
| 
| 
| 
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Oumaima Naanaa
| 
| Absente
| E301Présente
| E301
| E301
| E306
| 
| 
| 
| 
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Alice Coffin / Diana Marrucho
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Lutecia Damiens / Alexis Dorian
| E306 
| E303 Présents
| E303 Présents
| Fabricarium
| E303
| E306
| E306
| 
| 
| 
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Hugo Delatte
| 
| E304 Présents
| E304 
| E304 Présents
| 
| 
| 
| 
| 
| 
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Loïc Tombazzi / Marius Trimbur
| E304 
| E303 Présents
| E303 Présents
| E304 
| E303 
| E306 
| 
| 
| 
| 
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Marouan Mcharfi / Tristan lopez
| E304 
| E304 Présents
| E304 Présents
| E304 
| E304 
| E304 
| E304 
| 
| 
| 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Alexandre Huet / François Lefevre
| E306
| E306 Présents
| E304 Présents
| 
| 
| 
| 
| 
| 
| 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Djamil Mohamed / Hamza Kerroum
| C305/D306A 
| C305/D306A Présents
| C305/D306A Présents
| C305/D306A 
| C305/D306A 
| C305/D306A
| 
| 
| 
| 
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Jean-Baptiste Saison
| C305/D306A 
| C305/D306A Présent
| D306A Présent
| D306A/C305 
| D306A/D322 
| D306A/D322 
| 
| 
| 
| 
|}

IMA4 2016/2017 P20

2017-03-13T22:43:44Z

Mbutaye : /* Planning des tâches */

IMA4 2016/2017 P20

2017-03-09T06:47:07Z

Mbutaye : /* Semaine 6 */

Fichier:Rviz screenshot machine.png

2017-03-09T06:43:47Z

Mbutaye : Screenshot de l'affichage de l'entité ''BaseStation'' dans RViz (semaine 6) pour le projet P20 de 2016/17.

Screenshot de l'affichage de l'entité ''BaseStation'' dans RViz (semaine 6) pour le projet P20 de 2016/17.

Fichier:Rviz screenshot robot.png

2017-03-09T06:42:58Z

Mbutaye : Screenshot de l'affichage de l'entité ''Robot'' dans RViz (semaine 6) pour le projet P20 de 2016/17.

Screenshot de l'affichage de l'entité ''Robot'' dans RViz (semaine 6) pour le projet P20 de 2016/17.

IMA4 2016/2017 P20

2017-03-09T06:30:35Z

Mbutaye : /* Planning des tâches */

IMA4 2016/2017 P20

2017-03-08T15:09:39Z

Mbutaye : /* Planning des tâches */

Discussion:Projets IMA4 SC & SA 2016/2017

2017-03-08T13:13:03Z

Mbutaye : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Mini-cahier des charges || Mi-parcours || Fin de parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Cahier des charges conforme à la discussion avec l'encadrant. Présentation propre avec un effort d'illustration. Pas de liste des tâches ou de calendrier prévisionnel. Quelques coquilles corrigées.
| 
| 
| 
| 
| 
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Cahier des charges succinct. Attention à la rédaction en français. Un effort d'illustration avec un schéma global. Une liste des tâches, sans chiffrage pour l'instant..
| 
| 
| 
| 
| 
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Cahier des charges assez précis. Pas trop de coquilles. Une liste des tâches un peu succincte. Réfléchissez bien à la structure du programme pour la mise à jour simplifiée des fiches sur l'application.
| 
| 
| 
| 
| 
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Cahier des charges précis. Forme très correcte. Une liste des tâches réfléchie. Il y a même un calendrier prévisionnel.
| 
| 
| 
| 
| 
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Cahier des charges très précis. De même pour la liste des tâches. L'utilisation de bioloïds ne semble pas justifiée. Pourquoi ne parlez-vous de capteurs que dans le cadre d'un seul des deux appareils ?
| 
| 
| 
| 
| 
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Pas mal de coquilles corrigées. Une certaine imprécision (confusion Arduino Mega et ATMEGA, flou dans la liste des tâches). Cela dit un cahier des charges et une liste des tâches sont présentés. Pensez aux problèmes de calibration du système et à la transmission des données vers un smartphone par exemple.
| 
| 
| 
| 
| 
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Synthèse correcte de l'entretien avec l'encadrant. Le cahier des charges est correct mais moins précis que le sujet. Le découpage en tâche est un peu rapide : l'analyse des fichiers MIDI devrait être sous-découpée. Presque pas de coquilles.
| 
| 
| 
| 
| 
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Très bonne prise en main du sujet. Cahier des charges très précis. Liste des tâches bien détaillée. Orthographe irréprochable.
| 
| 
| 
| 
| 
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Une grande partie du cahier des charges est une copie du sujet. Définissez ce qu'est une Referee Box. D'un autre coté, le cahier des charges est précis. La liste des tâches est correcte. Cependant elle semble omettre la partie mécanique de la MPS ? Pas de coquilles.
| 
| 
| 
| 
| 
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Des imprécisions dans la transcription de la réunion avec l'encadrant. Voire des contre-sens. Le cahier des charges est assez complet. Pas de liste des tâches. Vous avez vraiment passé 3h sur la rédaction du cahier des charges ? (edit d'Alex : certainement pas)Une liste des tâches ajoutée.
| 
| 
| 
| 
| 
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Le texte a été modifié pour être compréhensible mais le problème n'est pas là. Vous n'avez pas du tout transcrit les demandes de l'encadrant mais donné le sujet du projet de l'an passé. Cette année vous devez améliorer l'aspect esthétique des robots, construire le quatrième robot et améliorer la détection infra-rouge en utilisant le protocole utilisé par les télécommandes infra-rouges classiques. Vous n'avez pas, non plus, donné une liste précise des tâches à réaliser.Cahier des charges révisé avec l'encadrant. La listes des tâches à réaliser est à préciser.
| 
| 
| 
| 
| 
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| La restitution de la discussion avec l'encadrant est très correcte et le cahier des charge est précisément décrit. Par contre la liste des tâches à effectuer n'est pas dressée en commençant par l'étude des conditions à respecter pour lancer un tel ballon.
| 
| 
| 
| 
| 
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Assimilation très correcte des demandes faites par les encadrants. Un cahier des charges précis. De même pour la liste des tâches. Un effort de présentation sans trop de coquilles. Cependant quelques erreurs relevées par M. Dhaussy, merci de corriger le CdC au vu des remarques transmises.
| 
| 
| 
| 
| 
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| Le cahier des charges est une recopie du sujet, avec des passages soulignés, certes. Une liste des tâches très précise mais uniquement orientée développement Web. Il manque toute la partie étude et utilisation des éco-systèmes d'isolation.Cahier des charges plus précis, vous pouvez vous lancer.
| 
| 
| 
| 
| 
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Cahier des charges très précis avec déjà des idées pour la réalisation. Liste des tâches à effectuer très détaillée.
| 
| 
| 
| 
| 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Très peu d'apport par rapport au sujet qui est lui même assez bref. Il ne semble pas y avoir eu de rencontre avec l'encadrant dans les temps impartis ? Pas de liste des tâches. Cahier des charges révisés sous la direction de deux encadrants.
| 
| 
| 
| 
| 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Le cahier des charges est une paraphrase du sujet. Dans la liste des tâches il semble curieux de ne pas commencer par l'étude des brouilleurs. Avez-vous échangé avec vos encadrants ?Cahier des charges plus précis.
| 
| 
| 
| 
| 
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Une simple paraphrase du sujet. Pas de liste des tâches à réaliser. Il semble que vous n'avez pas réussi à échanger avec vos encadrants dans les temps impartis. Des coquilles (corrigées).
| 
| 
| 
| 
| 
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Une rencontre avec les encadrants. Un cahier des charges assez précis. Pas de section "tâches à réaliser" mais une section "notre travail" qui pourrait en tenir lieu avec un effort de structuration.
| 
| 
| 
| 
| 
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Présentez les objectifs généraux pour commencer. Un cahier des charges très précis mais il manque la liste des tâches à effectuer. Débutez la par l'état de l'art sur les produits déjà commercialisés.
| 
| 
| 
| 
| 
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Le sujet du projet à été recopié. Les deux sections personnelles sont assez mal rédigées. Un contre-sens sur le mode de connexion du prototype actuel : la veilleuse est configurée en point d'accès. Parlez plutôt de "Précisions sur le cahier des charges" plutôt que de "Problèmes rencontrés sur l'étude du projet". Renommez aussi "Nouveau cahier des charges" en "Tâches à réaliser" et ajouter les autres tâches demandées dans le sujet.Cahier des charges et listes des tâches finalement validés par deux encadrants.
| 
| 
| 
| 
| 
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Uniquement une recopie du sujet.Un cahier des charges et une liste de tâches corrects après discussion avec deux encadrants.
| 
| 
| 
| 
| 
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Un très bon cahier des charges. Le sujet semble être bien assimilé. Une liste des tâches correcte (il faudrait peut-être détailler la programmation du proxy).
| 
| 
| 
| 
| 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Un excellent cahier des charges. Liste des tâches très détaillée. Parfait.
| 
| 
| 
| 
| 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Vous n'avez pas su vous adapter à la syntaxe mediawiki. Correction pour obtenir un CdC lisible. Une recopie intégrale du sujet. Un cahier des charges qui ressemble plus à une liste des tâches à effectuer.Vous utilisez bien la syntaxe mediawiki maintenant. Par contre il n'y a toujours pas de cahier des charges.
| 
| 
| 
| 
| 
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Un cahier des charges en 4 lignes, c'est trop court. En particulier rien sur le contexte du projet à savoir le matériel ou le simulateur sur lequel les tests seront effectués. Une liste des tâches, cette liste est-elle avalisé par l'encadrant ?Toujours pas de cahier des charges.
| 
| 
| 
| 
| 
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (25/01) !! Séance 2 (01/02) !! Séance 3 !! Séance 4 !! Séance 5 !! Séance 6 !! Séance 7 !! Séance 8 !! Séance 9 !! Séance 10
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Haroun Abdelali
| 
| Absent
| Absent
| D317 
| D309 
| 
| 
| 
| 
| 
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Wenyu sun / Xinyue xu
| E304 Presentes
| C201 Présentes
| C201Présentes
| C201Présentes
| E304&C201
| E304
| 
| 
| 
| 
| 
| 
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Martin Rohmer / Kévin Godesence
| E306 
| E303 Présents
| E301 Présents
| E305
| E303
| 
| 
| 
| 
| 
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Robin Cavalieri / Edmur Lopes
| E305 
| E305 Présents
| E305Présents
| E305
| E305
| E305
| 
| 
| 
| 
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Cedric Roussel / Thomas Stievenard
| 
| E303 Présents
| Présents
| E305
| E303
| 
| 
| 
| 
| 
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Mame Arame Diop / Amina Fahem
| 
| E303 Présentes
| E304 Présents
| E304
| E304
| E304
| 
| 
| 
| 
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Antoine Arnaudet / Vivian Senaffe
| E304 
| E305 Arnaudet présent Senaffe absent
| E304
| E304Présents
| E304
| E304
| 
| 
| 
| 
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Butaye Marianne / François Duport
| E304 
| E304 Présents
| E303 Présents
| E305
| E305
| E305
| 
| 
| 
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Samy Belhouachi / François Xavier Cockenpot
| 
| E305 Présents
| E301 Présents
| E305 
| E303 et E305
| 
| 
| 
| 
| 
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Cheikh Said Ahmed / Khadija El Messnaoui
| 
| E305 Said-Ahmed présent El Messnaoui absente
| Présents
| E303 
| E305
| 
| 
| 
| 
| 
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Manlu Luo / Xinyi Wang
| E305 
| E304 Présentes
| E304 Présentes
| E304 
| E304 
| 
| 
| 
| 
| 
| 
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| Olivier Mahieux / Grillère Baptiste
| E306 
| E305 Présents
| Présents
| 
| 
| 
| 
| 
| 
| 
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Rodolphe Toin
| E305 
| E305 Présent
| E305/301 Présents
| E305 
| E305 
| 
| 
| 
| 
| 
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| | E304 
| Rattrapage DS
| Abs (malade, mail)
| Malade
| Malade
| E301
| 
| 
| 
| 
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Thomas Gosse / Bacem Hagui
| 
| E304 Gosse présent Hagui absent
| Présents
| 
| 
| 
| 
| 
| 
| 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Tristan Hart / Etienne Profit
| 
| E304 Présents
| Présents
| 
| 
| 
| 
| 
| 
| 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Nicky Ung / Alexis Macherez
| E304 
| E304 Présents
| E304/301 Présents
| E305
| E304
| 
| 
| 
| 
| 
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Oumaima Naanaa
| 
| Absente
| E301Présente
| E301
| E301
| 
| 
| 
| 
| 
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Alice Coffin / Diana Marrucho
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Lutecia Damiens / Alexis Dorian
| E306 
| E303 Présents
| E303 Présents
| Fabricarium
| E303
| 
| 
| 
| 
| 
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Hugo Delatte
| 
| E304 Présents
| E304 
| E304 Présents
| 
| 
| 
| 
| 
| 
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Loïc Tombazzi / Marius Trimbur
| E304 
| E303 Présents
| E303 Présents
| E304 
| E303
| 
| 
| 
| 
| 
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Marouan Mcharfi / Tristan lopez
| E304 
| E304 Présents
| E304 Présents
| E304 
| E304
| 
| 
| 
| 
| 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Alexandre Huet / François Lefevre
| E306
| E306 Présents
| E304 Présents
| 
| 
| 
| 
| 
| 
| 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Djamil Mohamed / Hamza Kerroum
| C305/D306A 
| C305/D306A Présents
| C305/D306A Présents
| C305/D306A 
| C305/D306A 
| 
| 
| 
| 
| 
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Jean-Baptiste Saison
| C305/D306A 
| C305/D306A Présent
| D306A Présent
| D306A/C305 
| D306A/D322 
| 
| 
| 
| 
| 
|}

IMA4 2016/2017 P20

2017-03-07T06:29:09Z

Mbutaye : /* Semaine 5 */

IMA4 2016/2017 P20

2017-03-07T06:26:18Z

Mbutaye : /* Semaine 5 */

IMA4 2016/2017 P20

2017-03-07T06:23:03Z

Mbutaye : /* Feuille d'heures */

IMA4 2016/2017 P20

2017-03-02T09:45:38Z

Mbutaye : /* Semaine 5 */