IMA4 2016/2017 P20 - Historique des versions

Rex : /* Heures supplémentaires */

2017-06-16T08:34:58Z

‎Heures supplémentaires

Rex : /* Heures supplémentaires */

2017-06-16T08:34:36Z

‎Heures supplémentaires

Fduport : /* Fichiers Rendus */

2017-05-11T07:50:22Z

‎Fichiers Rendus

Fduport : /* Description du projet */

2017-05-10T20:46:13Z

‎Description du projet

Fduport : /* Description du projet */

2017-05-10T20:42:16Z

‎Description du projet

Mbutaye : /* Description du projet */

2017-05-10T11:23:32Z

‎Description du projet

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

2017-05-10T11:23:00Z

‎Liste des tâches à effectuer

Mbutaye : /* Semaine 10 */

2017-05-09T22:01:00Z

‎Semaine 10

Mbutaye : /* Heures supplémentaires */

2017-05-09T21:56:25Z

‎Heures supplémentaires

Mbutaye : /* Planning des tâches */

2017-05-09T21:34:26Z

‎Planning des tâches

@@ Ligne 550 : / Ligne 550 : @@
 Fichier:Rviz_screenshot_machine_state_busy.png|Machine occupée
 Fichier:Rviz_screenshot_machine_state_ok.png|Machine disponible
-Media:Feu_clignotant.mp4|Vidéo du feu qui clignote
+Fichier:Feu_clignotant.mp4|Vidéo du feu qui clignote
 </gallery>

@@ Ligne 550 : / Ligne 550 : @@
 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
+Media:Feu_clignotant.mp4|Vidéo du feu qui clignote
 </gallery>

← Version précédente		Version du 11 mai 2017 à 07:50
Ligne 566 :		Ligne 566 :

	== Fichiers Rendus ==		== Fichiers Rendus ==
		+	[[Média:Rapportprojet_BUTAYE_DUPORT.pdf]]

@@ Ligne 33 : / Ligne 33 : @@
 [[Fichier:Schema_compet.PNG|300px|thumb|center|En Rouge les communications propres à l'équipe (entre les robots), En vert les communications avec l'arbitre]]
 [[Fichier:Schemasimu.PNG|300px|thumb|center|Tout est sur un ordinateur. On remarque que le code de l'ARPL n'est plus dans les robots mais a l’extérieur et se connecte avec l'environnement simulé]]
 ====Choix techniques : matériel et logiciel====

← Version précédente		Version du 10 mai 2017 à 20:42
Ligne 29 :		Ligne 29 :

	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.		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.
		+
		+	Nous avons fait deux schéma simple pour expliquer ce que fait le simulateur par rapport à la réalité.
		+	[[Fichier:Schema_compet.PNG\|300px\|thumb\|center\|En Rouge les communications propres à l'équipe (entre les robots), En vert les communications avec l'arbitre]]
		+	[[Fichier:Schemasimu.PNG\|300px\|thumb\|center\|Tout est sur un ordinateur. On remarque que le code de l'ARPL n'est plus dans les robots mais a l’extérieur et se connecte avec l'environnement simulé]]

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

@@ Ligne 24 : / Ligne 24 : @@
 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.
+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.

@@ Ligne 59 : / Ligne 59 : @@
 *Paramétrage avancé de la simulation
 ** proposer différents modes de simulations ;
-** activation/déssactivation des paramètres de la simulation ;
+** activation/désactivation des paramètres de la simulation ;
 ** gestion des phases.

@@ Ligne 506 : / Ligne 506 : @@
 ===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.
+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.
+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.
+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.
+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.
-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.
+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.
-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.
+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.
 ===Heures supplémentaires===

@@ Ligne 239 : / Ligne 239 : @@
 | Communication RefBox
 | 01/04/2017
-| <font style="color: orange;">Débuté</font>
+| <font style="color: orange;">Inachevé</font>
 | Communication en place pour l'affichage des machines à leur position de départ.
 |-