Résultat de l’API de MediaWiki
Voici la représentation HTML du format JSON. HTML est utile pour le débogage, mais inapproprié pour être utilisé dans une application.
Spécifiez le paramètre format pour modifier le format de sortie. Pour voir la représentation non HTML du format JSON, mettez format=json.
Voyez la documentation complète, ou l’aide de l’API pour plus d’information.
{
"batchcomplete": "",
"continue": {
"gapcontinue": "RoboCup_2015_-_Pyro_Team",
"continue": "gapcontinue||"
},
"query": {
"pages": {
"1024": {
"pageid": 1024,
"ns": 0,
"title": "Reconfiguration d'un FPGA",
"revisions": [
{
"contentformat": "text/x-wiki",
"contentmodel": "wikitext",
"*": "<include nopre noesc src=\"/home/pedago/pimasc/include/video-ReconfigurationFPGA-iframe.html\" />\n__TOC__\n<br style=\"clear: both;\">\nWiki du projet de reconfiguration d'un FPGA.\n\nLe wiki est class\u00e9 par th\u00e8me mais chronologique : La prise en main de la Beaglebone Black a commenc\u00e9 avant la carte de test, etc.\n\n= Cahier des charges =\n\nProjet r\u00e9alis\u00e9 par ''Simon Malthieu''.\n\nTuteurs : ''Alexandre Bo\u00e9'', ''Thomas Vantroy'', ''Micka\u00ebl Coronado''.\n\nSuite \u00e0 la r\u00e9union avec Micka\u00ebl Coronado, g\u00e9rant de Inodesign, le cahier des charges suivant a \u00e9t\u00e9 \u00e9tabli : \n\n\n== Description du projet ==\n\nLe but du projet est de permettre une mise \u00e0 jour ais\u00e9 d'un FPGA. Il y a deux mani\u00e8res de programmer un FPGA. Soit directement via une liaison J-TAG. Dans ce cas-ci, le FPGA doit \u00eatre reprogramm\u00e9 \u00e0 chaque mise sous tension. Il existe cependant une autre solution, qui consiste \u00e0 associer une m\u00e9moire de type EEPROM au FPGA. Ainsi, il suffit d'\u00e9crire le bitstream dans la m\u00e9moire, et le FPGA va lire l'EEPROM \u00e0 chaque mise sous tension. \n\nLes deux mani\u00e8res devront \u00eatre d\u00e9velopp\u00e9es. (obsol\u00e8te au 02/04)\n\nL'interface devra aussi pouvoir v\u00e9rifier l'int\u00e9grit\u00e9 des donn\u00e9es, afin d'\u00e9viter un chargement de bitstream corrompu.\n\nL'autre partie du projet consiste \u00e0 g\u00e9rer la partie r\u00e9cup\u00e9ration du bitstream par FTP, ou mieux par SFTP. L'ensemble devra donc \u00eatre autonome, de la r\u00e9cup\u00e9ration du bitstream \u00e0 programmation du FPGA. (obsol\u00e8te au 02/04)\n\n'''EDIT 02/04''' : Suite \u00e0 une r\u00e9union avec Mickael Coronado \u00e0 propos de l'avancement de projet, il a \u00e9t\u00e9 d\u00e9cid\u00e9 d'abandonner la transmission par J-TAG et de se concentrer sur une interface web permettant l'upload de bitstream et le contr\u00f4le du programme.\n\n== Objectifs du projet au 02/04 ==\n\n* Concevoir un programme, ex\u00e9cut\u00e9 par un ordinateur embarqu\u00e9 de type Beaglebone Black, permettant d'\u00e9crire dans une EEPROM de type M25P80 un fichier bitstream de FPGA\n* Le programme devra aussi pouvoir v\u00e9rifier l'int\u00e9grit\u00e9 des donn\u00e9es \u00e9crites dans la m\u00e9moire\n* D\u00e9velopper une interface web permettant de contr\u00f4ler le programme : Elle doit permettre de t\u00e9l\u00e9verser un fichier sur l'ordinateur et ex\u00e9cuter le programme d'\u00e9criture avec ce fichier\n\n== Sp\u00e9cifications techniques ==\n\n'''Materiel'''\n\nLa plateforme choisie pour piloter l'EEPROM est la Beaglebone black. C'est un micro-ordinateur miniature embarquant un processeur Texas Instrument, mod\u00e8le Sitara XAM3359AZCZ100 Cortex A8 ARM cadenc\u00e9 \u00e0 1 GHz. Une exemplaire de cette plateforme est pr\u00eat\u00e9 par Micka\u00ebl Coronado pour les besoins du projet.\nCet ordinateur est adapt\u00e9 au prototypage car, contrairement au Raspberry Pi, son processeur peut \u00eatre achet\u00e9 s\u00e9par\u00e9ment et plac\u00e9 sur une carte personnalis\u00e9e. C'est ce que compte faire Mr Coronado pour le futur du projet.\n\n[[Fichier:beaglebone.jpg | centre | Image du Beaglebone Black]]\n\nL'EEPROM choisie est la M25P80 de chez Micron, notamment parce qu'elle est adapt\u00e9 aux FPGA de la marque Xilinx. Le FPGA conna\u00eet les commandes de lecture de cette EEPROM. Sa taille est 1 Mo, et elle poss\u00e8de une interface SPI qui servira \u00e0 communiquer avec la BBB.\n\n'''Logiciel'''\n\nUn syst\u00e8me d'exploitation est inclus de base dans la eMMC de la beaglebone. Il faudra v\u00e9rifier si cela suffit pour d\u00e9velopper le programme, ou s'il faut installer un autre OS. \n\nLe langage choisi pour le programme est le C, principalement parce que c'est le langage que je ma\u00eetrise le mieux. Il est aussi tout \u00e0 fait adapt\u00e9 \u00e0 la programmation embarqu\u00e9e\n\nL'interface web sera en HTML et PHP, l\u00e0 aussi parce que le PHP est le langage serveur que je connais le mieux.\n\n== \u00c9tapes de la premi\u00e8re partie : Ecriture dans l'EEPROM ==\n\n* Prise en main de la Beaglebone black (OS, interface de d\u00e9veloppement, ...)\n* Conception d'une carte de test avec une EEPROM et une interface SPI pour tester le programme. La cr\u00e9ation de la carte est effectu\u00e9 par Inodesign gr\u00e2ce \u00e0 un sch\u00e9ma qu'il faudra dessiner, \u00e0 la main ou gr\u00e2ce \u00e0 un logiciel comme Altium.\n* Lire les registres de l'EEPROM : Le d\u00e9but de l'EEPROM est constitu\u00e9 de registres contenant des informations diverses comme sa taille, sa date de fabrication ou son constructeur. Le but est de pouvoir lire ces registres depuis la beaglebone.\n* \u00c9crire dans l'EEPROM via SPI\n* \u00c9crire un fichier dans l'EEPROM\n* Lire les donn\u00e9es \u00e9crites et v\u00e9rifier leur int\u00e9grit\u00e9\n\n== Etapes de la seconde partie : Interface Web ==\n\n* Installation et configuration d'un serveur web sur le BBB\n* \u00c9criture de la page web en HTML\n* \u00c9criture de la page de traitement en PHP\n\n= Prise en main de la BBB =\n\n== Liens hypertextes destin\u00e9s \u00e0 la prise en main ==\n\n* [http://www.angstrom-distribution.org/ Site internet de la distribution linux Angstrom]\n* [http://www.linux.com/learn/tutorials/725368-getting-started-with-the-beaglebone-black-a-1ghz-arm-linux-machine-for-45 Tutoriel de prise en main de la BBB (eng)]\n* [http://elinux.org/RPi_Easy_SD_Card_Setup#Using_the_Linux_command_line Flashage d'une carte SD en ligne de commande]\n* [http://beagleboard.org/latest-images Derni\u00e8res versions de Angstrom pour BBB]\n\n== Mise \u00e0 jour de la distribution ==\n\nLa BBB poss\u00e8de une m\u00e9moire interne : une eMMC de 2Go, ce qui est amplement suffisant pour le projet. D'office, une distribution linux sp\u00e9cialement cr\u00e9\u00e9e pour la programmation embarqu\u00e9e est install\u00e9e sur la eMMC : Angstrom distribution. \nAfin d'avoir le dernier noyau et les derni\u00e8res optimisations, une mise \u00e0 jour est n\u00e9cessaire.\n\nLes \u00e9tapes pour mettre \u00e0 jour la BBB sont : \n* D\u00e9compresser l'image t\u00e9l\u00e9charg\u00e9 sur le site de la [http://beagleboard.org/latest-images beagleboard]\n* Flasher une carte SD (> 4Go) avec l'image. Ligne de commande utilis\u00e9e :\n<code> sudo dd bs=4M if=~/Documents/Projet/BBB-eMMC-flasher-2013.09.04.img of=/dev/sdc </code>\n''bs'' indique le nombre d'octets maximum \u00e0 transmettre en m\u00eame temps. \n* D\u00e9brancher la BBB et ins\u00e9rer la carte SD \u00e0 l'interieur.\n* Rester appuy\u00e9 sur le bouton BOOT (le plus pr\u00eat de la carte SD) et alimenter la BBB. Le flashage devrait commencer. Cela peut durer jusqu'\u00e0 45 minutes. Une fois termin\u00e9, les LEDs \u00e0 droite du port Ethernet restent allum\u00e9es. Il suffit alors de d\u00e9brancher la BBB puis de la rebrancher EN AYANT RETIR\u00c9 LA CARTE SD ! Sinon le flashage recommence.\n\n== Acc\u00e9der \u00e0 la BBB==\n\nUne interface r\u00e9seau est simul\u00e9 lorsqu'on branche la BBB par USB sur un ordinateur. Sous Ubuntu 13.10, aucun driver sp\u00e9cifique n'est n\u00e9cessaire, l'interface est imm\u00e9diatement reconnue. Une interface web est disponible avec une page de pr\u00e9sentation \u00e0 l'adresse 192.168.7.2 . L'IDE [https://c9.io/ cloud 9] en web-application est aussi pr\u00e9install\u00e9 et disponible sur le port 3000. Malgr\u00e9 de riches fonctionnalit\u00e9s, cloud 9 ne semble pas convenir au d\u00e9veloppement en langage C : Pas de debugeur ni de compilateur disponible d'apr\u00e8s le site internet.\n\nLa meilleure solution reste SSH. On y acc\u00e8de par la commande <code> ssh root@beaglebone.local </code>. Aucun mot de passe par d\u00e9faut. Gcc et Vim sont d\u00e9j\u00e0 install\u00e9s.\n\nIl est aussi possible de s'y connecter via minicom directement (9600 bauds, sans contr\u00f4le de flux sur /dev/ttyACM0)\n\n\n\n=R\u00e9alisation de la carte de test=\n\nL'EEPROM utilis\u00e9 est une M25P80 de chez Micron. Il faut les empreintes de ces composants au format Altium pour cr\u00e9er le PCB. Elles sont disponibles sur le site Altium apr\u00e8s cr\u00e9ation d'un compte. PCB cr\u00e9\u00e9, mais la carte ne peut pas \u00eatre r\u00e9alis\u00e9e \u00e0 l'\u00e9cole pour l'instant, car les machines permettant de cr\u00e9er les circuits sont hors-services.\n\nEn attendant, Mr Thierry Flamen poss\u00e8de des circuits pr\u00e9-imprim\u00e9 sp\u00e9cialement pour des petits composants CMS comme cette EEPROM. Les trous sont perc\u00e9s et le composant est soud\u00e9 dessus.\n\n[[Fichier:carte_test.jpg | centre | vignette | Carte de test]]\n\n[[Fichier:montage.jpg | centre | vignette | Montage avec la Beaglebone Black ]]\n\n= Premi\u00e8re partie : Lecture et \u00e9criture de l'EEPROM =\n\n==Liens utiles==\n* [http://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&sqi=2&ved=0CDoQFjAA&url=http%3A%2F%2Fwww.micron.com%2F~%2Fmedia%2FDocuments%2FProducts%2FData%2520Sheet%2FNOR%2520Flash%2FSerial%2520NOR%2FM25P%2FM25P80.pdf&ei=co8YU_6QEdSu7AaDoICgCQ&usg=AFQjCNEtGo583vxY52sXq8rMf9bREKpRTg&sig2=ddWnZ4caiiuh0_O2DUKhkg&bvm=bv.62577051,d.bGE&cad=rja Datasheet de la M25P80]\n*[https://www.linux.com/learn/tutorials/746860-how-to-access-chips-over-the-spi-on-beaglebone-black Tutoriel en anglais sur SPI, EEPROM et BBB]\n*[http://fr.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus Page wikipedia sur le SPI]\n*[https://www.kernel.org/doc/Documentation/spi/spidev Doc du noyau sur SPI]\n*[https://github.com/jadonk/validation-scripts/tree/master/test-capemgr Tutoriel sur les pins sous linux]\n\n==Interface SPI de la BBB==\n\nAfin de pouvoir \u00e9crire et lire avec read() et write() en C directement, il faut activer le(s) p\u00e9riph\u00e9rique(s) spidev*. Une s\u00e9rie de commandes permet de les cr\u00e9er. Tout est expliqu\u00e9 [http://elinux.org/BeagleBone_Black_Enable_SPIDEV ici].\n\nPlusieurs fichiers de test sont disponible sur internet : [https://raw.github.com/torvalds/linux/master/Documentation/spi/spidev_test.c ici] et [https://www.kernel.org/doc/Documentation/spi/spidev_fdx.c l\u00e0].\n\nProbl\u00e8me du lundi 17/02 : spidev1.0 est effectivement cr\u00e9\u00e9, mais il dispara\u00eet \u00e0 chaque red\u00e9marrage.\n19/02 : r\u00e9solu, le fichier uDev.txt \u00e9tait mal modifi\u00e9 (toutes les commandes doivent \u00eatre sur la m\u00eame ligne).\n\n== Communication avec l'EEPROM en C ==\n\nBranchement de la m\u00e9moire avec des fils directement sur la beaglebone black. Les trous destin\u00e9s \u00e0 l'interface SPI sont disponibles [http://www.elinux.org/Beagleboard:Cape_Expansion_Headers ici].\n\nLe tutoriel trouv\u00e9 sur internet fourni des exemples de programmes en C utilisant l'interface SPI : spidev_fdx.c et spidev.c.\n\ntentative de lecture directement avec les fonctions fournies par spidev_fdx.c, mais rien n'est lu. D'apr\u00e8s la datasheet, il faut envoyer des commandes avant de pouvoir lire. Par exemple, pour lire le nom du fabriquant il faut envoyer la commande READ DESCRIPTION dont le code de commande est 69h.\n\n''' 12/03 '''En s'inspirant des fonctions de spidev_fdx.c, \u00e9criture d'un programme de lecture de la description de l'EEPROM. Mais aucune valeur n'est re\u00e7ue. Il faut v\u00e9rifier les signaux SPI g\u00e9n\u00e9r\u00e9s par la BBB, ainsi que les signaux envoy\u00e9s par l'EEPROM gr\u00e2ce \u00e0 un oscilloscope.\n\nL'analyseur logique confirme que le programme fonctionne. Les trames correspondent au comportement voulu. V\u00e9rification des pistes de cuivres de la carte, recherche de court-circuit. Rien de concluant. Un amp\u00e8rem\u00e8tre est branch\u00e9 en s\u00e9rie avec l'alimentation pour v\u00e9rifier que l'EEPROM fonctionne et n'a pas \u00e9t\u00e9 endommag\u00e9e lors de la soudure des broches. Observation d'une augmentation de la consommation lors d'une tentative d'\u00e9criture. Cette consommation est sup\u00e9rieure \u00e0 la consommation de repos de la m\u00e9moire (d'apr\u00e8s la datasheet), mais inf\u00e9rieure \u00e0 la consommation en lecture ou en \u00e9criture. Le probl\u00e8me vient donc du programme et non de la carte.\n\n'''19/03''' : Finalement, apr\u00e8s avoir lu en d\u00e9tail la datasheet, l'EEPROM \u00e9tait en DEEP DOWN STATE et n'acceptait aucune commande autre que celle de r\u00e9veil. Apr\u00e8s l'envoi de celle-ci, les autres commandes de lecture fonctionnent et renvoient bien des donn\u00e9es .\n\nLa commande READ DESCRIPTION renvoie bien les donn\u00e9es concernant le fabricant et la taille de la m\u00e9moire. Donn\u00e9es v\u00e9rifi\u00e9es par la datasheet.\n\n'''26/03''' : \u00c9criture d'une fonction de lecture. Afin de lire des donn\u00e9es, il faut envoyer la commande READ DATA puis une addresse sur 3 octets. Tant que l'EEPROM est s\u00e9lectionn\u00e9e (Chip select \u00e0 0), l'EEPROM renvoie les donn\u00e9es contenues \u00e0 partir de l'adresse transmise. Pour l'instant, l'EEPROM est vide et ne transmet que des 1, car les informations \u00e9crites sont des 0. Par exemple la commande BULK ERASE met tous les bits de l'EEPROM \u00e0 1.\n\n'''30-31/03''' : J'\u00e9cris diff\u00e9rentes fonctions pour lire le registre de description, lire et \u00e9crire dans le registre d'\u00e9tat et lire et \u00e9crire dans la m\u00e9moire. La fonction d'\u00e9criture ne semblait ne pas fonctionner, puisque la lecture de la m\u00e9moire ne renvoyait que des 1. Or apr\u00e8s analyse \u00e0 l'analyseur logique, le probl\u00e8me venait de la fonction de lecture, qui envoyait mal la commande de lecture. Le programme envoyait l'octet de commande et les 3 octets d'adresse sous la forme d'un unsigned long. Lors du transfert SPI, le premier octet envoy\u00e9 \u00e9tait le 3\u00e8me octet d'adresse, au lieu d'\u00eatre la commande. La s\u00e9paration en plusieurs unsigned char (1 octet) a r\u00e9solu le probl\u00e8me.\n\n'''Depuis le 31/03 et jusqu'au 14/04''' : Apr\u00e8s avoir pass\u00e9 du temps sur l'interface web, je me rends compte que mes fonctions de lecture et d'\u00e9criture ne fonctionnent plus. Je passe du temps \u00e0 analyser mes trames SPI \u00e0 l'analyseur logique, sans trouver pourquoi je n'arrive pas \u00e0 lire ce que j'\u00e9cris. Je ne sais pas si c'est la lecture qui ne fonctionne pas, ou l'\u00e9criture, ce qui ne facilite pas la t\u00e2che. Apr\u00e8s des heures de recherches, je me rends compte de plusieurs chose : Je n'ai pas bien saisi le fonctionnement d'une EEPROM. Comme son nom l'indique, c'est une READ-ONLY memory. C'est \u00e0 dire qu'une fois \u00e9crite, elle ne peut \u00eatre r\u00e9-\u00e9crite sans \u00eatre effac\u00e9e gr\u00e2ce \u00e0 un courant \u00e9lectrique. Concr\u00e8tement, la commande PAGE PROGRAMM, qui permet d'\u00e9crire, met les bits \u00e0 0, alors qu'un BULK ERASE, la commande d'effacement complet, remet tous les bits \u00e0 1. \n\nAinsi il est n\u00e9cessaire d'effacer la m\u00e9moire avant d'\u00e9crire le moindre bit. Dans le cas contraire, \u00e9craser les donn\u00e9es donne petit \u00e0 petit une m\u00e9moire remplie de 0. C'est ce que j'obtenais au fur et \u00e0 mesure de mes \u00e9critures successives. La deuxi\u00e8me incompr\u00e9hension est le syst\u00e8me d'adressage. J'ai confondu pages et secteur. Je pensais donc qu'il n'y avait que 16 pages de 256 octets chacune. En fait, il existe bien 16 secteurs de 256 pages chacuns, elles-m\u00eame contenant 256 octets chacune.\n\nJe me concentre donc sur la partie effacement de m\u00e9moire gr\u00e2ce \u00e0 BULK ERASE, je v\u00e9rifie que seul des 1 (0xFF) subsistent dans la m\u00e9moire. Ensuite j'\u00e9cris dans la m\u00e9moire puis v\u00e9rifie les donn\u00e9es \u00e9crites avec des printf. Quand la commande BULK ERASE fonctionne, l'EEPROM positionne le bit 1 du registre de statut \u00e0 1, c'est le write in progress bit (WIP). On peut donc v\u00e9rifier si la m\u00e9moire est pr\u00eate \u00e0 \u00eatre \u00e9crite ou non. L'effacement complet de la m\u00e9moire peut durer jusqu'\u00e0 10 secondes (d'apr\u00e8s la datasheet, en pratique cela dure environ 6 secondes).\n\nVoil\u00e0 l'ensemble des commandes utilis\u00e9es, dans l'ordre chronologique, afin d'\u00e9crire dans la m\u00e9moire :\n * WRITE ENABLE : activation du bit d'\u00e9criture, indispensable avant un BULK ERASE\n * BULK ERASE : Effacement complet de la m\u00e9moire (positionnement de tous les bits \u00e0 1)\n * READ STATUS REGISTER : Lecture en boucle du bit d'\u00e9criture en cours (WIP), afin d'attendre que la m\u00e9moire soit pr\u00eate\n * WRITE ENABLE : Avant l'\u00e9criture\n * PAGE PROGRAM : Permet d'\u00e9crire dans une des pages de la m\u00e9moire (limit\u00e9 \u00e0 256 octets donc).\n\nLe programme fonctionne parfaitement jusqu'\u00e0 ce que je d\u00e9branche par inadvertance le fil d'alimentation de la m\u00e9moire. Impossible de faire un nouveau BULK ERASE apr\u00e8s \u00e7a, le WIP est tr\u00e8s rapidement mis \u00e0 0 et l'effacement ne semble pas fait. Pourtant toutes les autres commandes marchent : READ DESCRIPTION, READ STATUS REGISTER, m\u00eame la mise en veille fonctionne (DEEP POWER MODE). Ce doit \u00eatre aussi la cause du non fonctionnement apr\u00e8s les tests fructueux du 30 Mars. Je d\u00e9cide de v\u00e9rifier l'alimentation. M\u00eame apr\u00e8s avoir utilis\u00e9 diverses alimentations externes (Adaptateur 12V avec pont diviseur pour obtenir du 3,3 V, puis alimentation par le 3,3 V de l'Arduino) et ajout\u00e9 la capacit\u00e9 de d\u00e9couplage (100 nF comme pr\u00e9cis\u00e9 dans la documentation), rien ne permet de r\u00e9tablir le comportement du 14/04 au matin.\n\nVoici les trames r\u00e9cup\u00e9r\u00e9es \u00e0 l'analyseur logique pour diff\u00e9rentes commandes :\n[[Fichier:Scope1_modif.png | centre | 600px ]]\n[[Fichier:Scope2_modif.png | centre | 600px ]]\n\n= Interface web (\u00e0 partir du 7 Avril) =\n\nL'interface web comporte, dans un premier temps, un formulaire d'upload pour le bitstream, qui redirige vers une page de traitement php ex\u00e9cutant le programme d\u2019\u00e9criture en C, gr\u00e2ce \u00e0 la fonction PHP exec();\n\n== Liens ==\n\n* [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/11/20/beaglebone-web-server--setup Tutoriel tr\u00e8s complet sur l'installation d'un serveur web sur BBB]\n\n== Installation du serveur web Lighttpd et PHP ==\n\n'''07/04''' : Pour pouvoir installer le serveur, il faut d'abord connecter la BBB \u00e0 internet, ce que je n'avais pas fait depuis le d\u00e9but du projet. 2 fichiers sont \u00e0 modifier : \n\n/etc/network/interfaces : Fichier inexistant, il faut le cr\u00e9er pour configurer l'interface ethernet (eth0) en auto et activer DHCP. Le fichier contient donc apr\u00e8s modification : \nauto eth0\niface eth0 inet dhcp\n\nLe second fichier, /etc/resolv.conf, sert \u00e0 sp\u00e9cifier les serveurs DNS qui permet de faire la conversion nom de domaine <=> adresse IP. J'utilise 8.8.8.8, le serveur DNS OpenDNS.\n\nBien s\u00fbr, cette configuration est propre au mode de connexion de mon domicile (une simple box Free). La configuration serait diff\u00e9rente pour se connecter au r\u00e9seau de l'\u00e9cole.\n\nApr\u00e8s s'\u00eatre assur\u00e9 de la bonne connexion \u00e0 internet (par un ping), je commence \u00e0 mettre \u00e0 jour la BBB avant d'installer le paquet, ce qui prend de longues minutes.\n\nLe paquet \u00e0 installer est lighttpd, un serveur web l\u00e9ger \u00e9quivalent \u00e0 Apache. Son module fast-CGI est ajout\u00e9, afin d'activer PHP. L'installation commence bien, jusqu'au lancement du service web, qui \u00e9choue. Le tutoriel pr\u00e9cise la source du probl\u00e8me : un autre service utilise le port 80, en l'occurence l'IDE Cloud 9, qui est un environnement de d\u00e9veloppement sous le forme d'une interface web. Toute une s\u00e9rie de services doivent \u00eatre d\u00e9sactiv\u00e9s par la m\u00eame occasion, comme par exemple Bonescript, qui est un langage bas\u00e9 sur Javascript permettant d'\u00e9crire des programmes pour la BBB.\n\nApr\u00e8s un red\u00e9marrage du BBB, les services sont effectivement arr\u00eat\u00e9s et lighttpd est lanc\u00e9. Il suffit ensuite d'installer PHP et PHP-CGI, ce dernier permettant d'\u00e9xecuter le programme directement via une fonction PHP.\n\n'''14/04''' : Je m'attelle ensuite aux pages web. La structure de l'interface web est tr\u00e8s simple : La page d'accueil contient un formulaire d'upload, qui renvoie sur une page de traitement o\u00f9 le serveur v\u00e9rifie que le transfert de fichier s'est bien pass\u00e9. Il ex\u00e9cute ensuite le programme en C en passant le fichier en argument, et affiche les \u00e9ventuels messages d'erreurs. Afin de reconna\u00eetre le message d'erreur, je modifie le programme en C pour que chaque erreur commence par une ligne contenant la cha\u00eene de caract\u00e8re \"erreur\". La fonction exec() de PHP est tr\u00e8s pratique : Elle permet d'\u00e9xecuter n'importe quel programme comme si on le lancait en ligne de commande, et il est m\u00eame possible de r\u00e9cup\u00e9rer la sortie standard via un tableau de caract\u00e8re. La premi\u00e8re case du tableau de r\u00e9sultat contient donc la chaine \"erreur\" si l'\u00e9criture dans l'EEPROM a mal fonctionn\u00e9\n\nLa page de traitement ex\u00e9cute aussi le programme \"cmp\" qui permet de comparer deux fichiers. Il est utilis\u00e9 sur le fichier image de la m\u00e9moire cr\u00e9\u00e9 par le programme en C.\n\n[[Fichier:Index_php.png | centre | 600px | Page d'accueil de l'interface ]]\n[[Fichier:Traitement_php.png | centre | 600px | Page de traitement apr\u00e8s une \u00e9criture r\u00e9ussie ]]\n\n= Bilan =\n\nL'\u00e9criture n'est pas fonctionnelle le 15/04 au soir, bien que l'algorithme soit complet et l'interface web finie. Il faudrait un peu plus de temps pour d\u00e9terminer la source du probl\u00e8me d'alimentation (si c'est bien la cause du dysfonctionnement de l'effacement de la m\u00e9moire).\n\nIl y a plusieurs axes d'am\u00e9lioration :\n* Acc\u00e9der \u00e0 toutes les fonctions du programme avec des arguments (comme pour la fonction d'\u00e9criture) : Lecture de la description, du registre de statut, effacement de la m\u00e9moire, lecture avec passage de l'adresse en param\u00e8tre, etc.\n* am\u00e9liorer l'interface web avec gestion des bitstreams d\u00e9j\u00e0 upload\u00e9s\n* Ajouter du CSS pour la rendre plus esth\u00e9tique\n* S\u00e9curiser l'application web pour \u00e9viter l'upload de fichier non autoris\u00e9 sur le serveur ou l'\u00e9criture de fichier pouvant compromettre le FPGA\n\nArchive contenant le programme d'\u00e9criture final en C ainsi que les deux pages web en PHP : [[Fichier:projet_malthieu.zip]]\nRapport : [[Fichier:Rapport_malthieu.pdf]]"
}
]
},
"2073": {
"pageid": 2073,
"ns": 0,
"title": "RoboCup 2015",
"revisions": [
{
"contentformat": "text/x-wiki",
"contentmodel": "wikitext",
"*": "<include nopre noesc src=\"/home/pedago/pimasc/include/video-OpenGermanI-iframe.html\" />\n__TOC__\n<br style=\"clear: both;\"/>\n\n==Cahier des charges==\n===Pr\u00e9sentation g\u00e9n\u00e9rale du projet=== \n[[Fichier:logoPyro_icone.png |center ]]\n<center><I> Polytech RoboCup Team </I></center>\n\nLors de la comp\u00e9tition de l'Open German, pr\u00e9lude de la Robocup, il faudra mettre en place un syst\u00e8me d'autonomisation de production \u00e0 l'aide de Robotinos (robots mobiles de Festo ayant un syst\u00e8me d'exploitation Linux). Comme dans toutes comp\u00e9titions, le but est de gagner, par cons\u00e9quent, il faudra faire en sorte de gagner un maximum de points.\nC'est pourquoi il faut cr\u00e9er un manager \u00e0 l'aide de ROS, c'est-\u00e0-dire un n\u0153ud ou ensemble de n\u0153uds permettant de pouvoir recevoir les informations envoy\u00e9es par les autres n\u0153uds, de les traiter, tout cela afin de donner les ordres que doivent ex\u00e9cuter chaque Robotino. Ce manager devra \u00e9galement \u00eatre capable d'optimiser le nombre de points \u00e0 obtenir.\n\n====Contexte====\n\nLa comp\u00e9tition de l'Open German se d\u00e9roule en quatre phases sp\u00e9cifiques : phase de d\u00e9but-de-jeu, phase d'exploration, phase de production, phase de fin-de-jeu. Le manager aura des t\u00e2ches sp\u00e9cifiques \u00e0 remplir suivant les diff\u00e9rentes phases. La RefereeBox est un syst\u00e8me d'arbitrage auquel il est n\u00e9cessaire d'envoyer p\u00e9riodiquement des donn\u00e9es \u00e0 tout moment du jeu et qui donne \u00e0 chaque instant l'\u00e9tat du jeu ainsi que les produits demand\u00e9s en priorit\u00e9 durant la phase de production. \n\n====Objectif du projet====\n\n*Assurer un maximum de points suivant les al\u00e9as du jeu (panne de machine, produits demand\u00e9es, rupture de stock d'une mati\u00e8re premi\u00e8re, \u2026)\n*Assurer la p\u00e9rennit\u00e9 du projet (chaque ann\u00e9e des candidats de Polytech Lille y participent)\n\n====Description du projet====\n\nPour le projet, outre le fait de gagner le plus de points possibles, il faudra valider les trois contraintes suivantes : \n*Communication avec le n\u0153ud de la RefereeBox \u00e0 tout moment du jeu\n*Contrainte de robustesse (il ne faut qu'\u00e0 un moment ou \u00e0 un autre il n'y ait un blocage de tous les robots)\n*Coop\u00e9ration entre les trois robots\n<br />\n[[Fichier:Interactions.png|vignette|left|upright=2|Interactions des n\u0153uds avec le manager]]\n<br />\nLe manager devra interagir avec les diff\u00e9rents n\u0153uds suivants ayant chacun leurs r\u00f4les sp\u00e9cifiques :\n*RefereeBox Comm\u00a0: recevoir les donn\u00e9es envoy\u00e9es par la RefereeBox et envoyer des donn\u00e9es suivant l'\u00e9tat du jeu \u00e0 la RefereeBox\n*Robots Comm\u00a0: communiquer aux autres robots les informations concernant ce que chacun font\n*Traitement des TAGs\u00a0: lire les TAG \n*Traitement des feux\u00a0: lire l'\u00e9tat des colonnes de feu\n*Pince de pr\u00e9hension\u00a0: ouvrir et fermer la pince et renvoyer l'\u00e9tat de la pince\n*Approche finale\u00a0: s'adapter au banc de charge ou de d\u00e9charge de produits\n*G\u00e9n\u00e9ration trajectoire\u00a0: d\u00e9termine une trajectoire pour aller au lieu (X,Y)\n*R\u00e9alisation trajectoire\u00a0: parcourir la trajectoire \n*Localisation\u00a0: savoir p\u00e9riodiquement (faible p\u00e9riode) o\u00f9 se situe le robot\n*D\u00e9tection d'obstacle\u00a0: d\u00e9tecter les obstacles fixes et mobiles\n<br /><br />\n\n====Choix techniques : mat\u00e9riel et logiciel====\n\n*Utilisation de trois robotinos\n*Utilisation de ROS (Robot Operating System), c'est un ensemble d'outils informatiques open source permettant de d\u00e9velopper des logiciels pour la robotique. Il est disponible sous environnement Linux en version stable. Ce syst\u00e8me travaille en utilisant des n\u0153uds qui communiquent entre eux \u00e0 l'aide de services (requ\u00eate-r\u00e9ponse) et de topics (fichiers).\n*Utilisation de diff\u00e9rents langages\u00a0: C++ ou Python (n\u0153uds)\n*Travail sous Linux Ubuntu 12.04 car utilisation de la version HYDRO de ROS\n<br />\n\n===Etapes du projet===\n*Prise en main de ROS et du C++\n*\u00c9laboration de l'algorithme du manager pour la phase d'exploration\n*\u00c9laboration de l'algorithme du manager pour la phase de production\n**Coop\u00e9ration entre robots\n**R\u00e9partition des t\u00e2ches\n*Codage du manager\n*Tests et corrections\n<br />\n\n==Avancement du Projet==\n===Semaine 1===\n*Prise en main de ROS \n*R\u00e9alisation des tutoriels ROS disponibles au lien http://wiki.ros.org/fr/ROS/Tutorials\n*R\u00e9alisation de diff\u00e9rents tutoriels C++\n*Connaissance plus aigu\u00eb du sujet de l'Open German 2015\n<br />\n===Semaine 2===\n*R\u00e9flexions autour de la structure du manager : deux n\u0153uds\n**Un n\u0153ud ex\u00e9cuteur de t\u00e2ches\n**Un n\u0153ud g\u00e9n\u00e9rateur de t\u00e2ches\n*R\u00e9flexions sur l'algorithme g\u00e9n\u00e9ral du manager concernant la phase d'exploration\n**Fonctionnement par zoning pour la r\u00e9partition des t\u00e2ches des trois robots\n**R\u00e9flexion autour d'une alternative de r\u00e9partition par distances les plus courtes entre machines\n*Recherche de solutions pour la phase de production\n**Documentation autour de la planification de t\u00e2ches et la g\u00e9n\u00e9ration de t\u00e2che pour une \u00e9quipe\n**Recherche autour de la coop\u00e9ration et de l'allocation de r\u00f4les \u00e0 des robots multi-t\u00e2ches\n*Organisation g\u00e9n\u00e9rale\n**Structuration d'un \u00e9ch\u00e9ancier num\u00e9rique sous Asana\n**Demande d'autorisation pour l'ouverture de la salle C002 aupr\u00e8s de M. Scrive\n<br />\n\n===Semaine 3===\nVoil\u00e0 un lien permettant d'acc\u00e9der au sujet provisoire de la Robocup 2015 : [https://drive.google.com/file/d/0B39jN82rDE6qMG45cDN5Z0xiSVE/view?usp=sharing Sujet]<br />\n*R\u00e9flexions au sujet des infos \u00e0 communiquer au n\u0153ud AutresRobotsComm :\n**Ce que le robotino fait\n**Quelle machine le robotino est en train d'utiliser\n[[Fichier:DataSWithRobotComm.jpg|center]]\n<br />\n*R\u00e9flexions au niveau de l'algorithme de la phase de production\n**Proposition de le faire sous le principe de \"Diviser pour mieux r\u00e9gner\" (valid\u00e9 par M. Vincent Coelen)\n***Diviser la t\u00e2che principale en sous-t\u00e2ches, les sous-t\u00e2ches en sous-sous-t\u00e2ches et les sous-sous-t\u00e2ches en sous-sous-sous-t\u00e2ches \u00e9l\u00e9mentaires.\n**D\u00e9termination des t\u00e2ches \u00e0 r\u00e9aliser pour un exemple particulier\nOn souhaite produire, pendant une dur\u00e9e d\u00e9termin\u00e9e par la refBox, le produit suivant :\n[[Fichier:ExempleProduitDemande.jpg|center]]\n''Le produit est compos\u00e9 d\u2019une base bleue, d\u2019un ring rouge, d\u2019un ring vert et d\u2019un cap noir.''\n\n'''Obtenir Base Bleue''' \n ->Aller \u00e0 la Base Station\n g\u00e9n\u00e9rateur trajectoire\n ex\u00e9cuteur trajectoire\n ->V\u00e9rifier si machine OK\n approche finale\n traitement feux\n ->Prendre produit\n RefBoxComm (dire \u00e0 la Base Station quelle base est souhait\u00e9e et \u00e0 quelle banc le robotino est) \n approche finale \n pince (prendre)\n\n'''Obtenir ring rouge'''\n ->Aller \u00e0 une Ring Station\n Laquelle ? laquelle est inoccup\u00e9e ? la plus proche ? (RobotsComm)\n g\u00e9n\u00e9rateur de trajectoire\n ex\u00e9cuteur de trajectoire\n ->V\u00e9rifier si machine OK\n approche finale\n traitement feux\n ->Prendre produit \n RefBoxComm (pour dire quel produit et quel banc de livraison)\n approche finale\n pince (d\u00e9poser)\n pince (prendre)\n\n'''Obtenir ring vert'''\n ->Aller \u00e0 une Ring Station\n Laquelle ? laquelle est inoccup\u00e9e ? la plus proche ? (RobotsComm)\n (Du coup la plus proche sera celle o\u00f9 on vient de faire le ring pr\u00e9c\u00e9dent)\n g\u00e9n\u00e9rateur de trajectoire\n ex\u00e9cuteur de trajectoire\n ->V\u00e9rifier si machine OK\n dire \u00e0 la Ring Station quelle base est souhait\u00e9e ( ici, la verte )\n approche finale\n traitement feux\n ->Prendre produit \n RefBoxComm (pour dire quel produit et quel banc de livraison)\n approche finale\n pince (d\u00e9poser)\n pince (prendre)\n\n'''Finaliser produit'''\n ->Aller \u00e0 une Cap Station\n Laquelle ? laquelle est inoccup\u00e9e ? la plus proche ? (RobotsComm)\n g\u00e9n\u00e9rateur de trajectoire\n ex\u00e9cuteur de trajectoire\n ->V\u00e9rifier si machine OK\n dire \u00e0 la Cap Station quelle cap est souhait\u00e9 ( ici, le noir )\n approche finale\n traitement feux\n ->Prendre produit \n RefBoxComm (pour dire quel banc de livraison)\n approche finale\n pince (prendre)\n ->D\u00e9poser \u00e0 la Delivery Station\n g\u00e9n\u00e9rateur de trajectoire (vers la Delivery Station)\n ex\u00e9cuteur de trajectoire\n approche finale\n pince (d\u00e9poser)\n<br />\n*Organisation g\u00e9n\u00e9rale :\n**Cr\u00e9ation de la page Facebook de l'\u00e9quipe PYRO Team\n<br />\n\n===Semaine 4===\n*\u00c9criture des sous-t\u00e2ches \u00e0 r\u00e9aliser\n**Pseudo-codes de certaines sous-t\u00e2ches r\u00e9alis\u00e9es \n*Recherche d'ordonnancement optimis\u00e9 pour la fabrication du produit\n**Recherche d'algorithmes\n**Visualisation du probl\u00e8me d'ordonnancement concernant l'exemple pr\u00e9c\u00e9dent (base bleue, ring vert, ring rouge, cap noir)\n<br />\nIci, on a pris en plus en hypoth\u00e8se 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\u00e9hender le probl\u00e8me, nous nous sommes attach\u00e9s \u00e0 effectuer un tableau r\u00e9capitulant les t\u00e2ches \u00e0 effectuer pour le produit exemple et \u00e0 r\u00e9aliser un graphe mettant en avant les contraintes de pr\u00e9c\u00e9dence de chaque t\u00e2che.\n<br />\n\n{| class=\"wikitable\" style=\"text-align:center; width:80%;\"\n\n |-\n |\n ! scope=\"col\" | T\u00e2ches\n ! scope=\"col\" | Ressources utilis\u00e9es\n ! scope=\"col\" | Contraintes de pr\u00e9c\u00e9dence\n |-\n ! scope=\"row\" | T0\n | Ramener \u00e0 CS base avec cap\n | Robot 1, 2 ou 3\n | Aucune\n |-\n ! scope=\"row\" | T1\n | D\u00e9capsuler\n | Cap Station 1 ou 2\n | T0\n |-\n ! scope=\"row\" | T2\n | Ramener base suppl\u00e9mentaires \u00e0 RS\n | Robot 1, 2 ou 3\n | Aucune\n |-\n ! scope=\"row\" | T3\n | Chercher base bleue\n | Robot 1, 2 ou 3\n | Aucune\n |-\n ! scope=\"row\" | T4\n | Ramener \u00e0 RS pour ring vert\n | Robot 1, 2 ou 3\n | T7\n |-\n ! scope=\"row\" | T5\n | Ramener \u00e0 RS pour ring rouge\n | Robot 1, 2 ou 3\n | T8\n |-\n ! scope=\"row\" | T6\n | Ramener \u00e0 CS pour cap\n | Robot 1, 2 ou 3\n | T9\n |-\n ! scope=\"row\" | T7\n | Ramener Base\n | Base Station\n | T3\n |-\n ! scope=\"row\" | T8\n | Ajouter ring vert\n | Ring Station 1\n | T4\n |-\n ! scope=\"row\" | T9\n | Ajouter ring rouge\n | Ring Station 1 ou 2\n | T5 et T2\n |-\n ! scope=\"row\" | T10\n | Ajouter cap\n | Cap Station 1 ou 2\n | T6 et T1\n |-\n ! scope=\"row\" | T11\n | Traiter le produit fini\n | Delivery Station\n | T12\n |-\n ! scope=\"row\" | T12\n | Ramener \u00e0 DS\n | Robot 1, 2 ou 3\n | T10\n |}\n[[Fichier:TachesProduitExemple.png|center]]\n<center>Graphe montrant l'ordre des t\u00e2ches \u00e0 r\u00e9aliser</center>\n<br />\n\n===Semaine 5===\nDurant cette semaine, nous avons r\u00e9fl\u00e9chi sur le choix de structures pour nos donn\u00e9es : \n* Une '''liste principale''' de tous les produits demand\u00e9s par la RefBox \u00e0 un instant t. Cette liste principale a les caract\u00e9ristiques suivantes :\n** Une '''Priorit\u00e9''' sera calcul\u00e9e pour chaque produit avec les param\u00e8tres suivants : \n*** Nombre de points que peut apporter la production d'un produit de A \u00e0 Z.\n*** Une estimation du temps de production d'un produit.\n***La date limite de livraison du produit demand\u00e9\n** Une t\u00e2che est \u00e9lue si sa priorit\u00e9 est sup\u00e9rieure ou \u00e9gale \u00e0 celle des autres t\u00e2ches.\n** Quand la RefBox demande un produit, une cellule sera ajout\u00e9e dans cette liste. Et de m\u00eame, quand un produit sera termin\u00e9, on le supprimera de cette liste.\n* Chaque produit de la liste principale va contenir une '''liste de t\u00e2ches''' correspondantes \u00e0 la production de ce produit. Cette liste de t\u00e2ches a les caract\u00e9ristiques suivantes :\n** Chaque cellule correspond \u00e0 une t\u00e2che de la production d'un produit. Une t\u00e2che contient diff\u00e9rents champs :\n***Intitul\u00e9 de la t\u00e2che (par exemple ajouter une base)\n***Produit concern\u00e9e (par exemple P3)\n***Priorit\u00e9 de la t\u00e2che (par exemple 20)\n***Temps restant estim\u00e9 de production (par exemple 180s)\n** A chaque fois qu'une t\u00e2che est r\u00e9alis\u00e9e, elle sera supprim\u00e9e de la liste de t\u00e2ches. Ce qui veut dire, qu'on va devoir calcul\u00e9 \u00e0 nouveau la priorit\u00e9 de chaque t\u00e2che de la liste principale.\n** Afin de respecter les contraintes de pr\u00e9c\u00e9dence, on consid\u00e9rera que la t\u00e2che en t\u00eate de la liste de t\u00e2ches peut \u00eatre \u00e9lue. Par exemple, on ne peut pas ajouter un Ring si on n'a pas de base.\n<br />\nL'exemple suivant simule le cas o\u00f9 la RefBox a demand\u00e9 deux fois le produit P3 et deux fois le produit P2.\n*Le produit P3 est r\u00e9alisable en cinq t\u00e2ches.Ce produit mettra plus de temps \u00e0 \u00eatre fabriqu\u00e9 mais rapportera plus de points.\n*Le produit P2 est r\u00e9alisable en quatre t\u00e2ches.\n<br />\n[[Fichier:listedelistes.png|center]]\n<center>Structure utilis\u00e9e pour ranger les t\u00e2ches \u00e0 r\u00e9aliser</center>\n<br />\nDiff\u00e9rentes remarques utiles :\n*Avant de commencer \u00e0 r\u00e9aliser n'importe quel produit, il faudra au pr\u00e9alable v\u00e9rifier si on a lib\u00e9rer un espace de stockage pour plusieurs raisons :\n**Les Cap Stations ayant initialement aucun cap en stock, il faut les ramener de l'\u00e9tag\u00e8re qui en contient initialement car un produit est dit fini lorsqu'il a \u00e0 son sommet un cap.\n**L'\u00e9tag\u00e8re ayant \u00e9t\u00e9 d\u00e9barrass\u00e9e d'un cap, cela permet d'avoir un espace de stockage afin de d\u00e9poser des produits finis en attente de livraison ou des produits non finis dont on voudrait mettre en pause la production.\n*Il sera peut \u00eatre des fois plus avantageux d'abandonner temporairement la production d'un produit :\n**Il vaut mieux faire en sorte de terminer un seul produit sur deux dans les temps plut\u00f4t qu'aucun car du fait de la parall\u00e9lisation de la fabrication des produits, on peut \u00eatre surcharg\u00e9 de travail.\n**Un produit livr\u00e9 durant le laps de temps demand\u00e9 rapportera plus de points non n\u00e9gligeables.\n*Un tableau sera n\u00e9cessaire afin de savoir ce qu'il y a les espaces de stockage avec les champs suivants :\n**Type de produit\n**Liste de t\u00e2ches restantes pour la fabrication du produit (pour un produit fini cette liste est donc nulle)\n**Date de d\u00e9but de livraison\n**Date de fin de livraison\n**Emplacement de l'espace de stockage\n<br />\n\n===Semaine 6===\n*Diff\u00e9rentes fonctions et actions en pseudo code pour le g\u00e9n\u00e9rateur de t\u00e2ches\n**Fonction qui retourne un bool\u00e9en suivant si un produit est en stock ou non\n**Fonction qui retourne un bool\u00e9en suivant si on doit livrer le produit \u00e0 pr\u00e9sent ou non\n**Fonction qui retourne un bool\u00e9en suivant si on a d\u00e9j\u00e0 ou non mis le travail \u00e0 faire dans la structure contenant les t\u00e2ches \u00e0 r\u00e9aliser\n**Fonction qui retourne le nombre de points que rapporte un produit pass\u00e9 en param\u00e8tre\n**Action qui rajoute les nouveaux ordres de production dans la liste de listes de t\u00e2ches\n**Action qui calcule le ratio pour chaque t\u00e2che \n**Action qui supprime les t\u00e2ches vides (ie celles qui sont termin\u00e9es)\n*D\u00e9but de l'\u00e9criture en pseudo code de la fonction principale\n<br />\n*Discussion avec M. Vincent Coelen concernant l'avancement du projet :\n**Validation par M. Coelen Vincent des portions de pseudo code d\u00e9j\u00e0 \u00e9crites\n**Discussion autour de la mise en place d'un arr\u00eat imm\u00e9diat des robots \u00e0 tout moment du jeu\n**Am\u00e9lioration concernant la robustesse de l'algorithme si un robot n'est plus en \u00e9tat de fonctionnement \n<br />\n*Diff\u00e9rentes remarques utiles :\n**Branche concernant le manager cr\u00e9\u00e9e sur le [https://github.com/PyroTeam/robocup-pkg/ git] de l'\u00e9quipe \n**Discussion avec d'autres membres de l'\u00e9quipe sur les services et les topics \u00e0 envoyer et \u00e0 recevoir aux n\u0153uds du manager\n<br />\n===Semaine 7===\n\n====G\u00e9n\u00e9rateur de t\u00e2ches====\nD\u00e9but du codage C++ :\n*Cr\u00e9ation de diff\u00e9rentes classes :\n**La classe Tache (tache.h et tache.cpp)\n**La classe Stockage (stockage.h et stockage.cpp)\n**La classe RefBoxComm (refboxcomm.h)\n*Cr\u00e9ation de diff\u00e9rentes fonctions :\n**Dans tache.h et tache.cpp :\n***point_par_produit : retourne le nombre de points que vaut un produit\n***dans_les_temps : retourne un bool\u00e9en indiquant s'il est temps de ramener le produit\n**Dans listetaches.h et listetaches.cpp :\n***creation_liste_taches_prod : retourne une liste de taches \u00e0 partir d'un produit pass\u00e9 en param\u00e8tre\n***creation_liste_taches_act : retourne une liste de taches \u00e0 partir d'un produit et d'une action pass\u00e9s en param\u00e8tres\n**Dans tableaustockage.h :\n***produit_en_stock : retourne un bool\u00e9en indiquant si au moins un produit est en stock\n**Dans travail.h et travail.cpp :\n***deja_dans_travail : retourne un bool\u00e9en indiquant si un ordre de la RefBox a d\u00e9j\u00e0 \u00e9t\u00e9 pris en compte dans la structure contenant les t\u00e2ches \u00e0 r\u00e9aliser\n***max_ratio : retourne l'objet Tache qui a le plus grand ratio dans la structure contenant les t\u00e2ches \u00e0 r\u00e9aliser\n***rajout_dans_travail : rajoute un nouvel ordre de la RefBox dans la structure contenant les t\u00e2ches \u00e0 r\u00e9aliser \n***calcul_ratio : calcule le ratio de chaque premier de liste de la structure contenant les t\u00e2ches \u00e0 r\u00e9aliser\n<br />\nLes codes sont disponibles sur le [https://github.com/PyroTeam/robocup-pkg/tree/feature/manager/generateur_taches git]\n<br />\nDes tests ont \u00e9t\u00e9 r\u00e9alis\u00e9s afin de valider les fonctions cr\u00e9es en particulier les fonctions contenues dans travail.h et travail.cpp\n<br />\nVoici un petit aper\u00e7u de la console :\n<br />\n[[Fichier:Capture terminal gen taches 3.png|800px]]\n<br />\nAinsi, les quatres fonctions fonctionnent parfaitement :\n*deja_dans_travail indique bien que l'ordre de la RefBox n'a pas encore pris en compte\n*max_ratio retourne bien la t\u00e2che dont le ratio est maximum\n*rajout_dans_travail rajoute en fin de liste la liste de t\u00e2ches pour la premi\u00e8re cr\u00e9ation d'un produit P0 car un cap est disponible , puis il concat\u00e8ne une liste contenant en t\u00eate la t\u00e2che \"Decapsuler\" avec la liste de t\u00e2ches pour la seconde cr\u00e9ation d'un produit P0. En effet, la RefBox a demand\u00e9 deux fois le produit P0 et on ne peut cr\u00e9er un produit tant qu'un cap n'est pas disponible.\n*calcul_ratio calcule le ratio de chaque premi\u00e8re t\u00e2che en fonction du nombre de points et du temps, de plus, si c'est le bon moment pour d\u00e9stocker un produit il passe cette t\u00e2che \"Destocker\" en priorit\u00e9 (liste 6), en outre, la cr\u00e9ation d'un produit (liste 1 et liste 7) est prioritaire \u00e0 l'unique t\u00e2che \"Decapsuler\" (listes 2, 3, 4 et 5) . \n<br />\n'''Nous avons enfin re\u00e7u le sujet 2015 pour la comp\u00e9tition 2015, il est disponible [https://drive.google.com/file/d/0B39jN82rDE6qSk11YXFuQVljTlE/view?usp=sharing ici]'''\n<br />\n*Modification \u00e0 r\u00e9aliser :\n**la fonction de cr\u00e9ation de liste de t\u00e2ches\n**l'ordonnancement (en partie)\n**calcul de ratio de chaque t\u00e2che\n\n====Ex\u00e9cuteur de t\u00e2ches====\nL'\u00e9x\u00e9cuteur de taches va recevoir des ordres de la part du <b> g\u00e9n\u00e9rateur de taches </b>. En fonction de ces ordres, il enverra des demandes d'ex\u00e9cution/d'informations aux autres noeuds. Il y a donc un seul g\u00e9n\u00e9rateur de taches et trois ex\u00e9cuteurs de taches ( on a trois robotinos ). \nVoici les classes qui correspondent \u00e0 chaque ex\u00e9cuteur de taches : \n[[Fichier:shema1.png]]\n*'''Machine''' est une classe abstraite qui servira \u00e0 la cr\u00e9ation des quatre classes filles qui repr\u00e9senteront les quatre machines de la comp\u00e9tition. \n** ''string type'' sera donc BaseStation, RingStation, CapStation ou DeliveryStation.\n** ''Pose2D centreMachine'' est un point(x,y,theta) qui va correspondre au retour du noeud de localisation (Projet 36)\n** ''Pose2D entreeMachine'' est un point(x,y,theta) qui sera calcul\u00e9 afin de pouvoir d\u00e9terminer l'emplacement exacte du convoyeur pour d\u00e9poser un produit\n** ''Pose2D sortieMachine'' est un point(x,y,theta) qui sera calcul\u00e9 afin de pouvoir d\u00e9terminer l'emplacement exacte du convoyeur pour prendre un produit\n*'''BaseStation''' est une classe fille de la classe \"Machine\".\n** ''int baseRouge'', ''int baseNoir'' et ''int baseArgent'' vont correspondre aux nombres de bases rouges, bases noires, base argentes respectivement.\n*'''RingStation''' est une classe fille de la classe \"Machine\".\n** ''int ringVert'', ''int ringJaune'', ''int ringBleu'' et ''ringOrange'' vont correspondre aux nombres de rings verts, rings jaunes, rings bleus et rings oranges respectivement.\n*'''CapStation''' est une classe fille de la classe \"Machine\".\n** ''int capNoir'' et ''int capGris'' vont correspondre aux nombres de caps noirs et caps gris respectivement.\n** ''int stock[3]'' est un tableau qui va correspondre aux trois emplacements stockage de la capStation.\n** 'Pose2D stockage'' est un point(x,y,theta) qui correspond \u00e0 l'emplacement de la premi\u00e8re zone de stockage.\n\n===Semaine 8===\n====G\u00e9n\u00e9rateur de t\u00e2ches====\n*Cr\u00e9ation du service pour l'envoi des ordres pour l\u2019ex\u00e9cuteur de t\u00e2ches avec pour contenu:\n**Num\u00e9ro du robot\n***1, 2 ou 3\n**Ordre\n***ChercherBase\n***MettreCap\n***ChercherCap\n***MettreRing\n***ChercherRing\n***RamenerBaseRS\n***Livrer\n***Decapsuler\n***Destocker\n**Param\u00e8tre\n***noir\n***argent\n***rouge\n***orange\n***jaune\n***bleu\n***vert\n***gris\n***DS\n***stock\n***aucun\n**Id\n***0, 1, 2, 3, 4, 5 ou 6\n<br />\nL'ex\u00e9cuteur de t\u00e2ches du robot concern\u00e9 doit envoyer en retour :\n*un bool\u00e9en qui indique si l'ordre est accept\u00e9 ou non\n*l'ordre pris en compte\n*l'Id de retour\n<br />\nCr\u00e9ation d'un n\u0153ud ROS pour le d\u00e9bogage \u00e0 l'aide de ddd\n<br />\nCr\u00e9ation d'un n\u0153ud ROS pour similer l'envoi et la r\u00e9ception des ordres\n<br />\n<br />\nCr\u00e9ation de la classe action qui range les informations contenues dans le topic envoy\u00e9 par l'ex\u00e9cuteur de t\u00e2ches<br />\nUtilisation de la classe action dans la fonction principale pour la phase de production<br />\nTest OK cependant le traitement des informations ne se fait pas suffisamment rapidement pour une utilisation pratique\n<br />\n\n====Ex\u00e9cuteur de t\u00e2ches====\nL'ex\u00e9cuteur de taches est un noeud qui recevra des ordres de la part du <b>g\u00e9n\u00e9rateur de taches</b> et qui, \u00e0 son tour, va envoyer des ordres aux autres noeuds.\n\nAvec ROS, on peut communiquer entre les diff\u00e9rents noeuds de plusieurs fa\u00e7ons. En voici deux qui sont principalement utilis\u00e9s :\n* Les Topics : qui sont souvent utilis\u00e9s pour publier des valeurs de donn\u00e9es en continues \n* Les services : qui permettent d'envoyer un ordre \u00e0 un noeud (REQUEST) et qui permettent de recevoir de bonne r\u00e9ception de l'ordre (RESPONSE)\n\nVoici le sch\u00e9ma de communication entre les diff\u00e9rents noeuds, en rouge on a les services et en bleu les topics : \n\n[[Fichier:schema2.jpg]]\n\n===Semaine 9===\n<br />\n====Ex\u00e9cuteur de t\u00e2ches====\nApr\u00e8s avoir discuter avec les autres membres de l'\u00e9quipe, nous avons r\u00e9alis\u00e9 quelques modification au niveau des communications entre l'ex\u00e9cuteur de taches et les autres noeuds. En fait, <I> les services </I> permettent d'envoyer une requ\u00eate au serveur correspondant et ensuite le client re\u00e7oit une r\u00e9ponse de bonne r\u00e9ception de la requ\u00eate. Alors que <I> les topics </I> permettent d'envoyer, \u00e0 une certaine fr\u00e9quence, les valeurs de variables qui correspondent \u00e0 ce topic. Ainsi, on remarque qu'on aurait besoin d'utiliser un \"m\u00e9lange\" de ces deux moyens de communication. En Ros, cela existe : <B> les actions </B>.\n\nVoici donc \u00e0 nouveau le sch\u00e9ma de communication :\n[[Fichier:Schema.001.jpg]]\n\n===Semaine 10===\n<br />\n====Ex\u00e9cuteur de t\u00e2ches====\nAfin de pouvoir tester l'interaction de l'ex\u00e9cuteur de taches avec les autres noeuds, nous avons du faire des \"faux noeuds\" \u00e9tant donn\u00e9 que les \"vrais noeuds\" n'\u00e9taient pas encore termin\u00e9s. \n\nVoici une figure qui montre que l'ex\u00e9cuteur de taches, en haut \u00e0 gauche, est en attente de recevoir des ordres du g\u00e9n\u00e9rateurs de taches, \u00e0 cot\u00e9 de l'ex\u00e9cuteur :\n[[Fichier:before_order.tiff | thumb]]\n\nCeci est une repr\u00e9sentation de la phase d'exploration. En effet, dans cette phase l'ex\u00e9cuteur de taches vas recevoir un ordre du g\u00e9n\u00e9rateur de taches pour explorer une zone de la map. Il va donc demander au noeud navigation de se d\u00e9placer vers le point en bas \u00e0 gauche de la zone. D\u00e8s l'arriv\u00e9e, l'ex\u00e9cuteur de taches va demander au noeud \"approche finale\" de s'approcher de la machine afin de lire son ArTag. Grace \u00e0 ce dernier, il pourra savoir de quelle machine s'agit-il et si le Robotino est du cot\u00e9 de l'entr\u00e9e ou de la sortie. Parce que, en fait, s'il est en entr\u00e9e l'ex\u00e9cuteur de taches va demander \u00e0 la navigation puis l'approche finale d'aller au cot\u00e9e sortie de la machine puisque la colonne de feu se trouve du cot\u00e9 sortie. Une fois arriv\u00e9e au cot\u00e9 sortie, l'ex\u00e9cuteur de taches va demander au noeud du traitement feu de lire l'\u00e9tat des trois feus de la colonne FESTO. \nL'interpr\u00e9tation des feus se fait gr\u00e2ce \u00e0 la refereeBox. En effet, la refereeBox, publie sur un topic, un tableau avec tous les \u00e9tats possibles de feux avec une chaine de caract\u00e8res pour chaque \u00e9tat. L'ex\u00e9cuteur va donc pouvoir r\u00e9cup\u00e9rer la chaine de caract\u00e8res correspondante aux \u00e9tats de feus actuels de la machine explor\u00e9e. L'ex\u00e9cuteur peut donc maintenant identifier une machine en envoyant : la zone explor\u00e9e, l'id de l'ArTag trouv\u00e9, ainsi que la chaine de caract\u00e8res qui correspond au feus.\n\nDans la figure pr\u00e9c\u00e9dente, le g\u00e9n\u00e9rateur de taches n'avait pas encore envoy\u00e9 son ordre, on peut remarquer que l'ex\u00e9cuteur \u00e9tait en attente. Une fois l'ordre envoy\u00e9, comme dans la figure suivante, l'ex\u00e9cuteur peut commencer \u00e0 donner des ordres aux autre noeuds : \n[[Fichier:after_order.tiff]] <br/>\nOn remarque que l'ex\u00e9cuteur a communiqu\u00e9 avec tous les faux-noeuds pour enfin reporter une machine avec la refereeBox \"fake r\u00e9ception refereeBox \". \nNotons que fait d'utiliser des \"faux-noeuds\" pour tester nos algorithmes nous permet de se placer dans le cas id\u00e9ale.\n\n===Semaine 11===\n<br />\nCette semaine \u00e9tait consacr\u00e9 \u00e0 l'am\u00e9lioration de nos algorithmes et \u00e0 la correction des bugs ainsi qu'\u00e0 l'organisation de notre voyage.\n===Semaine 12===\n<br />\nNous sommes partis \u00e0 Magdebourg le mardi 21/4. Le programme de la semaine \u00e9tait le suivant : <br/>\n<u>Mercredi, Jeudi </u> : jours de SetUp. <br/>\nNous avons profit\u00e9 de ses jours pour finaliser nos programmes en tant qu'\u00e9quipe. Et de r\u00e9aliser des tests sur la piste et de modifier nos programmes afin d'am\u00e9liorer nos r\u00e9sultats. \nNous avons aussi r\u00e9alis\u00e9 un merge de toutes les branches de notre git afin de tester les interactions des noeuds entre eux. <br/>\n<u>Vendredi,Samedi </u> : jours de matchs <br/>\nEn fonction des matches, nous modifions nos programmes afin d'am\u00e9liorer nos programmes. <br/> \n<u>Dimanche </u> : Finale <br/>\nNous avons finis deuxi\u00e8me.\n<br />\n===Semaine 13===\nR\u00e9alisation de la vid\u00e9o du projet et envoi d'un mail \u00e0 M. Laurent Engels pour convertir la vid\u00e9o dans les diff\u00e9rents formats demand\u00e9s\n\n== Fichiers Rendus ==\n[[Fichier:Manager.zip]]\n<br />\n[[Fichier:Manager_msg.zip]]\n<br />\n[[Fichier:RapportProjetSmaggheHage.pdf]]"
}
]
}
}
}
}