Bilan de chaque séance

De Robotics.

Sommaire

Séance du 02/02/2010

Aymeric

  • Soudage des quatre LEDs à la plateforme de test et programmation en C du pic. Clignotement OK.
  • Recherche d'informations sur la calibration de camera et de la librairie openCV (http://www.ensieta.fr/e3i2/Bazeille/Tutorials.html#OPENCV)
  • Visionnage des différents exemples fournis avec OpenCV et analyse sommaire des codes.
  • Installation sur mon PC portable de Windows 7 (Non ca n'a rien à voir avec Carotte mais je devais le faire ^^) et de VmWare afin de travailler sous Linux.

TODO (Prochaine séance):

  • Tracking des DELs via la webcam. Choisir entre l'utilisation du mode RVB ou TSV. Effectuer différents tests afin de bien percevoir les DELs tout en occultant au maximum le reste.
  • Calibration de la camera.

Olivier

  • Recherche des différentes techniques de reconnaissance d'objets :

Pour cela, j'ai entre autre découvert un magasine spécialisé sur le traitement d'image : IEEE Transactions on Pattern Analysis and Machine Intelligence ([1]). Bien qu'il soit payant, de nombreux articles sont disponibles librement sur le net.

  • Recherche approfondies des principales techniques :
    • Transformée de Hough, pour la reconnaissance de droites
    • Transformée généralisée de Hough, pour la reconnaissance de formes
    • Analyse structurelle, à partir d'arbres des régions

TODO :

  • Lire le code des exemples utiles de la librairie OpenCV
  • Modélisation du code C à écrire avec ses fonctionnalités.


Hamed et Fahd

1)Travail bibliographique:

a)Documents consultés:

-Système cricket MIT

-Nissanka Bodhi Priyantha, The Cricket Indoor Location System PhD Thesis, Massachusetts Institute of Technology, June 2005.

-Allen K. L. Miu, Design and Implementation of an Indoor Mobile Navigation System SM Thesis, Massachusetts Institute of Technology, Jan 2002

- Recuperation du "cricket shematic", schema du micro-controleur

-Cricket v2 User manual


2) Travail effectué 

* Documentation  

*Définition du Hardware pour le dispositif de localisation:
 -choix transducteurs RF, du micro-controleur (à confirmer), du récepteur et
  émetteur U.S.

Informations acquises:

  • Architecture du dispositif de localisations: 
-Un transducteur RF
-Un micro-controlleur
-UN hardware générateur et récepteur d'ultrason
  • principe de la technique du "Time-Difference-of-Arrival (TDOA)" utilisé par cricket 
 ou amélioration possible en utilsant le système du Broadband Ultrasonic Location
 System



2)Travail pour les séances à venir

  • Documentation précise et approfondie sur le système Criket
  • Définir la procédure pour l'échantillonnage du signal RF

Chen Hao


Séance du 16/02/2010

Aymeric

  • J'ai passé toute la mâtiné avec Fabrice à essayer d'installer OpenCV 2.0.0 sur ma machine virtuelle et tout l'après-midi à essayer de le faire fonctionner.
  • Prise de nombreux clichés ([2]) et échange avec notre professeur de traitement des images (Hélène Thomas) afin de parvenir à faire ressortir au mieux les LEDs.
  • Essais de détection par soustraction d'image avec un des exemples de la librairie OpenCV 2.0.0. Résultats très décevants. Une période de clignotement inférieure à 100ms n'est pas détectée et il apparait beaucoup de fausses détections au moindre mouvement.

TODO (Prochaine séance):

  • Il me faut trouver un moyen d'augmenter la fréquence de rafraichissement de la webcam afin de détecter des fréquences de clignotement plus forte. Il faut aussi limiter au maximum les fausses détections, par exemple en attendant que plus rien ne bouge avant de lancer le programme.
  • OpenCV 2.0.0 pourrait peut-être résoudre le problème rencontré par les troisième années, c'est à dire faire fonctionner le programme en HD avec une résolution de 1600x1200. La limitation d'OpenCV 1.1.0 est apparemment limitée à 800x600. Cela réduirait l'erreur sur l'estimation de distance. Il s'agit donc d'un point à travailler.


Olivier

  • Installation d'OpenCV 2.0 et de Code::Blocks sur machine virtuelle. Tout est ok, si ce n'est un petit problème au niveau de la récupération de la liste des périphériques lors de l'exécution des samples.
  • Debut de modélisation de l'interface et du fonctionnement interne.
  • Recherche de documentation sur la méthode de reconnaissance Haar-like, que j'ai découverte au sein de l'exemple d'OpenCV pour la reconnaissance faciale. Cette méthode repose sur un apprentissage à partir de collections d'images, qui permet de générer un fichier xml utilisé pour la reconnaissance en temps réel. Toutes les fonctions nécessaires sont disponibles dans OpenCV, mais certains rapports parlent de périodes d'apprentissage allant d'un jour à plusieurs semaines (pour des collections de plusieurs milliers d'images).

TODO :

  • Programmer la reconnaissance de formes simples, ainsi que la caractérisation par la couleur.
  • Détailler le modèle de fonctionnement interne. (avec la possibilité de rajouter des algorithmes simplement)
  • Approfondir la méthode Haar-like pour voir s'il est raisonnable de l'implémenter ou non.

Hamed et Fahd

Notes sur le travail prévisionnel de la séance précédente:
 Le système Criket n'utilisant pas l'échantillonage, nous nous limiterons dans un premier temps a détecter le front montant d'un signal simple non codé. 
 Par la suite nous passerons à la numérisation (voir les objectifs à court terme.

1) Objectifs à court terme:

  • Définir dans un premier temps une architecture simple permettant de : 
 - générer un signal non codé dans un premier temps
 - choisir un microcontrolleur, définitif avant première semaine de mars (CAN et PWM intégrés)
 - déclencher le timer et l'interruption
 - repérer le pic et déterminer l'intervalle de temps delta t
 - numériser ce signal

2) Travail effectué: 

 - installation du logiciel CCS 
 - documentation sur les microcontrolleurs ARM
 - récupération et compréhension des codes sources C pour les interruptions et le CAN (ARM)
 - Configuration d'un système sous Windows xp: installation de CCS, de l'IDE MPLAB.
 - Prise en main de ces divers outils, test d'implantation de code samples fournis par Microchip dans un PIC 16F887 à l'aide d'un programmeur PICkit 2 Debug Express.
 - Élaboration d'un code C de test qui sera utile pour détecter le front montant de l'onde sinusoïdale de l'ultra son. (problème auquel on se ramène en      
   essayant de chronométrer le temps qui sépare l'appui du bouton poussoir (équivalent du signal RF) et l'instant ou la valeur renvoyée par un CAN relié à   
   un potentiomètre dépasse un certain seuil (equivalent au signal ultrason).

3) Travail pour les séances à venir: 

 - finir le test sur le front montant
 - coder en C les algorithmes d'interruption et de traitement du signal non codé
 - faire si possible les premiers tests

Chen Hao

Séance du 02/03/2010

Aymeric

  • Installation d'OpenCV 2.0 sur Windows et de Microsoft Visual Studio 2010. Des problèmes se sont posés, car par défaut OpenCV 2.0 n'inclut les fichiers lib nécessaires à Visual Studio. J'ai alors du moi-même les construire avec CMake 2.6 . [3]
  • Lecture de deux tutoriel en ligne ([4] et [5]) afin de véritablement prendre en main OpenCV. Les 3/4 de la journée y sont passés.
  • Paramétrage de VS2010 (Librairies, Includes, Sources,...) pour fonctionner avec OpenCV 2.0 et début de codage du programme.

TODO (Dans trois semaines à cause du SIGEM) :

  • Continuer à se renseigner sur les méthodes d'OpenCV et trouver une solution pour un affichage en HD.
  • Coder la méthode par soustraction d'images en s'inspirant des exemples OpenCV.
  • Tester plusieurs méthodes de traitement d'images afin de faire ressortir au mieux les DELs.

Olivier

  • Problème d'accessibilité à la webcam sous la machine virtuelle. Un essai avec une autre webcam USB ne donne rien non plus. Comme OpenCV est multi-OS, je continuerai à programmer sous Windows.
  • Installation d'openCV 2.0 sous Windows. Rencontre des même problèmes qu'Aymeric, résolus avec ses fichiers.
  • Reparamétrage de Microsoft Visual Studio 2010 pour fonctionner avec OpenCV 2.0 et non plus Open CV.
  • Début de programmation de la reconnaisance des formes simples.

TODO (Dans trois semaines à cause du SIGEM) :

  • Modéliser le programme sous UML.
  • Continuer la reconnaissance des formes simples.

Hamed et Fahd

Notes sur le travail prévisionnel de la séance précédente: Afin d'aller plus vite, nous passons directement au choix du microcontrolleur et de ses périphériques.

Travail effectué:

  • Documentation sur la famille de microcontrolleur ARM7 de chez Analog Devices
  • Documentation sur différents transceivers RF
  • Choix après lecture de la datasheet de la famille ADuC7019/20/21/22/24/25/26/27/28/29 du microcontrolleur ADuC7026 
 en rapport aux critères fixés en amont (voir fin du rapport)
  • choix du transducteur Modem radio "DWA3"

Critères de choix du microcontrolleur:

-pwm

-2 voies

-multiplication 8 bits

-15-44 kHz for ultrsounds

-160kHz per channel

-PLA = mini FPGA

-voies i2c, serie

-pouvoir tester les signaux sur la plateforme.

-AVR testing.

Chen Hao

Séance du 12/03/2010

Aymeric

SIGEM

Olivier

SIGEM

Hamed et Fahd

-Lecture Datasheet du ADuC702x

-Prise en main des codes sources de l'ADuc et de la librairie C

-Soutenances des troisièmes années sur le projet carotte

Chen Hao

Séance du 30/03/2010

Aymeric

Matin : Rédaction de la micro-soutenance et mise en place du GANNT + Quelques tests sur les nouvelles LEDs 180° (Mr Gillou me fourni les plans de montage et les transistors pour alimenter correctement les LEDs)

Après-midi : Montage des robots (A continuer à la séance suivante)

Olivier

  • Préparation de la micro-soutenance et du GANTT
  • Absence l'après midi pour cause de visite médicale

Hamed et Fahd

  • Confection des PowerPoint pour la micro-soutenance et du GANNT.
  • Premier test sur la plateforme du DSPIC.
  • Recupération des modules RF et de leurs documentations.
  • Montage de la meute de robots.

Chen Hao

Séance du 06/04/2010

Aymeric

Montage des robots. Les 6 plateformes mobiles sont terminés. [6] et [7]

Olivier

Montage des robots.

Hamed et Fahd

Montage des robots.

Chen Hao

Séance du 13/04/2010

Aymeric

Matinée :
- Test des plateformes. Seulement 2 fonctionnent correctement.
- Les câblages ont été vérifiés et certains ressoudé dans le bon sens.
TODO : Re-tester les plateformes et effectuer les modifications nécessaires.


Aprés-midi :
- Confection d'un prototype en carton de "Tour à Leds" en forme de pyramide inversé avec sur chaque face une Led ultra-luminescente avec programme de clignotement à fréquence donnée. => [8] <=
- Codage du programme principal en C. Partie "Segmentation des couleurs" OK
TODO : Partie "Soustraction d'image" buggé. Il me faudra aller voir les doctorants à la prochaine séance pour régler le problème.

Olivier

  • Test des plateformes avec Aymeric :
    • 5 LabJacks ont été réparties entre les robots pour le moment.
    • On a également nommé les robots pour pouvoir effectuer un suivi individuel.
  • Programmation de la partie filtrage du programme :
    • mise en place de plusieurs filtres de défloutage.
    • ébauche d'une fonction de comparaison de performance des filtres, pour une aide à la décision.

Hamed et Fahd

-Test sur les modules radiofrèquence. -Réalisation du montage émetteur-récepteur sur un banc. 

*Nous avons dans un premier temps utilisé le logiciel hyperterminal sous linux pour essayer de
 faire communiquer les deux modules sans succès.
* Ce problème peut être due à un survoltage avec le câble de communication USB-SERIE qui sert en même temps de câble d'alimentation.

-Nous allons réessayer l'expérience avec accès port sous windows, mais nous nous heurtons pour l'instant à un problème de driver

Chen Hao

Séance du 27/04/2010

Aymeric

Partie Programmation :
- Confection de la V2 de la tour à LEDs. En m'inspirant du Playstation MOVE de Sony ([9]), j'ai eu l'idée de découper des balles de ping-pong et de les coller sur les LEDs. Ceci permet de supprimer les points blancs (zones hyper-luminescente posant problème à la segmentation de l'image car incolore) à la capture et d'augmenter le nombre de pixel à l'écran pour chaque LEDs. => [10] <=
- Avec l'aide de Fabrice, j'ai pu corriger le problème de la soustraction d'image.
TODO : - Appliquer la segmentation à l'image soustraite.
- Trouver le barycentre de chaque couleur.
- Appliquer les algorithmes géométriques pour en déduire la distance et l'angle.
- Modifier le programme pour traiter plusieurs robots à l'écran.
- Optimiser.


Partie Montage des Robots :
Recablage correct et test des plateformes restantes. 5 sur 7 sont au point. Les deux autres ont des problèmes d'origine encore inconnue.
TODO : - Monter le reste des composants (Webcams, LEDs, Télémètres laser, etc...)
- Acheter du tube PVC de diamètre 1 à 2 cm pour fixer les LEDs en hauteur et sur les cotés des robots. En effet, le prototype de tour à LEDs s'est avéré d'une précision insuffisante. Il faut éloigner davantage les DELs les unes des autres.

Olivier

  • Correction du cablage des robots avec Aymeric.
  • Programmation de la fonction de reconnaissance des formes simples
    • Une fois opérationnelle : elle détectera les formes géométriques de base, les couleur des contours, ainsi que les couleurs de remplissage.

TODO : poursuivre sur cette lancée.

Hamed et Fahd

-Montage des robots -test des modules ultrason sur un montage fait par un doctorant travaillant en acoustique sous-marine: 

*les modules ultrason testé ici en fréquence audible ont l'air de bien fonctionner
* les piezo bien qu'étant très directifs fonctionnent apparemment mieux que les micro qui récupèrent beaucoup de bruit

-Début du codage du dspic pour la génération du signal et son traitement, nous disposons déjà de fonctions opérationnel de génération et de filtrage de signaux Mais il apparaît que la version que nous avons de MPlab (V8) n'est pas compatible avec les fichiers dont nous disposons. -Actuellement nous avons contacté avec M.Pondhaven pour essayer de résoudre ce problème de compatibilité.

Chen Hao

Séance du 11/05/2010

Aymeric

Je suis allé à CASTORAMA acheter du tube PVC et des équerres pour construire un premier prototype avec une LED en hauteur, une LED de chaque coté du robot et une LED à l'arrière :
Image 1 : [11]
Je me suis vite rendu compte que c'était très stupide de ma part étant donné qu'on ne voyait vite plus que 2 LEDs sur les 3 nécessaires selon l'angle de vue.
Image 2 : [12]

Finalement, je me suis dit : Pourquoi utiliser quatre LEDs si le but est finalement de toujours en voir trois ?
J'ai donc supprimé la LED à l'arrière et ré-agencé les LEDs latérales de manière à les voir quelque soit l'angle de vue :
Image 3 : [13]
La différence de hauteur sur l'axe y entre la DEL en hauteur et l'une des DEL à l'arrière nous donnera la distance à laquelle se trouve le robot. Les positions des DELs selon l'axe x nous donnera l'angle du robot.
Je pensais au début qu'en faisant ainsi, il y aurait un problème quand un des tubes en cacherait un autre mais ici seul un des deux petits tubes peut être cacher. Quand ce sera le cas on connaitra en réalité exactement l'angle du vue qui engendre cette occlusion.
Image 4 : [14]
L'implémentation et les tests de la partie géométrique dans le programme C vont donc pouvoir commencer.

PS : Je suis fier de vous présenter quelque chose que j'ai trouvé et qui va permettre à CAROTTE d'avancer beaucoup plus vite ^^ :
Image 5 : [15]
Image 6 : [16]
Oui, nous n'auront désormais plus à reprendre possession de la table à chaque séance et à rassembler les morceaux éparpillés de nos robots maltraités par les autres groupes (o_O).

Olivier

  • Ecriture des fonctions de reconnaissance des cercles se basant sur le principe d'accumulateur de l'algorithme généralisé de Hough. Pour pouvoir accumuler les valeurs, j'ai du recréer des fonctions de tracer de cercles car celles existantes écrasent la valeur précédente d'un pixel. J'ai opté pour deux algorithmes de tracé rapide de cercles : l'algorithme de Bresenham et l'algorithme d'Andres.
  • Les cercles sont reconnus mais j'ai eu un problème dans le choix du seuil de détection. Le seuil doit être fonction du rayon car un grand cercle contient plus de pixel qu'un petit cercle. Je calcule donc le nombre de pixels des cercles et place le seuil à environ 25% de cette valeur.
  • L'algorithme d'Andres est alors apparu comme incompatible avec cette technique. En effet, son principe est d'obtenir un pavage complet du plan lorsqu'on trace des cercles concentriques [17].
    • L'avantage est, pour un centre donné, de pouvoir associer chaque pixel de l'image à un unique cercle.
    • L'inconvénient vient du fait qu'un cercle de taille N peut contenir plus de pixel qu'un cercle de taille N+1. Le seuillage est alors faussé.
  • L'algorithme de Bresenham, quant à lui, convient bien au seuillage progressif. En revanche, il ne parvient pas à remplir tout le plan : il y a des "trous" [18]
  • Après le problème de seuillage plus ou moins résolu, vient le problème de détection multiple d'un même cercle. Du fait de la discrétisation, les maximums de l'accumulateur ne sont pas des points mais des amas de points (amas à 3 dimensions vu que les cercles nécessitent 3 paramètres. La recherche de maximum est actuellement effectué pour chaque rayon, indépendamment des autres. Les amas de points ne peuvent donc pas être moyennés selon les 3 dimensions.

Hamed et Fahd

-Résolution du problème de compilateur de MPLAB

-Génération d'un sinus (éventuellement bruité) sur un module piézo avec une fréquence de 3KHZ avec notre DSPIC

-le module piezo emet un signal (sinus) audible (3khz)

- Réalisation du montage émission réception en Radio fréquence

-Le montage fonctionne parfaitement sur le banc d'essaie (logiciel utilisé: Access port)

Travail à venir: Générer le sinus à une fréquence différente et procéder au codaage du sgnal

refaire le montage des module RF avec les DSPIC.

Chen Hao

Séance du 18/05/2010

Aymeric

N'étant pas satisfait de la segmentation de l'image, j'ai fait des dizaines de mesures de la valeur HSV de chaque LEDs vue par la webcam dans différentes conditions d'éclairages. Je les ai ensuite représenté sous Scilab en 3D afin d'en dégager 3 sphères contenant 95% des valeurs de chaque DELs. Résultat : [19] (Les losanges représente la DEL rouge, les croix la bleu et les croix entourées la verte). J'arrive donc bien à segmenter la rouge qui possède deux zones distinctes mais les valeurs de la bleu et de la verte sont vraiment entremêlées. Je me suis cependant rappelé que je travaillais en HSV afin de segmenter la DEL jaune mais qu'ayant décider de la supprimer, il serait beaucoup plus logique de travailler en RVB. J'ai donc refait quelques mesures et retracé le graphique : [20] Les nuages points sont bien mieux séparés. J'ai alors pu bien mieux en déduire les valeurs à segmenter. Malgré cela, selon l'exposition lumineuse, les valeurs RVB variaient de manière non-linéaire (Ce qui n'était pas le cas en HSV) et l'ajustement automatique du contraste et du gain de la webcam rendaient la détection impossible dans certains cas. Après avoir passé des heures à essayer de trouver sur internet comment régler le gain en exposition et l'intensité des couleurs de la webcam en C, je me suis finalement rendu compte que j'aurais du faire quelque chose il y a longtemps : Installer les pilotes officiels de la webcam. Grâce aux logiciels intégrés, j'ai alors pu faire vivement ressortir les couleurs des DELs en toutes circonstances.

J'ai passé le reste de la journée à trouver d'où venait le fait que le programme plantait au bout de 3 minutes d'utilisation. Cela venait en fait d'un cvCloneImage dans ma boucle de fonctionnement. Cette commande recréait à chaque fois une nouvelle IplImage sans supprimer la précédente et remplissait la mémoire vive. Il fallait en fait que je fasse un cvCreateImage avant la boucle et un cvCopyImage dedans.

Enfin j'ai commencé à travailler sur la synchronisation entre la fréquence de capture des images et la fréquence de clignotement des DELs. Il me faut en effet prendre en compte le temps d'exécution des traitements d'image et coder un algorithme qui ajustera la valeur dans le cvWait de ma boucle en fonction du frame-rate calculé.

Olivier

  • Pour pallier au problème de la détection multiple d'un même cercle, j'ai décider de remanier le code. J'ai alors créé une structure qui accueille un espace de Hough non limité en dimension.
  • J'ai ensuite repris l'algorithme de Hough standard pour créer les fonctions permettant de rechercher les droites dans une image, et ce en implémentant la structure précédemment créée. La collection de fonction pour la version 2D de l'algorithme est la suivante : 

//2D HoughSpace functions set (to recognize polygones)

void ctFindMaximum2D(CtHoughSpace *houghSpace);

void ctFindMaxima2D(CtHoughSpace *houghSpace, int threshold);

void ctHoughLines(IplImage *source, CtHoughSpace **pHoughSpace);


void ctDrawHoughSpace2D(CtHoughSpace *houghSpace);

void ctDrawMaxima2D(CtHoughSpace *houghSpace, int threshold);

void ctDrawLines(CtHoughSpace *houghSpace, int threshold);

  • Rq : Les 3 fonctions principales sont les 3 premières. Les 3 suivantes permettent de voir l'espace de Hough ainsi que le résultat.
  • Rq2 : J'ai rajouté "ct" devant le nom des fonctions pour suivre le modèle utilisé dans OpenCV, dont toutes les fonctions commencent par "cv". Il signifie simplement "Carotte".
  • La semaine prochaine, j'étends ces fonctions à la 3e dimension pour les cercles.

Hamed et Fahd

-Génération avec le dspic d'une sinusoide de fréquence variable (j'usqu'au ultrason) en utilisant le processeur

- Récupération et test de différents code sur le site de microship concernant les pwm

- essaie avec les pwm du dspic

- Début rédaction du rapport projet industriel

Chen Hao

Séance du 25/05/2010

Aymeric

1. Réalisation d'une interface graphique dans le style d'un radar permettant de voire en un coup d'oeil la distance et l'angle du robot.

2. Aprés avoir déterminé théoriquement l'équation reliant la distance de la webcam au robot au nombre de pixel séparant la DEL en hauteur aux DELs en contre-bas, j'ai réalisé une dizaines de mesures en pratique. L'équation théorique est de la forme d = l * 1/x ou d est la distance, l la distance focale de la lentille de la webcam et x le nombre de pixel d'écart. En réalisant la courbe de tendance des mesures pratiques, j'obtient d = 8857 * x^(-1.075) ce qui colle parfaitment au modèle théorique.

3. Implantation de la formule dans le programme. Les tests donnent des résultats satisfaisants : Jusqu'a 7m, l'erreur sur la mesure de distance est de plus ou moins 8cm.

Il ne me reste plus qu'a faire de même pour l'angle.

Olivier

  • J'ai continué le travail commencé la semaine dernière en écrivant la collection de fonctions nécessaires pour la reconnaissance des cercles : 

//3D HoughSpace functions set (to recognize circles)

void ctFindMaximum3D(CtHoughSpace *houghSpace);

void ctFindMaxima3D(CtHoughSpace *houghSpace, int threshold);

void ctHoughCircles(IplImage *source, CtHoughSpace **pHoughSpace);


void ctDrawHoughSpace3D(CtHoughSpace *houghSpace, CvScalar normal);

void ctDrawMaxima3D(CtHoughSpace *houghSpace, CvScalar normal, int threshold);

void ctDrawCircles(CtHoughSpace *houghSpace, int threshold);

  • Rq : Ce travail, même s'il semble fastidieux et redondant, est essentiel pour gagner en vitesse d'exécution. En effet, j'avais initialement commencé à faire les 3 fonctions principales indépendantes de la dimension de l'espace de Hough. Le code, plus compliqué à écrire, s'est également avéré très lent pour la dimension 2. J'ai donc abandonné cette idée.
  • Pour pouvoir reconnaitre les ellipses, il suffirait maintenant de réécrire ces fonctions en tenant compte de la quatrième dimension.

Hamed et Fahd

-L'émission fonctionnant, nous nous concentrons désormais exclusivement sur l'amplification et la réception.

-La documentation et les applications notes de microship ne nous fournissent pas des exemples exploitables.

-Rédaction du rapport.

Chen Hao

Séance du 01/06/2010

Aymeric

Réalisation UML du projet avec Olivier.
Confection et mise en place des LEDs sur deux autres robots. (Avancement : 75%)

Olivier

  • Avec Aymeric, après avoir détaillé l'architecture UML de nos programmes sur papier, nous l'avons rentrée dans l'application poséidon 6. Bien qu'essentiel, ce travail s'est avéré aussi long à faire sur papier qu'à recopier sur ordinateur (surtout quand l'application plante et perd des diagrammes).

Hamed et Fahd

Chen Hao

Récupérée de « http://media.ensta-bretagne.fr/robotics/index.php/Bilan_de_chaque_s%C3%A9ance »
Outils personnels