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

Réseau de lampes

2016-01-20T13:53:01Z

Shage-ch : /* Séance 3 */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====
Dans le cadre du module transversal "Internet des Objets", nous avons choisi de travailler sur un réseau de lampes connectés. En effet, dans un contexte économique et écologique, il est primordial d'avoir un contrôle à distance des lumières domestiques, lorsqu'il y a absence de personnes.
====Objectif du projet====
L'objectif principal du projet est d'avoir un système capable d'allumer, d'éteindre et de visualiser les états des lumières via un navigateur tout en se basant sur la présence ou non des personnes dans les pièces.
====Description du projet====
Le réseau de lumière peut, par exemple, être utilisé dans une maison. Dans chaque pièce on a un capteur et une lumière.
====Choix techniques : matériel et logiciel====
* Raspberry Pi
* OpenMote Base / OpenMote Battery / OpenMote cc2538
* Contiki : OS pour les capteurs miniatures en réseau.

==Étapes du projet==

===Partie 1===
*Installation de Contiki, RIOT ou tout autre OS sur les OpenMote permettant la communication entre elles.

===Partie 2===
*Communication Rx/Tx entre la RaspberryPI et un OpenMote.
*Réception de l'état d'un capteur de présence connecté à un OpenMote et extinction/allumage d'une LED de l'OpenMote (via traitement sur la RaspberryPI) en fonction de l'état du capteur.

===Partie 3===
*Installation d'un serveur Apache sur la RaspberryPI pour la gestion des lumières via un interface web (sur un smartphone, ordinateur ou autre).
*Mise en réseau et routage des OpenMote pour permettre la communication relai entre eux. Cela permettra la communication entre la RaspberryPI (connectée à la box) et n'importe quel OpenMote indépendamment de sa distance.

==Suivi de l'avancement du Projet==

===Séance 1 ===
Nous avons d'abord réalisé des tests préliminaires sur un OpenMote afin de nous familiariser avec par exemple l'allumage/extinction d'une LED. 
Les OpenMote sont livrées avec un OS pré-installé : [http://www.freertos.org/ FreeRTOS]. 
Nous avons donc suivi un [http://www.openmote.com/blog/bootstrapping-the-openmote-platform.html tutoriel de Bootstrapping]. 

On installe toutes les librairies ARM Cortex nécessaires au bon fonctionnement du chip embarqué sur l'OpenMote :
wget http://mirrors.kernel.org/ubuntu/pool/universe/libs/libstdc++-arm-none-eabi/libstdc++-arm-none-eabi-newlib_4.8.3-11ubuntu1+4_all.deb sudo dpkg -i libstdc++-arm-none-eabi-newlib_4.8.3-11ubuntu1+4_all.deb

On copie ensuite le firmware de l'OpenMote :
git clone --recursive https://github.com/OpenMote/firmware.git OpenMote/firmware

Avant de passer à la suite, il convient d'effectuer quelques manipulations non explicitées sur le tutoriel, mais pourtant indispensables : (Merci à T. Vantroys pour [http://vantroys.polytech-lille.net/mediawiki/index.php?title=OpenMote ces manipulations])
cd OpenMote/firmware/platform/cc2538/libcc2538
make
cp libcc2538 ..
cd ../../../test // répertoire OpenMote/firmware/test
chmod u+x tests-projetcts.sh
./tests-projects.sh

On se place dans le dossier projects :
cd ../projects // répertoire OpenMote/firmware/projects

Ce dossier contient de nombreux projets déjà écrits qu'il suffit de tester. On va dans notre cas tester les LED. Plaçons nous alors dans le dossier correspondant :
cd test-leds/src

Puis compilons !
make TARGET=cc2538 all BOARD=openmote-cc2538 all

La compilation faite, il faut maintenant flasher le programme sur l'OpenMote :
make TARGET=cc2538 all BOARD=openmote-cc2538 bsl

On remarque que le programme tourne bien (les LED flashent). 
'''/!\ Attention /!\ :''' Sur les OpenMote (contrairement à un Arduino par exemple) il est impossible de flasher de nouveau un programme si le programme courant tourne ! En pressant le bouton '''USER''' nous pouvons de nouveau flasher un programme.

===Séance 2 ===
====Compilation du premier programme sous Contiki====
Cette séance est consacrée à l'installation de [http://www.contiki-os.org/ Contiki]. Contiki est un OS Open-Source, consacré à l'Internet des Objets, c'est pourquoi nous souhaitons l'utiliser ! 
Nous avons souhaité suivre [http://www.openmote.com/blog/getting-started-with-contiki-and-openmote.html ce tutoriel]. 

[[Fichier:Contiki-Setup.jpg|400px|Crédit : http://www.openmote.com/]] 

Il faut posséder un [https://github.com/ compte github]. Ensuite, il faut forker [http://www.openmote.com/ftp/wp-content/uploads/2014/05/Fork-Contiki.png ce répertoire] (tout en étant connecté à notre compte).
[[Fichier:Fork-Contiki.png|700px|Crédit : http://www.openmote.com/]] 

Ensuite dans le terminal, nous clonons ce répertoire :
git clone https://github.com/USERNAME/contiki.git ~/Contiki

Si l'utilisateur souhaite contribuer à Contiki, il peut également ajouter le dépôt origine de Contiki comme une branche de suivi dans git. On taperait donc :
git remote add upstream https://github.com/contiki-os/contiki.git
git fetch origin -v
git fetch upstream -v
git merge upstream/master

Maintenant que nous avons le code source Contiki sur l'ordinateur, il est temps de le compiler. Nous commençons avec un projet simple "Hello World". Nous entrons les commandes suivantes :
cd ~/Contiki/examples/hello-world
make TARGET=cc2538dk hello-world

La compilation se fait : 
[[Fichier:Compile-Contiki.png|500px|Crédit : http://www.openmote.com/]] 

Une fois la compilation terminée, on a l'écran suivant : 
[[Fichier:Compiled-Contiki.png|500px|Crédit : http://www.openmote.com/]] 

La suite du tutoriel utilise un J-Tag pour flasher Contiki sur l'OpenMote. Nous n'avons malheureusement pas de J-Tag, donc nous allons flasher l'application exactement comme nous l'avions fait avec les tests préliminaires de la séance 1. 

====Flash de l'application====
On se place dans '''[Modification en cours]'''

===Séance 3 ===

* Nous avons décidé de changer de matériel puisque nous n'avons pas réussi de flasher notre programme sur Contiki de notre OpenMote., nous avons donc décidé d'utilser la RaspberryPI uniquement.
* Adresse IP de la RaspberryPI lors des séances de projet :
172.26.79.239
* Nous avons installé un serveur Apache sur la RaspberryPI.

===Séance 4 ===
[Notes] 
Connexion ESP en USB (via FTDI) 
Sequence boutons (GPIO & RESET) 
Code test
#define ESP8266_LED 2
void setup()
{
pinMode(ESP8266_LED, OUTPUT);
}
void loop()
{
digitalWrite(ESP8266_LED, HIGH);
delay(500);
digitalWrite(ESP8266_LED, LOW);
delay(500);
}
Interaction Wi-Fi via un smartphone: 
https://learn.adafruit.com/adafruit-io-basics-digital-input/adafruit-io-setup 

===Séance 5 ===

* Pour l'alimentation de notre ESP8266 nous avons utilisé un arduino ( 3,3V ). Alimentation onéreuse mais qui fonctionne.
* Nous avons décidé de représenter notre "lampe" par une led. Nous l'avons donc connectée au Gpio14 de l'ESP
( /!\ Remarque : Gpio15 ne peut pas être utiliser pour brancher la led sur l'ESP )
* Nous avons réussi à connecté la carte au wifi de notre portable.

Réseau de lampes

2016-01-20T13:49:28Z

Shage-ch : /* Séance 5 */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====
Dans le cadre du module transversal "Internet des Objets", nous avons choisi de travailler sur un réseau de lampes connectés. En effet, dans un contexte économique et écologique, il est primordial d'avoir un contrôle à distance des lumières domestiques, lorsqu'il y a absence de personnes.
====Objectif du projet====
L'objectif principal du projet est d'avoir un système capable d'allumer, d'éteindre et de visualiser les états des lumières via un navigateur tout en se basant sur la présence ou non des personnes dans les pièces.
====Description du projet====
Le réseau de lumière peut, par exemple, être utilisé dans une maison. Dans chaque pièce on a un capteur et une lumière.
====Choix techniques : matériel et logiciel====
* Raspberry Pi
* OpenMote Base / OpenMote Battery / OpenMote cc2538
* Contiki : OS pour les capteurs miniatures en réseau.

==Étapes du projet==

===Partie 1===
*Installation de Contiki, RIOT ou tout autre OS sur les OpenMote permettant la communication entre elles.

===Partie 2===
*Communication Rx/Tx entre la RaspberryPI et un OpenMote.
*Réception de l'état d'un capteur de présence connecté à un OpenMote et extinction/allumage d'une LED de l'OpenMote (via traitement sur la RaspberryPI) en fonction de l'état du capteur.

===Partie 3===
*Installation d'un serveur Apache sur la RaspberryPI pour la gestion des lumières via un interface web (sur un smartphone, ordinateur ou autre).
*Mise en réseau et routage des OpenMote pour permettre la communication relai entre eux. Cela permettra la communication entre la RaspberryPI (connectée à la box) et n'importe quel OpenMote indépendamment de sa distance.

==Suivi de l'avancement du Projet==

===Séance 1 ===
Nous avons d'abord réalisé des tests préliminaires sur un OpenMote afin de nous familiariser avec par exemple l'allumage/extinction d'une LED. 
Les OpenMote sont livrées avec un OS pré-installé : [http://www.freertos.org/ FreeRTOS]. 
Nous avons donc suivi un [http://www.openmote.com/blog/bootstrapping-the-openmote-platform.html tutoriel de Bootstrapping]. 

On installe toutes les librairies ARM Cortex nécessaires au bon fonctionnement du chip embarqué sur l'OpenMote :
wget http://mirrors.kernel.org/ubuntu/pool/universe/libs/libstdc++-arm-none-eabi/libstdc++-arm-none-eabi-newlib_4.8.3-11ubuntu1+4_all.deb sudo dpkg -i libstdc++-arm-none-eabi-newlib_4.8.3-11ubuntu1+4_all.deb

On copie ensuite le firmware de l'OpenMote :
git clone --recursive https://github.com/OpenMote/firmware.git OpenMote/firmware

Avant de passer à la suite, il convient d'effectuer quelques manipulations non explicitées sur le tutoriel, mais pourtant indispensables : (Merci à T. Vantroys pour [http://vantroys.polytech-lille.net/mediawiki/index.php?title=OpenMote ces manipulations])
cd OpenMote/firmware/platform/cc2538/libcc2538
make
cp libcc2538 ..
cd ../../../test // répertoire OpenMote/firmware/test
chmod u+x tests-projetcts.sh
./tests-projects.sh

On se place dans le dossier projects :
cd ../projects // répertoire OpenMote/firmware/projects

Ce dossier contient de nombreux projets déjà écrits qu'il suffit de tester. On va dans notre cas tester les LED. Plaçons nous alors dans le dossier correspondant :
cd test-leds/src

Puis compilons !
make TARGET=cc2538 all BOARD=openmote-cc2538 all

La compilation faite, il faut maintenant flasher le programme sur l'OpenMote :
make TARGET=cc2538 all BOARD=openmote-cc2538 bsl

On remarque que le programme tourne bien (les LED flashent). 
'''/!\ Attention /!\ :''' Sur les OpenMote (contrairement à un Arduino par exemple) il est impossible de flasher de nouveau un programme si le programme courant tourne ! En pressant le bouton '''USER''' nous pouvons de nouveau flasher un programme.

===Séance 2 ===
====Compilation du premier programme sous Contiki====
Cette séance est consacrée à l'installation de [http://www.contiki-os.org/ Contiki]. Contiki est un OS Open-Source, consacré à l'Internet des Objets, c'est pourquoi nous souhaitons l'utiliser ! 
Nous avons souhaité suivre [http://www.openmote.com/blog/getting-started-with-contiki-and-openmote.html ce tutoriel]. 

[[Fichier:Contiki-Setup.jpg|400px|Crédit : http://www.openmote.com/]] 

Il faut posséder un [https://github.com/ compte github]. Ensuite, il faut forker [http://www.openmote.com/ftp/wp-content/uploads/2014/05/Fork-Contiki.png ce répertoire] (tout en étant connecté à notre compte).
[[Fichier:Fork-Contiki.png|700px|Crédit : http://www.openmote.com/]] 

Ensuite dans le terminal, nous clonons ce répertoire :
git clone https://github.com/USERNAME/contiki.git ~/Contiki

Si l'utilisateur souhaite contribuer à Contiki, il peut également ajouter le dépôt origine de Contiki comme une branche de suivi dans git. On taperait donc :
git remote add upstream https://github.com/contiki-os/contiki.git
git fetch origin -v
git fetch upstream -v
git merge upstream/master

Maintenant que nous avons le code source Contiki sur l'ordinateur, il est temps de le compiler. Nous commençons avec un projet simple "Hello World". Nous entrons les commandes suivantes :
cd ~/Contiki/examples/hello-world
make TARGET=cc2538dk hello-world

La compilation se fait : 
[[Fichier:Compile-Contiki.png|500px|Crédit : http://www.openmote.com/]] 

Une fois la compilation terminée, on a l'écran suivant : 
[[Fichier:Compiled-Contiki.png|500px|Crédit : http://www.openmote.com/]] 

La suite du tutoriel utilise un J-Tag pour flasher Contiki sur l'OpenMote. Nous n'avons malheureusement pas de J-Tag, donc nous allons flasher l'application exactement comme nous l'avions fait avec les tests préliminaires de la séance 1. 

====Flash de l'application====
On se place dans '''[Modification en cours]'''

===Séance 3 ===
Adresse IP de la RaspberryPI lors des séances de projet :

172.26.79.239
===Séance 4 ===
[Notes] 
Connexion ESP en USB (via FTDI) 
Sequence boutons (GPIO & RESET) 
Code test
#define ESP8266_LED 2
void setup()
{
pinMode(ESP8266_LED, OUTPUT);
}
void loop()
{
digitalWrite(ESP8266_LED, HIGH);
delay(500);
digitalWrite(ESP8266_LED, LOW);
delay(500);
}
Interaction Wi-Fi via un smartphone: 
https://learn.adafruit.com/adafruit-io-basics-digital-input/adafruit-io-setup 

===Séance 5 ===

* Pour l'alimentation de notre ESP8266 nous avons utilisé un arduino ( 3,3V ). Alimentation onéreuse mais qui fonctionne.
* Nous avons décidé de représenter notre "lampe" par une led. Nous l'avons donc connectée au Gpio14 de l'ESP
( /!\ Remarque : Gpio15 ne peut pas être utiliser pour brancher la led sur l'ESP )
* Nous avons réussi à connecté la carte au wifi de notre portable.

Réseau de lampes

2016-01-20T10:06:33Z

Shage-ch : /* Séance 5 */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====
Dans le cadre du module transversal "Internet des Objets", nous avons choisi de travailler sur un réseau de lampes connectés. En effet, dans un contexte économique et écologique, il est primordial d'avoir un contrôle à distance des lumières domestiques, lorsqu'il y a absence de personnes.
====Objectif du projet====
L'objectif principal du projet est d'avoir un système capable d'allumer, d'éteindre et de visualiser les états des lumières via un navigateur tout en se basant sur la présence ou non des personnes dans les pièces.
====Description du projet====
Le réseau de lumière peut, par exemple, être utilisé dans une maison. Dans chaque pièce on a un capteur et une lumière.
====Choix techniques : matériel et logiciel====
* Raspberry Pi
* OpenMote Base / OpenMote Battery / OpenMote cc2538
* Contiki : OS pour les capteurs miniatures en réseau.

==Étapes du projet==

===Partie 1===
*Installation de Contiki, RIOT ou tout autre OS sur les OpenMote permettant la communication entre elles.

===Partie 2===
*Communication Rx/Tx entre la RaspberryPI et un OpenMote.
*Réception de l'état d'un capteur de présence connecté à un OpenMote et extinction/allumage d'une LED de l'OpenMote (via traitement sur la RaspberryPI) en fonction de l'état du capteur.

===Partie 3===
*Installation d'un serveur Apache sur la RaspberryPI pour la gestion des lumières via un interface web (sur un smartphone, ordinateur ou autre).
*Mise en réseau et routage des OpenMote pour permettre la communication relai entre eux. Cela permettra la communication entre la RaspberryPI (connectée à la box) et n'importe quel OpenMote indépendamment de sa distance.

==Suivi de l'avancement du Projet==

===Séance 1 ===
Nous avons d'abord réalisé des tests préliminaires sur un OpenMote afin de nous familiariser avec par exemple l'allumage/extinction d'une LED. 
Les OpenMote sont livrées avec un OS pré-installé : [http://www.freertos.org/ FreeRTOS]. 
Nous avons donc suivi un [http://www.openmote.com/blog/bootstrapping-the-openmote-platform.html tutoriel de Bootstrapping]. 

On installe toutes les librairies ARM Cortex nécessaires au bon fonctionnement du chip embarqué sur l'OpenMote :
wget http://mirrors.kernel.org/ubuntu/pool/universe/libs/libstdc++-arm-none-eabi/libstdc++-arm-none-eabi-newlib_4.8.3-11ubuntu1+4_all.deb sudo dpkg -i libstdc++-arm-none-eabi-newlib_4.8.3-11ubuntu1+4_all.deb

On copie ensuite le firmware de l'OpenMote :
git clone --recursive https://github.com/OpenMote/firmware.git OpenMote/firmware

Avant de passer à la suite, il convient d'effectuer quelques manipulations non explicitées sur le tutoriel, mais pourtant indispensables : (Merci à T. Vantroys pour [http://vantroys.polytech-lille.net/mediawiki/index.php?title=OpenMote ces manipulations])
cd OpenMote/firmware/platform/cc2538/libcc2538
make
cp libcc2538 ..
cd ../../../test // répertoire OpenMote/firmware/test
chmod u+x tests-projetcts.sh
./tests-projects.sh

On se place dans le dossier projects :
cd ../projects // répertoire OpenMote/firmware/projects

Ce dossier contient de nombreux projets déjà écrits qu'il suffit de tester. On va dans notre cas tester les LED. Plaçons nous alors dans le dossier correspondant :
cd test-leds/src

Puis compilons !
make TARGET=cc2538 all BOARD=openmote-cc2538 all

La compilation faite, il faut maintenant flasher le programme sur l'OpenMote :
make TARGET=cc2538 all BOARD=openmote-cc2538 bsl

On remarque que le programme tourne bien (les LED flashent). 
'''/!\ Attention /!\ :''' Sur les OpenMote (contrairement à un Arduino par exemple) il est impossible de flasher de nouveau un programme si le programme courant tourne ! En pressant le bouton '''USER''' nous pouvons de nouveau flasher un programme.

===Séance 2 ===
====Compilation du premier programme sous Contiki====
Cette séance est consacrée à l'installation de [http://www.contiki-os.org/ Contiki]. Contiki est un OS Open-Source, consacré à l'Internet des Objets, c'est pourquoi nous souhaitons l'utiliser ! 
Nous avons souhaité suivre [http://www.openmote.com/blog/getting-started-with-contiki-and-openmote.html ce tutoriel]. 

[[Fichier:Contiki-Setup.jpg|400px|Crédit : http://www.openmote.com/]] 

Il faut posséder un [https://github.com/ compte github]. Ensuite, il faut forker [http://www.openmote.com/ftp/wp-content/uploads/2014/05/Fork-Contiki.png ce répertoire] (tout en étant connecté à notre compte).
[[Fichier:Fork-Contiki.png|700px|Crédit : http://www.openmote.com/]] 

Ensuite dans le terminal, nous clonons ce répertoire :
git clone https://github.com/USERNAME/contiki.git ~/Contiki

Si l'utilisateur souhaite contribuer à Contiki, il peut également ajouter le dépôt origine de Contiki comme une branche de suivi dans git. On taperait donc :
git remote add upstream https://github.com/contiki-os/contiki.git
git fetch origin -v
git fetch upstream -v
git merge upstream/master

Maintenant que nous avons le code source Contiki sur l'ordinateur, il est temps de le compiler. Nous commençons avec un projet simple "Hello World". Nous entrons les commandes suivantes :
cd ~/Contiki/examples/hello-world
make TARGET=cc2538dk hello-world

La compilation se fait : 
[[Fichier:Compile-Contiki.png|500px|Crédit : http://www.openmote.com/]] 

Une fois la compilation terminée, on a l'écran suivant : 
[[Fichier:Compiled-Contiki.png|500px|Crédit : http://www.openmote.com/]] 

La suite du tutoriel utilise un J-Tag pour flasher Contiki sur l'OpenMote. Nous n'avons malheureusement pas de J-Tag, donc nous allons flasher l'application exactement comme nous l'avions fait avec les tests préliminaires de la séance 1. 

====Flash de l'application====
On se place dans '''[Modification en cours]'''

===Séance 3 ===
Adresse IP de la RaspberryPI lors des séances de projet :

172.26.79.239
===Séance 4 ===
[Notes] 
Connexion ESP en USB (via FTDI) 
Sequence boutons (GPIO & RESET) 
Code test
#define ESP8266_LED 2
void setup()
{
pinMode(ESP8266_LED, OUTPUT);
}
void loop()
{
digitalWrite(ESP8266_LED, HIGH);
delay(500);
digitalWrite(ESP8266_LED, LOW);
delay(500);
}
Interaction Wi-Fi via un smartphone: 
https://learn.adafruit.com/adafruit-io-basics-digital-input/adafruit-io-setup 

===Séance 5 ===

Gpio15 ne peut pas être utiliser pour brancher la led sur l'ESP. Nous l'avons donc branché sur le Gpio14

Réseau de lampes

2016-01-13T10:25:27Z

Shage-ch : /* Choix techniques : matériel et logiciel */

Réseau de lampes

2016-01-13T10:25:06Z

Shage-ch : /* Choix techniques : matériel et logiciel */

Réseau de lampes

2016-01-13T10:22:38Z

Shage-ch : /* Cahier des charges */

Réseau de lampes

2016-01-13T10:20:56Z

Shage-ch : /* Cahier des charges */

Cahier groupe n°2

2015-12-03T11:03:41Z

Shage-ch : /* Suivi de l'avancement du TP */

== Cahier des charges de la tâche particulière ==
=== Présentation de la tâche particulière ===
La tâche particulière que nous devons effectuer lors de ce projet est la configuration d'un des deux routeurs nécessaires à l'établissement d'un réseau redondant.

=== Matériel utilisé pour la tâche particulière ===
- Routeur 3560E

== Suivi de l'avancement du TP ==
=== Semaine 1 (01/10/2015) ===
En collaboration avec le groupe n°1 :

- Établissement d'un tableau regroupant les informations nécessaires au routage.

- Attribution des adresses IPv4 pour chaque VLAN, l'interconnexion des réseaux ainsi que les machines virtuelles.

=== Semaine 2 (08/10/2015) ===
Configuration du routeur de la salle E304 en IPv4 :

* Configuration des VLAN :

- VLAN 11 à 20 pour chaque binôme IMA5 SC.

- VLAN 110 pour les machines virtuelles des binômes.

- VLAN 130 pour l'interconnexion avec le routeur de l'école.

* Configuration entre le routeur et le commutateur de la salle E304.

* Configuration avec le commutateur de la salle E306.

* Configuration avec le routeur de l'école.

* Réalisation de la redondance entre les deux routeurs en IPv4.

=== Semaine 3 (15/10/2015) ===
* Configuration du routeur de la salle E304 en IPv6.

* Réalisation de la redondance entre les deux routeurs en IPv6.

* Nous avons choisi le nom de domaine : tissothage.lol

* Nous avons créé notre machine virtuelle sur le dom0 cordouan.insecserv.deule.net :

ssh root@cordouan.insecserv.deule.net

xen-create-image --hostname=PANACHE --dist=jessie --dir=/usr/local/xen --gateway=193.48.57.174 --ip=193.48.57.162

tail -f /var/log/xen-tools/PANACHE.log

* Modification du fichier de configuration : PANACHE.cfg (ajout du bridge=IMA5sc et taille mémoire à 512)

* Suite aux modifications :

xl create /etc/xen/PANACHE.cfg

* Lancement de la machine virtuelle :

xl console PANACHE

* Installation des paquets suivants sur la machine virtuelle : ssh, apache2, bind9

=== Semaine 4 (22/10/2015) ===

* Création du certificat SSL

openssl req -new -newkey rsa:2048 -sha256 -nodes -out tissothage.lol.csr -keyout tissothage.lol.key -subj '/C=FR/CN=tissothage.lol'

* Intrusion par changement d'adresse MAC : configuration de la connexion sans fil "baguette" de notre eeePC pour la salle E304 (en donnant notre adresse MAC).
# dans le fichier /etc/network/interfaces
auto wlan0 inet static
wireless-essid baguette
address 172.26.79.59
netmask 255.255.240.0
gateway 172.26.79.254

# dans le fichier /etc/resolv.conf
nameserver 193.48.57.48

* Nous avons réussi à se connecter sur le site de TF1 (site en ipv4).

* Pour pouvoir se connecter au réseau wifi "troubadour" de la salle E306 :
Nous avons changé l'adresse MAC du wlan0 par une reconnue par la borne wifi.
ifconfig wlan0 hw ether ADRESSE_MAC
Pour réinitialiser la configuration
/etc/init.d/networking restart
Nous avons modifié le fichier /etc/network/interfaces pour changer le nom "baguette" en "troubadour"

* Nous avons réussi à se connecter sur le site de TF1 (site en ipv4).

=== Semaine 5 (12/11/2015) ===

* Cassage de clef WEP d'un point d'accès Wifi
- Activation du mode monitor de la carte réseau :
airmon-ng start wlan0
- Pour voir tous les points d'accès :
airodump-ng wlan0
- Pour voir seulement les points d'accès sur le canal 7 (canal regroupant les points d'accès "cracotte") :
airodump-ng -w out -c 7 --bssid 00:23:5E:1E:05:41 wlan0
L'adresse MAC du bssid est celle du point d'accès "cracotte2".
- Enfin, pour trouver la clé, on lance :
aircrack-ng out-02.cap

* Pour le routeur de la salle E304 : nous avons rajouté le vlan1 qui correspond au réseau privé et qui a pour adresse MAC 10.10.10.253.

=== Semaine 6 (19/11/2015) ===

* Création des partitions LVM :
lvcreate -L 10G -n /dev/virtual/ima5-panache-home -v
lvcreate -L 10G -n /dev/virtual/ima5-panache-var -v

Puis on modifie le fichier /etc/xen/PANACHE.cfg afin d'y rajouter les partitions nouvellement créées :
disk = [
'phy:/dev/virtual/ima5-panache-var,xvdb,w'
'phy:/dev/virtual/ima5-panache-home,xvdb,w'
]

Ensuite, on configure Apache afin d'écouter sur le port 443 :
<IfModule mod_ssl.c>
Listen 443
NameVirtualHost 193.48.57.162:443
</IfModule>

Enfin, on ajoute un VirtualHost /etc/apache2/sites-available/000-tissothage.lol-ssl.conf :

<VirtualHost *:443>
ServerName www.tissothage.lol
ServerAlias tissothage.lol
DocumentRoot /var/www/www.tissothage.lol/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.tissothage.lol.crt
SSLCertificateKeyFile /etc/ssl/private/www.tissothage.lol.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

Malheureusement, nous nous sommes rendues compte que suite à une erreur de notre part (noms de domaine et de certificat différents), il était évident que ça ne fonctionnerait pas.

* Cassage de mot de passe WPA-PSK par force brute
Nous avons commencé par créer un dictionnaire qui est composé de tous les nombres à 8 chiffres. Voici le code en c qui permet de générer ce fichier :
#include<stdio.h>
#include<stdlib.h>
#define MAX_I 99999999
int main(){
int i=0;
FILE* fp = fopen("Dictionnaire.txt","w");
if( fp == NULL ) printf("ERROR\n");
else{
for(i=0 ; i <= MAX_I ; i++){
fprintf(fp,"%08d\n",i);
}
}
fclose(fp);
return 0;
}
Nous avons réussi à trouver la clée :

[[Fichier:wpa.png]]

=== Semaine 7 (26/11/2015) ===

* Rachat d'un nom de domaine "panache.lol" et installation du certificat ssl :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout panache.lol.key -out panache.lol.csr

Après récupération des fichiers .key et .csr, on fournit ce dernier à Gandi et on obtient le fichier .crt.

On place www.panache.lol.key dans /etc/ssl/private et www.panache.lol.crt dans /etc/ssl/certs.

Ensuite, on récupère le certificat intermédiaire que l'on place dans le fichier /etc/ssl/certs/GandiStandardSSLCA2.pem.

Puis, on ajoute le Virtual Host dans le fichier /etc/apache2/sites-available/000-panache.lol-ssl.conf :
<VirtualHost *:443>
ServerName www.panache.lol
ServerAlias panache.lol
DocumentRoot /var/www/www.panache.lol/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.panache.lol.crt
SSLCertificateKeyFile /etc/ssl/private/www.panache.lol.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

* Sécurisation des données
Création de 3 partitions de 1G

lvcreate -L 1G -n /dev/virtual/ima5-panache-raid1 -v
lvcreate -L 1G -n /dev/virtual/ima5-panache-raid2 -v
lvcreate -L 1G -n /dev/virtual/ima5-panache-raid3 -v

Nous avons ensuite modifié le fichier de config /etc/xen/PANACHE.cfg
disk = [
...
'phy:/dev/virtual/ima5-panache-raidA,xvdd,w',
'phy:/dev/virtual/ima5-panache-raidB,xvde,w',
'phy:/dev/virtual/ima5-panache-raidC,xvdf,w',
]

Afin de pouvoir créer un RAID5 avec les trois partitions, nous avons d'abord redémarré notre VM, ensuite :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf
Pour vérifier la création de notre md0:
cat /proc/mdstat

On obtient :

Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[2] xvde[1] xvdd[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Pour vérifier qu'on a créé un RAID5 logiciel avec nos trois partitions
mdadm --detail /dev/md0

Après avoir redémarré la VM, on remarque que le volume nouvellement créé nommé md0 a été remplacé par md127.

Après suppression d'une partition, on effectue la commande précédente de nouveau :
mdadm --detail /dev/md127

Et on obtient :
Version : 1.2
Raid Level : raid0
Total Devices : 2
Persistence : Superblock is persistent
State : inactive
Name : PANACHE:0 (local to host PANACHE)
UUID : a5a2ac63:89713b63:57d0149e:da7e1d76
Events : 0
Number Major Minor RaidDevice
- 202 48 - /dev/xvdd
- 202 64 - /dev/xvde

On vérifie le volume md127 :
cat /proc/mdstat
On a :
Personalities :
md127 : inactive xvde[1](S) xvdd[0](S)
2095104 blocks super 1.2
unused devices: <none>

=== Semaine 8 (03/12/2015) ===

* Cryptage des données

Nous avons commencé par supprimer les autres partitions sur la carte SD afin d'en avoir qu'une seule en utilisant la commande

fdisk /dev/sdb

Nous avons ensuite sécurisé la partition en mettant une clé :

cryptsetup create key /dev/sdb

Ainsi, on peut vérifier que dans le répértoire /dev/mapper on a un répértoir /key

Pour formater la carte :

mkfs /dev/manager/key

* Sécurisation wifi par WPA2-EAP

- Configuration du serveur FreeRadius en PEAP-MSCHAPv2

Cahier groupe n°2

2015-12-03T10:54:08Z

Shage-ch : /* Suivi de l'avancement du TP */

== Cahier des charges de la tâche particulière ==
=== Présentation de la tâche particulière ===
La tâche particulière que nous devons effectuer lors de ce projet est la configuration d'un des deux routeurs nécessaires à l'établissement d'un réseau redondant.

=== Matériel utilisé pour la tâche particulière ===
- Routeur 3560E

== Suivi de l'avancement du TP ==
=== Semaine 1 (01/10/2015) ===
En collaboration avec le groupe n°1 :

- Établissement d'un tableau regroupant les informations nécessaires au routage.

- Attribution des adresses IPv4 pour chaque VLAN, l'interconnexion des réseaux ainsi que les machines virtuelles.

=== Semaine 2 (08/10/2015) ===
Configuration du routeur de la salle E304 en IPv4 :

* Configuration des VLAN :

- VLAN 11 à 20 pour chaque binôme IMA5 SC.

- VLAN 110 pour les machines virtuelles des binômes.

- VLAN 130 pour l'interconnexion avec le routeur de l'école.

* Configuration entre le routeur et le commutateur de la salle E304.

* Configuration avec le commutateur de la salle E306.

* Configuration avec le routeur de l'école.

* Réalisation de la redondance entre les deux routeurs en IPv4.

=== Semaine 3 (15/10/2015) ===
* Configuration du routeur de la salle E304 en IPv6.

* Réalisation de la redondance entre les deux routeurs en IPv6.

* Nous avons choisi le nom de domaine : tissothage.lol

* Nous avons créé notre machine virtuelle sur le dom0 cordouan.insecserv.deule.net :

ssh root@cordouan.insecserv.deule.net

xen-create-image --hostname=PANACHE --dist=jessie --dir=/usr/local/xen --gateway=193.48.57.174 --ip=193.48.57.162

tail -f /var/log/xen-tools/PANACHE.log

* Modification du fichier de configuration : PANACHE.cfg (ajout du bridge=IMA5sc et taille mémoire à 512)

* Suite aux modifications :

xl create /etc/xen/PANACHE.cfg

* Lancement de la machine virtuelle :

xl console PANACHE

* Installation des paquets suivants sur la machine virtuelle : ssh, apache2, bind9

=== Semaine 4 (22/10/2015) ===

* Création du certificat SSL

openssl req -new -newkey rsa:2048 -sha256 -nodes -out tissothage.lol.csr -keyout tissothage.lol.key -subj '/C=FR/CN=tissothage.lol'

* Intrusion par changement d'adresse MAC : configuration de la connexion sans fil "baguette" de notre eeePC pour la salle E304 (en donnant notre adresse MAC).
# dans le fichier /etc/network/interfaces
auto wlan0 inet static
wireless-essid baguette
address 172.26.79.59
netmask 255.255.240.0
gateway 172.26.79.254

# dans le fichier /etc/resolv.conf
nameserver 193.48.57.48

* Nous avons réussi à se connecter sur le site de TF1 (site en ipv4).

* Pour pouvoir se connecter au réseau wifi "troubadour" de la salle E306 :
Nous avons changé l'adresse MAC du wlan0 par une reconnue par la borne wifi.
ifconfig wlan0 hw ether ADRESSE_MAC
Pour réinitialiser la configuration
/etc/init.d/networking restart
Nous avons modifié le fichier /etc/network/interfaces pour changer le nom "baguette" en "troubadour"

* Nous avons réussi à se connecter sur le site de TF1 (site en ipv4).

=== Semaine 5 (12/11/2015) ===

* Cassage de clef WEP d'un point d'accès Wifi
- Activation du mode monitor de la carte réseau :
airmon-ng start wlan0
- Pour voir tous les points d'accès :
airodump-ng wlan0
- Pour voir seulement les points d'accès sur le canal 7 (canal regroupant les points d'accès "cracotte") :
airodump-ng -w out -c 7 --bssid 00:23:5E:1E:05:41 wlan0
L'adresse MAC du bssid est celle du point d'accès "cracotte2".
- Enfin, pour trouver la clé, on lance :
aircrack-ng out-02.cap

* Pour le routeur de la salle E304 : nous avons rajouté le vlan1 qui correspond au réseau privé et qui a pour adresse MAC 10.10.10.253.

=== Semaine 6 (19/11/2015) ===

* Création des partitions LVM :
lvcreate -L 10G -n /dev/virtual/ima5-panache-home -v
lvcreate -L 10G -n /dev/virtual/ima5-panache-var -v

Puis on modifie le fichier /etc/xen/PANACHE.cfg afin d'y rajouter les partitions nouvellement créées :
disk = [
'phy:/dev/virtual/ima5-panache-var,xvdb,w'
'phy:/dev/virtual/ima5-panache-home,xvdb,w'
]

Ensuite, on configure Apache afin d'écouter sur le port 443 :
<IfModule mod_ssl.c>
Listen 443
NameVirtualHost 193.48.57.162:443
</IfModule>

Enfin, on ajoute un VirtualHost /etc/apache2/sites-available/000-tissothage.lol-ssl.conf :

<VirtualHost *:443>
ServerName www.tissothage.lol
ServerAlias tissothage.lol
DocumentRoot /var/www/www.tissothage.lol/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.tissothage.lol.crt
SSLCertificateKeyFile /etc/ssl/private/www.tissothage.lol.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

Malheureusement, nous nous sommes rendues compte que suite à une erreur de notre part (noms de domaine et de certificat différents), il était évident que ça ne fonctionnerait pas.

* Cassage de mot de passe WPA-PSK par force brute
Nous avons commencé par créer un dictionnaire qui est composé de tous les nombres à 8 chiffres. Voici le code en c qui permet de générer ce fichier :
#include<stdio.h>
#include<stdlib.h>
#define MAX_I 99999999
int main(){
int i=0;
FILE* fp = fopen("Dictionnaire.txt","w");
if( fp == NULL ) printf("ERROR\n");
else{
for(i=0 ; i <= MAX_I ; i++){
fprintf(fp,"%08d\n",i);
}
}
fclose(fp);
return 0;
}
Nous avons réussi à trouver la clée :

[[Fichier:wpa.png]]

=== Semaine 7 (26/11/2015) ===

* Rachat d'un nom de domaine "panache.lol" et installation du certificat ssl :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout panache.lol.key -out panache.lol.csr

Après récupération des fichiers .key et .csr, on fournit ce dernier à Gandi et on obtient le fichier .crt.

On place www.panache.lol.key dans /etc/ssl/private et www.panache.lol.crt dans /etc/ssl/certs.

Ensuite, on récupère le certificat intermédiaire que l'on place dans le fichier /etc/ssl/certs/GandiStandardSSLCA2.pem.

Puis, on ajoute le Virtual Host dans le fichier /etc/apache2/sites-available/000-panache.lol-ssl.conf :
<VirtualHost *:443>
ServerName www.panache.lol
ServerAlias panache.lol
DocumentRoot /var/www/www.panache.lol/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.panache.lol.crt
SSLCertificateKeyFile /etc/ssl/private/www.panache.lol.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

* Sécurisation des données
Création de 3 partitions de 1G

lvcreate -L 1G -n /dev/virtual/ima5-panache-raid1 -v
lvcreate -L 1G -n /dev/virtual/ima5-panache-raid2 -v
lvcreate -L 1G -n /dev/virtual/ima5-panache-raid3 -v

Nous avons ensuite modifié le fichier de config /etc/xen/PANACHE.cfg
disk = [
...
'phy:/dev/virtual/ima5-panache-raidA,xvdd,w',
'phy:/dev/virtual/ima5-panache-raidB,xvde,w',
'phy:/dev/virtual/ima5-panache-raidC,xvdf,w',
]

Afin de pouvoir créer un RAID5 avec les trois partitions, nous avons d'abord redémarré notre VM, ensuite :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf
Pour vérifier la création de notre md0:
cat /proc/mdstat

On obtient :

Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[2] xvde[1] xvdd[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Pour vérifier qu'on a créé un RAID5 logiciel avec nos trois partitions
mdadm --detail /dev/md0

Après avoir redémarré la VM, on remarque que le volume nouvellement créé nommé md0 a été remplacé par md127.

Après suppression d'une partition, on effectue la commande précédente de nouveau :
mdadm --detail /dev/md127

Et on obtient :
Version : 1.2
Raid Level : raid0
Total Devices : 2
Persistence : Superblock is persistent
State : inactive
Name : PANACHE:0 (local to host PANACHE)
UUID : a5a2ac63:89713b63:57d0149e:da7e1d76
Events : 0
Number Major Minor RaidDevice
- 202 48 - /dev/xvdd
- 202 64 - /dev/xvde

On vérifie le volume md127 :
cat /proc/mdstat
On a :
Personalities :
md127 : inactive xvde[1](S) xvdd[0](S)
2095104 blocks super 1.2
unused devices: <none>

=== Semaine 8 (03/12/2015) ===

* Cryptage des données

Nous avons commencé par supprimer les autres partitions sur la carte SD afin d'en avoir qu'une seule en utilisant la commande

fdisk /dev/sdb

Nous avons ensuite sécurisé la partition en mettant une clé :

cryptsetup create key /dev/sdb

Ainsi, on peut vérifier que dans le répértoire /dev/mapper on a un répértoir /key

Pour le montage :

mkfs /dev/manager/key

* Sécurisation wifi par WPA2-EAP

- Configuration du serveur FreeRadius en PEAP-MSCHAPv2

Cahier groupe n°2

2015-11-26T11:22:32Z

Shage-ch : /* Semaine 7 (26/11/2015) */

== Cahier des charges de la tâche particulière ==
=== Présentation de la tâche particulière ===
La tâche particulière que nous devons effectuer lors de ce projet est la configuration d'un des deux routeurs nécessaires à l'établissement d'un réseau redondant.

=== Matériel utilisé pour la tâche particulière ===
- Routeur 3560E

== Suivi de l'avancement du TP ==
=== Semaine 1 (01/10/2015) ===
En collaboration avec le groupe n°1 :

- Établissement d'un tableau regroupant les informations nécessaires au routage.

- Attribution des adresses IPv4 pour chaque VLAN, l'interconnexion des réseaux ainsi que les machines virtuelles.

=== Semaine 2 (08/10/2015) ===
Configuration du routeur de la salle E304 en IPv4 :

* Configuration des VLAN :

- VLAN 11 à 20 pour chaque binôme IMA5 SC.

- VLAN 110 pour les machines virtuelles des binômes.

- VLAN 130 pour l'interconnexion avec le routeur de l'école.

* Configuration entre le routeur et le commutateur de la salle E304.

* Configuration avec le commutateur de la salle E306.

* Configuration avec le routeur de l'école.

* Réalisation de la redondance entre les deux routeurs en IPv4.

=== Semaine 3 (15/10/2015) ===
* Configuration du routeur de la salle E304 en IPv6.

* Réalisation de la redondance entre les deux routeurs en IPv6.

* Nous avons choisi le nom de domaine : tissothage.lol

* Nous avons créé notre machine virtuelle sur le dom0 cordouan.insecserv.deule.net :

ssh root@cordouan.insecserv.deule.net

xen-create-image --hostname=PANACHE --dist=jessie --dir=/usr/local/xen --gateway=193.48.57.174 --ip=193.48.57.162

tail -f /var/log/xen-tools/PANACHE.log

* Modification du fichier de configuration : PANACHE.cfg (ajout du bridge=IMA5sc et taille mémoire à 512)

* Suite aux modifications :

xl create /etc/xen/PANACHE.cfg

* Lancement de la machine virtuelle :

xl console PANACHE

* Installation des paquets suivants sur la machine virtuelle : ssh, apache2, bind9

=== Semaine 4 (22/10/2015) ===

* Création du certificat SSL

openssl req -new -newkey rsa:2048 -sha256 -nodes -out tissothage.lol.csr -keyout tissothage.lol.key -subj '/C=FR/CN=tissothage.lol'

* Intrusion par changement d'adresse MAC : configuration de la connexion sans fil "baguette" de notre eeePC pour la salle E304 (en donnant notre adresse MAC).
# dans le fichier /etc/network/interfaces
auto wlan0 inet static
wireless-essid baguette
address 172.26.79.59
netmask 255.255.240.0
gateway 172.26.79.254

# dans le fichier /etc/resolv.conf
nameserver 193.48.57.48

* Nous avons réussi à se connecter sur le site de TF1 (site en ipv4).

* Pour pouvoir se connecter au réseau wifi "troubadour" de la salle E306 :
Nous avons changé l'adresse MAC du wlan0 par une reconnue par la borne wifi.
ifconfig wlan0 hw ether ADRESSE_MAC
Pour réinitialiser la configuration
/etc/init.d/networking restart
Nous avons modifié le fichier /etc/network/interfaces pour changer le nom "baguette" en "troubadour"

* Nous avons réussi à se connecter sur le site de TF1 (site en ipv4).

=== Semaine 5 (12/11/2015) ===

* Cassage de clef WEP d'un point d'accès Wifi
- Activation du mode monitor de la carte réseau :
airmon-ng start wlan0
- Pour voir tous les points d'accès :
airodump-ng wlan0
- Pour voir seulement les points d'accès sur le canal 7 (canal regroupant les points d'accès "cracotte") :
airodump-ng -w out -c 7 --bssid 00:23:5E:1E:05:41 wlan0
L'adresse MAC du bssid est celle du point d'accès "cracotte2".
- Enfin, pour trouver la clé, on lance :
aircrack-ng out-02.cap

* Pour le routeur de la salle E304 : nous avons rajouté le vlan1 qui correspond au réseau privé et qui a pour adresse MAC 10.10.10.253.

=== Semaine 6 (19/11/2015) ===

* Création des partitions LVM :
lvcreate -L 10G -n /dev/virtual/ima5-panache-home -v
lvcreate -L 10G -n /dev/virtual/ima5-panache-var -v

Puis on modifie le fichier /etc/xen/PANACHE.cfg afin d'y rajouter les partitions nouvellement créées :
disk = [
'phy:/dev/virtual/ima5-panache-var,xvdb,w'
'phy:/dev/virtual/ima5-panache-home,xvdb,w'
]

Ensuite, on configure Apache afin d'écouter sur le port 443 :
<IfModule mod_ssl.c>
Listen 443
NameVirtualHost 193.48.57.162:443
</IfModule>

Enfin, on ajoute un VirtualHost /etc/apache2/sites-available/000-tissothage.lol-ssl.conf :

<VirtualHost *:443>
ServerName www.tissothage.lol
ServerAlias tissothage.lol
DocumentRoot /var/www/www.tissothage.lol/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.tissothage.lol.crt
SSLCertificateKeyFile /etc/ssl/private/www.tissothage.lol.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

Malheureusement, nous nous sommes rendues compte que suite à une erreur de notre part (noms de domaine et de certificat différents), il était évident que ça ne fonctionnerait pas.

* Cassage de mot de passe WPA-PSK par force brute
Nous avons commencé par créer un dictionnaire qui est composé de tous les nombres à 8 chiffres. Voici le code en c qui permet de générer ce fichier :
#include<stdio.h>
#include<stdlib.h>
#define MAX_I 99999999
int main(){
int i=0;
FILE* fp = fopen("Dictionnaire.txt","w");
if( fp == NULL ) printf("ERROR\n");
else{
for(i=0 ; i <= MAX_I ; i++){
fprintf(fp,"%08d\n",i);
}
}
fclose(fp);
return 0;
}
Nous avons réussi à trouver la clée :

[[Fichier:wpa.png]]

=== Semaine 7 (26/11/2015) ===

* Rachat d'un nom de domaine "panache.lol" et installation du certificat ssl :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout panache.lol.key -out panache.lol.csr

Après récupération des fichiers .key et .csr, on fournit ce dernier à Gandi et on obtient le fichier .crt.

On place www.panache.lol.key dans /etc/ssl/private et www.panache.lol.crt dans /etc/ssl/certs.

Ensuite, on récupère le certificat intermédiaire que l'on place dans le fichier /etc/ssl/certs/GandiStandardSSLCA2.pem.

Puis, on ajoute le Virtual Host dans le fichier /etc/apache2/sites-available/000-panache.lol-ssl.conf :
<VirtualHost *:443>
ServerName www.panache.lol
ServerAlias panache.lol
DocumentRoot /var/www/www.panache.lol/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.panache.lol.crt
SSLCertificateKeyFile /etc/ssl/private/www.panache.lol.key
SSLCertificateChainFile /etc/ssl/certs/GandiStlvcreate -L 1G -n /dev/virtual/ima5-panache-raid3 -v
andardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

* Sécurisation des données
Création de 3 partitions de 1G

lvcreate -L 1G -n /dev/virtual/ima5-panache-raid1 -v
lvcreate -L 1G -n /dev/virtual/ima5-panache-raid2 -v
lvcreate -L 1G -n /dev/virtual/ima5-panache-raid3 -v

Nous avons ensuite modifié le fichier de config /etc/xen/PANACHE.cfg
disk = [
...
'phy:/dev/virtual/ima5-panache-raidA,xvdd,w',
'phy:/dev/virtual/ima5-panache-raidB,xvde,w',
'phy:/dev/virtual/ima5-panache-raidC,xvdf,w',
]

Afin de pouvoir créer un RAID5 avec les trois partitions, nous avons d'abord redémarré notre VM, ensuite :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf
Pour vérifier la création de notre md0:
cat /proc/mdstat

On obtient :

Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[2] xvde[1] xvdd[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Pour vérifier qu'on a créé un RAID5 logiciel avec nos trois partitions
mdadm --detail /dev/md0

Après avoir redémarré la VM, on remarque que le volume nouvellement créé nommé md0 a été remplacé par md127.

Après suppression d'une partition, on effectue la commande précédente de nouveau :
mdadm --detail /dev/md127

Et on obtient :
Version : 1.2
Raid Level : raid0
Total Devices : 2
Persistence : Superblock is persistent
State : inactive
Name : PANACHE:0 (local to host PANACHE)
UUID : a5a2ac63:89713b63:57d0149e:da7e1d76
Events : 0
Number Major Minor RaidDevice
- 202 48 - /dev/xvdd
- 202 64 - /dev/xvde

On vérifie le volume md127 :
cat /proc/mdstat
On a :
Personalities :
md127 : inactive xvde[1](S) xvdd[0](S)
2095104 blocks super 1.2
unused devices: <none>

Cahier groupe n°2

2015-11-26T10:50:19Z

Shage-ch : /* Semaine 7 (26/11/2015) */

== Cahier des charges de la tâche particulière ==
=== Présentation de la tâche particulière ===
La tâche particulière que nous devons effectuer lors de ce projet est la configuration d'un des deux routeurs nécessaires à l'établissement d'un réseau redondant.

=== Matériel utilisé pour la tâche particulière ===
- Routeur 3560E

== Suivi de l'avancement du TP ==
=== Semaine 1 (01/10/2015) ===
En collaboration avec le groupe n°1 :

- Établissement d'un tableau regroupant les informations nécessaires au routage.

- Attribution des adresses IPv4 pour chaque VLAN, l'interconnexion des réseaux ainsi que les machines virtuelles.

=== Semaine 2 (08/10/2015) ===
Configuration du routeur de la salle E304 en IPv4 :

* Configuration des VLAN :

- VLAN 11 à 20 pour chaque binôme IMA5 SC.

- VLAN 110 pour les machines virtuelles des binômes.

- VLAN 130 pour l'interconnexion avec le routeur de l'école.

* Configuration entre le routeur et le commutateur de la salle E304.

* Configuration avec le commutateur de la salle E306.

* Configuration avec le routeur de l'école.

* Réalisation de la redondance entre les deux routeurs en IPv4.

=== Semaine 3 (15/10/2015) ===
* Configuration du routeur de la salle E304 en IPv6.

* Réalisation de la redondance entre les deux routeurs en IPv6.

* Nous avons choisi le nom de domaine : tissothage.lol

* Nous avons créé notre machine virtuelle sur le dom0 cordouan.insecserv.deule.net :

ssh root@cordouan.insecserv.deule.net

xen-create-image --hostname=PANACHE --dist=jessie --dir=/usr/local/xen --gateway=193.48.57.174 --ip=193.48.57.162

tail -f /var/log/xen-tools/PANACHE.log

* Modification du fichier de configuration : PANACHE.cfg (ajout du bridge=IMA5sc et taille mémoire à 512)

* Suite aux modifications :

xl create /etc/xen/PANACHE.cfg

* Lancement de la machine virtuelle :

xl console PANACHE

* Installation des paquets suivants sur la machine virtuelle : ssh, apache2, bind9

=== Semaine 4 (22/10/2015) ===

* Création du certificat SSL

openssl req -new -newkey rsa:2048 -sha256 -nodes -out tissothage.lol.csr -keyout tissothage.lol.key -subj '/C=FR/CN=tissothage.lol'

* Intrusion par changement d'adresse MAC : configuration de la connexion sans fil "baguette" de notre eeePC pour la salle E304 (en donnant notre adresse MAC).
# dans le fichier /etc/network/interfaces
auto wlan0 inet static
wireless-essid baguette
address 172.26.79.59
netmask 255.255.240.0
gateway 172.26.79.254

# dans le fichier /etc/resolv.conf
nameserver 193.48.57.48

* Nous avons réussi à se connecter sur le site de TF1 (site en ipv4).

* Pour pouvoir se connecter au réseau wifi "troubadour" de la salle E306 :
Nous avons changé l'adresse MAC du wlan0 par une reconnue par la borne wifi.
ifconfig wlan0 hw ether ADRESSE_MAC
Pour réinitialiser la configuration
/etc/init.d/networking restart
Nous avons modifié le fichier /etc/network/interfaces pour changer le nom "baguette" en "troubadour"

* Nous avons réussi à se connecter sur le site de TF1 (site en ipv4).

=== Semaine 5 (12/11/2015) ===

* Cassage de clef WEP d'un point d'accès Wifi
- Activation du mode monitor de la carte réseau :
airmon-ng start wlan0
- Pour voir tous les points d'accès :
airodump-ng wlan0
- Pour voir seulement les points d'accès sur le canal 7 (canal regroupant les points d'accès "cracotte") :
airodump-ng -w out -c 7 --bssid 00:23:5E:1E:05:41 wlan0
L'adresse MAC du bssid est celle du point d'accès "cracotte2".
- Enfin, pour trouver la clé, on lance :
aircrack-ng out-02.cap

* Pour le routeur de la salle E304 : nous avons rajouté le vlan1 qui correspond au réseau privé et qui a pour adresse MAC 10.10.10.253.

=== Semaine 6 (19/11/2015) ===

* Création des partitions LVM :
lvcreate -L 10G -n /dev/virtual/ima5-panache-home -v
lvcreate -L 10G -n /dev/virtual/ima5-panache-var -v

Puis on modifie le fichier /etc/xen/PANACHE.cfg afin d'y rajouter les partitions nouvellement créées :
disk = [
'phy:/dev/virtual/ima5-panache-var,xvdb,w'
'phy:/dev/virtual/ima5-panache-home,xvdb,w'
]

Ensuite, on configure Apache afin d'écouter sur le port 443 :
<IfModule mod_ssl.c>
Listen 443
NameVirtualHost 193.48.57.162:443
</IfModule>

Enfin, on ajoute un VirtualHost /etc/apache2/sites-available/000-tissothage.lol-ssl.conf :

<VirtualHost *:443>
ServerName www.tissothage.lol
ServerAlias tissothage.lol
DocumentRoot /var/www/www.tissothage.lol/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.tissothage.lol.crt
SSLCertificateKeyFile /etc/ssl/private/www.tissothage.lol.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

Malheureusement, nous nous sommes rendues compte que suite à une erreur de notre part (noms de domaine et de certificat différents), il était évident que ça ne fonctionnerait pas.

* Cassage de mot de passe WPA-PSK par force brute
Nous avons commencé par créer un dictionnaire qui est composé de tous les nombres à 8 chiffres. Voici le code en c qui permet de générer ce fichier :
#include<stdio.h>
#include<stdlib.h>
#define MAX_I 99999999
int main(){
int i=0;
FILE* fp = fopen("Dictionnaire.txt","w");
if( fp == NULL ) printf("ERROR\n");
else{
for(i=0 ; i <= MAX_I ; i++){
fprintf(fp,"%08d\n",i);
}
}
fclose(fp);
return 0;
}
Nous avons réussi à trouver la clée :

[[Fichier:wpa.png]]

=== Semaine 7 (26/11/2015) ===

* Rachat d'un nom de domaine "panache.lol" et installation du certificat ssl :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout panache.lol.key -out panache.lol.csr

Après récupération des fichiers .key et .csr, on fournit ce dernier à Gandi et on obtient le fichier .crt.

On place www.panache.lol.key dans /etc/ssl/private et www.panache.lol.crt dans /etc/ssl/certs.

Ensuite, on récupère le certificat intermédiaire que l'on place dans le fichier /etc/ssl/certs/GandiStandardSSLCA2.pem.

Puis, on ajoute le Virtual Host dans le fichier /etc/apache2/sites-available/000-panache.lol-ssl.conf :
<VirtualHost *:443>
ServerName www.panache.lol
ServerAlias panache.lol
DocumentRoot /var/www/www.panache.lol/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.panache.lol.crt
SSLCertificateKeyFile /etc/ssl/private/www.panache.lol.key
SSLCertificateChainFile /etc/ssl/certs/GandiStlvcreate -L 1G -n /dev/virtual/ima5-panache-raid3 -v
andardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

* Sécurisation des données
Création de 3 partitions de 1G

lvcreate -L 1G -n /dev/virtual/ima5-panache-raid1 -v
lvcreate -L 1G -n /dev/virtual/ima5-panache-raid2 -v
lvcreate -L 1G -n /dev/virtual/ima5-panache-raid3 -v

Nous avons ensuite modifié le fichier de config /etc/xen/PANACHE.cfg
disk = [
...
'phy:/dev/virtual/ima5-panache-raidA,xvdd,w',
'phy:/dev/virtual/ima5-panache-raidB,xvde,w',
'phy:/dev/virtual/ima5-panache-raidC,xvdf,w',
]

Afin de pouvoir créer un RAID5 avec les trois partitions, nous avons d'abord redémarré notre VM, ensuite :

Cahier groupe n°2

2015-11-26T10:41:38Z

Shage-ch : /* Semaine 7 (26/11/2015) */

== Cahier des charges de la tâche particulière ==
=== Présentation de la tâche particulière ===
La tâche particulière que nous devons effectuer lors de ce projet est la configuration d'un des deux routeurs nécessaires à l'établissement d'un réseau redondant.

=== Matériel utilisé pour la tâche particulière ===
- Routeur 3560E

== Suivi de l'avancement du TP ==
=== Semaine 1 (01/10/2015) ===
En collaboration avec le groupe n°1 :

- Établissement d'un tableau regroupant les informations nécessaires au routage.

- Attribution des adresses IPv4 pour chaque VLAN, l'interconnexion des réseaux ainsi que les machines virtuelles.

=== Semaine 2 (08/10/2015) ===
Configuration du routeur de la salle E304 en IPv4 :

* Configuration des VLAN :

- VLAN 11 à 20 pour chaque binôme IMA5 SC.

- VLAN 110 pour les machines virtuelles des binômes.

- VLAN 130 pour l'interconnexion avec le routeur de l'école.

* Configuration entre le routeur et le commutateur de la salle E304.

* Configuration avec le commutateur de la salle E306.

* Configuration avec le routeur de l'école.

* Réalisation de la redondance entre les deux routeurs en IPv4.

=== Semaine 3 (15/10/2015) ===
* Configuration du routeur de la salle E304 en IPv6.

* Réalisation de la redondance entre les deux routeurs en IPv6.

* Nous avons choisi le nom de domaine : tissothage.lol

* Nous avons créé notre machine virtuelle sur le dom0 cordouan.insecserv.deule.net :

ssh root@cordouan.insecserv.deule.net

xen-create-image --hostname=PANACHE --dist=jessie --dir=/usr/local/xen --gateway=193.48.57.174 --ip=193.48.57.162

tail -f /var/log/xen-tools/PANACHE.log

* Modification du fichier de configuration : PANACHE.cfg (ajout du bridge=IMA5sc et taille mémoire à 512)

* Suite aux modifications :

xl create /etc/xen/PANACHE.cfg

* Lancement de la machine virtuelle :

xl console PANACHE

* Installation des paquets suivants sur la machine virtuelle : ssh, apache2, bind9

=== Semaine 4 (22/10/2015) ===

* Création du certificat SSL

openssl req -new -newkey rsa:2048 -sha256 -nodes -out tissothage.lol.csr -keyout tissothage.lol.key -subj '/C=FR/CN=tissothage.lol'

* Intrusion par changement d'adresse MAC : configuration de la connexion sans fil "baguette" de notre eeePC pour la salle E304 (en donnant notre adresse MAC).
# dans le fichier /etc/network/interfaces
auto wlan0 inet static
wireless-essid baguette
address 172.26.79.59
netmask 255.255.240.0
gateway 172.26.79.254

# dans le fichier /etc/resolv.conf
nameserver 193.48.57.48

* Nous avons réussi à se connecter sur le site de TF1 (site en ipv4).

* Pour pouvoir se connecter au réseau wifi "troubadour" de la salle E306 :
Nous avons changé l'adresse MAC du wlan0 par une reconnue par la borne wifi.
ifconfig wlan0 hw ether ADRESSE_MAC
Pour réinitialiser la configuration
/etc/init.d/networking restart
Nous avons modifié le fichier /etc/network/interfaces pour changer le nom "baguette" en "troubadour"

* Nous avons réussi à se connecter sur le site de TF1 (site en ipv4).

=== Semaine 5 (12/11/2015) ===

* Cassage de clef WEP d'un point d'accès Wifi
- Activation du mode monitor de la carte réseau :
airmon-ng start wlan0
- Pour voir tous les points d'accès :
airodump-ng wlan0
- Pour voir seulement les points d'accès sur le canal 7 (canal regroupant les points d'accès "cracotte") :
airodump-ng -w out -c 7 --bssid 00:23:5E:1E:05:41 wlan0
L'adresse MAC du bssid est celle du point d'accès "cracotte2".
- Enfin, pour trouver la clé, on lance :
aircrack-ng out-02.cap

* Pour le routeur de la salle E304 : nous avons rajouté le vlan1 qui correspond au réseau privé et qui a pour adresse MAC 10.10.10.253.

=== Semaine 6 (19/11/2015) ===

* Création des partitions LVM :
lvcreate -L 10G -n /dev/virtual/ima5-panache-home -v
lvcreate -L 10G -n /dev/virtual/ima5-panache-var -v

Puis on modifie le fichier /etc/xen/PANACHE.cfg afin d'y rajouter les partitions nouvellement créées :
disk = [
'phy:/dev/virtual/ima5-panache-var,xvdb,w'
'phy:/dev/virtual/ima5-panache-home,xvdb,w'
]

Ensuite, on configure Apache afin d'écouter sur le port 443 :
<IfModule mod_ssl.c>
Listen 443
NameVirtualHost 193.48.57.162:443
</IfModule>

Enfin, on ajoute un VirtualHost /etc/apache2/sites-available/000-tissothage.lol-ssl.conf :

<VirtualHost *:443>
ServerName www.tissothage.lol
ServerAlias tissothage.lol
DocumentRoot /var/www/www.tissothage.lol/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.tissothage.lol.crt
SSLCertificateKeyFile /etc/ssl/private/www.tissothage.lol.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

Malheureusement, nous nous sommes rendues compte que suite à une erreur de notre part (noms de domaine et de certificat différents), il était évident que ça ne fonctionnerait pas.

* Cassage de mot de passe WPA-PSK par force brute
Nous avons commencé par créer un dictionnaire qui est composé de tous les nombres à 8 chiffres. Voici le code en c qui permet de générer ce fichier :
#include<stdio.h>
#include<stdlib.h>
#define MAX_I 99999999
int main(){
int i=0;
FILE* fp = fopen("Dictionnaire.txt","w");
if( fp == NULL ) printf("ERROR\n");
else{
for(i=0 ; i <= MAX_I ; i++){
fprintf(fp,"%08d\n",i);
}
}
fclose(fp);
return 0;
}
Nous avons réussi à trouver la clée :

[[Fichier:wpa.png]]

=== Semaine 7 (26/11/2015) ===

* Rachat d'un nom de domaine "panache.lol" et installation du certificat ssl :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout panache.lol.key -out panache.lol.csr

Après récupération des fichiers .key et .csr, on fournit ce dernier à Gandi et on obtient le fichier .crt.

On place www.panache.lol.key dans /etc/ssl/private et www.panache.lol.crt dans /etc/ssl/certs.

Ensuite, on récupère le certificat intermédiaire que l'on place dans le fichier /etc/ssl/certs/GandiStandardSSLCA2.pem.

Puis, on ajoute le Virtual Host dans le fichier /etc/apache2/sites-available/000-panache.lol-ssl.conf :
<VirtualHost *:443>
ServerName www.panache.lol
ServerAlias panache.lol
DocumentRoot /var/www/www.panache.lol/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.panache.lol.crt
SSLCertificateKeyFile /etc/ssl/private/www.panache.lol.key
SSLCertificateChainFile /etc/ssl/certs/GandiStlvcreate -L 1G -n /dev/virtual/ima5-panache-raid3 -v
andardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

* Sécurisation des données
Création de 3 partitions de 1G

lvcreate -L 1G -n /dev/virtual/ima5-panache-raid1 -v
lvcreate -L 1G -n /dev/virtual/ima5-panache-raid2 -v
lvcreate -L 1G -n /dev/virtual/ima5-panache-raid3 -v

Nous avons ensuite modifié le fichier de config /etc/xen/PANACHE.cfg
disk = [
...
'phy:/dev/virtual/ima5-panache-raidA,xvdd,w',
'phy:/dev/virtual/ima5-panache-raidB,xvde,w',
'phy:/dev/virtual/ima5-panache-raidC,xvdf,w',
]

Afin de pouvoir créer un RAID5 avec les troios partitions, nous avons d'abord redémarré notre VM, ensuite :

Cahier groupe n°2

2015-11-26T09:55:50Z

Shage-ch : /* Semaine 7 (26/11/2015) */

== Cahier des charges de la tâche particulière ==
=== Présentation de la tâche particulière ===
La tâche particulière que nous devons effectuer lors de ce projet est la configuration d'un des deux routeurs nécessaires à l'établissement d'un réseau redondant.

=== Matériel utilisé pour la tâche particulière ===
- Routeur 3560E

== Suivi de l'avancement du TP ==
=== Semaine 1 (01/10/2015) ===
En collaboration avec le groupe n°1 :

- Établissement d'un tableau regroupant les informations nécessaires au routage.

- Attribution des adresses IPv4 pour chaque VLAN, l'interconnexion des réseaux ainsi que les machines virtuelles.

=== Semaine 2 (08/10/2015) ===
Configuration du routeur de la salle E304 en IPv4 :

* Configuration des VLAN :

- VLAN 11 à 20 pour chaque binôme IMA5 SC.

- VLAN 110 pour les machines virtuelles des binômes.

- VLAN 130 pour l'interconnexion avec le routeur de l'école.

* Configuration entre le routeur et le commutateur de la salle E304.

* Configuration avec le commutateur de la salle E306.

* Configuration avec le routeur de l'école.

* Réalisation de la redondance entre les deux routeurs en IPv4.

=== Semaine 3 (15/10/2015) ===
* Configuration du routeur de la salle E304 en IPv6.

* Réalisation de la redondance entre les deux routeurs en IPv6.

* Nous avons choisi le nom de domaine : tissothage.lol

* Nous avons créé notre machine virtuelle sur le dom0 cordouan.insecserv.deule.net :

ssh root@cordouan.insecserv.deule.net

xen-create-image --hostname=PANACHE --dist=jessie --dir=/usr/local/xen --gateway=193.48.57.174 --ip=193.48.57.162

tail -f /var/log/xen-tools/PANACHE.log

* Modification du fichier de configuration : PANACHE.cfg (ajout du bridge=IMA5sc et taille mémoire à 512)

* Suite aux modifications :

xl create /etc/xen/PANACHE.cfg

* Lancement de la machine virtuelle :

xl console PANACHE

* Installation des paquets suivants sur la machine virtuelle : ssh, apache2, bind9

=== Semaine 4 (22/10/2015) ===

* Création du certificat SSL

openssl req -new -newkey rsa:2048 -sha256 -nodes -out tissothage.lol.csr -keyout tissothage.lol.key -subj '/C=FR/CN=tissothage.lol'

* Intrusion par changement d'adresse MAC : configuration de la connexion sans fil "baguette" de notre eeePC pour la salle E304 (en donnant notre adresse MAC).
# dans le fichier /etc/network/interfaces
auto wlan0 inet static
wireless-essid baguette
address 172.26.79.59
netmask 255.255.240.0
gateway 172.26.79.254

# dans le fichier /etc/resolv.conf
nameserver 193.48.57.48

* Nous avons réussi à se connecter sur le site de TF1 (site en ipv4).

* Pour pouvoir se connecter au réseau wifi "troubadour" de la salle E306 :
Nous avons changé l'adresse MAC du wlan0 par une reconnue par la borne wifi.
ifconfig wlan0 hw ether ADRESSE_MAC
Pour réinitialiser la configuration
/etc/init.d/networking restart
Nous avons modifié le fichier /etc/network/interfaces pour changer le nom "baguette" en "troubadour"

* Nous avons réussi à se connecter sur le site de TF1 (site en ipv4).

=== Semaine 5 (12/11/2015) ===

* Cassage de clef WEP d'un point d'accès Wifi
- Activation du mode monitor de la carte réseau :
airmon-ng start wlan0
- Pour voir tous les points d'accès :
airodump-ng wlan0
- Pour voir seulement les points d'accès sur le canal 7 (canal regroupant les points d'accès "cracotte") :
airodump-ng -w out -c 7 --bssid 00:23:5E:1E:05:41 wlan0
L'adresse MAC du bssid est celle du point d'accès "cracotte2".
- Enfin, pour trouver la clé, on lance :
aircrack-ng out-02.cap

* Pour le routeur de la salle E304 : nous avons rajouté le vlan1 qui correspond au réseau privé et qui a pour adresse MAC 10.10.10.253.

=== Semaine 6 (19/11/2015) ===

* Création des partitions LVM :
lvcreate -L 10G -n /dev/virtual/ima5-panache-home -v
lvcreate -L 10G -n /dev/virtual/ima5-panache-var -v

Puis on modifie le fichier /etc/xen/PANACHE.cfg afin d'y rajouter les partitions nouvellement créées :
disk = [
'phy:/dev/virtual/ima5-panache-var,xvdb,w'
'phy:/dev/virtual/ima5-panache-home,xvdb,w'
]

Ensuite, on configure Apache afin d'écouter sur le port 443 :
<IfModule mod_ssl.c>
Listen 443
NameVirtualHost 193.48.57.162:443
</IfModule>

Enfin, on ajoute un VirtualHost /etc/apache2/sites-available/000-tissothage.lol-ssl.conf :

<VirtualHost *:443>
ServerName www.tissothage.lol
ServerAlias tissothage.lol
DocumentRoot /var/www/www.tissothage.lol/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.tissothage.lol.crt
SSLCertificateKeyFile /etc/ssl/private/www.tissothage.lol.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

Malheureusement, nous nous sommes rendues compte que suite à une erreur de notre part (noms de domaine et de certificat différents), il était évident que ça ne fonctionnerait pas.

* Cassage de mot de passe WPA-PSK par force brute
Nous avons commencé par créer un dictionnaire qui est composé de tous les nombres à 8 chiffres. Voici le code en c qui permet de générer ce fichier :
#include<stdio.h>
#include<stdlib.h>
#define MAX_I 99999999
int main(){
int i=0;
FILE* fp = fopen("Dictionnaire.txt","w");
if( fp == NULL ) printf("ERROR\n");
else{
for(i=0 ; i <= MAX_I ; i++){
fprintf(fp,"%08d\n",i);
}
}
fclose(fp);
return 0;
}
Nous avons réussi à trouver la clée :

[[Fichier:wpa.png]]

=== Semaine 7 (26/11/2015) ===

* Rachat d'un nom de domaine "panache.lol" et installation du certificat ssl :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout panache.lol.key -out panache.lol.csr

Après récupération des fichiers .key et .csr, on fournit ce dernier à Gandi et on obtient le fichier .crt.

On place www.panache.lol.key dans /etc/ssl/private et www.panache.lol.crt dans /etc/ssl/certs.

Ensuite, on récupère le certificat intermédiaire que l'on place dans le fichier /etc/ssl/certs/GandiStandardSSLCA2.pem.

Puis, on ajoute le Virtual Host dans le fichier /etc/apache2/sites-available/000-panache.lol-ssl.conf :
<VirtualHost *:443>
ServerName www.panache.lol
ServerAlias panache.lol
DocumentRoot /var/www/www.panache.lol/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.panache.lol.crt
SSLCertificateKeyFile /etc/ssl/private/www.panache.lol.key
SSLCertificateChainFile /etc/ssl/certs/GandiStlvcreate -L 1G -n /dev/virtual/ima5-panache-raid3 -v
andardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

* Sécurisation des données
Création de 3 partitions de 1G

lvcreate -L 1G -n /dev/virtual/ima5-panache-raid1 -v
lvcreate -L 1G -n /dev/virtual/ima5-panache-raid2 -v
lvcreate -L 1G -n /dev/virtual/ima5-panache-raid3 -v

Cahier groupe n°2

2015-11-25T14:58:38Z

Shage-ch : /* Semaine 6 (19/11/2015) */

Fichier:Wpa.png

2015-11-25T14:57:09Z

Shage-ch :

Cahier groupe n°2

2015-11-19T10:44:25Z

Shage-ch : /* Semaine 6 (19:11:2015) */

Cahier groupe n°2

2015-11-12T09:28:46Z

Shage-ch : /* Semaine 4 (22/10/2015) */

Cahier groupe n°2

2015-10-22T10:27:43Z

Shage-ch : /* Semaine 4 (22/10/2015) */

Cahier groupe n°2

2015-10-22T10:10:11Z

Shage-ch : /* Semaine 4 (22/10/2015) */

Cahier groupe n°2

2015-10-22T10:08:31Z

Shage-ch : /* Semaine 4 (22/10/2015) */

Cahier groupe n°2

2015-10-22T10:03:03Z

Shage-ch : /* Semaine 4 (22/10/2015) */

Cahier groupe n°2

2015-10-22T09:09:12Z

Shage-ch : /* Suivi de l'avancement du TP */

Cahier groupe n°2

2015-10-15T10:20:13Z

Shage-ch : /* Semaine 3 (15/10/2015) */

Cahier groupe n°2

2015-10-15T10:07:29Z

Shage-ch : /* Semaine 3 (15/10/2015) */

Cahier groupe n°2

2015-10-15T09:39:14Z

Shage-ch : /* Semaine 3 (15/10/2015) */

Cahier groupe n°2

2015-10-15T09:16:38Z

Shage-ch : /* Semaine 3 (15/10/2015) */

RoboCup 2015

2015-05-09T16:55:44Z

Shage-ch : /* Exécuteur de tâches */

__TOC__
 
[[Fichier:logoPyro_icone.png |center ]]
<center> Polytech RoboCup Team </center>

==Cahier des charges==
===Présentation générale du projet===

Lors de la compétition de l'Open German, prélude de la Robocup, il faudra mettre en place un système d'autonomisation de production à l'aide de Robotinos (robots mobiles de Festo ayant un système d'exploitation Linux). Comme dans toutes compétitions, le but est de gagner, par conséquent, il faudra faire en sorte de gagner un maximum de points.
C'est pourquoi il faut créer un manager à l'aide de ROS, c'est-à-dire un nœud ou ensemble de nœuds permettant de pouvoir recevoir les informations envoyées par les autres nœuds, de les traiter, tout cela afin de donner les ordres que doivent exécuter chaque Robotino. Ce manager devra également être capable d'optimiser le nombre de points à obtenir.

====Contexte====

La compétition de l'Open German se déroule en quatre phases spécifiques : phase de début-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des tâches spécifiques à remplir suivant les différentes phases. La RefereeBox est un système d'arbitrage auquel il est nécessaire d'envoyer périodiquement des données à tout moment du jeu et qui donne à chaque instant l'état du jeu ainsi que les produits demandés en priorité durant la phase de production.

====Objectif du projet====

*Assurer un maximum de points suivant les aléas du jeu (panne de machine, produits demandées, rupture de stock d'une matière première, …)
*Assurer la pérennité du projet (chaque année des candidats de Polytech Lille y participent)

====Description du projet====

Pour le projet, outre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes :
*Communication avec le nœud de la RefereeBox à tout moment du jeu
*Contrainte de robustesse (il ne faut qu'à un moment ou à un autre il n'y ait un blocage de tous les robots)
*Coopération entre les trois robots
 
[[Fichier:Interactions.png|vignette|left|upright=2|Interactions des nœuds avec le manager]]
 
Le manager devra interagir avec les différents nœuds suivants ayant chacun leurs rôles spécifiques :
*RefereeBox Comm : recevoir les données envoyées par la RefereeBox et envoyer des données suivant l'état du jeu à la RefereeBox
*Robots Comm : communiquer aux autres robots les informations concernant ce que chacun font
*Traitement des TAGs : lire les TAG
*Traitement des feux : lire l'état des colonnes de feu
*Pince de préhension : ouvrir et fermer la pince et renvoyer l'état de la pince
*Approche finale : s'adapter au banc de charge ou de décharge de produits
*Génération trajectoire : détermine une trajectoire pour aller au lieu (X,Y)
*Réalisation trajectoire : parcourir la trajectoire
*Localisation : savoir périodiquement (faible période) où se situe le robot
*Détection d'obstacle : détecter les obstacles fixes et mobiles
 

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

*Utilisation de trois robotinos
*Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce système travaille en utilisant des nœuds qui communiquent entre eux à l'aide de services (requête-réponse) et de topics (fichiers).
*Utilisation de différents langages : C++ ou Python (nœuds)
*Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS
 

===Etapes du projet===
*Prise en main de ROS et du C++
*Élaboration de l'algorithme du manager pour la phase d'exploration
*Élaboration de l'algorithme du manager pour la phase de production
**Coopération entre robots
**Répartition des tâches
*Codage du manager
*Tests et corrections
 

==Avancement du Projet==
===Semaine 1===
*Prise en main de ROS
*Réalisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials
*Réalisation de différents tutoriels C++
*Connaissance plus aiguë du sujet de l'Open German 2015
 
===Semaine 2===
*Réflexions autour de la structure du manager : deux nœuds
**Un nœud exécuteur de tâches
**Un nœud générateur de tâches
*Réflexions sur l'algorithme général du manager concernant la phase d'exploration
**Fonctionnement par zoning pour la répartition des tâches des trois robots
**Réflexion autour d'une alternative de répartition par distances les plus courtes entre machines
*Recherche de solutions pour la phase de production
**Documentation autour de la planification de tâches et la génération de tâche pour une équipe
**Recherche autour de la coopération et de l'allocation de rôles à des robots multi-tâches
*Organisation générale
**Structuration d'un échéancier numérique sous Asana
**Demande d'autorisation pour l'ouverture de la salle C002 auprès de M. Scrive
 

===Semaine 3===
Voilà un lien permettant d'accéder au sujet provisoire de la Robocup 2015 : [https://drive.google.com/file/d/0B39jN82rDE6qMG45cDN5Z0xiSVE/view?usp=sharing Sujet] 
*Réflexions au sujet des infos à communiquer au nœud AutresRobotsComm :
**Ce que le robotino fait
**Quelle machine le robotino est en train d'utiliser
[[Fichier:DataSWithRobotComm.jpg|center]]
 
*Réflexions au niveau de l'algorithme de la phase de production
**Proposition de le faire sous le principe de "Diviser pour mieux régner" (validé par M. Vincent Coelen)
***Diviser la tâche principale en sous-tâches, les sous-tâches en sous-sous-tâches et les sous-sous-tâches en sous-sous-sous-tâches élémentaires.
**Détermination des tâches à réaliser pour un exemple particulier
On souhaite produire, pendant une durée déterminée par la refBox, le produit suivant :
[[Fichier:ExempleProduitDemande.jpg|center]]
''Le produit est composé d’une base bleue, d’un ring rouge, d’un ring vert et d’un cap noir.''

'''Obtenir Base Bleue'''
->Aller à la Base Station
générateur trajectoire
exécuteur trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (dire à la Base Station quelle base est souhaitée et à quelle banc le robotino est)
approche finale
pince (prendre)

'''Obtenir ring rouge'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Obtenir ring vert'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
(Du coup la plus proche sera celle où on vient de faire le ring précédent)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Ring Station quelle base est souhaitée ( ici, la verte )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Finaliser produit'''
->Aller à une Cap Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Cap Station quelle cap est souhaité ( ici, le noir )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel banc de livraison)
approche finale
pince (prendre)
->Déposer à la Delivery Station
générateur de trajectoire (vers la Delivery Station)
exécuteur de trajectoire
approche finale
pince (déposer)
 
*Organisation générale :
**Création de la page Facebook de l'équipe PYRO Team
 

===Semaine 4===
*Écriture des sous-tâches à réaliser
**Pseudo-codes de certaines sous-tâches réalisées
*Recherche d'ordonnancement optimisé pour la fabrication du produit
**Recherche d'algorithmes
**Visualisation du problème d'ordonnancement concernant l'exemple précédent (base bleue, ring vert, ring rouge, cap noir)
 
Ici, on a pris en plus en hypothèse le fait que la Ring Station (RS1) est capable de mettre des rings rouges ou verts et que la RS2 est capable de de mettre des rings bleus et rouges. Afin de mieux appréhender le problème, nous nous sommes attachés à effectuer un tableau récapitulant les tâches à effectuer pour le produit exemple et à réaliser un graphe mettant en avant les contraintes de précédence de chaque tâche.
 

{| class="wikitable" style="text-align:center; width:80%;"

|-
|
! scope="col" | Tâches
! scope="col" | Ressources utilisées
! scope="col" | Contraintes de précédence
|-
! scope="row" | T0
| Ramener à CS base avec cap
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T1
| Décapsuler
| Cap Station 1 ou 2
| T0
|-
! scope="row" | T2
| Ramener base supplémentaires à RS
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T3
| Chercher base bleue
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T4
| Ramener à RS pour ring vert
| Robot 1, 2 ou 3
| T7
|-
! scope="row" | T5
| Ramener à RS pour ring rouge
| Robot 1, 2 ou 3
| T8
|-
! scope="row" | T6
| Ramener à CS pour cap
| Robot 1, 2 ou 3
| T9
|-
! scope="row" | T7
| Ramener Base
| Base Station
| T3
|-
! scope="row" | T8
| Ajouter ring vert
| Ring Station 1
| T4
|-
! scope="row" | T9
| Ajouter ring rouge
| Ring Station 1 ou 2
| T5 et T2
|-
! scope="row" | T10
| Ajouter cap
| Cap Station 1 ou 2
| T6 et T1
|-
! scope="row" | T11
| Traiter le produit fini
| Delivery Station
| T12
|-
! scope="row" | T12
| Ramener à DS
| Robot 1, 2 ou 3
| T10
|}
[[Fichier:TachesProduitExemple.png|center]]
<center>Graphe montrant l'ordre des tâches à réaliser</center>
 

===Semaine 5===
Durant cette semaine, nous avons réfléchi sur le choix de structures pour nos données :
* Une '''liste principale''' de tous les produits demandés par la RefBox à un instant t. Cette liste principale a les caractéristiques suivantes :
** Une '''Priorité''' sera calculée pour chaque produit avec les paramètres suivants :
*** Nombre de points que peut apporter la production d'un produit de A à Z.
*** Une estimation du temps de production d'un produit.
***La date limite de livraison du produit demandé
** Une tâche est élue si sa priorité est supérieure ou égale à celle des autres tâches.
** Quand la RefBox demande un produit, une cellule sera ajoutée dans cette liste. Et de même, quand un produit sera terminé, on le supprimera de cette liste.
* Chaque produit de la liste principale va contenir une '''liste de tâches''' correspondantes à la production de ce produit. Cette liste de tâches a les caractéristiques suivantes :
** Chaque cellule correspond à une tâche de la production d'un produit. Une tâche contient différents champs :
***Intitulé de la tâche (par exemple ajouter une base)
***Produit concernée (par exemple P3)
***Priorité de la tâche (par exemple 20)
***Temps restant estimé de production (par exemple 180s)
** A chaque fois qu'une tâche est réalisée, elle sera supprimée de la liste de tâches. Ce qui veut dire, qu'on va devoir calculé à nouveau la priorité de chaque tâche de la liste principale.
** Afin de respecter les contraintes de précédence, on considérera que la tâche en tête de la liste de tâches peut être élue. Par exemple, on ne peut pas ajouter un Ring si on n'a pas de base.
 
L'exemple suivant simule le cas où la RefBox a demandé deux fois le produit P3 et deux fois le produit P2.
*Le produit P3 est réalisable en cinq tâches.Ce produit mettra plus de temps à être fabriqué mais rapportera plus de points.
*Le produit P2 est réalisable en quatre tâches.
 
[[Fichier:listedelistes.png|center]]
<center>Structure utilisée pour ranger les tâches à réaliser</center>
 
Différentes remarques utiles :
*Avant de commencer à réaliser n'importe quel produit, il faudra au préalable vérifier si on a libérer un espace de stockage pour plusieurs raisons :
**Les Cap Stations ayant initialement aucun cap en stock, il faut les ramener de l'étagère qui en contient initialement car un produit est dit fini lorsqu'il a à son sommet un cap.
**L'étagère ayant été débarrassée d'un cap, cela permet d'avoir un espace de stockage afin de déposer des produits finis en attente de livraison ou des produits non finis dont on voudrait mettre en pause la production.
*Il sera peut être des fois plus avantageux d'abandonner temporairement la production d'un produit :
**Il vaut mieux faire en sorte de terminer un seul produit sur deux dans les temps plutôt qu'aucun car du fait de la parallélisation de la fabrication des produits, on peut être surchargé de travail.
**Un produit livré durant le laps de temps demandé rapportera plus de points non négligeables.
*Un tableau sera nécessaire afin de savoir ce qu'il y a les espaces de stockage avec les champs suivants :
**Type de produit
**Liste de tâches restantes pour la fabrication du produit (pour un produit fini cette liste est donc nulle)
**Date de début de livraison
**Date de fin de livraison
**Emplacement de l'espace de stockage
 

===Semaine 6===
*Différentes fonctions et actions en pseudo code pour le générateur de tâches
**Fonction qui retourne un booléen suivant si un produit est en stock ou non
**Fonction qui retourne un booléen suivant si on doit livrer le produit à présent ou non
**Fonction qui retourne un booléen suivant si on a déjà ou non mis le travail à faire dans la structure contenant les tâches à réaliser
**Fonction qui retourne le nombre de points que rapporte un produit passé en paramètre
**Action qui rajoute les nouveaux ordres de production dans la liste de listes de tâches
**Action qui calcule le ratio pour chaque tâche
**Action qui supprime les tâches vides (ie celles qui sont terminées)
*Début de l'écriture en pseudo code de la fonction principale
 
*Discussion avec M. Vincent Coelen concernant l'avancement du projet :
**Validation par M. Coelen Vincent des portions de pseudo code déjà écrites
**Discussion autour de la mise en place d'un arrêt immédiat des robots à tout moment du jeu
**Amélioration concernant la robustesse de l'algorithme si un robot n'est plus en état de fonctionnement
 
*Différentes remarques utiles :
**Branche concernant le manager créée sur le [https://github.com/PyroTeam/robocup-pkg/ git] de l'équipe
**Discussion avec d'autres membres de l'équipe sur les services et les topics à envoyer et à recevoir aux nœuds du manager
 
===Semaine 7===

====Générateur de tâches====
Début du codage C++ :
*Création de différentes classes :
**La classe Tache (tache.h et tache.cpp)
**La classe Stockage (stockage.h et stockage.cpp)
**La classe RefBoxComm (refboxcomm.h)
*Création de différentes fonctions :
**Dans tache.h et tache.cpp :
***point_par_produit : retourne le nombre de points que vaut un produit
***dans_les_temps : retourne un booléen indiquant s'il est temps de ramener le produit
**Dans listetaches.h et listetaches.cpp :
***creation_liste_taches_prod : retourne une liste de taches à partir d'un produit passé en paramètre
***creation_liste_taches_act : retourne une liste de taches à partir d'un produit et d'une action passés en paramètres
**Dans tableaustockage.h :
***produit_en_stock : retourne un booléen indiquant si au moins un produit est en stock
**Dans travail.h et travail.cpp :
***deja_dans_travail : retourne un booléen indiquant si un ordre de la RefBox a déjà été pris en compte dans la structure contenant les tâches à réaliser
***max_ratio : retourne l'objet Tache qui a le plus grand ratio dans la structure contenant les tâches à réaliser
***rajout_dans_travail : rajoute un nouvel ordre de la RefBox dans la structure contenant les tâches à réaliser
***calcul_ratio : calcule le ratio de chaque premier de liste de la structure contenant les tâches à réaliser
 
Les codes sont disponibles sur le [https://github.com/PyroTeam/robocup-pkg/tree/feature/manager/generateur_taches git]
 
Des tests ont été réalisés afin de valider les fonctions crées en particulier les fonctions contenues dans travail.h et travail.cpp
 
Voici un petit aperçu de la console :
 
[[Fichier:Capture terminal gen taches 3.png|800px]]
 
Ainsi, les quatres fonctions fonctionnent parfaitement :
*deja_dans_travail indique bien que l'ordre de la RefBox n'a pas encore pris en compte
*max_ratio retourne bien la tâche dont le ratio est maximum
*rajout_dans_travail rajoute en fin de liste la liste de tâches pour la première création d'un produit P0 car un cap est disponible , puis il concatène une liste contenant en tête la tâche "Decapsuler" avec la liste de tâches pour la seconde création d'un produit P0. En effet, la RefBox a demandé deux fois le produit P0 et on ne peut créer un produit tant qu'un cap n'est pas disponible.
*calcul_ratio calcule le ratio de chaque première tâche en fonction du nombre de points et du temps, de plus, si c'est le bon moment pour déstocker un produit il passe cette tâche "Destocker" en priorité (liste 6), en outre, la création d'un produit (liste 1 et liste 7) est prioritaire à l'unique tâche "Decapsuler" (listes 2, 3, 4 et 5) .
 
'''Nous avons enfin reçu le sujet 2015 pour la compétition 2015, il est disponible [https://drive.google.com/file/d/0B39jN82rDE6qSk11YXFuQVljTlE/view?usp=sharing ici]'''
 
*Modification à réaliser :
**la fonction de création de liste de tâches
**l'ordonnancement (en partie)
**calcul de ratio de chaque tâche

====Exécuteur de tâches====
L'éxécuteur de taches va recevoir des ordres de la part du générateur de taches . En fonction de ces ordres, il enverra des demandes d'exécution/d'informations aux autres noeuds. Il y a donc un seul générateur de taches et trois exécuteurs de taches ( on a trois robotinos ).
Voici les classes qui correspondent à chaque exécuteur de taches :
[[Fichier:shema1.png]]
*'''Machine''' est une classe abstraite qui servira à la création des quatre classes filles qui représenteront les quatre machines de la compétition.
** ''string type'' sera donc BaseStation, RingStation, CapStation ou DeliveryStation.
** ''Pose2D centreMachine'' est un point(x,y,theta) qui va correspondre au retour du noeud de localisation (Projet 36)
** ''Pose2D entreeMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour déposer un produit
** ''Pose2D sortieMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour prendre un produit
*'''BaseStation''' est une classe fille de la classe "Machine".
** ''int baseRouge'', ''int baseNoir'' et ''int baseArgent'' vont correspondre aux nombres de bases rouges, bases noires, base argentes respectivement.
*'''RingStation''' est une classe fille de la classe "Machine".
** ''int ringVert'', ''int ringJaune'', ''int ringBleu'' et ''ringOrange'' vont correspondre aux nombres de rings verts, rings jaunes, rings bleus et rings oranges respectivement.
*'''CapStation''' est une classe fille de la classe "Machine".
** ''int capNoir'' et ''int capGris'' vont correspondre aux nombres de caps noirs et caps gris respectivement.
** ''int stock[3]'' est un tableau qui va correspondre aux trois emplacements stockage de la capStation.
** 'Pose2D stockage'' est un point(x,y,theta) qui correspond à l'emplacement de la première zone de stockage.

===Semaine 8===
====Générateur de tâches====
*Création du service pour l'envoi des ordres pour l’exécuteur de tâches avec pour contenu:
**Numéro du robot
***1, 2 ou 3
**Ordre
***ChercherBase
***MettreCap
***ChercherCap
***MettreRing
***ChercherRing
***RamenerBaseRS
***Livrer
***Decapsuler
***Destocker
**Paramètre
***noir
***argent
***rouge
***orange
***jaune
***bleu
***vert
***gris
***DS
***stock
***aucun
**Id
***0, 1, 2, 3, 4, 5 ou 6
 
L'exécuteur de tâches du robot concerné doit envoyer en retour :
*un booléen qui indique si l'ordre est accepté ou non
*l'ordre pris en compte
*l'Id de retour
 
Création d'un nœud ROS pour le débogage à l'aide de ddd
 
Création d'un nœud ROS pour similer l'envoi et la réception des ordres
 
 
Création de la classe action qui range les informations contenues dans le topic envoyé par l'exécuteur de tâches 
Utilisation de la classe action dans la fonction principale pour la phase de production 
Test OK cependant le traitement des informations ne se fait pas suffisamment rapidement pour une utilisation pratique
 

====Exécuteur de tâches====
L'exécuteur de taches est un noeud qui recevra des ordres de la part du générateur de taches et qui, à son tour, va envoyer des ordres aux autres noeuds.

Avec ROS, on peut communiquer entre les différents noeuds de plusieurs façons. En voici deux qui sont principalement utilisés :
* Les Topics : qui sont souvent utilisés pour publier des valeurs de données en continues
* Les services : qui permettent d'envoyer un ordre à un noeud (REQUEST) et qui permettent de recevoir de bonne réception de l'ordre (RESPONSE)

Voici le schéma de communication entre les différents noeuds, en rouge on a les services et en bleu les topics :

[[Fichier:schema2.jpg]]

===Semaine 9===
 
====Exécuteur de tâches====
Après avoir discuter avec les autres membres de l'équipe, nous avons réalisé quelques modification au niveau des communications entre l'exécuteur de taches et les autres noeuds. En fait, les services permettent d'envoyer une requête au serveur correspondant et ensuite le client reçoit une réponse de bonne réception de la requête. Alors que les topics permettent d'envoyer, à une certaine fréquence, les valeurs de variables qui correspondent à ce topic. Ainsi, on remarque qu'on aurait besoin d'utiliser un "mélange" de ces deux moyens de communication. En Ros, cela existe : les actions .

Voici donc à nouveau le schéma de communication :
[[Fichier:Schema.001.jpg]]

===Semaine 10===
 
====Exécuteur de tâches====
Afin de pouvoir tester l'interaction de l'exécuteur de taches avec les autres noeuds, nous avons du faire des "faux noeuds" étant donné que les "vrais noeuds" n'étaient pas encore terminés.

Voici une figure qui montre que l'exécuteur de taches, en haut à gauche, est en attente de recevoir des ordres du générateurs de taches, à coté de l'exécuteur :
[[Fichier:before_order.tiff | thumb]]

Ceci est une représentation de la phase d'exploration. En effet, dans cette phase l'exécuteur de taches vas recevoir un ordre du générateur de taches pour explorer une zone de la map. Il va donc demander au noeud navigation de se déplacer vers le point en bas à gauche de la zone. Dès l'arrivée, l'exécuteur de taches va demander au noeud "approche finale" de s'approcher de la machine afin de lire son ArTag. Grace à ce dernier, il pourra savoir de quelle machine s'agit-il et si le Robotino est du coté de l'entrée ou de la sortie. Parce que, en fait, s'il est en entrée l'exécuteur de taches va demander à la navigation puis l'approche finale d'aller au cotée sortie de la machine puisque la colonne de feu se trouve du coté sortie. Une fois arrivée au coté sortie, l'exécuteur de taches va demander au noeud du traitement feu de lire l'état des trois feus de la colonne FESTO.
L'interprétation des feus se fait grâce à la refereeBox. En effet, la refereeBox, publie sur un topic, un tableau avec tous les états possibles de feux avec une chaine de caractères pour chaque état. L'exécuteur va donc pouvoir récupérer la chaine de caractères correspondante aux états de feus actuels de la machine explorée. L'exécuteur peut donc maintenant identifier une machine en envoyant : la zone explorée, l'id de l'ArTag trouvé, ainsi que la chaine de caractères qui correspond au feus.

Dans la figure précédente, le générateur de taches n'avait pas encore envoyé son ordre, on peut remarquer que l'exécuteur était en attente. Une fois l'ordre envoyé, comme dans la figure suivante, l'exécuteur peut commencer à donner des ordres aux autre noeuds :
[[Fichier:after_order.tiff]] 
On remarque que l'exécuteur a communiqué avec tous les faux-noeuds pour enfin reporter une machine avec la refereeBox "fake réception refereeBox ".
Notons que fait d'utiliser des "faux-noeuds" pour tester nos algorithmes nous permet de se placer dans le cas idéale.

===Semaine 11===
 
Cette semaine était consacré à l'amélioration de nos algorithmes et à la correction des bugs ainsi qu'à l'organisation de notre voyage.
===Semaine 12===
 
Nous sommes partis à Magdebourg le mardi 21/4. Le programme de la semaine était le suivant : 
Mercredi, Jeudi : jours de SetUp. 
Nous avons profité de ses jours pour finaliser nos programmes en tant qu'équipe. Et de réaliser des tests sur la piste et de modifier nos programmes afin d'améliorer nos résultats.
Nous avons aussi réalisé un merge de toutes les branches de notre git afin de tester les interactions des noeuds entre eux. 
Vendredi,Samedi : jours de matchs 
En fonction des matches, nous modifions nos programmes afin d'améliorer nos programmes. 
Dimanche : Finale 
Nous avons finis deuxième.

== Fichiers Rendus ==

RoboCup 2015

2015-05-09T08:51:57Z

Shage-ch : /* Exécuteur de tâches */

__TOC__
 
[[Fichier:logoPyro_icone.png |center ]]
<center> Polytech RoboCup Team </center>

==Cahier des charges==
===Présentation générale du projet===

Lors de la compétition de l'Open German, prélude de la Robocup, il faudra mettre en place un système d'autonomisation de production à l'aide de Robotinos (robots mobiles de Festo ayant un système d'exploitation Linux). Comme dans toutes compétitions, le but est de gagner, par conséquent, il faudra faire en sorte de gagner un maximum de points.
C'est pourquoi il faut créer un manager à l'aide de ROS, c'est-à-dire un nœud ou ensemble de nœuds permettant de pouvoir recevoir les informations envoyées par les autres nœuds, de les traiter, tout cela afin de donner les ordres que doivent exécuter chaque Robotino. Ce manager devra également être capable d'optimiser le nombre de points à obtenir.

====Contexte====

La compétition de l'Open German se déroule en quatre phases spécifiques : phase de début-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des tâches spécifiques à remplir suivant les différentes phases. La RefereeBox est un système d'arbitrage auquel il est nécessaire d'envoyer périodiquement des données à tout moment du jeu et qui donne à chaque instant l'état du jeu ainsi que les produits demandés en priorité durant la phase de production.

====Objectif du projet====

*Assurer un maximum de points suivant les aléas du jeu (panne de machine, produits demandées, rupture de stock d'une matière première, …)
*Assurer la pérennité du projet (chaque année des candidats de Polytech Lille y participent)

====Description du projet====

Pour le projet, outre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes :
*Communication avec le nœud de la RefereeBox à tout moment du jeu
*Contrainte de robustesse (il ne faut qu'à un moment ou à un autre il n'y ait un blocage de tous les robots)
*Coopération entre les trois robots
 
[[Fichier:Interactions.png|vignette|left|upright=2|Interactions des nœuds avec le manager]]
 
Le manager devra interagir avec les différents nœuds suivants ayant chacun leurs rôles spécifiques :
*RefereeBox Comm : recevoir les données envoyées par la RefereeBox et envoyer des données suivant l'état du jeu à la RefereeBox
*Robots Comm : communiquer aux autres robots les informations concernant ce que chacun font
*Traitement des TAGs : lire les TAG
*Traitement des feux : lire l'état des colonnes de feu
*Pince de préhension : ouvrir et fermer la pince et renvoyer l'état de la pince
*Approche finale : s'adapter au banc de charge ou de décharge de produits
*Génération trajectoire : détermine une trajectoire pour aller au lieu (X,Y)
*Réalisation trajectoire : parcourir la trajectoire
*Localisation : savoir périodiquement (faible période) où se situe le robot
*Détection d'obstacle : détecter les obstacles fixes et mobiles
 

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

*Utilisation de trois robotinos
*Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce système travaille en utilisant des nœuds qui communiquent entre eux à l'aide de services (requête-réponse) et de topics (fichiers).
*Utilisation de différents langages : C++ ou Python (nœuds)
*Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS
 

===Etapes du projet===
*Prise en main de ROS et du C++
*Élaboration de l'algorithme du manager pour la phase d'exploration
*Élaboration de l'algorithme du manager pour la phase de production
**Coopération entre robots
**Répartition des tâches
*Codage du manager
*Tests et corrections
 

==Avancement du Projet==
===Semaine 1===
*Prise en main de ROS
*Réalisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials
*Réalisation de différents tutoriels C++
*Connaissance plus aiguë du sujet de l'Open German 2015
 
===Semaine 2===
*Réflexions autour de la structure du manager : deux nœuds
**Un nœud exécuteur de tâches
**Un nœud générateur de tâches
*Réflexions sur l'algorithme général du manager concernant la phase d'exploration
**Fonctionnement par zoning pour la répartition des tâches des trois robots
**Réflexion autour d'une alternative de répartition par distances les plus courtes entre machines
*Recherche de solutions pour la phase de production
**Documentation autour de la planification de tâches et la génération de tâche pour une équipe
**Recherche autour de la coopération et de l'allocation de rôles à des robots multi-tâches
*Organisation générale
**Structuration d'un échéancier numérique sous Asana
**Demande d'autorisation pour l'ouverture de la salle C002 auprès de M. Scrive
 

===Semaine 3===
Voilà un lien permettant d'accéder au sujet provisoire de la Robocup 2015 : [https://drive.google.com/file/d/0B39jN82rDE6qMG45cDN5Z0xiSVE/view?usp=sharing Sujet] 
*Réflexions au sujet des infos à communiquer au nœud AutresRobotsComm :
**Ce que le robotino fait
**Quelle machine le robotino est en train d'utiliser
[[Fichier:DataSWithRobotComm.jpg|center]]
 
*Réflexions au niveau de l'algorithme de la phase de production
**Proposition de le faire sous le principe de "Diviser pour mieux régner" (validé par M. Vincent Coelen)
***Diviser la tâche principale en sous-tâches, les sous-tâches en sous-sous-tâches et les sous-sous-tâches en sous-sous-sous-tâches élémentaires.
**Détermination des tâches à réaliser pour un exemple particulier
On souhaite produire, pendant une durée déterminée par la refBox, le produit suivant :
[[Fichier:ExempleProduitDemande.jpg|center]]
''Le produit est composé d’une base bleue, d’un ring rouge, d’un ring vert et d’un cap noir.''

'''Obtenir Base Bleue'''
->Aller à la Base Station
générateur trajectoire
exécuteur trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (dire à la Base Station quelle base est souhaitée et à quelle banc le robotino est)
approche finale
pince (prendre)

'''Obtenir ring rouge'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Obtenir ring vert'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
(Du coup la plus proche sera celle où on vient de faire le ring précédent)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Ring Station quelle base est souhaitée ( ici, la verte )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Finaliser produit'''
->Aller à une Cap Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Cap Station quelle cap est souhaité ( ici, le noir )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel banc de livraison)
approche finale
pince (prendre)
->Déposer à la Delivery Station
générateur de trajectoire (vers la Delivery Station)
exécuteur de trajectoire
approche finale
pince (déposer)
 
*Organisation générale :
**Création de la page Facebook de l'équipe PYRO Team
 

===Semaine 4===
*Écriture des sous-tâches à réaliser
**Pseudo-codes de certaines sous-tâches réalisées
*Recherche d'ordonnancement optimisé pour la fabrication du produit
**Recherche d'algorithmes
**Visualisation du problème d'ordonnancement concernant l'exemple précédent (base bleue, ring vert, ring rouge, cap noir)
 
Ici, on a pris en plus en hypothèse le fait que la Ring Station (RS1) est capable de mettre des rings rouges ou verts et que la RS2 est capable de de mettre des rings bleus et rouges. Afin de mieux appréhender le problème, nous nous sommes attachés à effectuer un tableau récapitulant les tâches à effectuer pour le produit exemple et à réaliser un graphe mettant en avant les contraintes de précédence de chaque tâche.
 

{| class="wikitable" style="text-align:center; width:80%;"

|-
|
! scope="col" | Tâches
! scope="col" | Ressources utilisées
! scope="col" | Contraintes de précédence
|-
! scope="row" | T0
| Ramener à CS base avec cap
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T1
| Décapsuler
| Cap Station 1 ou 2
| T0
|-
! scope="row" | T2
| Ramener base supplémentaires à RS
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T3
| Chercher base bleue
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T4
| Ramener à RS pour ring vert
| Robot 1, 2 ou 3
| T7
|-
! scope="row" | T5
| Ramener à RS pour ring rouge
| Robot 1, 2 ou 3
| T8
|-
! scope="row" | T6
| Ramener à CS pour cap
| Robot 1, 2 ou 3
| T9
|-
! scope="row" | T7
| Ramener Base
| Base Station
| T3
|-
! scope="row" | T8
| Ajouter ring vert
| Ring Station 1
| T4
|-
! scope="row" | T9
| Ajouter ring rouge
| Ring Station 1 ou 2
| T5 et T2
|-
! scope="row" | T10
| Ajouter cap
| Cap Station 1 ou 2
| T6 et T1
|-
! scope="row" | T11
| Traiter le produit fini
| Delivery Station
| T12
|-
! scope="row" | T12
| Ramener à DS
| Robot 1, 2 ou 3
| T10
|}
[[Fichier:TachesProduitExemple.png|center]]
<center>Graphe montrant l'ordre des tâches à réaliser</center>
 

===Semaine 5===
Durant cette semaine, nous avons réfléchi sur le choix de structures pour nos données :
* Une '''liste principale''' de tous les produits demandés par la RefBox à un instant t. Cette liste principale a les caractéristiques suivantes :
** Une '''Priorité''' sera calculée pour chaque produit avec les paramètres suivants :
*** Nombre de points que peut apporter la production d'un produit de A à Z.
*** Une estimation du temps de production d'un produit.
***La date limite de livraison du produit demandé
** Une tâche est élue si sa priorité est supérieure ou égale à celle des autres tâches.
** Quand la RefBox demande un produit, une cellule sera ajoutée dans cette liste. Et de même, quand un produit sera terminé, on le supprimera de cette liste.
* Chaque produit de la liste principale va contenir une '''liste de tâches''' correspondantes à la production de ce produit. Cette liste de tâches a les caractéristiques suivantes :
** Chaque cellule correspond à une tâche de la production d'un produit. Une tâche contient différents champs :
***Intitulé de la tâche (par exemple ajouter une base)
***Produit concernée (par exemple P3)
***Priorité de la tâche (par exemple 20)
***Temps restant estimé de production (par exemple 180s)
** A chaque fois qu'une tâche est réalisée, elle sera supprimée de la liste de tâches. Ce qui veut dire, qu'on va devoir calculé à nouveau la priorité de chaque tâche de la liste principale.
** Afin de respecter les contraintes de précédence, on considérera que la tâche en tête de la liste de tâches peut être élue. Par exemple, on ne peut pas ajouter un Ring si on n'a pas de base.
 
L'exemple suivant simule le cas où la RefBox a demandé deux fois le produit P3 et deux fois le produit P2.
*Le produit P3 est réalisable en cinq tâches.Ce produit mettra plus de temps à être fabriqué mais rapportera plus de points.
*Le produit P2 est réalisable en quatre tâches.
 
[[Fichier:listedelistes.png|center]]
<center>Structure utilisée pour ranger les tâches à réaliser</center>
 
Différentes remarques utiles :
*Avant de commencer à réaliser n'importe quel produit, il faudra au préalable vérifier si on a libérer un espace de stockage pour plusieurs raisons :
**Les Cap Stations ayant initialement aucun cap en stock, il faut les ramener de l'étagère qui en contient initialement car un produit est dit fini lorsqu'il a à son sommet un cap.
**L'étagère ayant été débarrassée d'un cap, cela permet d'avoir un espace de stockage afin de déposer des produits finis en attente de livraison ou des produits non finis dont on voudrait mettre en pause la production.
*Il sera peut être des fois plus avantageux d'abandonner temporairement la production d'un produit :
**Il vaut mieux faire en sorte de terminer un seul produit sur deux dans les temps plutôt qu'aucun car du fait de la parallélisation de la fabrication des produits, on peut être surchargé de travail.
**Un produit livré durant le laps de temps demandé rapportera plus de points non négligeables.
*Un tableau sera nécessaire afin de savoir ce qu'il y a les espaces de stockage avec les champs suivants :
**Type de produit
**Liste de tâches restantes pour la fabrication du produit (pour un produit fini cette liste est donc nulle)
**Date de début de livraison
**Date de fin de livraison
**Emplacement de l'espace de stockage
 

===Semaine 6===
*Différentes fonctions et actions en pseudo code pour le générateur de tâches
**Fonction qui retourne un booléen suivant si un produit est en stock ou non
**Fonction qui retourne un booléen suivant si on doit livrer le produit à présent ou non
**Fonction qui retourne un booléen suivant si on a déjà ou non mis le travail à faire dans la structure contenant les tâches à réaliser
**Fonction qui retourne le nombre de points que rapporte un produit passé en paramètre
**Action qui rajoute les nouveaux ordres de production dans la liste de listes de tâches
**Action qui calcule le ratio pour chaque tâche
**Action qui supprime les tâches vides (ie celles qui sont terminées)
*Début de l'écriture en pseudo code de la fonction principale
 
*Discussion avec M. Vincent Coelen concernant l'avancement du projet :
**Validation par M. Coelen Vincent des portions de pseudo code déjà écrites
**Discussion autour de la mise en place d'un arrêt immédiat des robots à tout moment du jeu
**Amélioration concernant la robustesse de l'algorithme si un robot n'est plus en état de fonctionnement
 
*Différentes remarques utiles :
**Branche concernant le manager créée sur le [https://github.com/PyroTeam/robocup-pkg/ git] de l'équipe
**Discussion avec d'autres membres de l'équipe sur les services et les topics à envoyer et à recevoir aux nœuds du manager
 
===Semaine 7===

====Générateur de tâches====
Début du codage C++ :
*Création de différentes classes :
**La classe Tache (tache.h et tache.cpp)
**La classe Stockage (stockage.h et stockage.cpp)
**La classe RefBoxComm (refboxcomm.h)
*Création de différentes fonctions :
**Dans tache.h et tache.cpp :
***point_par_produit : retourne le nombre de points que vaut un produit
***dans_les_temps : retourne un booléen indiquant s'il est temps de ramener le produit
**Dans listetaches.h et listetaches.cpp :
***creation_liste_taches_prod : retourne une liste de taches à partir d'un produit passé en paramètre
***creation_liste_taches_act : retourne une liste de taches à partir d'un produit et d'une action passés en paramètres
**Dans tableaustockage.h :
***produit_en_stock : retourne un booléen indiquant si au moins un produit est en stock
**Dans travail.h et travail.cpp :
***deja_dans_travail : retourne un booléen indiquant si un ordre de la RefBox a déjà été pris en compte dans la structure contenant les tâches à réaliser
***max_ratio : retourne l'objet Tache qui a le plus grand ratio dans la structure contenant les tâches à réaliser
***rajout_dans_travail : rajoute un nouvel ordre de la RefBox dans la structure contenant les tâches à réaliser
***calcul_ratio : calcule le ratio de chaque premier de liste de la structure contenant les tâches à réaliser
 
Les codes sont disponibles sur le [https://github.com/PyroTeam/robocup-pkg/tree/feature/manager/generateur_taches git]
 
Des tests ont été réalisés afin de valider les fonctions crées en particulier les fonctions contenues dans travail.h et travail.cpp
 
Voici un petit aperçu de la console :
 
[[Fichier:Capture terminal gen taches 3.png|800px]]
 
Ainsi, les quatres fonctions fonctionnent parfaitement :
*deja_dans_travail indique bien que l'ordre de la RefBox n'a pas encore pris en compte
*max_ratio retourne bien la tâche dont le ratio est maximum
*rajout_dans_travail rajoute en fin de liste la liste de tâches pour la première création d'un produit P0 car un cap est disponible , puis il concatène une liste contenant en tête la tâche "Decapsuler" avec la liste de tâches pour la seconde création d'un produit P0. En effet, la RefBox a demandé deux fois le produit P0 et on ne peut créer un produit tant qu'un cap n'est pas disponible.
*calcul_ratio calcule le ratio de chaque première tâche en fonction du nombre de points et du temps, de plus, si c'est le bon moment pour déstocker un produit il passe cette tâche "Destocker" en priorité (liste 6), en outre, la création d'un produit (liste 1 et liste 7) est prioritaire à l'unique tâche "Decapsuler" (listes 2, 3, 4 et 5) .
 
'''Nous avons enfin reçu le sujet 2015 pour la compétition 2015, il est disponible [https://drive.google.com/file/d/0B39jN82rDE6qSk11YXFuQVljTlE/view?usp=sharing ici]'''
 
*Modification à réaliser :
**la fonction de création de liste de tâches
**l'ordonnancement (en partie)
**calcul de ratio de chaque tâche

====Exécuteur de tâches====
L'éxécuteur de taches va recevoir des ordres de la part du générateur de taches . En fonction de ces ordres, il enverra des demandes d'exécution/d'informations aux autres noeuds. Il y a donc un seul générateur de taches et trois exécuteurs de taches ( on a trois robotinos ).
Voici les classes qui correspondent à chaque exécuteur de taches :
[[Fichier:shema1.png]]
*'''Machine''' est une classe abstraite qui servira à la création des quatre classes filles qui représenteront les quatre machines de la compétition.
** ''string type'' sera donc BaseStation, RingStation, CapStation ou DeliveryStation.
** ''Pose2D centreMachine'' est un point(x,y,theta) qui va correspondre au retour du noeud de localisation (Projet 36)
** ''Pose2D entreeMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour déposer un produit
** ''Pose2D sortieMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour prendre un produit
*'''BaseStation''' est une classe fille de la classe "Machine".
** ''int baseRouge'', ''int baseNoir'' et ''int baseArgent'' vont correspondre aux nombres de bases rouges, bases noires, base argentes respectivement.
*'''RingStation''' est une classe fille de la classe "Machine".
** ''int ringVert'', ''int ringJaune'', ''int ringBleu'' et ''ringOrange'' vont correspondre aux nombres de rings verts, rings jaunes, rings bleus et rings oranges respectivement.
*'''CapStation''' est une classe fille de la classe "Machine".
** ''int capNoir'' et ''int capGris'' vont correspondre aux nombres de caps noirs et caps gris respectivement.
** ''int stock[3]'' est un tableau qui va correspondre aux trois emplacements stockage de la capStation.
** 'Pose2D stockage'' est un point(x,y,theta) qui correspond à l'emplacement de la première zone de stockage.

===Semaine 8===
====Générateur de tâches====
*Création du service pour l'envoi des ordres pour l’exécuteur de tâches avec pour contenu:
**Numéro du robot
***1, 2 ou 3
**Ordre
***ChercherBase
***MettreCap
***ChercherCap
***MettreRing
***ChercherRing
***RamenerBaseRS
***Livrer
***Decapsuler
***Destocker
**Paramètre
***noir
***argent
***rouge
***orange
***jaune
***bleu
***vert
***gris
***DS
***stock
***aucun
**Id
***0, 1, 2, 3, 4, 5 ou 6
 
L'exécuteur de tâches du robot concerné doit envoyer en retour :
*un booléen qui indique si l'ordre est accepté ou non
*l'ordre pris en compte
*l'Id de retour
 
Création d'un nœud ROS pour le débogage à l'aide de ddd
 
Création d'un nœud ROS pour similer l'envoi et la réception des ordres
 
 
Création de la classe action qui range les informations contenues dans le topic envoyé par l'exécuteur de tâches 
Utilisation de la classe action dans la fonction principale pour la phase de production 
Test OK cependant le traitement des informations ne se fait pas suffisamment rapidement pour une utilisation pratique
 

====Exécuteur de tâches====
L'exécuteur de taches est un noeud qui recevra des ordres de la part du générateur de taches et qui, à son tour, va envoyer des ordres aux autres noeuds.

Avec ROS, on peut communiquer entre les différents noeuds de plusieurs façons. En voici deux qui sont principalement utilisés :
* Les Topics : qui sont souvent utilisés pour publier des valeurs de données en continues
* Les services : qui permettent d'envoyer un ordre à un noeud (REQUEST) et qui permettent de recevoir de bonne réception de l'ordre (RESPONSE)

Voici le schéma de communication entre les différents noeuds, en rouge on a les services et en bleu les topics :

[[Fichier:schema2.jpg]]

===Semaine 9===
 
====Exécuteur de tâches====
Après avoir discuter avec les autres membres de l'équipe, nous avons réalisé quelques modification au niveau des communications entre l'exécuteur de taches et les autres noeuds. En fait, les services permettent d'envoyer une requête au serveur correspondant et ensuite le client reçoit une réponse de bonne réception de la requête. Alors que les topics permettent d'envoyer, à une certaine fréquence, les valeurs de variables qui correspondent à ce topic. Ainsi, on remarque qu'on aurait besoin d'utiliser un "mélange" de ces deux moyens de communication. En Ros, cela existe : les actions .

Voici donc à nouveau le schéma de communication :
[[Fichier:Schema.001.jpg]]

===Semaine 10===
 
====Exécuteur de tâches====
Afin de pouvoir tester l'interaction de l'exécuteur de taches avec les autres noeuds, nous avons du faire des "faux noeuds" étant donné que les "vrais noeuds" n'étaient pas encore terminés.

Voici une figure qui montre que l'exécuteur de taches, en haut à gauche, est en attente de recevoir des ordres du générateurs de taches, à coté de l'exécuteur :
[[Fichier:before_order.tiff | thumb]]

Ceci est une représentation de la phase d'exploration. En effet, dans cette phase l'exécuteur de taches vas recevoir un ordre du générateur de taches pour explorer une zone de la map. Il va donc demander au noeud localisation de se déplacer vers le point en bas à gauche de la zone. Dès l'arrivée, l'exécuteur de taches va demander au noeud "approche finale" de s'approcher de la machine afin de lire son ArTag. Grace à ce dernier, il pourra savoir de quelle machine s'agit-il et si le Robotino est du coté de l'entrée ou de la sortie. Parce que, en fait, s'il est en entrée l'exécuteur de taches va demander à la navigation puis l'approche finale d'aller au cotée sortie de la machine puisque la colonne de feu se trouve du coté sortie. Une fois arrivée au coté sortie, l'exécuteur de taches va demander au noeud du traitement feu de lire l'état des trois feus de la colonne FESTO.
L'interprétation des feus se fait grâce à la refereeBox. En effet, la refereeBox, publie sur un topic, un tableau avec tous les états possibles de feux avec une chaine de caractères pour chaque état. L'exécuteur va donc pouvoir récupérer la chaine de caractères correspondante aux états de feus actuels de la machine explorée. L'exécuteur peut donc maintenant identifier une machine en envoyant : la zone explorée, l'id de l'ArTag trouvé, ainsi que la chaine de caractères qui correspond au feus.

Dans la figure précédente, le générateur de taches n'avait pas encore envoyé son ordre, on peut remarquer que l'exécuteur était en attente. Une fois l'ordre envoyé, comme dans la figure suivante, l'exécuteur peut commencer à donner des ordres aux autre noeuds :
[[Fichier:after_order.tiff]] 
On remarque que l'exécuteur a communiqué avec tous les faux-noeuds pour enfin reporter une machine avec la refereeBox "fake réception refereeBox ".
Notons que fait d'utiliser des "faux-noeuds" pour tester nos algorithmes nous permet de se placer dans le cas idéale.

===Semaine 11===
 
Cette semaine était consacré à l'amélioration de nos algorithmes et à la correction des bugs ainsi qu'à l'organisation de notre voyage.
===Semaine 12===
 
Nous sommes partis à Magdebourg le mardi 21/4. Le programme de la semaine était le suivant : 
Mercredi, Jeudi : jours de SetUp. 
Nous avons profité de ses jours pour finaliser nos programmes en tant qu'équipe. Et de réaliser des tests sur la piste et de modifier nos programmes afin d'améliorer nos résultats.
Nous avons aussi réalisé un merge de toutes les branches de notre git afin de tester les interactions des noeuds entre eux. 
Vendredi,Samedi : jours de matchs 
En fonction des matches, nous modifions nos programmes afin d'améliorer nos programmes. 
Dimanche : Finale 
Nous avons finis deuxième.

== Fichiers Rendus ==

RoboCup 2015

2015-05-05T16:44:23Z

Shage-ch :

__TOC__
 
[[Fichier:logoPyro_icone.png |center ]]
<center> Polytech RoboCup Team </center>

==Cahier des charges==
===Présentation générale du projet===

Lors de la compétition de l'Open German, prélude de la Robocup, il faudra mettre en place un système d'autonomisation de production à l'aide de Robotinos (robots mobiles de Festo ayant un système d'exploitation Linux). Comme dans toutes compétitions, le but est de gagner, par conséquent, il faudra faire en sorte de gagner un maximum de points.
C'est pourquoi il faut créer un manager à l'aide de ROS, c'est-à-dire un nœud ou ensemble de nœuds permettant de pouvoir recevoir les informations envoyées par les autres nœuds, de les traiter, tout cela afin de donner les ordres que doivent exécuter chaque Robotino. Ce manager devra également être capable d'optimiser le nombre de points à obtenir.

====Contexte====

La compétition de l'Open German se déroule en quatre phases spécifiques : phase de début-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des tâches spécifiques à remplir suivant les différentes phases. La RefereeBox est un système d'arbitrage auquel il est nécessaire d'envoyer périodiquement des données à tout moment du jeu et qui donne à chaque instant l'état du jeu ainsi que les produits demandés en priorité durant la phase de production.

====Objectif du projet====

*Assurer un maximum de points suivant les aléas du jeu (panne de machine, produits demandées, rupture de stock d'une matière première, …)
*Assurer la pérennité du projet (chaque année des candidats de Polytech Lille y participent)

====Description du projet====

Pour le projet, outre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes :
*Communication avec le nœud de la RefereeBox à tout moment du jeu
*Contrainte de robustesse (il ne faut qu'à un moment ou à un autre il n'y ait un blocage de tous les robots)
*Coopération entre les trois robots
 
[[Fichier:Interactions.png|vignette|left|upright=2|Interactions des nœuds avec le manager]]
 
Le manager devra interagir avec les différents nœuds suivants ayant chacun leurs rôles spécifiques :
*RefereeBox Comm : recevoir les données envoyées par la RefereeBox et envoyer des données suivant l'état du jeu à la RefereeBox
*Robots Comm : communiquer aux autres robots les informations concernant ce que chacun font
*Traitement des TAGs : lire les TAG
*Traitement des feux : lire l'état des colonnes de feu
*Pince de préhension : ouvrir et fermer la pince et renvoyer l'état de la pince
*Approche finale : s'adapter au banc de charge ou de décharge de produits
*Génération trajectoire : détermine une trajectoire pour aller au lieu (X,Y)
*Réalisation trajectoire : parcourir la trajectoire
*Localisation : savoir périodiquement (faible période) où se situe le robot
*Détection d'obstacle : détecter les obstacles fixes et mobiles
 

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

*Utilisation de trois robotinos
*Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce système travaille en utilisant des nœuds qui communiquent entre eux à l'aide de services (requête-réponse) et de topics (fichiers).
*Utilisation de différents langages : C++ ou Python (nœuds)
*Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS
 

===Etapes du projet===
*Prise en main de ROS et du C++
*Élaboration de l'algorithme du manager pour la phase d'exploration
*Élaboration de l'algorithme du manager pour la phase de production
**Coopération entre robots
**Répartition des tâches
*Codage du manager
*Tests et corrections
 

==Avancement du Projet==
===Semaine 1===
*Prise en main de ROS
*Réalisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials
*Réalisation de différents tutoriels C++
*Connaissance plus aiguë du sujet de l'Open German 2015
 
===Semaine 2===
*Réflexions autour de la structure du manager : deux nœuds
**Un nœud exécuteur de tâches
**Un nœud générateur de tâches
*Réflexions sur l'algorithme général du manager concernant la phase d'exploration
**Fonctionnement par zoning pour la répartition des tâches des trois robots
**Réflexion autour d'une alternative de répartition par distances les plus courtes entre machines
*Recherche de solutions pour la phase de production
**Documentation autour de la planification de tâches et la génération de tâche pour une équipe
**Recherche autour de la coopération et de l'allocation de rôles à des robots multi-tâches
*Organisation générale
**Structuration d'un échéancier numérique sous Asana
**Demande d'autorisation pour l'ouverture de la salle C002 auprès de M. Scrive
 

===Semaine 3===
Voilà un lien permettant d'accéder au sujet provisoire de la Robocup 2015 : [https://drive.google.com/file/d/0B39jN82rDE6qMG45cDN5Z0xiSVE/view?usp=sharing Sujet] 
*Réflexions au sujet des infos à communiquer au nœud AutresRobotsComm :
**Ce que le robotino fait
**Quelle machine le robotino est en train d'utiliser
[[Fichier:DataSWithRobotComm.jpg|center]]
 
*Réflexions au niveau de l'algorithme de la phase de production
**Proposition de le faire sous le principe de "Diviser pour mieux régner" (validé par M. Vincent Coelen)
***Diviser la tâche principale en sous-tâches, les sous-tâches en sous-sous-tâches et les sous-sous-tâches en sous-sous-sous-tâches élémentaires.
**Détermination des tâches à réaliser pour un exemple particulier
On souhaite produire, pendant une durée déterminée par la refBox, le produit suivant :
[[Fichier:ExempleProduitDemande.jpg|center]]
''Le produit est composé d’une base bleue, d’un ring rouge, d’un ring vert et d’un cap noir.''

'''Obtenir Base Bleue'''
->Aller à la Base Station
générateur trajectoire
exécuteur trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (dire à la Base Station quelle base est souhaitée et à quelle banc le robotino est)
approche finale
pince (prendre)

'''Obtenir ring rouge'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Obtenir ring vert'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
(Du coup la plus proche sera celle où on vient de faire le ring précédent)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Ring Station quelle base est souhaitée ( ici, la verte )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Finaliser produit'''
->Aller à une Cap Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Cap Station quelle cap est souhaité ( ici, le noir )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel banc de livraison)
approche finale
pince (prendre)
->Déposer à la Delivery Station
générateur de trajectoire (vers la Delivery Station)
exécuteur de trajectoire
approche finale
pince (déposer)
 
*Organisation générale :
**Création de la page Facebook de l'équipe PYRO Team
 

===Semaine 4===
*Écriture des sous-tâches à réaliser
**Pseudo-codes de certaines sous-tâches réalisées
*Recherche d'ordonnancement optimisé pour la fabrication du produit
**Recherche d'algorithmes
**Visualisation du problème d'ordonnancement concernant l'exemple précédent (base bleue, ring vert, ring rouge, cap noir)
 
Ici, on a pris en plus en hypothèse le fait que la Ring Station (RS1) est capable de mettre des rings rouges ou verts et que la RS2 est capable de de mettre des rings bleus et rouges. Afin de mieux appréhender le problème, nous nous sommes attachés à effectuer un tableau récapitulant les tâches à effectuer pour le produit exemple et à réaliser un graphe mettant en avant les contraintes de précédence de chaque tâche.
 

{| class="wikitable" style="text-align:center; width:80%;"

|-
|
! scope="col" | Tâches
! scope="col" | Ressources utilisées
! scope="col" | Contraintes de précédence
|-
! scope="row" | T0
| Ramener à CS base avec cap
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T1
| Décapsuler
| Cap Station 1 ou 2
| T0
|-
! scope="row" | T2
| Ramener base supplémentaires à RS
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T3
| Chercher base bleue
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T4
| Ramener à RS pour ring vert
| Robot 1, 2 ou 3
| T7
|-
! scope="row" | T5
| Ramener à RS pour ring rouge
| Robot 1, 2 ou 3
| T8
|-
! scope="row" | T6
| Ramener à CS pour cap
| Robot 1, 2 ou 3
| T9
|-
! scope="row" | T7
| Ramener Base
| Base Station
| T3
|-
! scope="row" | T8
| Ajouter ring vert
| Ring Station 1
| T4
|-
! scope="row" | T9
| Ajouter ring rouge
| Ring Station 1 ou 2
| T5 et T2
|-
! scope="row" | T10
| Ajouter cap
| Cap Station 1 ou 2
| T6 et T1
|-
! scope="row" | T11
| Traiter le produit fini
| Delivery Station
| T12
|-
! scope="row" | T12
| Ramener à DS
| Robot 1, 2 ou 3
| T10
|}
[[Fichier:TachesProduitExemple.png|center]]
<center>Graphe montrant l'ordre des tâches à réaliser</center>
 

===Semaine 5===
Durant cette semaine, nous avons réfléchi sur le choix de structures pour nos données :
* Une '''liste principale''' de tous les produits demandés par la RefBox à un instant t. Cette liste principale a les caractéristiques suivantes :
** Une '''Priorité''' sera calculée pour chaque produit avec les paramètres suivants :
*** Nombre de points que peut apporter la production d'un produit de A à Z.
*** Une estimation du temps de production d'un produit.
***La date limite de livraison du produit demandé
** Une tâche est élue si sa priorité est supérieure ou égale à celle des autres tâches.
** Quand la RefBox demande un produit, une cellule sera ajoutée dans cette liste. Et de même, quand un produit sera terminé, on le supprimera de cette liste.
* Chaque produit de la liste principale va contenir une '''liste de tâches''' correspondantes à la production de ce produit. Cette liste de tâches a les caractéristiques suivantes :
** Chaque cellule correspond à une tâche de la production d'un produit. Une tâche contient différents champs :
***Intitulé de la tâche (par exemple ajouter une base)
***Produit concernée (par exemple P3)
***Priorité de la tâche (par exemple 20)
***Temps restant estimé de production (par exemple 180s)
** A chaque fois qu'une tâche est réalisée, elle sera supprimée de la liste de tâches. Ce qui veut dire, qu'on va devoir calculé à nouveau la priorité de chaque tâche de la liste principale.
** Afin de respecter les contraintes de précédence, on considérera que la tâche en tête de la liste de tâches peut être élue. Par exemple, on ne peut pas ajouter un Ring si on n'a pas de base.
 
L'exemple suivant simule le cas où la RefBox a demandé deux fois le produit P3 et deux fois le produit P2.
*Le produit P3 est réalisable en cinq tâches.Ce produit mettra plus de temps à être fabriqué mais rapportera plus de points.
*Le produit P2 est réalisable en quatre tâches.
 
[[Fichier:listedelistes.png|center]]
<center>Structure utilisée pour ranger les tâches à réaliser</center>
 
Différentes remarques utiles :
*Avant de commencer à réaliser n'importe quel produit, il faudra au préalable vérifier si on a libérer un espace de stockage pour plusieurs raisons :
**Les Cap Stations ayant initialement aucun cap en stock, il faut les ramener de l'étagère qui en contient initialement car un produit est dit fini lorsqu'il a à son sommet un cap.
**L'étagère ayant été débarrassée d'un cap, cela permet d'avoir un espace de stockage afin de déposer des produits finis en attente de livraison ou des produits non finis dont on voudrait mettre en pause la production.
*Il sera peut être des fois plus avantageux d'abandonner temporairement la production d'un produit :
**Il vaut mieux faire en sorte de terminer un seul produit sur deux dans les temps plutôt qu'aucun car du fait de la parallélisation de la fabrication des produits, on peut être surchargé de travail.
**Un produit livré durant le laps de temps demandé rapportera plus de points non négligeables.
*Un tableau sera nécessaire afin de savoir ce qu'il y a les espaces de stockage avec les champs suivants :
**Type de produit
**Liste de tâches restantes pour la fabrication du produit (pour un produit fini cette liste est donc nulle)
**Date de début de livraison
**Date de fin de livraison
**Emplacement de l'espace de stockage
 

===Semaine 6===
*Différentes fonctions et actions en pseudo code pour le générateur de tâches
**Fonction qui retourne un booléen suivant si un produit est en stock ou non
**Fonction qui retourne un booléen suivant si on doit livrer le produit à présent ou non
**Fonction qui retourne un booléen suivant si on a déjà ou non mis le travail à faire dans la structure contenant les tâches à réaliser
**Fonction qui retourne le nombre de points que rapporte un produit passé en paramètre
**Action qui rajoute les nouveaux ordres de production dans la liste de listes de tâches
**Action qui calcule le ratio pour chaque tâche
**Action qui supprime les tâches vides (ie celles qui sont terminées)
*Début de l'écriture en pseudo code de la fonction principale
 
*Discussion avec M. Vincent Coelen concernant l'avancement du projet :
**Validation par M. Coelen Vincent des portions de pseudo code déjà écrites
**Discussion autour de la mise en place d'un arrêt immédiat des robots à tout moment du jeu
**Amélioration concernant la robustesse de l'algorithme si un robot n'est plus en état de fonctionnement
 
*Différentes remarques utiles :
**Branche concernant le manager créée sur le [https://github.com/PyroTeam/robocup-pkg/ git] de l'équipe
**Discussion avec d'autres membres de l'équipe sur les services et les topics à envoyer et à recevoir aux nœuds du manager
 
===Semaine 7===

====Générateur de tâches====
Début du codage C++ :
*Création de différentes classes :
**La classe Tache (tache.h et tache.cpp)
**La classe Stockage (stockage.h et stockage.cpp)
**La classe RefBoxComm (refboxcomm.h)
*Création de différentes fonctions :
**Dans tache.h et tache.cpp :
***point_par_produit : retourne le nombre de points que vaut un produit
***dans_les_temps : retourne un booléen indiquant s'il est temps de ramener le produit
**Dans listetaches.h et listetaches.cpp :
***creation_liste_taches_prod : retourne une liste de taches à partir d'un produit passé en paramètre
***creation_liste_taches_act : retourne une liste de taches à partir d'un produit et d'une action passés en paramètres
**Dans tableaustockage.h :
***produit_en_stock : retourne un booléen indiquant si au moins un produit est en stock
**Dans travail.h et travail.cpp :
***deja_dans_travail : retourne un booléen indiquant si un ordre de la RefBox a déjà été pris en compte dans la structure contenant les tâches à réaliser
***max_ratio : retourne l'objet Tache qui a le plus grand ratio dans la structure contenant les tâches à réaliser
***rajout_dans_travail : rajoute un nouvel ordre de la RefBox dans la structure contenant les tâches à réaliser
***calcul_ratio : calcule le ratio de chaque premier de liste de la structure contenant les tâches à réaliser
 
Les codes sont disponibles sur le [https://github.com/PyroTeam/robocup-pkg/tree/feature/manager/generateur_taches git]
 
Des tests ont été réalisés afin de valider les fonctions crées en particulier les fonctions contenues dans travail.h et travail.cpp
 
Voici un petit aperçu de la console :
 
[[Fichier:Capture terminal gen taches 3.png|800px]]
 
Ainsi, les quatres fonctions fonctionnent parfaitement :
*deja_dans_travail indique bien que l'ordre de la RefBox n'a pas encore pris en compte
*max_ratio retourne bien la tâche dont le ratio est maximum
*rajout_dans_travail rajoute en fin de liste la liste de tâches pour la première création d'un produit P0 car un cap est disponible , puis il concatène une liste contenant en tête la tâche "Decapsuler" avec la liste de tâches pour la seconde création d'un produit P0. En effet, la RefBox a demandé deux fois le produit P0 et on ne peut créer un produit tant qu'un cap n'est pas disponible.
*calcul_ratio calcule le ratio de chaque première tâche en fonction du nombre de points et du temps, de plus, si c'est le bon moment pour déstocker un produit il passe cette tâche "Destocker" en priorité (liste 6), en outre, la création d'un produit (liste 1 et liste 7) est prioritaire à l'unique tâche "Decapsuler" (listes 2, 3, 4 et 5) .
 
'''Nous avons enfin reçu le sujet 2015 pour la compétition 2015, il est disponible [https://drive.google.com/file/d/0B39jN82rDE6qSk11YXFuQVljTlE/view?usp=sharing ici]'''
 
*Modification à réaliser :
**la fonction de création de liste de tâches
**l'ordonnancement (en partie)
**calcul de ratio de chaque tâche

====Exécuteur de tâches====
L'éxécuteur de taches va recevoir des ordres de la part du générateur de taches . En fonction de ces ordres, il enverra des demandes d'exécution/d'informations aux autres noeuds. Il y a donc un seul générateur de taches et trois exécuteurs de taches ( on a trois robotinos ).
Voici les classes qui correspondent à chaque exécuteur de taches :
[[Fichier:shema1.png]]
*'''Machine''' est une classe abstraite qui servira à la création des quatre classes filles qui représenteront les quatre machines de la compétition.
** ''string type'' sera donc BaseStation, RingStation, CapStation ou DeliveryStation.
** ''Pose2D centreMachine'' est un point(x,y,theta) qui va correspondre au retour du noeud de localisation (Projet 36)
** ''Pose2D entreeMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour déposer un produit
** ''Pose2D sortieMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour prendre un produit
*'''BaseStation''' est une classe fille de la classe "Machine".
** ''int baseRouge'', ''int baseNoir'' et ''int baseArgent'' vont correspondre aux nombres de bases rouges, bases noires, base argentes respectivement.
*'''RingStation''' est une classe fille de la classe "Machine".
** ''int ringVert'', ''int ringJaune'', ''int ringBleu'' et ''ringOrange'' vont correspondre aux nombres de rings verts, rings jaunes, rings bleus et rings oranges respectivement.
*'''CapStation''' est une classe fille de la classe "Machine".
** ''int capNoir'' et ''int capGris'' vont correspondre aux nombres de caps noirs et caps gris respectivement.
** ''int stock[3]'' est un tableau qui va correspondre aux trois emplacements stockage de la capStation.
** 'Pose2D stockage'' est un point(x,y,theta) qui correspond à l'emplacement de la première zone de stockage.

===Semaine 8===
====Générateur de tâches====
*Création du service pour l'envoi des ordres pour l’exécuteur de tâches avec pour contenu:
**Numéro du robot
***1, 2 ou 3
**Ordre
***ChercherBase
***MettreCap
***ChercherCap
***MettreRing
***ChercherRing
***RamenerBaseRS
***Livrer
***Decapsuler
***Destocker
**Paramètre
***noir
***argent
***rouge
***orange
***jaune
***bleu
***vert
***gris
***DS
***stock
***aucun
**Id
***0, 1, 2, 3, 4, 5 ou 6
 
L'exécuteur de tâches du robot concerné doit envoyer en retour :
*un booléen qui indique si l'ordre est accepté ou non
*l'ordre pris en compte
*l'Id de retour
 
Création d'un nœud ROS pour le débogage à l'aide de ddd
 
Création d'un nœud ROS pour similer l'envoi et la réception des ordres
 
 
Création de la classe action qui range les informations contenues dans le topic envoyé par l'exécuteur de tâches 
Utilisation de la classe action dans la fonction principale pour la phase de production 
Test OK cependant le traitement des informations ne se fait pas suffisamment rapidement pour une utilisation pratique
 

====Exécuteur de tâches====
L'exécuteur de taches est un noeud qui recevra des ordres de la part du générateur de taches et qui, à son tour, va envoyer des ordres aux autres noeuds.

Avec ROS, on peut communiquer entre les différents noeuds de plusieurs façons. En voici deux qui sont principalement utilisés :
* Les Topics : qui sont souvent utilisés pour publier des valeurs de données en continues
* Les services : qui permettent d'envoyer un ordre à un noeud (REQUEST) et qui permettent de recevoir de bonne réception de l'ordre (RESPONSE)

Voici le schéma de communication entre les différents noeuds, en rouge on a les services et en bleu les topics :

[[Fichier:schema2.jpg]]

===Semaine 9===
 
====Exécuteur de tâches====
Après avoir discuter avec les autres membres de l'équipe, nous avons réalisé quelques modification au niveau des communications entre l'exécuteur de taches et les autres noeuds. En fait, les services permettent d'envoyer une requête au serveur correspondant et ensuite le client reçoit une réponse de bonne réception de la requête. Alors que les topics permettent d'envoyer, à une certaine fréquence, les valeurs de variables qui correspondent à ce topic. Ainsi, on remarque qu'on aurait besoin d'utiliser un "mélange" de ces deux moyens de communication. En Ros, cela existe : les actions .

Voici donc à nouveau le schéma de communication :
[[Fichier:Schema.001.jpg]]

===Semaine 10===
 
====Exécuteur de tâches====
Afin de pouvoir tester l'interaction de l'exécuteur de taches avec les autres noeuds, nous avons du faire des "faux noeuds" étant donné que les "vrais noeuds" n'étaient pas encore terminés.

Voici une figure qui montre que l'exécuteur de taches, en haut à gauche, est en attente de recevoir des ordres du générateurs de taches, à coté de l'exécuteur :
[[Fichier:before_order.tiff]]

Ceci est une représentation de la phase d'exploration. En effet, dans cette phase l'exécuteur de taches vas recevoir un ordre du générateur de taches pour explorer une zone de la map. Il va donc demander au noeud localisation de se déplacer vers le point en bas à gauche de la zone. Dès l'arrivée, l'exécuteur de taches va demander au noeud "approche finale" de s'approcher de la machine afin de lire son ArTag. Grace à ce dernier, il pourra savoir de quelle machine s'agit-il et si le Robotino est du coté de l'entrée ou de la sortie. Parce que, en fait, s'il est en entrée l'exécuteur de taches va demander à la navigation puis l'approche finale d'aller au cotée sortie de la machine puisque la colonne de feu se trouve du coté sortie. Une fois arrivée au coté sortie, l'exécuteur de taches va demander au noeud du traitement feu de lire l'état des trois feus de la colonne FESTO.
L'interprétation des feus se fait grâce à la refereeBox. En effet, la refereeBox, publie sur un topic, un tableau avec tous les états possibles de feux avec une chaine de caractères pour chaque état. L'exécuteur va donc pouvoir récupérer la chaine de caractères correspondante aux états de feus actuels de la machine explorée. L'exécuteur peut donc maintenant identifier une machine en envoyant : la zone explorée, l'id de l'ArTag trouvé, ainsi que la chaine de caractères qui correspond au feus.

Dans la figure précédente, le générateur de taches n'avait pas encore envoyé son ordre, on peut remarquer que l'exécuteur était en attente. Une fois l'ordre envoyé, comme dans la figure suivante, l'exécuteur peut commencer à donner des ordres aux autre noeuds :
[[Fichier:after_order.tiff]] 
On remarque que l'exécuteur a communiqué avec tous les faux-noeuds pour enfin reporter une machine avec la refereeBox "fake réception refereeBox ".
Notons que fait d'utiliser des "faux-noeuds" pour tester nos algorithmes nous permet de se placer dans le cas idéale.

===Semaine 11===
 
Cette semaine était consacré à l'amélioration de nos algorithmes et à la correction des bugs ainsi qu'à l'organisation de notre voyage.
===Semaine 12===
 
Nous sommes partis à Magdebourg le mardi 21/4. Le programme de la semaine était le suivant : 
Mercredi, Jeudi : jours de SetUp. 
Nous avons profité de ses jours pour finaliser nos programmes en tant qu'équipe. Et de réaliser des tests sur la piste et de modifier nos programmes afin d'améliorer nos résultats.
Nous avons aussi réalisé un merge de toutes les branches de notre git afin de tester les interactions des noeuds entre eux. 
Vendredi,Samedi : jours de matchs 
En fonction des matches, nous modifions nos programmes afin d'améliorer nos programmes. 
Dimanche : Finale 
Nous avons finis deuxième.

== Fichiers Rendus ==

RoboCup 2015

2015-05-05T14:19:15Z

Shage-ch : /* Exécuteur de tâches */

__TOC__
 
[[Fichier:logoPyro_icone.png |center ]]
<center> Polytech RoboCup Team </center>

==Cahier des charges==
===Présentation générale du projet===

Lors de la compétition de l'Open German, prélude de la Robocup, il faudra mettre en place un système d'autonomisation de production à l'aide de Robotinos (robots mobiles de Festo ayant un système d'exploitation Linux). Comme dans toutes compétitions, le but est de gagner, par conséquent, il faudra faire en sorte de gagner un maximum de points.
C'est pourquoi il faut créer un manager à l'aide de ROS, c'est-à-dire un nœud ou ensemble de nœuds permettant de pouvoir recevoir les informations envoyées par les autres nœuds, de les traiter, tout cela afin de donner les ordres que doivent exécuter chaque Robotino. Ce manager devra également être capable d'optimiser le nombre de points à obtenir.

====Contexte====

La compétition de l'Open German se déroule en quatre phases spécifiques : phase de début-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des tâches spécifiques à remplir suivant les différentes phases. La RefereeBox est un système d'arbitrage auquel il est nécessaire d'envoyer périodiquement des données à tout moment du jeu et qui donne à chaque instant l'état du jeu ainsi que les produits demandés en priorité durant la phase de production.

====Objectif du projet====

*Assurer un maximum de points suivant les aléas du jeu (panne de machine, produits demandées, rupture de stock d'une matière première, …)
*Assurer la pérennité du projet (chaque année des candidats de Polytech Lille y participent)

====Description du projet====

Pour le projet, outre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes :
*Communication avec le nœud de la RefereeBox à tout moment du jeu
*Contrainte de robustesse (il ne faut qu'à un moment ou à un autre il n'y ait un blocage de tous les robots)
*Coopération entre les trois robots
 
[[Fichier:Interactions.png|vignette|left|upright=2|Interactions des nœuds avec le manager]]
 
Le manager devra interagir avec les différents nœuds suivants ayant chacun leurs rôles spécifiques :
*RefereeBox Comm : recevoir les données envoyées par la RefereeBox et envoyer des données suivant l'état du jeu à la RefereeBox
*Robots Comm : communiquer aux autres robots les informations concernant ce que chacun font
*Traitement des TAGs : lire les TAG
*Traitement des feux : lire l'état des colonnes de feu
*Pince de préhension : ouvrir et fermer la pince et renvoyer l'état de la pince
*Approche finale : s'adapter au banc de charge ou de décharge de produits
*Génération trajectoire : détermine une trajectoire pour aller au lieu (X,Y)
*Réalisation trajectoire : parcourir la trajectoire
*Localisation : savoir périodiquement (faible période) où se situe le robot
*Détection d'obstacle : détecter les obstacles fixes et mobiles
 

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

*Utilisation de trois robotinos
*Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce système travaille en utilisant des nœuds qui communiquent entre eux à l'aide de services (requête-réponse) et de topics (fichiers).
*Utilisation de différents langages : C++ ou Python (nœuds)
*Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS
 

===Etapes du projet===
*Prise en main de ROS et du C++
*Élaboration de l'algorithme du manager pour la phase d'exploration
*Élaboration de l'algorithme du manager pour la phase de production
**Coopération entre robots
**Répartition des tâches
*Codage du manager
*Tests et corrections
 

==Avancement du Projet==
===Semaine 1===
*Prise en main de ROS
*Réalisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials
*Réalisation de différents tutoriels C++
*Connaissance plus aiguë du sujet de l'Open German 2015
 
===Semaine 2===
*Réflexions autour de la structure du manager : deux nœuds
**Un nœud exécuteur de tâches
**Un nœud générateur de tâches
*Réflexions sur l'algorithme général du manager concernant la phase d'exploration
**Fonctionnement par zoning pour la répartition des tâches des trois robots
**Réflexion autour d'une alternative de répartition par distances les plus courtes entre machines
*Recherche de solutions pour la phase de production
**Documentation autour de la planification de tâches et la génération de tâche pour une équipe
**Recherche autour de la coopération et de l'allocation de rôles à des robots multi-tâches
*Organisation générale
**Structuration d'un échéancier numérique sous Asana
**Demande d'autorisation pour l'ouverture de la salle C002 auprès de M. Scrive
 

===Semaine 3===
Voilà un lien permettant d'accéder au sujet provisoire de la Robocup 2015 : [https://drive.google.com/file/d/0B39jN82rDE6qMG45cDN5Z0xiSVE/view?usp=sharing Sujet] 
*Réflexions au sujet des infos à communiquer au nœud AutresRobotsComm :
**Ce que le robotino fait
**Quelle machine le robotino est en train d'utiliser
[[Fichier:DataSWithRobotComm.jpg|center]]
 
*Réflexions au niveau de l'algorithme de la phase de production
**Proposition de le faire sous le principe de "Diviser pour mieux régner" (validé par M. Vincent Coelen)
***Diviser la tâche principale en sous-tâches, les sous-tâches en sous-sous-tâches et les sous-sous-tâches en sous-sous-sous-tâches élémentaires.
**Détermination des tâches à réaliser pour un exemple particulier
On souhaite produire, pendant une durée déterminée par la refBox, le produit suivant :
[[Fichier:ExempleProduitDemande.jpg|center]]
''Le produit est composé d’une base bleue, d’un ring rouge, d’un ring vert et d’un cap noir.''

'''Obtenir Base Bleue'''
->Aller à la Base Station
générateur trajectoire
exécuteur trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (dire à la Base Station quelle base est souhaitée et à quelle banc le robotino est)
approche finale
pince (prendre)

'''Obtenir ring rouge'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Obtenir ring vert'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
(Du coup la plus proche sera celle où on vient de faire le ring précédent)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Ring Station quelle base est souhaitée ( ici, la verte )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Finaliser produit'''
->Aller à une Cap Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Cap Station quelle cap est souhaité ( ici, le noir )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel banc de livraison)
approche finale
pince (prendre)
->Déposer à la Delivery Station
générateur de trajectoire (vers la Delivery Station)
exécuteur de trajectoire
approche finale
pince (déposer)
 
*Organisation générale :
**Création de la page Facebook de l'équipe PYRO Team
 

===Semaine 4===
*Écriture des sous-tâches à réaliser
**Pseudo-codes de certaines sous-tâches réalisées
*Recherche d'ordonnancement optimisé pour la fabrication du produit
**Recherche d'algorithmes
**Visualisation du problème d'ordonnancement concernant l'exemple précédent (base bleue, ring vert, ring rouge, cap noir)
 
Ici, on a pris en plus en hypothèse le fait que la Ring Station (RS1) est capable de mettre des rings rouges ou verts et que la RS2 est capable de de mettre des rings bleus et rouges. Afin de mieux appréhender le problème, nous nous sommes attachés à effectuer un tableau récapitulant les tâches à effectuer pour le produit exemple et à réaliser un graphe mettant en avant les contraintes de précédence de chaque tâche.
 

{| class="wikitable" style="text-align:center; width:80%;"

|-
|
! scope="col" | Tâches
! scope="col" | Ressources utilisées
! scope="col" | Contraintes de précédence
|-
! scope="row" | T0
| Ramener à CS base avec cap
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T1
| Décapsuler
| Cap Station 1 ou 2
| T0
|-
! scope="row" | T2
| Ramener base supplémentaires à RS
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T3
| Chercher base bleue
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T4
| Ramener à RS pour ring vert
| Robot 1, 2 ou 3
| T7
|-
! scope="row" | T5
| Ramener à RS pour ring rouge
| Robot 1, 2 ou 3
| T8
|-
! scope="row" | T6
| Ramener à CS pour cap
| Robot 1, 2 ou 3
| T9
|-
! scope="row" | T7
| Ramener Base
| Base Station
| T3
|-
! scope="row" | T8
| Ajouter ring vert
| Ring Station 1
| T4
|-
! scope="row" | T9
| Ajouter ring rouge
| Ring Station 1 ou 2
| T5 et T2
|-
! scope="row" | T10
| Ajouter cap
| Cap Station 1 ou 2
| T6 et T1
|-
! scope="row" | T11
| Traiter le produit fini
| Delivery Station
| T12
|-
! scope="row" | T12
| Ramener à DS
| Robot 1, 2 ou 3
| T10
|}
[[Fichier:TachesProduitExemple.png|center]]
<center>Graphe montrant l'ordre des tâches à réaliser</center>
 

===Semaine 5===
Durant cette semaine, nous avons réfléchi sur le choix de structures pour nos données :
* Une '''liste principale''' de tous les produits demandés par la RefBox à un instant t. Cette liste principale a les caractéristiques suivantes :
** Une '''Priorité''' sera calculée pour chaque produit avec les paramètres suivants :
*** Nombre de points que peut apporter la production d'un produit de A à Z.
*** Une estimation du temps de production d'un produit.
***La date limite de livraison du produit demandé
** Une tâche est élue si sa priorité est supérieure ou égale à celle des autres tâches.
** Quand la RefBox demande un produit, une cellule sera ajoutée dans cette liste. Et de même, quand un produit sera terminé, on le supprimera de cette liste.
* Chaque produit de la liste principale va contenir une '''liste de tâches''' correspondantes à la production de ce produit. Cette liste de tâches a les caractéristiques suivantes :
** Chaque cellule correspond à une tâche de la production d'un produit. Une tâche contient différents champs :
***Intitulé de la tâche (par exemple ajouter une base)
***Produit concernée (par exemple P3)
***Priorité de la tâche (par exemple 20)
***Temps restant estimé de production (par exemple 180s)
** A chaque fois qu'une tâche est réalisée, elle sera supprimée de la liste de tâches. Ce qui veut dire, qu'on va devoir calculé à nouveau la priorité de chaque tâche de la liste principale.
** Afin de respecter les contraintes de précédence, on considérera que la tâche en tête de la liste de tâches peut être élue. Par exemple, on ne peut pas ajouter un Ring si on n'a pas de base.
 
L'exemple suivant simule le cas où la RefBox a demandé deux fois le produit P3 et deux fois le produit P2.
*Le produit P3 est réalisable en cinq tâches.Ce produit mettra plus de temps à être fabriqué mais rapportera plus de points.
*Le produit P2 est réalisable en quatre tâches.
 
[[Fichier:listedelistes.png|center]]
<center>Structure utilisée pour ranger les tâches à réaliser</center>
 
Différentes remarques utiles :
*Avant de commencer à réaliser n'importe quel produit, il faudra au préalable vérifier si on a libérer un espace de stockage pour plusieurs raisons :
**Les Cap Stations ayant initialement aucun cap en stock, il faut les ramener de l'étagère qui en contient initialement car un produit est dit fini lorsqu'il a à son sommet un cap.
**L'étagère ayant été débarrassée d'un cap, cela permet d'avoir un espace de stockage afin de déposer des produits finis en attente de livraison ou des produits non finis dont on voudrait mettre en pause la production.
*Il sera peut être des fois plus avantageux d'abandonner temporairement la production d'un produit :
**Il vaut mieux faire en sorte de terminer un seul produit sur deux dans les temps plutôt qu'aucun car du fait de la parallélisation de la fabrication des produits, on peut être surchargé de travail.
**Un produit livré durant le laps de temps demandé rapportera plus de points non négligeables.
*Un tableau sera nécessaire afin de savoir ce qu'il y a les espaces de stockage avec les champs suivants :
**Type de produit
**Liste de tâches restantes pour la fabrication du produit (pour un produit fini cette liste est donc nulle)
**Date de début de livraison
**Date de fin de livraison
**Emplacement de l'espace de stockage
 

===Semaine 6===
*Différentes fonctions et actions en pseudo code pour le générateur de tâches
**Fonction qui retourne un booléen suivant si un produit est en stock ou non
**Fonction qui retourne un booléen suivant si on doit livrer le produit à présent ou non
**Fonction qui retourne un booléen suivant si on a déjà ou non mis le travail à faire dans la structure contenant les tâches à réaliser
**Fonction qui retourne le nombre de points que rapporte un produit passé en paramètre
**Action qui rajoute les nouveaux ordres de production dans la liste de listes de tâches
**Action qui calcule le ratio pour chaque tâche
**Action qui supprime les tâches vides (ie celles qui sont terminées)
*Début de l'écriture en pseudo code de la fonction principale
 
*Discussion avec M. Vincent Coelen concernant l'avancement du projet :
**Validation par M. Coelen Vincent des portions de pseudo code déjà écrites
**Discussion autour de la mise en place d'un arrêt immédiat des robots à tout moment du jeu
**Amélioration concernant la robustesse de l'algorithme si un robot n'est plus en état de fonctionnement
 
*Différentes remarques utiles :
**Branche concernant le manager créée sur le [https://github.com/PyroTeam/robocup-pkg/ git] de l'équipe
**Discussion avec d'autres membres de l'équipe sur les services et les topics à envoyer et à recevoir aux nœuds du manager
 
===Semaine 7===

====Générateur de tâches====
Début du codage C++ :
*Création de différentes classes :
**La classe Tache (tache.h et tache.cpp)
**La classe Stockage (stockage.h et stockage.cpp)
**La classe RefBoxComm (refboxcomm.h)
*Création de différentes fonctions :
**Dans tache.h et tache.cpp :
***point_par_produit : retourne le nombre de points que vaut un produit
***dans_les_temps : retourne un booléen indiquant s'il est temps de ramener le produit
**Dans listetaches.h et listetaches.cpp :
***creation_liste_taches_prod : retourne une liste de taches à partir d'un produit passé en paramètre
***creation_liste_taches_act : retourne une liste de taches à partir d'un produit et d'une action passés en paramètres
**Dans tableaustockage.h :
***produit_en_stock : retourne un booléen indiquant si au moins un produit est en stock
**Dans travail.h et travail.cpp :
***deja_dans_travail : retourne un booléen indiquant si un ordre de la RefBox a déjà été pris en compte dans la structure contenant les tâches à réaliser
***max_ratio : retourne l'objet Tache qui a le plus grand ratio dans la structure contenant les tâches à réaliser
***rajout_dans_travail : rajoute un nouvel ordre de la RefBox dans la structure contenant les tâches à réaliser
***calcul_ratio : calcule le ratio de chaque premier de liste de la structure contenant les tâches à réaliser
 
Les codes sont disponibles sur le [https://github.com/PyroTeam/robocup-pkg/tree/feature/manager/generateur_taches git]
 
Des tests ont été réalisés afin de valider les fonctions crées en particulier les fonctions contenues dans travail.h et travail.cpp
 
Voici un petit aperçu de la console :
 
[[Fichier:Capture terminal gen taches 3.png|800px]]
 
Ainsi, les quatres fonctions fonctionnent parfaitement :
*deja_dans_travail indique bien que l'ordre de la RefBox n'a pas encore pris en compte
*max_ratio retourne bien la tâche dont le ratio est maximum
*rajout_dans_travail rajoute en fin de liste la liste de tâches pour la première création d'un produit P0 car un cap est disponible , puis il concatène une liste contenant en tête la tâche "Decapsuler" avec la liste de tâches pour la seconde création d'un produit P0. En effet, la RefBox a demandé deux fois le produit P0 et on ne peut créer un produit tant qu'un cap n'est pas disponible.
*calcul_ratio calcule le ratio de chaque première tâche en fonction du nombre de points et du temps, de plus, si c'est le bon moment pour déstocker un produit il passe cette tâche "Destocker" en priorité (liste 6), en outre, la création d'un produit (liste 1 et liste 7) est prioritaire à l'unique tâche "Decapsuler" (listes 2, 3, 4 et 5) .
 
'''Nous avons enfin reçu le sujet 2015 pour la compétition 2015, il est disponible [https://drive.google.com/file/d/0B39jN82rDE6qSk11YXFuQVljTlE/view?usp=sharing ici]'''
 
*Modification à réaliser :
**la fonction de création de liste de tâches
**l'ordonnancement (en partie)
**calcul de ratio de chaque tâche

====Exécuteur de tâches====
L'éxécuteur de taches va recevoir des ordres de la part du générateur de taches . En fonction de ces ordres, il enverra des demandes d'exécution/d'informations aux autres noeuds. Il y a donc un seul générateur de taches et trois exécuteurs de taches ( on a trois robotinos ).
Voici les classes qui correspondent à chaque exécuteur de taches :
[[Fichier:shema1.png]]
*'''Machine''' est une classe abstraite qui servira à la création des quatre classes filles qui représenteront les quatre machines de la compétition.
** ''string type'' sera donc BaseStation, RingStation, CapStation ou DeliveryStation.
** ''Pose2D centreMachine'' est un point(x,y,theta) qui va correspondre au retour du noeud de localisation (Projet 36)
** ''Pose2D entreeMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour déposer un produit
** ''Pose2D sortieMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour prendre un produit
*'''BaseStation''' est une classe fille de la classe "Machine".
** ''int baseRouge'', ''int baseNoir'' et ''int baseArgent'' vont correspondre aux nombres de bases rouges, bases noires, base argentes respectivement.
*'''RingStation''' est une classe fille de la classe "Machine".
** ''int ringVert'', ''int ringJaune'', ''int ringBleu'' et ''ringOrange'' vont correspondre aux nombres de rings verts, rings jaunes, rings bleus et rings oranges respectivement.
*'''CapStation''' est une classe fille de la classe "Machine".
** ''int capNoir'' et ''int capGris'' vont correspondre aux nombres de caps noirs et caps gris respectivement.
** ''int stock[3]'' est un tableau qui va correspondre aux trois emplacements stockage de la capStation.
** 'Pose2D stockage'' est un point(x,y,theta) qui correspond à l'emplacement de la première zone de stockage.

===Semaine 8===
====Générateur de tâches====
*Création du service pour l'envoi des ordres pour l’exécuteur de tâches avec pour contenu:
**Numéro du robot
***1, 2 ou 3
**Ordre
***ChercherBase
***MettreCap
***ChercherCap
***MettreRing
***ChercherRing
***RamenerBaseRS
***Livrer
***Decapsuler
***Destocker
**Paramètre
***noir
***argent
***rouge
***orange
***jaune
***bleu
***vert
***gris
***DS
***stock
***aucun
**Id
***0, 1, 2, 3, 4, 5 ou 6
 
L'exécuteur de tâches du robot concerné doit envoyer en retour :
*un booléen qui indique si l'ordre est accepté ou non
*l'ordre pris en compte
*l'Id de retour
 
Création d'un nœud ROS pour le débogage à l'aide de ddd
 
Création d'un nœud ROS pour similer l'envoi et la réception des ordres
 
 
Création de la classe action qui range les informations contenues dans le topic envoyé par l'exécuteur de tâches 
Utilisation de la classe action dans la fonction principale pour la phase de production 
Test OK cependant le traitement des informations ne se fait pas suffisamment rapidement pour une utilisation pratique
 

====Exécuteur de tâches====
L'exécuteur de taches est un noeud qui recevra des ordres de la part du générateur de taches et qui, à son tour, va envoyer des ordres aux autres noeuds.

Avec ROS, on peut communiquer entre les différents noeuds de plusieurs façons. En voici deux qui sont principalement utilisés :
* Les Topics : qui sont souvent utilisés pour publier des valeurs de données en continues
* Les services : qui permettent d'envoyer un ordre à un noeud (REQUEST) et qui permettent de recevoir de bonne réception de l'ordre (RESPONSE)

Voici le schéma de communication entre les différents noeuds, en rouge on a les services et en bleu les topics :

[[Fichier:schema2.jpg]]

===Semaine 9===
 
====Exécuteur de tâches====
Après avoir discuter avec les autres membres de l'équipe, nous avons réalisé quelques modification au niveau des communications entre l'exécuteur de taches et les autres noeuds. En fait, les services permettent d'envoyer une requête au serveur correspondant et ensuite le client reçoit une réponse de bonne réception de la requête. Alors que les topics permettent d'envoyer, à une certaine fréquence, les valeurs de variables qui correspondent à ce topic. Ainsi, on remarque qu'on aurait besoin d'utiliser un "mélange" de ces deux moyens de communication. En Ros, cela existe : les actions .

Voici donc à nouveau le schéma de communication :
[[Fichier:Schema.001.jpg]]

===Semaine 10===
 
====Exécuteur de tâches====
Afin de pouvoir tester l'interaction de l'exécuteur de taches avec les autres noeuds, nous avons du faire des "faux noeuds" étant donné que les "vrais noeuds" n'étaient pas encore terminés.

Voici une figure qui montre que l'exécuteur de taches, en haut à gauche, est en attente de recevoir des ordres du générateurs de taches, à coté de l'exécuteur :
[[Fichier:before_order.tiff]]

Ceci est une représentation de la phase d'exploration. En effet, dans cette phase l'exécuteur de taches vas recevoir un ordre du générateur de taches pour explorer une zone de la map. Il va donc demander au noeud localisation de se déplacer vers le point en bas à gauche de la zone. Dès l'arrivée, l'exécuteur de taches va demander au noeud "approche finale" de s'approcher de la machine afin de lire son ArTag. Grace à ce dernier, il pourra savoir de quelle machine s'agit-il et si le Robotino est du coté de l'entrée ou de la sortie. Parce que, en fait, s'il est en entrée l'exécuteur de taches va demander à la navigation puis l'approche finale d'aller au cotée sortie de la machine puisque la colonne de feu se trouve du coté sortie. Une fois arrivée au coté sortie, l'exécuteur de taches va demander au noeud du traitement feu de lire l'état des trois feus de la colonne FESTO.
L'interprétation des feus se fait grâce à la refereeBox. En effet, la refereeBox, publie sur un topic, un tableau avec tous les états possibles de feux avec une chaine de caractères pour chaque état. L'exécuteur va donc pouvoir récupérer la chaine de caractères correspondante aux états de feus actuels de la machine explorée. L'exécuteur peut donc maintenant identifier une machine en envoyant : la zone explorée, l'id de l'ArTag trouvé, ainsi que la chaine de caractères qui correspond au feus.

Dans la figure précédente, le générateur de taches n'avait pas encore envoyé son ordre, on peut remarquer que l'exécuteur était en attente. Une fois l'ordre envoyé, comme dans la figure suivante, l'exécuteur peut commencer à donner des ordres aux autre noeuds :
[[Fichier:after_order.tiff]] 
On remarque que l'exécuteur a communiqué avec tous les faux-noeuds pour enfin reporter une machine avec la refereeBox "fake réception refereeBox ".
Notons que fait d'utiliser des "faux-noeuds" pour tester nos algorithmes nous permet de se placer dans le cas idéale.

===Semaine 11===
 
===Semaine 12===
 

== Fichiers Rendus ==

RoboCup 2015

2015-05-04T20:38:47Z

Shage-ch : /* Exécuteur de tâches */

__TOC__
 
[[Fichier:logoPyro_icone.png |center ]]
<center> Polytech RoboCup Team </center>

==Cahier des charges==
===Présentation générale du projet===

Lors de la compétition de l'Open German, prélude de la Robocup, il faudra mettre en place un système d'autonomisation de production à l'aide de Robotinos (robots mobiles de Festo ayant un système d'exploitation Linux). Comme dans toutes compétitions, le but est de gagner, par conséquent, il faudra faire en sorte de gagner un maximum de points.
C'est pourquoi il faut créer un manager à l'aide de ROS, c'est-à-dire un nœud ou ensemble de nœuds permettant de pouvoir recevoir les informations envoyées par les autres nœuds, de les traiter, tout cela afin de donner les ordres que doivent exécuter chaque Robotino. Ce manager devra également être capable d'optimiser le nombre de points à obtenir.

====Contexte====

La compétition de l'Open German se déroule en quatre phases spécifiques : phase de début-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des tâches spécifiques à remplir suivant les différentes phases. La RefereeBox est un système d'arbitrage auquel il est nécessaire d'envoyer périodiquement des données à tout moment du jeu et qui donne à chaque instant l'état du jeu ainsi que les produits demandés en priorité durant la phase de production.

====Objectif du projet====

*Assurer un maximum de points suivant les aléas du jeu (panne de machine, produits demandées, rupture de stock d'une matière première, …)
*Assurer la pérennité du projet (chaque année des candidats de Polytech Lille y participent)

====Description du projet====

Pour le projet, outre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes :
*Communication avec le nœud de la RefereeBox à tout moment du jeu
*Contrainte de robustesse (il ne faut qu'à un moment ou à un autre il n'y ait un blocage de tous les robots)
*Coopération entre les trois robots
 
[[Fichier:Interactions.png|vignette|left|upright=2|Interactions des nœuds avec le manager]]
 
Le manager devra interagir avec les différents nœuds suivants ayant chacun leurs rôles spécifiques :
*RefereeBox Comm : recevoir les données envoyées par la RefereeBox et envoyer des données suivant l'état du jeu à la RefereeBox
*Robots Comm : communiquer aux autres robots les informations concernant ce que chacun font
*Traitement des TAGs : lire les TAG
*Traitement des feux : lire l'état des colonnes de feu
*Pince de préhension : ouvrir et fermer la pince et renvoyer l'état de la pince
*Approche finale : s'adapter au banc de charge ou de décharge de produits
*Génération trajectoire : détermine une trajectoire pour aller au lieu (X,Y)
*Réalisation trajectoire : parcourir la trajectoire
*Localisation : savoir périodiquement (faible période) où se situe le robot
*Détection d'obstacle : détecter les obstacles fixes et mobiles
 

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

*Utilisation de trois robotinos
*Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce système travaille en utilisant des nœuds qui communiquent entre eux à l'aide de services (requête-réponse) et de topics (fichiers).
*Utilisation de différents langages : C++ ou Python (nœuds)
*Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS
 

===Etapes du projet===
*Prise en main de ROS et du C++
*Élaboration de l'algorithme du manager pour la phase d'exploration
*Élaboration de l'algorithme du manager pour la phase de production
**Coopération entre robots
**Répartition des tâches
*Codage du manager
*Tests et corrections
 

==Avancement du Projet==
===Semaine 1===
*Prise en main de ROS
*Réalisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials
*Réalisation de différents tutoriels C++
*Connaissance plus aiguë du sujet de l'Open German 2015
 
===Semaine 2===
*Réflexions autour de la structure du manager : deux nœuds
**Un nœud exécuteur de tâches
**Un nœud générateur de tâches
*Réflexions sur l'algorithme général du manager concernant la phase d'exploration
**Fonctionnement par zoning pour la répartition des tâches des trois robots
**Réflexion autour d'une alternative de répartition par distances les plus courtes entre machines
*Recherche de solutions pour la phase de production
**Documentation autour de la planification de tâches et la génération de tâche pour une équipe
**Recherche autour de la coopération et de l'allocation de rôles à des robots multi-tâches
*Organisation générale
**Structuration d'un échéancier numérique sous Asana
**Demande d'autorisation pour l'ouverture de la salle C002 auprès de M. Scrive
 

===Semaine 3===
Voilà un lien permettant d'accéder au sujet provisoire de la Robocup 2015 : [https://drive.google.com/file/d/0B39jN82rDE6qMG45cDN5Z0xiSVE/view?usp=sharing Sujet] 
*Réflexions au sujet des infos à communiquer au nœud AutresRobotsComm :
**Ce que le robotino fait
**Quelle machine le robotino est en train d'utiliser
[[Fichier:DataSWithRobotComm.jpg|center]]
 
*Réflexions au niveau de l'algorithme de la phase de production
**Proposition de le faire sous le principe de "Diviser pour mieux régner" (validé par M. Vincent Coelen)
***Diviser la tâche principale en sous-tâches, les sous-tâches en sous-sous-tâches et les sous-sous-tâches en sous-sous-sous-tâches élémentaires.
**Détermination des tâches à réaliser pour un exemple particulier
On souhaite produire, pendant une durée déterminée par la refBox, le produit suivant :
[[Fichier:ExempleProduitDemande.jpg|center]]
''Le produit est composé d’une base bleue, d’un ring rouge, d’un ring vert et d’un cap noir.''

'''Obtenir Base Bleue'''
->Aller à la Base Station
générateur trajectoire
exécuteur trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (dire à la Base Station quelle base est souhaitée et à quelle banc le robotino est)
approche finale
pince (prendre)

'''Obtenir ring rouge'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Obtenir ring vert'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
(Du coup la plus proche sera celle où on vient de faire le ring précédent)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Ring Station quelle base est souhaitée ( ici, la verte )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Finaliser produit'''
->Aller à une Cap Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Cap Station quelle cap est souhaité ( ici, le noir )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel banc de livraison)
approche finale
pince (prendre)
->Déposer à la Delivery Station
générateur de trajectoire (vers la Delivery Station)
exécuteur de trajectoire
approche finale
pince (déposer)
 
*Organisation générale :
**Création de la page Facebook de l'équipe PYRO Team
 

===Semaine 4===
*Écriture des sous-tâches à réaliser
**Pseudo-codes de certaines sous-tâches réalisées
*Recherche d'ordonnancement optimisé pour la fabrication du produit
**Recherche d'algorithmes
**Visualisation du problème d'ordonnancement concernant l'exemple précédent (base bleue, ring vert, ring rouge, cap noir)
 
Ici, on a pris en plus en hypothèse le fait que la Ring Station (RS1) est capable de mettre des rings rouges ou verts et que la RS2 est capable de de mettre des rings bleus et rouges. Afin de mieux appréhender le problème, nous nous sommes attachés à effectuer un tableau récapitulant les tâches à effectuer pour le produit exemple et à réaliser un graphe mettant en avant les contraintes de précédence de chaque tâche.
 

{| class="wikitable" style="text-align:center; width:80%;"

|-
|
! scope="col" | Tâches
! scope="col" | Ressources utilisées
! scope="col" | Contraintes de précédence
|-
! scope="row" | T0
| Ramener à CS base avec cap
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T1
| Décapsuler
| Cap Station 1 ou 2
| T0
|-
! scope="row" | T2
| Ramener base supplémentaires à RS
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T3
| Chercher base bleue
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T4
| Ramener à RS pour ring vert
| Robot 1, 2 ou 3
| T7
|-
! scope="row" | T5
| Ramener à RS pour ring rouge
| Robot 1, 2 ou 3
| T8
|-
! scope="row" | T6
| Ramener à CS pour cap
| Robot 1, 2 ou 3
| T9
|-
! scope="row" | T7
| Ramener Base
| Base Station
| T3
|-
! scope="row" | T8
| Ajouter ring vert
| Ring Station 1
| T4
|-
! scope="row" | T9
| Ajouter ring rouge
| Ring Station 1 ou 2
| T5 et T2
|-
! scope="row" | T10
| Ajouter cap
| Cap Station 1 ou 2
| T6 et T1
|-
! scope="row" | T11
| Traiter le produit fini
| Delivery Station
| T12
|-
! scope="row" | T12
| Ramener à DS
| Robot 1, 2 ou 3
| T10
|}
[[Fichier:TachesProduitExemple.png|center]]
<center>Graphe montrant l'ordre des tâches à réaliser</center>
 

===Semaine 5===
Durant cette semaine, nous avons réfléchi sur le choix de structures pour nos données :
* Une '''liste principale''' de tous les produits demandés par la RefBox à un instant t. Cette liste principale a les caractéristiques suivantes :
** Une '''Priorité''' sera calculée pour chaque produit avec les paramètres suivants :
*** Nombre de points que peut apporter la production d'un produit de A à Z.
*** Une estimation du temps de production d'un produit.
***La date limite de livraison du produit demandé
** Une tâche est élue si sa priorité est supérieure ou égale à celle des autres tâches.
** Quand la RefBox demande un produit, une cellule sera ajoutée dans cette liste. Et de même, quand un produit sera terminé, on le supprimera de cette liste.
* Chaque produit de la liste principale va contenir une '''liste de tâches''' correspondantes à la production de ce produit. Cette liste de tâches a les caractéristiques suivantes :
** Chaque cellule correspond à une tâche de la production d'un produit. Une tâche contient différents champs :
***Intitulé de la tâche (par exemple ajouter une base)
***Produit concernée (par exemple P3)
***Priorité de la tâche (par exemple 20)
***Temps restant estimé de production (par exemple 180s)
** A chaque fois qu'une tâche est réalisée, elle sera supprimée de la liste de tâches. Ce qui veut dire, qu'on va devoir calculé à nouveau la priorité de chaque tâche de la liste principale.
** Afin de respecter les contraintes de précédence, on considérera que la tâche en tête de la liste de tâches peut être élue. Par exemple, on ne peut pas ajouter un Ring si on n'a pas de base.
 
L'exemple suivant simule le cas où la RefBox a demandé deux fois le produit P3 et deux fois le produit P2.
*Le produit P3 est réalisable en cinq tâches.Ce produit mettra plus de temps à être fabriqué mais rapportera plus de points.
*Le produit P2 est réalisable en quatre tâches.
 
[[Fichier:listedelistes.png|center]]
<center>Structure utilisée pour ranger les tâches à réaliser</center>
 
Différentes remarques utiles :
*Avant de commencer à réaliser n'importe quel produit, il faudra au préalable vérifier si on a libérer un espace de stockage pour plusieurs raisons :
**Les Cap Stations ayant initialement aucun cap en stock, il faut les ramener de l'étagère qui en contient initialement car un produit est dit fini lorsqu'il a à son sommet un cap.
**L'étagère ayant été débarrassée d'un cap, cela permet d'avoir un espace de stockage afin de déposer des produits finis en attente de livraison ou des produits non finis dont on voudrait mettre en pause la production.
*Il sera peut être des fois plus avantageux d'abandonner temporairement la production d'un produit :
**Il vaut mieux faire en sorte de terminer un seul produit sur deux dans les temps plutôt qu'aucun car du fait de la parallélisation de la fabrication des produits, on peut être surchargé de travail.
**Un produit livré durant le laps de temps demandé rapportera plus de points non négligeables.
*Un tableau sera nécessaire afin de savoir ce qu'il y a les espaces de stockage avec les champs suivants :
**Type de produit
**Liste de tâches restantes pour la fabrication du produit (pour un produit fini cette liste est donc nulle)
**Date de début de livraison
**Date de fin de livraison
**Emplacement de l'espace de stockage
 

===Semaine 6===
*Différentes fonctions et actions en pseudo code pour le générateur de tâches
**Fonction qui retourne un booléen suivant si un produit est en stock ou non
**Fonction qui retourne un booléen suivant si on doit livrer le produit à présent ou non
**Fonction qui retourne un booléen suivant si on a déjà ou non mis le travail à faire dans la structure contenant les tâches à réaliser
**Fonction qui retourne le nombre de points que rapporte un produit passé en paramètre
**Action qui rajoute les nouveaux ordres de production dans la liste de listes de tâches
**Action qui calcule le ratio pour chaque tâche
**Action qui supprime les tâches vides (ie celles qui sont terminées)
*Début de l'écriture en pseudo code de la fonction principale
 
*Discussion avec M. Vincent Coelen concernant l'avancement du projet :
**Validation par M. Coelen Vincent des portions de pseudo code déjà écrites
**Discussion autour de la mise en place d'un arrêt immédiat des robots à tout moment du jeu
**Amélioration concernant la robustesse de l'algorithme si un robot n'est plus en état de fonctionnement
 
*Différentes remarques utiles :
**Branche concernant le manager créée sur le [https://github.com/PyroTeam/robocup-pkg/ git] de l'équipe
**Discussion avec d'autres membres de l'équipe sur les services et les topics à envoyer et à recevoir aux nœuds du manager
 
===Semaine 7===

====Générateur de tâches====
Début du codage C++ :
*Création de différentes classes :
**La classe Tache (tache.h et tache.cpp)
**La classe Stockage (stockage.h et stockage.cpp)
**La classe RefBoxComm (refboxcomm.h)
*Création de différentes fonctions :
**Dans tache.h et tache.cpp :
***point_par_produit : retourne le nombre de points que vaut un produit
***dans_les_temps : retourne un booléen indiquant s'il est temps de ramener le produit
**Dans listetaches.h et listetaches.cpp :
***creation_liste_taches_prod : retourne une liste de taches à partir d'un produit passé en paramètre
***creation_liste_taches_act : retourne une liste de taches à partir d'un produit et d'une action passés en paramètres
**Dans tableaustockage.h :
***produit_en_stock : retourne un booléen indiquant si au moins un produit est en stock
**Dans travail.h et travail.cpp :
***deja_dans_travail : retourne un booléen indiquant si un ordre de la RefBox a déjà été pris en compte dans la structure contenant les tâches à réaliser
***max_ratio : retourne l'objet Tache qui a le plus grand ratio dans la structure contenant les tâches à réaliser
***rajout_dans_travail : rajoute un nouvel ordre de la RefBox dans la structure contenant les tâches à réaliser
***calcul_ratio : calcule le ratio de chaque premier de liste de la structure contenant les tâches à réaliser
 
Les codes sont disponibles sur le [https://github.com/PyroTeam/robocup-pkg/tree/feature/manager/generateur_taches git]
 
Des tests ont été réalisés afin de valider les fonctions crées en particulier les fonctions contenues dans travail.h et travail.cpp
 
Voici un petit aperçu de la console :
 
[[Fichier:Capture terminal gen taches 3.png|800px]]
 
Ainsi, les quatres fonctions fonctionnent parfaitement :
*deja_dans_travail indique bien que l'ordre de la RefBox n'a pas encore pris en compte
*max_ratio retourne bien la tâche dont le ratio est maximum
*rajout_dans_travail rajoute en fin de liste la liste de tâches pour la première création d'un produit P0 car un cap est disponible , puis il concatène une liste contenant en tête la tâche "Decapsuler" avec la liste de tâches pour la seconde création d'un produit P0. En effet, la RefBox a demandé deux fois le produit P0 et on ne peut créer un produit tant qu'un cap n'est pas disponible.
*calcul_ratio calcule le ratio de chaque première tâche en fonction du nombre de points et du temps, de plus, si c'est le bon moment pour déstocker un produit il passe cette tâche "Destocker" en priorité (liste 6), en outre, la création d'un produit (liste 1 et liste 7) est prioritaire à l'unique tâche "Decapsuler" (listes 2, 3, 4 et 5) .
 
'''Nous avons enfin reçu le sujet 2015 pour la compétition 2015, il est disponible [https://drive.google.com/file/d/0B39jN82rDE6qSk11YXFuQVljTlE/view?usp=sharing ici]'''
 
*Modification à réaliser :
**la fonction de création de liste de tâches
**l'ordonnancement (en partie)
**calcul de ratio de chaque tâche

====Exécuteur de tâches====
L'éxécuteur de taches va recevoir des ordres de la part du générateur de taches . En fonction de ces ordres, il enverra des demandes d'exécution/d'informations aux autres noeuds. Il y a donc un seul générateur de taches et trois exécuteurs de taches ( on a trois robotinos ).
Voici les classes qui correspondent à chaque exécuteur de taches :
[[Fichier:shema1.png]]
*'''Machine''' est une classe abstraite qui servira à la création des quatre classes filles qui représenteront les quatre machines de la compétition.
** ''string type'' sera donc BaseStation, RingStation, CapStation ou DeliveryStation.
** ''Pose2D centreMachine'' est un point(x,y,theta) qui va correspondre au retour du noeud de localisation (Projet 36)
** ''Pose2D entreeMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour déposer un produit
** ''Pose2D sortieMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour prendre un produit
*'''BaseStation''' est une classe fille de la classe "Machine".
** ''int baseRouge'', ''int baseNoir'' et ''int baseArgent'' vont correspondre aux nombres de bases rouges, bases noires, base argentes respectivement.
*'''RingStation''' est une classe fille de la classe "Machine".
** ''int ringVert'', ''int ringJaune'', ''int ringBleu'' et ''ringOrange'' vont correspondre aux nombres de rings verts, rings jaunes, rings bleus et rings oranges respectivement.
*'''CapStation''' est une classe fille de la classe "Machine".
** ''int capNoir'' et ''int capGris'' vont correspondre aux nombres de caps noirs et caps gris respectivement.
** ''int stock[3]'' est un tableau qui va correspondre aux trois emplacements stockage de la capStation.
** 'Pose2D stockage'' est un point(x,y,theta) qui correspond à l'emplacement de la première zone de stockage.

===Semaine 8===
====Générateur de tâches====
*Création du service pour l'envoi des ordres pour l’exécuteur de tâches avec pour contenu:
**Numéro du robot
***1, 2 ou 3
**Ordre
***ChercherBase
***MettreCap
***ChercherCap
***MettreRing
***ChercherRing
***RamenerBaseRS
***Livrer
***Decapsuler
***Destocker
**Paramètre
***noir
***argent
***rouge
***orange
***jaune
***bleu
***vert
***gris
***DS
***stock
***aucun
**Id
***0, 1, 2, 3, 4, 5 ou 6
 
L'exécuteur de tâches du robot concerné doit envoyer en retour :
*un booléen qui indique si l'ordre est accepté ou non
*l'ordre pris en compte
*l'Id de retour
 
Création d'un nœud ROS pour le débogage à l'aide de ddd
 
Création d'un nœud ROS pour similer l'envoi et la réception des ordres
 
 
Création de la classe action qui range les informations contenues dans le topic envoyé par l'exécuteur de tâches 
Utilisation de la classe action dans la fonction principale pour la phase de production 
Test OK cependant le traitement des informations ne se fait pas suffisamment rapidement pour une utilisation pratique
 

====Exécuteur de tâches====
L'exécuteur de taches est un noeud qui recevra des ordres de la part du générateur de taches et qui, à son tour, va envoyer des ordres aux autres noeuds.

Avec ROS, on peut communiquer entre les différents noeuds de plusieurs façons. En voici deux qui sont principalement utilisés :
* Les Topics : qui sont souvent utilisés pour publier des valeurs de données en continues
* Les services : qui permettent d'envoyer un ordre à un noeud (REQUEST) et qui permettent de recevoir de bonne réception de l'ordre (RESPONSE)

Voici le schéma de communication entre les différents noeuds, en rouge on a les services et en bleu les topics :

[[Fichier:schema2.jpg]]

===Semaine 9===
 
====Exécuteur de tâches====
Après avoir discuter avec les autres membres de l'équipe, nous avons réalisé quelques modification au niveau des communications entre l'exécuteur de taches et les autres noeuds. En fait, les services permettent d'envoyer une requête au serveur correspondant et ensuite le client reçoit une réponse de bonne réception de la requête. Alors que les topics permettent d'envoyer, à une certaine fréquence, les valeurs de variables qui correspondent à ce topic. Ainsi, on remarque qu'on aurait besoin d'utiliser un "mélange" de ces deux moyens de communication. En Ros, cela existe : les actions .

Voici donc à nouveau le schéma de communication :
[[Fichier:Schema.001.jpg]]

===Semaine 10===
 
====Exécuteur de tâches====
Afin de pouvoir tester l'interaction de l'exécuteur de taches avec les autres noeuds, nous avons du faire des "faux noeuds" étant donné que les "vrais noeuds" n'étaient pas encore terminés.

Voici une figure qui montre que l'exécuteur de taches, en haut à gauche, est en attente de recevoir des ordres du générateurs de taches, à coté de l'exécuteur :
[[Fichier:before_order.tiff]]

Ceci est une représentation de la phase d'exploration. En effet, dans cette phase l'exécuteur de taches vas recevoir un ordre du générateur de taches pour explorer une zone de la map. Il va donc demander au noeud localisation de se déplacer vers le point en bas à gauche de la zone. Dès l'arrivée, l'exécuteur de taches va demander au noeud "approche finale" de s'approcher de la machine afin de lire son ArTag. Grace à ce dernier, il pourra savoir de quelle machine s'agit-il et si le Robotino est du coté de l'entrée ou de la sortie. Parce que, en fait, s'il est en entrée l'exécuteur de taches va demander à la navigation puis l'approche finale d'aller au cotée sortie de la machine puisque la colonne de feu se trouve du coté sortie. Une fois arrivée au coté sortie, l'exécuteur de taches va demander au noeud du traitement feu de lire l'état des trois feus de la colonne FESTO.
L'interprétation des feus se fait grâce à la refereeBox. En effet, la refereeBox, publie sur un topic, un tableau avec tous les états possibles de feux avec une chaine de caractères pour chaque état. L'exécuteur va donc pouvoir récupérer la chaine de caractères correspondante aux états de feus actuels de la machine explorée. L'exécuteur peut donc maintenant identifier une machine en envoyant : la zone explorée, l'id de l'ArTag trouvé, ainsi que la chaine de caractères qui correspond au feus.

===Semaine 11===
 
===Semaine 12===
 

== Fichiers Rendus ==

RoboCup 2015

2015-05-04T14:03:18Z

Shage-ch :

__TOC__
 
[[Fichier:logoPyro_icone.png |center ]]
<center> Polytech RoboCup Team </center>

==Cahier des charges==
===Présentation générale du projet===

Lors de la compétition de l'Open German, prélude de la Robocup, il faudra mettre en place un système d'autonomisation de production à l'aide de Robotinos (robots mobiles de Festo ayant un système d'exploitation Linux). Comme dans toutes compétitions, le but est de gagner, par conséquent, il faudra faire en sorte de gagner un maximum de points.
C'est pourquoi il faut créer un manager à l'aide de ROS, c'est-à-dire un nœud ou ensemble de nœuds permettant de pouvoir recevoir les informations envoyées par les autres nœuds, de les traiter, tout cela afin de donner les ordres que doivent exécuter chaque Robotino. Ce manager devra également être capable d'optimiser le nombre de points à obtenir.

====Contexte====

La compétition de l'Open German se déroule en quatre phases spécifiques : phase de début-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des tâches spécifiques à remplir suivant les différentes phases. La RefereeBox est un système d'arbitrage auquel il est nécessaire d'envoyer périodiquement des données à tout moment du jeu et qui donne à chaque instant l'état du jeu ainsi que les produits demandés en priorité durant la phase de production.

====Objectif du projet====

*Assurer un maximum de points suivant les aléas du jeu (panne de machine, produits demandées, rupture de stock d'une matière première, …)
*Assurer la pérennité du projet (chaque année des candidats de Polytech Lille y participent)

====Description du projet====

Pour le projet, outre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes :
*Communication avec le nœud de la RefereeBox à tout moment du jeu
*Contrainte de robustesse (il ne faut qu'à un moment ou à un autre il n'y ait un blocage de tous les robots)
*Coopération entre les trois robots
 
[[Fichier:Interactions.png|vignette|left|upright=2|Interactions des nœuds avec le manager]]
 
Le manager devra interagir avec les différents nœuds suivants ayant chacun leurs rôles spécifiques :
*RefereeBox Comm : recevoir les données envoyées par la RefereeBox et envoyer des données suivant l'état du jeu à la RefereeBox
*Robots Comm : communiquer aux autres robots les informations concernant ce que chacun font
*Traitement des TAGs : lire les TAG
*Traitement des feux : lire l'état des colonnes de feu
*Pince de préhension : ouvrir et fermer la pince et renvoyer l'état de la pince
*Approche finale : s'adapter au banc de charge ou de décharge de produits
*Génération trajectoire : détermine une trajectoire pour aller au lieu (X,Y)
*Réalisation trajectoire : parcourir la trajectoire
*Localisation : savoir périodiquement (faible période) où se situe le robot
*Détection d'obstacle : détecter les obstacles fixes et mobiles
 

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

*Utilisation de trois robotinos
*Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce système travaille en utilisant des nœuds qui communiquent entre eux à l'aide de services (requête-réponse) et de topics (fichiers).
*Utilisation de différents langages : C++ ou Python (nœuds)
*Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS
 

===Etapes du projet===
*Prise en main de ROS et du C++
*Élaboration de l'algorithme du manager pour la phase d'exploration
*Élaboration de l'algorithme du manager pour la phase de production
**Coopération entre robots
**Répartition des tâches
*Codage du manager
*Tests et corrections
 

==Avancement du Projet==
===Semaine 1===
*Prise en main de ROS
*Réalisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials
*Réalisation de différents tutoriels C++
*Connaissance plus aiguë du sujet de l'Open German 2015
 
===Semaine 2===
*Réflexions autour de la structure du manager : deux nœuds
**Un nœud exécuteur de tâches
**Un nœud générateur de tâches
*Réflexions sur l'algorithme général du manager concernant la phase d'exploration
**Fonctionnement par zoning pour la répartition des tâches des trois robots
**Réflexion autour d'une alternative de répartition par distances les plus courtes entre machines
*Recherche de solutions pour la phase de production
**Documentation autour de la planification de tâches et la génération de tâche pour une équipe
**Recherche autour de la coopération et de l'allocation de rôles à des robots multi-tâches
*Organisation générale
**Structuration d'un échéancier numérique sous Asana
**Demande d'autorisation pour l'ouverture de la salle C002 auprès de M. Scrive
 

===Semaine 3===
Voilà un lien permettant d'accéder au sujet provisoire de la Robocup 2015 : [https://drive.google.com/file/d/0B39jN82rDE6qMG45cDN5Z0xiSVE/view?usp=sharing Sujet] 
*Réflexions au sujet des infos à communiquer au nœud AutresRobotsComm :
**Ce que le robotino fait
**Quelle machine le robotino est en train d'utiliser
[[Fichier:DataSWithRobotComm.jpg|center]]
 
*Réflexions au niveau de l'algorithme de la phase de production
**Proposition de le faire sous le principe de "Diviser pour mieux régner" (validé par M. Vincent Coelen)
***Diviser la tâche principale en sous-tâches, les sous-tâches en sous-sous-tâches et les sous-sous-tâches en sous-sous-sous-tâches élémentaires.
**Détermination des tâches à réaliser pour un exemple particulier
On souhaite produire, pendant une durée déterminée par la refBox, le produit suivant :
[[Fichier:ExempleProduitDemande.jpg|center]]
''Le produit est composé d’une base bleue, d’un ring rouge, d’un ring vert et d’un cap noir.''

'''Obtenir Base Bleue'''
->Aller à la Base Station
générateur trajectoire
exécuteur trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (dire à la Base Station quelle base est souhaitée et à quelle banc le robotino est)
approche finale
pince (prendre)

'''Obtenir ring rouge'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Obtenir ring vert'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
(Du coup la plus proche sera celle où on vient de faire le ring précédent)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Ring Station quelle base est souhaitée ( ici, la verte )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Finaliser produit'''
->Aller à une Cap Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Cap Station quelle cap est souhaité ( ici, le noir )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel banc de livraison)
approche finale
pince (prendre)
->Déposer à la Delivery Station
générateur de trajectoire (vers la Delivery Station)
exécuteur de trajectoire
approche finale
pince (déposer)
 
*Organisation générale :
**Création de la page Facebook de l'équipe PYRO Team
 

===Semaine 4===
*Écriture des sous-tâches à réaliser
**Pseudo-codes de certaines sous-tâches réalisées
*Recherche d'ordonnancement optimisé pour la fabrication du produit
**Recherche d'algorithmes
**Visualisation du problème d'ordonnancement concernant l'exemple précédent (base bleue, ring vert, ring rouge, cap noir)
 
Ici, on a pris en plus en hypothèse le fait que la Ring Station (RS1) est capable de mettre des rings rouges ou verts et que la RS2 est capable de de mettre des rings bleus et rouges. Afin de mieux appréhender le problème, nous nous sommes attachés à effectuer un tableau récapitulant les tâches à effectuer pour le produit exemple et à réaliser un graphe mettant en avant les contraintes de précédence de chaque tâche.
 

{| class="wikitable" style="text-align:center; width:80%;"

|-
|
! scope="col" | Tâches
! scope="col" | Ressources utilisées
! scope="col" | Contraintes de précédence
|-
! scope="row" | T0
| Ramener à CS base avec cap
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T1
| Décapsuler
| Cap Station 1 ou 2
| T0
|-
! scope="row" | T2
| Ramener base supplémentaires à RS
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T3
| Chercher base bleue
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T4
| Ramener à RS pour ring vert
| Robot 1, 2 ou 3
| T7
|-
! scope="row" | T5
| Ramener à RS pour ring rouge
| Robot 1, 2 ou 3
| T8
|-
! scope="row" | T6
| Ramener à CS pour cap
| Robot 1, 2 ou 3
| T9
|-
! scope="row" | T7
| Ramener Base
| Base Station
| T3
|-
! scope="row" | T8
| Ajouter ring vert
| Ring Station 1
| T4
|-
! scope="row" | T9
| Ajouter ring rouge
| Ring Station 1 ou 2
| T5 et T2
|-
! scope="row" | T10
| Ajouter cap
| Cap Station 1 ou 2
| T6 et T1
|-
! scope="row" | T11
| Traiter le produit fini
| Delivery Station
| T12
|-
! scope="row" | T12
| Ramener à DS
| Robot 1, 2 ou 3
| T10
|}
[[Fichier:TachesProduitExemple.png|center]]
<center>Graphe montrant l'ordre des tâches à réaliser</center>
 

===Semaine 5===
Durant cette semaine, nous avons réfléchi sur le choix de structures pour nos données :
* Une '''liste principale''' de tous les produits demandés par la RefBox à un instant t. Cette liste principale a les caractéristiques suivantes :
** Une '''Priorité''' sera calculée pour chaque produit avec les paramètres suivants :
*** Nombre de points que peut apporter la production d'un produit de A à Z.
*** Une estimation du temps de production d'un produit.
***La date limite de livraison du produit demandé
** Une tâche est élue si sa priorité est supérieure ou égale à celle des autres tâches.
** Quand la RefBox demande un produit, une cellule sera ajoutée dans cette liste. Et de même, quand un produit sera terminé, on le supprimera de cette liste.
* Chaque produit de la liste principale va contenir une '''liste de tâches''' correspondantes à la production de ce produit. Cette liste de tâches a les caractéristiques suivantes :
** Chaque cellule correspond à une tâche de la production d'un produit. Une tâche contient différents champs :
***Intitulé de la tâche (par exemple ajouter une base)
***Produit concernée (par exemple P3)
***Priorité de la tâche (par exemple 20)
***Temps restant estimé de production (par exemple 180s)
** A chaque fois qu'une tâche est réalisée, elle sera supprimée de la liste de tâches. Ce qui veut dire, qu'on va devoir calculé à nouveau la priorité de chaque tâche de la liste principale.
** Afin de respecter les contraintes de précédence, on considérera que la tâche en tête de la liste de tâches peut être élue. Par exemple, on ne peut pas ajouter un Ring si on n'a pas de base.
 
L'exemple suivant simule le cas où la RefBox a demandé deux fois le produit P3 et deux fois le produit P2.
*Le produit P3 est réalisable en cinq tâches.Ce produit mettra plus de temps à être fabriqué mais rapportera plus de points.
*Le produit P2 est réalisable en quatre tâches.
 
[[Fichier:listedelistes.png|center]]
<center>Structure utilisée pour ranger les tâches à réaliser</center>
 
Différentes remarques utiles :
*Avant de commencer à réaliser n'importe quel produit, il faudra au préalable vérifier si on a libérer un espace de stockage pour plusieurs raisons :
**Les Cap Stations ayant initialement aucun cap en stock, il faut les ramener de l'étagère qui en contient initialement car un produit est dit fini lorsqu'il a à son sommet un cap.
**L'étagère ayant été débarrassée d'un cap, cela permet d'avoir un espace de stockage afin de déposer des produits finis en attente de livraison ou des produits non finis dont on voudrait mettre en pause la production.
*Il sera peut être des fois plus avantageux d'abandonner temporairement la production d'un produit :
**Il vaut mieux faire en sorte de terminer un seul produit sur deux dans les temps plutôt qu'aucun car du fait de la parallélisation de la fabrication des produits, on peut être surchargé de travail.
**Un produit livré durant le laps de temps demandé rapportera plus de points non négligeables.
*Un tableau sera nécessaire afin de savoir ce qu'il y a les espaces de stockage avec les champs suivants :
**Type de produit
**Liste de tâches restantes pour la fabrication du produit (pour un produit fini cette liste est donc nulle)
**Date de début de livraison
**Date de fin de livraison
**Emplacement de l'espace de stockage
 

===Semaine 6===
*Différentes fonctions et actions en pseudo code pour le générateur de tâches
**Fonction qui retourne un booléen suivant si un produit est en stock ou non
**Fonction qui retourne un booléen suivant si on doit livrer le produit à présent ou non
**Fonction qui retourne un booléen suivant si on a déjà ou non mis le travail à faire dans la structure contenant les tâches à réaliser
**Fonction qui retourne le nombre de points que rapporte un produit passé en paramètre
**Action qui rajoute les nouveaux ordres de production dans la liste de listes de tâches
**Action qui calcule le ratio pour chaque tâche
**Action qui supprime les tâches vides (ie celles qui sont terminées)
*Début de l'écriture en pseudo code de la fonction principale
 
*Discussion avec M. Vincent Coelen concernant l'avancement du projet :
**Validation par M. Coelen Vincent des portions de pseudo code déjà écrites
**Discussion autour de la mise en place d'un arrêt immédiat des robots à tout moment du jeu
**Amélioration concernant la robustesse de l'algorithme si un robot n'est plus en état de fonctionnement
 
*Différentes remarques utiles :
**Branche concernant le manager créée sur le [https://github.com/PyroTeam/robocup-pkg/ git] de l'équipe
**Discussion avec d'autres membres de l'équipe sur les services et les topics à envoyer et à recevoir aux nœuds du manager
 
===Semaine 7===

====Générateur de tâches====
Début du codage C++ :
*Création de différentes classes :
**La classe Tache (tache.h et tache.cpp)
**La classe Stockage (stockage.h et stockage.cpp)
**La classe RefBoxComm (refboxcomm.h)
*Création de différentes fonctions :
**Dans tache.h et tache.cpp :
***point_par_produit : retourne le nombre de points que vaut un produit
***dans_les_temps : retourne un booléen indiquant s'il est temps de ramener le produit
**Dans listetaches.h et listetaches.cpp :
***creation_liste_taches_prod : retourne une liste de taches à partir d'un produit passé en paramètre
***creation_liste_taches_act : retourne une liste de taches à partir d'un produit et d'une action passés en paramètres
**Dans tableaustockage.h :
***produit_en_stock : retourne un booléen indiquant si au moins un produit est en stock
**Dans travail.h et travail.cpp :
***deja_dans_travail : retourne un booléen indiquant si un ordre de la RefBox a déjà été pris en compte dans la structure contenant les tâches à réaliser
***max_ratio : retourne l'objet Tache qui a le plus grand ratio dans la structure contenant les tâches à réaliser
***rajout_dans_travail : rajoute un nouvel ordre de la RefBox dans la structure contenant les tâches à réaliser
***calcul_ratio : calcule le ratio de chaque premier de liste de la structure contenant les tâches à réaliser
 
Les codes sont disponibles sur le [https://github.com/PyroTeam/robocup-pkg/tree/feature/manager/generateur_taches git]
 
Des tests ont été réalisés afin de valider les fonctions crées en particulier les fonctions contenues dans travail.h et travail.cpp
 
Voici un petit aperçu de la console :
 
[[Fichier:Capture terminal gen taches 3.png|800px]]
 
Ainsi, les quatres fonctions fonctionnent parfaitement :
*deja_dans_travail indique bien que l'ordre de la RefBox n'a pas encore pris en compte
*max_ratio retourne bien la tâche dont le ratio est maximum
*rajout_dans_travail rajoute en fin de liste la liste de tâches pour la première création d'un produit P0 car un cap est disponible , puis il concatène une liste contenant en tête la tâche "Decapsuler" avec la liste de tâches pour la seconde création d'un produit P0. En effet, la RefBox a demandé deux fois le produit P0 et on ne peut créer un produit tant qu'un cap n'est pas disponible.
*calcul_ratio calcule le ratio de chaque première tâche en fonction du nombre de points et du temps, de plus, si c'est le bon moment pour déstocker un produit il passe cette tâche "Destocker" en priorité (liste 6), en outre, la création d'un produit (liste 1 et liste 7) est prioritaire à l'unique tâche "Decapsuler" (listes 2, 3, 4 et 5) .
 
'''Nous avons enfin reçu le sujet 2015 pour la compétition 2015, il est disponible [https://drive.google.com/file/d/0B39jN82rDE6qSk11YXFuQVljTlE/view?usp=sharing ici]'''
 
*Modification à réaliser :
**la fonction de création de liste de tâches
**l'ordonnancement (en partie)
**calcul de ratio de chaque tâche

====Exécuteur de tâches====
L'éxécuteur de taches va recevoir des ordres de la part du générateur de taches . En fonction de ces ordres, il enverra des demandes d'exécution/d'informations aux autres noeuds. Il y a donc un seul générateur de taches et trois exécuteurs de taches ( on a trois robotinos ).
Voici les classes qui correspondent à chaque exécuteur de taches :
[[Fichier:shema1.png]]
*'''Machine''' est une classe abstraite qui servira à la création des quatre classes filles qui représenteront les quatre machines de la compétition.
** ''string type'' sera donc BaseStation, RingStation, CapStation ou DeliveryStation.
** ''Pose2D centreMachine'' est un point(x,y,theta) qui va correspondre au retour du noeud de localisation (Projet 36)
** ''Pose2D entreeMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour déposer un produit
** ''Pose2D sortieMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour prendre un produit
*'''BaseStation''' est une classe fille de la classe "Machine".
** ''int baseRouge'', ''int baseNoir'' et ''int baseArgent'' vont correspondre aux nombres de bases rouges, bases noires, base argentes respectivement.
*'''RingStation''' est une classe fille de la classe "Machine".
** ''int ringVert'', ''int ringJaune'', ''int ringBleu'' et ''ringOrange'' vont correspondre aux nombres de rings verts, rings jaunes, rings bleus et rings oranges respectivement.
*'''CapStation''' est une classe fille de la classe "Machine".
** ''int capNoir'' et ''int capGris'' vont correspondre aux nombres de caps noirs et caps gris respectivement.
** ''int stock[3]'' est un tableau qui va correspondre aux trois emplacements stockage de la capStation.
** 'Pose2D stockage'' est un point(x,y,theta) qui correspond à l'emplacement de la première zone de stockage.

===Semaine 8===
====Générateur de tâches====
*Création du service pour l'envoi des ordres pour l’exécuteur de tâches avec pour contenu:
**Numéro du robot
***1, 2 ou 3
**Ordre
***ChercherBase
***MettreCap
***ChercherCap
***MettreRing
***ChercherRing
***RamenerBaseRS
***Livrer
***Decapsuler
***Destocker
**Paramètre
***noir
***argent
***rouge
***orange
***jaune
***bleu
***vert
***gris
***DS
***stock
***aucun
**Id
***0, 1, 2, 3, 4, 5 ou 6
 
L'exécuteur de tâches du robot concerné doit envoyer en retour :
*un booléen qui indique si l'ordre est accepté ou non
*l'ordre pris en compte
*l'Id de retour
 
Création d'un nœud ROS pour le débogage à l'aide de ddd
 
Création d'un nœud ROS pour similer l'envoi et la réception des ordres
 
 
Création de la classe action qui range les informations contenues dans le topic envoyé par l'exécuteur de tâches 
Utilisation de la classe action dans la fonction principale pour la phase de production 
Test OK cependant le traitement des informations ne se fait pas suffisamment rapidement pour une utilisation pratique
 

====Exécuteur de tâches====
L'exécuteur de taches est un noeud qui recevra des ordres de la part du générateur de taches et qui, à son tour, va envoyer des ordres aux autres noeuds.

Avec ROS, on peut communiquer entre les différents noeuds de plusieurs façons. En voici deux qui sont principalement utilisés :
* Les Topics : qui sont souvent utilisés pour publier des valeurs de données en continues
* Les services : qui permettent d'envoyer un ordre à un noeud (REQUEST) et qui permettent de recevoir de bonne réception de l'ordre (RESPONSE)

Voici le schéma de communication entre les différents noeuds, en rouge on a les services et en bleu les topics :

[[Fichier:schema2.jpg]]

===Semaine 9===
 
====Exécuteur de tâches====
Après avoir discuter avec les autres membres de l'équipe, nous avons réalisé quelques modification au niveau des communications entre l'exécuteur de taches et les autres noeuds. En fait, les services permettent d'envoyer une requête au serveur correspondant et ensuite le client reçoit une réponse de bonne réception de la requête. Alors que les topics permettent d'envoyer, à une certaine fréquence, les valeurs de variables qui correspondent à ce topic. Ainsi, on remarque qu'on aurait besoin d'utiliser un "mélange" de ces deux moyens de communication. En Ros, cela existe : les actions .

Voici donc à nouveau le schéma de communication :
[[Fichier:Schema.001.jpg]]

===Semaine 10===
 
====Exécuteur de tâches====
Afin de pouvoir tester l'interaction de l'exécuteur de taches avec les autres noeuds, nous avons du faire des "faux noeuds" étant donné que les "vrais noeuds" n'étaient pas encore terminés.

Voici une figure qui montre que l'exécuteur de taches est en attente de recevoir des ordres du générateurs de taches :
[[Fichier:before_order.tiff]]
===Semaine 11===
 
===Semaine 12===
 

== Fichiers Rendus ==

RoboCup 2015

2015-05-04T12:53:33Z

Shage-ch :

__TOC__
 
[[Fichier:logoPyro_icone.png |center ]]
<center> Polytech RoboCup Team </center>

==Cahier des charges==
===Présentation générale du projet===

Lors de la compétition de l'Open German, prélude de la Robocup, il faudra mettre en place un système d'autonomisation de production à l'aide de Robotinos (robots mobiles de Festo ayant un système d'exploitation Linux). Comme dans toutes compétitions, le but est de gagner, par conséquent, il faudra faire en sorte de gagner un maximum de points.
C'est pourquoi il faut créer un manager à l'aide de ROS, c'est-à-dire un nœud ou ensemble de nœuds permettant de pouvoir recevoir les informations envoyées par les autres nœuds, de les traiter, tout cela afin de donner les ordres que doivent exécuter chaque Robotino. Ce manager devra également être capable d'optimiser le nombre de points à obtenir.

====Contexte====

La compétition de l'Open German se déroule en quatre phases spécifiques : phase de début-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des tâches spécifiques à remplir suivant les différentes phases. La RefereeBox est un système d'arbitrage auquel il est nécessaire d'envoyer périodiquement des données à tout moment du jeu et qui donne à chaque instant l'état du jeu ainsi que les produits demandés en priorité durant la phase de production.

====Objectif du projet====

*Assurer un maximum de points suivant les aléas du jeu (panne de machine, produits demandées, rupture de stock d'une matière première, …)
*Assurer la pérennité du projet (chaque année des candidats de Polytech Lille y participent)

====Description du projet====

Pour le projet, outre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes :
*Communication avec le nœud de la RefereeBox à tout moment du jeu
*Contrainte de robustesse (il ne faut qu'à un moment ou à un autre il n'y ait un blocage de tous les robots)
*Coopération entre les trois robots
 
[[Fichier:Interactions.png|vignette|left|upright=2|Interactions des nœuds avec le manager]]
 
Le manager devra interagir avec les différents nœuds suivants ayant chacun leurs rôles spécifiques :
*RefereeBox Comm : recevoir les données envoyées par la RefereeBox et envoyer des données suivant l'état du jeu à la RefereeBox
*Robots Comm : communiquer aux autres robots les informations concernant ce que chacun font
*Traitement des TAGs : lire les TAG
*Traitement des feux : lire l'état des colonnes de feu
*Pince de préhension : ouvrir et fermer la pince et renvoyer l'état de la pince
*Approche finale : s'adapter au banc de charge ou de décharge de produits
*Génération trajectoire : détermine une trajectoire pour aller au lieu (X,Y)
*Réalisation trajectoire : parcourir la trajectoire
*Localisation : savoir périodiquement (faible période) où se situe le robot
*Détection d'obstacle : détecter les obstacles fixes et mobiles
 

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

*Utilisation de trois robotinos
*Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce système travaille en utilisant des nœuds qui communiquent entre eux à l'aide de services (requête-réponse) et de topics (fichiers).
*Utilisation de différents langages : C++ ou Python (nœuds)
*Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS
 

===Etapes du projet===
*Prise en main de ROS et du C++
*Élaboration de l'algorithme du manager pour la phase d'exploration
*Élaboration de l'algorithme du manager pour la phase de production
**Coopération entre robots
**Répartition des tâches
*Codage du manager
*Tests et corrections
 

==Avancement du Projet==
===Semaine 1===
*Prise en main de ROS
*Réalisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials
*Réalisation de différents tutoriels C++
*Connaissance plus aiguë du sujet de l'Open German 2015
 
===Semaine 2===
*Réflexions autour de la structure du manager : deux nœuds
**Un nœud exécuteur de tâches
**Un nœud générateur de tâches
*Réflexions sur l'algorithme général du manager concernant la phase d'exploration
**Fonctionnement par zoning pour la répartition des tâches des trois robots
**Réflexion autour d'une alternative de répartition par distances les plus courtes entre machines
*Recherche de solutions pour la phase de production
**Documentation autour de la planification de tâches et la génération de tâche pour une équipe
**Recherche autour de la coopération et de l'allocation de rôles à des robots multi-tâches
*Organisation générale
**Structuration d'un échéancier numérique sous Asana
**Demande d'autorisation pour l'ouverture de la salle C002 auprès de M. Scrive
 

===Semaine 3===
Voilà un lien permettant d'accéder au sujet provisoire de la Robocup 2015 : [https://drive.google.com/file/d/0B39jN82rDE6qMG45cDN5Z0xiSVE/view?usp=sharing Sujet] 
*Réflexions au sujet des infos à communiquer au nœud AutresRobotsComm :
**Ce que le robotino fait
**Quelle machine le robotino est en train d'utiliser
[[Fichier:DataSWithRobotComm.jpg|center]]
 
*Réflexions au niveau de l'algorithme de la phase de production
**Proposition de le faire sous le principe de "Diviser pour mieux régner" (validé par M. Vincent Coelen)
***Diviser la tâche principale en sous-tâches, les sous-tâches en sous-sous-tâches et les sous-sous-tâches en sous-sous-sous-tâches élémentaires.
**Détermination des tâches à réaliser pour un exemple particulier
On souhaite produire, pendant une durée déterminée par la refBox, le produit suivant :
[[Fichier:ExempleProduitDemande.jpg|center]]
''Le produit est composé d’une base bleue, d’un ring rouge, d’un ring vert et d’un cap noir.''

'''Obtenir Base Bleue'''
->Aller à la Base Station
générateur trajectoire
exécuteur trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (dire à la Base Station quelle base est souhaitée et à quelle banc le robotino est)
approche finale
pince (prendre)

'''Obtenir ring rouge'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Obtenir ring vert'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
(Du coup la plus proche sera celle où on vient de faire le ring précédent)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Ring Station quelle base est souhaitée ( ici, la verte )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Finaliser produit'''
->Aller à une Cap Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Cap Station quelle cap est souhaité ( ici, le noir )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel banc de livraison)
approche finale
pince (prendre)
->Déposer à la Delivery Station
générateur de trajectoire (vers la Delivery Station)
exécuteur de trajectoire
approche finale
pince (déposer)
 
*Organisation générale :
**Création de la page Facebook de l'équipe PYRO Team
 

===Semaine 4===
*Écriture des sous-tâches à réaliser
**Pseudo-codes de certaines sous-tâches réalisées
*Recherche d'ordonnancement optimisé pour la fabrication du produit
**Recherche d'algorithmes
**Visualisation du problème d'ordonnancement concernant l'exemple précédent (base bleue, ring vert, ring rouge, cap noir)
 
Ici, on a pris en plus en hypothèse le fait que la Ring Station (RS1) est capable de mettre des rings rouges ou verts et que la RS2 est capable de de mettre des rings bleus et rouges. Afin de mieux appréhender le problème, nous nous sommes attachés à effectuer un tableau récapitulant les tâches à effectuer pour le produit exemple et à réaliser un graphe mettant en avant les contraintes de précédence de chaque tâche.
 

{| class="wikitable" style="text-align:center; width:80%;"

|-
|
! scope="col" | Tâches
! scope="col" | Ressources utilisées
! scope="col" | Contraintes de précédence
|-
! scope="row" | T0
| Ramener à CS base avec cap
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T1
| Décapsuler
| Cap Station 1 ou 2
| T0
|-
! scope="row" | T2
| Ramener base supplémentaires à RS
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T3
| Chercher base bleue
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T4
| Ramener à RS pour ring vert
| Robot 1, 2 ou 3
| T7
|-
! scope="row" | T5
| Ramener à RS pour ring rouge
| Robot 1, 2 ou 3
| T8
|-
! scope="row" | T6
| Ramener à CS pour cap
| Robot 1, 2 ou 3
| T9
|-
! scope="row" | T7
| Ramener Base
| Base Station
| T3
|-
! scope="row" | T8
| Ajouter ring vert
| Ring Station 1
| T4
|-
! scope="row" | T9
| Ajouter ring rouge
| Ring Station 1 ou 2
| T5 et T2
|-
! scope="row" | T10
| Ajouter cap
| Cap Station 1 ou 2
| T6 et T1
|-
! scope="row" | T11
| Traiter le produit fini
| Delivery Station
| T12
|-
! scope="row" | T12
| Ramener à DS
| Robot 1, 2 ou 3
| T10
|}
[[Fichier:TachesProduitExemple.png|center]]
<center>Graphe montrant l'ordre des tâches à réaliser</center>
 

===Semaine 5===
Durant cette semaine, nous avons réfléchi sur le choix de structures pour nos données :
* Une '''liste principale''' de tous les produits demandés par la RefBox à un instant t. Cette liste principale a les caractéristiques suivantes :
** Une '''Priorité''' sera calculée pour chaque produit avec les paramètres suivants :
*** Nombre de points que peut apporter la production d'un produit de A à Z.
*** Une estimation du temps de production d'un produit.
***La date limite de livraison du produit demandé
** Une tâche est élue si sa priorité est supérieure ou égale à celle des autres tâches.
** Quand la RefBox demande un produit, une cellule sera ajoutée dans cette liste. Et de même, quand un produit sera terminé, on le supprimera de cette liste.
* Chaque produit de la liste principale va contenir une '''liste de tâches''' correspondantes à la production de ce produit. Cette liste de tâches a les caractéristiques suivantes :
** Chaque cellule correspond à une tâche de la production d'un produit. Une tâche contient différents champs :
***Intitulé de la tâche (par exemple ajouter une base)
***Produit concernée (par exemple P3)
***Priorité de la tâche (par exemple 20)
***Temps restant estimé de production (par exemple 180s)
** A chaque fois qu'une tâche est réalisée, elle sera supprimée de la liste de tâches. Ce qui veut dire, qu'on va devoir calculé à nouveau la priorité de chaque tâche de la liste principale.
** Afin de respecter les contraintes de précédence, on considérera que la tâche en tête de la liste de tâches peut être élue. Par exemple, on ne peut pas ajouter un Ring si on n'a pas de base.
 
L'exemple suivant simule le cas où la RefBox a demandé deux fois le produit P3 et deux fois le produit P2.
*Le produit P3 est réalisable en cinq tâches.Ce produit mettra plus de temps à être fabriqué mais rapportera plus de points.
*Le produit P2 est réalisable en quatre tâches.
 
[[Fichier:listedelistes.png|center]]
<center>Structure utilisée pour ranger les tâches à réaliser</center>
 
Différentes remarques utiles :
*Avant de commencer à réaliser n'importe quel produit, il faudra au préalable vérifier si on a libérer un espace de stockage pour plusieurs raisons :
**Les Cap Stations ayant initialement aucun cap en stock, il faut les ramener de l'étagère qui en contient initialement car un produit est dit fini lorsqu'il a à son sommet un cap.
**L'étagère ayant été débarrassée d'un cap, cela permet d'avoir un espace de stockage afin de déposer des produits finis en attente de livraison ou des produits non finis dont on voudrait mettre en pause la production.
*Il sera peut être des fois plus avantageux d'abandonner temporairement la production d'un produit :
**Il vaut mieux faire en sorte de terminer un seul produit sur deux dans les temps plutôt qu'aucun car du fait de la parallélisation de la fabrication des produits, on peut être surchargé de travail.
**Un produit livré durant le laps de temps demandé rapportera plus de points non négligeables.
*Un tableau sera nécessaire afin de savoir ce qu'il y a les espaces de stockage avec les champs suivants :
**Type de produit
**Liste de tâches restantes pour la fabrication du produit (pour un produit fini cette liste est donc nulle)
**Date de début de livraison
**Date de fin de livraison
**Emplacement de l'espace de stockage
 

===Semaine 6===
*Différentes fonctions et actions en pseudo code pour le générateur de tâches
**Fonction qui retourne un booléen suivant si un produit est en stock ou non
**Fonction qui retourne un booléen suivant si on doit livrer le produit à présent ou non
**Fonction qui retourne un booléen suivant si on a déjà ou non mis le travail à faire dans la structure contenant les tâches à réaliser
**Fonction qui retourne le nombre de points que rapporte un produit passé en paramètre
**Action qui rajoute les nouveaux ordres de production dans la liste de listes de tâches
**Action qui calcule le ratio pour chaque tâche
**Action qui supprime les tâches vides (ie celles qui sont terminées)
*Début de l'écriture en pseudo code de la fonction principale
 
*Discussion avec M. Vincent Coelen concernant l'avancement du projet :
**Validation par M. Coelen Vincent des portions de pseudo code déjà écrites
**Discussion autour de la mise en place d'un arrêt immédiat des robots à tout moment du jeu
**Amélioration concernant la robustesse de l'algorithme si un robot n'est plus en état de fonctionnement
 
*Différentes remarques utiles :
**Branche concernant le manager créée sur le [https://github.com/PyroTeam/robocup-pkg/ git] de l'équipe
**Discussion avec d'autres membres de l'équipe sur les services et les topics à envoyer et à recevoir aux nœuds du manager
 
===Semaine 7===

====Générateur de tâches====
Début du codage C++ :
*Création de différentes classes :
**La classe Tache (tache.h et tache.cpp)
**La classe Stockage (stockage.h et stockage.cpp)
**La classe RefBoxComm (refboxcomm.h)
*Création de différentes fonctions :
**Dans tache.h et tache.cpp :
***point_par_produit : retourne le nombre de points que vaut un produit
***dans_les_temps : retourne un booléen indiquant s'il est temps de ramener le produit
**Dans listetaches.h et listetaches.cpp :
***creation_liste_taches_prod : retourne une liste de taches à partir d'un produit passé en paramètre
***creation_liste_taches_act : retourne une liste de taches à partir d'un produit et d'une action passés en paramètres
**Dans tableaustockage.h :
***produit_en_stock : retourne un booléen indiquant si au moins un produit est en stock
**Dans travail.h et travail.cpp :
***deja_dans_travail : retourne un booléen indiquant si un ordre de la RefBox a déjà été pris en compte dans la structure contenant les tâches à réaliser
***max_ratio : retourne l'objet Tache qui a le plus grand ratio dans la structure contenant les tâches à réaliser
***rajout_dans_travail : rajoute un nouvel ordre de la RefBox dans la structure contenant les tâches à réaliser
***calcul_ratio : calcule le ratio de chaque premier de liste de la structure contenant les tâches à réaliser
 
Les codes sont disponibles sur le [https://github.com/PyroTeam/robocup-pkg/tree/feature/manager/generateur_taches git]
 
Des tests ont été réalisés afin de valider les fonctions crées en particulier les fonctions contenues dans travail.h et travail.cpp
 
Voici un petit aperçu de la console :
 
[[Fichier:Capture terminal gen taches 3.png|800px]]
 
Ainsi, les quatres fonctions fonctionnent parfaitement :
*deja_dans_travail indique bien que l'ordre de la RefBox n'a pas encore pris en compte
*max_ratio retourne bien la tâche dont le ratio est maximum
*rajout_dans_travail rajoute en fin de liste la liste de tâches pour la première création d'un produit P0 car un cap est disponible , puis il concatène une liste contenant en tête la tâche "Decapsuler" avec la liste de tâches pour la seconde création d'un produit P0. En effet, la RefBox a demandé deux fois le produit P0 et on ne peut créer un produit tant qu'un cap n'est pas disponible.
*calcul_ratio calcule le ratio de chaque première tâche en fonction du nombre de points et du temps, de plus, si c'est le bon moment pour déstocker un produit il passe cette tâche "Destocker" en priorité (liste 6), en outre, la création d'un produit (liste 1 et liste 7) est prioritaire à l'unique tâche "Decapsuler" (listes 2, 3, 4 et 5) .
 
'''Nous avons enfin reçu le sujet 2015 pour la compétition 2015, il est disponible [https://drive.google.com/file/d/0B39jN82rDE6qSk11YXFuQVljTlE/view?usp=sharing ici]'''
 
*Modification à réaliser :
**la fonction de création de liste de tâches
**l'ordonnancement (en partie)
**calcul de ratio de chaque tâche

====Exécuteur de tâches====
L'éxécuteur de taches va recevoir des ordres de la part du générateur de taches . En fonction de ces ordres, il enverra des demandes d'exécution/d'informations aux autres noeuds. Il y a donc un seul générateur de taches et trois exécuteurs de taches ( on a trois robotinos ).
Voici les classes qui correspondent à chaque exécuteur de taches :
[[Fichier:shema1.png]]
*'''Machine''' est une classe abstraite qui servira à la création des quatre classes filles qui représenteront les quatre machines de la compétition.
** ''string type'' sera donc BaseStation, RingStation, CapStation ou DeliveryStation.
** ''Pose2D centreMachine'' est un point(x,y,theta) qui va correspondre au retour du noeud de localisation (Projet 36)
** ''Pose2D entreeMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour déposer un produit
** ''Pose2D sortieMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour prendre un produit
*'''BaseStation''' est une classe fille de la classe "Machine".
** ''int baseRouge'', ''int baseNoir'' et ''int baseArgent'' vont correspondre aux nombres de bases rouges, bases noires, base argentes respectivement.
*'''RingStation''' est une classe fille de la classe "Machine".
** ''int ringVert'', ''int ringJaune'', ''int ringBleu'' et ''ringOrange'' vont correspondre aux nombres de rings verts, rings jaunes, rings bleus et rings oranges respectivement.
*'''CapStation''' est une classe fille de la classe "Machine".
** ''int capNoir'' et ''int capGris'' vont correspondre aux nombres de caps noirs et caps gris respectivement.
** ''int stock[3]'' est un tableau qui va correspondre aux trois emplacements stockage de la capStation.
** 'Pose2D stockage'' est un point(x,y,theta) qui correspond à l'emplacement de la première zone de stockage.

===Semaine 8===
====Générateur de tâches====
*Création du service pour l'envoi des ordres pour l’exécuteur de tâches avec pour contenu:
**Numéro du robot
***1, 2 ou 3
**Ordre
***ChercherBase
***MettreCap
***ChercherCap
***MettreRing
***ChercherRing
***RamenerBaseRS
***Livrer
***Decapsuler
***Destocker
**Paramètre
***noir
***argent
***rouge
***orange
***jaune
***bleu
***vert
***gris
***DS
***stock
***aucun
**Id
***0, 1, 2, 3, 4, 5 ou 6
 
L'exécuteur de tâches du robot concerné doit envoyer en retour :
*un booléen qui indique si l'ordre est accepté ou non
*l'ordre pris en compte
*l'Id de retour
 
Création d'un nœud ROS pour le débogage à l'aide de ddd
 
Création d'un nœud ROS pour similer l'envoi et la réception des ordres
 
 
Création de la classe action qui range les informations contenues dans le topic envoyé par l'exécuteur de tâches 
Utilisation de la classe action dans la fonction principale pour la phase de production 
Test OK cependant le traitement des informations ne se fait pas suffisamment rapidement pour une utilisation pratique
 

====Exécuteur de tâches====
L'exécuteur de taches est un noeud qui recevra des ordres de la part du générateur de taches et qui, à son tour, va envoyer des ordres aux autres noeuds.

Avec ROS, on peut communiquer entre les différents noeuds de plusieurs façons. En voici deux qui sont principalement utilisés :
* Les Topics : qui sont souvent utilisés pour publier des valeurs de données en continues
* Les services : qui permettent d'envoyer un ordre à un noeud (REQUEST) et qui permettent de recevoir de bonne réception de l'ordre (RESPONSE)

Voici le schéma de communication entre les différents noeuds, en rouge on a les services et en bleu les topics :

[[Fichier:schema2.jpg]]

===Semaine 9===
 
====Exécuteur de tâches====
Après avoir discuter avec les autres membres de l'équipe, nous avons réalisé quelques modification au niveau des communications entre l'exécuteur de taches et les autres noeuds. En fait, les services permettent d'envoyer une requête au serveur correspondant et ensuite le client reçoit une réponse de bonne réception de la requête. Alors que les topics permettent d'envoyer, à une certaine fréquence, les valeurs de variables qui correspondent à ce topic. Ainsi, on remarque qu'on aurait besoin d'utiliser un "mélange" de ces deux moyens de communication. En Ros, cela existe : les actions .

Voici donc à nouveau le schéma de communication :
[[Fichier:Schema.001.jpg]]

===Semaine 10===
 
====Exécuteur de tâches====
Afin de pouvoir tester l'interaction de l'exécuteur de taches avec les autres noeuds, nous avons du faire des "faux noeuds" étant donné que les "vrais noeuds" n'étaient pas encore terminés.
[[Fichier:Before_order.jpg]]
===Semaine 11===
 
===Semaine 12===
 

== Fichiers Rendus ==

Fichier:Before order.tiff

2015-05-04T10:47:53Z

Shage-ch :

RoboCup 2015

2015-04-15T21:36:57Z

Shage-ch : /* Exécuteur de tâches */

__TOC__
 
[[Fichier:logoPyro_icone.png |center ]]
<center> Polytech RoboCup Team </center>

==Cahier des charges==
===Présentation générale du projet===

Lors de la compétition de l'Open German, prélude de la Robocup, il faudra mettre en place un système d'autonomisation de production à l'aide de Robotinos (robots mobiles de Festo ayant un système d'exploitation Linux). Comme dans toutes compétitions, le but est de gagner, par conséquent, il faudra faire en sorte de gagner un maximum de points.
C'est pourquoi il faut créer un manager à l'aide de ROS, c'est-à-dire un nœud ou ensemble de nœuds permettant de pouvoir recevoir les informations envoyées par les autres nœuds, de les traiter, tout cela afin de donner les ordres que doivent exécuter chaque Robotino. Ce manager devra également être capable d'optimiser le nombre de points à obtenir.

====Contexte====

La compétition de l'Open German se déroule en quatre phases spécifiques : phase de début-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des tâches spécifiques à remplir suivant les différentes phases. La RefereeBox est un système d'arbitrage auquel il est nécessaire d'envoyer périodiquement des données à tout moment du jeu et qui donne à chaque instant l'état du jeu ainsi que les produits demandés en priorité durant la phase de production.

====Objectif du projet====

*Assurer un maximum de points suivant les aléas du jeu (panne de machine, produits demandées, rupture de stock d'une matière première, …)
*Assurer la pérennité du projet (chaque année des candidats de Polytech Lille y participent)

====Description du projet====

Pour le projet, outre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes :
*Communication avec le nœud de la RefereeBox à tout moment du jeu
*Contrainte de robustesse (il ne faut qu'à un moment ou à un autre il n'y ait un blocage de tous les robots)
*Coopération entre les trois robots
 
[[Fichier:Interactions.png|vignette|left|upright=2|Interactions des nœuds avec le manager]]
 
Le manager devra interagir avec les différents nœuds suivants ayant chacun leurs rôles spécifiques :
*RefereeBox Comm : recevoir les données envoyées par la RefereeBox et envoyer des données suivant l'état du jeu à la RefereeBox
*Robots Comm : communiquer aux autres robots les informations concernant ce que chacun font
*Traitement des TAGs : lire les TAG
*Traitement des feux : lire l'état des colonnes de feu
*Pince de préhension : ouvrir et fermer la pince et renvoyer l'état de la pince
*Approche finale : s'adapter au banc de charge ou de décharge de produits
*Génération trajectoire : détermine une trajectoire pour aller au lieu (X,Y)
*Réalisation trajectoire : parcourir la trajectoire
*Localisation : savoir périodiquement (faible période) où se situe le robot
*Détection d'obstacle : détecter les obstacles fixes et mobiles
 

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

*Utilisation de trois robotinos
*Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce système travaille en utilisant des nœuds qui communiquent entre eux à l'aide de services (requête-réponse) et de topics (fichiers).
*Utilisation de différents langages : C++ ou Python (nœuds)
*Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS
 

===Etapes du projet===
*Prise en main de ROS et du C++
*Élaboration de l'algorithme du manager pour la phase d'exploration
*Élaboration de l'algorithme du manager pour la phase de production
**Coopération entre robots
**Répartition des tâches
*Codage du manager
*Tests et corrections
 

==Avancement du Projet==
===Semaine 1===
*Prise en main de ROS
*Réalisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials
*Réalisation de différents tutoriels C++
*Connaissance plus aiguë du sujet de l'Open German 2015
 
===Semaine 2===
*Réflexions autour de la structure du manager : deux nœuds
**Un nœud exécuteur de tâches
**Un nœud générateur de tâches
*Réflexions sur l'algorithme général du manager concernant la phase d'exploration
**Fonctionnement par zoning pour la répartition des tâches des trois robots
**Réflexion autour d'une alternative de répartition par distances les plus courtes entre machines
*Recherche de solutions pour la phase de production
**Documentation autour de la planification de tâches et la génération de tâche pour une équipe
**Recherche autour de la coopération et de l'allocation de rôles à des robots multi-tâches
*Organisation générale
**Structuration d'un échéancier numérique sous Asana
**Demande d'autorisation pour l'ouverture de la salle C002 auprès de M. Scrive
 

===Semaine 3===
Voilà un lien permettant d'accéder au sujet provisoire de la Robocup 2015 : [https://drive.google.com/file/d/0B39jN82rDE6qMG45cDN5Z0xiSVE/view?usp=sharing Sujet] 
*Réflexions au sujet des infos à communiquer au nœud AutresRobotsComm :
**Ce que le robotino fait
**Quelle machine le robotino est en train d'utiliser
[[Fichier:DataSWithRobotComm.jpg|center]]
 
*Réflexions au niveau de l'algorithme de la phase de production
**Proposition de le faire sous le principe de "Diviser pour mieux régner" (validé par M. Vincent Coelen)
***Diviser la tâche principale en sous-tâches, les sous-tâches en sous-sous-tâches et les sous-sous-tâches en sous-sous-sous-tâches élémentaires.
**Détermination des tâches à réaliser pour un exemple particulier
On souhaite produire, pendant une durée déterminée par la refBox, le produit suivant :
[[Fichier:ExempleProduitDemande.jpg|center]]
''Le produit est composé d’une base bleue, d’un ring rouge, d’un ring vert et d’un cap noir.''

'''Obtenir Base Bleue'''
->Aller à la Base Station
générateur trajectoire
exécuteur trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (dire à la Base Station quelle base est souhaitée et à quelle banc le robotino est)
approche finale
pince (prendre)

'''Obtenir ring rouge'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Obtenir ring vert'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
(Du coup la plus proche sera celle où on vient de faire le ring précédent)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Ring Station quelle base est souhaitée ( ici, la verte )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Finaliser produit'''
->Aller à une Cap Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Cap Station quelle cap est souhaité ( ici, le noir )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel banc de livraison)
approche finale
pince (prendre)
->Déposer à la Delivery Station
générateur de trajectoire (vers la Delivery Station)
exécuteur de trajectoire
approche finale
pince (déposer)
 
*Organisation générale :
**Création de la page Facebook de l'équipe PYRO Team
 

===Semaine 4===
*Écriture des sous-tâches à réaliser
**Pseudo-codes de certaines sous-tâches réalisées
*Recherche d'ordonnancement optimisé pour la fabrication du produit
**Recherche d'algorithmes
**Visualisation du problème d'ordonnancement concernant l'exemple précédent (base bleue, ring vert, ring rouge, cap noir)
 
Ici, on a pris en plus en hypothèse le fait que la Ring Station (RS1) est capable de mettre des rings rouges ou verts et que la RS2 est capable de de mettre des rings bleus et rouges. Afin de mieux appréhender le problème, nous nous sommes attachés à effectuer un tableau récapitulant les tâches à effectuer pour le produit exemple et à réaliser un graphe mettant en avant les contraintes de précédence de chaque tâche.
 

{| class="wikitable" style="text-align:center; width:80%;"

|-
|
! scope="col" | Tâches
! scope="col" | Ressources utilisées
! scope="col" | Contraintes de précédence
|-
! scope="row" | T0
| Ramener à CS base avec cap
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T1
| Décapsuler
| Cap Station 1 ou 2
| T0
|-
! scope="row" | T2
| Ramener base supplémentaires à RS
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T3
| Chercher base bleue
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T4
| Ramener à RS pour ring vert
| Robot 1, 2 ou 3
| T7
|-
! scope="row" | T5
| Ramener à RS pour ring rouge
| Robot 1, 2 ou 3
| T8
|-
! scope="row" | T6
| Ramener à CS pour cap
| Robot 1, 2 ou 3
| T9
|-
! scope="row" | T7
| Ramener Base
| Base Station
| T3
|-
! scope="row" | T8
| Ajouter ring vert
| Ring Station 1
| T4
|-
! scope="row" | T9
| Ajouter ring rouge
| Ring Station 1 ou 2
| T5 et T2
|-
! scope="row" | T10
| Ajouter cap
| Cap Station 1 ou 2
| T6 et T1
|-
! scope="row" | T11
| Traiter le produit fini
| Delivery Station
| T12
|-
! scope="row" | T12
| Ramener à DS
| Robot 1, 2 ou 3
| T10
|}
[[Fichier:TachesProduitExemple.png|center]]
<center>Graphe montrant l'ordre des tâches à réaliser</center>
 

===Semaine 5===
Durant cette semaine, nous avons réfléchi sur le choix de structures pour nos données :
* Une '''liste principale''' de tous les produits demandés par la RefBox à un instant t. Cette liste principale a les caractéristiques suivantes :
** Une '''Priorité''' sera calculée pour chaque produit avec les paramètres suivants :
*** Nombre de points que peut apporter la production d'un produit de A à Z.
*** Une estimation du temps de production d'un produit.
***La date limite de livraison du produit demandé
** Une tâche est élue si sa priorité est supérieure ou égale à celle des autres tâches.
** Quand la RefBox demande un produit, une cellule sera ajoutée dans cette liste. Et de même, quand un produit sera terminé, on le supprimera de cette liste.
* Chaque produit de la liste principale va contenir une '''liste de tâches''' correspondantes à la production de ce produit. Cette liste de tâches a les caractéristiques suivantes :
** Chaque cellule correspond à une tâche de la production d'un produit. Une tâche contient différents champs :
***Intitulé de la tâche (par exemple ajouter une base)
***Produit concernée (par exemple P3)
***Priorité de la tâche (par exemple 20)
***Temps restant estimé de production (par exemple 180s)
** A chaque fois qu'une tâche est réalisée, elle sera supprimée de la liste de tâches. Ce qui veut dire, qu'on va devoir calculé à nouveau la priorité de chaque tâche de la liste principale.
** Afin de respecter les contraintes de précédence, on considérera que la tâche en tête de la liste de tâches peut être élue. Par exemple, on ne peut pas ajouter un Ring si on n'a pas de base.
 
L'exemple suivant simule le cas où la RefBox a demandé deux fois le produit P3 et deux fois le produit P2.
*Le produit P3 est réalisable en cinq tâches.Ce produit mettra plus de temps à être fabriqué mais rapportera plus de points.
*Le produit P2 est réalisable en quatre tâches.
 
[[Fichier:listedelistes.png|center]]
<center>Structure utilisée pour ranger les tâches à réaliser</center>
 
Différentes remarques utiles :
*Avant de commencer à réaliser n'importe quel produit, il faudra au préalable vérifier si on a libérer un espace de stockage pour plusieurs raisons :
**Les Cap Stations ayant initialement aucun cap en stock, il faut les ramener de l'étagère qui en contient initialement car un produit est dit fini lorsqu'il a à son sommet un cap.
**L'étagère ayant été débarrassée d'un cap, cela permet d'avoir un espace de stockage afin de déposer des produits finis en attente de livraison ou des produits non finis dont on voudrait mettre en pause la production.
*Il sera peut être des fois plus avantageux d'abandonner temporairement la production d'un produit :
**Il vaut mieux faire en sorte de terminer un seul produit sur deux dans les temps plutôt qu'aucun car du fait de la parallélisation de la fabrication des produits, on peut être surchargé de travail.
**Un produit livré durant le laps de temps demandé rapportera plus de points non négligeables.
*Un tableau sera nécessaire afin de savoir ce qu'il y a les espaces de stockage avec les champs suivants :
**Type de produit
**Liste de tâches restantes pour la fabrication du produit (pour un produit fini cette liste est donc nulle)
**Date de début de livraison
**Date de fin de livraison
**Emplacement de l'espace de stockage
 

===Semaine 6===
*Différentes fonctions et actions en pseudo code pour le générateur de tâches
**Fonction qui retourne un booléen suivant si un produit est en stock ou non
**Fonction qui retourne un booléen suivant si on doit livrer le produit à présent ou non
**Fonction qui retourne un booléen suivant si on a déjà ou non mis le travail à faire dans la structure contenant les tâches à réaliser
**Fonction qui retourne le nombre de points que rapporte un produit passé en paramètre
**Action qui rajoute les nouveaux ordres de production dans la liste de listes de tâches
**Action qui calcule le ratio pour chaque tâche
**Action qui supprime les tâches vides (ie celles qui sont terminées)
*Début de l'écriture en pseudo code de la fonction principale
 
*Discussion avec M. Vincent Coelen concernant l'avancement du projet :
**Validation par M. Coelen Vincent des portions de pseudo code déjà écrites
**Discussion autour de la mise en place d'un arrêt immédiat des robots à tout moment du jeu
**Amélioration concernant la robustesse de l'algorithme si un robot n'est plus en état de fonctionnement
 
*Différentes remarques utiles :
**Branche concernant le manager créée sur le [https://github.com/PyroTeam/robocup-pkg/ git] de l'équipe
**Discussion avec d'autres membres de l'équipe sur les services et les topics à envoyer et à recevoir aux nœuds du manager
 
===Semaine 7===

====Générateur de tâches====
Début du codage C++ :
*Création de différentes classes :
**La classe Tache (tache.h et tache.cpp)
**La classe Stockage (stockage.h et stockage.cpp)
**La classe RefBoxComm (refboxcomm.h)
*Création de différentes fonctions :
**Dans tache.h et tache.cpp :
***point_par_produit : retourne le nombre de points que vaut un produit
***dans_les_temps : retourne un booléen indiquant s'il est temps de ramener le produit
**Dans listetaches.h et listetaches.cpp :
***creation_liste_taches_prod : retourne une liste de taches à partir d'un produit passé en paramètre
***creation_liste_taches_act : retourne une liste de taches à partir d'un produit et d'une action passés en paramètres
**Dans tableaustockage.h :
***produit_en_stock : retourne un booléen indiquant si au moins un produit est en stock
**Dans travail.h et travail.cpp :
***deja_dans_travail : retourne un booléen indiquant si un ordre de la RefBox a déjà été pris en compte dans la structure contenant les tâches à réaliser
***max_ratio : retourne l'objet Tache qui a le plus grand ratio dans la structure contenant les tâches à réaliser
***rajout_dans_travail : rajoute un nouvel ordre de la RefBox dans la structure contenant les tâches à réaliser
***calcul_ratio : calcule le ratio de chaque premier de liste de la structure contenant les tâches à réaliser
 
Les codes sont disponibles sur le [https://github.com/PyroTeam/robocup-pkg/tree/feature/manager/generateur_taches git]
 
Des tests ont été réalisés afin de valider les fonctions crées en particulier les fonctions contenues dans travail.h et travail.cpp
 
Voici un petit aperçu de la console :
 
[[Fichier:Capture terminal gen taches 3.png|800px]]
 
Ainsi, les quatres fonctions fonctionnent parfaitement :
*deja_dans_travail indique bien que l'ordre de la RefBox n'a pas encore pris en compte
*max_ratio retourne bien la tâche dont le ratio est maximum
*rajout_dans_travail rajoute en fin de liste la liste de tâches pour la première création d'un produit P0 car un cap est disponible , puis il concatène une liste contenant en tête la tâche "Decapsuler" avec la liste de tâches pour la seconde création d'un produit P0. En effet, la RefBox a demandé deux fois le produit P0 et on ne peut créer un produit tant qu'un cap n'est pas disponible.
*calcul_ratio calcule le ratio de chaque première tâche en fonction du nombre de points et du temps, de plus, si c'est le bon moment pour déstocker un produit il passe cette tâche "Destocker" en priorité (liste 6), en outre, la création d'un produit (liste 1 et liste 7) est prioritaire à l'unique tâche "Decapsuler" (listes 2, 3, 4 et 5) .
 
'''Nous avons enfin reçu le sujet 2015 pour la compétition 2015, il est disponible [https://drive.google.com/file/d/0B39jN82rDE6qSk11YXFuQVljTlE/view?usp=sharing ici]'''
 
*Modification à réaliser :
**la fonction de création de liste de tâches
**l'ordonnancement (en partie)
**calcul de ratio de chaque tâche

====Exécuteur de tâches====
L'éxécuteur de taches va recevoir des ordres de la part du générateur de taches . En fonction de ces ordres, il enverra des demandes d'exécution/d'informations aux autres noeuds. Il y a donc un seul générateur de taches et trois exécuteurs de taches ( on a trois robotinos ).
Voici les classes qui correspondent à chaque exécuteur de taches :
[[Fichier:shema1.png]]
*'''Machine''' est une classe abstraite qui servira à la création des quatre classes filles qui représenteront les quatre machines de la compétition.
** ''string type'' sera donc BaseStation, RingStation, CapStation ou DeliveryStation.
** ''Pose2D centreMachine'' est un point(x,y,theta) qui va correspondre au retour du noeud de localisation (Projet 36)
** ''Pose2D entreeMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour déposer un produit
** ''Pose2D sortieMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour prendre un produit
*'''BaseStation''' est une classe fille de la classe "Machine".
** ''int baseRouge'', ''int baseNoir'' et ''int baseArgent'' vont correspondre aux nombres de bases rouges, bases noires, base argentes respectivement.
*'''RingStation''' est une classe fille de la classe "Machine".
** ''int ringVert'', ''int ringJaune'', ''int ringBleu'' et ''ringOrange'' vont correspondre aux nombres de rings verts, rings jaunes, rings bleus et rings oranges respectivement.
*'''CapStation''' est une classe fille de la classe "Machine".
** ''int capNoir'' et ''int capGris'' vont correspondre aux nombres de caps noirs et caps gris respectivement.
** ''int stock[3]'' est un tableau qui va correspondre aux trois emplacements stockage de la capStation.
** 'Pose2D stockage'' est un point(x,y,theta) qui correspond à l'emplacement de la première zone de stockage.

===Semaine 8===
====Générateur de tâches====
*Création du service pour l'envoi des ordres pour l’exécuteur de tâches avec pour contenu:
**Numéro du robot
***1, 2 ou 3
**Ordre
***ChercherBase
***MettreCap
***ChercherCap
***MettreRing
***ChercherRing
***RamenerBaseRS
***Livrer
***Decapsuler
***Destocker
**Paramètre
***noir
***argent
***rouge
***orange
***jaune
***bleu
***vert
***gris
***DS
***stock
***aucun
**Id
***0, 1, 2, 3, 4, 5 ou 6
 
L'exécuteur de tâches du robot concerné doit envoyer en retour :
*un booléen qui indique si l'ordre est accepté ou non
*l'ordre pris en compte
*l'Id de retour
 
Création d'un nœud ROS pour le débogage à l'aide de ddd
 
Création d'un nœud ROS pour similer l'envoi et la réception des ordres
 
 
Création de la classe action qui range les informations contenues dans le topic envoyé par l'exécuteur de tâches 
Utilisation de la classe action dans la fonction principale pour la phase de production 
Test OK cependant le traitement des informations ne se fait pas suffisamment rapidement pour une utilisation pratique
 

====Exécuteur de tâches====
L'exécuteur de taches est un noeud qui recevra des ordres de la part du générateur de taches et qui, à son tour, va envoyer des ordres aux autres noeuds.

Avec ROS, on peut communiquer entre les différents noeuds de plusieurs façons. En voici deux qui sont principalement utilisés :
* Les Topics : qui sont souvent utilisés pour publier des valeurs de données en continues
* Les services : qui permettent d'envoyer un ordre à un noeud (REQUEST) et qui permettent de recevoir de bonne réception de l'ordre (RESPONSE)

Voici le schéma de communication entre les différents noeuds, en rouge on a les services et en bleu les topics :

[[Fichier:schema2.jpg]]

===Semaine 9===
 
====Exécuteur de tâches====
Après avoir discuter avec les autres membres de l'équipe, nous avons réalisé quelques modification au niveau des communications entre l'exécuteur de taches et les autres noeuds. En fait, les services permettent d'envoyer une requête au serveur correspondant et ensuite le client reçoit une réponse de bonne réception de la requête. Alors que les topics permettent d'envoyer, à une certaine fréquence, les valeurs de variables qui correspondent à ce topic. Ainsi, on remarque qu'on aurait besoin d'utiliser un "mélange" de ces deux moyens de communication. En Ros, cela existe : les actions .

Voici donc à nouveau le schéma de communication :
[[Fichier:Schema.001.jpg]]

===Semaine 10===
 
===Semaine 11===
 
===Semaine 12===
 

== Fichiers Rendus ==

RoboCup 2015

2015-04-15T21:18:56Z

Shage-ch :

__TOC__
 
[[Fichier:logoPyro_icone.png |center ]]
<center> Polytech RoboCup Team </center>

==Cahier des charges==
===Présentation générale du projet===

Lors de la compétition de l'Open German, prélude de la Robocup, il faudra mettre en place un système d'autonomisation de production à l'aide de Robotinos (robots mobiles de Festo ayant un système d'exploitation Linux). Comme dans toutes compétitions, le but est de gagner, par conséquent, il faudra faire en sorte de gagner un maximum de points.
C'est pourquoi il faut créer un manager à l'aide de ROS, c'est-à-dire un nœud ou ensemble de nœuds permettant de pouvoir recevoir les informations envoyées par les autres nœuds, de les traiter, tout cela afin de donner les ordres que doivent exécuter chaque Robotino. Ce manager devra également être capable d'optimiser le nombre de points à obtenir.

====Contexte====

La compétition de l'Open German se déroule en quatre phases spécifiques : phase de début-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des tâches spécifiques à remplir suivant les différentes phases. La RefereeBox est un système d'arbitrage auquel il est nécessaire d'envoyer périodiquement des données à tout moment du jeu et qui donne à chaque instant l'état du jeu ainsi que les produits demandés en priorité durant la phase de production.

====Objectif du projet====

*Assurer un maximum de points suivant les aléas du jeu (panne de machine, produits demandées, rupture de stock d'une matière première, …)
*Assurer la pérennité du projet (chaque année des candidats de Polytech Lille y participent)

====Description du projet====

Pour le projet, outre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes :
*Communication avec le nœud de la RefereeBox à tout moment du jeu
*Contrainte de robustesse (il ne faut qu'à un moment ou à un autre il n'y ait un blocage de tous les robots)
*Coopération entre les trois robots
 
[[Fichier:Interactions.png|vignette|left|upright=2|Interactions des nœuds avec le manager]]
 
Le manager devra interagir avec les différents nœuds suivants ayant chacun leurs rôles spécifiques :
*RefereeBox Comm : recevoir les données envoyées par la RefereeBox et envoyer des données suivant l'état du jeu à la RefereeBox
*Robots Comm : communiquer aux autres robots les informations concernant ce que chacun font
*Traitement des TAGs : lire les TAG
*Traitement des feux : lire l'état des colonnes de feu
*Pince de préhension : ouvrir et fermer la pince et renvoyer l'état de la pince
*Approche finale : s'adapter au banc de charge ou de décharge de produits
*Génération trajectoire : détermine une trajectoire pour aller au lieu (X,Y)
*Réalisation trajectoire : parcourir la trajectoire
*Localisation : savoir périodiquement (faible période) où se situe le robot
*Détection d'obstacle : détecter les obstacles fixes et mobiles
 

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

*Utilisation de trois robotinos
*Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce système travaille en utilisant des nœuds qui communiquent entre eux à l'aide de services (requête-réponse) et de topics (fichiers).
*Utilisation de différents langages : C++ ou Python (nœuds)
*Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS
 

===Etapes du projet===
*Prise en main de ROS et du C++
*Élaboration de l'algorithme du manager pour la phase d'exploration
*Élaboration de l'algorithme du manager pour la phase de production
**Coopération entre robots
**Répartition des tâches
*Codage du manager
*Tests et corrections
 

==Avancement du Projet==
===Semaine 1===
*Prise en main de ROS
*Réalisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials
*Réalisation de différents tutoriels C++
*Connaissance plus aiguë du sujet de l'Open German 2015
 
===Semaine 2===
*Réflexions autour de la structure du manager : deux nœuds
**Un nœud exécuteur de tâches
**Un nœud générateur de tâches
*Réflexions sur l'algorithme général du manager concernant la phase d'exploration
**Fonctionnement par zoning pour la répartition des tâches des trois robots
**Réflexion autour d'une alternative de répartition par distances les plus courtes entre machines
*Recherche de solutions pour la phase de production
**Documentation autour de la planification de tâches et la génération de tâche pour une équipe
**Recherche autour de la coopération et de l'allocation de rôles à des robots multi-tâches
*Organisation générale
**Structuration d'un échéancier numérique sous Asana
**Demande d'autorisation pour l'ouverture de la salle C002 auprès de M. Scrive
 

===Semaine 3===
Voilà un lien permettant d'accéder au sujet provisoire de la Robocup 2015 : [https://drive.google.com/file/d/0B39jN82rDE6qMG45cDN5Z0xiSVE/view?usp=sharing Sujet] 
*Réflexions au sujet des infos à communiquer au nœud AutresRobotsComm :
**Ce que le robotino fait
**Quelle machine le robotino est en train d'utiliser
[[Fichier:DataSWithRobotComm.jpg|center]]
 
*Réflexions au niveau de l'algorithme de la phase de production
**Proposition de le faire sous le principe de "Diviser pour mieux régner" (validé par M. Vincent Coelen)
***Diviser la tâche principale en sous-tâches, les sous-tâches en sous-sous-tâches et les sous-sous-tâches en sous-sous-sous-tâches élémentaires.
**Détermination des tâches à réaliser pour un exemple particulier
On souhaite produire, pendant une durée déterminée par la refBox, le produit suivant :
[[Fichier:ExempleProduitDemande.jpg|center]]
''Le produit est composé d’une base bleue, d’un ring rouge, d’un ring vert et d’un cap noir.''

'''Obtenir Base Bleue'''
->Aller à la Base Station
générateur trajectoire
exécuteur trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (dire à la Base Station quelle base est souhaitée et à quelle banc le robotino est)
approche finale
pince (prendre)

'''Obtenir ring rouge'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Obtenir ring vert'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
(Du coup la plus proche sera celle où on vient de faire le ring précédent)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Ring Station quelle base est souhaitée ( ici, la verte )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Finaliser produit'''
->Aller à une Cap Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Cap Station quelle cap est souhaité ( ici, le noir )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel banc de livraison)
approche finale
pince (prendre)
->Déposer à la Delivery Station
générateur de trajectoire (vers la Delivery Station)
exécuteur de trajectoire
approche finale
pince (déposer)
 
*Organisation générale :
**Création de la page Facebook de l'équipe PYRO Team
 

===Semaine 4===
*Écriture des sous-tâches à réaliser
**Pseudo-codes de certaines sous-tâches réalisées
*Recherche d'ordonnancement optimisé pour la fabrication du produit
**Recherche d'algorithmes
**Visualisation du problème d'ordonnancement concernant l'exemple précédent (base bleue, ring vert, ring rouge, cap noir)
 
Ici, on a pris en plus en hypothèse le fait que la Ring Station (RS1) est capable de mettre des rings rouges ou verts et que la RS2 est capable de de mettre des rings bleus et rouges. Afin de mieux appréhender le problème, nous nous sommes attachés à effectuer un tableau récapitulant les tâches à effectuer pour le produit exemple et à réaliser un graphe mettant en avant les contraintes de précédence de chaque tâche.
 

{| class="wikitable" style="text-align:center; width:80%;"

|-
|
! scope="col" | Tâches
! scope="col" | Ressources utilisées
! scope="col" | Contraintes de précédence
|-
! scope="row" | T0
| Ramener à CS base avec cap
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T1
| Décapsuler
| Cap Station 1 ou 2
| T0
|-
! scope="row" | T2
| Ramener base supplémentaires à RS
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T3
| Chercher base bleue
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T4
| Ramener à RS pour ring vert
| Robot 1, 2 ou 3
| T7
|-
! scope="row" | T5
| Ramener à RS pour ring rouge
| Robot 1, 2 ou 3
| T8
|-
! scope="row" | T6
| Ramener à CS pour cap
| Robot 1, 2 ou 3
| T9
|-
! scope="row" | T7
| Ramener Base
| Base Station
| T3
|-
! scope="row" | T8
| Ajouter ring vert
| Ring Station 1
| T4
|-
! scope="row" | T9
| Ajouter ring rouge
| Ring Station 1 ou 2
| T5 et T2
|-
! scope="row" | T10
| Ajouter cap
| Cap Station 1 ou 2
| T6 et T1
|-
! scope="row" | T11
| Traiter le produit fini
| Delivery Station
| T12
|-
! scope="row" | T12
| Ramener à DS
| Robot 1, 2 ou 3
| T10
|}
[[Fichier:TachesProduitExemple.png|center]]
<center>Graphe montrant l'ordre des tâches à réaliser</center>
 

===Semaine 5===
Durant cette semaine, nous avons réfléchi sur le choix de structures pour nos données :
* Une '''liste principale''' de tous les produits demandés par la RefBox à un instant t. Cette liste principale a les caractéristiques suivantes :
** Une '''Priorité''' sera calculée pour chaque produit avec les paramètres suivants :
*** Nombre de points que peut apporter la production d'un produit de A à Z.
*** Une estimation du temps de production d'un produit.
***La date limite de livraison du produit demandé
** Une tâche est élue si sa priorité est supérieure ou égale à celle des autres tâches.
** Quand la RefBox demande un produit, une cellule sera ajoutée dans cette liste. Et de même, quand un produit sera terminé, on le supprimera de cette liste.
* Chaque produit de la liste principale va contenir une '''liste de tâches''' correspondantes à la production de ce produit. Cette liste de tâches a les caractéristiques suivantes :
** Chaque cellule correspond à une tâche de la production d'un produit. Une tâche contient différents champs :
***Intitulé de la tâche (par exemple ajouter une base)
***Produit concernée (par exemple P3)
***Priorité de la tâche (par exemple 20)
***Temps restant estimé de production (par exemple 180s)
** A chaque fois qu'une tâche est réalisée, elle sera supprimée de la liste de tâches. Ce qui veut dire, qu'on va devoir calculé à nouveau la priorité de chaque tâche de la liste principale.
** Afin de respecter les contraintes de précédence, on considérera que la tâche en tête de la liste de tâches peut être élue. Par exemple, on ne peut pas ajouter un Ring si on n'a pas de base.
 
L'exemple suivant simule le cas où la RefBox a demandé deux fois le produit P3 et deux fois le produit P2.
*Le produit P3 est réalisable en cinq tâches.Ce produit mettra plus de temps à être fabriqué mais rapportera plus de points.
*Le produit P2 est réalisable en quatre tâches.
 
[[Fichier:listedelistes.png|center]]
<center>Structure utilisée pour ranger les tâches à réaliser</center>
 
Différentes remarques utiles :
*Avant de commencer à réaliser n'importe quel produit, il faudra au préalable vérifier si on a libérer un espace de stockage pour plusieurs raisons :
**Les Cap Stations ayant initialement aucun cap en stock, il faut les ramener de l'étagère qui en contient initialement car un produit est dit fini lorsqu'il a à son sommet un cap.
**L'étagère ayant été débarrassée d'un cap, cela permet d'avoir un espace de stockage afin de déposer des produits finis en attente de livraison ou des produits non finis dont on voudrait mettre en pause la production.
*Il sera peut être des fois plus avantageux d'abandonner temporairement la production d'un produit :
**Il vaut mieux faire en sorte de terminer un seul produit sur deux dans les temps plutôt qu'aucun car du fait de la parallélisation de la fabrication des produits, on peut être surchargé de travail.
**Un produit livré durant le laps de temps demandé rapportera plus de points non négligeables.
*Un tableau sera nécessaire afin de savoir ce qu'il y a les espaces de stockage avec les champs suivants :
**Type de produit
**Liste de tâches restantes pour la fabrication du produit (pour un produit fini cette liste est donc nulle)
**Date de début de livraison
**Date de fin de livraison
**Emplacement de l'espace de stockage
 

===Semaine 6===
*Différentes fonctions et actions en pseudo code pour le générateur de tâches
**Fonction qui retourne un booléen suivant si un produit est en stock ou non
**Fonction qui retourne un booléen suivant si on doit livrer le produit à présent ou non
**Fonction qui retourne un booléen suivant si on a déjà ou non mis le travail à faire dans la structure contenant les tâches à réaliser
**Fonction qui retourne le nombre de points que rapporte un produit passé en paramètre
**Action qui rajoute les nouveaux ordres de production dans la liste de listes de tâches
**Action qui calcule le ratio pour chaque tâche
**Action qui supprime les tâches vides (ie celles qui sont terminées)
*Début de l'écriture en pseudo code de la fonction principale
 
*Discussion avec M. Vincent Coelen concernant l'avancement du projet :
**Validation par M. Coelen Vincent des portions de pseudo code déjà écrites
**Discussion autour de la mise en place d'un arrêt immédiat des robots à tout moment du jeu
**Amélioration concernant la robustesse de l'algorithme si un robot n'est plus en état de fonctionnement
 
*Différentes remarques utiles :
**Branche concernant le manager créée sur le [https://github.com/PyroTeam/robocup-pkg/ git] de l'équipe
**Discussion avec d'autres membres de l'équipe sur les services et les topics à envoyer et à recevoir aux nœuds du manager
 
===Semaine 7===

====Générateur de tâches====
Début du codage C++ :
*Création de différentes classes :
**La classe Tache (tache.h et tache.cpp)
**La classe Stockage (stockage.h et stockage.cpp)
**La classe RefBoxComm (refboxcomm.h)
*Création de différentes fonctions :
**Dans tache.h et tache.cpp :
***point_par_produit : retourne le nombre de points que vaut un produit
***dans_les_temps : retourne un booléen indiquant s'il est temps de ramener le produit
**Dans listetaches.h et listetaches.cpp :
***creation_liste_taches_prod : retourne une liste de taches à partir d'un produit passé en paramètre
***creation_liste_taches_act : retourne une liste de taches à partir d'un produit et d'une action passés en paramètres
**Dans tableaustockage.h :
***produit_en_stock : retourne un booléen indiquant si au moins un produit est en stock
**Dans travail.h et travail.cpp :
***deja_dans_travail : retourne un booléen indiquant si un ordre de la RefBox a déjà été pris en compte dans la structure contenant les tâches à réaliser
***max_ratio : retourne l'objet Tache qui a le plus grand ratio dans la structure contenant les tâches à réaliser
***rajout_dans_travail : rajoute un nouvel ordre de la RefBox dans la structure contenant les tâches à réaliser
***calcul_ratio : calcule le ratio de chaque premier de liste de la structure contenant les tâches à réaliser
 
Les codes sont disponibles sur le [https://github.com/PyroTeam/robocup-pkg/tree/feature/manager/generateur_taches git]
 
Des tests ont été réalisés afin de valider les fonctions crées en particulier les fonctions contenues dans travail.h et travail.cpp
 
Voici un petit aperçu de la console :
 
[[Fichier:Capture terminal gen taches 3.png|800px]]
 
Ainsi, les quatres fonctions fonctionnent parfaitement :
*deja_dans_travail indique bien que l'ordre de la RefBox n'a pas encore pris en compte
*max_ratio retourne bien la tâche dont le ratio est maximum
*rajout_dans_travail rajoute en fin de liste la liste de tâches pour la première création d'un produit P0 car un cap est disponible , puis il concatène une liste contenant en tête la tâche "Decapsuler" avec la liste de tâches pour la seconde création d'un produit P0. En effet, la RefBox a demandé deux fois le produit P0 et on ne peut créer un produit tant qu'un cap n'est pas disponible.
*calcul_ratio calcule le ratio de chaque première tâche en fonction du nombre de points et du temps, de plus, si c'est le bon moment pour déstocker un produit il passe cette tâche "Destocker" en priorité (liste 6), en outre, la création d'un produit (liste 1 et liste 7) est prioritaire à l'unique tâche "Decapsuler" (listes 2, 3, 4 et 5) .
 
'''Nous avons enfin reçu le sujet 2015 pour la compétition 2015, il est disponible [https://drive.google.com/file/d/0B39jN82rDE6qSk11YXFuQVljTlE/view?usp=sharing ici]'''
 
*Modification à réaliser :
**la fonction de création de liste de tâches
**l'ordonnancement (en partie)
**calcul de ratio de chaque tâche

====Exécuteur de tâches====
L'éxécuteur de taches va recevoir des ordres de la part du générateur de taches . En fonction de ces ordres, il enverra des demandes d'exécution/d'informations aux autres noeuds. Il y a donc un seul générateur de taches et trois exécuteurs de taches ( on a trois robotinos ).
Voici les classes qui correspondent à chaque exécuteur de taches :
[[Fichier:shema1.png]]
*'''Machine''' est une classe abstraite qui servira à la création des quatre classes filles qui représenteront les quatre machines de la compétition.
** ''string type'' sera donc BaseStation, RingStation, CapStation ou DeliveryStation.
** ''Pose2D centreMachine'' est un point(x,y,theta) qui va correspondre au retour du noeud de localisation (Projet 36)
** ''Pose2D entreeMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour déposer un produit
** ''Pose2D sortieMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour prendre un produit
*'''BaseStation''' est une classe fille de la classe "Machine".
** ''int baseRouge'', ''int baseNoir'' et ''int baseArgent'' vont correspondre aux nombres de bases rouges, bases noires, base argentes respectivement.
*'''RingStation''' est une classe fille de la classe "Machine".
** ''int ringVert'', ''int ringJaune'', ''int ringBleu'' et ''ringOrange'' vont correspondre aux nombres de rings verts, rings jaunes, rings bleus et rings oranges respectivement.
*'''CapStation''' est une classe fille de la classe "Machine".
** ''int capNoir'' et ''int capGris'' vont correspondre aux nombres de caps noirs et caps gris respectivement.
** ''int stock[3]'' est un tableau qui va correspondre aux trois emplacements stockage de la capStation.
** 'Pose2D stockage'' est un point(x,y,theta) qui correspond à l'emplacement de la première zone de stockage.

===Semaine 8===
====Générateur de tâches====
*Création du service pour l'envoi des ordres pour l’exécuteur de tâches avec pour contenu:
**Numéro du robot
***1, 2 ou 3
**Ordre
***ChercherBase
***MettreCap
***ChercherCap
***MettreRing
***ChercherRing
***RamenerBaseRS
***Livrer
***Decapsuler
***Destocker
**Paramètre
***noir
***argent
***rouge
***orange
***jaune
***bleu
***vert
***gris
***DS
***stock
***aucun
**Id
***0, 1, 2, 3, 4, 5 ou 6
 
L'exécuteur de tâches du robot concerné doit envoyer en retour :
*un booléen qui indique si l'ordre est accepté ou non
*l'ordre pris en compte
*l'Id de retour
 
Création d'un nœud ROS pour le débogage à l'aide de ddd
 
Création d'un nœud ROS pour similer l'envoi et la réception des ordres
 
 
Création de la classe action qui range les informations contenues dans le topic envoyé par l'exécuteur de tâches 
Utilisation de la classe action dans la fonction principale pour la phase de production 
Test OK cependant le traitement des informations ne se fait pas suffisamment rapidement pour une utilisation pratique
 

====Exécuteur de tâches====
L'exécuteur de taches est un noeud qui recevra des ordres de la part du générateur de taches et qui, à son tour, va envoyer des ordres aux autres noeuds.

Avec ROS, on peut communiquer entre les différents noeuds de plusieurs façons. En voici deux qui sont principalement utilisés :
* Les Topics : qui sont souvent utilisés pour publier des valeurs de données en continues
* Les services : qui permettent d'envoyer un ordre à un noeud (REQUEST) et qui permettent de recevoir de bonne réception de l'ordre (RESPONSE)

Voici le schéma de communication entre les différents noeuds, en rouge on a les services et en bleu les topics :

[[Fichier:schema2.jpg]]

===Semaine 9===
 
====Exécuteur de tâches====
Après avoir discuter avec les autres membres de l'équipe, nous avons réalisé quelques modification au niveau des communications entre l'exécuteur de taches et les autres noeuds. En fait, les services permettent d'envoyer une requête au serveur correspondant et ensuite le client reçoit une réponse de bonne réception de la requête. Alors que les topics permettent d'envoyer, à une certaine fréquence, les valeurs de variables qui correspondent à ce topic. Ainsi, on remarque qu'on aurait besoin d'utiliser un "mélange" de ces deux moyens de communication. En Ros, cela existe : les actions .

Voici donc à nouveau le schéma de communication :

===Semaine 10===
 
===Semaine 11===
 
===Semaine 12===
 

== Fichiers Rendus ==

Fichier:Schema.001.jpg

2015-04-15T21:16:53Z

Shage-ch :

RoboCup 2015

2015-03-19T13:31:30Z

Shage-ch : /* Exécuteur de tâches */

__TOC__
 
[[Fichier:logoPyro_icone.png |center ]]
<center> Polytech RoboCup Team </center>

==Cahier des charges==
===Présentation générale du projet===

Lors de la compétition de l'Open German, prélude de la Robocup, il faudra mettre en place un système d'autonomisation de production à l'aide de Robotinos (robots mobiles de Festo ayant un système d'exploitation Linux). Comme dans toutes compétitions, le but est de gagner, par conséquent, il faudra faire en sorte de gagner un maximum de points.
C'est pourquoi il faut créer un manager à l'aide de ROS, c'est-à-dire un nœud ou ensemble de nœuds permettant de pouvoir recevoir les informations envoyées par les autres nœuds, de les traiter, tout cela afin de donner les ordres que doivent exécuter chaque Robotino. Ce manager devra également être capable d'optimiser le nombre de points à obtenir.

====Contexte====

La compétition de l'Open German se déroule en quatre phases spécifiques : phase de début-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des tâches spécifiques à remplir suivant les différentes phases. La RefereeBox est un système d'arbitrage auquel il est nécessaire d'envoyer périodiquement des données à tout moment du jeu et qui donne à chaque instant l'état du jeu ainsi que les produits demandés en priorité durant la phase de production.

====Objectif du projet====

*Assurer un maximum de points suivant les aléas du jeu (panne de machine, produits demandées, rupture de stock d'une matière première, …)
*Assurer la pérennité du projet (chaque année des candidats de Polytech Lille y participent)

====Description du projet====

Pour le projet, outre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes :
*Communication avec le nœud de la RefereeBox à tout moment du jeu
*Contrainte de robustesse (il ne faut qu'à un moment ou à un autre il n'y ait un blocage de tous les robots)
*Coopération entre les trois robots
 
[[Fichier:Interactions.png|vignette|left|upright=2|Interactions des nœuds avec le manager]]
 
Le manager devra interagir avec les différents nœuds suivants ayant chacun leurs rôles spécifiques :
*RefereeBox Comm : recevoir les données envoyées par la RefereeBox et envoyer des données suivant l'état du jeu à la RefereeBox
*Robots Comm : communiquer aux autres robots les informations concernant ce que chacun font
*Traitement des TAGs : lire les TAG
*Traitement des feux : lire l'état des colonnes de feu
*Pince de préhension : ouvrir et fermer la pince et renvoyer l'état de la pince
*Approche finale : s'adapter au banc de charge ou de décharge de produits
*Génération trajectoire : détermine une trajectoire pour aller au lieu (X,Y)
*Réalisation trajectoire : parcourir la trajectoire
*Localisation : savoir périodiquement (faible période) où se situe le robot
*Détection d'obstacle : détecter les obstacles fixes et mobiles
 

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

*Utilisation de trois robotinos
*Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce système travaille en utilisant des nœuds qui communiquent entre eux à l'aide de services (requête-réponse) et de topics (fichiers).
*Utilisation de différents langages : C++ ou Python (nœuds)
*Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS
 

===Etapes du projet===
*Prise en main de ROS et du C++
*Élaboration de l'algorithme du manager pour la phase d'exploration
*Élaboration de l'algorithme du manager pour la phase de production
**Coopération entre robots
**Répartition des tâches
*Codage du manager
*Tests et corrections
 

==Avancement du Projet==
===Semaine 1===
*Prise en main de ROS
*Réalisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials
*Réalisation de différents tutoriels C++
*Connaissance plus aiguë du sujet de l'Open German 2015
 
===Semaine 2===
*Réflexions autour de la structure du manager : deux nœuds
**Un nœud exécuteur de tâches
**Un nœud générateur de tâches
*Réflexions sur l'algorithme général du manager concernant la phase d'exploration
**Fonctionnement par zoning pour la répartition des tâches des trois robots
**Réflexion autour d'une alternative de répartition par distances les plus courtes entre machines
*Recherche de solutions pour la phase de production
**Documentation autour de la planification de tâches et la génération de tâche pour une équipe
**Recherche autour de la coopération et de l'allocation de rôles à des robots multi-tâches
*Organisation générale
**Structuration d'un échéancier numérique sous Asana
**Demande d'autorisation pour l'ouverture de la salle C002 auprès de M. Scrive
 

===Semaine 3===
Voilà un lien permettant d'accéder au sujet provisoire de la Robocup 2015 : [https://drive.google.com/file/d/0B39jN82rDE6qMG45cDN5Z0xiSVE/view?usp=sharing Sujet] 
*Réflexions au sujet des infos à communiquer au nœud AutresRobotsComm :
**Ce que le robotino fait
**Quelle machine le robotino est en train d'utiliser
[[Fichier:DataSWithRobotComm.jpg|center]]
 
*Réflexions au niveau de l'algorithme de la phase de production
**Proposition de le faire sous le principe de "Diviser pour mieux régner" (validé par M. Vincent Coelen)
***Diviser la tâche principale en sous-tâches, les sous-tâches en sous-sous-tâches et les sous-sous-tâches en sous-sous-sous-tâches élémentaires.
**Détermination des tâches à réaliser pour un exemple particulier
On souhaite produire, pendant une durée déterminée par la refBox, le produit suivant :
[[Fichier:ExempleProduitDemande.jpg|center]]
''Le produit est composé d’une base bleue, d’un ring rouge, d’un ring vert et d’un cap noir.''

'''Obtenir Base Bleue'''
->Aller à la Base Station
générateur trajectoire
exécuteur trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (dire à la Base Station quelle base est souhaitée et à quelle banc le robotino est)
approche finale
pince (prendre)

'''Obtenir ring rouge'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Obtenir ring vert'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
(Du coup la plus proche sera celle où on vient de faire le ring précédent)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Ring Station quelle base est souhaitée ( ici, la verte )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Finaliser produit'''
->Aller à une Cap Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Cap Station quelle cap est souhaité ( ici, le noir )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel banc de livraison)
approche finale
pince (prendre)
->Déposer à la Delivery Station
générateur de trajectoire (vers la Delivery Station)
exécuteur de trajectoire
approche finale
pince (déposer)
 
*Organisation générale :
**Création de la page Facebook de l'équipe PYRO Team
 

===Semaine 4===
*Écriture des sous-tâches à réaliser
**Pseudo-codes de certaines sous-tâches réalisées
*Recherche d'ordonnancement optimisé pour la fabrication du produit
**Recherche d'algorithmes
**Visualisation du problème d'ordonnancement concernant l'exemple précédent (base bleue, ring vert, ring rouge, cap noir)
 
Ici, on a pris en plus en hypothèse le fait que la Ring Station (RS1) est capable de mettre des rings rouges ou verts et que la RS2 est capable de de mettre des rings bleus et rouges. Afin de mieux appréhender le problème, nous nous sommes attachés à effectuer un tableau récapitulant les tâches à effectuer pour le produit exemple et à réaliser un graphe mettant en avant les contraintes de précédence de chaque tâche.
 

{| class="wikitable" style="text-align:center; width:80%;"

|-
|
! scope="col" | Tâches
! scope="col" | Ressources utilisées
! scope="col" | Contraintes de précédence
|-
! scope="row" | T0
| Ramener à CS base avec cap
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T1
| Décapsuler
| Cap Station 1 ou 2
| T0
|-
! scope="row" | T2
| Ramener base supplémentaires à RS
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T3
| Chercher base bleue
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T4
| Ramener à RS pour ring vert
| Robot 1, 2 ou 3
| T7
|-
! scope="row" | T5
| Ramener à RS pour ring rouge
| Robot 1, 2 ou 3
| T8
|-
! scope="row" | T6
| Ramener à CS pour cap
| Robot 1, 2 ou 3
| T9
|-
! scope="row" | T7
| Ramener Base
| Base Station
| T3
|-
! scope="row" | T8
| Ajouter ring vert
| Ring Station 1
| T4
|-
! scope="row" | T9
| Ajouter ring rouge
| Ring Station 1 ou 2
| T5 et T2
|-
! scope="row" | T10
| Ajouter cap
| Cap Station 1 ou 2
| T6 et T1
|-
! scope="row" | T11
| Traiter le produit fini
| Delivery Station
| T12
|-
! scope="row" | T12
| Ramener à DS
| Robot 1, 2 ou 3
| T10
|}
[[Fichier:TachesProduitExemple.png|center]]
<center>Graphe montrant l'ordre des tâches à réaliser</center>
 

===Semaine 5===
Durant cette semaine, nous avons réfléchi sur le choix de structures pour nos données :
* Une '''liste principale''' de tous les produits demandés par la RefBox à un instant t. Cette liste principale a les caractéristiques suivantes :
** Une '''Priorité''' sera calculée pour chaque produit avec les paramètres suivants :
*** Nombre de points que peut apporter la production d'un produit de A à Z.
*** Une estimation du temps de production d'un produit.
***La date limite de livraison du produit demandé
** Une tâche est élue si sa priorité est supérieure ou égale à celle des autres tâches.
** Quand la RefBox demande un produit, une cellule sera ajoutée dans cette liste. Et de même, quand un produit sera terminé, on le supprimera de cette liste.
* Chaque produit de la liste principale va contenir une '''liste de tâches''' correspondantes à la production de ce produit. Cette liste de tâches a les caractéristiques suivantes :
** Chaque cellule correspond à une tâche de la production d'un produit. Une tâche contient différents champs :
***Intitulé de la tâche (par exemple ajouter une base)
***Produit concernée (par exemple P3)
***Priorité de la tâche (par exemple 20)
***Temps restant estimé de production (par exemple 180s)
** A chaque fois qu'une tâche est réalisée, elle sera supprimée de la liste de tâches. Ce qui veut dire, qu'on va devoir calculé à nouveau la priorité de chaque tâche de la liste principale.
** Afin de respecter les contraintes de précédence, on considérera que la tâche en tête de la liste de tâches peut être élue. Par exemple, on ne peut pas ajouter un Ring si on n'a pas de base.
 
L'exemple suivant simule le cas où la RefBox a demandé deux fois le produit P3 et deux fois le produit P2.
*Le produit P3 est réalisable en cinq tâches.Ce produit mettra plus de temps à être fabriqué mais rapportera plus de points.
*Le produit P2 est réalisable en quatre tâches.
 
[[Fichier:listedelistes.png|center]]
<center>Structure utilisée pour ranger les tâches à réaliser</center>
 
Différentes remarques utiles :
*Avant de commencer à réaliser n'importe quel produit, il faudra au préalable vérifier si on a libérer un espace de stockage pour plusieurs raisons :
**Les Cap Stations ayant initialement aucun cap en stock, il faut les ramener de l'étagère qui en contient initialement car un produit est dit fini lorsqu'il a à son sommet un cap.
**L'étagère ayant été débarrassée d'un cap, cela permet d'avoir un espace de stockage afin de déposer des produits finis en attente de livraison ou des produits non finis dont on voudrait mettre en pause la production.
*Il sera peut être des fois plus avantageux d'abandonner temporairement la production d'un produit :
**Il vaut mieux faire en sorte de terminer un seul produit sur deux dans les temps plutôt qu'aucun car du fait de la parallélisation de la fabrication des produits, on peut être surchargé de travail.
**Un produit livré durant le laps de temps demandé rapportera plus de points non négligeables.
*Un tableau sera nécessaire afin de savoir ce qu'il y a les espaces de stockage avec les champs suivants :
**Type de produit
**Liste de tâches restantes pour la fabrication du produit (pour un produit fini cette liste est donc nulle)
**Date de début de livraison
**Date de fin de livraison
**Emplacement de l'espace de stockage
 

===Semaine 6===
*Différentes fonctions et actions en pseudo code pour le générateur de tâches
**Fonction qui retourne un booléen suivant si un produit est en stock ou non
**Fonction qui retourne un booléen suivant si on doit livrer le produit à présent ou non
**Fonction qui retourne un booléen suivant si on a déjà ou non mis le travail à faire dans la structure contenant les tâches à réaliser
**Fonction qui retourne le nombre de points que rapporte un produit passé en paramètre
**Action qui rajoute les nouveaux ordres de production dans la liste de listes de tâches
**Action qui calcule le ratio pour chaque tâche
**Action qui supprime les tâches vides (ie celles qui sont terminées)
*Début de l'écriture en pseudo code de la fonction principale
 
*Discussion avec M. Vincent Coelen concernant l'avancement du projet :
**Validation par M. Coelen Vincent des portions de pseudo code déjà écrites
**Discussion autour de la mise en place d'un arrêt immédiat des robots à tout moment du jeu
**Amélioration concernant la robustesse de l'algorithme si un robot n'est plus en état de fonctionnement
 
*Différentes remarques utiles :
**Branche concernant le manager créée sur le [https://github.com/PyroTeam/robocup-pkg/ git] de l'équipe
**Discussion avec d'autres membres de l'équipe sur les services et les topics à envoyer et à recevoir aux nœuds du manager
 
===Semaine 7===

====Générateur de tâches====
Début du codage C++ :
*Création de différentes classes :
**La classe Tache (tache.h et tache.cpp)
**La classe Stockage (stockage.h et stockage.cpp)
**La classe RefBoxComm (refboxcomm.h)
*Création de différentes fonctions :
**Dans tache.h et tache.cpp :
***point_par_produit : retourne le nombre de points que vaut un produit
***dans_les_temps : retourne un booléen indiquant s'il est temps de ramener le produit
**Dans listetaches.h et listetaches.cpp :
***creation_liste_taches_prod : retourne une liste de taches à partir d'un produit passé en paramètre
***creation_liste_taches_act : retourne une liste de taches à partir d'un produit et d'une action passés en paramètres
**Dans tableaustockage.h :
***produit_en_stock : retourne un booléen indiquant si au moins un produit est en stock
**Dans travail.h et travail.cpp :
***deja_dans_travail : retourne un booléen indiquant si un ordre de la RefBox a déjà été pris en compte dans la structure contenant les tâches à réaliser
***max_ratio : retourne l'objet Tache qui a le plus grand ratio dans la structure contenant les tâches à réaliser
***rajout_dans_travail : rajoute un nouvel ordre de la RefBox dans la structure contenant les tâches à réaliser
***calcul_ratio : calcule le ratio de chaque premier de liste de la structure contenant les tâches à réaliser
 
Les codes sont disponibles sur le [https://github.com/PyroTeam/robocup-pkg/tree/feature/manager/generateur_taches git]
 
Des tests ont été réalisés afin de valider les fonctions crées en particulier les fonctions contenues dans travail.h et travail.cpp
 
Voici un petit aperçu de la console :
 
[[Fichier:Capture terminal gen taches 3.png|800px]]
 
Ainsi, les quatres fonctions fonctionnent parfaitement :
*deja_dans_travail indique bien que l'ordre de la RefBox n'a pas encore pris en compte
*max_ratio retourne bien la tâche dont le ratio est maximum
*rajout_dans_travail rajoute en fin de liste la liste de tâches pour la première création d'un produit P0 car un cap est disponible , puis il concatène une liste contenant en tête la tâche "Decapsuler" avec la liste de tâches pour la seconde création d'un produit P0. En effet, la RefBox a demandé deux fois le produit P0 et on ne peut créer un produit tant qu'un cap n'est pas disponible.
*calcul_ratio calcule le ratio de chaque première tâche en fonction du nombre de points et du temps, de plus, si c'est le bon moment pour déstocker un produit il passe cette tâche "Destocker" en priorité (liste 6), en outre, la création d'un produit (liste 1 et liste 7) est prioritaire à l'unique tâche "Decapsuler" (listes 2, 3, 4 et 5) .
 
'''Nous avons enfin reçu le sujet 2015 pour la compétition 2015, il est disponible [https://drive.google.com/file/d/0B39jN82rDE6qSk11YXFuQVljTlE/view?usp=sharing ici]'''
 
*Modification à réaliser :
**la fonction de création de liste de tâches
**l'ordonnancement (en partie)
**calcul de ratio de chaque tâche

====Exécuteur de tâches====
L'éxécuteur de taches va recevoir des ordres de la part du générateur de taches . En fonction de ces ordres, il enverra des demandes d'exécution/d'informations aux autres noeuds. Il y a donc un seul générateur de taches et trois exécuteurs de taches ( on a trois robotinos ).
Voici les classes qui correspondent à chaque exécuteur de taches :
[[Fichier:shema1.png]]
*'''Machine''' est une classe abstraite qui servira à la création des quatre classes filles qui représenteront les quatre machines de la compétition.
** ''string type'' sera donc BaseStation, RingStation, CapStation ou DeliveryStation.
** ''Pose2D centreMachine'' est un point(x,y,theta) qui va correspondre au retour du noeud de localisation (Projet 36)
** ''Pose2D entreeMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour déposer un produit
** ''Pose2D sortieMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour prendre un produit
*'''BaseStation''' est une classe fille de la classe "Machine".
** ''int baseRouge'', ''int baseNoir'' et ''int baseArgent'' vont correspondre aux nombres de bases rouges, bases noires, base argentes respectivement.
*'''RingStation''' est une classe fille de la classe "Machine".
** ''int ringVert'', ''int ringJaune'', ''int ringBleu'' et ''ringOrange'' vont correspondre aux nombres de rings verts, rings jaunes, rings bleus et rings oranges respectivement.
*'''CapStation''' est une classe fille de la classe "Machine".
** ''int capNoir'' et ''int capGris'' vont correspondre aux nombres de caps noirs et caps gris respectivement.
** ''int stock[3]'' est un tableau qui va correspondre aux trois emplacements stockage de la capStation.
** 'Pose2D stockage'' est un point(x,y,theta) qui correspond à l'emplacement de la première zone de stockage.

===Semaine 8===
====Générateur de tâches====
*Création du service pour l'envoi des ordres pour l’exécuteur de tâches avec pour contenu:
**Numéro du robot
***1, 2 ou 3
**Ordre
***ChercherBase
***MettreCap
***ChercherCap
***MettreRing
***ChercherRing
***RamenerBaseRS
***Livrer
***Decapsuler
***Destocker
**Paramètre
***noir
***argent
***rouge
***orange
***jaune
***bleu
***vert
***gris
***DS
***stock
***aucun
**Id
***0, 1, 2, 3, 4, 5 ou 6
 
L'exécuteur de tâches du robot concerné doit envoyer en retour :
*un booléen qui indique si l'ordre est accepté ou non
*l'ordre pris en compte
*l'Id de retour
 
Création d'un nœud ROS pour le débogage à l'aide de ddd
 
Création d'un nœud ROS pour similer l'envoi et la réception des ordres
 
====Exécuteur de tâches====
L'exécuteur de taches est un noeud qui recevra des ordres de la part du générateur de taches et qui, à son tour, va envoyer des ordres aux autres noeuds.

Avec ROS, on peut communiquer entre les différents noeuds de plusieurs façons. En voici deux qui sont principalement utilisés :
* Les Topics : qui sont souvent utilisés pour publier des valeurs de données en continues
* Les services : qui permettent d'envoyer un ordre à un noeud (REQUEST) et qui permettent de recevoir de bonne réception de l'ordre (RESPONSE)

Voici le schéma de communication entre les différents noeuds, en rouge on a les services et en bleu les topics :

[[Fichier:schema2.jpg]]

===Semaine 9===
 
===Semaine 10===
 
===Semaine 11===
 
===Semaine 12===
 

== Fichiers Rendus ==

RoboCup 2015

2015-03-19T13:11:24Z

Shage-ch : /* Exécuteur de tâches */

__TOC__
 
[[Fichier:logoPyro_icone.png |center ]]
<center> Polytech RoboCup Team </center>

==Cahier des charges==
===Présentation générale du projet===

Lors de la compétition de l'Open German, prélude de la Robocup, il faudra mettre en place un système d'autonomisation de production à l'aide de Robotinos (robots mobiles de Festo ayant un système d'exploitation Linux). Comme dans toutes compétitions, le but est de gagner, par conséquent, il faudra faire en sorte de gagner un maximum de points.
C'est pourquoi il faut créer un manager à l'aide de ROS, c'est-à-dire un nœud ou ensemble de nœuds permettant de pouvoir recevoir les informations envoyées par les autres nœuds, de les traiter, tout cela afin de donner les ordres que doivent exécuter chaque Robotino. Ce manager devra également être capable d'optimiser le nombre de points à obtenir.

====Contexte====

La compétition de l'Open German se déroule en quatre phases spécifiques : phase de début-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des tâches spécifiques à remplir suivant les différentes phases. La RefereeBox est un système d'arbitrage auquel il est nécessaire d'envoyer périodiquement des données à tout moment du jeu et qui donne à chaque instant l'état du jeu ainsi que les produits demandés en priorité durant la phase de production.

====Objectif du projet====

*Assurer un maximum de points suivant les aléas du jeu (panne de machine, produits demandées, rupture de stock d'une matière première, …)
*Assurer la pérennité du projet (chaque année des candidats de Polytech Lille y participent)

====Description du projet====

Pour le projet, outre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes :
*Communication avec le nœud de la RefereeBox à tout moment du jeu
*Contrainte de robustesse (il ne faut qu'à un moment ou à un autre il n'y ait un blocage de tous les robots)
*Coopération entre les trois robots
 
[[Fichier:Interactions.png|vignette|left|upright=2|Interactions des nœuds avec le manager]]
 
Le manager devra interagir avec les différents nœuds suivants ayant chacun leurs rôles spécifiques :
*RefereeBox Comm : recevoir les données envoyées par la RefereeBox et envoyer des données suivant l'état du jeu à la RefereeBox
*Robots Comm : communiquer aux autres robots les informations concernant ce que chacun font
*Traitement des TAGs : lire les TAG
*Traitement des feux : lire l'état des colonnes de feu
*Pince de préhension : ouvrir et fermer la pince et renvoyer l'état de la pince
*Approche finale : s'adapter au banc de charge ou de décharge de produits
*Génération trajectoire : détermine une trajectoire pour aller au lieu (X,Y)
*Réalisation trajectoire : parcourir la trajectoire
*Localisation : savoir périodiquement (faible période) où se situe le robot
*Détection d'obstacle : détecter les obstacles fixes et mobiles
 

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

*Utilisation de trois robotinos
*Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce système travaille en utilisant des nœuds qui communiquent entre eux à l'aide de services (requête-réponse) et de topics (fichiers).
*Utilisation de différents langages : C++ ou Python (nœuds)
*Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS
 

===Etapes du projet===
*Prise en main de ROS et du C++
*Élaboration de l'algorithme du manager pour la phase d'exploration
*Élaboration de l'algorithme du manager pour la phase de production
**Coopération entre robots
**Répartition des tâches
*Codage du manager
*Tests et corrections
 

==Avancement du Projet==
===Semaine 1===
*Prise en main de ROS
*Réalisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials
*Réalisation de différents tutoriels C++
*Connaissance plus aiguë du sujet de l'Open German 2015
 
===Semaine 2===
*Réflexions autour de la structure du manager : deux nœuds
**Un nœud exécuteur de tâches
**Un nœud générateur de tâches
*Réflexions sur l'algorithme général du manager concernant la phase d'exploration
**Fonctionnement par zoning pour la répartition des tâches des trois robots
**Réflexion autour d'une alternative de répartition par distances les plus courtes entre machines
*Recherche de solutions pour la phase de production
**Documentation autour de la planification de tâches et la génération de tâche pour une équipe
**Recherche autour de la coopération et de l'allocation de rôles à des robots multi-tâches
*Organisation générale
**Structuration d'un échéancier numérique sous Asana
**Demande d'autorisation pour l'ouverture de la salle C002 auprès de M. Scrive
 

===Semaine 3===
Voilà un lien permettant d'accéder au sujet provisoire de la Robocup 2015 : [https://drive.google.com/file/d/0B39jN82rDE6qMG45cDN5Z0xiSVE/view?usp=sharing Sujet] 
*Réflexions au sujet des infos à communiquer au nœud AutresRobotsComm :
**Ce que le robotino fait
**Quelle machine le robotino est en train d'utiliser
[[Fichier:DataSWithRobotComm.jpg|center]]
 
*Réflexions au niveau de l'algorithme de la phase de production
**Proposition de le faire sous le principe de "Diviser pour mieux régner" (validé par M. Vincent Coelen)
***Diviser la tâche principale en sous-tâches, les sous-tâches en sous-sous-tâches et les sous-sous-tâches en sous-sous-sous-tâches élémentaires.
**Détermination des tâches à réaliser pour un exemple particulier
On souhaite produire, pendant une durée déterminée par la refBox, le produit suivant :
[[Fichier:ExempleProduitDemande.jpg|center]]
''Le produit est composé d’une base bleue, d’un ring rouge, d’un ring vert et d’un cap noir.''

'''Obtenir Base Bleue'''
->Aller à la Base Station
générateur trajectoire
exécuteur trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (dire à la Base Station quelle base est souhaitée et à quelle banc le robotino est)
approche finale
pince (prendre)

'''Obtenir ring rouge'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Obtenir ring vert'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
(Du coup la plus proche sera celle où on vient de faire le ring précédent)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Ring Station quelle base est souhaitée ( ici, la verte )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Finaliser produit'''
->Aller à une Cap Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Cap Station quelle cap est souhaité ( ici, le noir )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel banc de livraison)
approche finale
pince (prendre)
->Déposer à la Delivery Station
générateur de trajectoire (vers la Delivery Station)
exécuteur de trajectoire
approche finale
pince (déposer)
 
*Organisation générale :
**Création de la page Facebook de l'équipe PYRO Team
 

===Semaine 4===
*Écriture des sous-tâches à réaliser
**Pseudo-codes de certaines sous-tâches réalisées
*Recherche d'ordonnancement optimisé pour la fabrication du produit
**Recherche d'algorithmes
**Visualisation du problème d'ordonnancement concernant l'exemple précédent (base bleue, ring vert, ring rouge, cap noir)
 
Ici, on a pris en plus en hypothèse le fait que la Ring Station (RS1) est capable de mettre des rings rouges ou verts et que la RS2 est capable de de mettre des rings bleus et rouges. Afin de mieux appréhender le problème, nous nous sommes attachés à effectuer un tableau récapitulant les tâches à effectuer pour le produit exemple et à réaliser un graphe mettant en avant les contraintes de précédence de chaque tâche.
 

{| class="wikitable" style="text-align:center; width:80%;"

|-
|
! scope="col" | Tâches
! scope="col" | Ressources utilisées
! scope="col" | Contraintes de précédence
|-
! scope="row" | T0
| Ramener à CS base avec cap
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T1
| Décapsuler
| Cap Station 1 ou 2
| T0
|-
! scope="row" | T2
| Ramener base supplémentaires à RS
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T3
| Chercher base bleue
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T4
| Ramener à RS pour ring vert
| Robot 1, 2 ou 3
| T7
|-
! scope="row" | T5
| Ramener à RS pour ring rouge
| Robot 1, 2 ou 3
| T8
|-
! scope="row" | T6
| Ramener à CS pour cap
| Robot 1, 2 ou 3
| T9
|-
! scope="row" | T7
| Ramener Base
| Base Station
| T3
|-
! scope="row" | T8
| Ajouter ring vert
| Ring Station 1
| T4
|-
! scope="row" | T9
| Ajouter ring rouge
| Ring Station 1 ou 2
| T5 et T2
|-
! scope="row" | T10
| Ajouter cap
| Cap Station 1 ou 2
| T6 et T1
|-
! scope="row" | T11
| Traiter le produit fini
| Delivery Station
| T12
|-
! scope="row" | T12
| Ramener à DS
| Robot 1, 2 ou 3
| T10
|}
[[Fichier:TachesProduitExemple.png|center]]
<center>Graphe montrant l'ordre des tâches à réaliser</center>
 

===Semaine 5===
Durant cette semaine, nous avons réfléchi sur le choix de structures pour nos données :
* Une '''liste principale''' de tous les produits demandés par la RefBox à un instant t. Cette liste principale a les caractéristiques suivantes :
** Une '''Priorité''' sera calculée pour chaque produit avec les paramètres suivants :
*** Nombre de points que peut apporter la production d'un produit de A à Z.
*** Une estimation du temps de production d'un produit.
***La date limite de livraison du produit demandé
** Une tâche est élue si sa priorité est supérieure ou égale à celle des autres tâches.
** Quand la RefBox demande un produit, une cellule sera ajoutée dans cette liste. Et de même, quand un produit sera terminé, on le supprimera de cette liste.
* Chaque produit de la liste principale va contenir une '''liste de tâches''' correspondantes à la production de ce produit. Cette liste de tâches a les caractéristiques suivantes :
** Chaque cellule correspond à une tâche de la production d'un produit. Une tâche contient différents champs :
***Intitulé de la tâche (par exemple ajouter une base)
***Produit concernée (par exemple P3)
***Priorité de la tâche (par exemple 20)
***Temps restant estimé de production (par exemple 180s)
** A chaque fois qu'une tâche est réalisée, elle sera supprimée de la liste de tâches. Ce qui veut dire, qu'on va devoir calculé à nouveau la priorité de chaque tâche de la liste principale.
** Afin de respecter les contraintes de précédence, on considérera que la tâche en tête de la liste de tâches peut être élue. Par exemple, on ne peut pas ajouter un Ring si on n'a pas de base.
 
L'exemple suivant simule le cas où la RefBox a demandé deux fois le produit P3 et deux fois le produit P2.
*Le produit P3 est réalisable en cinq tâches.Ce produit mettra plus de temps à être fabriqué mais rapportera plus de points.
*Le produit P2 est réalisable en quatre tâches.
 
[[Fichier:listedelistes.png|center]]
<center>Structure utilisée pour ranger les tâches à réaliser</center>
 
Différentes remarques utiles :
*Avant de commencer à réaliser n'importe quel produit, il faudra au préalable vérifier si on a libérer un espace de stockage pour plusieurs raisons :
**Les Cap Stations ayant initialement aucun cap en stock, il faut les ramener de l'étagère qui en contient initialement car un produit est dit fini lorsqu'il a à son sommet un cap.
**L'étagère ayant été débarrassée d'un cap, cela permet d'avoir un espace de stockage afin de déposer des produits finis en attente de livraison ou des produits non finis dont on voudrait mettre en pause la production.
*Il sera peut être des fois plus avantageux d'abandonner temporairement la production d'un produit :
**Il vaut mieux faire en sorte de terminer un seul produit sur deux dans les temps plutôt qu'aucun car du fait de la parallélisation de la fabrication des produits, on peut être surchargé de travail.
**Un produit livré durant le laps de temps demandé rapportera plus de points non négligeables.
*Un tableau sera nécessaire afin de savoir ce qu'il y a les espaces de stockage avec les champs suivants :
**Type de produit
**Liste de tâches restantes pour la fabrication du produit (pour un produit fini cette liste est donc nulle)
**Date de début de livraison
**Date de fin de livraison
**Emplacement de l'espace de stockage
 

===Semaine 6===
*Différentes fonctions et actions en pseudo code pour le générateur de tâches
**Fonction qui retourne un booléen suivant si un produit est en stock ou non
**Fonction qui retourne un booléen suivant si on doit livrer le produit à présent ou non
**Fonction qui retourne un booléen suivant si on a déjà ou non mis le travail à faire dans la structure contenant les tâches à réaliser
**Fonction qui retourne le nombre de points que rapporte un produit passé en paramètre
**Action qui rajoute les nouveaux ordres de production dans la liste de listes de tâches
**Action qui calcule le ratio pour chaque tâche
**Action qui supprime les tâches vides (ie celles qui sont terminées)
*Début de l'écriture en pseudo code de la fonction principale
 
*Discussion avec M. Vincent Coelen concernant l'avancement du projet :
**Validation par M. Coelen Vincent des portions de pseudo code déjà écrites
**Discussion autour de la mise en place d'un arrêt immédiat des robots à tout moment du jeu
**Amélioration concernant la robustesse de l'algorithme si un robot n'est plus en état de fonctionnement
 
*Différentes remarques utiles :
**Branche concernant le manager créée sur le [https://github.com/PyroTeam/robocup-pkg/ git] de l'équipe
**Discussion avec d'autres membres de l'équipe sur les services et les topics à envoyer et à recevoir aux nœuds du manager
 
===Semaine 7===

====Générateur de tâches====
Début du codage C++ :
*Création de différentes classes :
**La classe Tache (tache.h et tache.cpp)
**La classe Stockage (stockage.h et stockage.cpp)
**La classe RefBoxComm (refboxcomm.h)
*Création de différentes fonctions :
**Dans tache.h et tache.cpp :
***point_par_produit : retourne le nombre de points que vaut un produit
***dans_les_temps : retourne un booléen indiquant s'il est temps de ramener le produit
**Dans listetaches.h et listetaches.cpp :
***creation_liste_taches_prod : retourne une liste de taches à partir d'un produit passé en paramètre
***creation_liste_taches_act : retourne une liste de taches à partir d'un produit et d'une action passés en paramètres
**Dans tableaustockage.h :
***produit_en_stock : retourne un booléen indiquant si au moins un produit est en stock
**Dans travail.h et travail.cpp :
***deja_dans_travail : retourne un booléen indiquant si un ordre de la RefBox a déjà été pris en compte dans la structure contenant les tâches à réaliser
***max_ratio : retourne l'objet Tache qui a le plus grand ratio dans la structure contenant les tâches à réaliser
***rajout_dans_travail : rajoute un nouvel ordre de la RefBox dans la structure contenant les tâches à réaliser
***calcul_ratio : calcule le ratio de chaque premier de liste de la structure contenant les tâches à réaliser
 
Les codes sont disponibles sur le [https://github.com/PyroTeam/robocup-pkg/tree/feature/manager/generateur_taches git]
 
Des tests ont été réalisés afin de valider les fonctions crées en particulier les fonctions contenues dans travail.h et travail.cpp
 
Voici un petit aperçu de la console :
 
[[Fichier:Capture terminal gen taches 3.png|800px]]
 
Ainsi, les quatres fonctions fonctionnent parfaitement :
*deja_dans_travail indique bien que l'ordre de la RefBox n'a pas encore pris en compte
*max_ratio retourne bien la tâche dont le ratio est maximum
*rajout_dans_travail rajoute en fin de liste la liste de tâches pour la première création d'un produit P0 car un cap est disponible , puis il concatène une liste contenant en tête la tâche "Decapsuler" avec la liste de tâches pour la seconde création d'un produit P0. En effet, la RefBox a demandé deux fois le produit P0 et on ne peut créer un produit tant qu'un cap n'est pas disponible.
*calcul_ratio calcule le ratio de chaque première tâche en fonction du nombre de points et du temps, de plus, si c'est le bon moment pour déstocker un produit il passe cette tâche "Destocker" en priorité (liste 6), en outre, la création d'un produit (liste 1 et liste 7) est prioritaire à l'unique tâche "Decapsuler" (listes 2, 3, 4 et 5) .
 
'''Nous avons enfin reçu le sujet 2015 pour la compétition 2015, il est disponible [https://drive.google.com/file/d/0B39jN82rDE6qSk11YXFuQVljTlE/view?usp=sharing ici]'''
 
*Modification à réaliser :
**la fonction de création de liste de tâches
**l'ordonnancement (en partie)
**calcul de ratio de chaque tâche

====Exécuteur de tâches====
L'éxécuteur de taches va recevoir des ordres de la part du générateur de taches . En fonction de ces ordres, il enverra des demandes d'exécution/d'informations aux autres noeuds. Il y a donc un seul générateur de taches et trois exécuteurs de taches ( on a trois robotinos ).
Voici les classes qui correspondent à chaque exécuteur de taches :
[[Fichier:shema1.png]]
*'''Machine''' est une classe abstraite qui servira à la création des quatre classes filles qui représenteront les quatre machines de la compétition.
** ''string type'' sera donc BaseStation, RingStation, CapStation ou DeliveryStation.
** ''Pose2D centreMachine'' est un point(x,y,theta) qui va correspondre au retour du noeud de localisation (Projet 36)
** ''Pose2D entreeMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour déposer un produit
** ''Pose2D sortieMachine'' est un point(x,y,theta) qui sera calculé afin de pouvoir déterminer l'emplacement exacte du convoyeur pour prendre un produit
*'''BaseStation''' est une classe fille de la classe "Machine".
** ''int baseRouge'', ''int baseNoir'' et ''int baseArgent'' vont correspondre aux nombres de bases rouges, bases noires, base argentes respectivement.
*'''RingStation''' est une classe fille de la classe "Machine".
** ''int ringVert'', ''int ringJaune'', ''int ringBleu'' et ''ringOrange'' vont correspondre aux nombres de rings verts, rings jaunes, rings bleus et rings oranges respectivement.
*'''CapStation''' est une classe fille de la classe "Machine".
** ''int capNoir'' et ''int capGris'' vont correspondre aux nombres de caps noirs et caps gris respectivement.
** ''int stock[3]'' est un tableau qui va correspondre aux trois emplacements stockage de la capStation.
** 'Pose2D stockage'' est un point(x,y,theta) qui correspond à l'emplacement de la première zone de stockage.

===Semaine 8===
====Générateur de tâches====
*Création du service pour l'envoi des ordres pour l’exécuteur de tâches avec pour contenu:
**Numéro du robot
***1, 2 ou 3
**Ordre
***ChercherBase
***MettreCap
***ChercherCap
***MettreRing
***ChercherRing
***RamenerBaseRS
***Livrer
***Decapsuler
***Destocker
**Paramètre
***noir
***argent
***rouge
***orange
***jaune
***bleu
***vert
***gris
***DS
***stock
***aucun
**Id
***0, 1, 2, 3, 4, 5 ou 6
 
L'exécuteur de tâches du robot concerné doit envoyer en retour :
*un booléen qui indique si l'ordre est accepté ou non
*l'ordre pris en compte
*l'Id de retour
 
Création d'un nœud ROS pour le débogage à l'aide de ddd
 
Création d'un nœud ROS pour similer l'envoi et la réception des ordres
 
====Exécuteur de tâches====
L'exécuteur de taches est un noeud qui recevra des ordres de la part du générateur de taches et qui, à son tour, va envoyer des ordres aux autres noeuds.

Voici le schéma de communication entre les différents noeuds :

[[Fichier:schema2.jpg]]

===Semaine 9===
 
===Semaine 10===
 
===Semaine 11===
 
===Semaine 12===
 

== Fichiers Rendus ==

RoboCup 2015

2015-03-19T12:42:48Z

Shage-ch : /* Exécuteur de tâches */

__TOC__
 
[[Fichier:logoPyro_icone.png |center ]]
<center> Polytech RoboCup Team </center>

==Cahier des charges==
===Présentation générale du projet===

Lors de la compétition de l'Open German, prélude de la Robocup, il faudra mettre en place un système d'autonomisation de production à l'aide de Robotinos (robots mobiles de Festo ayant un système d'exploitation Linux). Comme dans toutes compétitions, le but est de gagner, par conséquent, il faudra faire en sorte de gagner un maximum de points.
C'est pourquoi il faut créer un manager à l'aide de ROS, c'est-à-dire un nœud ou ensemble de nœuds permettant de pouvoir recevoir les informations envoyées par les autres nœuds, de les traiter, tout cela afin de donner les ordres que doivent exécuter chaque Robotino. Ce manager devra également être capable d'optimiser le nombre de points à obtenir.

====Contexte====

La compétition de l'Open German se déroule en quatre phases spécifiques : phase de début-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des tâches spécifiques à remplir suivant les différentes phases. La RefereeBox est un système d'arbitrage auquel il est nécessaire d'envoyer périodiquement des données à tout moment du jeu et qui donne à chaque instant l'état du jeu ainsi que les produits demandés en priorité durant la phase de production.

====Objectif du projet====

*Assurer un maximum de points suivant les aléas du jeu (panne de machine, produits demandées, rupture de stock d'une matière première, …)
*Assurer la pérennité du projet (chaque année des candidats de Polytech Lille y participent)

====Description du projet====

Pour le projet, outre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes :
*Communication avec le nœud de la RefereeBox à tout moment du jeu
*Contrainte de robustesse (il ne faut qu'à un moment ou à un autre il n'y ait un blocage de tous les robots)
*Coopération entre les trois robots
 
[[Fichier:Interactions.png|vignette|left|upright=2|Interactions des nœuds avec le manager]]
 
Le manager devra interagir avec les différents nœuds suivants ayant chacun leurs rôles spécifiques :
*RefereeBox Comm : recevoir les données envoyées par la RefereeBox et envoyer des données suivant l'état du jeu à la RefereeBox
*Robots Comm : communiquer aux autres robots les informations concernant ce que chacun font
*Traitement des TAGs : lire les TAG
*Traitement des feux : lire l'état des colonnes de feu
*Pince de préhension : ouvrir et fermer la pince et renvoyer l'état de la pince
*Approche finale : s'adapter au banc de charge ou de décharge de produits
*Génération trajectoire : détermine une trajectoire pour aller au lieu (X,Y)
*Réalisation trajectoire : parcourir la trajectoire
*Localisation : savoir périodiquement (faible période) où se situe le robot
*Détection d'obstacle : détecter les obstacles fixes et mobiles
 

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

*Utilisation de trois robotinos
*Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce système travaille en utilisant des nœuds qui communiquent entre eux à l'aide de services (requête-réponse) et de topics (fichiers).
*Utilisation de différents langages : C++ ou Python (nœuds)
*Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS
 

===Etapes du projet===
*Prise en main de ROS et du C++
*Élaboration de l'algorithme du manager pour la phase d'exploration
*Élaboration de l'algorithme du manager pour la phase de production
**Coopération entre robots
**Répartition des tâches
*Codage du manager
*Tests et corrections
 

==Avancement du Projet==
===Semaine 1===
*Prise en main de ROS
*Réalisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials
*Réalisation de différents tutoriels C++
*Connaissance plus aiguë du sujet de l'Open German 2015
 
===Semaine 2===
*Réflexions autour de la structure du manager : deux nœuds
**Un nœud exécuteur de tâches
**Un nœud générateur de tâches
*Réflexions sur l'algorithme général du manager concernant la phase d'exploration
**Fonctionnement par zoning pour la répartition des tâches des trois robots
**Réflexion autour d'une alternative de répartition par distances les plus courtes entre machines
*Recherche de solutions pour la phase de production
**Documentation autour de la planification de tâches et la génération de tâche pour une équipe
**Recherche autour de la coopération et de l'allocation de rôles à des robots multi-tâches
*Organisation générale
**Structuration d'un échéancier numérique sous Asana
**Demande d'autorisation pour l'ouverture de la salle C002 auprès de M. Scrive
 

===Semaine 3===
Voilà un lien permettant d'accéder au sujet provisoire de la Robocup 2015 : [https://drive.google.com/file/d/0B39jN82rDE6qMG45cDN5Z0xiSVE/view?usp=sharing Sujet] 
*Réflexions au sujet des infos à communiquer au nœud AutresRobotsComm :
**Ce que le robotino fait
**Quelle machine le robotino est en train d'utiliser
[[Fichier:DataSWithRobotComm.jpg|center]]
 
*Réflexions au niveau de l'algorithme de la phase de production
**Proposition de le faire sous le principe de "Diviser pour mieux régner" (validé par M. Vincent Coelen)
***Diviser la tâche principale en sous-tâches, les sous-tâches en sous-sous-tâches et les sous-sous-tâches en sous-sous-sous-tâches élémentaires.
**Détermination des tâches à réaliser pour un exemple particulier
On souhaite produire, pendant une durée déterminée par la refBox, le produit suivant :
[[Fichier:ExempleProduitDemande.jpg|center]]
''Le produit est composé d’une base bleue, d’un ring rouge, d’un ring vert et d’un cap noir.''

'''Obtenir Base Bleue'''
->Aller à la Base Station
générateur trajectoire
exécuteur trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (dire à la Base Station quelle base est souhaitée et à quelle banc le robotino est)
approche finale
pince (prendre)

'''Obtenir ring rouge'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Obtenir ring vert'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
(Du coup la plus proche sera celle où on vient de faire le ring précédent)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Ring Station quelle base est souhaitée ( ici, la verte )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Finaliser produit'''
->Aller à une Cap Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Cap Station quelle cap est souhaité ( ici, le noir )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel banc de livraison)
approche finale
pince (prendre)
->Déposer à la Delivery Station
générateur de trajectoire (vers la Delivery Station)
exécuteur de trajectoire
approche finale
pince (déposer)
 
*Organisation générale :
**Création de la page Facebook de l'équipe PYRO Team
 

===Semaine 4===
*Écriture des sous-tâches à réaliser
**Pseudo-codes de certaines sous-tâches réalisées
*Recherche d'ordonnancement optimisé pour la fabrication du produit
**Recherche d'algorithmes
**Visualisation du problème d'ordonnancement concernant l'exemple précédent (base bleue, ring vert, ring rouge, cap noir)
 
Ici, on a pris en plus en hypothèse le fait que la Ring Station (RS1) est capable de mettre des rings rouges ou verts et que la RS2 est capable de de mettre des rings bleus et rouges. Afin de mieux appréhender le problème, nous nous sommes attachés à effectuer un tableau récapitulant les tâches à effectuer pour le produit exemple et à réaliser un graphe mettant en avant les contraintes de précédence de chaque tâche.
 

{| class="wikitable" style="text-align:center; width:80%;"

|-
|
! scope="col" | Tâches
! scope="col" | Ressources utilisées
! scope="col" | Contraintes de précédence
|-
! scope="row" | T0
| Ramener à CS base avec cap
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T1
| Décapsuler
| Cap Station 1 ou 2
| T0
|-
! scope="row" | T2
| Ramener base supplémentaires à RS
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T3
| Chercher base bleue
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T4
| Ramener à RS pour ring vert
| Robot 1, 2 ou 3
| T7
|-
! scope="row" | T5
| Ramener à RS pour ring rouge
| Robot 1, 2 ou 3
| T8
|-
! scope="row" | T6
| Ramener à CS pour cap
| Robot 1, 2 ou 3
| T9
|-
! scope="row" | T7
| Ramener Base
| Base Station
| T3
|-
! scope="row" | T8
| Ajouter ring vert
| Ring Station 1
| T4
|-
! scope="row" | T9
| Ajouter ring rouge
| Ring Station 1 ou 2
| T5 et T2
|-
! scope="row" | T10
| Ajouter cap
| Cap Station 1 ou 2
| T6 et T1
|-
! scope="row" | T11
| Traiter le produit fini
| Delivery Station
| T12
|-
! scope="row" | T12
| Ramener à DS
| Robot 1, 2 ou 3
| T10
|}
[[Fichier:TachesProduitExemple.png|center]]
<center>Graphe montrant l'ordre des tâches à réaliser</center>
 

===Semaine 5===
Durant cette semaine, nous avons réfléchi sur le choix de structures pour nos données :
* Une '''liste principale''' de tous les produits demandés par la RefBox à un instant t. Cette liste principale a les caractéristiques suivantes :
** Une '''Priorité''' sera calculée pour chaque produit avec les paramètres suivants :
*** Nombre de points que peut apporter la production d'un produit de A à Z.
*** Une estimation du temps de production d'un produit.
***La date limite de livraison du produit demandé
** Une tâche est élue si sa priorité est supérieure ou égale à celle des autres tâches.
** Quand la RefBox demande un produit, une cellule sera ajoutée dans cette liste. Et de même, quand un produit sera terminé, on le supprimera de cette liste.
* Chaque produit de la liste principale va contenir une '''liste de tâches''' correspondantes à la production de ce produit. Cette liste de tâches a les caractéristiques suivantes :
** Chaque cellule correspond à une tâche de la production d'un produit. Une tâche contient différents champs :
***Intitulé de la tâche (par exemple ajouter une base)
***Produit concernée (par exemple P3)
***Priorité de la tâche (par exemple 20)
***Temps restant estimé de production (par exemple 180s)
** A chaque fois qu'une tâche est réalisée, elle sera supprimée de la liste de tâches. Ce qui veut dire, qu'on va devoir calculé à nouveau la priorité de chaque tâche de la liste principale.
** Afin de respecter les contraintes de précédence, on considérera que la tâche en tête de la liste de tâches peut être élue. Par exemple, on ne peut pas ajouter un Ring si on n'a pas de base.
 
L'exemple suivant simule le cas où la RefBox a demandé deux fois le produit P3 et deux fois le produit P2.
*Le produit P3 est réalisable en cinq tâches.Ce produit mettra plus de temps à être fabriqué mais rapportera plus de points.
*Le produit P2 est réalisable en quatre tâches.
 
[[Fichier:listedelistes.png|center]]
<center>Structure utilisée pour ranger les tâches à réaliser</center>
 
Différentes remarques utiles :
*Avant de commencer à réaliser n'importe quel produit, il faudra au préalable vérifier si on a libérer un espace de stockage pour plusieurs raisons :
**Les Cap Stations ayant initialement aucun cap en stock, il faut les ramener de l'étagère qui en contient initialement car un produit est dit fini lorsqu'il a à son sommet un cap.
**L'étagère ayant été débarrassée d'un cap, cela permet d'avoir un espace de stockage afin de déposer des produits finis en attente de livraison ou des produits non finis dont on voudrait mettre en pause la production.
*Il sera peut être des fois plus avantageux d'abandonner temporairement la production d'un produit :
**Il vaut mieux faire en sorte de terminer un seul produit sur deux dans les temps plutôt qu'aucun car du fait de la parallélisation de la fabrication des produits, on peut être surchargé de travail.
**Un produit livré durant le laps de temps demandé rapportera plus de points non négligeables.
*Un tableau sera nécessaire afin de savoir ce qu'il y a les espaces de stockage avec les champs suivants :
**Type de produit
**Liste de tâches restantes pour la fabrication du produit (pour un produit fini cette liste est donc nulle)
**Date de début de livraison
**Date de fin de livraison
**Emplacement de l'espace de stockage
 

===Semaine 6===
*Différentes fonctions et actions en pseudo code pour le générateur de tâches
**Fonction qui retourne un booléen suivant si un produit est en stock ou non
**Fonction qui retourne un booléen suivant si on doit livrer le produit à présent ou non
**Fonction qui retourne un booléen suivant si on a déjà ou non mis le travail à faire dans la structure contenant les tâches à réaliser
**Fonction qui retourne le nombre de points que rapporte un produit passé en paramètre
**Action qui rajoute les nouveaux ordres de production dans la liste de listes de tâches
**Action qui calcule le ratio pour chaque tâche
**Action qui supprime les tâches vides (ie celles qui sont terminées)
*Début de l'écriture en pseudo code de la fonction principale
 
*Discussion avec M. Vincent Coelen concernant l'avancement du projet :
**Validation par M. Coelen Vincent des portions de pseudo code déjà écrites
**Discussion autour de la mise en place d'un arrêt immédiat des robots à tout moment du jeu
**Amélioration concernant la robustesse de l'algorithme si un robot n'est plus en état de fonctionnement
 
*Différentes remarques utiles :
**Branche concernant le manager créée sur le [https://github.com/PyroTeam/robocup-pkg/ git] de l'équipe
**Discussion avec d'autres membres de l'équipe sur les services et les topics à envoyer et à recevoir aux nœuds du manager
 
===Semaine 7===

====Générateur de tâches====
Début du codage C++ :
*Création de différentes classes :
**La classe Tache (tache.h et tache.cpp)
**La classe Stockage (stockage.h et stockage.cpp)
**La classe RefBoxComm (refboxcomm.h)
*Création de différentes fonctions :
**Dans tache.h et tache.cpp :
***point_par_produit : retourne le nombre de points que vaut un produit
***dans_les_temps : retourne un booléen indiquant s'il est temps de ramener le produit
**Dans listetaches.h et listetaches.cpp :
***creation_liste_taches_prod : retourne une liste de taches à partir d'un produit passé en paramètre
***creation_liste_taches_act : retourne une liste de taches à partir d'un produit et d'une action passés en paramètres
**Dans tableaustockage.h :
***produit_en_stock : retourne un booléen indiquant si au moins un produit est en stock
**Dans travail.h et travail.cpp :
***deja_dans_travail : retourne un booléen indiquant si un ordre de la RefBox a déjà été pris en compte dans la structure contenant les tâches à réaliser
***max_ratio : retourne l'objet Tache qui a le plus grand ratio dans la structure contenant les tâches à réaliser
***rajout_dans_travail : rajoute un nouvel ordre de la RefBox dans la structure contenant les tâches à réaliser
***calcul_ratio : calcule le ratio de chaque premier de liste de la structure contenant les tâches à réaliser
 
Les codes sont disponibles sur le [https://github.com/PyroTeam/robocup-pkg/tree/feature/manager/generateur_taches git]
 
Des tests ont été réalisés afin de valider les fonctions crées en particulier les fonctions contenues dans travail.h et travail.cpp
 
Voici un petit aperçu de la console :
 
[[Fichier:Capture terminal gen taches 3.png|800px]]
 
Ainsi, les quatres fonctions fonctionnent parfaitement :
*deja_dans_travail indique bien que l'ordre de la RefBox n'a pas encore pris en compte
*max_ratio retourne bien la tâche dont le ratio est maximum
*rajout_dans_travail rajoute en fin de liste la liste de tâches pour la première création d'un produit P0 car un cap est disponible , puis il concatène une liste contenant en tête la tâche "Decapsuler" avec la liste de tâches pour la seconde création d'un produit P0. En effet, la RefBox a demandé deux fois le produit P0 et on ne peut créer un produit tant qu'un cap n'est pas disponible.
*calcul_ratio calcule le ratio de chaque première tâche en fonction du nombre de points et du temps, de plus, si c'est le bon moment pour déstocker un produit il passe cette tâche "Destocker" en priorité (liste 6), en outre, la création d'un produit (liste 1 et liste 7) est prioritaire à l'unique tâche "Decapsuler" (listes 2, 3, 4 et 5) .
 
'''Nous avons enfin reçu le sujet 2015 pour la compétition 2015, il est disponible [https://drive.google.com/file/d/0B39jN82rDE6qSk11YXFuQVljTlE/view?usp=sharing ici]'''
 
*Modification à réaliser :
**la fonction de création de liste de tâches
**l'ordonnancement (en partie)
**calcul de ratio de chaque tâche

====Exécuteur de tâches====
[[Fichier:shema1.png]]

===Semaine 8===
====Générateur de tâches====
*Création du service pour l'envoi des ordres pour l’exécuteur de tâches avec pour contenu:
**Numéro du robot
***1, 2 ou 3
**Ordre
***ChercherBase
***MettreCap
***ChercherCap
***MettreRing
***ChercherRing
***RamenerBaseRS
***Livrer
***Decapsuler
***Destocker
**Paramètre
***noir
***argent
***rouge
***orange
***jaune
***bleu
***vert
***gris
***DS
***stock
***aucun
**Id
***0, 1, 2, 3, 4, 5 ou 6
 
L'exécuteur de tâches du robot concerné doit envoyer en retour :
*un booléen qui indique si l'ordre est accepté ou non
*l'ordre pris en compte
*l'Id de retour
 
Création d'un nœud ROS pour le débogage à l'aide de ddd
 
Création d'un nœud ROS pour similer l'envoi et la réception des ordres
 
====Exécuteur de tâches====
L'exécuteur de taches est un noeud qui recevra des ordres de la part du générateur de taches et qui, à son tour, va envoyer des ordres aux autres noeuds.

Voici le schéma de communication entre les différents noeuds :

[[Fichier:schema2.jpg]]

===Semaine 9===
 
===Semaine 10===
 
===Semaine 11===
 
===Semaine 12===
 

== Fichiers Rendus ==

Fichier:Shema1.png

2015-03-19T12:38:04Z

Shage-ch :

RoboCup 2015

2015-03-19T11:29:47Z

Shage-ch : /* Générateur de tâches */

__TOC__
 
[[Fichier:logoPyro_icone.png |center ]]
<center> Polytech RoboCup Team </center>

==Cahier des charges==
===Présentation générale du projet===

Lors de la compétition de l'Open German, prélude de la Robocup, il faudra mettre en place un système d'autonomisation de production à l'aide de Robotinos (robots mobiles de Festo ayant un système d'exploitation Linux). Comme dans toutes compétitions, le but est de gagner, par conséquent, il faudra faire en sorte de gagner un maximum de points.
C'est pourquoi il faut créer un manager à l'aide de ROS, c'est-à-dire un nœud ou ensemble de nœuds permettant de pouvoir recevoir les informations envoyées par les autres nœuds, de les traiter, tout cela afin de donner les ordres que doivent exécuter chaque Robotino. Ce manager devra également être capable d'optimiser le nombre de points à obtenir.

====Contexte====

La compétition de l'Open German se déroule en quatre phases spécifiques : phase de début-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des tâches spécifiques à remplir suivant les différentes phases. La RefereeBox est un système d'arbitrage auquel il est nécessaire d'envoyer périodiquement des données à tout moment du jeu et qui donne à chaque instant l'état du jeu ainsi que les produits demandés en priorité durant la phase de production.

====Objectif du projet====

*Assurer un maximum de points suivant les aléas du jeu (panne de machine, produits demandées, rupture de stock d'une matière première, …)
*Assurer la pérennité du projet (chaque année des candidats de Polytech Lille y participent)

====Description du projet====

Pour le projet, outre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes :
*Communication avec le nœud de la RefereeBox à tout moment du jeu
*Contrainte de robustesse (il ne faut qu'à un moment ou à un autre il n'y ait un blocage de tous les robots)
*Coopération entre les trois robots
 
[[Fichier:Interactions.png|vignette|left|upright=2|Interactions des nœuds avec le manager]]
 
Le manager devra interagir avec les différents nœuds suivants ayant chacun leurs rôles spécifiques :
*RefereeBox Comm : recevoir les données envoyées par la RefereeBox et envoyer des données suivant l'état du jeu à la RefereeBox
*Robots Comm : communiquer aux autres robots les informations concernant ce que chacun font
*Traitement des TAGs : lire les TAG
*Traitement des feux : lire l'état des colonnes de feu
*Pince de préhension : ouvrir et fermer la pince et renvoyer l'état de la pince
*Approche finale : s'adapter au banc de charge ou de décharge de produits
*Génération trajectoire : détermine une trajectoire pour aller au lieu (X,Y)
*Réalisation trajectoire : parcourir la trajectoire
*Localisation : savoir périodiquement (faible période) où se situe le robot
*Détection d'obstacle : détecter les obstacles fixes et mobiles
 

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

*Utilisation de trois robotinos
*Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce système travaille en utilisant des nœuds qui communiquent entre eux à l'aide de services (requête-réponse) et de topics (fichiers).
*Utilisation de différents langages : C++ ou Python (nœuds)
*Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS
 

===Etapes du projet===
*Prise en main de ROS et du C++
*Élaboration de l'algorithme du manager pour la phase d'exploration
*Élaboration de l'algorithme du manager pour la phase de production
**Coopération entre robots
**Répartition des tâches
*Codage du manager
*Tests et corrections
 

==Avancement du Projet==
===Semaine 1===
*Prise en main de ROS
*Réalisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials
*Réalisation de différents tutoriels C++
*Connaissance plus aiguë du sujet de l'Open German 2015
 
===Semaine 2===
*Réflexions autour de la structure du manager : deux nœuds
**Un nœud exécuteur de tâches
**Un nœud générateur de tâches
*Réflexions sur l'algorithme général du manager concernant la phase d'exploration
**Fonctionnement par zoning pour la répartition des tâches des trois robots
**Réflexion autour d'une alternative de répartition par distances les plus courtes entre machines
*Recherche de solutions pour la phase de production
**Documentation autour de la planification de tâches et la génération de tâche pour une équipe
**Recherche autour de la coopération et de l'allocation de rôles à des robots multi-tâches
*Organisation générale
**Structuration d'un échéancier numérique sous Asana
**Demande d'autorisation pour l'ouverture de la salle C002 auprès de M. Scrive
 

===Semaine 3===
Voilà un lien permettant d'accéder au sujet provisoire de la Robocup 2015 : [https://drive.google.com/file/d/0B39jN82rDE6qMG45cDN5Z0xiSVE/view?usp=sharing Sujet] 
*Réflexions au sujet des infos à communiquer au nœud AutresRobotsComm :
**Ce que le robotino fait
**Quelle machine le robotino est en train d'utiliser
[[Fichier:DataSWithRobotComm.jpg|center]]
 
*Réflexions au niveau de l'algorithme de la phase de production
**Proposition de le faire sous le principe de "Diviser pour mieux régner" (validé par M. Vincent Coelen)
***Diviser la tâche principale en sous-tâches, les sous-tâches en sous-sous-tâches et les sous-sous-tâches en sous-sous-sous-tâches élémentaires.
**Détermination des tâches à réaliser pour un exemple particulier
On souhaite produire, pendant une durée déterminée par la refBox, le produit suivant :
[[Fichier:ExempleProduitDemande.jpg|center]]
''Le produit est composé d’une base bleue, d’un ring rouge, d’un ring vert et d’un cap noir.''

'''Obtenir Base Bleue'''
->Aller à la Base Station
générateur trajectoire
exécuteur trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (dire à la Base Station quelle base est souhaitée et à quelle banc le robotino est)
approche finale
pince (prendre)

'''Obtenir ring rouge'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Obtenir ring vert'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
(Du coup la plus proche sera celle où on vient de faire le ring précédent)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Ring Station quelle base est souhaitée ( ici, la verte )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Finaliser produit'''
->Aller à une Cap Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Cap Station quelle cap est souhaité ( ici, le noir )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel banc de livraison)
approche finale
pince (prendre)
->Déposer à la Delivery Station
générateur de trajectoire (vers la Delivery Station)
exécuteur de trajectoire
approche finale
pince (déposer)
 
*Organisation générale :
**Création de la page Facebook de l'équipe PYRO Team
 

===Semaine 4===
*Écriture des sous-tâches à réaliser
**Pseudo-codes de certaines sous-tâches réalisées
*Recherche d'ordonnancement optimisé pour la fabrication du produit
**Recherche d'algorithmes
**Visualisation du problème d'ordonnancement concernant l'exemple précédent (base bleue, ring vert, ring rouge, cap noir)
 
Ici, on a pris en plus en hypothèse le fait que la Ring Station (RS1) est capable de mettre des rings rouges ou verts et que la RS2 est capable de de mettre des rings bleus et rouges. Afin de mieux appréhender le problème, nous nous sommes attachés à effectuer un tableau récapitulant les tâches à effectuer pour le produit exemple et à réaliser un graphe mettant en avant les contraintes de précédence de chaque tâche.
 

{| class="wikitable" style="text-align:center; width:80%;"

|-
|
! scope="col" | Tâches
! scope="col" | Ressources utilisées
! scope="col" | Contraintes de précédence
|-
! scope="row" | T0
| Ramener à CS base avec cap
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T1
| Décapsuler
| Cap Station 1 ou 2
| T0
|-
! scope="row" | T2
| Ramener base supplémentaires à RS
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T3
| Chercher base bleue
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T4
| Ramener à RS pour ring vert
| Robot 1, 2 ou 3
| T7
|-
! scope="row" | T5
| Ramener à RS pour ring rouge
| Robot 1, 2 ou 3
| T8
|-
! scope="row" | T6
| Ramener à CS pour cap
| Robot 1, 2 ou 3
| T9
|-
! scope="row" | T7
| Ramener Base
| Base Station
| T3
|-
! scope="row" | T8
| Ajouter ring vert
| Ring Station 1
| T4
|-
! scope="row" | T9
| Ajouter ring rouge
| Ring Station 1 ou 2
| T5 et T2
|-
! scope="row" | T10
| Ajouter cap
| Cap Station 1 ou 2
| T6 et T1
|-
! scope="row" | T11
| Traiter le produit fini
| Delivery Station
| T12
|-
! scope="row" | T12
| Ramener à DS
| Robot 1, 2 ou 3
| T10
|}
[[Fichier:TachesProduitExemple.png|center]]
<center>Graphe montrant l'ordre des tâches à réaliser</center>
 

===Semaine 5===
Durant cette semaine, nous avons réfléchi sur le choix de structures pour nos données :
* Une '''liste principale''' de tous les produits demandés par la RefBox à un instant t. Cette liste principale a les caractéristiques suivantes :
** Une '''Priorité''' sera calculée pour chaque produit avec les paramètres suivants :
*** Nombre de points que peut apporter la production d'un produit de A à Z.
*** Une estimation du temps de production d'un produit.
***La date limite de livraison du produit demandé
** Une tâche est élue si sa priorité est supérieure ou égale à celle des autres tâches.
** Quand la RefBox demande un produit, une cellule sera ajoutée dans cette liste. Et de même, quand un produit sera terminé, on le supprimera de cette liste.
* Chaque produit de la liste principale va contenir une '''liste de tâches''' correspondantes à la production de ce produit. Cette liste de tâches a les caractéristiques suivantes :
** Chaque cellule correspond à une tâche de la production d'un produit. Une tâche contient différents champs :
***Intitulé de la tâche (par exemple ajouter une base)
***Produit concernée (par exemple P3)
***Priorité de la tâche (par exemple 20)
***Temps restant estimé de production (par exemple 180s)
** A chaque fois qu'une tâche est réalisée, elle sera supprimée de la liste de tâches. Ce qui veut dire, qu'on va devoir calculé à nouveau la priorité de chaque tâche de la liste principale.
** Afin de respecter les contraintes de précédence, on considérera que la tâche en tête de la liste de tâches peut être élue. Par exemple, on ne peut pas ajouter un Ring si on n'a pas de base.
 
L'exemple suivant simule le cas où la RefBox a demandé deux fois le produit P3 et deux fois le produit P2.
*Le produit P3 est réalisable en cinq tâches.Ce produit mettra plus de temps à être fabriqué mais rapportera plus de points.
*Le produit P2 est réalisable en quatre tâches.
 
[[Fichier:listedelistes.png|center]]
<center>Structure utilisée pour ranger les tâches à réaliser</center>
 
Différentes remarques utiles :
*Avant de commencer à réaliser n'importe quel produit, il faudra au préalable vérifier si on a libérer un espace de stockage pour plusieurs raisons :
**Les Cap Stations ayant initialement aucun cap en stock, il faut les ramener de l'étagère qui en contient initialement car un produit est dit fini lorsqu'il a à son sommet un cap.
**L'étagère ayant été débarrassée d'un cap, cela permet d'avoir un espace de stockage afin de déposer des produits finis en attente de livraison ou des produits non finis dont on voudrait mettre en pause la production.
*Il sera peut être des fois plus avantageux d'abandonner temporairement la production d'un produit :
**Il vaut mieux faire en sorte de terminer un seul produit sur deux dans les temps plutôt qu'aucun car du fait de la parallélisation de la fabrication des produits, on peut être surchargé de travail.
**Un produit livré durant le laps de temps demandé rapportera plus de points non négligeables.
*Un tableau sera nécessaire afin de savoir ce qu'il y a les espaces de stockage avec les champs suivants :
**Type de produit
**Liste de tâches restantes pour la fabrication du produit (pour un produit fini cette liste est donc nulle)
**Date de début de livraison
**Date de fin de livraison
**Emplacement de l'espace de stockage
 

===Semaine 6===
*Différentes fonctions et actions en pseudo code pour le générateur de tâches
**Fonction qui retourne un booléen suivant si un produit est en stock ou non
**Fonction qui retourne un booléen suivant si on doit livrer le produit à présent ou non
**Fonction qui retourne un booléen suivant si on a déjà ou non mis le travail à faire dans la structure contenant les tâches à réaliser
**Fonction qui retourne le nombre de points que rapporte un produit passé en paramètre
**Action qui rajoute les nouveaux ordres de production dans la liste de listes de tâches
**Action qui calcule le ratio pour chaque tâche
**Action qui supprime les tâches vides (ie celles qui sont terminées)
*Début de l'écriture en pseudo code de la fonction principale
 
*Discussion avec M. Vincent Coelen concernant l'avancement du projet :
**Validation par M. Coelen Vincent des portions de pseudo code déjà écrites
**Discussion autour de la mise en place d'un arrêt immédiat des robots à tout moment du jeu
**Amélioration concernant la robustesse de l'algorithme si un robot n'est plus en état de fonctionnement
 
*Différentes remarques utiles :
**Branche concernant le manager créée sur le [https://github.com/PyroTeam/robocup-pkg/ git] de l'équipe
**Discussion avec d'autres membres de l'équipe sur les services et les topics à envoyer et à recevoir aux nœuds du manager
 
===Semaine 7===

====Générateur de tâches====
Début du codage C++ :
*Création de différentes classes :
**La classe Tache (tache.h et tache.cpp)
**La classe Stockage (stockage.h et stockage.cpp)
**La classe RefBoxComm (refboxcomm.h)
*Création de différentes fonctions :
**Dans tache.h et tache.cpp :
***point_par_produit : retourne le nombre de points que vaut un produit
***dans_les_temps : retourne un booléen indiquant s'il est temps de ramener le produit
**Dans listetaches.h et listetaches.cpp :
***creation_liste_taches_prod : retourne une liste de taches à partir d'un produit passé en paramètre
***creation_liste_taches_act : retourne une liste de taches à partir d'un produit et d'une action passés en paramètres
**Dans tableaustockage.h :
***produit_en_stock : retourne un booléen indiquant si au moins un produit est en stock
**Dans travail.h et travail.cpp :
***deja_dans_travail : retourne un booléen indiquant si un ordre de la RefBox a déjà été pris en compte dans la structure contenant les tâches à réaliser
***max_ratio : retourne l'objet Tache qui a le plus grand ratio dans la structure contenant les tâches à réaliser
***rajout_dans_travail : rajoute un nouvel ordre de la RefBox dans la structure contenant les tâches à réaliser
***calcul_ratio : calcule le ratio de chaque premier de liste de la structure contenant les tâches à réaliser
 
Les codes sont disponibles sur le [https://github.com/PyroTeam/robocup-pkg/tree/feature/manager/generateur_taches git]
 
Des tests ont été réalisés afin de valider les fonctions crées en particulier les fonctions contenues dans travail.h et travail.cpp
 
Voici un petit aperçu de la console :
 
[[Fichier:Capture terminal gen taches 3.png|800px]]
 
Ainsi, les quatres fonctions fonctionnent parfaitement :
*deja_dans_travail indique bien que l'ordre de la RefBox n'a pas encore pris en compte
*max_ratio retourne bien la tâche dont le ratio est maximum
*rajout_dans_travail rajoute en fin de liste la liste de tâches pour la première création d'un produit P0 car un cap est disponible , puis il concatène une liste contenant en tête la tâche "Decapsuler" avec la liste de tâches pour la seconde création d'un produit P0. En effet, la RefBox a demandé deux fois le produit P0 et on ne peut créer un produit tant qu'un cap n'est pas disponible.
*calcul_ratio calcule le ratio de chaque première tâche en fonction du nombre de points et du temps, de plus, si c'est le bon moment pour déstocker un produit il passe cette tâche "Destocker" en priorité (liste 6), en outre, la création d'un produit (liste 1 et liste 7) est prioritaire à l'unique tâche "Decapsuler" (listes 2, 3, 4 et 5) .
 
'''Nous avons enfin reçu le sujet 2015 pour la compétition 2015, il est disponible [https://drive.google.com/file/d/0B39jN82rDE6qSk11YXFuQVljTlE/view?usp=sharing ici]'''
 
*Modification à réaliser :
**la fonction de création de liste de tâches
**l'ordonnancement (en partie)
**calcul de ratio de chaque tâche

====Exécuteur de tâches====
[[Fichier:shema1.jpg]]

===Semaine 8===
====Générateur de tâches====
*Création du service pour l'envoi des ordres pour l’exécuteur de tâches avec pour contenu:
**Numéro du robot
***1, 2 ou 3
**Ordre
***ChercherBase
***MettreCap
***ChercherCap
***MettreRing
***ChercherRing
***RamenerBaseRS
***Livrer
***Decapsuler
***Destocker
**Paramètre
***noir
***argent
***rouge
***orange
***jaune
***bleu
***vert
***gris
***DS
***stock
***aucun
**Id
***0, 1, 2, 3, 4, 5 ou 6
 
L'exécuteur de tâches du robot concerné doit envoyer en retour :
*un booléen qui indique si l'ordre est accepté ou non
*l'ordre pris en compte
*l'Id de retour
 
Création d'un nœud ROS pour le débogage à l'aide de ddd
 
Création d'un nœud ROS pour similer l'envoi et la réception des ordres
 
====Exécuteur de tâches====
L'exécuteur de taches est un noeud qui recevra des ordres de la part du générateur de taches et qui, à son tour, va envoyer des ordres aux autres noeuds.

Voici le schéma de communication entre les différents noeuds :

[[Fichier:schema2.jpg]]

===Semaine 9===
 
===Semaine 10===
 
===Semaine 11===
 
===Semaine 12===
 

== Fichiers Rendus ==

RoboCup 2015

2015-03-19T11:24:14Z

Shage-ch : /* Exécuteur de tâches */

__TOC__
 
[[Fichier:logoPyro_icone.png |center ]]
<center> Polytech RoboCup Team </center>

==Cahier des charges==
===Présentation générale du projet===

Lors de la compétition de l'Open German, prélude de la Robocup, il faudra mettre en place un système d'autonomisation de production à l'aide de Robotinos (robots mobiles de Festo ayant un système d'exploitation Linux). Comme dans toutes compétitions, le but est de gagner, par conséquent, il faudra faire en sorte de gagner un maximum de points.
C'est pourquoi il faut créer un manager à l'aide de ROS, c'est-à-dire un nœud ou ensemble de nœuds permettant de pouvoir recevoir les informations envoyées par les autres nœuds, de les traiter, tout cela afin de donner les ordres que doivent exécuter chaque Robotino. Ce manager devra également être capable d'optimiser le nombre de points à obtenir.

====Contexte====

La compétition de l'Open German se déroule en quatre phases spécifiques : phase de début-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des tâches spécifiques à remplir suivant les différentes phases. La RefereeBox est un système d'arbitrage auquel il est nécessaire d'envoyer périodiquement des données à tout moment du jeu et qui donne à chaque instant l'état du jeu ainsi que les produits demandés en priorité durant la phase de production.

====Objectif du projet====

*Assurer un maximum de points suivant les aléas du jeu (panne de machine, produits demandées, rupture de stock d'une matière première, …)
*Assurer la pérennité du projet (chaque année des candidats de Polytech Lille y participent)

====Description du projet====

Pour le projet, outre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes :
*Communication avec le nœud de la RefereeBox à tout moment du jeu
*Contrainte de robustesse (il ne faut qu'à un moment ou à un autre il n'y ait un blocage de tous les robots)
*Coopération entre les trois robots
 
[[Fichier:Interactions.png|vignette|left|upright=2|Interactions des nœuds avec le manager]]
 
Le manager devra interagir avec les différents nœuds suivants ayant chacun leurs rôles spécifiques :
*RefereeBox Comm : recevoir les données envoyées par la RefereeBox et envoyer des données suivant l'état du jeu à la RefereeBox
*Robots Comm : communiquer aux autres robots les informations concernant ce que chacun font
*Traitement des TAGs : lire les TAG
*Traitement des feux : lire l'état des colonnes de feu
*Pince de préhension : ouvrir et fermer la pince et renvoyer l'état de la pince
*Approche finale : s'adapter au banc de charge ou de décharge de produits
*Génération trajectoire : détermine une trajectoire pour aller au lieu (X,Y)
*Réalisation trajectoire : parcourir la trajectoire
*Localisation : savoir périodiquement (faible période) où se situe le robot
*Détection d'obstacle : détecter les obstacles fixes et mobiles
 

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

*Utilisation de trois robotinos
*Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce système travaille en utilisant des nœuds qui communiquent entre eux à l'aide de services (requête-réponse) et de topics (fichiers).
*Utilisation de différents langages : C++ ou Python (nœuds)
*Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS
 

===Etapes du projet===
*Prise en main de ROS et du C++
*Élaboration de l'algorithme du manager pour la phase d'exploration
*Élaboration de l'algorithme du manager pour la phase de production
**Coopération entre robots
**Répartition des tâches
*Codage du manager
*Tests et corrections
 

==Avancement du Projet==
===Semaine 1===
*Prise en main de ROS
*Réalisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials
*Réalisation de différents tutoriels C++
*Connaissance plus aiguë du sujet de l'Open German 2015
 
===Semaine 2===
*Réflexions autour de la structure du manager : deux nœuds
**Un nœud exécuteur de tâches
**Un nœud générateur de tâches
*Réflexions sur l'algorithme général du manager concernant la phase d'exploration
**Fonctionnement par zoning pour la répartition des tâches des trois robots
**Réflexion autour d'une alternative de répartition par distances les plus courtes entre machines
*Recherche de solutions pour la phase de production
**Documentation autour de la planification de tâches et la génération de tâche pour une équipe
**Recherche autour de la coopération et de l'allocation de rôles à des robots multi-tâches
*Organisation générale
**Structuration d'un échéancier numérique sous Asana
**Demande d'autorisation pour l'ouverture de la salle C002 auprès de M. Scrive
 

===Semaine 3===
Voilà un lien permettant d'accéder au sujet provisoire de la Robocup 2015 : [https://drive.google.com/file/d/0B39jN82rDE6qMG45cDN5Z0xiSVE/view?usp=sharing Sujet] 
*Réflexions au sujet des infos à communiquer au nœud AutresRobotsComm :
**Ce que le robotino fait
**Quelle machine le robotino est en train d'utiliser
[[Fichier:DataSWithRobotComm.jpg|center]]
 
*Réflexions au niveau de l'algorithme de la phase de production
**Proposition de le faire sous le principe de "Diviser pour mieux régner" (validé par M. Vincent Coelen)
***Diviser la tâche principale en sous-tâches, les sous-tâches en sous-sous-tâches et les sous-sous-tâches en sous-sous-sous-tâches élémentaires.
**Détermination des tâches à réaliser pour un exemple particulier
On souhaite produire, pendant une durée déterminée par la refBox, le produit suivant :
[[Fichier:ExempleProduitDemande.jpg|center]]
''Le produit est composé d’une base bleue, d’un ring rouge, d’un ring vert et d’un cap noir.''

'''Obtenir Base Bleue'''
->Aller à la Base Station
générateur trajectoire
exécuteur trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (dire à la Base Station quelle base est souhaitée et à quelle banc le robotino est)
approche finale
pince (prendre)

'''Obtenir ring rouge'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Obtenir ring vert'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
(Du coup la plus proche sera celle où on vient de faire le ring précédent)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Ring Station quelle base est souhaitée ( ici, la verte )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Finaliser produit'''
->Aller à une Cap Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Cap Station quelle cap est souhaité ( ici, le noir )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel banc de livraison)
approche finale
pince (prendre)
->Déposer à la Delivery Station
générateur de trajectoire (vers la Delivery Station)
exécuteur de trajectoire
approche finale
pince (déposer)
 
*Organisation générale :
**Création de la page Facebook de l'équipe PYRO Team
 

===Semaine 4===
*Écriture des sous-tâches à réaliser
**Pseudo-codes de certaines sous-tâches réalisées
*Recherche d'ordonnancement optimisé pour la fabrication du produit
**Recherche d'algorithmes
**Visualisation du problème d'ordonnancement concernant l'exemple précédent (base bleue, ring vert, ring rouge, cap noir)
 
Ici, on a pris en plus en hypothèse le fait que la Ring Station (RS1) est capable de mettre des rings rouges ou verts et que la RS2 est capable de de mettre des rings bleus et rouges. Afin de mieux appréhender le problème, nous nous sommes attachés à effectuer un tableau récapitulant les tâches à effectuer pour le produit exemple et à réaliser un graphe mettant en avant les contraintes de précédence de chaque tâche.
 

{| class="wikitable" style="text-align:center; width:80%;"

|-
|
! scope="col" | Tâches
! scope="col" | Ressources utilisées
! scope="col" | Contraintes de précédence
|-
! scope="row" | T0
| Ramener à CS base avec cap
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T1
| Décapsuler
| Cap Station 1 ou 2
| T0
|-
! scope="row" | T2
| Ramener base supplémentaires à RS
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T3
| Chercher base bleue
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T4
| Ramener à RS pour ring vert
| Robot 1, 2 ou 3
| T7
|-
! scope="row" | T5
| Ramener à RS pour ring rouge
| Robot 1, 2 ou 3
| T8
|-
! scope="row" | T6
| Ramener à CS pour cap
| Robot 1, 2 ou 3
| T9
|-
! scope="row" | T7
| Ramener Base
| Base Station
| T3
|-
! scope="row" | T8
| Ajouter ring vert
| Ring Station 1
| T4
|-
! scope="row" | T9
| Ajouter ring rouge
| Ring Station 1 ou 2
| T5 et T2
|-
! scope="row" | T10
| Ajouter cap
| Cap Station 1 ou 2
| T6 et T1
|-
! scope="row" | T11
| Traiter le produit fini
| Delivery Station
| T12
|-
! scope="row" | T12
| Ramener à DS
| Robot 1, 2 ou 3
| T10
|}
[[Fichier:TachesProduitExemple.png|center]]
<center>Graphe montrant l'ordre des tâches à réaliser</center>
 

===Semaine 5===
Durant cette semaine, nous avons réfléchi sur le choix de structures pour nos données :
* Une '''liste principale''' de tous les produits demandés par la RefBox à un instant t. Cette liste principale a les caractéristiques suivantes :
** Une '''Priorité''' sera calculée pour chaque produit avec les paramètres suivants :
*** Nombre de points que peut apporter la production d'un produit de A à Z.
*** Une estimation du temps de production d'un produit.
***La date limite de livraison du produit demandé
** Une tâche est élue si sa priorité est supérieure ou égale à celle des autres tâches.
** Quand la RefBox demande un produit, une cellule sera ajoutée dans cette liste. Et de même, quand un produit sera terminé, on le supprimera de cette liste.
* Chaque produit de la liste principale va contenir une '''liste de tâches''' correspondantes à la production de ce produit. Cette liste de tâches a les caractéristiques suivantes :
** Chaque cellule correspond à une tâche de la production d'un produit. Une tâche contient différents champs :
***Intitulé de la tâche (par exemple ajouter une base)
***Produit concernée (par exemple P3)
***Priorité de la tâche (par exemple 20)
***Temps restant estimé de production (par exemple 180s)
** A chaque fois qu'une tâche est réalisée, elle sera supprimée de la liste de tâches. Ce qui veut dire, qu'on va devoir calculé à nouveau la priorité de chaque tâche de la liste principale.
** Afin de respecter les contraintes de précédence, on considérera que la tâche en tête de la liste de tâches peut être élue. Par exemple, on ne peut pas ajouter un Ring si on n'a pas de base.
 
L'exemple suivant simule le cas où la RefBox a demandé deux fois le produit P3 et deux fois le produit P2.
*Le produit P3 est réalisable en cinq tâches.Ce produit mettra plus de temps à être fabriqué mais rapportera plus de points.
*Le produit P2 est réalisable en quatre tâches.
 
[[Fichier:listedelistes.png|center]]
<center>Structure utilisée pour ranger les tâches à réaliser</center>
 
Différentes remarques utiles :
*Avant de commencer à réaliser n'importe quel produit, il faudra au préalable vérifier si on a libérer un espace de stockage pour plusieurs raisons :
**Les Cap Stations ayant initialement aucun cap en stock, il faut les ramener de l'étagère qui en contient initialement car un produit est dit fini lorsqu'il a à son sommet un cap.
**L'étagère ayant été débarrassée d'un cap, cela permet d'avoir un espace de stockage afin de déposer des produits finis en attente de livraison ou des produits non finis dont on voudrait mettre en pause la production.
*Il sera peut être des fois plus avantageux d'abandonner temporairement la production d'un produit :
**Il vaut mieux faire en sorte de terminer un seul produit sur deux dans les temps plutôt qu'aucun car du fait de la parallélisation de la fabrication des produits, on peut être surchargé de travail.
**Un produit livré durant le laps de temps demandé rapportera plus de points non négligeables.
*Un tableau sera nécessaire afin de savoir ce qu'il y a les espaces de stockage avec les champs suivants :
**Type de produit
**Liste de tâches restantes pour la fabrication du produit (pour un produit fini cette liste est donc nulle)
**Date de début de livraison
**Date de fin de livraison
**Emplacement de l'espace de stockage
 

===Semaine 6===
*Différentes fonctions et actions en pseudo code pour le générateur de tâches
**Fonction qui retourne un booléen suivant si un produit est en stock ou non
**Fonction qui retourne un booléen suivant si on doit livrer le produit à présent ou non
**Fonction qui retourne un booléen suivant si on a déjà ou non mis le travail à faire dans la structure contenant les tâches à réaliser
**Fonction qui retourne le nombre de points que rapporte un produit passé en paramètre
**Action qui rajoute les nouveaux ordres de production dans la liste de listes de tâches
**Action qui calcule le ratio pour chaque tâche
**Action qui supprime les tâches vides (ie celles qui sont terminées)
*Début de l'écriture en pseudo code de la fonction principale
 
*Discussion avec M. Vincent Coelen concernant l'avancement du projet :
**Validation par M. Coelen Vincent des portions de pseudo code déjà écrites
**Discussion autour de la mise en place d'un arrêt immédiat des robots à tout moment du jeu
**Amélioration concernant la robustesse de l'algorithme si un robot n'est plus en état de fonctionnement
 
*Différentes remarques utiles :
**Branche concernant le manager créée sur le [https://github.com/PyroTeam/robocup-pkg/ git] de l'équipe
**Discussion avec d'autres membres de l'équipe sur les services et les topics à envoyer et à recevoir aux nœuds du manager
 
===Semaine 7===

====Générateur de tâches====
Début du codage C++ :
*Création de différentes classes :
**La classe Tache (tache.h et tache.cpp)
**La classe Stockage (stockage.h et stockage.cpp)
**La classe RefBoxComm (refboxcomm.h)
*Création de différentes fonctions :
**Dans tache.h et tache.cpp :
***point_par_produit : retourne le nombre de points que vaut un produit
***dans_les_temps : retourne un booléen indiquant s'il est temps de ramener le produit
**Dans listetaches.h et listetaches.cpp :
***creation_liste_taches_prod : retourne une liste de taches à partir d'un produit passé en paramètre
***creation_liste_taches_act : retourne une liste de taches à partir d'un produit et d'une action passés en paramètres
**Dans tableaustockage.h :
***produit_en_stock : retourne un booléen indiquant si au moins un produit est en stock
**Dans travail.h et travail.cpp :
***deja_dans_travail : retourne un booléen indiquant si un ordre de la RefBox a déjà été pris en compte dans la structure contenant les tâches à réaliser
***max_ratio : retourne l'objet Tache qui a le plus grand ratio dans la structure contenant les tâches à réaliser
***rajout_dans_travail : rajoute un nouvel ordre de la RefBox dans la structure contenant les tâches à réaliser
***calcul_ratio : calcule le ratio de chaque premier de liste de la structure contenant les tâches à réaliser
 
Les codes sont disponibles sur le [https://github.com/PyroTeam/robocup-pkg/tree/feature/manager/generateur_taches git]
 
Des tests ont été réalisés afin de valider les fonctions crées en particulier les fonctions contenues dans travail.h et travail.cpp
 
Voici un petit aperçu de la console :
 
[[Fichier:Capture terminal gen taches 3.png|800px]]
 
Ainsi, les quatres fonctions fonctionnent parfaitement :
*deja_dans_travail indique bien que l'ordre de la RefBox n'a pas encore pris en compte
*max_ratio retourne bien la tâche dont le ratio est maximum
*rajout_dans_travail rajoute en fin de liste la liste de tâches pour la première création d'un produit P0 car un cap est disponible , puis il concatène une liste contenant en tête la tâche "Decapsuler" avec la liste de tâches pour la seconde création d'un produit P0. En effet, la RefBox a demandé deux fois le produit P0 et on ne peut créer un produit tant qu'un cap n'est pas disponible.
*calcul_ratio calcule le ratio de chaque première tâche en fonction du nombre de points et du temps, de plus, si c'est le bon moment pour déstocker un produit il passe cette tâche "Destocker" en priorité (liste 6), en outre, la création d'un produit (liste 1 et liste 7) est prioritaire à l'unique tâche "Decapsuler" (listes 2, 3, 4 et 5) .
 
'''Nous avons enfin reçu le sujet 2015 pour la compétition 2015, il est disponible [https://drive.google.com/file/d/0B39jN82rDE6qSk11YXFuQVljTlE/view?usp=sharing ici]'''
 
*Modification à réaliser :
**la fonction de création de liste de tâches
**l'ordonnancement (en partie)
**calcul de ratio de chaque tâche

===Semaine 8===
====Générateur de tâches====
*Création du service pour l'envoi des ordres pour l’exécuteur de tâches avec pour contenu:
**Numéro du robot
***1, 2 ou 3
**Ordre
***ChercherBase
***MettreCap
***ChercherCap
***MettreRing
***ChercherRing
***RamenerBaseRS
***Livrer
***Decapsuler
***Destocker
**Paramètre
***noir
***argent
***rouge
***orange
***jaune
***bleu
***vert
***gris
***DS
***stock
***aucun
**Id
***0, 1, 2, 3, 4, 5 ou 6
 
L'exécuteur de tâches du robot concerné doit envoyer en retour :
*un booléen qui indique si l'ordre est accepté ou non
*l'ordre pris en compte
*l'Id de retour
 
Création d'un nœud ROS pour le débogage à l'aide de ddd
 
Création d'un nœud ROS pour similer l'envoi et la réception des ordres
 
====Exécuteur de tâches====
L'exécuteur de taches est un noeud qui recevra des ordres de la part du générateur de taches et qui, à son tour, va envoyer des ordres aux autres noeuds.

Voici le schéma de communication entre les différents noeuds :

[[Fichier:schema2.jpg]]

===Semaine 9===
 
===Semaine 10===
 
===Semaine 11===
 
===Semaine 12===
 

== Fichiers Rendus ==

Fichier:Schema2.jpg

2015-03-19T11:23:02Z

Shage-ch :

RoboCup 2015

2015-03-19T11:20:51Z

Shage-ch : /* Semaine 8 */

__TOC__
 
[[Fichier:logoPyro_icone.png |center ]]
<center> Polytech RoboCup Team </center>

==Cahier des charges==
===Présentation générale du projet===

Lors de la compétition de l'Open German, prélude de la Robocup, il faudra mettre en place un système d'autonomisation de production à l'aide de Robotinos (robots mobiles de Festo ayant un système d'exploitation Linux). Comme dans toutes compétitions, le but est de gagner, par conséquent, il faudra faire en sorte de gagner un maximum de points.
C'est pourquoi il faut créer un manager à l'aide de ROS, c'est-à-dire un nœud ou ensemble de nœuds permettant de pouvoir recevoir les informations envoyées par les autres nœuds, de les traiter, tout cela afin de donner les ordres que doivent exécuter chaque Robotino. Ce manager devra également être capable d'optimiser le nombre de points à obtenir.

====Contexte====

La compétition de l'Open German se déroule en quatre phases spécifiques : phase de début-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des tâches spécifiques à remplir suivant les différentes phases. La RefereeBox est un système d'arbitrage auquel il est nécessaire d'envoyer périodiquement des données à tout moment du jeu et qui donne à chaque instant l'état du jeu ainsi que les produits demandés en priorité durant la phase de production.

====Objectif du projet====

*Assurer un maximum de points suivant les aléas du jeu (panne de machine, produits demandées, rupture de stock d'une matière première, …)
*Assurer la pérennité du projet (chaque année des candidats de Polytech Lille y participent)

====Description du projet====

Pour le projet, outre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes :
*Communication avec le nœud de la RefereeBox à tout moment du jeu
*Contrainte de robustesse (il ne faut qu'à un moment ou à un autre il n'y ait un blocage de tous les robots)
*Coopération entre les trois robots
 
[[Fichier:Interactions.png|vignette|left|upright=2|Interactions des nœuds avec le manager]]
 
Le manager devra interagir avec les différents nœuds suivants ayant chacun leurs rôles spécifiques :
*RefereeBox Comm : recevoir les données envoyées par la RefereeBox et envoyer des données suivant l'état du jeu à la RefereeBox
*Robots Comm : communiquer aux autres robots les informations concernant ce que chacun font
*Traitement des TAGs : lire les TAG
*Traitement des feux : lire l'état des colonnes de feu
*Pince de préhension : ouvrir et fermer la pince et renvoyer l'état de la pince
*Approche finale : s'adapter au banc de charge ou de décharge de produits
*Génération trajectoire : détermine une trajectoire pour aller au lieu (X,Y)
*Réalisation trajectoire : parcourir la trajectoire
*Localisation : savoir périodiquement (faible période) où se situe le robot
*Détection d'obstacle : détecter les obstacles fixes et mobiles
 

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

*Utilisation de trois robotinos
*Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce système travaille en utilisant des nœuds qui communiquent entre eux à l'aide de services (requête-réponse) et de topics (fichiers).
*Utilisation de différents langages : C++ ou Python (nœuds)
*Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS
 

===Etapes du projet===
*Prise en main de ROS et du C++
*Élaboration de l'algorithme du manager pour la phase d'exploration
*Élaboration de l'algorithme du manager pour la phase de production
**Coopération entre robots
**Répartition des tâches
*Codage du manager
*Tests et corrections
 

==Avancement du Projet==
===Semaine 1===
*Prise en main de ROS
*Réalisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials
*Réalisation de différents tutoriels C++
*Connaissance plus aiguë du sujet de l'Open German 2015
 
===Semaine 2===
*Réflexions autour de la structure du manager : deux nœuds
**Un nœud exécuteur de tâches
**Un nœud générateur de tâches
*Réflexions sur l'algorithme général du manager concernant la phase d'exploration
**Fonctionnement par zoning pour la répartition des tâches des trois robots
**Réflexion autour d'une alternative de répartition par distances les plus courtes entre machines
*Recherche de solutions pour la phase de production
**Documentation autour de la planification de tâches et la génération de tâche pour une équipe
**Recherche autour de la coopération et de l'allocation de rôles à des robots multi-tâches
*Organisation générale
**Structuration d'un échéancier numérique sous Asana
**Demande d'autorisation pour l'ouverture de la salle C002 auprès de M. Scrive
 

===Semaine 3===
Voilà un lien permettant d'accéder au sujet provisoire de la Robocup 2015 : [https://drive.google.com/file/d/0B39jN82rDE6qMG45cDN5Z0xiSVE/view?usp=sharing Sujet] 
*Réflexions au sujet des infos à communiquer au nœud AutresRobotsComm :
**Ce que le robotino fait
**Quelle machine le robotino est en train d'utiliser
[[Fichier:DataSWithRobotComm.jpg|center]]
 
*Réflexions au niveau de l'algorithme de la phase de production
**Proposition de le faire sous le principe de "Diviser pour mieux régner" (validé par M. Vincent Coelen)
***Diviser la tâche principale en sous-tâches, les sous-tâches en sous-sous-tâches et les sous-sous-tâches en sous-sous-sous-tâches élémentaires.
**Détermination des tâches à réaliser pour un exemple particulier
On souhaite produire, pendant une durée déterminée par la refBox, le produit suivant :
[[Fichier:ExempleProduitDemande.jpg|center]]
''Le produit est composé d’une base bleue, d’un ring rouge, d’un ring vert et d’un cap noir.''

'''Obtenir Base Bleue'''
->Aller à la Base Station
générateur trajectoire
exécuteur trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (dire à la Base Station quelle base est souhaitée et à quelle banc le robotino est)
approche finale
pince (prendre)

'''Obtenir ring rouge'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Obtenir ring vert'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
(Du coup la plus proche sera celle où on vient de faire le ring précédent)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Ring Station quelle base est souhaitée ( ici, la verte )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Finaliser produit'''
->Aller à une Cap Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Cap Station quelle cap est souhaité ( ici, le noir )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel banc de livraison)
approche finale
pince (prendre)
->Déposer à la Delivery Station
générateur de trajectoire (vers la Delivery Station)
exécuteur de trajectoire
approche finale
pince (déposer)
 
*Organisation générale :
**Création de la page Facebook de l'équipe PYRO Team
 

===Semaine 4===
*Écriture des sous-tâches à réaliser
**Pseudo-codes de certaines sous-tâches réalisées
*Recherche d'ordonnancement optimisé pour la fabrication du produit
**Recherche d'algorithmes
**Visualisation du problème d'ordonnancement concernant l'exemple précédent (base bleue, ring vert, ring rouge, cap noir)
 
Ici, on a pris en plus en hypothèse le fait que la Ring Station (RS1) est capable de mettre des rings rouges ou verts et que la RS2 est capable de de mettre des rings bleus et rouges. Afin de mieux appréhender le problème, nous nous sommes attachés à effectuer un tableau récapitulant les tâches à effectuer pour le produit exemple et à réaliser un graphe mettant en avant les contraintes de précédence de chaque tâche.
 

{| class="wikitable" style="text-align:center; width:80%;"

|-
|
! scope="col" | Tâches
! scope="col" | Ressources utilisées
! scope="col" | Contraintes de précédence
|-
! scope="row" | T0
| Ramener à CS base avec cap
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T1
| Décapsuler
| Cap Station 1 ou 2
| T0
|-
! scope="row" | T2
| Ramener base supplémentaires à RS
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T3
| Chercher base bleue
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T4
| Ramener à RS pour ring vert
| Robot 1, 2 ou 3
| T7
|-
! scope="row" | T5
| Ramener à RS pour ring rouge
| Robot 1, 2 ou 3
| T8
|-
! scope="row" | T6
| Ramener à CS pour cap
| Robot 1, 2 ou 3
| T9
|-
! scope="row" | T7
| Ramener Base
| Base Station
| T3
|-
! scope="row" | T8
| Ajouter ring vert
| Ring Station 1
| T4
|-
! scope="row" | T9
| Ajouter ring rouge
| Ring Station 1 ou 2
| T5 et T2
|-
! scope="row" | T10
| Ajouter cap
| Cap Station 1 ou 2
| T6 et T1
|-
! scope="row" | T11
| Traiter le produit fini
| Delivery Station
| T12
|-
! scope="row" | T12
| Ramener à DS
| Robot 1, 2 ou 3
| T10
|}
[[Fichier:TachesProduitExemple.png|center]]
<center>Graphe montrant l'ordre des tâches à réaliser</center>
 

===Semaine 5===
Durant cette semaine, nous avons réfléchi sur le choix de structures pour nos données :
* Une '''liste principale''' de tous les produits demandés par la RefBox à un instant t. Cette liste principale a les caractéristiques suivantes :
** Une '''Priorité''' sera calculée pour chaque produit avec les paramètres suivants :
*** Nombre de points que peut apporter la production d'un produit de A à Z.
*** Une estimation du temps de production d'un produit.
***La date limite de livraison du produit demandé
** Une tâche est élue si sa priorité est supérieure ou égale à celle des autres tâches.
** Quand la RefBox demande un produit, une cellule sera ajoutée dans cette liste. Et de même, quand un produit sera terminé, on le supprimera de cette liste.
* Chaque produit de la liste principale va contenir une '''liste de tâches''' correspondantes à la production de ce produit. Cette liste de tâches a les caractéristiques suivantes :
** Chaque cellule correspond à une tâche de la production d'un produit. Une tâche contient différents champs :
***Intitulé de la tâche (par exemple ajouter une base)
***Produit concernée (par exemple P3)
***Priorité de la tâche (par exemple 20)
***Temps restant estimé de production (par exemple 180s)
** A chaque fois qu'une tâche est réalisée, elle sera supprimée de la liste de tâches. Ce qui veut dire, qu'on va devoir calculé à nouveau la priorité de chaque tâche de la liste principale.
** Afin de respecter les contraintes de précédence, on considérera que la tâche en tête de la liste de tâches peut être élue. Par exemple, on ne peut pas ajouter un Ring si on n'a pas de base.
 
L'exemple suivant simule le cas où la RefBox a demandé deux fois le produit P3 et deux fois le produit P2.
*Le produit P3 est réalisable en cinq tâches.Ce produit mettra plus de temps à être fabriqué mais rapportera plus de points.
*Le produit P2 est réalisable en quatre tâches.
 
[[Fichier:listedelistes.png|center]]
<center>Structure utilisée pour ranger les tâches à réaliser</center>
 
Différentes remarques utiles :
*Avant de commencer à réaliser n'importe quel produit, il faudra au préalable vérifier si on a libérer un espace de stockage pour plusieurs raisons :
**Les Cap Stations ayant initialement aucun cap en stock, il faut les ramener de l'étagère qui en contient initialement car un produit est dit fini lorsqu'il a à son sommet un cap.
**L'étagère ayant été débarrassée d'un cap, cela permet d'avoir un espace de stockage afin de déposer des produits finis en attente de livraison ou des produits non finis dont on voudrait mettre en pause la production.
*Il sera peut être des fois plus avantageux d'abandonner temporairement la production d'un produit :
**Il vaut mieux faire en sorte de terminer un seul produit sur deux dans les temps plutôt qu'aucun car du fait de la parallélisation de la fabrication des produits, on peut être surchargé de travail.
**Un produit livré durant le laps de temps demandé rapportera plus de points non négligeables.
*Un tableau sera nécessaire afin de savoir ce qu'il y a les espaces de stockage avec les champs suivants :
**Type de produit
**Liste de tâches restantes pour la fabrication du produit (pour un produit fini cette liste est donc nulle)
**Date de début de livraison
**Date de fin de livraison
**Emplacement de l'espace de stockage
 

===Semaine 6===
*Différentes fonctions et actions en pseudo code pour le générateur de tâches
**Fonction qui retourne un booléen suivant si un produit est en stock ou non
**Fonction qui retourne un booléen suivant si on doit livrer le produit à présent ou non
**Fonction qui retourne un booléen suivant si on a déjà ou non mis le travail à faire dans la structure contenant les tâches à réaliser
**Fonction qui retourne le nombre de points que rapporte un produit passé en paramètre
**Action qui rajoute les nouveaux ordres de production dans la liste de listes de tâches
**Action qui calcule le ratio pour chaque tâche
**Action qui supprime les tâches vides (ie celles qui sont terminées)
*Début de l'écriture en pseudo code de la fonction principale
 
*Discussion avec M. Vincent Coelen concernant l'avancement du projet :
**Validation par M. Coelen Vincent des portions de pseudo code déjà écrites
**Discussion autour de la mise en place d'un arrêt immédiat des robots à tout moment du jeu
**Amélioration concernant la robustesse de l'algorithme si un robot n'est plus en état de fonctionnement
 
*Différentes remarques utiles :
**Branche concernant le manager créée sur le [https://github.com/PyroTeam/robocup-pkg/ git] de l'équipe
**Discussion avec d'autres membres de l'équipe sur les services et les topics à envoyer et à recevoir aux nœuds du manager
 
===Semaine 7===

====Générateur de tâches====
Début du codage C++ :
*Création de différentes classes :
**La classe Tache (tache.h et tache.cpp)
**La classe Stockage (stockage.h et stockage.cpp)
**La classe RefBoxComm (refboxcomm.h)
*Création de différentes fonctions :
**Dans tache.h et tache.cpp :
***point_par_produit : retourne le nombre de points que vaut un produit
***dans_les_temps : retourne un booléen indiquant s'il est temps de ramener le produit
**Dans listetaches.h et listetaches.cpp :
***creation_liste_taches_prod : retourne une liste de taches à partir d'un produit passé en paramètre
***creation_liste_taches_act : retourne une liste de taches à partir d'un produit et d'une action passés en paramètres
**Dans tableaustockage.h :
***produit_en_stock : retourne un booléen indiquant si au moins un produit est en stock
**Dans travail.h et travail.cpp :
***deja_dans_travail : retourne un booléen indiquant si un ordre de la RefBox a déjà été pris en compte dans la structure contenant les tâches à réaliser
***max_ratio : retourne l'objet Tache qui a le plus grand ratio dans la structure contenant les tâches à réaliser
***rajout_dans_travail : rajoute un nouvel ordre de la RefBox dans la structure contenant les tâches à réaliser
***calcul_ratio : calcule le ratio de chaque premier de liste de la structure contenant les tâches à réaliser
 
Les codes sont disponibles sur le [https://github.com/PyroTeam/robocup-pkg/tree/feature/manager/generateur_taches git]
 
Des tests ont été réalisés afin de valider les fonctions crées en particulier les fonctions contenues dans travail.h et travail.cpp
 
Voici un petit aperçu de la console :
 
[[Fichier:Capture terminal gen taches 3.png|800px]]
 
Ainsi, les quatres fonctions fonctionnent parfaitement :
*deja_dans_travail indique bien que l'ordre de la RefBox n'a pas encore pris en compte
*max_ratio retourne bien la tâche dont le ratio est maximum
*rajout_dans_travail rajoute en fin de liste la liste de tâches pour la première création d'un produit P0 car un cap est disponible , puis il concatène une liste contenant en tête la tâche "Decapsuler" avec la liste de tâches pour la seconde création d'un produit P0. En effet, la RefBox a demandé deux fois le produit P0 et on ne peut créer un produit tant qu'un cap n'est pas disponible.
*calcul_ratio calcule le ratio de chaque première tâche en fonction du nombre de points et du temps, de plus, si c'est le bon moment pour déstocker un produit il passe cette tâche "Destocker" en priorité (liste 6), en outre, la création d'un produit (liste 1 et liste 7) est prioritaire à l'unique tâche "Decapsuler" (listes 2, 3, 4 et 5) .
 
'''Nous avons enfin reçu le sujet 2015 pour la compétition 2015, il est disponible [https://drive.google.com/file/d/0B39jN82rDE6qSk11YXFuQVljTlE/view?usp=sharing ici]'''
 
*Modification à réaliser :
**la fonction de création de liste de tâches
**l'ordonnancement (en partie)
**calcul de ratio de chaque tâche

===Semaine 8===
====Générateur de tâches====
*Création du service pour l'envoi des ordres pour l’exécuteur de tâches avec pour contenu:
**Numéro du robot
***1, 2 ou 3
**Ordre
***ChercherBase
***MettreCap
***ChercherCap
***MettreRing
***ChercherRing
***RamenerBaseRS
***Livrer
***Decapsuler
***Destocker
**Paramètre
***noir
***argent
***rouge
***orange
***jaune
***bleu
***vert
***gris
***DS
***stock
***aucun
**Id
***0, 1, 2, 3, 4, 5 ou 6
 
L'exécuteur de tâches du robot concerné doit envoyer en retour :
*un booléen qui indique si l'ordre est accepté ou non
*l'ordre pris en compte
*l'Id de retour
 
Création d'un nœud ROS pour le débogage à l'aide de ddd
 
Création d'un nœud ROS pour similer l'envoi et la réception des ordres
 
====Exécuteur de tâches====
L'exécuteur de taches est un noeud qui recevra des ordres de la part du générateur de taches et qui, à son tour, va envoyer des ordres aux autres noeuds.

Voici le schéma de communication entre les différents noeuds :

[[Fichier:wiki.jpg]]

===Semaine 9===
 
===Semaine 10===
 
===Semaine 11===
 
===Semaine 12===
 

== Fichiers Rendus ==

RoboCup 2015

2015-03-19T10:23:46Z

Shage-ch : /* Générateur de tâches */

__TOC__
 
[[Fichier:logoPyro_icone.png |center ]]
<center> Polytech RoboCup Team </center>

==Cahier des charges==
===Présentation générale du projet===

Lors de la compétition de l'Open German, prélude de la Robocup, il faudra mettre en place un système d'autonomisation de production à l'aide de Robotinos (robots mobiles de Festo ayant un système d'exploitation Linux). Comme dans toutes compétitions, le but est de gagner, par conséquent, il faudra faire en sorte de gagner un maximum de points.
C'est pourquoi il faut créer un manager à l'aide de ROS, c'est-à-dire un nœud ou ensemble de nœuds permettant de pouvoir recevoir les informations envoyées par les autres nœuds, de les traiter, tout cela afin de donner les ordres que doivent exécuter chaque Robotino. Ce manager devra également être capable d'optimiser le nombre de points à obtenir.

====Contexte====

La compétition de l'Open German se déroule en quatre phases spécifiques : phase de début-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des tâches spécifiques à remplir suivant les différentes phases. La RefereeBox est un système d'arbitrage auquel il est nécessaire d'envoyer périodiquement des données à tout moment du jeu et qui donne à chaque instant l'état du jeu ainsi que les produits demandés en priorité durant la phase de production.

====Objectif du projet====

*Assurer un maximum de points suivant les aléas du jeu (panne de machine, produits demandées, rupture de stock d'une matière première, …)
*Assurer la pérennité du projet (chaque année des candidats de Polytech Lille y participent)

====Description du projet====

Pour le projet, outre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes :
*Communication avec le nœud de la RefereeBox à tout moment du jeu
*Contrainte de robustesse (il ne faut qu'à un moment ou à un autre il n'y ait un blocage de tous les robots)
*Coopération entre les trois robots
 
[[Fichier:Interactions.png|vignette|left|upright=2|Interactions des nœuds avec le manager]]
 
Le manager devra interagir avec les différents nœuds suivants ayant chacun leurs rôles spécifiques :
*RefereeBox Comm : recevoir les données envoyées par la RefereeBox et envoyer des données suivant l'état du jeu à la RefereeBox
*Robots Comm : communiquer aux autres robots les informations concernant ce que chacun font
*Traitement des TAGs : lire les TAG
*Traitement des feux : lire l'état des colonnes de feu
*Pince de préhension : ouvrir et fermer la pince et renvoyer l'état de la pince
*Approche finale : s'adapter au banc de charge ou de décharge de produits
*Génération trajectoire : détermine une trajectoire pour aller au lieu (X,Y)
*Réalisation trajectoire : parcourir la trajectoire
*Localisation : savoir périodiquement (faible période) où se situe le robot
*Détection d'obstacle : détecter les obstacles fixes et mobiles
 

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

*Utilisation de trois robotinos
*Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce système travaille en utilisant des nœuds qui communiquent entre eux à l'aide de services (requête-réponse) et de topics (fichiers).
*Utilisation de différents langages : C++ ou Python (nœuds)
*Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS
 

===Etapes du projet===
*Prise en main de ROS et du C++
*Élaboration de l'algorithme du manager pour la phase d'exploration
*Élaboration de l'algorithme du manager pour la phase de production
**Coopération entre robots
**Répartition des tâches
*Codage du manager
*Tests et corrections
 

==Avancement du Projet==
===Semaine 1===
*Prise en main de ROS
*Réalisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials
*Réalisation de différents tutoriels C++
*Connaissance plus aiguë du sujet de l'Open German 2015
 
===Semaine 2===
*Réflexions autour de la structure du manager : deux nœuds
**Un nœud exécuteur de tâches
**Un nœud générateur de tâches
*Réflexions sur l'algorithme général du manager concernant la phase d'exploration
**Fonctionnement par zoning pour la répartition des tâches des trois robots
**Réflexion autour d'une alternative de répartition par distances les plus courtes entre machines
*Recherche de solutions pour la phase de production
**Documentation autour de la planification de tâches et la génération de tâche pour une équipe
**Recherche autour de la coopération et de l'allocation de rôles à des robots multi-tâches
*Organisation générale
**Structuration d'un échéancier numérique sous Asana
**Demande d'autorisation pour l'ouverture de la salle C002 auprès de M. Scrive
 

===Semaine 3===
Voilà un lien permettant d'accéder au sujet provisoire de la Robocup 2015 : [https://drive.google.com/file/d/0B39jN82rDE6qMG45cDN5Z0xiSVE/view?usp=sharing Sujet] 
*Réflexions au sujet des infos à communiquer au nœud AutresRobotsComm :
**Ce que le robotino fait
**Quelle machine le robotino est en train d'utiliser
[[Fichier:DataSWithRobotComm.jpg|center]]
 
*Réflexions au niveau de l'algorithme de la phase de production
**Proposition de le faire sous le principe de "Diviser pour mieux régner" (validé par M. Vincent Coelen)
***Diviser la tâche principale en sous-tâches, les sous-tâches en sous-sous-tâches et les sous-sous-tâches en sous-sous-sous-tâches élémentaires.
**Détermination des tâches à réaliser pour un exemple particulier
On souhaite produire, pendant une durée déterminée par la refBox, le produit suivant :
[[Fichier:ExempleProduitDemande.jpg|center]]
''Le produit est composé d’une base bleue, d’un ring rouge, d’un ring vert et d’un cap noir.''

'''Obtenir Base Bleue'''
->Aller à la Base Station
générateur trajectoire
exécuteur trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (dire à la Base Station quelle base est souhaitée et à quelle banc le robotino est)
approche finale
pince (prendre)

'''Obtenir ring rouge'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Obtenir ring vert'''
->Aller à une Ring Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
(Du coup la plus proche sera celle où on vient de faire le ring précédent)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Ring Station quelle base est souhaitée ( ici, la verte )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Finaliser produit'''
->Aller à une Cap Station
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la Cap Station quelle cap est souhaité ( ici, le noir )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel banc de livraison)
approche finale
pince (prendre)
->Déposer à la Delivery Station
générateur de trajectoire (vers la Delivery Station)
exécuteur de trajectoire
approche finale
pince (déposer)
 
*Organisation générale :
**Création de la page Facebook de l'équipe PYRO Team
 

===Semaine 4===
*Écriture des sous-tâches à réaliser
**Pseudo-codes de certaines sous-tâches réalisées
*Recherche d'ordonnancement optimisé pour la fabrication du produit
**Recherche d'algorithmes
**Visualisation du problème d'ordonnancement concernant l'exemple précédent (base bleue, ring vert, ring rouge, cap noir)
 
Ici, on a pris en plus en hypothèse le fait que la Ring Station (RS1) est capable de mettre des rings rouges ou verts et que la RS2 est capable de de mettre des rings bleus et rouges. Afin de mieux appréhender le problème, nous nous sommes attachés à effectuer un tableau récapitulant les tâches à effectuer pour le produit exemple et à réaliser un graphe mettant en avant les contraintes de précédence de chaque tâche.
 

{| class="wikitable" style="text-align:center; width:80%;"

|-
|
! scope="col" | Tâches
! scope="col" | Ressources utilisées
! scope="col" | Contraintes de précédence
|-
! scope="row" | T0
| Ramener à CS base avec cap
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T1
| Décapsuler
| Cap Station 1 ou 2
| T0
|-
! scope="row" | T2
| Ramener base supplémentaires à RS
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T3
| Chercher base bleue
| Robot 1, 2 ou 3
| Aucune
|-
! scope="row" | T4
| Ramener à RS pour ring vert
| Robot 1, 2 ou 3
| T7
|-
! scope="row" | T5
| Ramener à RS pour ring rouge
| Robot 1, 2 ou 3
| T8
|-
! scope="row" | T6
| Ramener à CS pour cap
| Robot 1, 2 ou 3
| T9
|-
! scope="row" | T7
| Ramener Base
| Base Station
| T3
|-
! scope="row" | T8
| Ajouter ring vert
| Ring Station 1
| T4
|-
! scope="row" | T9
| Ajouter ring rouge
| Ring Station 1 ou 2
| T5 et T2
|-
! scope="row" | T10
| Ajouter cap
| Cap Station 1 ou 2
| T6 et T1
|-
! scope="row" | T11
| Traiter le produit fini
| Delivery Station
| T12
|-
! scope="row" | T12
| Ramener à DS
| Robot 1, 2 ou 3
| T10
|}
[[Fichier:TachesProduitExemple.png|center]]
<center>Graphe montrant l'ordre des tâches à réaliser</center>
 

===Semaine 5===
Durant cette semaine, nous avons réfléchi sur le choix de structures pour nos données :
* Une '''liste principale''' de tous les produits demandés par la RefBox à un instant t. Cette liste principale a les caractéristiques suivantes :
** Une '''Priorité''' sera calculée pour chaque produit avec les paramètres suivants :
*** Nombre de points que peut apporter la production d'un produit de A à Z.
*** Une estimation du temps de production d'un produit.
***La date limite de livraison du produit demandé
** Une tâche est élue si sa priorité est supérieure ou égale à celle des autres tâches.
** Quand la RefBox demande un produit, une cellule sera ajoutée dans cette liste. Et de même, quand un produit sera terminé, on le supprimera de cette liste.
* Chaque produit de la liste principale va contenir une '''liste de tâches''' correspondantes à la production de ce produit. Cette liste de tâches a les caractéristiques suivantes :
** Chaque cellule correspond à une tâche de la production d'un produit. Une tâche contient différents champs :
***Intitulé de la tâche (par exemple ajouter une base)
***Produit concernée (par exemple P3)
***Priorité de la tâche (par exemple 20)
***Temps restant estimé de production (par exemple 180s)
** A chaque fois qu'une tâche est réalisée, elle sera supprimée de la liste de tâches. Ce qui veut dire, qu'on va devoir calculé à nouveau la priorité de chaque tâche de la liste principale.
** Afin de respecter les contraintes de précédence, on considérera que la tâche en tête de la liste de tâches peut être élue. Par exemple, on ne peut pas ajouter un Ring si on n'a pas de base.
 
L'exemple suivant simule le cas où la RefBox a demandé deux fois le produit P3 et deux fois le produit P2.
*Le produit P3 est réalisable en cinq tâches.Ce produit mettra plus de temps à être fabriqué mais rapportera plus de points.
*Le produit P2 est réalisable en quatre tâches.
 
[[Fichier:listedelistes.png|center]]
<center>Structure utilisée pour ranger les tâches à réaliser</center>
 
Différentes remarques utiles :
*Avant de commencer à réaliser n'importe quel produit, il faudra au préalable vérifier si on a libérer un espace de stockage pour plusieurs raisons :
**Les Cap Stations ayant initialement aucun cap en stock, il faut les ramener de l'étagère qui en contient initialement car un produit est dit fini lorsqu'il a à son sommet un cap.
**L'étagère ayant été débarrassée d'un cap, cela permet d'avoir un espace de stockage afin de déposer des produits finis en attente de livraison ou des produits non finis dont on voudrait mettre en pause la production.
*Il sera peut être des fois plus avantageux d'abandonner temporairement la production d'un produit :
**Il vaut mieux faire en sorte de terminer un seul produit sur deux dans les temps plutôt qu'aucun car du fait de la parallélisation de la fabrication des produits, on peut être surchargé de travail.
**Un produit livré durant le laps de temps demandé rapportera plus de points non négligeables.
*Un tableau sera nécessaire afin de savoir ce qu'il y a les espaces de stockage avec les champs suivants :
**Type de produit
**Liste de tâches restantes pour la fabrication du produit (pour un produit fini cette liste est donc nulle)
**Date de début de livraison
**Date de fin de livraison
**Emplacement de l'espace de stockage
 

===Semaine 6===
*Différentes fonctions et actions en pseudo code pour le générateur de tâches
**Fonction qui retourne un booléen suivant si un produit est en stock ou non
**Fonction qui retourne un booléen suivant si on doit livrer le produit à présent ou non
**Fonction qui retourne un booléen suivant si on a déjà ou non mis le travail à faire dans la structure contenant les tâches à réaliser
**Fonction qui retourne le nombre de points que rapporte un produit passé en paramètre
**Action qui rajoute les nouveaux ordres de production dans la liste de listes de tâches
**Action qui calcule le ratio pour chaque tâche
**Action qui supprime les tâches vides (ie celles qui sont terminées)
*Début de l'écriture en pseudo code de la fonction principale
 
*Discussion avec M. Vincent Coelen concernant l'avancement du projet :
**Validation par M. Coelen Vincent des portions de pseudo code déjà écrites
**Discussion autour de la mise en place d'un arrêt immédiat des robots à tout moment du jeu
**Amélioration concernant la robustesse de l'algorithme si un robot n'est plus en état de fonctionnement
 
*Différentes remarques utiles :
**Branche concernant le manager créée sur le [https://github.com/PyroTeam/robocup-pkg/ git] de l'équipe
**Discussion avec d'autres membres de l'équipe sur les services et les topics à envoyer et à recevoir aux nœuds du manager
 
===Semaine 7===

====Générateur de tâches====
Début du codage C++ :
*Création de différentes classes :
**La classe Tache (tache.h et tache.cpp)
**La classe Stockage (stockage.h et stockage.cpp)
**La classe RefBoxComm (refboxcomm.h)
*Création de différentes fonctions :
**Dans tache.h et tache.cpp :
***point_par_produit : retourne le nombre de points que vaut un produit
***dans_les_temps : retourne un booléen indiquant s'il est temps de ramener le produit
**Dans listetaches.h et listetaches.cpp :
***creation_liste_taches_prod : retourne une liste de taches à partir d'un produit passé en paramètre
***creation_liste_taches_act : retourne une liste de taches à partir d'un produit et d'une action passés en paramètres
**Dans tableaustockage.h :
***produit_en_stock : retourne un booléen indiquant si au moins un produit est en stock
**Dans travail.h et travail.cpp :
***deja_dans_travail : retourne un booléen indiquant si un ordre de la RefBox a déjà été pris en compte dans la structure contenant les tâches à réaliser
***max_ratio : retourne l'objet Tache qui a le plus grand ratio dans la structure contenant les tâches à réaliser
***rajout_dans_travail : rajoute un nouvel ordre de la RefBox dans la structure contenant les tâches à réaliser
***calcul_ratio : calcule le ratio de chaque premier de liste de la structure contenant les tâches à réaliser
 
Les codes sont disponibles sur le [https://github.com/PyroTeam/robocup-pkg/tree/feature/manager/generateur_taches git]
 
Des tests ont été réalisés afin de valider les fonctions crées en particulier les fonctions contenues dans travail.h et travail.cpp
 
Voici un petit aperçu de la console :
 
[[Fichier:Capture terminal gen taches 3.png|800px]]
 
Ainsi, les quatres fonctions fonctionnent parfaitement :
*deja_dans_travail indique bien que l'ordre de la RefBox n'a pas encore pris en compte
*max_ratio retourne bien la tâche dont le ratio est maximum
*rajout_dans_travail rajoute en fin de liste la liste de tâches pour la première création d'un produit P0 car un cap est disponible , puis il concatène une liste contenant en tête la tâche "Decapsuler" avec la liste de tâches pour la seconde création d'un produit P0. En effet, la RefBox a demandé deux fois le produit P0 et on ne peut créer un produit tant qu'un cap n'est pas disponible.
*calcul_ratio calcule le ratio de chaque première tâche en fonction du nombre de points et du temps, de plus, si c'est le bon moment pour déstocker un produit il passe cette tâche "Destocker" en priorité (liste 6), en outre, la création d'un produit (liste 1 et liste 7) est prioritaire à l'unique tâche "Decapsuler" (listes 2, 3, 4 et 5) .
 
'''Nous avons enfin reçu le sujet 2015 pour la compétition 2015, il est disponible [https://drive.google.com/file/d/0B39jN82rDE6qSk11YXFuQVljTlE/view?usp=sharing ici]'''
 
*Modification à réaliser :
**la fonction de création de liste de tâches
**l'ordonnancement (en partie)
**calcul de ratio de chaque tâche

===Semaine 8===
[[Fichier:[[Fichier:Exemple.jpg]]]]====Générateur de tâches====
*Création du service pour l'envoi des ordres pour l’exécuteur de tâches avec pour contenu:
**Numéro du robot
***1, 2 ou 3
**Ordre
***ChercherBase
***MettreCap
***ChercherCap
***MettreRing
***ChercherRing
***RamenerBaseRS
***Livrer
***Decapsuler
***Destocker
**Paramètre
***noir
***argent
***rouge
***orange
***jaune
***bleu
***vert
***gris
***DS
***stock
***aucun
**Id
***0, 1, 2, 3, 4, 5 ou 6
 
L'exécuteur de tâches du robot concerné doit envoyer en retour :
*un booléen qui indique si l'ordre est accepté ou non
*l'ordre pris en compte
*l'Id de retour
 
Création d'un nœud ROS pour le débogage à l'aide de ddd
 
Création d'un nœud ROS pour similer l'envoi et la réception des ordres
 
====Exécuteur de tâches====
L'exécuteur de taches est un noeud qui recevra des ordres de la part du générateur de taches et qui, à son tour, va envoyer des ordres aux autres noeuds.

Voici le schéma de communication entre les différents noeuds :

[[Fichier:wiki.jpg]]

===Semaine 9===
 
===Semaine 10===
 
===Semaine 11===
 
===Semaine 12===
 

== Fichiers Rendus ==

RoboCup 2015

2015-02-25T16:31:33Z

Shage-ch : /* Semaine 5 */

RoboCup 2015

2015-02-12T08:47:51Z

Shage-ch : /* Semaine 3 */

RoboCup 2015

2015-02-11T15:18:20Z

Shage-ch :

RoboCup 2015

2015-02-11T15:17:44Z

Shage-ch :

__TOC__
 
[[Fichier:logoPyro_icone.png |center ]]
 Polytech RoboCup Team 

==Cahier des charges==
===Présentation générale du projet===

Lors de la compétition de l'Open German, prélude de la Robocup, il faudra mettre en place un système d'autonomisation de production à l'aide de Robotinos (robots mobiles de Festo ayant un système d'exploitation Linux). Comme dans toutes compétitions, le but est de gagner, par conséquent, il faudra faire en sorte de gagner un maximum de points.
C'est pourquoi il faut créer un manager à l'aide de ROS, c'est-à-dire un nœud ou ensemble de nœuds permettant de pouvoir recevoir les informations envoyées par les autres nœuds, de les traiter, tout cela afin de donner les ordres que doivent exécuter chaque Robotino. Ce manager devra également être capable d'optimiser le nombre de points à obtenir.

====Contexte====

La compétition de l'Open German se déroule en quatre phases spécifiques : phase de début-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des tâches spécifiques à remplir suivant les différentes phases. La RefereeBox est un système d'arbitrage auquel il est nécessaire d'envoyer périodiquement des données à tout moment du jeu et qui donne à chaque instant l'état du jeu ainsi que les produits demandés en priorité durant la phase de production.

====Objectif du projet====

*Assurer un maximum de points suivant les aléas du jeu (panne de machine, produits demandées, rupture de stock d'une matière première, …)
*Assurer la pérennité du projet (chaque année des candidats de Polytech Lille y participent)

====Description du projet====

Pour le projet, autre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes :
*Communication avec le nœud de la RefereeBox à tout moment du jeu
*Contrainte de robustesse (il ne faut qu'à un moment ou à un autre il n'y ait un blocage de tous les robots)
*Coopération entre les trois robots
 
[[Fichier:Interactions.png|vignette|left|upright=2|Interactions des nœuds avec le manager]]
 
Le manager devra interagir avec les différents nœuds suivants ayant chacun leurs rôles spécifiques :
*RefereeBox Comm : recevoir les données envoyées par la RefereeBox et envoyer des données suivant l'état du jeu à la RefereeBox
*Robots Comm : communiquer aux autres robots les informations concernant ce que chacun font
*Traitement des TAGs : lire les TAG
*Traitement des feux : lire l'état des colonnes de feu
*Pince de préhension : ouvrir et fermer la pince et renvoyer l'état de la pince
*Approche finale : s'adapter au banc de charge ou de décharge de produits
*Génération trajectoire : détermine une trajectoire pour aller au lieu (X,Y)
*Réalisation trajectoire : parcourir la trajectoire
*Localisation : savoir périodiquement (faible période) où se situe le robot
*Détection d'obstacle : détecter les obstacles fixes et mobiles
 

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

*Utilisation de trois robotinos
*Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce système travaille en utilisant des nœuds qui communiquent entre eux à l'aide de services (requête-réponse) et de topics (fichiers).
*Utilisation de différents langages : C++ ou Python (nœuds)
*Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS
 

===Etapes du projet===
*Prise en main de ROS et du C++
*Élaboration de l'algorithme du manager pour la phase d'exploration
*Élaboration de l'algorithme du manager pour la phase de production
**Coopération entre robots
**Répartition des tâches
*Codage du manager
*Tests et corrections
 

==Avancement du Projet==
===Semaine 1===
*Prise en main de ROS
*Réalisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials
*Réalisation de différents tutoriels C++
*Connaissance plus aiguë du sujet de l'Open German 2015
 
===Semaine 2===
*Réflexions autour de la structure du manager : deux nœuds
**Un nœud exécuteur de tâches
**Un nœud générateur de tâches
*Réflexions sur l'algorithme général du manager concernant la phase d'exploration
**Fonctionnement par zoning pour la répartition des tâches des trois robots
**Réflexion autour d'une alternative de répartition par distances les plus courtes entre machines
*Recherche de solutions pour la phase de production
**Documentation autour de la planification de tâches et la génération de tâche pour une équipe
**Recherche autour de la coopération et de l'allocation de rôles à des robots multi-tâches
*Organisation générale
**Structuration d'un échéancier numérique sous Asana
**Demande d'autorisation pour l'ouverture de la salle C002 auprès de M. Scrive
 

===Semaine 3===
*Réflexions au niveau de l'algorithme de la phase de prodution
**Proposition de le faire sous le principe de "Diviser pour mieux régner" (validé par M. Vincent Coelen)
**Détermination des tâches à réaliser pour un exemple particulier
On souhaite produire, pendant une durée déterminée par la refBox, le produit suivant :
[[Fichier:ExempleProduitDemande.jpg|center]]
''Le produit est composé d’une base bleue, d’un ring rouge, d’un ring vert et d’un cap noir.''

'''Obtenir Base Bleue'''
->Aller à la BS
générateur trajectoire
exécuteur trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
dire à la BS quelle base est souhaitée et à quelle banc le robotino est
approche finale
pince (prendre)

'''Obtenir ring rouge'''
->Aller à une RS
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Obtenir ring vert'''
->Aller à une RS
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
(Du coup la plus proche sera celle où on vient de faire le ring précédent)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la RS quelle base est souhaitée ( ici, la verte )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel produit et quel banc de livraison)
approche finale
pince (déposer)
pince (prendre)

'''Finaliser produit'''
->Aller à une CS
Laquelle ? laquelle est inoccupée ? la plus proche ? (RobotsComm)
générateur de trajectoire
exécuteur de trajectoire
->Vérifier si machine OK
dire à la CS quelle cap est souhaité ( ici, le noir )
approche finale
traitement feux
->Prendre produit
RefBoxComm (pour dire quel banc de livraison)
approche finale
pince (prendre)
->Déposer à la DS
générateur de trajectoire (vers la DS)
exécuteur de trajectoire
approche finale
pince (déposer)
 

===Semaine 4===
 
===Semaine 5===
 
===Semaine 6===
 

== Fichiers Rendus ==