Wiki de Projets IMA - Contributions de l’utilisateur [fr]

IMA4 2017/2018 P44

2018-05-15T23:19:19Z

Zbriois : /* Documents Rendus */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Séance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,25
| 0,25
| 0,5
| 1
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|-
| 2. Traitement a faire sur l'image (opencv, filtres ...)
| 5
| 4
| 4
| 5
| 13
|-
| 3. Récupérer les images depuis la caméra
| 4
| 4
| 5
| 4
| 13
|-
| 4. Comparaison avec la banque d'image
| 8
|
|
|
|
|-
| 5. Positionnement de la camera
| 2
| 2
|
|
| 2
|-
| '''TOTAL'''
| 24
| 10,25
| 9,25
| 9,5
| 19
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Feuille d'heures Mars==

{| class="wikitable"
!Tâches Mars !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,5
| 0,5
| 0,5
| 1,5
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
| 3
|
|
| 3
|-
| 2. Reconnaissance (Tenserflow)
| 8
| 2
| 5
| 6
| 13
|-
| 3. Prise en main de ROS associé a la caméra
| 8
| 4
| 6
| 6
| 16
|-
| '''TOTAL'''
| 19
| 9,5
| 11,5
| 12,5
| 23,5
|}

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
** avec le realsense-viewer on arrive bien a récupérer les informations de la caméra: [[Fichier:capture1.jpeg|600px|center]]
** cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue: [[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

==Mars : Séance 4 - 28/03/18==
;Bases d'utilisation de ROS:
:Pour exécuter un programme ROS il faut utiliser des fichiers spéciaux: les launch files. Pour lancer un launch file : ''roslaunch <package_name> <launch_file>'' qui prend en paramètre le nom du package qui contient le launch file et le launch file lui même. ROS utilise des packages pour organiser ses programmes. Un package contient:
::- dossier launch qui contient les launch files
::- dossier src qui contient les fichiers sources (c++, python ...)
::- fichier CMakeLists.txt qui contient la liste des règles cmake pour la compilation
::- fichier package.xml qui contient les informations/dépendances du package 
:Pour aller dans un package: ''roscd <package_name>'' 
:Tout les fichiers launch contient un <launch> tag, dans ce tag on trouve un <node> tag, dans lequel on spécifie:
::- pkg=“package_name”, nom du package qui contient le code pour le programme ROS a exécuter
::- type=“python_file_name.py”, nom du programme qu'on veut exécuter>
::- name=“node_name”, nom du node qui va launch le fichier Python
::- output=“type_of_output” ,c'est dans cette chaîne qu'on va imprimer la sortie du fichier Python.
:Comment créer un package ? 
::- les packages que nous allons créer seront dans le dossier catkin_ws pour qu'ils puissent être exécutés par ROS,
::- ''roscd'' permet d'accéder au répertoire catkin_ws/devel,
::- nos packages seront a placer dans catkin_ws/src,
::- ''catkin_create_pkg <package_name> <package_dependecies>'' permet de créer un nouveau package,
::- ''rospack list | grep my_package'' permet de vérifier que le package a bien été crée.

;Tentative de création de package 
:Nous avons d'abord tenté de créer un package d'après les explications juste au dessus, mais nous obtenions une erreur ''Invalid roslaunch XML syntax: not well-formed'' 
:Supposant qu'il s'agissait d'un problème de mauvaise syntaxe au niveau des paramètres du fichier ''projet_launch_file.launch'', nous avons suivi le tutoriel http://www.theconstructsim.com/ros-for-beginners/ afin de vérifier simplement que nous pouvions créer un package sans erreur avec un fichier python des plus basique. Cependant nous avons toujours le même problème d'erreur de syntaxe XML:
[[Fichier:Capturepackage.jpg|600px|center]]

==Feuille d'heures Avril==

{| class="wikitable"
!Tâches Mars !! Séance 1 !! Séance 2 !! Séance 3 !! Open German !! Total
|-
| ''Wiki''
|
| 0,5
|
| 0,5
| 1
|-
| 1. Reconnaissance d'image sur la carte
| 2,5
| 2
|
|
| 4,5
|-
| 1. Reconnaissance d'image sur l'ordinateur
|
|
| 4
| 50
| 54
|-
| 2. Placement finale de la caméra
| 3,5
|
|
| 0,5
| 4
|-
| 3. Récupération des pointCloude2
| 3,5
| 2
|
|
| 5,5
|-
| '''TOTAL'''
| 9,5
| 4,5
| 4
| 51
| 68
|}

==Avril : Séance 1 - 04/04/18==
;création de package
:Problème de la semaine dernière résolu après recopie a la main du fichier my_package_launch_file.launch, il devait s'agir de la présence d'un caractère non imprimable.

;Placement de la caméra
:choix de la position
:étude du champs de vision réel de la caméra

;Installation de TensorFlow sur la carte
:On a eu un problème car les instructions AVX ne sont pas supportées par la carte
La compétition arrive bientot donc on va se concentrer sur la partie ROS. On fera fonctionner notre programme sur un ordinateur dans un premier temps.

==Avril : Séance 2 - 11/04/18==

Installation de ROS (sur le deuxième PC)

Détermination de la position exacte de la caméra sur la plateforme du Robotino.

Début du script pour la reconnaissance d'image

==Avril : Séance 3 - 18/04/18==
; Avancement sur les scripts d’exécution de Tensorflow:
:Un script de lancement pour entrainer l'algorithme de reconnaissance d'image
:Un script qui prend en entrée le nom d'une image et retourne le nom de l'objet pris sur la photo avec le pourcentage de certitude

==Avril : Semaine de l'Open German ==
; Installation de Tensorflow (sur le deuxième PC):
: Problème de lancement de Tensorflow via ROS, ROS ne cherchait pas Tensorflow au bon endroit (certainement à cause du multi-versions Python)

; Décision de filtre final:
: Tentative de filtre passthrought et voxel grid: échec. Malgré un appel et des paramétrages correspondants aux tutoriels ROS et une compilation sans erreur le filtre ne s'effectue pas.
: Filtre "à la main": tout les pointsclouds récupérés de la caméra dont la distance sur l'axe z est supérieure à la portée infrarouge de la caméra sont transformés en pixels noirs.

; Prise de différents sets d'images des MPS:
: Avec caméra correctement placée sur le robot: sans filtre, 2 filtres cannys différents, sobel x, sobel y, laplacien,
: Même chose mais avec caméra à une hauteur aléatoire,
: Caméra sur le robot, proche de la MPS et filtre "à la main"
: Vidéo prise pour chaque MPS, puis découpage en images pour avoir plus de 600 images par MPS

; Ne concernant pas directement le projet:
: préparation de l'inventaire
: arbitrage
: montage des robots

; Optimisation de l'algorithme de reconnaissance d'image
: Création de plusieurs algorithmes de reconnaissance d'image (changement de paramètre pour déterminer le meilleur)
: Test de reconnaissance d'image de chaque MPS avec algorithmes
: Analyse des résultats et optimisation du script de reconnaissance

=Documents Rendus=
[[Media:Rapport_final_P44_bis.pdf]] 
https://archives.plil.fr/zbriois/PROJET_4A.git

IMA4 2017/2018 P44

2018-05-15T23:19:06Z

Zbriois : /* Documents Rendus */

IMA4 2017/2018 P44

2018-05-15T22:54:53Z

Zbriois : /* Documents Rendus */

Fichier:Rapport final P44 bis.pdf

2018-05-15T22:54:26Z

Zbriois : avec les images

avec les images

IMA4 2017/2018 P44

2018-05-15T22:13:47Z

Zbriois : /* Feuille d'heures Avril */

IMA4 2017/2018 P44

2018-05-15T22:13:34Z

Zbriois : /* Feuille d'heures Avril */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Séance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,25
| 0,25
| 0,5
| 1
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|-
| 2. Traitement a faire sur l'image (opencv, filtres ...)
| 5
| 4
| 4
| 5
| 13
|-
| 3. Récupérer les images depuis la caméra
| 4
| 4
| 5
| 4
| 13
|-
| 4. Comparaison avec la banque d'image
| 8
|
|
|
|
|-
| 5. Positionnement de la camera
| 2
| 2
|
|
| 2
|-
| '''TOTAL'''
| 24
| 10,25
| 9,25
| 9,5
| 19
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Feuille d'heures Mars==

{| class="wikitable"
!Tâches Mars !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,5
| 0,5
| 0,5
| 1,5
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
| 3
|
|
| 3
|-
| 2. Reconnaissance (Tenserflow)
| 8
| 2
| 5
| 6
| 13
|-
| 3. Prise en main de ROS associé a la caméra
| 8
| 4
| 6
| 6
| 16
|-
| '''TOTAL'''
| 19
| 9,5
| 11,5
| 12,5
| 23,5
|}

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
** avec le realsense-viewer on arrive bien a récupérer les informations de la caméra: [[Fichier:capture1.jpeg|600px|center]]
** cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue: [[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

==Mars : Séance 4 - 28/03/18==
;Bases d'utilisation de ROS:
:Pour exécuter un programme ROS il faut utiliser des fichiers spéciaux: les launch files. Pour lancer un launch file : ''roslaunch <package_name> <launch_file>'' qui prend en paramètre le nom du package qui contient le launch file et le launch file lui même. ROS utilise des packages pour organiser ses programmes. Un package contient:
::- dossier launch qui contient les launch files
::- dossier src qui contient les fichiers sources (c++, python ...)
::- fichier CMakeLists.txt qui contient la liste des règles cmake pour la compilation
::- fichier package.xml qui contient les informations/dépendances du package 
:Pour aller dans un package: ''roscd <package_name>'' 
:Tout les fichiers launch contient un <launch> tag, dans ce tag on trouve un <node> tag, dans lequel on spécifie:
::- pkg=“package_name”, nom du package qui contient le code pour le programme ROS a exécuter
::- type=“python_file_name.py”, nom du programme qu'on veut exécuter>
::- name=“node_name”, nom du node qui va launch le fichier Python
::- output=“type_of_output” ,c'est dans cette chaîne qu'on va imprimer la sortie du fichier Python.
:Comment créer un package ? 
::- les packages que nous allons créer seront dans le dossier catkin_ws pour qu'ils puissent être exécutés par ROS,
::- ''roscd'' permet d'accéder au répertoire catkin_ws/devel,
::- nos packages seront a placer dans catkin_ws/src,
::- ''catkin_create_pkg <package_name> <package_dependecies>'' permet de créer un nouveau package,
::- ''rospack list | grep my_package'' permet de vérifier que le package a bien été crée.

;Tentative de création de package 
:Nous avons d'abord tenté de créer un package d'après les explications juste au dessus, mais nous obtenions une erreur ''Invalid roslaunch XML syntax: not well-formed'' 
:Supposant qu'il s'agissait d'un problème de mauvaise syntaxe au niveau des paramètres du fichier ''projet_launch_file.launch'', nous avons suivi le tutoriel http://www.theconstructsim.com/ros-for-beginners/ afin de vérifier simplement que nous pouvions créer un package sans erreur avec un fichier python des plus basique. Cependant nous avons toujours le même problème d'erreur de syntaxe XML:
[[Fichier:Capturepackage.jpg|600px|center]]

==Feuille d'heures Avril==

{| class="wikitable"
!Tâches Mars !! Séance 1 !! Séance 2 !! Séance 3 !! Open German !! Total
|-
| ''Wiki''
|
| 0,5
|
| 0,5
| 1
|-
| 1. Reconnaissance d'image sur la carte
| 2,5
| 2
|
|
| 4,5
|-
| 1. Reconnaissance d'image sur l'ordinateur
|
|
| 4
| 50
| 54
|-
| 2. Placement finale de la caméra
| 3,5
|
|
| 0,5
| 4
|-
| 3. Récupération des pointCloude2
| 3,5
| 2
|
|
| 5,5
|-
| '''TOTAL'''
| 9,5
| 4,5
| 4
| 50
| 68
|}

==Avril : Séance 1 - 04/04/18==
;création de package
:Problème de la semaine dernière résolu après recopie a la main du fichier my_package_launch_file.launch, il devait s'agir de la présence d'un caractère non imprimable.

;Placement de la caméra
:choix de la position
:étude du champs de vision réel de la caméra

;Installation de TensorFlow sur la carte
:On a eu un problème car les instructions AVX ne sont pas supportées par la carte
La compétition arrive bientot donc on va se concentrer sur la partie ROS. On fera fonctionner notre programme sur un ordinateur dans un premier temps.

==Avril : Séance 2 - 11/04/18==

Installation de ROS (sur le deuxième PC)

Détermination de la position exacte de la caméra sur la plateforme du Robotino.

Début du script pour la reconnaissance d'image

==Avril : Séance 3 - 18/04/18==
; Avancement sur les scripts d’exécution de Tensorflow:
:Un script de lancement pour entrainer l'algorithme de reconnaissance d'image
:Un script qui prend en entrée le nom d'une image et retourne le nom de l'objet pris sur la photo avec le pourcentage de certitude

==Avril : Semaine de l'Open German ==
; Installation de Tensorflow (sur le deuxième PC):
: Problème de lancement de Tensorflow via ROS, ROS ne cherchait pas Tensorflow au bon endroit (certainement à cause du multi-versions Python)

; Décision de filtre final:
: Tentative de filtre passthrought et voxel grid: échec. Malgré un appel et des paramétrages correspondants aux tutoriels ROS et une compilation sans erreur le filtre ne s'effectue pas.
: Filtre "à la main": tout les pointsclouds récupérés de la caméra dont la distance sur l'axe z est supérieure à la portée infrarouge de la caméra sont transformés en pixels noirs.

; Prise de différents sets d'images des MPS:
: Avec caméra correctement placée sur le robot: sans filtre, 2 filtres cannys différents, sobel x, sobel y, laplacien,
: Même chose mais avec caméra à une hauteur aléatoire,
: Caméra sur le robot, proche de la MPS et filtre "à la main"
: Vidéo prise pour chaque MPS, puis découpage en images pour avoir plus de 600 images par MPS

; Ne concernant pas directement le projet:
: préparation de l'inventaire
: arbitrage
: montage des robots

; Optimisation de l'algorithme de reconnaissance d'image
: Création de plusieurs algorithmes de reconnaissance d'image (changement de paramètre pour déterminer le meilleur)
: Test de reconnaissance d'image de chaque MPS avec algorithmes
: Analyse des résultats et optimisation du script de reconnaissance

=Documents Rendus=

IMA4 2017/2018 P44

2018-05-15T22:12:11Z

Zbriois : /* Avril : Séance 3 - 18/04/18 */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Séance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,25
| 0,25
| 0,5
| 1
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|-
| 2. Traitement a faire sur l'image (opencv, filtres ...)
| 5
| 4
| 4
| 5
| 13
|-
| 3. Récupérer les images depuis la caméra
| 4
| 4
| 5
| 4
| 13
|-
| 4. Comparaison avec la banque d'image
| 8
|
|
|
|
|-
| 5. Positionnement de la camera
| 2
| 2
|
|
| 2
|-
| '''TOTAL'''
| 24
| 10,25
| 9,25
| 9,5
| 19
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Feuille d'heures Mars==

{| class="wikitable"
!Tâches Mars !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,5
| 0,5
| 0,5
| 1,5
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
| 3
|
|
| 3
|-
| 2. Reconnaissance (Tenserflow)
| 8
| 2
| 5
| 6
| 13
|-
| 3. Prise en main de ROS associé a la caméra
| 8
| 4
| 6
| 6
| 16
|-
| '''TOTAL'''
| 19
| 9,5
| 11,5
| 12,5
| 23,5
|}

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
** avec le realsense-viewer on arrive bien a récupérer les informations de la caméra: [[Fichier:capture1.jpeg|600px|center]]
** cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue: [[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

==Mars : Séance 4 - 28/03/18==
;Bases d'utilisation de ROS:
:Pour exécuter un programme ROS il faut utiliser des fichiers spéciaux: les launch files. Pour lancer un launch file : ''roslaunch <package_name> <launch_file>'' qui prend en paramètre le nom du package qui contient le launch file et le launch file lui même. ROS utilise des packages pour organiser ses programmes. Un package contient:
::- dossier launch qui contient les launch files
::- dossier src qui contient les fichiers sources (c++, python ...)
::- fichier CMakeLists.txt qui contient la liste des règles cmake pour la compilation
::- fichier package.xml qui contient les informations/dépendances du package 
:Pour aller dans un package: ''roscd <package_name>'' 
:Tout les fichiers launch contient un <launch> tag, dans ce tag on trouve un <node> tag, dans lequel on spécifie:
::- pkg=“package_name”, nom du package qui contient le code pour le programme ROS a exécuter
::- type=“python_file_name.py”, nom du programme qu'on veut exécuter>
::- name=“node_name”, nom du node qui va launch le fichier Python
::- output=“type_of_output” ,c'est dans cette chaîne qu'on va imprimer la sortie du fichier Python.
:Comment créer un package ? 
::- les packages que nous allons créer seront dans le dossier catkin_ws pour qu'ils puissent être exécutés par ROS,
::- ''roscd'' permet d'accéder au répertoire catkin_ws/devel,
::- nos packages seront a placer dans catkin_ws/src,
::- ''catkin_create_pkg <package_name> <package_dependecies>'' permet de créer un nouveau package,
::- ''rospack list | grep my_package'' permet de vérifier que le package a bien été crée.

;Tentative de création de package 
:Nous avons d'abord tenté de créer un package d'après les explications juste au dessus, mais nous obtenions une erreur ''Invalid roslaunch XML syntax: not well-formed'' 
:Supposant qu'il s'agissait d'un problème de mauvaise syntaxe au niveau des paramètres du fichier ''projet_launch_file.launch'', nous avons suivi le tutoriel http://www.theconstructsim.com/ros-for-beginners/ afin de vérifier simplement que nous pouvions créer un package sans erreur avec un fichier python des plus basique. Cependant nous avons toujours le même problème d'erreur de syntaxe XML:
[[Fichier:Capturepackage.jpg|600px|center]]

==Feuille d'heures Avril==

{| class="wikitable"
!Tâches Mars !! Séance 1 !! Séance 2 !! Séance 3 !! Open German !! Total
|-
| ''Wiki''
|
| 0,5
|
| 0,5
| 1
|-
| 1. Reconnaissance d'image sur la carte
| 2,5
| 2
|
|
| 4,5
|-
| 1. Reconnaissance d'image sur l'ordinateur
|
|
| 4
| 50
| 54
|-
| 2. Placement finale de la caméra
| 3,5
|
|
|
| 3,5
|-
| 3. Récupération des pointCloude2
| 3,5
| 2
|
|
| 5,5
|-
| '''TOTAL'''
| 9,5
| 4,5
| 4
| 50
| 68
|}

==Avril : Séance 1 - 04/04/18==
;création de package
:Problème de la semaine dernière résolu après recopie a la main du fichier my_package_launch_file.launch, il devait s'agir de la présence d'un caractère non imprimable.

;Placement de la caméra
:choix de la position
:étude du champs de vision réel de la caméra

;Installation de TensorFlow sur la carte
:On a eu un problème car les instructions AVX ne sont pas supportées par la carte
La compétition arrive bientot donc on va se concentrer sur la partie ROS. On fera fonctionner notre programme sur un ordinateur dans un premier temps.

==Avril : Séance 2 - 11/04/18==

Installation de ROS (sur le deuxième PC)

Détermination de la position exacte de la caméra sur la plateforme du Robotino.

Début du script pour la reconnaissance d'image

==Avril : Séance 3 - 18/04/18==
; Avancement sur les scripts d’exécution de Tensorflow:
:Un script de lancement pour entrainer l'algorithme de reconnaissance d'image
:Un script qui prend en entrée le nom d'une image et retourne le nom de l'objet pris sur la photo avec le pourcentage de certitude

==Avril : Semaine de l'Open German ==
; Installation de Tensorflow (sur le deuxième PC):
: Problème de lancement de Tensorflow via ROS, ROS ne cherchait pas Tensorflow au bon endroit (certainement à cause du multi-versions Python)

; Décision de filtre final:
: Tentative de filtre passthrought et voxel grid: échec. Malgré un appel et des paramétrages correspondants aux tutoriels ROS et une compilation sans erreur le filtre ne s'effectue pas.
: Filtre "à la main": tout les pointsclouds récupérés de la caméra dont la distance sur l'axe z est supérieure à la portée infrarouge de la caméra sont transformés en pixels noirs.

; Prise de différents sets d'images des MPS:
: Avec caméra correctement placée sur le robot: sans filtre, 2 filtres cannys différents, sobel x, sobel y, laplacien,
: Même chose mais avec caméra à une hauteur aléatoire,
: Caméra sur le robot, proche de la MPS et filtre "à la main"
: Vidéo prise pour chaque MPS, puis découpage en images pour avoir plus de 600 images par MPS

; Ne concernant pas directement le projet:
: préparation de l'inventaire
: arbitrage
: montage des robots

; Optimisation de l'algorithme de reconnaissance d'image
: Création de plusieurs algorithmes de reconnaissance d'image (changement de paramètre pour déterminer le meilleur)
: Test de reconnaissance d'image de chaque MPS avec algorithmes
: Analyse des résultats et optimisation du script de reconnaissance

=Documents Rendus=

IMA4 2017/2018 P44

2018-05-01T17:58:48Z

Zbriois :

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Séance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,25
| 0,25
| 0,5
| 1
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|-
| 2. Traitement a faire sur l'image (opencv, filtres ...)
| 5
| 4
| 4
| 5
| 13
|-
| 3. Récupérer les images depuis la caméra
| 4
| 4
| 5
| 4
| 13
|-
| 4. Comparaison avec la banque d'image
| 8
|
|
|
|
|-
| 5. Positionnement de la camera
| 2
| 2
|
|
| 2
|-
| '''TOTAL'''
| 24
| 10,25
| 9,25
| 9,5
| 19
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Feuille d'heures Mars==

{| class="wikitable"
!Tâches Mars !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,5
| 0,5
| 0,5
| 1,5
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
| 3
|
|
| 3
|-
| 2. Reconnaissance (Tenserflow)
| 8
| 2
| 5
| 6
| 13
|-
| 3. Prise en main de ROS associé a la caméra
| 8
| 4
| 6
| 6
| 16
|-
| '''TOTAL'''
| 19
| 9,5
| 11,5
| 12,5
| 23,5
|}

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
** avec le realsense-viewer on arrive bien a récupérer les informations de la caméra: [[Fichier:capture1.jpeg|600px|center]]
** cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue: [[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

==Mars : Séance 4 - 28/03/18==
;Bases d'utilisation de ROS:
:Pour exécuter un programme ROS il faut utiliser des fichiers spéciaux: les launch files. Pour lancer un launch file : ''roslaunch <package_name> <launch_file>'' qui prend en paramètre le nom du package qui contient le launch file et le launch file lui même. ROS utilise des packages pour organiser ses programmes. Un package contient:
::- dossier launch qui contient les launch files
::- dossier src qui contient les fichiers sources (c++, python ...)
::- fichier CMakeLists.txt qui contient la liste des règles cmake pour la compilation
::- fichier package.xml qui contient les informations/dépendances du package 
:Pour aller dans un package: ''roscd <package_name>'' 
:Tout les fichiers launch contient un <launch> tag, dans ce tag on trouve un <node> tag, dans lequel on spécifie:
::- pkg=“package_name”, nom du package qui contient le code pour le programme ROS a exécuter
::- type=“python_file_name.py”, nom du programme qu'on veut exécuter>
::- name=“node_name”, nom du node qui va launch le fichier Python
::- output=“type_of_output” ,c'est dans cette chaîne qu'on va imprimer la sortie du fichier Python.
:Comment créer un package ? 
::- les packages que nous allons créer seront dans le dossier catkin_ws pour qu'ils puissent être exécutés par ROS,
::- ''roscd'' permet d'accéder au répertoire catkin_ws/devel,
::- nos packages seront a placer dans catkin_ws/src,
::- ''catkin_create_pkg <package_name> <package_dependecies>'' permet de créer un nouveau package,
::- ''rospack list | grep my_package'' permet de vérifier que le package a bien été crée.

;Tentative de création de package 
:Nous avons d'abord tenté de créer un package d'après les explications juste au dessus, mais nous obtenions une erreur ''Invalid roslaunch XML syntax: not well-formed'' 
:Supposant qu'il s'agissait d'un problème de mauvaise syntaxe au niveau des paramètres du fichier ''projet_launch_file.launch'', nous avons suivi le tutoriel http://www.theconstructsim.com/ros-for-beginners/ afin de vérifier simplement que nous pouvions créer un package sans erreur avec un fichier python des plus basique. Cependant nous avons toujours le même problème d'erreur de syntaxe XML:
[[Fichier:Capturepackage.jpg|600px|center]]

==Feuille d'heures Avril==

{| class="wikitable"
!Tâches Mars !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
|
| 0,5
|
|
|-
| 1. Reconnaissance d'image sur la carte
| 2,5
| 2
|
|
|-
| 2. Placement finale de la caméra
| 3,5
|
|
|
|-
| 3. Récupération des pointCloude2
| 3,5
| 2
|
|
|-
| '''TOTAL'''
| 9,5
| 4,5
|
|
|}

==Avril : Séance 1 - 04/04/18==
;création de package
:Problème de la semaine dernière résolu après recopie a la main du fichier my_package_launch_file.launch, il devait s'agir de la présence d'un caractère non imprimable.

;Placement de la caméra
:choix de la position
:étude du champs de vision réel de la caméra

;Installation de TensorFlow sur la carte
:On a eu un problème car les instructions AVX non supportées par la carte
La compétition arrive bientot donc on va se concentrer sur la partie ROS. On fera fonctionner notre programme sur un ordinateur dans un premier temps.

==Avril : Séance 2 - 11/04/18==

Installation de ROS (sur le deuxième PC)

Détermination de la position exacte de la caméra sur la plateforme du Robotino.

Début du script pour la reconnaissance d'image:nd

==Avril : Séance 3 - 18/04/18==
; Avancement sur les scripts d’exécution de Tensorflow:

==Avril : Semaine de l'Open German ==
; Installation de Tensorflow (sur le deuxième PC):
: Problème de lancement de Tensorflow via ROS, ROS ne cherchait pas Tensorflow au bon endroit (certainement à cause du multi-versions Python)

; Décision de filtre final:
: Tentative de filtre passthrought et voxel grid: échec. Malgré un appel et des paramétrages correspondants aux tutoriels ROS et une compilation sans erreur le filtre ne s'effectue pas.
: Filtre "à la main": tout les pointsclouds récupérés de la caméra dont la distance sur l'axe z est supérieure à la portée infrarouge de la caméra sont transformés en pixels noirs.

; Prise de différents sets d'images des MPS:
: Avec caméra correctement placée sur le robot: sans filtre, 2 filtres cannys différents, sobel x, sobel y, laplacien,
: Même chose mais avec caméra à une hauteur aléatoire,
: Caméra sur le robot, proche de la MPS et filtre "à la main"

; Ne concernant pas directement le projet:
: arbitrage,
: montage des robots

=Documents Rendus=

IMA4 2017/2018 P44

2018-05-01T17:44:35Z

Zbriois : /* Avril : Séance 2 - 11/04/18 */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Séance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,25
| 0,25
| 0,5
| 1
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|-
| 2. Traitement a faire sur l'image (opencv, filtres ...)
| 5
| 4
| 4
| 5
| 13
|-
| 3. Récupérer les images depuis la caméra
| 4
| 4
| 5
| 4
| 13
|-
| 4. Comparaison avec la banque d'image
| 8
|
|
|
|
|-
| 5. Positionnement de la camera
| 2
| 2
|
|
| 2
|-
| '''TOTAL'''
| 24
| 10,25
| 9,25
| 9,5
| 19
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Feuille d'heures Mars==

{| class="wikitable"
!Tâches Mars !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,5
| 0,5
| 0,5
| 1,5
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
| 3
|
|
| 3
|-
| 2. Reconnaissance (Tenserflow)
| 8
| 2
| 5
| 6
| 13
|-
| 3. Prise en main de ROS associé a la caméra
| 8
| 4
| 6
| 6
| 16
|-
| '''TOTAL'''
| 19
| 9,5
| 11,5
| 12,5
| 23,5
|}

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
** avec le realsense-viewer on arrive bien a récupérer les informations de la caméra: [[Fichier:capture1.jpeg|600px|center]]
** cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue: [[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

==Mars : Séance 4 - 28/03/18==
;Bases d'utilisation de ROS:
:Pour exécuter un programme ROS il faut utiliser des fichiers spéciaux: les launch files. Pour lancer un launch file : ''roslaunch <package_name> <launch_file>'' qui prend en paramètre le nom du package qui contient le launch file et le launch file lui même. ROS utilise des packages pour organiser ses programmes. Un package contient:
::- dossier launch qui contient les launch files
::- dossier src qui contient les fichiers sources (c++, python ...)
::- fichier CMakeLists.txt qui contient la liste des règles cmake pour la compilation
::- fichier package.xml qui contient les informations/dépendances du package 
:Pour aller dans un package: ''roscd <package_name>'' 
:Tout les fichiers launch contient un <launch> tag, dans ce tag on trouve un <node> tag, dans lequel on spécifie:
::- pkg=“package_name”, nom du package qui contient le code pour le programme ROS a exécuter
::- type=“python_file_name.py”, nom du programme qu'on veut exécuter>
::- name=“node_name”, nom du node qui va launch le fichier Python
::- output=“type_of_output” ,c'est dans cette chaîne qu'on va imprimer la sortie du fichier Python.
:Comment créer un package ? 
::- les packages que nous allons créer seront dans le dossier catkin_ws pour qu'ils puissent être exécutés par ROS,
::- ''roscd'' permet d'accéder au répertoire catkin_ws/devel,
::- nos packages seront a placer dans catkin_ws/src,
::- ''catkin_create_pkg <package_name> <package_dependecies>'' permet de créer un nouveau package,
::- ''rospack list | grep my_package'' permet de vérifier que le package a bien été crée.

;Tentative de création de package 
:Nous avons d'abord tenté de créer un package d'après les explications juste au dessus, mais nous obtenions une erreur ''Invalid roslaunch XML syntax: not well-formed'' 
:Supposant qu'il s'agissait d'un problème de mauvaise syntaxe au niveau des paramètres du fichier ''projet_launch_file.launch'', nous avons suivi le tutoriel http://www.theconstructsim.com/ros-for-beginners/ afin de vérifier simplement que nous pouvions créer un package sans erreur avec un fichier python des plus basique. Cependant nous avons toujours le même problème d'erreur de syntaxe XML:
[[Fichier:Capturepackage.jpg|600px|center]]

==Feuille d'heures Avril==

{| class="wikitable"
!Tâches Mars !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
|
| 0,5
|
|
|-
| 1. Reconnaissance d'image sur la carte
| 2,5
| 2
|
|
|-
| 2. Placement finale de la caméra
| 3,5
|
|
|
|-
| 3. Récupération des pointCloude2
| 3,5
| 2
|
|
|-
| '''TOTAL'''
| 9,5
| 4,5
|
|
|}

==Avril : Séance 1 - 04/04/18==
;création de package
:Problème de la semaine dernière résolu après recopie a la main du fichier my_package_launch_file.launch, il devait s'agir de la présence d'un caractère non imprimable.

;Placement de la caméra
:choix de la position
:étude du champs de vision réel de la caméra

;Installation de TensorFlow sur la carte
:On a eu un problème car les instructions AVX non supportées par la carte
La compétition arrive bientot donc on va se concentrer sur la partie ROS. On fera fonctionner notre programme sur un ordinateur dans un premier temps.

==Avril : Séance 2 - 11/04/18==

Installation de ROS

Détermination de la position exacte de la caméra sur la plateforme du Robotino.

Début du script pour la reconnaissance d'image:

==Avril : Séance 3 - 18/04/18==

=Documents Rendus=

Discussion:Projets IMA4 SC & SA 2017/2018

2018-04-18T13:44:28Z

Zbriois : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Analyse du projet || Retour sur l'analyse || Matériel || Mi-parcours || Fin de parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Présentation sans supports, bonne analyse de la concurrence. Par contre le scénario d'usage est à revoir en précisant l'usage pour le particulier.
| Le scénario est précisé mais aucune réponse aux questions difficiles "gestion des températures et procédure d'entretien".
| Rien.
| Si le contenu du Wiki reflète la quantité de travail fourni, c'est inquiétant.
| Peu de matière, pas de justification des choix, aucune réalisation concréte présentée. Sauf effort très important de dernière minute, un projet qui n'aboutira pas.
|
|
| Inutile en l'état actuel du projet.
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Présentation focalisée sur les réseaux de neurones. Exercice mal compris (pas d'introduction du contexte, pas de scénario d'usage).
| Toujours pas d'analyse de la concurrence, ni de scénario d'usage. Pas de réponse aux questions difficiles "quel est le matériel ? quel est le protocole ? quelles sont les entrées du réseau de neurones ?".
| Une liste mais il manque des références vers les fournisseurs agréés (voir page de l'an dernier).
| Illustrez votre Wiki avec des schémas ou des photos de votre montage. Décrivez mieux votre plateforme de test et les résultats obtenus. Essayez de corriger les problèmes de français.
| Wiki trop peu alimenté pour cette phase du projet, aucune illustration, impossible de se faire une idée de l'avancée du projet avec le Wiki. Coquilles non prises en compte.
|
|
| Une démonstration avec le dispositif décrit en fin de Wiki peut être envisagée.
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Exercice correctement réalisé.
| Pas de réponse aux questions difficiles "Architecture de la source d'énergie (nombre de chemins d'énergie ?)".
| Rien.
| Vous devriez avoir quelques éléments sur la réalisation. Complétez votre Wiki.
| Un Wiki illustré mais avec du copier/coller des manuels de référence sans grand intérêt. Toujours pas de circuit testé en fin de projet. Un très important effort final est toujours possible.
|
|
| A priori inutile sauf si une version fonctionnelle de la carte était obtenue.
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Présentation focalisée sur la création du site Web. Effort fait pour rédiger un scénario d'usage.
| Réponses aux questions mais l'analyse de la consommation est imprécise. 
| Du matériel listé dans la page Wiki mais à reporter en bas de la page des projets de cette année avec des références valides.
| Un effort de documentation mais illustrez par des schémas, des pages de l'application et des tests.
| Un Wiki correct mais sans plus, des problèmes de format, des illustrations mal incluses, des vidéos youtube. Cela dit le Wiki peut devenir tout à fait correct avec un peu de temps et de soin.
|
|
| Pas de doute sur le travail effectué, une vidéo de démonstration est possible et requise.
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Exercice correctement réalisé. Scénario d'usage à préciser sur la partie réseau de capteurs.
| Scénario d'usage non précisé. Pas de réponse à la question difficile.
| Du matériel listé mais sans référence, êtes-vous sur que le matériel n'a pas besoin d'être acheté ?
| Très bonne description de l'avancé du projet. N'hésitez pas à solliciter votre encadrant direct en cas de blocage !
| Très bonne description de l'avancé du projet. Prenez un peu de temps pour corriger les coquilles assez fréquentes. Wiki légérement décalé par rapport au travail effectué.
|
|
| Aucun doute sur le travail effectué mais il n'est pas sur que le sujet se prête à une vidéo. A discuter avec les encadrants.
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Pas de support. Exercice très bien réalisé.
| Pas de réponse aux questions difficiles "quelle alimentation ? comment faire pour différencier les briques ? comment les briques vont-elles communiquer ? quelle sécurité vis-à-vis des enfants ?"
| Pas de liste de matériel.
| Très bonne description de l'avancé du projet. Faites un effort de formatage du texte (par exemple en utilisant des sous-titres plutôt que de souligner des lignes).
| Le travail progresse mais le Wiki est décalé.
|
|
| Une démonstration est requise, faites en sorte que les prototypes soient au rendez-vous.
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Rien à signaler (juste une confusion entre le MSP430 et le CC430).
| Questions difficiles évacuées. 
| Du matériel listé mais sans référence.
| Une bonne description de l'avancé du projet.
| Un Wiki correct permettant de suivre l'avancé du projet. Le rapport devra être plus précis.
|
|
| Aucun doute sur la qualité du travail, le sujet ne se prête pas à une démonstration sauf si des processus visuels peuvent être chargés sur RIOT pour CC430.
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Un peu rapide, exercice réalisé. 
| Pas d'analyse de la concurrence. Peu d'effort de rédaction. Des coquilles. Une réponse rapide à la question difficile.
| Du matériel listé mais pas forcément exhaustif et sans référence valide.
| Très bonne description de l'avancé du projet. Wiki agréable à lire.
| Merci de corriger les coquilles trop nombreuses en fin de Wiki. Les derniers travaux sont décrits trop succinctement.
|
|
| Une démonstration est requise. Un grand effort va devoir être fourni pour obtenir un prototype fonctionnel.
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Doublant
| Doublant
| Page Wiki vide, pas de liste de matériel.
| Une bonne description de l'avancé du projet. Essayez de mieux formater votre texte pour une meilleure facilité de lecture.
| Travail correctement décrit mais une tendance à s'arrêter à chaque obstacle, qu'en est-il de l'utilisation de <code>v4l2loopback</code> ?
|
|
| Une démonstration est requise. Faites en sorte d'obtenir un prototype fonctionnel.
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Présentation acceptable mais avec des supports non soignés. Pas d'analyse de la concurrence, pas de scénario d'usage.
| L'analyse de la concurrence et le scénario d'usage ont été ajoutés. Par contre pas de réponse aux questions difficiles "quelle sera l'autonomie de la balle et quel sera le système de rechargement ?".
| Pas de liste de matériel.
| Rien sur l'avancé du projet au 18/02/2018. Wiki mis à jour en catastrophe le 19/02/2018. Peu d'informations, seul le routage d'une carte semble avoir été entrepris.
| Aucune mise à jour du Wiki depuis la dernière remarque ci-dessus. L'avancée du travail ne peut pas être évaluée.
|
|
| Une démonstration est requise. Un prototype sera-t-il disponible ?
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Présentation acceptable mais avec des supports non soignés. Trouver des concurrents indirects. Une histoire mais pas de scénario d'usage.
| Page Wiki modifiée après la présentation. Une réponse incomplète à la question difficile. Trop de coquilles pour ce niveau d'études.
| Pas de liste de matériel.
| Bonne description du travail. Cinq séances pour faire chauffer une résistance, n'est-ce pas trop ?
| Rien à dire sur la forme, le Wiki est toujours bien tenu et permet de se faire une bonne idée de l'avancée du projet. Par contre le travail effectué sur les dernières semaine est très léger.
|
|
| De gros doute sur la possibilité d'avoir un dispositif convaincant à montrer en fin de projet. Je ne demande qu'à être démenti.
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Doublant
| Doublant
| Aucune modification de la page Wiki depuis début octobre.
| Une bonne description de l'avancé du projet. Projet encore dans la phase de prototypage. Comment vous comptez recevoir une carte SIM ?
| Wiki non mis à jour. Le code (IDE Arduino) est inclus in extenso dans le Wiki. Toujours pas d'intégration des composants.
|
|
| De gros doute sur la possibilité d'avoir un dispositif convaincant à montrer en fin de projet. Je ne demande qu'à être démenti.
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Supports très textuels, pas de scénario d'usage mais une rédaction sur l'intérêt psychologique, pas vraiment de partie "concurrents".
| Un effort pour trouver des "concurrents", pas de réponses aux questions difficiles "combien de LEDs ? quelle alimentation pour quelle autonomie".
| Pas de liste de matériel.
| Le travail est a peu près décrit mais la page Wiki ressemble a un brouillon.
| Beaucoup d'aide pour améliorer le Wiki mais pas d'effort pour le maintenir par la suite : pas de description du mandala décoré. Rien non plus sur la programmation des animations.
|
|
| Une démonstration est requise, il faut finaliser le projet, concernant le matériel c'est correctement engagé mais il faut un gros effort sur la programmation.
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Bonne présentation orale. Utilisation du bluetooth peu convainquant. Pas de scénario d'usage. Un "concurrent" trouvé.
| Concept de scénario d'usage non compris. Une réponse à la question difficile très rapide et non convaincante.
| Une liste de matériel dans la page Wiki mais à insérer dans le tableau en bas de la page principale. Pas de référence (voir sur la page de l'an passé).
| Le travail avec le prototype pilote de LEDs est très bien décrit et de façon agréable à lire. Par contre le schéma du futur circuit est très mal engagé. Il faut commencer par faire un schéma plus précis du collier.
| La discussion sur la conception du circuit est difficile à comprendre, d'où sortent les intensités de 0,6A et de 1,2A ? Mettre une photo d'écran pour le PCB est une hérésie sachant qu'il est possible d'exporter une image directement de Fritzing. Sans un très important travail final, il sera impossible de mener le projet à bien.
|
|
| Une démonstration est requise, il faut finaliser le projet un très gros effort est nécessaire malgré l'aide déjà apporté.
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Support assez corrects, sujet non entièrement compris, scénario d'usage minimal.
| Un problème dans le scénario d'usage : les conteneurs doivent être lancés sur un serveur. Une réponse acceptable à la question difficile.
| Pas de matériel particulier.
| Rien sur l'avancé du projet. Aucun travail ?
| Le Wiki a été utilisé mais montre un manque de travail flagrant. Un élève ne participe pas au projet.
|
|
| Sauf miracle aucune démonstration ne sera possible.
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Analyse très correcte.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Compte-rendu du travail très lapidaire et parfois illisible à cause des coquilles. Le Wiki ne donne pas l'impression que le projet avance.
| Il est clair que le Wiki est alimenté mais un manque de rigueur dans la syntaxe mediawiki et de trop nombreuses coquilles ne permettent pas une lecture facile. Avec un peu de soin vous pourriez avoir un excellent Wiki. Le travail décrit est foisonnant, essayez de synthétiser, en particulier il serait intéressant de savoir dans quel état sont les différents travaux entrepris.
|
|
| Une démonstration est requise.
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Présentation trop impécise, pas vraiment de scénario d'usage. Par contre des concurrents ont été présentés.
| Un scénario d'usage éloigné de la future utilisation. Trop de coquilles dans ce scénario. Réponse à la question difficile.
| Une liste du matériel mais pas dans la page principale. Pas de référence (voir page de l'an passé).
| Compte-rendu non à jour au 18/02/2018 alors que la feuille d'heures est à jour. Le Wiki manque d'illustration, par exemple donnez le schéma du circuit. Des informations sur la carte en gestation.
| Wiki non mis à jour. Toujours entrain de travailler sur la clef XBee.
|
|
| Une démonstration est requise. Un très grand effort semble nécessaire pour avoir quelque chose à présenter sur la table.
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Analyse très correcte. Un concurrent assez peu en rapport avec les essaims de robots mais dans la ligne des dispositifs de déminage.
| Pas de question difficile.
| Liste du matériel. Préciser pour le chassis.
| Impossible de connaître l'avancé du projet à la lecture du Wiki. N'êtes-vous pas entrain de vous perdre dans vos problèmes avec FreeRTOS ?
| De quelle résistance devant le récepteur IR parlez-vous ? Il n'y en a pas sur le PCB. Votre Wiki se concentre ces dernières semaines sur la modélisation du chassis alors que le travail sur la programmation de l'ATMega328p n'y figure pas. C'est dommage sachant qu'il s'agit du travail le plus valorisant.
|
|
| Une démonstation est requise. Arriverez-vous à souder et programmer une carte à temps ? Votre chassis complexe sera-t-il aussi fonctionnel qu'un chassis très simple à base de 2 plaques et d'entretoises ?
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Objectif mal expliqué. Exercice réalisé.
| Mieux définir l'objectif suite à la visite en entreprise. Pas de réponse à la question difficile.
| Aucune liste de matériel.
| Bonne description du travail. Votre Wiki manque d'illustrations sur un sujet qui le permet.
| Wiki non à jour. Ce qui est disponible donne l'impression d'un papillonnage de tutorial en tutorial. Vous abandonnez la banana PI D1 en début de projet pour vous concentrer sur de la reconnaissance d'image que vous ne semblez pas avoir conduit à bien puisque vous parlez de l'abandonner. Vous passez de C++ à python sans raison convaincante. Vous développez un serveur Web sous <code>flask</code> que vous cachez derrière un proxy inverse <code>ngnix</code>. Vous parlez de stratégie en semaine 9 ce qui bien tardif. Votre projet semble embourbé.
|
|
| Malheureusement il ne semble pas qu'il y aura quoi que ce soit à montrer. Je ne demande qu'à être démenti.
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Excellente présentation et excellent travail préparatoire, Scénario d'usage à préciser, trouver des concurrents.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Attention quand vous dites qu'un ATMega328p n'a pas assez de sorties pour commander 8 oscillateurs, il dispose tout de même de plus de 20 E/S.
| Wiki toujours excellent. Votre exploration du monde de l'électronique analogique est passionnant à lire du moins pour un profane en la matière. Juste des notes pour les deux dernières semaines mais c'est mieux que rien et vous avez raison de vous concentrer sur la réalisation.
|
|
| Démonstration requise. En espérant que la sculpture soit totalement opérationnelle.
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Exercice réussi. Cependant précisez les acteurs dans le scénario d'usage.
| Pas de modification du scénario. Pas de réponse à la question difficile.
| Rien à redire sur la liste de matériel.
| Description du travail correct, des illustrations. Essayez de formater avec la syntaxe Wiki.
| Wiki très correct sur la forme. Pas tout à fait à jour.
|
|
| Démonstration requise. Du travail nécessaire pour avoir un prototype pour la démonstration.
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Analyse très correcte.
| Réponses aux questions difficiles.
| Aucune liste de matériel.
| Le travail effectué est décrit. Un nombre de coquilles non acceptable, la lecture en devient difficile. Utilisez la syntaxe de formatage du Wiki.
| Corrigez vos erreurs de grammaire et d'orthographe ! Utilisez correctement la syntaxe mediawiki.
|
|
| Démonstration requise. Même un résultat négatif, du style la plante est muette, est intéressant.
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Sujet se prêtant peu à l'exercice mais très bonne présentation. Sujet travaillé.
| Pas vraiment de question, la suggestion est noté dans la page Wiki.
| Pas de matériel à commander.
| Description du travail un peu rapide (DNS leak quesako ?). Rédaction en cours au moment de la lecture du Wiki.Effort de rédaction entre le 18/02/2018 et le 19/02/2018. Il manque des sections mais le travail effectué devient lisible.
| Très bon Wiki. Des améliorations possibles comme la correction des coquilles et compléter la partie état de l'art.
|
|
| Aucun doute sur la qualité et la quantité de travail comme le montre l'"état de l'art" du Wiki. Ce sujet se prête peu à une vidéo. Il est cependant possible d'envisager une courte vidéo avec la confrontation de deux navigations Web, une classique, l'autre en passant par Tor. Le coté délicat est de trouver des démonstrations visuelles de la confidentialité apportée par Tor.
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Analyse très correcte.
| Pas de réponse aux questions difficiles "Comment démarrer l'imprimante à distance ? Comment sera calibrée la plaque d’impression ?
Comment la plaque va se fixer sur le sol ? 
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Il est possible de mettre une copie d'écran de l'application de plus. Pas la peine de vous tirer dans les pattes.
| Respectez la syntaxe mediawiki. Voir les corrections. Ajoutez une photo de l'imprimante dans l'état actuel. Très bon Wiki.
|
|
| Démonstration requise. Aucun doute sur le fait que le dispositif fonctionnera parfaitement de bout en bout.
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Le projet ne semble pas encore avoir été sérieusement étudié.
| Net effort de documentation de la page Wiki. Pas de réponse directe à la question difficile sur la Kinect mais une discussion sur le problème posé.
| Aucune liste de matériel.
| Très bonne description du travail. Des illustrations mais il pourrait y avoir des photos du système robotino / kinect.
| Depuis février le projet piétine. Votre feuille d'heure de février en témoigne : les banques d'images des MPS n'ont pas pu être constituées (pas de raison donnée pour cet échec), de plus 13h pour acquérir des images d'une caméra même stéréoscopique est exagéré. Il vous a fallu tout le mois de mars pour résoudre ces problèmes et encore votre discussion sur la reconnaissance des MPS est peu pertinente comme expliqué en séance. Toujours rien sur l'implantation du dispositif de reconnaissance sur le système embarqué.
|
|
| Il semble peu probable qu'une démonstration puisse avoir lieu. Je ne demande qu'à être démenti.
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Contexte mal présenté, sujet flou. Scénario d'usage à préciser. Pas de contact avec les encadrants avant la présentation.
| Page de Wiki vide.
| Aucune liste de matériel.
| Compte-rendu rapide du travail. Ce compte-rendu est inquiétant. Il ne semble y avoir aucun résultat depuis le début du projet. Un module a été abandonné sans que le module en question n'ait été décrit ou que la raison de l'abandon ait été précisé. Attention votre projet est en voie d'échec.
| Wiki court. Le seul travail décrit est l'écriture d'un script shell. Une seule ligne sur la création d'un conteneur.
|
|
| Aucune démonstration envisageable.
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Doublant
| Page de Wiki assez vide.
| Aucune liste de matériel.
| Le robot centaure est en plus mauvais état maintenant qu'au début du projet. Vous semblez avoir une nouvelle fois abandonné votre projet. Des ajouts mineurs au Wiki le 19/02/2018.
| Du travail réalisé avec un certain succès durant le mois de mars. A nouveau abandon du projet en avril.
|
|
| Il ne semble pas raisonnable d'espérer une démonstration.
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Présentation très correcte.
| Pas de réponse à la question difficile. Page Wiki un peu vide.
| Pas de matériel à commander.
| Un Wiki incomplet alors que la feuille d'heures est actualisée. Vous semblez toujours bloqués sur les problèmes d'étalonnage !
| Wiki très peu alimenté. Présentation du contrôle avec simulink.
|
|
| Une démonstration requise. Pour l'instant seul le contrôle par simulink est disponible. Ce n'est pas suffisant.
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Doublant
| Wiki avec quelques informations sur le travail accompli depuis fin novembre : étude sur modbus et labview. Quelques coquilles.
| Aucune liste de matériel.
| Très peu d'illustrations. Texte mal formaté et avec des coquilles intolérable à ce niveau d'étude. Le compte-rendu donne l'impression d'une méthode de travail très brouillonne.
|
| Wiki insuffisant.
|
| Projet terminé, pas de vidéo.
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Présentation sans support. Trouver des concurrents indirects. Pas de scénario d'usage.
| Page Wiki vide.
| Aucune liste de matériel.
| Rien sur l'avancé du projet. Projet en échec ?
| Rien sur l'avancé du projet. Projet en échec.
|
|
| Aucune avancée, il est désormais impossible d'avoir un prototype en fin de projet.
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Analyse très correcte.
| Page Wiki bien tenue. Ajoutez des illustrations.
| Quelques éléments sur le matériel dans la page Wiki mais aucune liste avec références.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Presque à jour. Vous n'aviez pas des cartes à faire fabriquer à l'extérieur ?
| Rédaction rapide sur les dernières semaine. Une expérimentation est nécessaire à ce stage du projet. Elle est attendue avec impatience.
|
|
| Démonstration requise. Débrouillez-vous pour avoir quelque chose de percutant à montrer !
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Exercice bien réalisé.
| Page Wiki très complète. Ajoutez des illustrations.
| Une liste probablement pas exhaustive.
| Exceptionnel ! Très illustré, bien rédigé, le travail de recherche est très bien décrit. Je ne suis pas un fan de la mise en gras d'un quart du texte et la syntaxe Wiki n'est pas vraiment utilisée mais c'est du détail?
| Il faudra encore relire le Wiki pour corriger les coquilles des nouveaux paragraphes. Les images et les vidéos sont aussi à ajouter. Il n'en reste pas moins que le Wiki et impressionnant et sera exceptionnel une fois totalement rédigé et corrigé.
|
|
| Démonstration absolument requise. Il y aura forcément quelque chose à montrer !
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Doublant
| Page Wiki vide.
| Pas de matériel à commander.
| Rien sur l'avancé du projet. Projet en échec ?
| Toujours rien sur l'avancé du projet. Projet en échec.
|
|
| Vidéo non adaptée au sujet.
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Erasmus
|
|
| Projet en échec constaté.
| A voir avec l'encadrant direct.
|
|
| A voir avec l'encadrant direct.
|-
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (17/01) !! Séance 2 (24/01) !! Séance 3 (31/01) !! Séance 4 (7/02) !! Séance 5 (14/02) !! Séance 6 (21/02) !! Séance 7 (7/03) !! Séance 8 (14/03) !! Séance 9 (21/03) !! Séance 10 (28/03) !! Séance 11 (4/04) !! Séance 12 (11/04) !! Séance 13 (18/04)
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|Quentin Boëns / Henri Carlier
|E304
|E304/305
|E304
|E304
|E304
|C201
|C201
|C201/E304
|E304/Fab
|Fab/A313
|C205 Départ 17h (entretien stage)
|C205
|C205
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|Ji Yang
|E306
|E303
| Pas de salle 
|E301
|E306
|E306
|E306
|C201
|E304
|E306
|E306
|
|
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexis Viscogliosi / Abass Ayoub
|C008
|C008
|E304 Alexis Viscogliosi Absent excusé pour entretien stage
|C008
|C008
|C201
|C201
|C201
|C201
|C201
|C201
|C201
|C201
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Paul Ribeiro / Mehanna Naïf
|E303
|E301
|A204 Absents 
|E301
|E301 puis B309 puis B207
|E301
|E301
|C201 puis E304
|C201 et E304
|C201
|C201/E303
|C201
|
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Antoine Gossehdelatte
| E306
| E306
| E306
| E306
| E306
| E306
| E306
|
|
|
|
|
|
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Maëva Delaporte / Simon Blas
| E304 
| E304 
| E304 
| E301 
| E301 
| E301 
| E301 
| C201/E304 
| E301 
| E301 
| E301 
|
|
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Baptiste Cartier
| E306
| E301
| E306
| E301
| E301
| E301
| E306
| E304
| E306
| E301
| E301
|
|
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Amine El Messaoudi / Simon Feutrier
| E301
| E301
| C201
| C201
| B207
| C201
| C201
| C201
| C201
| C201
| C201
| E305 - C202
|
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Jade Dupont
|E304
|E304
|E304
|E304
|E304
|Absence Maladie
|E304
|E304
|E304
|E304
|E304
|Absente entretien stage
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Thomas Cunin / Thibault Cattelain
| E304
| B306/E304
| Pas de salle (E304 - A305)
| E301
| E301
| E301
| E301
| E304
| E304/C200
| E304
| E304
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Rémi Mairesse / Gustave Roux
| E304
| E301
| Pas de salle 
| E304
| E304
| E304 / C201
| C201
| C201
| C201
| C201
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Oumaima Naanaa
|E302
|E304
|E304
|E304
|E304
|E304
|E304
|E304
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Lirui Zhang / Lihe Zhang
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E302
| E304
| E304
| E302
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Lijie Yao / Keren Qiang
| E303
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Maxime Creteur / Gao Fan
|E303
|E301
|A204 Absents 
|E303
|B309 puis B207
|E301
|E301
|E304
|E301
|E301
|E303 Gao Fan absent 
|E304
|
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Amaury Knockaert / Fabrice Taingland
| E304
| E304
| E304/E302
| C203/E306
| E306/E304
| Forum stages euratech/E304
| E304
| E306
| E306
| E306
| E304
| E304 / C205
|
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Matthieu Delobelle
| E306
| E306
| E303 - C201
| E306 - C201
| E304
| E306
| E306
| C201
| C201
| C201
| C201-E302
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Benjamin Canu / Ganix Etcheguibel
| E306
| E306
| E306
| E306
| E306
| Forum Euratech jusqu'à 17h E306
| E306
| E306
| E306
| E306 / Fab
| E306 / Fab
| E306 / C202
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Taky Djeraba / Thomas Hubert
| E306
| E306
| Pas de salle 
| E306
| E306
| E306
| E306
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Jean-Baptiste Watine / Antoine Untereiner
| E306/C201
| E301
| Pas de salle (C201) 
| C205
| C205/E301
| C205/E301
| E301
| C205
| C205/C201
| C205
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Transley Gracias / Camille Saad
| E306
| E306
| E305
| E306
| E306
| E306
| E306
| E306/C202
| E306
| E306
| E306
| E306/C202
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Xavier Chenot / Rodolphe Toin
| E306
| E306
| E306
| E306
| E306
| E306
| E306 puis C201
| C205
| C205
| C205
| C205
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Antoine Duquenoy / Anthony Durot
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E305
| E306
| E305
| E305
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Eloi Zalczer / Justine Senellart
|E302/E306
|E302/E306
|E304/E302
|E304/E302
|E306/E302
|Hors Polytech/E302
|E302/E304
|E302/E304
|E304/E302
|E306/E302
|E306/E302
|Entretien/E302
|
|-
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Damien Narbais / Zoé Briois
| E306
| E301
| Pas de salle (E301)
| E304 + 17h réunion C00X
| C205
| E304 + 17h réunion C00X
| A317
| E304
| E30X
| C205 + Damien -> entretien stage
| C205
| C205
| C205
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Hugo Delbroucq / Nicolas Havard
| E301
| INRIA
| Pas de salle (INRIA)
| E301
| E301 puis E304
| E301
| E301
| E304
| INRIA
| E301
| E301
| E301
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Claire Vandamme / Alexandra Villa
|C008
|C008
|Hors Polytech/B106
|C008
|C008
|Bureau de Mr Pekpe/E306
|C008
|C008
|C008(Claire : jusque 16h, RDV médical)
|C008
|C008
|C008
|C008
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Florian Le Foll
| E301
| E301
| (Pas de salle) E303
|E303
|E303
|C201
|C201
|C201
|C201
|C201
|C201
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Carval Amaury/ Prud'Homme Geoffrey
| fabricarium
| fabricarium puis Hors Polytech
| E304
| E301
| Carval E306 - Preud'homme E301
| E301
| Carval C20X - Preud'homme Fabricarium
| Quelque part
| Fabricarium
| E306
| Fabricarium (au fond)
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Erwan Dufresne
| E302/E306
| E301
| E304
| E301
| E302
| E306
| E302
| E302/Fabricarium
| E302/Fabricarium
| Fabricarium/E304
| E304/Fab
| E306/Fab
|-
| PP1 [[IMA4 2017/2018 PP1|Robot hexapode pour escalier]]
| Eduardo Gomez
| C201
| C201
| C201
| Fabricarium
| Fabricarium
| C201
| C201/Fabricarium
| C201/Fabricarium
| C201/Fabricarium
|
| C201
| C201
| C201
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|}

Discussion:Projets IMA4 SC & SA 2017/2018

2018-04-11T12:52:38Z

Zbriois : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Analyse du projet || Retour sur l'analyse || Matériel || Mi-parcours || Fin de parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Présentation sans supports, bonne analyse de la concurrence. Par contre le scénario d'usage est à revoir en précisant l'usage pour le particulier.
| Le scénario est précisé mais aucune réponse aux questions difficiles "gestion des températures et procédure d'entretien".
| Rien.
| Si le contenu du Wiki reflète la quantité de travail fourni, c'est inquiétant.
| Peu de matière, pas de justification des choix, aucune réalisation concréte présentée. Sauf effort très important de dernière minute, un projet qui n'aboutira pas.
|
|
| Inutile en l'état actuel du projet.
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Présentation focalisée sur les réseaux de neurones. Exercice mal compris (pas d'introduction du contexte, pas de scénario d'usage).
| Toujours pas d'analyse de la concurrence, ni de scénario d'usage. Pas de réponse aux questions difficiles "quel est le matériel ? quel est le protocole ? quelles sont les entrées du réseau de neurones ?".
| Une liste mais il manque des références vers les fournisseurs agréés (voir page de l'an dernier).
| Illustrez votre Wiki avec des schémas ou des photos de votre montage. Décrivez mieux votre plateforme de test et les résultats obtenus. Essayez de corriger les problèmes de français.
| Wiki trop peu alimenté pour cette phase du projet, aucune illustration, impossible de se faire une idée de l'avancée du projet avec le Wiki. Coquilles non prises en compte.
|
|
| Une démonstration avec le dispositif décrit en fin de Wiki peut être envisagée.
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Exercice correctement réalisé.
| Pas de réponse aux questions difficiles "Architecture de la source d'énergie (nombre de chemins d'énergie ?)".
| Rien.
| Vous devriez avoir quelques éléments sur la réalisation. Complétez votre Wiki.
| Un Wiki illustré mais avec du copier/coller des manuels de référence sans grand intérêt. Toujours pas de circuit testé en fin de projet. Un très important effort final est toujours possible.
|
|
| A priori inutile sauf si une version fonctionnelle de la carte était obtenue.
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Présentation focalisée sur la création du site Web. Effort fait pour rédiger un scénario d'usage.
| Réponses aux questions mais l'analyse de la consommation est imprécise. 
| Du matériel listé dans la page Wiki mais à reporter en bas de la page des projets de cette année avec des références valides.
| Un effort de documentation mais illustrez par des schémas, des pages de l'application et des tests.
| Un Wiki correct mais sans plus, des problèmes de format, des illustrations mal incluses, des vidéos youtube. Cela dit le Wiki peut devenir tout à fait correct avec un peu de temps et de soin.
|
|
| Pas de doute sur le travail effectué, une vidéo de démonstration est possible et requise.
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Exercice correctement réalisé. Scénario d'usage à préciser sur la partie réseau de capteurs.
| Scénario d'usage non précisé. Pas de réponse à la question difficile.
| Du matériel listé mais sans référence, êtes-vous sur que le matériel n'a pas besoin d'être acheté ?
| Très bonne description de l'avancé du projet. N'hésitez pas à solliciter votre encadrant direct en cas de blocage !
| Très bonne description de l'avancé du projet. Prenez un peu de temps pour corriger les coquilles assez fréquentes. Wiki légérement décalé par rapport au travail effectué.
|
|
| Aucun doute sur le travail effectué mais il n'est pas sur que le sujet se prête à une vidéo. A discuter avec les encadrants.
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Pas de support. Exercice très bien réalisé.
| Pas de réponse aux questions difficiles "quelle alimentation ? comment faire pour différencier les briques ? comment les briques vont-elles communiquer ? quelle sécurité vis-à-vis des enfants ?"
| Pas de liste de matériel.
| Très bonne description de l'avancé du projet. Faites un effort de formatage du texte (par exemple en utilisant des sous-titres plutôt que de souligner des lignes).
| Le travail progresse mais le Wiki est décalé.
|
|
| Une démonstration est requise, faites en sorte que les prototypes soient au rendez-vous.
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Rien à signaler (juste une confusion entre le MSP430 et le CC430).
| Questions difficiles évacuées. 
| Du matériel listé mais sans référence.
| Une bonne description de l'avancé du projet.
| Un Wiki correct permettant de suivre l'avancé du projet. Le rapport devra être plus précis.
|
|
| Aucun doute sur la qualité du travail, le sujet ne se prête pas à une démonstration sauf si des processus visuels peuvent être chargés sur RIOT pour CC430.
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Un peu rapide, exercice réalisé. 
| Pas d'analyse de la concurrence. Peu d'effort de rédaction. Des coquilles. Une réponse rapide à la question difficile.
| Du matériel listé mais pas forcément exhaustif et sans référence valide.
| Très bonne description de l'avancé du projet. Wiki agréable à lire.
| Merci de corriger les coquilles trop nombreuses en fin de Wiki. Les derniers travaux sont décrits trop succinctement.
|
|
| Une démonstration est requise. Un grand effort va devoir être fourni pour obtenir un prototype fonctionnel.
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Doublant
| Doublant
| Page Wiki vide, pas de liste de matériel.
| Une bonne description de l'avancé du projet. Essayez de mieux formater votre texte pour une meilleure facilité de lecture.
| Travail correctement décrit mais une tendance à s'arrêter à chaque obstacle, qu'en est-il de l'utilisation de <code>v4l2loopback</code> ?
|
|
| Une démonstration est requise. Faites en sorte d'obtenir un prototype fonctionnel.
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Présentation acceptable mais avec des supports non soignés. Pas d'analyse de la concurrence, pas de scénario d'usage.
| L'analyse de la concurrence et le scénario d'usage ont été ajoutés. Par contre pas de réponse aux questions difficiles "quelle sera l'autonomie de la balle et quel sera le système de rechargement ?".
| Pas de liste de matériel.
| Rien sur l'avancé du projet au 18/02/2018. Wiki mis à jour en catastrophe le 19/02/2018. Peu d'informations, seul le routage d'une carte semble avoir été entrepris.
| Aucune mise à jour du Wiki depuis la dernière remarque ci-dessus. L'avancée du travail ne peut pas être évaluée.
|
|
| Une démonstration est requise. Un prototype sera-t-il disponible ?
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Présentation acceptable mais avec des supports non soignés. Trouver des concurrents indirects. Une histoire mais pas de scénario d'usage.
| Page Wiki modifiée après la présentation. Une réponse incomplète à la question difficile. Trop de coquilles pour ce niveau d'études.
| Pas de liste de matériel.
| Bonne description du travail. Cinq séances pour faire chauffer une résistance, n'est-ce pas trop ?
| Rien à dire sur la forme, le Wiki est toujours bien tenu et permet de se faire une bonne idée de l'avancée du projet. Par contre le travail effectué sur les dernières semaine est très léger.
|
|
| De gros doute sur la possibilité d'avoir un dispositif convaincant à montrer en fin de projet. Je ne demande qu'à être démenti.
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Doublant
| Doublant
| Aucune modification de la page Wiki depuis début octobre.
| Une bonne description de l'avancé du projet. Projet encore dans la phase de prototypage. Comment vous comptez recevoir une carte SIM ?
| Wiki non mis à jour. Le code (IDE Arduino) est inclus in extenso dans le Wiki. Toujours pas d'intégration des composants.
|
|
| De gros doute sur la possibilité d'avoir un dispositif convaincant à montrer en fin de projet. Je ne demande qu'à être démenti.
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Supports très textuels, pas de scénario d'usage mais une rédaction sur l'intérêt psychologique, pas vraiment de partie "concurrents".
| Un effort pour trouver des "concurrents", pas de réponses aux questions difficiles "combien de LEDs ? quelle alimentation pour quelle autonomie".
| Pas de liste de matériel.
| Le travail est a peu près décrit mais la page Wiki ressemble a un brouillon.
| Beaucoup d'aide pour améliorer le Wiki mais pas d'effort pour le maintenir par la suite : pas de description du mandala décoré. Rien non plus sur la programmation des animations.
|
|
| Une démonstration est requise, il faut finaliser le projet, concernant le matériel c'est correctement engagé mais il faut un gros effort sur la programmation.
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Bonne présentation orale. Utilisation du bluetooth peu convainquant. Pas de scénario d'usage. Un "concurrent" trouvé.
| Concept de scénario d'usage non compris. Une réponse à la question difficile très rapide et non convaincante.
| Une liste de matériel dans la page Wiki mais à insérer dans le tableau en bas de la page principale. Pas de référence (voir sur la page de l'an passé).
| Le travail avec le prototype pilote de LEDs est très bien décrit et de façon agréable à lire. Par contre le schéma du futur circuit est très mal engagé. Il faut commencer par faire un schéma plus précis du collier.
| La discussion sur la conception du circuit est difficile à comprendre, d'où sortent les intensités de 0,6A et de 1,2A ? Mettre une photo d'écran pour le PCB est une hérésie sachant qu'il est possible d'exporter une image directement de Fritzing. Sans un très important travail final, il sera impossible de mener le projet à bien.
|
|
| Une démonstration est requise, il faut finaliser le projet un très gros effort est nécessaire malgré l'aide déjà apporté.
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Support assez corrects, sujet non entièrement compris, scénario d'usage minimal.
| Un problème dans le scénario d'usage : les conteneurs doivent être lancés sur un serveur. Une réponse acceptable à la question difficile.
| Pas de matériel particulier.
| Rien sur l'avancé du projet. Aucun travail ?
| Le Wiki a été utilisé mais montre un manque de travail flagrant. Un élève ne participe pas au projet.
|
|
| Sauf miracle aucune démonstration ne sera possible.
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Analyse très correcte.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Compte-rendu du travail très lapidaire et parfois illisible à cause des coquilles. Le Wiki ne donne pas l'impression que le projet avance.
| Il est clair que le Wiki est alimenté mais un manque de rigueur dans la syntaxe mediawiki et de trop nombreuses coquilles ne permettent pas une lecture facile. Avec un peu de soin vous pourriez avoir un excellent Wiki. Le travail décrit est foisonnant, essayez de synthétiser, en particulier il serait intéressant de savoir dans quel état sont les différents travaux entrepris.
|
|
| Une démonstration est requise.
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Présentation trop impécise, pas vraiment de scénario d'usage. Par contre des concurrents ont été présentés.
| Un scénario d'usage éloigné de la future utilisation. Trop de coquilles dans ce scénario. Réponse à la question difficile.
| Une liste du matériel mais pas dans la page principale. Pas de référence (voir page de l'an passé).
| Compte-rendu non à jour au 18/02/2018 alors que la feuille d'heures est à jour. Le Wiki manque d'illustration, par exemple donnez le schéma du circuit. Des informations sur la carte en gestation.
| Wiki non mis à jour. Toujours entrain de travailler sur la clef XBee.
|
|
| Une démonstration est requise. Un très grand effort semble nécessaire pour avoir quelque chose à présenter sur la table.
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Analyse très correcte. Un concurrent assez peu en rapport avec les essaims de robots mais dans la ligne des dispositifs de déminage.
| Pas de question difficile.
| Liste du matériel. Préciser pour le chassis.
| Impossible de connaître l'avancé du projet à la lecture du Wiki. N'êtes-vous pas entrain de vous perdre dans vos problèmes avec FreeRTOS ?
| De quelle résistance devant le récepteur IR parlez-vous ? Il n'y en a pas sur le PCB. Votre Wiki se concentre ces dernières semaines sur la modélisation du chassis alors que le travail sur la programmation de l'ATMega328p n'y figure pas. C'est dommage sachant qu'il s'agit du travail le plus valorisant.
|
|
| Une démonstation est requise. Arriverez-vous à souder et programmer une carte à temps ? Votre chassis complexe sera-t-il aussi fonctionnel qu'un chassis très simple à base de 2 plaques et d'entretoises ?
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Objectif mal expliqué. Exercice réalisé.
| Mieux définir l'objectif suite à la visite en entreprise. Pas de réponse à la question difficile.
| Aucune liste de matériel.
| Bonne description du travail. Votre Wiki manque d'illustrations sur un sujet qui le permet.
| Wiki non à jour. Ce qui est disponible donne l'impression d'un papillonnage de tutorial en tutorial. Vous abandonnez la banana PI D1 en début de projet pour vous concentrer sur de la reconnaissance d'image que vous ne semblez pas avoir conduit à bien puisque vous parlez de l'abandonner. Vous passez de C++ à python sans raison convaincante. Vous développez un serveur Web sous <code>flask</code> que vous cachez derrière un proxy inverse <code>ngnix</code>. Vous parlez de stratégie en semaine 9 ce qui bien tardif. Votre projet semble embourbé.
|
|
| Malheureusement il ne semble pas qu'il y aura quoi que ce soit à montrer. Je ne demande qu'à être démenti.
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Excellente présentation et excellent travail préparatoire, Scénario d'usage à préciser, trouver des concurrents.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Attention quand vous dites qu'un ATMega328p n'a pas assez de sorties pour commander 8 oscillateurs, il dispose tout de même de plus de 20 E/S.
| Wiki toujours excellent. Votre exploration du monde de l'électronique analogique est passionnant à lire du moins pour un profane en la matière. Juste des notes pour les deux dernières semaines mais c'est mieux que rien et vous avez raison de vous concentrer sur la réalisation.
|
|
| Démonstration requise. En espérant que la sculpture soit totalement opérationnelle.
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Exercice réussi. Cependant précisez les acteurs dans le scénario d'usage.
| Pas de modification du scénario. Pas de réponse à la question difficile.
| Rien à redire sur la liste de matériel.
| Description du travail correct, des illustrations. Essayez de formater avec la syntaxe Wiki.
| Wiki très correct sur la forme. Pas tout à fait à jour.
|
|
| Démonstration requise. Du travail nécessaire pour avoir un prototype pour la démonstration.
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Analyse très correcte.
| Réponses aux questions difficiles.
| Aucune liste de matériel.
| Le travail effectué est décrit. Un nombre de coquilles non acceptable, la lecture en devient difficile. Utilisez la syntaxe de formatage du Wiki.
| Corrigez vos erreurs de grammaire et d'orthographe ! Utilisez correctement la syntaxe mediawiki.
|
|
| Démonstration requise. Même un résultat négatif, du style la plante est muette, est intéressant.
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Sujet se prêtant peu à l'exercice mais très bonne présentation. Sujet travaillé.
| Pas vraiment de question, la suggestion est noté dans la page Wiki.
| Pas de matériel à commander.
| Description du travail un peu rapide (DNS leak quesako ?). Rédaction en cours au moment de la lecture du Wiki.Effort de rédaction entre le 18/02/2018 et le 19/02/2018. Il manque des sections mais le travail effectué devient lisible.
| Très bon Wiki. Des améliorations possibles comme la correction des coquilles et compléter la partie état de l'art.
|
|
| Aucun doute sur la qualité et la quantité de travail comme le montre l'"état de l'art" du Wiki. Ce sujet se prête peu à une vidéo. Il est cependant possible d'envisager une courte vidéo avec la confrontation de deux navigations Web, une classique, l'autre en passant par Tor. Le coté délicat est de trouver des démonstrations visuelles de la confidentialité apportée par Tor.
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Analyse très correcte.
| Pas de réponse aux questions difficiles "Comment démarrer l'imprimante à distance ? Comment sera calibrée la plaque d’impression ?
Comment la plaque va se fixer sur le sol ? 
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Il est possible de mettre une copie d'écran de l'application de plus. Pas la peine de vous tirer dans les pattes.
| Respectez la syntaxe mediawiki. Voir les corrections. Ajoutez une photo de l'imprimante dans l'état actuel. Très bon Wiki.
|
|
| Démonstration requise. Aucun doute sur le fait que le dispositif fonctionnera parfaitement de bout en bout.
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Le projet ne semble pas encore avoir été sérieusement étudié.
| Net effort de documentation de la page Wiki. Pas de réponse directe à la question difficile sur la Kinect mais une discussion sur le problème posé.
| Aucune liste de matériel.
| Très bonne description du travail. Des illustrations mais il pourrait y avoir des photos du système robotino / kinect.
| Depuis février le projet piétine. Votre feuille d'heure de février en témoigne : les banques d'images des MPS n'ont pas pu être constituées (pas de raison donnée pour cet échec), de plus 13h pour acquérir des images d'une caméra même stéréoscopique est exagéré. Il vous a fallu tout le mois de mars pour résoudre ces problèmes et encore votre discussion sur la reconnaissance des MPS est peu pertinente comme expliqué en séance. Toujours rien sur l'implantation du dispositif de reconnaissance sur le système embarqué.
|
|
| Il semble peu probable qu'une démonstration puisse avoir lieu. Je ne demande qu'à être démenti.
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Contexte mal présenté, sujet flou. Scénario d'usage à préciser. Pas de contact avec les encadrants avant la présentation.
| Page de Wiki vide.
| Aucune liste de matériel.
| Compte-rendu rapide du travail. Ce compte-rendu est inquiétant. Il ne semble y avoir aucun résultat depuis le début du projet. Un module a été abandonné sans que le module en question n'ait été décrit ou que la raison de l'abandon ait été précisé. Attention votre projet est en voie d'échec.
| Wiki court. Le seul travail décrit est l'écriture d'un script shell. Une seule ligne sur la création d'un conteneur.
|
|
| Aucune démonstration envisageable.
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Doublant
| Page de Wiki assez vide.
| Aucune liste de matériel.
| Le robot centaure est en plus mauvais état maintenant qu'au début du projet. Vous semblez avoir une nouvelle fois abandonné votre projet. Des ajouts mineurs au Wiki le 19/02/2018.
| Du travail réalisé avec un certain succès durant le mois de mars. A nouveau abandon du projet en avril.
|
|
| Il ne semble pas raisonnable d'espérer une démonstration.
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Présentation très correcte.
| Pas de réponse à la question difficile. Page Wiki un peu vide.
| Pas de matériel à commander.
| Un Wiki incomplet alors que la feuille d'heures est actualisée. Vous semblez toujours bloqués sur les problèmes d'étalonnage !
| Wiki très peu alimenté. Présentation du contrôle avec simulink.
|
|
| Une démonstration requise. Pour l'instant seul le contrôle par simulink est disponible. Ce n'est pas suffisant.
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Doublant
| Wiki avec quelques informations sur le travail accompli depuis fin novembre : étude sur modbus et labview. Quelques coquilles.
| Aucune liste de matériel.
| Très peu d'illustrations. Texte mal formaté et avec des coquilles intolérable à ce niveau d'étude. Le compte-rendu donne l'impression d'une méthode de travail très brouillonne.
|
| Wiki insuffisant.
|
| Projet terminé, pas de vidéo.
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Présentation sans support. Trouver des concurrents indirects. Pas de scénario d'usage.
| Page Wiki vide.
| Aucune liste de matériel.
| Rien sur l'avancé du projet. Projet en échec ?
| Rien sur l'avancé du projet. Projet en échec.
|
|
| Aucune avancée, il est désormais impossible d'avoir un prototype en fin de projet.
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Analyse très correcte.
| Page Wiki bien tenue. Ajoutez des illustrations.
| Quelques éléments sur le matériel dans la page Wiki mais aucune liste avec références.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Presque à jour. Vous n'aviez pas des cartes à faire fabriquer à l'extérieur ?
| Rédaction rapide sur les dernières semaine. Une expérimentation est nécessaire à ce stage du projet. Elle est attendue avec impatience.
|
|
| Démonstration requise. Débrouillez-vous pour avoir quelque chose de percutant à montrer !
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Exercice bien réalisé.
| Page Wiki très complète. Ajoutez des illustrations.
| Une liste probablement pas exhaustive.
| Exceptionnel ! Très illustré, bien rédigé, le travail de recherche est très bien décrit. Je ne suis pas un fan de la mise en gras d'un quart du texte et la syntaxe Wiki n'est pas vraiment utilisée mais c'est du détail?
| Il faudra encore relire le Wiki pour corriger les coquilles des nouveaux paragraphes. Les images et les vidéos sont aussi à ajouter. Il n'en reste pas moins que le Wiki et impressionnant et sera exceptionnel une fois totalement rédigé et corrigé.
|
|
| Démonstration absolument requise. Il y aura forcément quelque chose à montrer !
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Doublant
| Page Wiki vide.
| Pas de matériel à commander.
| Rien sur l'avancé du projet. Projet en échec ?
| Toujours rien sur l'avancé du projet. Projet en échec.
|
|
| Vidéo non adaptée au sujet.
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Erasmus
|
|
| Projet en échec constaté.
| A voir avec l'encadrant direct.
|
|
| A voir avec l'encadrant direct.
|-
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (17/01) !! Séance 2 (24/01) !! Séance 3 (31/01) !! Séance 4 (7/02) !! Séance 5 (14/02) !! Séance 6 (21/02) !! Séance 7 (7/03) !! Séance 8 (14/03) !! Séance 9 (21/03) !! Séance 10 (28/03) !! Séance 11 (4/04) !! Séance 12 (11/04) !! Séance 13 (18/04)
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|Quentin Boëns / Henri Carlier
|E304
|E304/305
|E304
|E304
|E304
|C201
|C201
|C201/E304
|E304/Fab
|Fab/A313
|C205 Départ 17h (entretien stage)
|
|
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|Ji Yang
|E306
|E303
| Pas de salle 
|E301
|E306
|E306
|E306
|C201
|E304
|E306
|E306
|
|
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexis Viscogliosi / Abass Ayoub
|C008
|C008
|E304 Alexis Viscogliosi Absent excusé pour entretien stage
|C008
|C008
|C201
|C201
|C201
|C201
|C201
|C201
|
|
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Paul Ribeiro / Mehanna Naïf
|E303
|E301
|A204 Absents 
|E301
|E301 puis B309 puis B207
|E301
|E301
|C201 puis E304
|C201 et E304
|C201
|C201/E303
|
|
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Antoine Gossehdelatte
| E306
| E306
| E306
| E306
| E306
| E306
| E306
|
|
|
|
|
|
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Maëva Delaporte / Simon Blas
| E304 
| E304 
| E304 
| E301 
| E301 
| E301 
| E301 
| C201/E304 
| E301 
| E301 
| E301 
|
|
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Baptiste Cartier
| E306
| E301
| E306
| E301
| E301
| E301
| E306
| E304
| E306
| E301
| E301
|
|
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Amine El Messaoudi / Simon Feutrier
| E301
| E301
| C201
| C201
| B207
| C201
| C201
| C201
|
|
|
|
|
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Jade Dupont
|E304
|E304
|E304
|E304
|E304
|Absence Maladie
|E304
|E304
|E304
|E304
|E304
|Absente entretien stage
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Thomas Cunin / Thibault Cattelain
| E304
| B306/E304
| Pas de salle (E304 - A305)
| E301
| E301
| E301
| E301
| E304
| E304/C200
| E304
| E304
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Rémi Mairesse / Gustave Roux
| E304
| E301
| Pas de salle 
| E304
| E304
| E304 / C201
| C201
| C201
| C201
| C201
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Oumaima Naanaa
|E302
|E304
|E304
|E304
|E304
|E304
|E304
|E304
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Lirui Zhang / Lihe Zhang
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| C201
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Lijie Yao / Keren Qiang
| E303
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Maxime Creteur / Gao Fan
|E303
|E301
|A204 Absents 
|E303
|B309 puis B207
|E301
|E301
|E304
|E301
|E301
|E303 Gao Fan absent 
|
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Amaury Knockaert / Fabrice Taingland
| E304
| E304
| E304/E302
| C203/E306
| E306/E304
| Forum stages euratech/E304
| E304
| E306
| E306
| E306
| E304
|
|
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Matthieu Delobelle
| E306
| E306
| E303 - C201
| E306 - C201
| E304
| E306
| E306
| C201
| C201
| C201
| C201-E302
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Benjamin Canu / Ganix Etcheguibel
| E306
| E306
| E306
| E306
| E306
| Forum Euratech jusqu'à 17h E306
| E306
| E306
| E306
| E306 / Fab
| E306 / Fab
| E306 / C204
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Taky Djeraba / Thomas Hubert
| E306
| E306
| Pas de salle 
| E306
| E306
| E306
| E306
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Jean-Baptiste Watine / Antoine Untereiner
| E306/C201
| E301
| Pas de salle (C201) 
| C205
| C205/E301
| C205/E301
| E301
| C205
| C205/C201
| C205
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Transley Gracias / Camille Saad
| E306
| E306
| E305
| E306
| E306
| E306
| E306
| E306/C202
| E306
| E306
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Xavier Chenot / Rodolphe Toin
| E306
| E306
| E306
| E306
| E306
| E306
| E306 puis C201
| C205
| C205
| C205
| C205
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Antoine Duquenoy / Anthony Durot
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E305
| E306
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Eloi Zalczer / Justine Senellart
|E302/E306
|E302/E306
|E304/E302
|E304/E302
|E306/E302
|Hors Polytech/E302
|E302/E304
|E302/E304
|E304/E302
|E306/E302
|E306/E302
|
|-
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Damien Narbais / Zoé Briois
| E306
| E301
| Pas de salle (E301)
| E304 + 17h réunion C00X
| C205
| E304 + 17h réunion C00X
| A317
| E304
| E30X
| C205 + Damien -> entretien stage
| C205
| C205
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Hugo Delbroucq / Nicolas Havard
| E301
| INRIA
| Pas de salle (INRIA)
| E301
| E301 puis E304
| E301
| E301
| E304
| INRIA
| E301
| E301
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Claire Vandamme / Alexandra Villa
|C008
|C008
|Hors Polytech/B106
|C008
|C008
|Bureau de Mr Pekpe/E306
|C008
|C008
|C008(Claire : jusque 16h, RDV médical)
|C008
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Florian Le Foll
| E301
| E301
| (Pas de salle) E303
|E303
|E303
|C201
|C201
|C201
|C201
|C201
|C201
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Carval Amaury/ Prud'Homme Geoffrey
| fabricarium
| fabricarium puis Hors Polytech
| E304
| E301
| Carval E306 - Preud'homme E301
| E301
| Carval C20X - Preud'homme Fabricarium
| Quelque part
| Fabricarium
| E306
| Fabricarium (au fond)
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Erwan Dufresne
| E302/E306
| E301
| E304
| E301
| E302
| E306
| E302
| E302/Fabricarium
| E302/Fabricarium
| Fabricarium/E304
| E304/Fab
|-
| PP1 [[IMA4 2017/2018 PP1|Robot hexapode pour escalier]]
| Eduardo Gomez
| C201
| C201
| C201
| Fabricarium
| Fabricarium
| C201
| C201/Fabricarium
| C201/Fabricarium
| C201/Fabricarium
|
| C201
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|}

IMA4 2017/2018 P44

2018-04-04T13:54:27Z

Zbriois : /* Feuille d'heures Mars */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,25
| 0,25
| 0,5
| 1
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|-
| 2. Traitement a faire sur l'image (opencv, filtres ...)
| 5
| 4
| 4
| 5
| 13
|-
| 3. Récupérer les images depuis la caméra
| 4
| 4
| 5
| 4
| 13
|-
| 4. Comparaison avec la banque d'image
| 8
|
|
|
|
|-
| 5. Positionnement de la camera
| 2
| 2
|
|
| 2
|-
| '''TOTAL'''
| 24
| 10,25
| 9,25
| 9,5
| 19
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Feuille d'heures Mars==

{| class="wikitable"
!Tâches Mars !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,5
| 0,5
| 0,5
| 1,5
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
| 3
|
|
| 3
|-
| 2. Reconnaissance (Tenserflow)
| 8
| 2
| 5
| 6
| 13
|-
| 3. Prise en main de ROS associé a la caméra
| 8
| 4
| 6
| 6
| 16
|-
| '''TOTAL'''
| 19
| 9,5
| 11,5
| 12,5
| 23,5
|}

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
:- avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
:- cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

==Mars : Séance 4 - 28/03/18==
;Bases d'utilisation de ROS:
:Pour exécuter un programme ROS il faut utiliser des fichiers spéciaux: les launch files. Pour lancer un launch file : ''roslaunch <package_name> <launch_file>'' qui prend en paramètre le nom du package qui contient le launch file et le launch file lui même. ROS utilise des packages pour organiser ses programmes. Un package contient:
::- dossier launch qui contient les launch files
::- dossier src qui contient les fichiers sources (c++, python ...)
::- fichier CMakeLists.txt qui contient la liste des règles cmake pour la compilation
::- fichier package.xml qui contient les informations/dépendances du package 
:Pour aller dans un package: ''roscd <package_name>'' 
:Tout les fichiers launch contient un <launch> tag, dans ce tag on trouve un <node> tag, dans lequel on spécifie:
::- pkg=“package_name”, nom du package qui contient le code pour le programme ROS a exécuter
::- type=“python_file_name.py”, nom du programme qu'on veut exécuter>
::- name=“node_name”, nom du node qui va launch le fichier Python
::- output=“type_of_output” ,c'est dans cette chaîne qu'on va imprimer la sortie du fichier Python.
:Comment créer un package ? 
::- les packages que nous allons créer seront dans le dossier catkin_ws pour qu'ils puissent être exécutés par ROS,
::- ''roscd'' permet d'accéder au répertoire catkin_ws/devel,
::- nos packages seront a placer dans catkin_ws/src,
::- ''catkin_create_pkg <package_name> <package_dependecies>'' permet de créer un nouveau package,
::- ''rospack list | grep my_package'' permet de vérifier que le package a bien été crée.

;Tentative de création de package 
:Nous avons d'abord tenté de créer un package d'après les explications juste au dessus, mais nous obtenions une erreur ''Invalid roslaunch XML syntax: not well-formed'' 
:Supposant qu'il s'agissait d'un problème de mauvaise syntaxe au niveau des paramètres du fichier ''projet_launch_file.launch'', nous avons suivi le tutoriel http://www.theconstructsim.com/ros-for-beginners/ afin de vérifier simplement que nous pouvions créer un package sans erreur avec un fichier python des plus basique. Cependant nous avons toujours le même problème d'erreur de syntaxe XML:
[[Fichier:Capturepackage.jpg|600px|center]]

==Avril : Séance 1 - 04/04/18==
;création de package
:Problème de la semaine dernière résolu après recopie a la main du fichier my_package_launch_file.launch, il devait s'agir de la présence d'un caractère non imprimable.

=Documents Rendus=

IMA4 2017/2018 P44

2018-04-04T13:54:06Z

Zbriois : /* Feuille d'heures Mars */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,25
| 0,25
| 0,5
| 1
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|-
| 2. Traitement a faire sur l'image (opencv, filtres ...)
| 5
| 4
| 4
| 5
| 13
|-
| 3. Récupérer les images depuis la caméra
| 4
| 4
| 5
| 4
| 13
|-
| 4. Comparaison avec la banque d'image
| 8
|
|
|
|
|-
| 5. Positionnement de la camera
| 2
| 2
|
|
| 2
|-
| '''TOTAL'''
| 24
| 10,25
| 9,25
| 9,5
| 19
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Feuille d'heures Mars==

{| class="wikitable"
!Tâches Mars !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,5
| 0,5
| 0,5
| 1,5
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
| 3
|
|
| 3
|-
| 2. Reconnaissance (Tenserflow)
| 8
| 2
| 5
| 6
| 13
|-
| 3. Prise en main de ROS associé a la caméra
| 8
| 4
| 6
| 6
| 16
|-
| '''TOTAL'''
| 19
| 9,5
| 11,5
| 12,5
| 23
|}

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
:- avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
:- cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

==Mars : Séance 4 - 28/03/18==
;Bases d'utilisation de ROS:
:Pour exécuter un programme ROS il faut utiliser des fichiers spéciaux: les launch files. Pour lancer un launch file : ''roslaunch <package_name> <launch_file>'' qui prend en paramètre le nom du package qui contient le launch file et le launch file lui même. ROS utilise des packages pour organiser ses programmes. Un package contient:
::- dossier launch qui contient les launch files
::- dossier src qui contient les fichiers sources (c++, python ...)
::- fichier CMakeLists.txt qui contient la liste des règles cmake pour la compilation
::- fichier package.xml qui contient les informations/dépendances du package 
:Pour aller dans un package: ''roscd <package_name>'' 
:Tout les fichiers launch contient un <launch> tag, dans ce tag on trouve un <node> tag, dans lequel on spécifie:
::- pkg=“package_name”, nom du package qui contient le code pour le programme ROS a exécuter
::- type=“python_file_name.py”, nom du programme qu'on veut exécuter>
::- name=“node_name”, nom du node qui va launch le fichier Python
::- output=“type_of_output” ,c'est dans cette chaîne qu'on va imprimer la sortie du fichier Python.
:Comment créer un package ? 
::- les packages que nous allons créer seront dans le dossier catkin_ws pour qu'ils puissent être exécutés par ROS,
::- ''roscd'' permet d'accéder au répertoire catkin_ws/devel,
::- nos packages seront a placer dans catkin_ws/src,
::- ''catkin_create_pkg <package_name> <package_dependecies>'' permet de créer un nouveau package,
::- ''rospack list | grep my_package'' permet de vérifier que le package a bien été crée.

;Tentative de création de package 
:Nous avons d'abord tenté de créer un package d'après les explications juste au dessus, mais nous obtenions une erreur ''Invalid roslaunch XML syntax: not well-formed'' 
:Supposant qu'il s'agissait d'un problème de mauvaise syntaxe au niveau des paramètres du fichier ''projet_launch_file.launch'', nous avons suivi le tutoriel http://www.theconstructsim.com/ros-for-beginners/ afin de vérifier simplement que nous pouvions créer un package sans erreur avec un fichier python des plus basique. Cependant nous avons toujours le même problème d'erreur de syntaxe XML:
[[Fichier:Capturepackage.jpg|600px|center]]

==Avril : Séance 1 - 04/04/18==
;création de package
:Problème de la semaine dernière résolu après recopie a la main du fichier my_package_launch_file.launch, il devait s'agir de la présence d'un caractère non imprimable.

=Documents Rendus=

IMA4 2017/2018 P44

2018-04-04T13:53:37Z

Zbriois : /* Feuille d'heures Février */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,25
| 0,25
| 0,5
| 1
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|-
| 2. Traitement a faire sur l'image (opencv, filtres ...)
| 5
| 4
| 4
| 5
| 13
|-
| 3. Récupérer les images depuis la caméra
| 4
| 4
| 5
| 4
| 13
|-
| 4. Comparaison avec la banque d'image
| 8
|
|
|
|
|-
| 5. Positionnement de la camera
| 2
| 2
|
|
| 2
|-
| '''TOTAL'''
| 24
| 10,25
| 9,25
| 9,5
| 19
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Feuille d'heures Mars==

{| class="wikitable"
!Tâches Mars !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,25
| 0,25
| 0,5
| 1
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
| 3
|
|
| 3
|-
| 2. Reconnaissance (Tenserflow)
| 8
| 2
| 5
| 6
| 13
|-
| 3. Prise en main de ROS associé a la caméra
| 8
| 4
| 6
| 6
| 16
|-
| '''TOTAL'''
| 19
| 9,25
| 11,25
| 12,5
| 23
|}

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
:- avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
:- cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

==Mars : Séance 4 - 28/03/18==
;Bases d'utilisation de ROS:
:Pour exécuter un programme ROS il faut utiliser des fichiers spéciaux: les launch files. Pour lancer un launch file : ''roslaunch <package_name> <launch_file>'' qui prend en paramètre le nom du package qui contient le launch file et le launch file lui même. ROS utilise des packages pour organiser ses programmes. Un package contient:
::- dossier launch qui contient les launch files
::- dossier src qui contient les fichiers sources (c++, python ...)
::- fichier CMakeLists.txt qui contient la liste des règles cmake pour la compilation
::- fichier package.xml qui contient les informations/dépendances du package 
:Pour aller dans un package: ''roscd <package_name>'' 
:Tout les fichiers launch contient un <launch> tag, dans ce tag on trouve un <node> tag, dans lequel on spécifie:
::- pkg=“package_name”, nom du package qui contient le code pour le programme ROS a exécuter
::- type=“python_file_name.py”, nom du programme qu'on veut exécuter>
::- name=“node_name”, nom du node qui va launch le fichier Python
::- output=“type_of_output” ,c'est dans cette chaîne qu'on va imprimer la sortie du fichier Python.
:Comment créer un package ? 
::- les packages que nous allons créer seront dans le dossier catkin_ws pour qu'ils puissent être exécutés par ROS,
::- ''roscd'' permet d'accéder au répertoire catkin_ws/devel,
::- nos packages seront a placer dans catkin_ws/src,
::- ''catkin_create_pkg <package_name> <package_dependecies>'' permet de créer un nouveau package,
::- ''rospack list | grep my_package'' permet de vérifier que le package a bien été crée.

;Tentative de création de package 
:Nous avons d'abord tenté de créer un package d'après les explications juste au dessus, mais nous obtenions une erreur ''Invalid roslaunch XML syntax: not well-formed'' 
:Supposant qu'il s'agissait d'un problème de mauvaise syntaxe au niveau des paramètres du fichier ''projet_launch_file.launch'', nous avons suivi le tutoriel http://www.theconstructsim.com/ros-for-beginners/ afin de vérifier simplement que nous pouvions créer un package sans erreur avec un fichier python des plus basique. Cependant nous avons toujours le même problème d'erreur de syntaxe XML:
[[Fichier:Capturepackage.jpg|600px|center]]

==Avril : Séance 1 - 04/04/18==
;création de package
:Problème de la semaine dernière résolu après recopie a la main du fichier my_package_launch_file.launch, il devait s'agir de la présence d'un caractère non imprimable.

=Documents Rendus=

IMA4 2017/2018 P44

2018-04-04T13:47:37Z

Zbriois : /* Réalisation du Projet */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,25
| 0,25
| 0,5
| 1
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|-
| 2. Traitement a faire sur l'image (opencv, filtres ...)
| 5
| 4
| 4
| 5
| 13
|-
| 3. Récupérer les images depuis la caméra
| 4
| 4
| 5
| 4
| 13
|-
| 4. Comparaison avec la banque d'image
| 8
|
|
|
|
|-
| 5. Positionnement de la camera
| 2
| 2
|
|
| 2
|-
| '''TOTAL'''
| 24
| 10,25
| 9,25
| 9,5
| 19
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,25
| 0,25
| 0,5
| 1
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|-
| 2. Reconnaissance (Tenserflow)
| 5
| 4
| 4
| 5
| 13
|-
| 3. Récupérer les images depuis la caméra
| 4
| 4
| 5
| 4
| 13
|-
| 4. Comparaison avec la banque d'image
| 8
|
|
|
|
|-
| 5. Positionnement de la camera
| 2
| 2
|
|
| 2
|-
| '''TOTAL'''
| 24
| 10,25
| 9,25
| 9,5
| 19
|}

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
:- avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
:- cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

==Mars : Séance 4 - 28/03/18==
;Bases d'utilisation de ROS:
:Pour exécuter un programme ROS il faut utiliser des fichiers spéciaux: les launch files. Pour lancer un launch file : ''roslaunch <package_name> <launch_file>'' qui prend en paramètre le nom du package qui contient le launch file et le launch file lui même. ROS utilise des packages pour organiser ses programmes. Un package contient:
::- dossier launch qui contient les launch files
::- dossier src qui contient les fichiers sources (c++, python ...)
::- fichier CMakeLists.txt qui contient la liste des règles cmake pour la compilation
::- fichier package.xml qui contient les informations/dépendances du package 
:Pour aller dans un package: ''roscd <package_name>'' 
:Tout les fichiers launch contient un <launch> tag, dans ce tag on trouve un <node> tag, dans lequel on spécifie:
::- pkg=“package_name”, nom du package qui contient le code pour le programme ROS a exécuter
::- type=“python_file_name.py”, nom du programme qu'on veut exécuter>
::- name=“node_name”, nom du node qui va launch le fichier Python
::- output=“type_of_output” ,c'est dans cette chaîne qu'on va imprimer la sortie du fichier Python.
:Comment créer un package ? 
::- les packages que nous allons créer seront dans le dossier catkin_ws pour qu'ils puissent être exécutés par ROS,
::- ''roscd'' permet d'accéder au répertoire catkin_ws/devel,
::- nos packages seront a placer dans catkin_ws/src,
::- ''catkin_create_pkg <package_name> <package_dependecies>'' permet de créer un nouveau package,
::- ''rospack list | grep my_package'' permet de vérifier que le package a bien été crée.

;Tentative de création de package 
:Nous avons d'abord tenté de créer un package d'après les explications juste au dessus, mais nous obtenions une erreur ''Invalid roslaunch XML syntax: not well-formed'' 
:Supposant qu'il s'agissait d'un problème de mauvaise syntaxe au niveau des paramètres du fichier ''projet_launch_file.launch'', nous avons suivi le tutoriel http://www.theconstructsim.com/ros-for-beginners/ afin de vérifier simplement que nous pouvions créer un package sans erreur avec un fichier python des plus basique. Cependant nous avons toujours le même problème d'erreur de syntaxe XML:
[[Fichier:Capturepackage.jpg|600px|center]]

==Avril : Séance 1 - 04/04/18==
;création de package
:Problème de la semaine dernière résolu après recopie a la main du fichier my_package_launch_file.launch, il devait s'agir de la présence d'un caractère non imprimable.

=Documents Rendus=

IMA4 2017/2018 P44

2018-04-04T13:46:27Z

Zbriois : /* Feuille d'heures Février */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
| 0,25
| 0,25
| 0,5
| 1
|-
| 1. Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|-
| 2. Traitement a faire sur l'image (opencv, filtres ...)
| 5
| 4
| 4
| 5
| 13
|-
| 3. Récupérer les images depuis la caméra
| 4
| 4
| 5
| 4
| 13
|-
| 4. Comparaison avec la banque d'image
| 8
|
|
|
|
|-
| 5. Positionnement de la camera
| 2
| 2
|
|
| 2
|-
| '''TOTAL'''
| 24
| 10,25
| 9,25
| 9,5
| 19
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
:- avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
:- cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

==Mars : Séance 4 - 28/03/18==
;Bases d'utilisation de ROS:
:Pour exécuter un programme ROS il faut utiliser des fichiers spéciaux: les launch files. Pour lancer un launch file : ''roslaunch <package_name> <launch_file>'' qui prend en paramètre le nom du package qui contient le launch file et le launch file lui même. ROS utilise des packages pour organiser ses programmes. Un package contient:
::- dossier launch qui contient les launch files
::- dossier src qui contient les fichiers sources (c++, python ...)
::- fichier CMakeLists.txt qui contient la liste des règles cmake pour la compilation
::- fichier package.xml qui contient les informations/dépendances du package 
:Pour aller dans un package: ''roscd <package_name>'' 
:Tout les fichiers launch contient un <launch> tag, dans ce tag on trouve un <node> tag, dans lequel on spécifie:
::- pkg=“package_name”, nom du package qui contient le code pour le programme ROS a exécuter
::- type=“python_file_name.py”, nom du programme qu'on veut exécuter>
::- name=“node_name”, nom du node qui va launch le fichier Python
::- output=“type_of_output” ,c'est dans cette chaîne qu'on va imprimer la sortie du fichier Python.
:Comment créer un package ? 
::- les packages que nous allons créer seront dans le dossier catkin_ws pour qu'ils puissent être exécutés par ROS,
::- ''roscd'' permet d'accéder au répertoire catkin_ws/devel,
::- nos packages seront a placer dans catkin_ws/src,
::- ''catkin_create_pkg <package_name> <package_dependecies>'' permet de créer un nouveau package,
::- ''rospack list | grep my_package'' permet de vérifier que le package a bien été crée.

;Tentative de création de package 
:Nous avons d'abord tenté de créer un package d'après les explications juste au dessus, mais nous obtenions une erreur ''Invalid roslaunch XML syntax: not well-formed'' 
:Supposant qu'il s'agissait d'un problème de mauvaise syntaxe au niveau des paramètres du fichier ''projet_launch_file.launch'', nous avons suivi le tutoriel http://www.theconstructsim.com/ros-for-beginners/ afin de vérifier simplement que nous pouvions créer un package sans erreur avec un fichier python des plus basique. Cependant nous avons toujours le même problème d'erreur de syntaxe XML:
[[Fichier:Capturepackage.jpg|600px|center]]

==Avril : Séance 1 - 04/04/18==
;création de package
:Problème de la semaine dernière résolu après recopie a la main du fichier my_package_launch_file.launch, il devait s'agir de la présence d'un caractère non imprimable.

=Documents Rendus=

IMA4 2017/2018 P44

2018-04-04T13:10:47Z

Zbriois : /* Feuille d'heures Février */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|-
| 2.1.Détection des contours
| 6
| 3
|
| 3
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
| 3
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
| 9
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|-
| '''TOTAL'''
| 47
| 7
| 11
| 12
| 40
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
:- avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
:- cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

==Mars : Séance 4 - 28/03/18==
;Bases d'utilisation de ROS:
:Pour exécuter un programme ROS il faut utiliser des fichiers spéciaux: les launch files. Pour lancer un launch file : ''roslaunch <package_name> <launch_file>'' qui prend en paramètre le nom du package qui contient le launch file et le launch file lui même. ROS utilise des packages pour organiser ses programmes. Un package contient:
::- dossier launch qui contient les launch files
::- dossier src qui contient les fichiers sources (c++, python ...)
::- fichier CMakeLists.txt qui contient la liste des règles cmake pour la compilation
::- fichier package.xml qui contient les informations/dépendances du package 
:Pour aller dans un package: ''roscd <package_name>'' 
:Tout les fichiers launch contient un <launch> tag, dans ce tag on trouve un <node> tag, dans lequel on spécifie:
::- pkg=“package_name”, nom du package qui contient le code pour le programme ROS a exécuter
::- type=“python_file_name.py”, nom du programme qu'on veut exécuter>
::- name=“node_name”, nom du node qui va launch le fichier Python
::- output=“type_of_output” ,c'est dans cette chaîne qu'on va imprimer la sortie du fichier Python.
:Comment créer un package ? 
::- les packages que nous allons créer seront dans le dossier catkin_ws pour qu'ils puissent être exécutés par ROS,
::- ''roscd'' permet d'accéder au répertoire catkin_ws/devel,
::- nos packages seront a placer dans catkin_ws/src,
::- ''catkin_create_pkg <package_name> <package_dependecies>'' permet de créer un nouveau package,
::- ''rospack list | grep my_package'' permet de vérifier que le package a bien été crée.

;Tentative de création de package 
:Nous avons d'abord tenté de créer un package d'après les explications juste au dessus, mais nous obtenions une erreur ''Invalid roslaunch XML syntax: not well-formed'' 
:Supposant qu'il s'agissait d'un problème de mauvaise syntaxe au niveau des paramètres du fichier ''projet_launch_file.launch'', nous avons suivi le tutoriel http://www.theconstructsim.com/ros-for-beginners/ afin de vérifier simplement que nous pouvions créer un package sans erreur avec un fichier python des plus basique. Cependant nous avons toujours le même problème d'erreur de syntaxe XML:
[[Fichier:Capturepackage.jpg|600px|center]]

==Avril : Séance 1 - 04/04/18==
;création de package
:Problème de la semaine dernière résolu après recopie a la main du fichier my_package_launch_file.launch, il devait s'agir de la présence d'un caractère non imprimable.

=Documents Rendus=

IMA4 2017/2018 P44

2018-04-04T13:09:00Z

Zbriois : /* Avril : Séance 1 - 04/04/18 */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
| 3
|
| 3
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
| 3
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
| 9
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
| 7
| 11
| 12
|
| 40
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
:- avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
:- cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

==Mars : Séance 4 - 28/03/18==
;Bases d'utilisation de ROS:
:Pour exécuter un programme ROS il faut utiliser des fichiers spéciaux: les launch files. Pour lancer un launch file : ''roslaunch <package_name> <launch_file>'' qui prend en paramètre le nom du package qui contient le launch file et le launch file lui même. ROS utilise des packages pour organiser ses programmes. Un package contient:
::- dossier launch qui contient les launch files
::- dossier src qui contient les fichiers sources (c++, python ...)
::- fichier CMakeLists.txt qui contient la liste des règles cmake pour la compilation
::- fichier package.xml qui contient les informations/dépendances du package 
:Pour aller dans un package: ''roscd <package_name>'' 
:Tout les fichiers launch contient un <launch> tag, dans ce tag on trouve un <node> tag, dans lequel on spécifie:
::- pkg=“package_name”, nom du package qui contient le code pour le programme ROS a exécuter
::- type=“python_file_name.py”, nom du programme qu'on veut exécuter>
::- name=“node_name”, nom du node qui va launch le fichier Python
::- output=“type_of_output” ,c'est dans cette chaîne qu'on va imprimer la sortie du fichier Python.
:Comment créer un package ? 
::- les packages que nous allons créer seront dans le dossier catkin_ws pour qu'ils puissent être exécutés par ROS,
::- ''roscd'' permet d'accéder au répertoire catkin_ws/devel,
::- nos packages seront a placer dans catkin_ws/src,
::- ''catkin_create_pkg <package_name> <package_dependecies>'' permet de créer un nouveau package,
::- ''rospack list | grep my_package'' permet de vérifier que le package a bien été crée.

;Tentative de création de package 
:Nous avons d'abord tenté de créer un package d'après les explications juste au dessus, mais nous obtenions une erreur ''Invalid roslaunch XML syntax: not well-formed'' 
:Supposant qu'il s'agissait d'un problème de mauvaise syntaxe au niveau des paramètres du fichier ''projet_launch_file.launch'', nous avons suivi le tutoriel http://www.theconstructsim.com/ros-for-beginners/ afin de vérifier simplement que nous pouvions créer un package sans erreur avec un fichier python des plus basique. Cependant nous avons toujours le même problème d'erreur de syntaxe XML:
[[Fichier:Capturepackage.jpg|600px|center]]

==Avril : Séance 1 - 04/04/18==
;création de package
:Problème de la semaine dernière résolu après recopie a la main du fichier my_package_launch_file.launch, il devait s'agir de la présence d'un caractère non imprimable.

=Documents Rendus=

IMA4 2017/2018 P44

2018-04-04T13:08:28Z

Zbriois : /* Réalisation du Projet */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
| 3
|
| 3
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
| 3
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
| 9
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
| 7
| 11
| 12
|
| 40
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
:- avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
:- cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

==Mars : Séance 4 - 28/03/18==
;Bases d'utilisation de ROS:
:Pour exécuter un programme ROS il faut utiliser des fichiers spéciaux: les launch files. Pour lancer un launch file : ''roslaunch <package_name> <launch_file>'' qui prend en paramètre le nom du package qui contient le launch file et le launch file lui même. ROS utilise des packages pour organiser ses programmes. Un package contient:
::- dossier launch qui contient les launch files
::- dossier src qui contient les fichiers sources (c++, python ...)
::- fichier CMakeLists.txt qui contient la liste des règles cmake pour la compilation
::- fichier package.xml qui contient les informations/dépendances du package 
:Pour aller dans un package: ''roscd <package_name>'' 
:Tout les fichiers launch contient un <launch> tag, dans ce tag on trouve un <node> tag, dans lequel on spécifie:
::- pkg=“package_name”, nom du package qui contient le code pour le programme ROS a exécuter
::- type=“python_file_name.py”, nom du programme qu'on veut exécuter>
::- name=“node_name”, nom du node qui va launch le fichier Python
::- output=“type_of_output” ,c'est dans cette chaîne qu'on va imprimer la sortie du fichier Python.
:Comment créer un package ? 
::- les packages que nous allons créer seront dans le dossier catkin_ws pour qu'ils puissent être exécutés par ROS,
::- ''roscd'' permet d'accéder au répertoire catkin_ws/devel,
::- nos packages seront a placer dans catkin_ws/src,
::- ''catkin_create_pkg <package_name> <package_dependecies>'' permet de créer un nouveau package,
::- ''rospack list | grep my_package'' permet de vérifier que le package a bien été crée.

;Tentative de création de package 
:Nous avons d'abord tenté de créer un package d'après les explications juste au dessus, mais nous obtenions une erreur ''Invalid roslaunch XML syntax: not well-formed'' 
:Supposant qu'il s'agissait d'un problème de mauvaise syntaxe au niveau des paramètres du fichier ''projet_launch_file.launch'', nous avons suivi le tutoriel http://www.theconstructsim.com/ros-for-beginners/ afin de vérifier simplement que nous pouvions créer un package sans erreur avec un fichier python des plus basique. Cependant nous avons toujours le même problème d'erreur de syntaxe XML:
[[Fichier:Capturepackage.jpg|600px|center]]

==Avril : Séance 1 - 04/04/18==
;Problème de la semaine dernière résolu après recopie a la main du fichier my_package_launch_file.launch, il devait s'agir de la présence d'un caractère non imprimable.

=Documents Rendus=

Discussion:Projets IMA4 SC & SA 2017/2018

2018-04-04T12:54:51Z

Zbriois : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Analyse du projet || Retour sur l'analyse || Matériel || Mi-parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Présentation sans supports, bonne analyse de la concurrence. Par contre le scénario d'usage est à revoir en précisant l'usage pour le particulier.
| Le scénario est précisé mais aucune réponse aux questions difficiles "gestion des températures et procédure d'entretien".
| Rien.
| Si le contenu du Wiki reflète la quantité de travail fourni, c'est inquiétant.
|
|
|
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Présentation focalisée sur les réseaux de neurones. Exercice mal compris (pas d'introduction du contexte, pas de scénario d'usage).
| Toujours pas d'analyse de la concurrence, ni de scénario d'usage. Pas de réponse aux questions difficiles "quel est le matériel ? quel est le protocole ? quelles sont les entrées du réseau de neurones ?".
| Une liste mais il manque des références vers les fournisseurs agréés (voir page de l'an dernier).
| Illustrez votre Wiki avec des schémas ou des photos de votre montage. Décrivez mieux votre plateforme de test et les résultats obtenus. Essayez de corriger les problèmes de français.
|
|
|
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Exercice correctement réalisé.
| Pas de réponse aux questions difficiles "Architecture de la source d'énergie (nombre de chemins d'énergie ?)".
| Rien.
| Vous devriez avoir quelques éléments sur la réalisation. Complétez votre Wiki.
|
|
|
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Présentation focalisée sur la création du site Web. Effort fait pour rédiger un scénario d'usage.
| Réponses aux questions mais l'analyse de la consommation est imprécise. 
| Du matériel listé dans la page Wiki mais à reporter en bas de la page des projets de cette année avec des références valides.
| Un effort de documentation mais illustrez par des schémas, des pages de l'application et des tests.
|
|
|
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Exercice correctement réalisé. Scénario d'usage à préciser sur la partie réseau de capteurs.
| Scénario d'usage non précisé. Pas de réponse à la question difficile.
| Du matériel listé mais sans référence, êtes-vous sur que le matériel n'a pas besoin d'être acheté ?
| Très bonne description de l'avancé du projet. N'hésitez pas à solliciter votre encadrant direct en cas de blocage !
|
|
|
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Pas de support. Exercice très bien réalisé.
| Pas de réponse aux questions difficiles "quelle alimentation ? comment faire pour différencier les briques ? comment les briques vont-elles communiquer ? quelle sécurité vis-à-vis des enfants ?"
| Pas de liste de matériel.
| Très bonne description de l'avancé du projet. Faites un effort de formatage du texte (par exemple en utilisant des sous-titres plutôt que de souligner des lignes).
|
|
|
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Rien à signaler (juste une confusion entre le MSP430 et le CC430).
| Questions difficiles évacuées. 
| Du matériel listé mais sans référence.
| Une bonne description de l'avancé du projet.
|
|
|
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Un peu rapide, exercice réalisé. 
| Pas d'analyse de la concurrence. Peu d'effort de rédaction. Des coquilles. Une réponse rapide à la question difficile.
| Du matériel listé mais pas forcément exhaustif et sans référence valide.
| Très bonne description de l'avancé du projet. Wiki agréable à lire.
|
|
|
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Doublant
| Doublant
| Page Wiki vide, pas de liste de matériel.
| Une bonne description de l'avancé du projet. Essayez de mieux formater votre texte pour une meilleure facilité de lecture.
|
|
|
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Présentation acceptable mais avec des supports non soignés. Pas d'analyse de la concurrence, pas de scénario d'usage.
| L'analyse de la concurrence et le scénario d'usage ont été ajoutés. Par contre pas de réponse aux questions difficiles "quelle sera l'autonomie de la balle et quel sera le système de rechargement ?".
| Pas de liste de matériel.
| Rien sur l'avancé du projet au 18/02/2018. Wiki mis à jour en catastrophe le 19/02/2018. Peu d'informations, seul le routage d'une carte semble avoir été entrepris.
|
|
|
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Présentation acceptable mais avec des supports non soignés. Trouver des concurrents indirects. Une histoire mais pas de scénario d'usage.
| Page Wiki modifiée après la présentation. Une réponse incomplète à la question difficile. Trop de coquilles pour ce niveau d'études.
| Pas de liste de matériel.
| Bonne description du travail. Cinq séances pour faire chauffer une résistance, n'est-ce pas trop ?
|
|
|
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Doublant
| Doublant
| Aucune modification de la page Wiki depuis début octobre.
| Une bonne description de l'avancé du projet. Projet encore dans la phase de prototypage. Comment vous comptez recevoir une carte SIM ?
|
|
|
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Supports très textuels, pas de scénario d'usage mais une rédaction sur l'intérêt psychologique, pas vraiment de partie "concurrents".
| Un effort pour trouver des "concurrents", pas de réponses aux questions difficiles "combien de LEDs ? quelle alimentation pour quelle autonomie".
| Pas de liste de matériel.
| Le travail est a peu près décrit mais la page Wiki ressemble a un brouillon.
|
|
|
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Bonne présentation orale. Utilisation du bluetooth peu convainquant. Pas de scénario d'usage. Un "concurrent" trouvé.
| Concept de scénario d'usage non compris. Une réponse à la question difficile très rapide et non convaincante.
| Une liste de matériel dans la page Wiki mais à insérer dans le tableau en bas de la page principale. Pas de référence (voir sur la page de l'an passé).
| Le travail avec le prototype pilote de LEDs est très bien décrit et de façon agréable à lire. Par contre le schéma du futur circuit est très mal engagé. Il faut commencer par faire un schéma plus précis du collier.
|
|
|
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Support assez corrects, sujet non entièrement compris, scénario d'usage minimal.
| Un problème dans le scénario d'usage : les conteneurs doivent être lancés sur un serveur. Une réponse acceptable à la question difficile.
| Pas de matériel particulier.
| Rien sur l'avancé du projet. Aucun travail ?
|
|
|
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Analyse très correcte.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Compte-rendu du travail très lapidaire et parfois illisible à cause des coquilles. Le Wiki ne donne pas l'impression que le projet avance.
|
|
|
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Présentation trop impécise, pas vraiment de scénario d'usage. Par contre des concurrents ont été présentés.
| Un scénario d'usage éloigné de la future utilisation. Trop de coquilles dans ce scénario. Réponse à la question difficile.
| Une liste du matériel mais pas dans la page principale. Pas de référence (voir page de l'an passé).
| Compte-rendu non à jour au 18/02/2018 alors que la feuille d'heures est à jour. Le Wiki manque d'illustration, par exemple donnez le schéma du circuit. Des informations sur la carte en gestation.
|
|
|
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Analyse très correcte. Un concurrent assez peu en rapport avec les essaims de robots mais dans la ligne des dispositifs de déminage.
| Pas de question difficile.
| Liste du matériel. Préciser pour le chassis.
| Impossible de connaître l'avancé du projet à la lecture du Wiki. N'êtes-vous pas entrain de vous perdre dans vos problèmes avec FreeRTOS ?
|
|
|
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Objectif mal expliqué. Exercice réalisé.
| Mieux définir l'objectif suite à la visite en entreprise. Pas de réponse à la question difficile.
| Aucune liste de matériel.
| Bonne description du travail. Votre Wiki manque d'illustrations sur un sujet qui le permet.
|
|
|
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Excellente présentation et excellent travail préparatoire, Scénario d'usage à préciser, trouver des concurrents.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Attention quand vous dites qu'un ATMega328p n'a pas assez de sorties pour commander 8 oscillateurs, il dispose tout de même de plus de 20 E/S.
|
|
|
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Exercice réussi. Cependant précisez les acteurs dans le scénario d'usage.
| Pas de modification du scénario. Pas de réponse à la question difficile.
| Rien à redire sur la liste de matériel.
| Description du travail correct, des illustrations. Essayez de formater avec la syntaxe Wiki.
|
|
|
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Analyse très correcte.
| Réponses aux questions difficiles.
| Aucune liste de matériel.
| Le travail effectué est décrit. Un nombre de coquilles non acceptable, la lecture en devient difficile. Utilisez la syntaxe de formatage du Wiki.
|
|
|
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Sujet se prêtant peu à l'exercice mais très bonne présentation. Sujet travaillé.
| Pas vraiment de question, la suggestion est noté dans la page Wiki.
| Pas de matériel à commander.
| Description du travail un peu rapide (DNS leak quesako ?). Rédaction en cours au moment de la lecture du Wiki.Effort de rédaction entre le 18/02/2018 et le 19/02/2018. Il manque des sections mais le travail effectué devient lisible.
|
|
|
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Analyse très correcte.
| Pas de réponse aux questions difficiles "Comment démarrer l'imprimante à distance ? Comment sera calibrée la plaque d’impression ?
Comment la plaque va se fixer sur le sol ? 
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Il est possible de mettre une copie d'écran de l'application de plus. Pas la peine de vous tirer dans les pattes.
|
|
|
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Le projet ne semble pas encore avoir été sérieusement étudié.
| Net effort de documentation de la page Wiki. Pas de réponse directe à la question difficile sur la Kinect mais une discussion sur le problème posé.
| Aucune liste de matériel.
| Très bonne description du travail. Des illustrations mais il pourrait y avoir des photos du système robotino / kinect.
|
|
|
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Contexte mal présenté, sujet flou. Scénario d'usage à préciser. Pas de contact avec les encadrants avant la présentation.
| Page de Wiki vide.
| Aucune liste de matériel.
| Compte-rendu rapide du travail. Ce compte-rendu est inquiétant. Il ne semble y avoir aucun résultat depuis le début du projet. Un module a été abandonné sans que le module en question n'ait été décrit ou que la raison de l'abandon ait été précisé. Attention votre projet est en voie d'échec.
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Doublant
| Page de Wiki assez vide.
| Aucune liste de matériel.
| Le robot centaure est en plus mauvais état maintenant qu'au début du projet. Vous semblez avoir une nouvelle fois abandonné votre projet. Des ajouts mineurs au Wiki le 19/02/2018.
|
|
|
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Présentation très correcte.
| Pas de réponse à la question difficile. Page Wiki un peu vide.
| Pas de matériel à commander.
| Un Wiki incomplet alors que la feuille d'heures est actualisée. Vous semblez toujours bloqués sur les problèmes d'étalonnage !
|
|
|
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Doublant
| Wiki avec quelques informations sur le travail accompli depuis fin novembre : étude sur modbus et labview. Quelques coquilles.
| Aucune liste de matériel.
| Très peu d'illustrations. Texte mal formaté et avec des coquilles intolérable à ce niveau d'étude. Le compte-rendu donne l'impression d'une méthode de travail très brouillonne.
|
|
|
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Présentation sans support. Trouver des concurrents indirects. Pas de scénario d'usage.
| Page Wiki vide.
| Aucune liste de matériel.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Analyse très correcte.
| Page Wiki bien tenue. Ajoutez des illustrations.
| Quelques éléments sur le matériel dans la page Wiki mais aucune liste avec références.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Presque à jour. Vous n'aviez pas des cartes à faire fabriquer à l'extérieur ?
|
|
|
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Exercice bien réalisé.
| Page Wiki très complète. Ajoutez des illustrations.
| Une liste probablement pas exhaustive.
|Exceptionnel ! Très illustré, bien rédigé, le travail de recherche est très bien décrit. Je ne suis pas un fan de la mise en gras d'un quart du texte et la syntaxe Wiki n'est pas vraiment utilisée mais c'est du détail?
|
|
|
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Doublant
| Page Wiki vide.
| Pas de matériel à commander.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Erasmus
|
|
| Projet en échec constaté.
|
|
|
|-
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (17/01) !! Séance 2 (24/01) !! Séance 3 (31/01) !! Séance 4 (7/02) !! Séance 5 (14/02) !! Séance 6 (21/02) !! Séance 7 (7/03) !! Séance 8 (14/03) !! Séance 9 (21/03) !! Séance 10 (28/03) !! Séance 11 (4/04) !! Séance 12 (11/04) !! Séance 13 (18/04)
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|Quentin Boëns / Henri Carlier
|E304
|E304/305
|E304
|E304
|E304
|C201
|C201
|C201/E304
|E304/Fab
|Fab/A313
|C205 Départ 17h (entretien stage)
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|Ji Yang
|E306
|E303
| Pas de salle 
|E301
|E306
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexis Viscogliosi / Abass Ayoub
|C008
|C008
|E304 Alexis Viscogliosi Absent excusé pour entretien stage
|C008
|C008
|C201
|C201
|C201
|C201
|C201
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Paul Ribeiro / Mehanna Naïf
|E303
|E301
|A204 Absents 
|E301
|E301 puis B309 puis B207
|E301
|E301
|C201 puis E304
|C201 et E304
|C201
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Antoine Gosse
| E306
| E306
| E306
| E306
| E306
| E306
| E306
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Maëva Delaporte / Simon Blas
| E304 
| E304 
| E304 
| E301 
| E301 
| E301 
| E301 
| C201/E304 
| E301 
| E301 
| E301 
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Baptiste Cartier
| E306
| E301
| E306
| E301
| E301
| E301
| E306
| E304
| E306
| E301
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Amine El Messaoudi / Simon Feutrier
| E301
| E301
| C201
| C201
| B207
| C201
| C201
| C201
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Jade Dupont
|E304
|E304
|E304
|E304
|E304
|Absence Maladie
|E304
|E304
|E304
|E304
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Thomas Cunin / Thibault Cattelain
| E304
| B306/E304
| Pas de salle (E304 - A305)
| E301
| E301
| E301
| E301
| E304
| E304/C200
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Rémi Mairesse / Gustave Roux
| E304
| E301
| Pas de salle 
| E304
| E304
| E304 / C201
| C201
| C201
| C201
| C201
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Oumaima Naanaa
|E302
|E304
|E304
|E304
|E304
|E304
|E304
|E304
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Lirui Zhang / Lihe Zhang
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| C201
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Lijie Yao / Keren Qiang
| E303
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Maxime Creteur / Gao Fan
|E303
|E301
|A204 Absents 
|E303
|B309 puis B207
|E301
|E301
|E304
|E301
|E301
|E303
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Amaury Knockaert / Fabrice Taingland
| E304
| E304
| E304/E302
| C203/E306
| E306/E304
| Forum stages euratech/E304
| E304
| E306
| E306
| E306
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Matthieu Delobelle
| E306
| E306
| E303 - C201
| E306 - C201
| E304
| E306
| E306
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Benjamin Canu / Ganix Etcheguibel
| E306
| E306
| E306
| E306
| E306
| Forum Euratech jusque 17h E306
| E306
| E306
| E306
| E306 / Fab
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Taky Djeraba / Thomas Hubert
| E306
| E306
| Pas de salle 
| E306
| E306
| E306
| E306
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Jean-Baptiste Watine / Antoine Untereiner
| E306/C201
| E301
| Pas de salle (C201) 
| C205
| C205/E301
| C205/E301
| E301
| C205
| C205/C201
| C205
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Transley Gracias / Camille Saad
| E306
| E306
| E305
| E306
| E306
| E306
| E306
| E306/C202
| E306
| E306
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Xavier Chenot / Rodolphe Toin
| E306
| E306
| E306
| E306
| E306
| E306
| E306 puis C201
| C205
| C205
| C205
| C205
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Antoine Duquenoy / Anthony Durot
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E305
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Eloi Zalczer / Justine Senellart
|E302/E306
|E302/E306
|E304/E302
|E304/E302
|E306/E302
|Hors Polytech/E302
|E302/E304
|E302/E304
|E304/E302
|E306/E302
|
|-
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Damien Narbais / Zoé Briois
| E306
| E301
| Pas de salle (E301)
| E304 + 17h réunion C00X
| C205
| E304 + 17h réunion C00X
| A317
| E304
| E30X
| C205 + Damien -> entretien stage
| C205
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Hugo Delbroucq / Nicolas Havard
| E301
| INRIA
| Pas de salle (INRIA)
| E301
| E301 puis E304
| E301
| E301
| E304
| INRIA
| E301
| E301
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Claire Vandamme / Alexandra Villa
|C008
|C008
|Hors Polytech/B106
|C008
|C008
|Bureau de Mr Pekpe/E306
|C008
|C008
|C008(Claire : jusque 16h, RDV médical)
|C008
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Florian Le Foll
| E301
| E301
| (Pas de salle) E303
|E303
|E303
|C201
|C201
|C201
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Carval Amaury/ Prud'Homme Geoffrey
| fabricarium
| fabricarium puis Hors Polytech
| E304
| E301
| Carval E306 - Preud'homme E301
| E301
| Carval C20X - Preud'homme Fabricarium
| Quelque part
| Fabricarium
| E306
| Fabricarium (au fond)
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Erwan Dufresne
| E302/E306
| E301
| E304
| E301
| E302
| E306
| E302
| E302/Fabricarium
| E302/Fabricarium
| Fabricarium/E304
|
|-
| PP1 [[IMA4 2017/2018 PP1|Robot hexapode pour escalier]]
| Eduardo Gomez
| C201
| C201
| C201
| Fabricarium
| Fabricarium
| C201
| C201/Fabricarium
| C201/Fabricarium
| C201/Fabricarium
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|}

IMA4 2017/2018 P44

2018-03-28T16:34:01Z

Zbriois : /* Mars : Séance 4 - 28/03/18 */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
| 3
|
| 3
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
| 3
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
| 9
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
| 7
| 11
| 12
|
| 40
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
:- avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
:- cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

==Mars : Séance 4 - 28/03/18==
;Bases d'utilisation de ROS:
:Pour exécuter un programme ROS il faut utiliser des fichiers spéciaux: les launch files. Pour lancer un launch file : ''roslaunch <package_name> <launch_file>'' qui prend en paramètre le nom du package qui contient le launch file et le launch file lui même. ROS utilise des packages pour organiser ses programmes. Un package contient:
::- dossier launch qui contient les launch files
::- dossier src qui contient les fichiers sources (c++, python ...)
::- fichier CMakeLists.txt qui contient la liste des règles cmake pour la compilation
::- fichier package.xml qui contient les informations/dépendances du package 
:Pour aller dans un package: ''roscd <package_name>'' 
:Tout les fichiers launch contient un <launch> tag, dans ce tag on trouve un <node> tag, dans lequel on spécifie:
::- pkg=“package_name”, nom du package qui contient le code pour le programme ROS a exécuter
::- type=“python_file_name.py”, nom du programme qu'on veut exécuter>
::- name=“node_name”, nom du node qui va launch le fichier Python
::- output=“type_of_output” ,c'est dans cette chaîne qu'on va imprimer la sortie du fichier Python.
:Comment créer un package ? 
::- les packages que nous allons créer seront dans le dossier catkin_ws pour qu'ils puissent être exécutés par ROS,
::- ''roscd'' permet d'accéder au répertoire catkin_ws/devel,
::- nos packages seront a placer dans catkin_ws/src,
::- ''catkin_create_pkg <package_name> <package_dependecies>'' permet de créer un nouveau package,
::- ''rospack list | grep my_package'' permet de vérifier que le package a bien été crée.

;Tentative de création de package 
:Nous avons d'abord tenté de créer un package d'après les explications juste au dessus, mais nous obtenions une erreur ''Invalid roslaunch XML syntax: not well-formed'' 
:Supposant qu'il s'agissait d'un problème de mauvaise syntaxe au niveau des paramètres du fichier ''projet_launch_file.launch'', nous avons suivi le tutoriel http://www.theconstructsim.com/ros-for-beginners/ afin de vérifier simplement que nous pouvions créer un package sans erreur avec un fichier python des plus basique. Cependant nous avons toujours le même problème d'erreur de syntaxe XML:
[[Fichier:Capturepackage.jpg|600px|center]]

=Documents Rendus=

Fichier:Capturepackage.jpg

2018-03-28T16:33:32Z

Zbriois : erreur lors de la creation de package

erreur lors de la creation de package

IMA4 2017/2018 P44

2018-03-28T16:33:01Z

Zbriois : /* Mars : Séance 4 - 28/03/18 */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
| 3
|
| 3
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
| 3
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
| 9
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
| 7
| 11
| 12
|
| 40
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
:- avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
:- cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

==Mars : Séance 4 - 28/03/18==
;Bases d'utilisation de ROS:
:Pour exécuter un programme ROS il faut utiliser des fichiers spéciaux: les launch files. Pour lancer un launch file : ''roslaunch <package_name> <launch_file>'' qui prend en paramètre le nom du package qui contient le launch file et le launch file lui même. ROS utilise des packages pour organiser ses programmes. Un package contient:
::- dossier launch qui contient les launch files
::- dossier src qui contient les fichiers sources (c++, python ...)
::- fichier CMakeLists.txt qui contient la liste des règles cmake pour la compilation
::- fichier package.xml qui contient les informations/dépendances du package 
:Pour aller dans un package: ''roscd <package_name>'' 
:Tout les fichiers launch contient un <launch> tag, dans ce tag on trouve un <node> tag, dans lequel on spécifie:
::- pkg=“package_name”, nom du package qui contient le code pour le programme ROS a exécuter
::- type=“python_file_name.py”, nom du programme qu'on veut exécuter>
::- name=“node_name”, nom du node qui va launch le fichier Python
::- output=“type_of_output” ,c'est dans cette chaîne qu'on va imprimer la sortie du fichier Python.
:Comment créer un package ? 
::- les packages que nous allons créer seront dans le dossier catkin_ws pour qu'ils puissent être exécutés par ROS,
::- ''roscd'' permet d'accéder au répertoire catkin_ws/devel,
::- nos packages seront a placer dans catkin_ws/src,
::- ''catkin_create_pkg <package_name> <package_dependecies>'' permet de créer un nouveau package,
::- ''rospack list | grep my_package'' permet de vérifier que le package a bien été crée.

;Tentative de création de package 
:Nous avons d'abord tenté de créer un package d'après les explications juste au dessus, mais nous obtenions une erreur ''Invalid roslaunch XML syntax: not well-formed'' 
:Supposant qu'il s'agissait d'un problème de mauvaise syntaxe au niveau des paramètres du fichier ''projet_launch_file.launch'', nous avons suivi le tutoriel http://www.theconstructsim.com/ros-for-beginners/ afin de vérifier simplement que nous pouvions créer un package sans erreur avec un fichier python des plus basique. Cependant nous avons toujours le même problème d'erreur de syntaxe XML:
[[Fichier:capture.jpeg|600px|center]]

=Documents Rendus=

IMA4 2017/2018 P44

2018-03-28T16:32:14Z

Zbriois : /* Mars : Séance 4 - 28/03/18 */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
| 3
|
| 3
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
| 3
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
| 9
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
| 7
| 11
| 12
|
| 40
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
:- avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
:- cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

==Mars : Séance 4 - 28/03/18==
;Bases d'utilisation de ROS:
:Pour exécuter un programme ROS il faut utiliser des fichiers spéciaux: les launch files. Pour lancer un launch file : ''roslaunch <package_name> <launch_file>'' qui prend en paramètre le nom du package qui contient le launch file et le launch file lui même. ROS utilise des packages pour organiser ses programmes. Un package contient:
::- dossier launch qui contient les launch files
::- dossier src qui contient les fichiers sources (c++, python ...)
::- fichier CMakeLists.txt qui contient la liste des règles cmake pour la compilation
::- fichier package.xml qui contient les informations/dépendances du package 
:Pour aller dans un package: ''roscd <package_name>'' 
:Tout les fichiers launch contient un <launch> tag, dans ce tag on trouve un <node> tag, dans lequel on spécifie:
::- pkg=“package_name”, nom du package qui contient le code pour le programme ROS a exécuter
::- type=“python_file_name.py”, nom du programme qu'on veut exécuter>
::- name=“node_name”, nom du node qui va launch le fichier Python
::- output=“type_of_output” ,c'est dans cette chaîne qu'on va imprimer la sortie du fichier Python.
:Comment créer un package ? 
::- les packages que nous allons créer seront dans le dossier catkin_ws pour qu'ils puissent être exécutés par ROS,
::- ''roscd'' permet d'accéder au répertoire catkin_ws/devel,
::- nos packages seront a placer dans catkin_ws/src,
::- ''catkin_create_pkg <package_name> <package_dependecies>'' permet de créer un nouveau package,
::- ''rospack list | grep my_package'' permet de vérifier que le package a bien été crée.

;Tentative de création de package 
:Nous avons d'abord tenté de créer un package d'après les explications juste au dessus, mais nous obtenions une erreur ''Invalid roslaunch XML syntax: not well-formed'' 
:Supposant qu'il s'agissait d'un problème de mauvaise syntaxe au niveau des paramètres du fichier ''projet_launch_file.launch'', nous avons suivi le tutoriel http://www.theconstructsim.com/ros-for-beginners/ afin de vérifier simplement que nous pouvions créer un package sans erreur avec un fichier python des plus basique. Cependant nous avons toujours le même problème d'erreur de syntaxe XML:
[[Fichier:capture.jpeg]]

=Documents Rendus=

Discussion:Projets IMA4 SC & SA 2017/2018

2018-03-28T13:39:57Z

Zbriois : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Analyse du projet || Retour sur l'analyse || Matériel || Mi-parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Présentation sans supports, bonne analyse de la concurrence. Par contre le scénario d'usage est à revoir en précisant l'usage pour le particulier.
| Le scénario est précisé mais aucune réponse aux questions difficiles "gestion des températures et procédure d'entretien".
| Rien.
| Si le contenu du Wiki reflète la quantité de travail fourni, c'est inquiétant.
|
|
|
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Présentation focalisée sur les réseaux de neurones. Exercice mal compris (pas d'introduction du contexte, pas de scénario d'usage).
| Toujours pas d'analyse de la concurrence, ni de scénario d'usage. Pas de réponse aux questions difficiles "quel est le matériel ? quel est le protocole ? quelles sont les entrées du réseau de neurones ?".
| Une liste mais il manque des références vers les fournisseurs agréés (voir page de l'an dernier).
| Illustrez votre Wiki avec des schémas ou des photos de votre montage. Décrivez mieux votre plateforme de test et les résultats obtenus. Essayez de corriger les problèmes de français.
|
|
|
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Exercice correctement réalisé.
| Pas de réponse aux questions difficiles "Architecture de la source d'énergie (nombre de chemins d'énergie ?)".
| Rien.
| Vous devriez avoir quelques éléments sur la réalisation. Complétez votre Wiki.
|
|
|
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Présentation focalisée sur la création du site Web. Effort fait pour rédiger un scénario d'usage.
| Réponses aux questions mais l'analyse de la consommation est imprécise. 
| Du matériel listé dans la page Wiki mais à reporter en bas de la page des projets de cette année avec des références valides.
| Un effort de documentation mais illustrez par des schémas, des pages de l'application et des tests.
|
|
|
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Exercice correctement réalisé. Scénario d'usage à préciser sur la partie réseau de capteurs.
| Scénario d'usage non précisé. Pas de réponse à la question difficile.
| Du matériel listé mais sans référence, êtes-vous sur que le matériel n'a pas besoin d'être acheté ?
| Très bonne description de l'avancé du projet. N'hésitez pas à solliciter votre encadrant direct en cas de blocage !
|
|
|
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Pas de support. Exercice très bien réalisé.
| Pas de réponse aux questions difficiles "quelle alimentation ? comment faire pour différencier les briques ? comment les briques vont-elles communiquer ? quelle sécurité vis-à-vis des enfants ?"
| Pas de liste de matériel.
| Très bonne description de l'avancé du projet. Faites un effort de formatage du texte (par exemple en utilisant des sous-titres plutôt que de souligner des lignes).
|
|
|
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Rien à signaler (juste une confusion entre le MSP430 et le CC430).
| Questions difficiles évacuées. 
| Du matériel listé mais sans référence.
| Une bonne description de l'avancé du projet.
|
|
|
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Un peu rapide, exercice réalisé. 
| Pas d'analyse de la concurrence. Peu d'effort de rédaction. Des coquilles. Une réponse rapide à la question difficile.
| Du matériel listé mais pas forcément exhaustif et sans référence valide.
| Très bonne description de l'avancé du projet. Wiki agréable à lire.
|
|
|
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Doublant
| Doublant
| Page Wiki vide, pas de liste de matériel.
| Une bonne description de l'avancé du projet. Essayez de mieux formater votre texte pour une meilleure facilité de lecture.
|
|
|
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Présentation acceptable mais avec des supports non soignés. Pas d'analyse de la concurrence, pas de scénario d'usage.
| L'analyse de la concurrence et le scénario d'usage ont été ajoutés. Par contre pas de réponse aux questions difficiles "quelle sera l'autonomie de la balle et quel sera le système de rechargement ?".
| Pas de liste de matériel.
| Rien sur l'avancé du projet au 18/02/2018. Wiki mis à jour en catastrophe le 19/02/2018. Peu d'informations, seul le routage d'une carte semble avoir été entrepris.
|
|
|
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Présentation acceptable mais avec des supports non soignés. Trouver des concurrents indirects. Une histoire mais pas de scénario d'usage.
| Page Wiki modifiée après la présentation. Une réponse incomplète à la question difficile. Trop de coquilles pour ce niveau d'études.
| Pas de liste de matériel.
| Bonne description du travail. Cinq séances pour faire chauffer une résistance, n'est-ce pas trop ?
|
|
|
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Doublant
| Doublant
| Aucune modification de la page Wiki depuis début octobre.
| Une bonne description de l'avancé du projet. Projet encore dans la phase de prototypage. Comment vous comptez recevoir une carte SIM ?
|
|
|
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Supports très textuels, pas de scénario d'usage mais une rédaction sur l'intérêt psychologique, pas vraiment de partie "concurrents".
| Un effort pour trouver des "concurrents", pas de réponses aux questions difficiles "combien de LEDs ? quelle alimentation pour quelle autonomie".
| Pas de liste de matériel.
| Le travail est a peu près décrit mais la page Wiki ressemble a un brouillon.
|
|
|
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Bonne présentation orale. Utilisation du bluetooth peu convainquant. Pas de scénario d'usage. Un "concurrent" trouvé.
| Concept de scénario d'usage non compris. Une réponse à la question difficile très rapide et non convaincante.
| Une liste de matériel dans la page Wiki mais à insérer dans le tableau en bas de la page principale. Pas de référence (voir sur la page de l'an passé).
| Le travail avec le prototype pilote de LEDs est très bien décrit et de façon agréable à lire. Par contre le schéma du futur circuit est très mal engagé. Il faut commencer par faire un schéma plus précis du collier.
|
|
|
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Support assez corrects, sujet non entièrement compris, scénario d'usage minimal.
| Un problème dans le scénario d'usage : les conteneurs doivent être lancés sur un serveur. Une réponse acceptable à la question difficile.
| Pas de matériel particulier.
| Rien sur l'avancé du projet. Aucun travail ?
|
|
|
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Analyse très correcte.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Compte-rendu du travail très lapidaire et parfois illisible à cause des coquilles. Le Wiki ne donne pas l'impression que le projet avance.
|
|
|
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Présentation trop impécise, pas vraiment de scénario d'usage. Par contre des concurrents ont été présentés.
| Un scénario d'usage éloigné de la future utilisation. Trop de coquilles dans ce scénario. Réponse à la question difficile.
| Une liste du matériel mais pas dans la page principale. Pas de référence (voir page de l'an passé).
| Compte-rendu non à jour au 18/02/2018 alors que la feuille d'heures est à jour. Le Wiki manque d'illustration, par exemple donnez le schéma du circuit. Des informations sur la carte en gestation.
|
|
|
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Analyse très correcte. Un concurrent assez peu en rapport avec les essaims de robots mais dans la ligne des dispositifs de déminage.
| Pas de question difficile.
| Liste du matériel. Préciser pour le chassis.
| Impossible de connaître l'avancé du projet à la lecture du Wiki. N'êtes-vous pas entrain de vous perdre dans vos problèmes avec FreeRTOS ?
|
|
|
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Objectif mal expliqué. Exercice réalisé.
| Mieux définir l'objectif suite à la visite en entreprise. Pas de réponse à la question difficile.
| Aucune liste de matériel.
| Bonne description du travail. Votre Wiki manque d'illustrations sur un sujet qui le permet.
|
|
|
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Excellente présentation et excellent travail préparatoire, Scénario d'usage à préciser, trouver des concurrents.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Attention quand vous dites qu'un ATMega328p n'a pas assez de sorties pour commander 8 oscillateurs, il dispose tout de même de plus de 20 E/S.
|
|
|
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Exercice réussi. Cependant précisez les acteurs dans le scénario d'usage.
| Pas de modification du scénario. Pas de réponse à la question difficile.
| Rien à redire sur la liste de matériel.
| Description du travail correct, des illustrations. Essayez de formater avec la syntaxe Wiki.
|
|
|
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Analyse très correcte.
| Réponses aux questions difficiles.
| Aucune liste de matériel.
| Le travail effectué est décrit. Un nombre de coquilles non acceptable, la lecture en devient difficile. Utilisez la syntaxe de formatage du Wiki.
|
|
|
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Sujet se prêtant peu à l'exercice mais très bonne présentation. Sujet travaillé.
| Pas vraiment de question, la suggestion est noté dans la page Wiki.
| Pas de matériel à commander.
| Description du travail un peu rapide (DNS leak quesako ?). Rédaction en cours au moment de la lecture du Wiki.Effort de rédaction entre le 18/02/2018 et le 19/02/2018. Il manque des sections mais le travail effectué devient lisible.
|
|
|
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Analyse très correcte.
| Pas de réponse aux questions difficiles "Comment démarrer l'imprimante à distance ? Comment sera calibrée la plaque d’impression ?
Comment la plaque va se fixer sur le sol ? 
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Il est possible de mettre une copie d'écran de l'application de plus. Pas la peine de vous tirer dans les pattes.
|
|
|
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Le projet ne semble pas encore avoir été sérieusement étudié.
| Net effort de documentation de la page Wiki. Pas de réponse directe à la question difficile sur la Kinect mais une discussion sur le problème posé.
| Aucune liste de matériel.
| Très bonne description du travail. Des illustrations mais il pourrait y avoir des photos du système robotino / kinect.
|
|
|
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Contexte mal présenté, sujet flou. Scénario d'usage à préciser. Pas de contact avec les encadrants avant la présentation.
| Page de Wiki vide.
| Aucune liste de matériel.
| Compte-rendu rapide du travail. Ce compte-rendu est inquiétant. Il ne semble y avoir aucun résultat depuis le début du projet. Un module a été abandonné sans que le module en question n'ait été décrit ou que la raison de l'abandon ait été précisé. Attention votre projet est en voie d'échec.
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Doublant
| Page de Wiki assez vide.
| Aucune liste de matériel.
| Le robot centaure est en plus mauvais état maintenant qu'au début du projet. Vous semblez avoir une nouvelle fois abandonné votre projet. Des ajouts mineurs au Wiki le 19/02/2018.
|
|
|
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Présentation très correcte.
| Pas de réponse à la question difficile. Page Wiki un peu vide.
| Pas de matériel à commander.
| Un Wiki incomplet alors que la feuille d'heures est actualisée. Vous semblez toujours bloqués sur les problèmes d'étalonnage !
|
|
|
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Doublant
| Wiki avec quelques informations sur le travail accompli depuis fin novembre : étude sur modbus et labview. Quelques coquilles.
| Aucune liste de matériel.
| Très peu d'illustrations. Texte mal formaté et avec des coquilles intolérable à ce niveau d'étude. Le compte-rendu donne l'impression d'une méthode de travail très brouillonne.
|
|
|
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Présentation sans support. Trouver des concurrents indirects. Pas de scénario d'usage.
| Page Wiki vide.
| Aucune liste de matériel.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Analyse très correcte.
| Page Wiki bien tenue. Ajoutez des illustrations.
| Quelques éléments sur le matériel dans la page Wiki mais aucune liste avec références.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Presque à jour. Vous n'aviez pas des cartes à faire fabriquer à l'extérieur ?
|
|
|
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Exercice bien réalisé.
| Page Wiki très complète. Ajoutez des illustrations.
| Une liste probablement pas exhaustive.
|Exceptionnel ! Très illustré, bien rédigé, le travail de recherche est très bien décrit. Je ne suis pas un fan de la mise en gras d'un quart du texte et la syntaxe Wiki n'est pas vraiment utilisée mais c'est du détail?
|
|
|
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Doublant
| Page Wiki vide.
| Pas de matériel à commander.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Erasmus
|
|
| Projet en échec constaté.
|
|
|
|-
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (17/01) !! Séance 2 (24/01) !! Séance 3 (31/01) !! Séance 4 (7/02) !! Séance 5 (14/02) !! Séance 6 (21/02) !! Séance 7 (7/03) !! Séance 8 (14/03) !! Séance 9 (21/03) !! Séance 10 (28/03) !! Séance 11 (4/04) !! Séance 12 (11/04) !! Séance 13 (18/04)
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|Quentin Boëns / Henri Carlier
|E304
|E304/305
|E304
|E304
|E304
|C201
|C201
|C201/E304
|E304/Fab
|Fab
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|Ji Yang
|E306
|E303
| Pas de salle 
|E301
|E306
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexis Viscogliosi / Abass Ayoub
|C008
|C008
|E304 Alexis Viscogliosi Absent excusé pour entretien stage
|C008
|C008
|C201
|C201
|C201
|C201
|C201
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Paul Ribeiro / Mehanna Naïf
|E303
|E301
|A204 Absents 
|E301
|E301 puis B309 puis B207
|E301
|E301
|C201 puis E304
|C201 et E304
|C201
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Antoine Gosse
| E306
| E306
| E306
| E306
| E306
| E306
| E306
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Maëva Delaporte / Simon Blas
| E304 
| E304 
| E304 
| E301 
| E301 
| E301 
| E301 
| C201/E304 
| E301 
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Baptiste Cartier
| E306
| E301
| E306
| E301
| E301
| E301
| E306
| E304
| E306
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Amine El Messaoudi / Simon Feutrier
| E301
| E301
| C201
| C201
| B207
| C201
| C201
| C201
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Jade Dupont
|E304
|E304
|E304
|E304
|E304
|Absence Maladie
|E304
|E304
|E304
|E304
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Thomas Cunin / Thibault Cattelain
| E304
| B306/E304
| Pas de salle (E304 - A305)
| E301
| E301
| E301
| E301
| E304
| E304/C200
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Rémi Mairesse / Gustave Roux
| E304
| E301
| Pas de salle 
| E304
| E304
| E304 / C201
| C201
| C201
| C201
| C201
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Oumaima Naanaa
|E302
|E304
|E304
|E304
|E304
|E304
|E304
|E304
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Lirui Zhang / Lihe Zhang
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| C201
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Lijie Yao / Keren Qiang
| E303
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Maxime Creteur / Gao Fan
|E303
|E301
|A204 Absents 
|E303
|B309 puis B207
|E301
|E301
|E304
|E301
|E301
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Amaury Knockaert / Fabrice Taingland
| E304
| E304
| E304/E302
| C203/E306
| E306/E304
| Forum stages euratech/E304
| E304
| E306
| E306
| E306
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Matthieu Delobelle
| E306
| E306
| E303 - C201
| E306 - C201
| E304
| E306
| E306
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Benjamin Canu / Ganix Etcheguibel
| E306
| E306
| E306
| E306
| E306
| Forum Euratech jusque 17h E306
| E306
| E306
| E306
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Taky Djeraba / Thomas Hubert
| E306
| E306
| Pas de salle 
| E306
| E306
| E306
| E306
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Jean-Baptiste Watine / Antoine Untereiner
| E306/C201
| E301
| Pas de salle (C201) 
| C205
| C205/E301
| C205/E301
| E301
| C205
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Transley Gracias / Camille Saad
| E306
| E306
| E305
| E306
| E306
| E306
| E306
| E306/C202
| E306
| E306
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Xavier Chenot / Rodolphe Toin
| E306
| E306
| E306
| E306
| E306
| E306
| E306 puis C201
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Antoine Duquenoy / Anthony Durot
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E305
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Eloi Zalczer / Justine Senellart
|E302/E306
|E302/E306
|E304/E302
|E304/E302
|E306/E302
|Hors Polytech/E302
|E302/E304
|E302/E304
|E304/E302
|E306/E302
|
|-
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Damien Narbais / Zoé Briois
| E306
| E301
| Pas de salle (E301)
| E304 + 17h réunion C00X
| C205
| E304 + 17h réunion C00X
| A317
| E304
| E30X
| C205 + Damien -> entretien stage
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Hugo Delbroucq / Nicolas Havard
| E301
| INRIA
| Pas de salle (INRIA)
| E301
| E301 puis E304
| E301
| E301
| E304
| INRIA
| E301
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Claire Vandamme / Alexandra Villa
|C008
|C008
|Hors Polytech/B106
|C008
|C008
|Bureau de Mr Pekpe/E306
|C008
|C008
|C008(Claire : jusque 16h, RDV médical)
|C008
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Florian Le Foll
| E301
| E301
| (Pas de salle) E303
|E303
|E303
|C201
|C201
|C201
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Carval Amaury/ Prud'Homme Geoffrey
| fabricarium
| fabricarium puis Hors Polytech
| E304
| E301
| Carval E306 - Preud'homme E301
| E301
| Carval C20X - Preud'homme Fabricarium
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Erwan Dufresne
| E302/E306
| E301
| E304
| E301
| E302
| E306
| E302
| E302/Fabricarium
| E302/Fabricarium
| Fabricarium/E304
|
|-
| PP1 [[IMA4 2017/2018 PP1|Robot hexapode pour escalier]]
| Eduardo Gomez
| C201
| C201
| C201
| Fabricarium
| Fabricarium
| C201
| C201/Fabricarium
| C201/Fabricarium
| C201/Fabricarium
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|}

Discussion:Projets IMA4 SC & SA 2017/2018

2018-03-28T13:39:23Z

Zbriois : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Analyse du projet || Retour sur l'analyse || Matériel || Mi-parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Présentation sans supports, bonne analyse de la concurrence. Par contre le scénario d'usage est à revoir en précisant l'usage pour le particulier.
| Le scénario est précisé mais aucune réponse aux questions difficiles "gestion des températures et procédure d'entretien".
| Rien.
| Si le contenu du Wiki reflète la quantité de travail fourni, c'est inquiétant.
|
|
|
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Présentation focalisée sur les réseaux de neurones. Exercice mal compris (pas d'introduction du contexte, pas de scénario d'usage).
| Toujours pas d'analyse de la concurrence, ni de scénario d'usage. Pas de réponse aux questions difficiles "quel est le matériel ? quel est le protocole ? quelles sont les entrées du réseau de neurones ?".
| Une liste mais il manque des références vers les fournisseurs agréés (voir page de l'an dernier).
| Illustrez votre Wiki avec des schémas ou des photos de votre montage. Décrivez mieux votre plateforme de test et les résultats obtenus. Essayez de corriger les problèmes de français.
|
|
|
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Exercice correctement réalisé.
| Pas de réponse aux questions difficiles "Architecture de la source d'énergie (nombre de chemins d'énergie ?)".
| Rien.
| Vous devriez avoir quelques éléments sur la réalisation. Complétez votre Wiki.
|
|
|
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Présentation focalisée sur la création du site Web. Effort fait pour rédiger un scénario d'usage.
| Réponses aux questions mais l'analyse de la consommation est imprécise. 
| Du matériel listé dans la page Wiki mais à reporter en bas de la page des projets de cette année avec des références valides.
| Un effort de documentation mais illustrez par des schémas, des pages de l'application et des tests.
|
|
|
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Exercice correctement réalisé. Scénario d'usage à préciser sur la partie réseau de capteurs.
| Scénario d'usage non précisé. Pas de réponse à la question difficile.
| Du matériel listé mais sans référence, êtes-vous sur que le matériel n'a pas besoin d'être acheté ?
| Très bonne description de l'avancé du projet. N'hésitez pas à solliciter votre encadrant direct en cas de blocage !
|
|
|
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Pas de support. Exercice très bien réalisé.
| Pas de réponse aux questions difficiles "quelle alimentation ? comment faire pour différencier les briques ? comment les briques vont-elles communiquer ? quelle sécurité vis-à-vis des enfants ?"
| Pas de liste de matériel.
| Très bonne description de l'avancé du projet. Faites un effort de formatage du texte (par exemple en utilisant des sous-titres plutôt que de souligner des lignes).
|
|
|
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Rien à signaler (juste une confusion entre le MSP430 et le CC430).
| Questions difficiles évacuées. 
| Du matériel listé mais sans référence.
| Une bonne description de l'avancé du projet.
|
|
|
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Un peu rapide, exercice réalisé. 
| Pas d'analyse de la concurrence. Peu d'effort de rédaction. Des coquilles. Une réponse rapide à la question difficile.
| Du matériel listé mais pas forcément exhaustif et sans référence valide.
| Très bonne description de l'avancé du projet. Wiki agréable à lire.
|
|
|
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Doublant
| Doublant
| Page Wiki vide, pas de liste de matériel.
| Une bonne description de l'avancé du projet. Essayez de mieux formater votre texte pour une meilleure facilité de lecture.
|
|
|
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Présentation acceptable mais avec des supports non soignés. Pas d'analyse de la concurrence, pas de scénario d'usage.
| L'analyse de la concurrence et le scénario d'usage ont été ajoutés. Par contre pas de réponse aux questions difficiles "quelle sera l'autonomie de la balle et quel sera le système de rechargement ?".
| Pas de liste de matériel.
| Rien sur l'avancé du projet au 18/02/2018. Wiki mis à jour en catastrophe le 19/02/2018. Peu d'informations, seul le routage d'une carte semble avoir été entrepris.
|
|
|
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Présentation acceptable mais avec des supports non soignés. Trouver des concurrents indirects. Une histoire mais pas de scénario d'usage.
| Page Wiki modifiée après la présentation. Une réponse incomplète à la question difficile. Trop de coquilles pour ce niveau d'études.
| Pas de liste de matériel.
| Bonne description du travail. Cinq séances pour faire chauffer une résistance, n'est-ce pas trop ?
|
|
|
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Doublant
| Doublant
| Aucune modification de la page Wiki depuis début octobre.
| Une bonne description de l'avancé du projet. Projet encore dans la phase de prototypage. Comment vous comptez recevoir une carte SIM ?
|
|
|
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Supports très textuels, pas de scénario d'usage mais une rédaction sur l'intérêt psychologique, pas vraiment de partie "concurrents".
| Un effort pour trouver des "concurrents", pas de réponses aux questions difficiles "combien de LEDs ? quelle alimentation pour quelle autonomie".
| Pas de liste de matériel.
| Le travail est a peu près décrit mais la page Wiki ressemble a un brouillon.
|
|
|
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Bonne présentation orale. Utilisation du bluetooth peu convainquant. Pas de scénario d'usage. Un "concurrent" trouvé.
| Concept de scénario d'usage non compris. Une réponse à la question difficile très rapide et non convaincante.
| Une liste de matériel dans la page Wiki mais à insérer dans le tableau en bas de la page principale. Pas de référence (voir sur la page de l'an passé).
| Le travail avec le prototype pilote de LEDs est très bien décrit et de façon agréable à lire. Par contre le schéma du futur circuit est très mal engagé. Il faut commencer par faire un schéma plus précis du collier.
|
|
|
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Support assez corrects, sujet non entièrement compris, scénario d'usage minimal.
| Un problème dans le scénario d'usage : les conteneurs doivent être lancés sur un serveur. Une réponse acceptable à la question difficile.
| Pas de matériel particulier.
| Rien sur l'avancé du projet. Aucun travail ?
|
|
|
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Analyse très correcte.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Compte-rendu du travail très lapidaire et parfois illisible à cause des coquilles. Le Wiki ne donne pas l'impression que le projet avance.
|
|
|
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Présentation trop impécise, pas vraiment de scénario d'usage. Par contre des concurrents ont été présentés.
| Un scénario d'usage éloigné de la future utilisation. Trop de coquilles dans ce scénario. Réponse à la question difficile.
| Une liste du matériel mais pas dans la page principale. Pas de référence (voir page de l'an passé).
| Compte-rendu non à jour au 18/02/2018 alors que la feuille d'heures est à jour. Le Wiki manque d'illustration, par exemple donnez le schéma du circuit. Des informations sur la carte en gestation.
|
|
|
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Analyse très correcte. Un concurrent assez peu en rapport avec les essaims de robots mais dans la ligne des dispositifs de déminage.
| Pas de question difficile.
| Liste du matériel. Préciser pour le chassis.
| Impossible de connaître l'avancé du projet à la lecture du Wiki. N'êtes-vous pas entrain de vous perdre dans vos problèmes avec FreeRTOS ?
|
|
|
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Objectif mal expliqué. Exercice réalisé.
| Mieux définir l'objectif suite à la visite en entreprise. Pas de réponse à la question difficile.
| Aucune liste de matériel.
| Bonne description du travail. Votre Wiki manque d'illustrations sur un sujet qui le permet.
|
|
|
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Excellente présentation et excellent travail préparatoire, Scénario d'usage à préciser, trouver des concurrents.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Attention quand vous dites qu'un ATMega328p n'a pas assez de sorties pour commander 8 oscillateurs, il dispose tout de même de plus de 20 E/S.
|
|
|
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Exercice réussi. Cependant précisez les acteurs dans le scénario d'usage.
| Pas de modification du scénario. Pas de réponse à la question difficile.
| Rien à redire sur la liste de matériel.
| Description du travail correct, des illustrations. Essayez de formater avec la syntaxe Wiki.
|
|
|
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Analyse très correcte.
| Réponses aux questions difficiles.
| Aucune liste de matériel.
| Le travail effectué est décrit. Un nombre de coquilles non acceptable, la lecture en devient difficile. Utilisez la syntaxe de formatage du Wiki.
|
|
|
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Sujet se prêtant peu à l'exercice mais très bonne présentation. Sujet travaillé.
| Pas vraiment de question, la suggestion est noté dans la page Wiki.
| Pas de matériel à commander.
| Description du travail un peu rapide (DNS leak quesako ?). Rédaction en cours au moment de la lecture du Wiki.Effort de rédaction entre le 18/02/2018 et le 19/02/2018. Il manque des sections mais le travail effectué devient lisible.
|
|
|
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Analyse très correcte.
| Pas de réponse aux questions difficiles "Comment démarrer l'imprimante à distance ? Comment sera calibrée la plaque d’impression ?
Comment la plaque va se fixer sur le sol ? 
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Il est possible de mettre une copie d'écran de l'application de plus. Pas la peine de vous tirer dans les pattes.
|
|
|
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Le projet ne semble pas encore avoir été sérieusement étudié.
| Net effort de documentation de la page Wiki. Pas de réponse directe à la question difficile sur la Kinect mais une discussion sur le problème posé.
| Aucune liste de matériel.
| Très bonne description du travail. Des illustrations mais il pourrait y avoir des photos du système robotino / kinect.
|
|
|
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Contexte mal présenté, sujet flou. Scénario d'usage à préciser. Pas de contact avec les encadrants avant la présentation.
| Page de Wiki vide.
| Aucune liste de matériel.
| Compte-rendu rapide du travail. Ce compte-rendu est inquiétant. Il ne semble y avoir aucun résultat depuis le début du projet. Un module a été abandonné sans que le module en question n'ait été décrit ou que la raison de l'abandon ait été précisé. Attention votre projet est en voie d'échec.
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Doublant
| Page de Wiki assez vide.
| Aucune liste de matériel.
| Le robot centaure est en plus mauvais état maintenant qu'au début du projet. Vous semblez avoir une nouvelle fois abandonné votre projet. Des ajouts mineurs au Wiki le 19/02/2018.
|
|
|
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Présentation très correcte.
| Pas de réponse à la question difficile. Page Wiki un peu vide.
| Pas de matériel à commander.
| Un Wiki incomplet alors que la feuille d'heures est actualisée. Vous semblez toujours bloqués sur les problèmes d'étalonnage !
|
|
|
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Doublant
| Wiki avec quelques informations sur le travail accompli depuis fin novembre : étude sur modbus et labview. Quelques coquilles.
| Aucune liste de matériel.
| Très peu d'illustrations. Texte mal formaté et avec des coquilles intolérable à ce niveau d'étude. Le compte-rendu donne l'impression d'une méthode de travail très brouillonne.
|
|
|
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Présentation sans support. Trouver des concurrents indirects. Pas de scénario d'usage.
| Page Wiki vide.
| Aucune liste de matériel.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Analyse très correcte.
| Page Wiki bien tenue. Ajoutez des illustrations.
| Quelques éléments sur le matériel dans la page Wiki mais aucune liste avec références.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Presque à jour. Vous n'aviez pas des cartes à faire fabriquer à l'extérieur ?
|
|
|
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Exercice bien réalisé.
| Page Wiki très complète. Ajoutez des illustrations.
| Une liste probablement pas exhaustive.
|Exceptionnel ! Très illustré, bien rédigé, le travail de recherche est très bien décrit. Je ne suis pas un fan de la mise en gras d'un quart du texte et la syntaxe Wiki n'est pas vraiment utilisée mais c'est du détail?
|
|
|
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Doublant
| Page Wiki vide.
| Pas de matériel à commander.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Erasmus
|
|
| Projet en échec constaté.
|
|
|
|-
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (17/01) !! Séance 2 (24/01) !! Séance 3 (31/01) !! Séance 4 (7/02) !! Séance 5 (14/02) !! Séance 6 (21/02) !! Séance 7 (7/03) !! Séance 8 (14/03) !! Séance 9 (21/03) !! Séance 10 (28/03) !! Séance 11 (4/04) !! Séance 12 (11/04) !! Séance 13 (18/04)
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|Quentin Boëns / Henri Carlier
|E304
|E304/305
|E304
|E304
|E304
|C201
|C201
|C201/E304
|E304/Fab
|Fab
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|Ji Yang
|E306
|E303
| Pas de salle 
|E301
|E306
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexis Viscogliosi / Abass Ayoub
|C008
|C008
|E304 Alexis Viscogliosi Absent excusé pour entretien stage
|C008
|C008
|C201
|C201
|C201
|C201
|C201
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Paul Ribeiro / Mehanna Naïf
|E303
|E301
|A204 Absents 
|E301
|E301 puis B309 puis B207
|E301
|E301
|C201 puis E304
|C201 et E304
|C201
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Antoine Gosse
| E306
| E306
| E306
| E306
| E306
| E306
| E306
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Maëva Delaporte / Simon Blas
| E304 
| E304 
| E304 
| E301 
| E301 
| E301 
| E301 
| C201/E304 
| E301 
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Baptiste Cartier
| E306
| E301
| E306
| E301
| E301
| E301
| E306
| E304
| E306
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Amine El Messaoudi / Simon Feutrier
| E301
| E301
| C201
| C201
| B207
| C201
| C201
| C201
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Jade Dupont
|E304
|E304
|E304
|E304
|E304
|Absence Maladie
|E304
|E304
|E304
|E304
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Thomas Cunin / Thibault Cattelain
| E304
| B306/E304
| Pas de salle (E304 - A305)
| E301
| E301
| E301
| E301
| E304
| E304/C200
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Rémi Mairesse / Gustave Roux
| E304
| E301
| Pas de salle 
| E304
| E304
| E304 / C201
| C201
| C201
| C201
| C201
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Oumaima Naanaa
|E302
|E304
|E304
|E304
|E304
|E304
|E304
|E304
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Lirui Zhang / Lihe Zhang
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| C201
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Lijie Yao / Keren Qiang
| E303
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Maxime Creteur / Gao Fan
|E303
|E301
|A204 Absents 
|E303
|B309 puis B207
|E301
|E301
|E304
|E301
|E301
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Amaury Knockaert / Fabrice Taingland
| E304
| E304
| E304/E302
| C203/E306
| E306/E304
| Forum stages euratech/E304
| E304
| E306
| E306
| E306
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Matthieu Delobelle
| E306
| E306
| E303 - C201
| E306 - C201
| E304
| E306
| E306
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Benjamin Canu / Ganix Etcheguibel
| E306
| E306
| E306
| E306
| E306
| Forum Euratech jusque 17h E306
| E306
| E306
| E306
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Taky Djeraba / Thomas Hubert
| E306
| E306
| Pas de salle 
| E306
| E306
| E306
| E306
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Jean-Baptiste Watine / Antoine Untereiner
| E306/C201
| E301
| Pas de salle (C201) 
| C205
| C205/E301
| C205/E301
| E301
| C205
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Transley Gracias / Camille Saad
| E306
| E306
| E305
| E306
| E306
| E306
| E306
| E306/C202
| E306
| E306
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Xavier Chenot / Rodolphe Toin
| E306
| E306
| E306
| E306
| E306
| E306
| E306 puis C201
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Antoine Duquenoy / Anthony Durot
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E305
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Eloi Zalczer / Justine Senellart
|E302/E306
|E302/E306
|E304/E302
|E304/E302
|E306/E302
|Hors Polytech/E302
|E302/E304
|E302/E304
|E304/E302
|E306/E302
|
|-
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Damien Narbais / Zoé Briois
| E306
| E301
| Pas de salle (E301)
| E304 + 17h réunion C00X
| C205
| E304 + 17h réunion C00X
| A317
| E304
| E30X
| C205 | Damien -> entretien stage
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Hugo Delbroucq / Nicolas Havard
| E301
| INRIA
| Pas de salle (INRIA)
| E301
| E301 puis E304
| E301
| E301
| E304
| INRIA
| E301
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Claire Vandamme / Alexandra Villa
|C008
|C008
|Hors Polytech/B106
|C008
|C008
|Bureau de Mr Pekpe/E306
|C008
|C008
|C008(Claire : jusque 16h, RDV médical)
|C008
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Florian Le Foll
| E301
| E301
| (Pas de salle) E303
|E303
|E303
|C201
|C201
|C201
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Carval Amaury/ Prud'Homme Geoffrey
| fabricarium
| fabricarium puis Hors Polytech
| E304
| E301
| Carval E306 - Preud'homme E301
| E301
| Carval C20X - Preud'homme Fabricarium
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Erwan Dufresne
| E302/E306
| E301
| E304
| E301
| E302
| E306
| E302
| E302/Fabricarium
| E302/Fabricarium
| Fabricarium/E304
|
|-
| PP1 [[IMA4 2017/2018 PP1|Robot hexapode pour escalier]]
| Eduardo Gomez
| C201
| C201
| C201
| Fabricarium
| Fabricarium
| C201
| C201/Fabricarium
| C201/Fabricarium
| C201/Fabricarium
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|}

IMA4 2017/2018 P44

2018-03-28T13:14:27Z

Zbriois : /* Mars : Séance 4 - 28/03/18 */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
| 3
|
| 3
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
| 3
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
| 9
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
| 7
| 11
| 12
|
| 40
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
:- avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
:- cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

==Mars : Séance 4 - 28/03/18==
* Résumé sur l'utilisation de ROS: 
Pour executer un programme ROS il faut utiliser des fichiers spéciaux: les launch files. Pour cela on utilise la commande ''roslaunch <package_name> <launch_file>'' qui prend en paramètre le nom du package qui contient le launch file et le launch file lui même. 
ROS utilise des packages pour organiser ses programmes. On a les launch files dans le dossier launch, les fichiers sources (c++, python ...) dans le dossier src, la liste des règles cmake pour la compilation dans le CMakeLists.txt et les informations/dépendance du package dans le fichier package.xml. 
Pour aller dans un package il faut faire: ''roscd <package_name>'' 
Tout les fichiers launch contient un <launch> tag, dans ce tag on trouve un <node> tag, dans lequel on spécifie:
:1. pkg=“package_name” # nom du package qui contient le code pour le programme ROS a exécuter
:2. type=“python_file_name.py” # nom du programme qu'on veut executer
:3. name=“node_name” # Nom du node qui va launch le fichier Python
:4. output=“type_of_output” # C'est dans cette chaîne qu'on va imprimer la sortie du fichier Python
Comment créer un package ? 
Les packages que nous allons créer seront dans le dossier catkin_ws pour qu'ils puissent être exécutés par ROS. Quand on fait roscd on arrive dans le répertoire catkin_ws/devel. Les packages que nous on va créer on les placera dans catkin_ws/src. Pour créer un nouveau package: ''catkin_create_pkg <package_name> <package_dependecies>'' 
Pour vérifier qu'il a bien été crée on peut faire ''rospack list | grep my_package''

=Documents Rendus=

IMA4 2017/2018 P44

2018-03-28T13:14:02Z

Zbriois : /* Réalisation du Projet */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
| 3
|
| 3
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
| 3
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
| 9
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
| 7
| 11
| 12
|
| 40
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
:- avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
:- cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

==Mars : Séance 4 - 28/03/18==
* Résumé sur l'utilisation de ROS: 
Pour executer un programme ROS il faut utiliser des fichiers spéciaux: les launch files. Pour cela on utilise la commande ''roslaunch <package_name> <launch_file>'' qui prend en paramètre le nom du package qui contient le launch file et le launch file lui même. 
ROS utilise des packages pour organiser ses programmes. On a les launch files dans le dossier launch, les fichiers sources (c++, python ...) dans le dossier src, la liste des règles cmake pour la compilation dans le CMakeLists.txt et les informations/dépendance du package dans le fichier package.xml. 
Pour aller dans un package il faut faire: ''roscd <package_name>'' 
Tout les fichiers launch contient un <launch> tag, dans ce tag on trouve un <node> tag, dans lequel on spécifie:
:1. pkg=“package_name” # nom du package qui contient le code pour le programme ROS a exécuter
:2. type=“python_file_name.py” # nom du programme qu'on veut executer
:3. name=“node_name” # Nom du node qui va launch le fichier Python
:4. output=“type_of_output” # C'est dans cette chaîne qu'on va imprimer la sortie du fichier Python
Comment créer un package ? 
Les packages que nous allons créer seront dans le dossier catkin_ws pour qu'ils puissent être exécutés par ROS. Quand on fait roscd on arrive dans le répertoire catkin_ws/devel. Les packages que nous on va créer on les placera dans catkin_ws/src. Pour créer un nouveau package: ''catkin_create_pkg <package_name> <package_dependecies>'' 
Pour vérifier qu'il a bien été créer on peut faire ''rospack list | grep my_package''

=Documents Rendus=

Discussion:Projets IMA4 SC & SA 2017/2018

2018-03-28T13:06:06Z

Zbriois : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Analyse du projet || Retour sur l'analyse || Matériel || Mi-parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Présentation sans supports, bonne analyse de la concurrence. Par contre le scénario d'usage est à revoir en précisant l'usage pour le particulier.
| Le scénario est précisé mais aucune réponse aux questions difficiles "gestion des températures et procédure d'entretien".
| Rien.
| Si le contenu du Wiki reflète la quantité de travail fourni, c'est inquiétant.
|
|
|
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Présentation focalisée sur les réseaux de neurones. Exercice mal compris (pas d'introduction du contexte, pas de scénario d'usage).
| Toujours pas d'analyse de la concurrence, ni de scénario d'usage. Pas de réponse aux questions difficiles "quel est le matériel ? quel est le protocole ? quelles sont les entrées du réseau de neurones ?".
| Une liste mais il manque des références vers les fournisseurs agréés (voir page de l'an dernier).
| Illustrez votre Wiki avec des schémas ou des photos de votre montage. Décrivez mieux votre plateforme de test et les résultats obtenus. Essayez de corriger les problèmes de français.
|
|
|
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Exercice correctement réalisé.
| Pas de réponse aux questions difficiles "Architecture de la source d'énergie (nombre de chemins d'énergie ?)".
| Rien.
| Vous devriez avoir quelques éléments sur la réalisation. Complétez votre Wiki.
|
|
|
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Présentation focalisée sur la création du site Web. Effort fait pour rédiger un scénario d'usage.
| Réponses aux questions mais l'analyse de la consommation est imprécise. 
| Du matériel listé dans la page Wiki mais à reporter en bas de la page des projets de cette année avec des références valides.
| Un effort de documentation mais illustrez par des schémas, des pages de l'application et des tests.
|
|
|
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Exercice correctement réalisé. Scénario d'usage à préciser sur la partie réseau de capteurs.
| Scénario d'usage non précisé. Pas de réponse à la question difficile.
| Du matériel listé mais sans référence, êtes-vous sur que le matériel n'a pas besoin d'être acheté ?
| Très bonne description de l'avancé du projet. N'hésitez pas à solliciter votre encadrant direct en cas de blocage !
|
|
|
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Pas de support. Exercice très bien réalisé.
| Pas de réponse aux questions difficiles "quelle alimentation ? comment faire pour différencier les briques ? comment les briques vont-elles communiquer ? quelle sécurité vis-à-vis des enfants ?"
| Pas de liste de matériel.
| Très bonne description de l'avancé du projet. Faites un effort de formatage du texte (par exemple en utilisant des sous-titres plutôt que de souligner des lignes).
|
|
|
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Rien à signaler (juste une confusion entre le MSP430 et le CC430).
| Questions difficiles évacuées. 
| Du matériel listé mais sans référence.
| Une bonne description de l'avancé du projet.
|
|
|
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Un peu rapide, exercice réalisé. 
| Pas d'analyse de la concurrence. Peu d'effort de rédaction. Des coquilles. Une réponse rapide à la question difficile.
| Du matériel listé mais pas forcément exhaustif et sans référence valide.
| Très bonne description de l'avancé du projet. Wiki agréable à lire.
|
|
|
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Doublant
| Doublant
| Page Wiki vide, pas de liste de matériel.
| Une bonne description de l'avancé du projet. Essayez de mieux formater votre texte pour une meilleure facilité de lecture.
|
|
|
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Présentation acceptable mais avec des supports non soignés. Pas d'analyse de la concurrence, pas de scénario d'usage.
| L'analyse de la concurrence et le scénario d'usage ont été ajoutés. Par contre pas de réponse aux questions difficiles "quelle sera l'autonomie de la balle et quel sera le système de rechargement ?".
| Pas de liste de matériel.
| Rien sur l'avancé du projet au 18/02/2018. Wiki mis à jour en catastrophe le 19/02/2018. Peu d'informations, seul le routage d'une carte semble avoir été entrepris.
|
|
|
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Présentation acceptable mais avec des supports non soignés. Trouver des concurrents indirects. Une histoire mais pas de scénario d'usage.
| Page Wiki modifiée après la présentation. Une réponse incomplète à la question difficile. Trop de coquilles pour ce niveau d'études.
| Pas de liste de matériel.
| Bonne description du travail. Cinq séances pour faire chauffer une résistance, n'est-ce pas trop ?
|
|
|
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Doublant
| Doublant
| Aucune modification de la page Wiki depuis début octobre.
| Une bonne description de l'avancé du projet. Projet encore dans la phase de prototypage. Comment vous comptez recevoir une carte SIM ?
|
|
|
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Supports très textuels, pas de scénario d'usage mais une rédaction sur l'intérêt psychologique, pas vraiment de partie "concurrents".
| Un effort pour trouver des "concurrents", pas de réponses aux questions difficiles "combien de LEDs ? quelle alimentation pour quelle autonomie".
| Pas de liste de matériel.
| Le travail est a peu près décrit mais la page Wiki ressemble a un brouillon.
|
|
|
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Bonne présentation orale. Utilisation du bluetooth peu convainquant. Pas de scénario d'usage. Un "concurrent" trouvé.
| Concept de scénario d'usage non compris. Une réponse à la question difficile très rapide et non convaincante.
| Une liste de matériel dans la page Wiki mais à insérer dans le tableau en bas de la page principale. Pas de référence (voir sur la page de l'an passé).
| Le travail avec le prototype pilote de LEDs est très bien décrit et de façon agréable à lire. Par contre le schéma du futur circuit est très mal engagé. Il faut commencer par faire un schéma plus précis du collier.
|
|
|
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Support assez corrects, sujet non entièrement compris, scénario d'usage minimal.
| Un problème dans le scénario d'usage : les conteneurs doivent être lancés sur un serveur. Une réponse acceptable à la question difficile.
| Pas de matériel particulier.
| Rien sur l'avancé du projet. Aucun travail ?
|
|
|
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Analyse très correcte.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Compte-rendu du travail très lapidaire et parfois illisible à cause des coquilles. Le Wiki ne donne pas l'impression que le projet avance.
|
|
|
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Présentation trop impécise, pas vraiment de scénario d'usage. Par contre des concurrents ont été présentés.
| Un scénario d'usage éloigné de la future utilisation. Trop de coquilles dans ce scénario. Réponse à la question difficile.
| Une liste du matériel mais pas dans la page principale. Pas de référence (voir page de l'an passé).
| Compte-rendu non à jour au 18/02/2018 alors que la feuille d'heures est à jour. Le Wiki manque d'illustration, par exemple donnez le schéma du circuit. Des informations sur la carte en gestation.
|
|
|
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Analyse très correcte. Un concurrent assez peu en rapport avec les essaims de robots mais dans la ligne des dispositifs de déminage.
| Pas de question difficile.
| Liste du matériel. Préciser pour le chassis.
| Impossible de connaître l'avancé du projet à la lecture du Wiki. N'êtes-vous pas entrain de vous perdre dans vos problèmes avec FreeRTOS ?
|
|
|
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Objectif mal expliqué. Exercice réalisé.
| Mieux définir l'objectif suite à la visite en entreprise. Pas de réponse à la question difficile.
| Aucune liste de matériel.
| Bonne description du travail. Votre Wiki manque d'illustrations sur un sujet qui le permet.
|
|
|
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Excellente présentation et excellent travail préparatoire, Scénario d'usage à préciser, trouver des concurrents.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Attention quand vous dites qu'un ATMega328p n'a pas assez de sorties pour commander 8 oscillateurs, il dispose tout de même de plus de 20 E/S.
|
|
|
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Exercice réussi. Cependant précisez les acteurs dans le scénario d'usage.
| Pas de modification du scénario. Pas de réponse à la question difficile.
| Rien à redire sur la liste de matériel.
| Description du travail correct, des illustrations. Essayez de formater avec la syntaxe Wiki.
|
|
|
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Analyse très correcte.
| Réponses aux questions difficiles.
| Aucune liste de matériel.
| Le travail effectué est décrit. Un nombre de coquilles non acceptable, la lecture en devient difficile. Utilisez la syntaxe de formatage du Wiki.
|
|
|
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Sujet se prêtant peu à l'exercice mais très bonne présentation. Sujet travaillé.
| Pas vraiment de question, la suggestion est noté dans la page Wiki.
| Pas de matériel à commander.
| Description du travail un peu rapide (DNS leak quesako ?). Rédaction en cours au moment de la lecture du Wiki.Effort de rédaction entre le 18/02/2018 et le 19/02/2018. Il manque des sections mais le travail effectué devient lisible.
|
|
|
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Analyse très correcte.
| Pas de réponse aux questions difficiles "Comment démarrer l'imprimante à distance ? Comment sera calibrée la plaque d’impression ?
Comment la plaque va se fixer sur le sol ? 
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Il est possible de mettre une copie d'écran de l'application de plus. Pas la peine de vous tirer dans les pattes.
|
|
|
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Le projet ne semble pas encore avoir été sérieusement étudié.
| Net effort de documentation de la page Wiki. Pas de réponse directe à la question difficile sur la Kinect mais une discussion sur le problème posé.
| Aucune liste de matériel.
| Très bonne description du travail. Des illustrations mais il pourrait y avoir des photos du système robotino / kinect.
|
|
|
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Contexte mal présenté, sujet flou. Scénario d'usage à préciser. Pas de contact avec les encadrants avant la présentation.
| Page de Wiki vide.
| Aucune liste de matériel.
| Compte-rendu rapide du travail. Ce compte-rendu est inquiétant. Il ne semble y avoir aucun résultat depuis le début du projet. Un module a été abandonné sans que le module en question n'ait été décrit ou que la raison de l'abandon ait été précisé. Attention votre projet est en voie d'échec.
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Doublant
| Page de Wiki assez vide.
| Aucune liste de matériel.
| Le robot centaure est en plus mauvais état maintenant qu'au début du projet. Vous semblez avoir une nouvelle fois abandonné votre projet. Des ajouts mineurs au Wiki le 19/02/2018.
|
|
|
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Présentation très correcte.
| Pas de réponse à la question difficile. Page Wiki un peu vide.
| Pas de matériel à commander.
| Un Wiki incomplet alors que la feuille d'heures est actualisée. Vous semblez toujours bloqués sur les problèmes d'étalonnage !
|
|
|
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Doublant
| Wiki avec quelques informations sur le travail accompli depuis fin novembre : étude sur modbus et labview. Quelques coquilles.
| Aucune liste de matériel.
| Très peu d'illustrations. Texte mal formaté et avec des coquilles intolérable à ce niveau d'étude. Le compte-rendu donne l'impression d'une méthode de travail très brouillonne.
|
|
|
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Présentation sans support. Trouver des concurrents indirects. Pas de scénario d'usage.
| Page Wiki vide.
| Aucune liste de matériel.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Analyse très correcte.
| Page Wiki bien tenue. Ajoutez des illustrations.
| Quelques éléments sur le matériel dans la page Wiki mais aucune liste avec références.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Presque à jour. Vous n'aviez pas des cartes à faire fabriquer à l'extérieur ?
|
|
|
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Exercice bien réalisé.
| Page Wiki très complète. Ajoutez des illustrations.
| Une liste probablement pas exhaustive.
|Exceptionnel ! Très illustré, bien rédigé, le travail de recherche est très bien décrit. Je ne suis pas un fan de la mise en gras d'un quart du texte et la syntaxe Wiki n'est pas vraiment utilisée mais c'est du détail?
|
|
|
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Doublant
| Page Wiki vide.
| Pas de matériel à commander.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Erasmus
|
|
| Projet en échec constaté.
|
|
|
|-
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (17/01) !! Séance 2 (24/01) !! Séance 3 (31/01) !! Séance 4 (7/02) !! Séance 5 (14/02) !! Séance 6 (21/02) !! Séance 7 (7/03) !! Séance 8 (14/03) !! Séance 9 (21/03) !! Séance 10 (28/03) !! Séance 11 (4/04) !! Séance 12 (11/04) !! Séance 13 (18/04)
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|Quentin Boëns / Henri Carlier
|E304
|E304/305
|E304
|E304
|E304
|C201
|C201
|C201/E304
|E304/Fab
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|Ji Yang
|E306
|E303
| Pas de salle 
|E301
|E306
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexis Viscogliosi / Abass Ayoub
|C008
|C008
|E304 Alexis Viscogliosi Absent excusé pour entretien stage
|C008
|C008
|C201
|C201
|C201
|C201
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Paul Ribeiro / Mehanna Naïf
|E303
|E301
|A204 Absents 
|E301
|E301 puis B309 puis B207
|E301
|E301
|C201 puis E304
|C201 et E304
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Antoine Gosse
| E306
| E306
| E306
| E306
| E306
| E306
| E306
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Maëva Delaporte / Simon Blas
| E304 
| E304 
| E304 
| E301 
| E301 
| E301 
| E301 
| C201/E304 
| E301 
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Baptiste Cartier
| E306
| E301
| E306
| E301
| E301
| E301
| E306
| E304
| E306
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Amine El Messaoudi / Simon Feutrier
| E301
| E301
| C201
| C201
| B207
| C201
| C201
| C201
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Jade Dupont
|E304
|E304
|E304
|E304
|E304
|Absence Maladie
|E304
|E304
|E304
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Thomas Cunin / Thibault Cattelain
| E304
| B306/E304
| Pas de salle (E304 - A305)
| E301
| E301
| E301
| E301
| E304
| E304/C200
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Rémi Mairesse / Gustave Roux
| E304
| E301
| Pas de salle 
| E304
| E304
| E304 / C201
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Oumaima Naanaa
|E302
|E304
|E304
|E304
|E304
|E304
|E304
|E304
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Lirui Zhang / Lihe Zhang
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| C201
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Lijie Yao / Keren Qiang
| E303
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Maxime Creteur / Gao Fan
|E303
|E301
|A204 Absents 
|E303
|B309 puis B207
|E301
|E301
|E304
|E301
|E301
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Amaury Knockaert / Fabrice Taingland
| E304
| E304
| E304/E302
| C203/E306
| E306/E304
| Forum stages euratech/E304
| E304
| E306
| E306
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Matthieu Delobelle
| E306
| E306
| E303 - C201
| E306 - C201
| E304
| E306
| E306
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Benjamin Canu / Ganix Etcheguibel
| E306
| E306
| E306
| E306
| E306
| Forum Euratech jusque 17h E306
| E306
| E306
| E306
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Taky Djeraba / Thomas Hubert
| E306
| E306
| Pas de salle 
| E306
| E306
| E306
| E306
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Jean-Baptiste Watine / Antoine Untereiner
| E306/C201
| E301
| Pas de salle (C201) 
| C205
| C205/E301
| C205/E301
| E301
| C205
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Transley Gracias / Camille Saad
| E306
| E306
| E305
| E306
| E306
| E306
| E306
| E306/C202
| E306
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Xavier Chenot / Rodolphe Toin
| E306
| E306
| E306
| E306
| E306
| E306
| E306 puis C201
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Antoine Duquenoy / Anthony Durot
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Eloi Zalczer / Justine Senellart
|E302/E306
|E302/E306
|E304/E302
|E304/E302
|E306/E302
|Hors Polytech/E302
|E302/E304
|E302/E304
|E304/E302
|
|-
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Damien Narbais / Zoé Briois
| E306
| E301
| Pas de salle (E301)
| E304 + 17h réunion C00X
| C205
| E304 + 17h réunion C00X
| A317
| E304
| E30X
| C205
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Hugo Delbroucq / Nicolas Havard
| E301
| INRIA
| Pas de salle (INRIA)
| E301
| E301 puis E304
| E301
| E301
| E304
| E301
| INRIA
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Claire Vandamme / Alexandra Villa
|C008
|C008
|Hors Polytech/B106 Pas de salle Absentes 
|C008
|C008
|Bureau de Mr Pekpe/E306
|C008
|C008
|C008(Claire : jusque 16h, RDV médical)
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Florian Le Foll
| E301
| E301
| (Pas de salle) E303
|E303
|E303
|C201
|C201
|C201
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Carval Amaury/ Prud'Homme Geoffrey
| fabricarium
| fabricarium puis Hors Polytech
| E304
| E301
| Carval E306 - Preud'homme E301
| E301
| Carval C20X - Preud'homme Fabricarium
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Erwan Dufresne
| E302/E306
| E301
| E304
| E301
| E302
| E306
| E302
| E302/Fabricarium
| E302/Fabricarium
| Fabricarium/E304
|
|-
| PP1 [[IMA4 2017/2018 PP1|Robot hexapode pour escalier]]
| Eduardo Gomez
| C201
| C201
| C201
| Fabricarium
| Fabricarium
| C201
| C201/Fabricarium
| C201/Fabricarium
| C201/Fabricarium
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|}

Discussion:Projets IMA4 SC & SA 2017/2018

2018-03-28T13:05:21Z

Zbriois : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Analyse du projet || Retour sur l'analyse || Matériel || Mi-parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Présentation sans supports, bonne analyse de la concurrence. Par contre le scénario d'usage est à revoir en précisant l'usage pour le particulier.
| Le scénario est précisé mais aucune réponse aux questions difficiles "gestion des températures et procédure d'entretien".
| Rien.
| Si le contenu du Wiki reflète la quantité de travail fourni, c'est inquiétant.
|
|
|
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Présentation focalisée sur les réseaux de neurones. Exercice mal compris (pas d'introduction du contexte, pas de scénario d'usage).
| Toujours pas d'analyse de la concurrence, ni de scénario d'usage. Pas de réponse aux questions difficiles "quel est le matériel ? quel est le protocole ? quelles sont les entrées du réseau de neurones ?".
| Une liste mais il manque des références vers les fournisseurs agréés (voir page de l'an dernier).
| Illustrez votre Wiki avec des schémas ou des photos de votre montage. Décrivez mieux votre plateforme de test et les résultats obtenus. Essayez de corriger les problèmes de français.
|
|
|
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Exercice correctement réalisé.
| Pas de réponse aux questions difficiles "Architecture de la source d'énergie (nombre de chemins d'énergie ?)".
| Rien.
| Vous devriez avoir quelques éléments sur la réalisation. Complétez votre Wiki.
|
|
|
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Présentation focalisée sur la création du site Web. Effort fait pour rédiger un scénario d'usage.
| Réponses aux questions mais l'analyse de la consommation est imprécise. 
| Du matériel listé dans la page Wiki mais à reporter en bas de la page des projets de cette année avec des références valides.
| Un effort de documentation mais illustrez par des schémas, des pages de l'application et des tests.
|
|
|
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Exercice correctement réalisé. Scénario d'usage à préciser sur la partie réseau de capteurs.
| Scénario d'usage non précisé. Pas de réponse à la question difficile.
| Du matériel listé mais sans référence, êtes-vous sur que le matériel n'a pas besoin d'être acheté ?
| Très bonne description de l'avancé du projet. N'hésitez pas à solliciter votre encadrant direct en cas de blocage !
|
|
|
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Pas de support. Exercice très bien réalisé.
| Pas de réponse aux questions difficiles "quelle alimentation ? comment faire pour différencier les briques ? comment les briques vont-elles communiquer ? quelle sécurité vis-à-vis des enfants ?"
| Pas de liste de matériel.
| Très bonne description de l'avancé du projet. Faites un effort de formatage du texte (par exemple en utilisant des sous-titres plutôt que de souligner des lignes).
|
|
|
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Rien à signaler (juste une confusion entre le MSP430 et le CC430).
| Questions difficiles évacuées. 
| Du matériel listé mais sans référence.
| Une bonne description de l'avancé du projet.
|
|
|
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Un peu rapide, exercice réalisé. 
| Pas d'analyse de la concurrence. Peu d'effort de rédaction. Des coquilles. Une réponse rapide à la question difficile.
| Du matériel listé mais pas forcément exhaustif et sans référence valide.
| Très bonne description de l'avancé du projet. Wiki agréable à lire.
|
|
|
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Doublant
| Doublant
| Page Wiki vide, pas de liste de matériel.
| Une bonne description de l'avancé du projet. Essayez de mieux formater votre texte pour une meilleure facilité de lecture.
|
|
|
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Présentation acceptable mais avec des supports non soignés. Pas d'analyse de la concurrence, pas de scénario d'usage.
| L'analyse de la concurrence et le scénario d'usage ont été ajoutés. Par contre pas de réponse aux questions difficiles "quelle sera l'autonomie de la balle et quel sera le système de rechargement ?".
| Pas de liste de matériel.
| Rien sur l'avancé du projet au 18/02/2018. Wiki mis à jour en catastrophe le 19/02/2018. Peu d'informations, seul le routage d'une carte semble avoir été entrepris.
|
|
|
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Présentation acceptable mais avec des supports non soignés. Trouver des concurrents indirects. Une histoire mais pas de scénario d'usage.
| Page Wiki modifiée après la présentation. Une réponse incomplète à la question difficile. Trop de coquilles pour ce niveau d'études.
| Pas de liste de matériel.
| Bonne description du travail. Cinq séances pour faire chauffer une résistance, n'est-ce pas trop ?
|
|
|
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Doublant
| Doublant
| Aucune modification de la page Wiki depuis début octobre.
| Une bonne description de l'avancé du projet. Projet encore dans la phase de prototypage. Comment vous comptez recevoir une carte SIM ?
|
|
|
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Supports très textuels, pas de scénario d'usage mais une rédaction sur l'intérêt psychologique, pas vraiment de partie "concurrents".
| Un effort pour trouver des "concurrents", pas de réponses aux questions difficiles "combien de LEDs ? quelle alimentation pour quelle autonomie".
| Pas de liste de matériel.
| Le travail est a peu près décrit mais la page Wiki ressemble a un brouillon.
|
|
|
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Bonne présentation orale. Utilisation du bluetooth peu convainquant. Pas de scénario d'usage. Un "concurrent" trouvé.
| Concept de scénario d'usage non compris. Une réponse à la question difficile très rapide et non convaincante.
| Une liste de matériel dans la page Wiki mais à insérer dans le tableau en bas de la page principale. Pas de référence (voir sur la page de l'an passé).
| Le travail avec le prototype pilote de LEDs est très bien décrit et de façon agréable à lire. Par contre le schéma du futur circuit est très mal engagé. Il faut commencer par faire un schéma plus précis du collier.
|
|
|
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Support assez corrects, sujet non entièrement compris, scénario d'usage minimal.
| Un problème dans le scénario d'usage : les conteneurs doivent être lancés sur un serveur. Une réponse acceptable à la question difficile.
| Pas de matériel particulier.
| Rien sur l'avancé du projet. Aucun travail ?
|
|
|
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Analyse très correcte.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Compte-rendu du travail très lapidaire et parfois illisible à cause des coquilles. Le Wiki ne donne pas l'impression que le projet avance.
|
|
|
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Présentation trop impécise, pas vraiment de scénario d'usage. Par contre des concurrents ont été présentés.
| Un scénario d'usage éloigné de la future utilisation. Trop de coquilles dans ce scénario. Réponse à la question difficile.
| Une liste du matériel mais pas dans la page principale. Pas de référence (voir page de l'an passé).
| Compte-rendu non à jour au 18/02/2018 alors que la feuille d'heures est à jour. Le Wiki manque d'illustration, par exemple donnez le schéma du circuit. Des informations sur la carte en gestation.
|
|
|
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Analyse très correcte. Un concurrent assez peu en rapport avec les essaims de robots mais dans la ligne des dispositifs de déminage.
| Pas de question difficile.
| Liste du matériel. Préciser pour le chassis.
| Impossible de connaître l'avancé du projet à la lecture du Wiki. N'êtes-vous pas entrain de vous perdre dans vos problèmes avec FreeRTOS ?
|
|
|
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Objectif mal expliqué. Exercice réalisé.
| Mieux définir l'objectif suite à la visite en entreprise. Pas de réponse à la question difficile.
| Aucune liste de matériel.
| Bonne description du travail. Votre Wiki manque d'illustrations sur un sujet qui le permet.
|
|
|
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Excellente présentation et excellent travail préparatoire, Scénario d'usage à préciser, trouver des concurrents.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Attention quand vous dites qu'un ATMega328p n'a pas assez de sorties pour commander 8 oscillateurs, il dispose tout de même de plus de 20 E/S.
|
|
|
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Exercice réussi. Cependant précisez les acteurs dans le scénario d'usage.
| Pas de modification du scénario. Pas de réponse à la question difficile.
| Rien à redire sur la liste de matériel.
| Description du travail correct, des illustrations. Essayez de formater avec la syntaxe Wiki.
|
|
|
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Analyse très correcte.
| Réponses aux questions difficiles.
| Aucune liste de matériel.
| Le travail effectué est décrit. Un nombre de coquilles non acceptable, la lecture en devient difficile. Utilisez la syntaxe de formatage du Wiki.
|
|
|
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Sujet se prêtant peu à l'exercice mais très bonne présentation. Sujet travaillé.
| Pas vraiment de question, la suggestion est noté dans la page Wiki.
| Pas de matériel à commander.
| Description du travail un peu rapide (DNS leak quesako ?). Rédaction en cours au moment de la lecture du Wiki.Effort de rédaction entre le 18/02/2018 et le 19/02/2018. Il manque des sections mais le travail effectué devient lisible.
|
|
|
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Analyse très correcte.
| Pas de réponse aux questions difficiles "Comment démarrer l'imprimante à distance ? Comment sera calibrée la plaque d’impression ?
Comment la plaque va se fixer sur le sol ? 
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Il est possible de mettre une copie d'écran de l'application de plus. Pas la peine de vous tirer dans les pattes.
|
|
|
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Le projet ne semble pas encore avoir été sérieusement étudié.
| Net effort de documentation de la page Wiki. Pas de réponse directe à la question difficile sur la Kinect mais une discussion sur le problème posé.
| Aucune liste de matériel.
| Très bonne description du travail. Des illustrations mais il pourrait y avoir des photos du système robotino / kinect.
|
|
|
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Contexte mal présenté, sujet flou. Scénario d'usage à préciser. Pas de contact avec les encadrants avant la présentation.
| Page de Wiki vide.
| Aucune liste de matériel.
| Compte-rendu rapide du travail. Ce compte-rendu est inquiétant. Il ne semble y avoir aucun résultat depuis le début du projet. Un module a été abandonné sans que le module en question n'ait été décrit ou que la raison de l'abandon ait été précisé. Attention votre projet est en voie d'échec.
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Doublant
| Page de Wiki assez vide.
| Aucune liste de matériel.
| Le robot centaure est en plus mauvais état maintenant qu'au début du projet. Vous semblez avoir une nouvelle fois abandonné votre projet. Des ajouts mineurs au Wiki le 19/02/2018.
|
|
|
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Présentation très correcte.
| Pas de réponse à la question difficile. Page Wiki un peu vide.
| Pas de matériel à commander.
| Un Wiki incomplet alors que la feuille d'heures est actualisée. Vous semblez toujours bloqués sur les problèmes d'étalonnage !
|
|
|
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Doublant
| Wiki avec quelques informations sur le travail accompli depuis fin novembre : étude sur modbus et labview. Quelques coquilles.
| Aucune liste de matériel.
| Très peu d'illustrations. Texte mal formaté et avec des coquilles intolérable à ce niveau d'étude. Le compte-rendu donne l'impression d'une méthode de travail très brouillonne.
|
|
|
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Présentation sans support. Trouver des concurrents indirects. Pas de scénario d'usage.
| Page Wiki vide.
| Aucune liste de matériel.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Analyse très correcte.
| Page Wiki bien tenue. Ajoutez des illustrations.
| Quelques éléments sur le matériel dans la page Wiki mais aucune liste avec références.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Presque à jour. Vous n'aviez pas des cartes à faire fabriquer à l'extérieur ?
|
|
|
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Exercice bien réalisé.
| Page Wiki très complète. Ajoutez des illustrations.
| Une liste probablement pas exhaustive.
|Exceptionnel ! Très illustré, bien rédigé, le travail de recherche est très bien décrit. Je ne suis pas un fan de la mise en gras d'un quart du texte et la syntaxe Wiki n'est pas vraiment utilisée mais c'est du détail?
|
|
|
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Doublant
| Page Wiki vide.
| Pas de matériel à commander.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Erasmus
|
|
| Projet en échec constaté.
|
|
|
|-
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (17/01) !! Séance 2 (24/01) !! Séance 3 (31/01) !! Séance 4 (7/02) !! Séance 5 (14/02) !! Séance 6 (21/02) !! Séance 7 (7/03) !! Séance 8 (14/03) !! Séance 9 (21/03) !! Séance 10 (28/03) !! Séance 11 (4/04) !! Séance 12 (11/04) !! Séance 13 (18/04)
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|Quentin Boëns / Henri Carlier
|E304
|E304/305
|E304
|E304
|E304
|C201
|C201
|C201/E304
|E304/Fab
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|Ji Yang
|E306
|E303
| Pas de salle 
|E301
|E306
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexis Viscogliosi / Abass Ayoub
|C008
|C008
|E304 Alexis Viscogliosi Absent excusé pour entretien stage
|C008
|C008
|C201
|C201
|C201
|C201
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Paul Ribeiro / Mehanna Naïf
|E303
|E301
|A204 Absents 
|E301
|E301 puis B309 puis B207
|E301
|E301
|C201 puis E304
|C201 et E304
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Antoine Gosse
| E306
| E306
| E306
| E306
| E306
| E306
| E306
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Maëva Delaporte / Simon Blas
| E304 
| E304 
| E304 
| E301 
| E301 
| E301 
| E301 
| C201/E304 
| E301 
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Baptiste Cartier
| E306
| E301
| E306
| E301
| E301
| E301
| E306
| E304
| E306
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Amine El Messaoudi / Simon Feutrier
| E301
| E301
| C201
| C201
| B207
| C201
| C201
| C201
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Jade Dupont
|E304
|E304
|E304
|E304
|E304
|Absence Maladie
|E304
|E304
|E304
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Thomas Cunin / Thibault Cattelain
| E304
| B306/E304
| Pas de salle (E304 - A305)
| E301
| E301
| E301
| E301
| E304
| E304/C200
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Rémi Mairesse / Gustave Roux
| E304
| E301
| Pas de salle 
| E304
| E304
| E304 / C201
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Oumaima Naanaa
|E302
|E304
|E304
|E304
|E304
|E304
|E304
|E304
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Lirui Zhang / Lihe Zhang
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| C201
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Lijie Yao / Keren Qiang
| E303
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Maxime Creteur / Gao Fan
|E303
|E301
|A204 Absents 
|E303
|B309 puis B207
|E301
|E301
|E304
|E301
|E301
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Amaury Knockaert / Fabrice Taingland
| E304
| E304
| E304/E302
| C203/E306
| E306/E304
| Forum stages euratech/E304
| E304
| E306
| E306
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Matthieu Delobelle
| E306
| E306
| E303 - C201
| E306 - C201
| E304
| E306
| E306
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Benjamin Canu / Ganix Etcheguibel
| E306
| E306
| E306
| E306
| E306
| Forum Euratech jusque 17h E306
| E306
| E306
| E306
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Taky Djeraba / Thomas Hubert
| E306
| E306
| Pas de salle 
| E306
| E306
| E306
| E306
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Jean-Baptiste Watine / Antoine Untereiner
| E306/C201
| E301
| Pas de salle (C201) 
| C205
| C205/E301
| C205/E301
| E301
| C205
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Transley Gracias / Camille Saad
| E306
| E306
| E305
| E306
| E306
| E306
| E306
| E306/C202
| E306
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Xavier Chenot / Rodolphe Toin
| E306
| E306
| E306
| E306
| E306
| E306
| E306 puis C201
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Antoine Duquenoy / Anthony Durot
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Eloi Zalczer / Justine Senellart
|E302/E306
|E302/E306
|E304/E302
|E304/E302
|E306/E302
|Hors Polytech/E302
|E302/E304
|E302/E304
|E304/E302
|
|-
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Damien Narbais / Zoé Briois
| E306
| E301
| Pas de salle (E301)
| E304 + 17h réunion C00X
| C205
| E304 + 17h réunion C00X
| A317
| E304
| C205
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Hugo Delbroucq / Nicolas Havard
| E301
| INRIA
| Pas de salle (INRIA)
| E301
| E301 puis E304
| E301
| E301
| E304
| E301
| INRIA
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Claire Vandamme / Alexandra Villa
|C008
|C008
|Hors Polytech/B106 Pas de salle Absentes 
|C008
|C008
|Bureau de Mr Pekpe/E306
|C008
|C008
|C008(Claire : jusque 16h, RDV médical)
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Florian Le Foll
| E301
| E301
| (Pas de salle) E303
|E303
|E303
|C201
|C201
|C201
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Carval Amaury/ Prud'Homme Geoffrey
| fabricarium
| fabricarium puis Hors Polytech
| E304
| E301
| Carval E306 - Preud'homme E301
| E301
| Carval C20X - Preud'homme Fabricarium
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Erwan Dufresne
| E302/E306
| E301
| E304
| E301
| E302
| E306
| E302
| E302/Fabricarium
| E302/Fabricarium
| Fabricarium/E304
|
|-
| PP1 [[IMA4 2017/2018 PP1|Robot hexapode pour escalier]]
| Eduardo Gomez
| C201
| C201
| C201
| Fabricarium
| Fabricarium
| C201
| C201/Fabricarium
| C201/Fabricarium
| C201/Fabricarium
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|}

IMA4 2017/2018 P44

2018-03-25T21:57:51Z

Zbriois : /* Mars : Séance 3 - 21/03/18 */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
| 3
|
| 3
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
| 3
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
| 9
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
| 7
| 11
| 12
|
| 40
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
:- avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
:- cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiquée par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

=Documents Rendus=

IMA4 2017/2018 P44

2018-03-25T21:56:03Z

Zbriois : /* Février : Séance 1 - 07/02/18 */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
| 3
|
| 3
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
| 3
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
| 9
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
| 7
| 11
| 12
|
| 40
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), ou un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là il y aura des risques liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
:- avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
:- cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiqué par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

=Documents Rendus=

IMA4 2017/2018 P44

2018-03-25T21:34:22Z

Zbriois : /* Mars : Séance 3 - 21/03/18 */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
| 3
|
| 3
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
| 3
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
| 9
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
| 7
| 11
| 12
|
| 40
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), d'un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là risquent liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
:- avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
:- cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

* On arrive maintenant à obtenir une connexion valide avec la caméra depuis ROS grâce à la commande "roslaunch realsense_camera sr300_nodelet_rgbd.launch" communiqué par nos tuteurs et non "roslaunch realsense_ros_camera rs_camera.launch" que nous avions trouvée sur les tutoriels ROS.

=Documents Rendus=

IMA4 2017/2018 P44

2018-03-25T21:32:57Z

Zbriois : /* Mars : Séance 2 - 14/03/18 */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
| 3
|
| 3
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
| 3
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
| 9
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
| 7
| 11
| 12
|
| 40
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), d'un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là risquent liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
:- avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
:- cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît, on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch) alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

==Mars : Séance 3 - 21/03/18==

Avec la librairie TensorFlow, nous avons un algorithme qui catégorise l'image envoyée en entrée avec une certaine fiabilité.

Pour cela, il faut lui donner une banque d'images pour pouvoir reconnaitre nos MPS.

Pour le moment nous n'avons que 4 MPS modélisées en 3D. Grace à un logiciel, nous avons pris 20 captures d'écran pour chaque MPS. Ce n'est pas beaucoup mais nous avons déjà de bons résultats. Cela est du au programme qui prend des images aléatoires que nous lui avons donné et qui les modifie lors de son entrainement(luminosité, recadrage, rotation de l'image ...).

*Voici quelques tests effectués :
**ligne du haut : Image envoyée à l'algorithme
**ligne du bas : |Résultat après l'exécution (plus la valeur est proche de 1, plus la réponse est fiable)

{|
|-
|
[[File:Base_newCapture_qqonq.png|400 px]]

Image quelconque du modèle 3D MPS base
|
[[File:Base_morceau.png|400 px]]

Partie quelconque du modèle 3D de la MPS base

|
[[File:Base reel3.jpg|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition
|
[[File:base_reel_crop.png|400 px]]

Image réel d'une MPS base, prise d'une caméra, lors d'une ancienne compétition, recadrée
|-
|
[[File:Result_base_newCapture_qqonq.png|400 px]]

Le type de la MPS (base) a bien été reconnu.
|
[[File:Result_base_morceau.png|400 px]]

Le type de la MPS n'a pas été reconnu.
|
[[File:Result_base_reel1.png|400 px]]

Le type de la MPS (base) n'a pas été reconnu et s'est même trompé de machine alors que la fiabilité est à 1.
|
[[File:Result_base_reel_crop.png|400 px]]

Recadré, le type de la MPS (base) a bien été reconnu, avec une fiabilité élevée.
|}

De ces tests, nous pouvons voir la nécéssité de recadrer l'image. C'est pour cela que nous utilisons ls capteur de distance de la caméra.

Pour encore améliorer les résultats, nous prendrons des photos des MPS sur place car les modèles 3D non aucun cablage et les photos seront prises directement avec la caméra.

=Documents Rendus=

Discussion:Projets IMA4 SC & SA 2017/2018

2018-03-21T13:55:14Z

Zbriois : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Analyse du projet || Retour sur l'analyse || Matériel || Mi-parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Présentation sans supports, bonne analyse de la concurrence. Par contre le scénario d'usage est à revoir en précisant l'usage pour le particulier.
| Le scénario est précisé mais aucune réponse aux questions difficiles "gestion des températures et procédure d'entretien".
| Rien.
| Si le contenu du Wiki reflète la quantité de travail fourni, c'est inquiétant.
|
|
|
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Présentation focalisée sur les réseaux de neurones. Exercice mal compris (pas d'introduction du contexte, pas de scénario d'usage).
| Toujours pas d'analyse de la concurrence, ni de scénario d'usage. Pas de réponse aux questions difficiles "quel est le matériel ? quel est le protocole ? quelles sont les entrées du réseau de neurones ?".
| Une liste mais il manque des références vers les fournisseurs agréés (voir page de l'an dernier).
| Illustrez votre Wiki avec des schémas ou des photos de votre montage. Décrivez mieux votre plateforme de test et les résultats obtenus. Essayez de corriger les problèmes de français.
|
|
|
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Exercice correctement réalisé.
| Pas de réponse aux questions difficiles "Architecture de la source d'énergie (nombre de chemins d'énergie ?)".
| Rien.
| Vous devriez avoir quelques éléments sur la réalisation. Complétez votre Wiki.
|
|
|
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Présentation focalisée sur la création du site Web. Effort fait pour rédiger un scénario d'usage.
| Réponses aux questions mais l'analyse de la consommation est imprécise. 
| Du matériel listé dans la page Wiki mais à reporter en bas de la page des projets de cette année avec des références valides.
| Un effort de documentation mais illustrez par des schémas, des pages de l'application et des tests.
|
|
|
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Exercice correctement réalisé. Scénario d'usage à préciser sur la partie réseau de capteurs.
| Scénario d'usage non précisé. Pas de réponse à la question difficile.
| Du matériel listé mais sans référence, êtes-vous sur que le matériel n'a pas besoin d'être acheté ?
| Très bonne description de l'avancé du projet. N'hésitez pas à solliciter votre encadrant direct en cas de blocage !
|
|
|
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Pas de support. Exercice très bien réalisé.
| Pas de réponse aux questions difficiles "quelle alimentation ? comment faire pour différencier les briques ? comment les briques vont-elles communiquer ? quelle sécurité vis-à-vis des enfants ?"
| Pas de liste de matériel.
| Très bonne description de l'avancé du projet. Faites un effort de formatage du texte (par exemple en utilisant des sous-titres plutôt que de souligner des lignes).
|
|
|
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Rien à signaler (juste une confusion entre le MSP430 et le CC430).
| Questions difficiles évacuées. 
| Du matériel listé mais sans référence.
| Une bonne description de l'avancé du projet.
|
|
|
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Un peu rapide, exercice réalisé. 
| Pas d'analyse de la concurrence. Peu d'effort de rédaction. Des coquilles. Une réponse rapide à la question difficile.
| Du matériel listé mais pas forcément exhaustif et sans référence valide.
| Très bonne description de l'avancé du projet. Wiki agréable à lire.
|
|
|
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Doublant
| Doublant
| Page Wiki vide, pas de liste de matériel.
| Une bonne description de l'avancé du projet. Essayez de mieux formater votre texte pour une meilleure facilité de lecture.
|
|
|
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Présentation acceptable mais avec des supports non soignés. Pas d'analyse de la concurrence, pas de scénario d'usage.
| L'analyse de la concurrence et le scénario d'usage ont été ajoutés. Par contre pas de réponse aux questions difficiles "quelle sera l'autonomie de la balle et quel sera le système de rechargement ?".
| Pas de liste de matériel.
| Rien sur l'avancé du projet au 18/02/2018. Wiki mis à jour en catastrophe le 19/02/2018. Peu d'informations, seul le routage d'une carte semble avoir été entrepris.
|
|
|
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Présentation acceptable mais avec des supports non soignés. Trouver des concurrents indirects. Une histoire mais pas de scénario d'usage.
| Page Wiki modifiée après la présentation. Une réponse incomplète à la question difficile. Trop de coquilles pour ce niveau d'études.
| Pas de liste de matériel.
| Bonne description du travail. Cinq séances pour faire chauffer une résistance, n'est-ce pas trop ?
|
|
|
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Doublant
| Doublant
| Aucune modification de la page Wiki depuis début octobre.
| Une bonne description de l'avancé du projet. Projet encore dans la phase de prototypage. Comment vous comptez recevoir une carte SIM ?
|
|
|
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Supports très textuels, pas de scénario d'usage mais une rédaction sur l'intérêt psychologique, pas vraiment de partie "concurrents".
| Un effort pour trouver des "concurrents", pas de réponses aux questions difficiles "combien de LEDs ? quelle alimentation pour quelle autonomie".
| Pas de liste de matériel.
| Le travail est a peu près décrit mais la page Wiki ressemble a un brouillon.
|
|
|
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Bonne présentation orale. Utilisation du bluetooth peu convainquant. Pas de scénario d'usage. Un "concurrent" trouvé.
| Concept de scénario d'usage non compris. Une réponse à la question difficile très rapide et non convaincante.
| Une liste de matériel dans la page Wiki mais à insérer dans le tableau en bas de la page principale. Pas de référence (voir sur la page de l'an passé).
| Le travail avec le prototype pilote de LEDs est très bien décrit et de façon agréable à lire. Par contre le schéma du futur circuit est très mal engagé. Il faut commencer par faire un schéma plus précis du collier.
|
|
|
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Support assez corrects, sujet non entièrement compris, scénario d'usage minimal.
| Un problème dans le scénario d'usage : les conteneurs doivent être lancés sur un serveur. Une réponse acceptable à la question difficile.
| Pas de matériel particulier.
| Rien sur l'avancé du projet. Aucun travail ?
|
|
|
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Analyse très correcte.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Compte-rendu du travail très lapidaire et parfois illisible à cause des coquilles. Le Wiki ne donne pas l'impression que le projet avance.
|
|
|
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Présentation trop impécise, pas vraiment de scénario d'usage. Par contre des concurrents ont été présentés.
| Un scénario d'usage éloigné de la future utilisation. Trop de coquilles dans ce scénario. Réponse à la question difficile.
| Une liste du matériel mais pas dans la page principale. Pas de référence (voir page de l'an passé).
| Compte-rendu non à jour au 18/02/2018 alors que la feuille d'heures est à jour. Le Wiki manque d'illustration, par exemple donnez le schéma du circuit. Des informations sur la carte en gestation.
|
|
|
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Analyse très correcte. Un concurrent assez peu en rapport avec les essaims de robots mais dans la ligne des dispositifs de déminage.
| Pas de question difficile.
| Liste du matériel. Préciser pour le chassis.
| Impossible de connaître l'avancé du projet à la lecture du Wiki. N'êtes-vous pas entrain de vous perdre dans vos problèmes avec FreeRTOS ?
|
|
|
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Objectif mal expliqué. Exercice réalisé.
| Mieux définir l'objectif suite à la visite en entreprise. Pas de réponse à la question difficile.
| Aucune liste de matériel.
| Bonne description du travail. Votre Wiki manque d'illustrations sur un sujet qui le permet.
|
|
|
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Excellente présentation et excellent travail préparatoire, Scénario d'usage à préciser, trouver des concurrents.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Attention quand vous dites qu'un ATMega328p n'a pas assez de sorties pour commander 8 oscillateurs, il dispose tout de même de plus de 20 E/S.
|
|
|
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Exercice réussi. Cependant précisez les acteurs dans le scénario d'usage.
| Pas de modification du scénario. Pas de réponse à la question difficile.
| Rien à redire sur la liste de matériel.
| Description du travail correct, des illustrations. Essayez de formater avec la syntaxe Wiki.
|
|
|
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Analyse très correcte.
| Réponses aux questions difficiles.
| Aucune liste de matériel.
| Le travail effectué est décrit. Un nombre de coquilles non acceptable, la lecture en devient difficile. Utilisez la syntaxe de formatage du Wiki.
|
|
|
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Sujet se prêtant peu à l'exercice mais très bonne présentation. Sujet travaillé.
| Pas vraiment de question, la suggestion est noté dans la page Wiki.
| Pas de matériel à commander.
| Description du travail un peu rapide (DNS leak quesako ?). Rédaction en cours au moment de la lecture du Wiki.Effort de rédaction entre le 18/02/2018 et le 19/02/2018. Il manque des sections mais le travail effectué devient lisible.
|
|
|
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Analyse très correcte.
| Pas de réponse aux questions difficiles "Comment démarrer l'imprimante à distance ? Comment sera calibrée la plaque d’impression ?
Comment la plaque va se fixer sur le sol ? 
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Il est possible de mettre une copie d'écran de l'application de plus. Pas la peine de vous tirer dans les pattes.
|
|
|
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Le projet ne semble pas encore avoir été sérieusement étudié.
| Net effort de documentation de la page Wiki. Pas de réponse directe à la question difficile sur la Kinect mais une discussion sur le problème posé.
| Aucune liste de matériel.
| Très bonne description du travail. Des illustrations mais il pourrait y avoir des photos du système robotino / kinect.
|
|
|
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Contexte mal présenté, sujet flou. Scénario d'usage à préciser. Pas de contact avec les encadrants avant la présentation.
| Page de Wiki vide.
| Aucune liste de matériel.
| Compte-rendu rapide du travail. Ce compte-rendu est inquiétant. Il ne semble y avoir aucun résultat depuis le début du projet. Un module a été abandonné sans que le module en question n'ait été décrit ou que la raison de l'abandon ait été précisé. Attention votre projet est en voie d'échec.
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Doublant
| Page de Wiki assez vide.
| Aucune liste de matériel.
| Le robot centaure est en plus mauvais état maintenant qu'au début du projet. Vous semblez avoir une nouvelle fois abandonné votre projet. Des ajouts mineurs au Wiki le 19/02/2018.
|
|
|
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Présentation très correcte.
| Pas de réponse à la question difficile. Page Wiki un peu vide.
| Pas de matériel à commander.
| Un Wiki incomplet alors que la feuille d'heures est actualisée. Vous semblez toujours bloqués sur les problèmes d'étalonnage !
|
|
|
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Doublant
| Wiki avec quelques informations sur le travail accompli depuis fin novembre : étude sur modbus et labview. Quelques coquilles.
| Aucune liste de matériel.
| Très peu d'illustrations. Texte mal formaté et avec des coquilles intolérable à ce niveau d'étude. Le compte-rendu donne l'impression d'une méthode de travail très brouillonne.
|
|
|
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Présentation sans support. Trouver des concurrents indirects. Pas de scénario d'usage.
| Page Wiki vide.
| Aucune liste de matériel.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Analyse très correcte.
| Page Wiki bien tenue. Ajoutez des illustrations.
| Quelques éléments sur le matériel dans la page Wiki mais aucune liste avec références.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Presque à jour. Vous n'aviez pas des cartes à faire fabriquer à l'extérieur ?
|
|
|
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Exercice bien réalisé.
| Page Wiki très complète. Ajoutez des illustrations.
| Une liste probablement pas exhaustive.
|Exceptionnel ! Très illustré, bien rédigé, le travail de recherche est très bien décrit. Je ne suis pas un fan de la mise en gras d'un quart du texte et la syntaxe Wiki n'est pas vraiment utilisée mais c'est du détail?
|
|
|
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Doublant
| Page Wiki vide.
| Pas de matériel à commander.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Erasmus
|
|
| Projet en échec constaté.
|
|
|
|-
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (17/01) !! Séance 2 (24/01) !! Séance 3 (31/01) !! Séance 4 (7/02) !! Séance 5 (14/02) !! Séance 6 (21/02) !! Séance 7 (7/03) !! Séance 8 (14/03) !! Séance 9 (21/03) !! Séance 10 (28/03) !! Séance 11 (4/04) !! Séance 12 (11/04) !! Séance 13 (18/04)
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|Quentin Boëns / Henri Carlier
|E304
|E304/305
|E304
|E304
|E304
|C201
|C201
|C201/E304
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|Ji Yang
|E306
|E303
| Pas de salle 
|E301
|E306
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexis Viscogliosi / Abass Ayoub
|C008
|C008
|E304 Alexis Viscogliosi Absent excusé pour entretien stage
|C008
|C008
|C201
|C201
|C201
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Paul Ribeiro / Mehanna Naïf
|E303
|E301
|A204 Absents 
|E301
|E301 puis B309 puis B207
|E301
|E301
|C201 puis E304
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Antoine Gosse
| E306
| E306
| E306
| E306
| E306
| E306
| E306
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Maëva Delaporte / Simon Blas
| E304 
| E304 
| E304 
| E301 
| E301 
| E301 
| E301 
| C201/E304 
| E301 
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Baptiste Cartier
| E306
| E301
| E306
| E301
| E301
| E301
| E306
| E304
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Amine El Messaoudi / Simon Feutrier
| E301
| E301
| C201
| C201
| B207
| C201
| C201
| C201
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Jade Dupont
|E304
|E304
|E304
|E304
|E304
|Absence Maladie
|E304
|E304
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Thomas Cunin / Thibault Cattelain
| E304
| B306/E304
| Pas de salle (E304 - A305)
| E301
| E301
| E301
| E301
| E304
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Rémi Mairesse / Gustave Roux
| E304
| E301
| Pas de salle 
| E304
| E304
| E304 / C201
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Oumaima Naanaa
|E302
|E304
|E304
|E304
|E304
|E304
|E304
|E304
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Lirui Zhang / Lihe Zhang
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| C201
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Lijie Yao / Keren Qiang
| E303
| E304
| E304
| E304
| E304
| E304
| E304
| E304
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Maxime Creteur / Gao Fan
|E303
|E301
|A204 Absents 
|E303
|B309 puis B207
|E301
|E301
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Amaury Knockaert / Fabrice Taingland
| E304
| E304
| E304/E302
| C203/E306
| E306/E304
| Forum stages euratech/E304
| E304
| E306
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Matthieu Delobelle
| E306
| E306
| E303 - C201
| E306 - C201
| E304
| E306
| E306
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Benjamin Canu / Ganix Etcheguibel
| E306
| E306
| E306
| E306
| E306
| Forum Euratech jusque 17h E306
| E306
| E306
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Taky Djeraba / Thomas Hubert
| E306
| E306
| Pas de salle 
| E306
| E306
| E306
| E306
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Jean-Baptiste Watine / Antoine Untereiner
| E306/C201
| E301
| Pas de salle (C201) 
| C205
| C205/E301
| C205/E301
| E301
| C205
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Transley Gracias / Camille Saad
| E306
| E306
| E305
| E306
| E306
| E306
| E306
| E306/C202
| E306
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Xavier Chenot / Rodolphe Toin
| E306
| E306
| E306
| E306
| E306
| E306
| E306 puis C201
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Antoine Duquenoy / Anthony Durot
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Eloi Zalczer / Justine Senellart
|E302/E306
|E302/E306
|E304/E302
|E304/E302
|E306/E302
|Hors Polytech/E302
|E302/E304
|E302/E304
|
|-
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Damien Narbais / Zoé Briois
| E306
| E301
| Pas de salle (E301)
| E304 + 17h réunion C00X
| C205
| E304 + 17h réunion C00X
| A317
| E304
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Hugo Delbroucq / Nicolas Havard
| E301
| INRIA
| Pas de salle (INRIA)
| E301
| E301 puis E304
| E301
| E301
| E304
| E301
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Claire Vandamme / Alexandra Villa
|C008
|C008
|Hors Polytech/B106 Pas de salle Absentes 
|C008
|C008
|Bureau de Mr Pekpe/E306
|C008
|C008
|C008(Claire : jusque 16h, RDV médical)
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Florian Le Foll
| E301
| E301
| (Pas de salle) E303
|E303
|E303
|C201
|C201
|C201
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Carval Amaury/ Prud'Homme Geoffrey
| fabricarium
| fabricarium puis Hors Polytech
| E304
| E301
| Carval E306 - Preud'homme E301
| E301
| Carval C20X - Preud'homme Fabricarium
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Erwan Dufresne
| E302/E306
| E301
| E304
| E301
| E302
| E306
| E302
| E302/Fabricarium
|
|-
| PP1 [[IMA4 2017/2018 PP1|Robot hexapode pour escalier]]
| Eduardo Gomez
| C201
| C201
| C201
| Fabricarium
| Fabricarium
| C201
| C201/Fabricarium
| C201/Fabricarium
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|}

IMA4 2017/2018 P44

2018-03-14T23:53:14Z

Zbriois : /* Mars : Séance 2 - 14/03/18 */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
|
|
| 3
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
|
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
|
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
|
|
|
|
|
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), d'un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là risquent liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
:- avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
:- cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît
:- on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch)
:- alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

=Documents Rendus=

IMA4 2017/2018 P44

2018-03-14T23:22:46Z

Zbriois : /* Mars : Séance 2 - 14/03/18 */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
|
|
| 3
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
|
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
|
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
|
|
|
|
|
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), d'un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là risquent liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
**avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|600px|center]]
*cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît
*on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch)
*alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

=Documents Rendus=

IMA4 2017/2018 P44

2018-03-14T23:22:25Z

Zbriois : /* Réalisation du Projet */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
|
|
| 3
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
|
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
|
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
|
|
|
|
|
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), d'un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là risquent liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

==Mars : Séance 2 - 14/03/18==

*Installation de tout les paquets nécessaires (grâce au tutoriel https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#installing-the-packages)
*Connexion avec la caméra établie
**avec le realsense-viewer on arrive bien a récupérer les informations de la caméra:
[[Fichier:capture1.jpeg|300px|center]]
*cependant sur le terminal l'erreur "Failed to read busnum/devnum." apparaît
*on obtient la même erreur lorsque l'on essaye de lancer le noeud ROS directement en ligne de commande (roslaunch realsense_ros_camera rs_camera.launch)
*alors que pourtant la caméra est bien reconnue:
[[Fichier:capture2.jpeg|600px|center]]

=Documents Rendus=

Fichier:Capture2.jpeg

2018-03-14T23:19:09Z

Zbriois :

Fichier:Capture1.jpeg

2018-03-14T23:18:32Z

Zbriois :

IMA4 2017/2018 P44

2018-03-14T14:58:04Z

Zbriois : /* Février : Séance 3 - 21/02/18 */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
|
|
| 3
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
|
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
|
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
|
|
|
|
|
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), d'un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là risquent liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS:
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (donc inclinaison) (limité à 1m10)
::::test concluant avec la caméra placée 30cm au dessus du plateau du Robotino, vers l'arrière) et distance Robotino-MPS=40cm mais d'autres placements sont possibles, en jouant sur l'inclinaison notamment.
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

=Documents Rendus=

IMA4 2017/2018 P44

2018-03-14T14:21:17Z

Zbriois : /* Mars : Séance 1 - 07/03/18 */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
|
|
| 3
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
|
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
|
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
|
|
|
|
|
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Canny (mais le résultat dépend de la qualité de l'image donc à tester), d'un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là risquent liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

*Compte Rendu de la réunion avec les tuteurs
::-Positionnement de la caméra à définir
::::prise de mesures pour la placer, et voir toute la face de la MPS
::::redressement de l'image à réaliser si on place la caméra trop en hauteur (limité à 1m10)
::-Récupération de la carte
::::USB déjà configuré dans le BIOS
::::RAM de 4Go avec plusieurs coeurs --> penser aux threads
::-Récupération d'image possible grâce à des vidéos sur youtube (https://www.youtube.com/channel/UCB5ieBWgXVeg2ih_JMHiDrg)
::-Définir ce qui est clairement identifiable, qu’est ce qui est identique sur toutes les machines (peut être ensuite utilisé pour redresser l'image)
::-On va utiliser ROS pour :
::::-faciliter la communication entre le robotino et la carte
::::-récupérer les informations de la caméra (IF et image couleur) dans un même fichier

==Mars : Séance 1 - 07/03/18==

*Utilisation de blender pour visualiser les fichiers wrl et trouver des similitudes entre les MPS
*Début code pour classifier les images en utilisant TensorFlow
*Installation de ROS
*Découverte des tutoriels d'utilisation de ROS

=Documents Rendus=

Discussion:Projets IMA4 SC & SA 2017/2018

2018-03-14T14:03:44Z

Zbriois : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Analyse du projet || Retour sur l'analyse || Matériel || Mi-parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Présentation sans supports, bonne analyse de la concurrence. Par contre le scénario d'usage est à revoir en précisant l'usage pour le particulier.
| Le scénario est précisé mais aucune réponse aux questions difficiles "gestion des températures et procédure d'entretien".
| Rien.
| Si le contenu du Wiki reflète la quantité de travail fourni, c'est inquiétant.
|
|
|
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Présentation focalisée sur les réseaux de neurones. Exercice mal compris (pas d'introduction du contexte, pas de scénario d'usage).
| Toujours pas d'analyse de la concurrence, ni de scénario d'usage. Pas de réponse aux questions difficiles "quel est le matériel ? quel est le protocole ? quelles sont les entrées du réseau de neurones ?".
| Une liste mais il manque des références vers les fournisseurs agréés (voir page de l'an dernier).
| Illustrez votre Wiki avec des schémas ou des photos de votre montage. Décrivez mieux votre plateforme de test et les résultats obtenus. Essayez de corriger les problèmes de français.
|
|
|
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Exercice correctement réalisé.
| Pas de réponse aux questions difficiles "Architecture de la source d'énergie (nombre de chemins d'énergie ?)".
| Rien.
| Vous devriez avoir quelques éléments sur la réalisation. Complétez votre Wiki.
|
|
|
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Présentation focalisée sur la création du site Web. Effort fait pour rédiger un scénario d'usage.
| Réponses aux questions mais l'analyse de la consommation est imprécise. 
| Du matériel listé dans la page Wiki mais à reporter en bas de la page des projets de cette année avec des références valides.
| Un effort de documentation mais illustrez par des schémas, des pages de l'application et des tests.
|
|
|
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Exercice correctement réalisé. Scénario d'usage à préciser sur la partie réseau de capteurs.
| Scénario d'usage non précisé. Pas de réponse à la question difficile.
| Du matériel listé mais sans référence, êtes-vous sur que le matériel n'a pas besoin d'être acheté ?
| Très bonne description de l'avancé du projet. N'hésitez pas à solliciter votre encadrant direct en cas de blocage !
|
|
|
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Pas de support. Exercice très bien réalisé.
| Pas de réponse aux questions difficiles "quelle alimentation ? comment faire pour différencier les briques ? comment les briques vont-elles communiquer ? quelle sécurité vis-à-vis des enfants ?"
| Pas de liste de matériel.
| Très bonne description de l'avancé du projet. Faites un effort de formatage du texte (par exemple en utilisant des sous-titres plutôt que de souligner des lignes).
|
|
|
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Rien à signaler (juste une confusion entre le MSP430 et le CC430).
| Questions difficiles évacuées. 
| Du matériel listé mais sans référence.
| Une bonne description de l'avancé du projet.
|
|
|
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Un peu rapide, exercice réalisé. 
| Pas d'analyse de la concurrence. Peu d'effort de rédaction. Des coquilles. Une réponse rapide à la question difficile.
| Du matériel listé mais pas forcément exhaustif et sans référence valide.
| Très bonne description de l'avancé du projet. Wiki agréable à lire.
|
|
|
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Doublant
| Doublant
| Page Wiki vide, pas de liste de matériel.
| Une bonne description de l'avancé du projet. Essayez de mieux formater votre texte pour une meilleure facilité de lecture.
|
|
|
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Présentation acceptable mais avec des supports non soignés. Pas d'analyse de la concurrence, pas de scénario d'usage.
| L'analyse de la concurrence et le scénario d'usage ont été ajoutés. Par contre pas de réponse aux questions difficiles "quelle sera l'autonomie de la balle et quel sera le système de rechargement ?".
| Pas de liste de matériel.
| Rien sur l'avancé du projet au 18/02/2018. Wiki mis à jour en catastrophe le 19/02/2018. Peu d'informations, seul le routage d'une carte semble avoir été entrepris.
|
|
|
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Présentation acceptable mais avec des supports non soignés. Trouver des concurrents indirects. Une histoire mais pas de scénario d'usage.
| Page Wiki modifiée après la présentation. Une réponse incomplète à la question difficile. Trop de coquilles pour ce niveau d'études.
| Pas de liste de matériel.
| Bonne description du travail. Cinq séances pour faire chauffer une résistance, n'est-ce pas trop ?
|
|
|
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Doublant
| Doublant
| Aucune modification de la page Wiki depuis début octobre.
| Une bonne description de l'avancé du projet. Projet encore dans la phase de prototypage. Comment vous comptez recevoir une carte SIM ?
|
|
|
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Supports très textuels, pas de scénario d'usage mais une rédaction sur l'intérêt psychologique, pas vraiment de partie "concurrents".
| Un effort pour trouver des "concurrents", pas de réponses aux questions difficiles "combien de LEDs ? quelle alimentation pour quelle autonomie".
| Pas de liste de matériel.
| Le travail est a peu près décrit mais la page Wiki ressemble a un brouillon.
|
|
|
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Bonne présentation orale. Utilisation du bluetooth peu convainquant. Pas de scénario d'usage. Un "concurrent" trouvé.
| Concept de scénario d'usage non compris. Une réponse à la question difficile très rapide et non convaincante.
| Une liste de matériel dans la page Wiki mais à insérer dans le tableau en bas de la page principale. Pas de référence (voir sur la page de l'an passé).
| Le travail avec le prototype pilote de LEDs est très bien décrit et de façon agréable à lire. Par contre le schéma du futur circuit est très mal engagé. Il faut commencer par faire un schéma plus précis du collier.
|
|
|
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Support assez corrects, sujet non entièrement compris, scénario d'usage minimal.
| Un problème dans le scénario d'usage : les conteneurs doivent être lancés sur un serveur. Une réponse acceptable à la question difficile.
| Pas de matériel particulier.
| Rien sur l'avancé du projet. Aucun travail ?
|
|
|
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Analyse très correcte.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Compte-rendu du travail très lapidaire et parfois illisible à cause des coquilles. Le Wiki ne donne pas l'impression que le projet avance.
|
|
|
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Présentation trop impécise, pas vraiment de scénario d'usage. Par contre des concurrents ont été présentés.
| Un scénario d'usage éloigné de la future utilisation. Trop de coquilles dans ce scénario. Réponse à la question difficile.
| Une liste du matériel mais pas dans la page principale. Pas de référence (voir page de l'an passé).
| Compte-rendu non à jour au 18/02/2018 alors que la feuille d'heures est à jour. Le Wiki manque d'illustration, par exemple donnez le schéma du circuit. Des informations sur la carte en gestation.
|
|
|
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Analyse très correcte. Un concurrent assez peu en rapport avec les essaims de robots mais dans la ligne des dispositifs de déminage.
| Pas de question difficile.
| Liste du matériel. Préciser pour le chassis.
| Impossible de connaître l'avancé du projet à la lecture du Wiki. N'êtes-vous pas entrain de vous perdre dans vos problèmes avec FreeRTOS ?
|
|
|
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Objectif mal expliqué. Exercice réalisé.
| Mieux définir l'objectif suite à la visite en entreprise. Pas de réponse à la question difficile.
| Aucune liste de matériel.
| Bonne description du travail. Votre Wiki manque d'illustrations sur un sujet qui le permet.
|
|
|
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Excellente présentation et excellent travail préparatoire, Scénario d'usage à préciser, trouver des concurrents.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Attention quand vous dites qu'un ATMega328p n'a pas assez de sorties pour commander 8 oscillateurs, il dispose tout de même de plus de 20 E/S.
|
|
|
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Exercice réussi. Cependant précisez les acteurs dans le scénario d'usage.
| Pas de modification du scénario. Pas de réponse à la question difficile.
| Rien à redire sur la liste de matériel.
| Description du travail correct, des illustrations. Essayez de formater avec la syntaxe Wiki.
|
|
|
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Analyse très correcte.
| Réponses aux questions difficiles.
| Aucune liste de matériel.
| Le travail effectué est décrit. Un nombre de coquilles non acceptable, la lecture en devient difficile. Utilisez la syntaxe de formatage du Wiki.
|
|
|
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Sujet se prêtant peu à l'exercice mais très bonne présentation. Sujet travaillé.
| Pas vraiment de question, la suggestion est noté dans la page Wiki.
| Pas de matériel à commander.
| Description du travail un peu rapide (DNS leak quesako ?). Rédaction en cours au moment de la lecture du Wiki.Effort de rédaction entre le 18/02/2018 et le 19/02/2018. Il manque des sections mais le travail effectué devient lisible.
|
|
|
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Analyse très correcte.
| Pas de réponse aux questions difficiles "Comment démarrer l'imprimante à distance ? Comment sera calibrée la plaque d’impression ?
Comment la plaque va se fixer sur le sol ? 
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Il est possible de mettre une copie d'écran de l'application de plus. Pas la peine de vous tirer dans les pattes.
|
|
|
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Le projet ne semble pas encore avoir été sérieusement étudié.
| Net effort de documentation de la page Wiki. Pas de réponse directe à la question difficile sur la Kinect mais une discussion sur le problème posé.
| Aucune liste de matériel.
| Très bonne description du travail. Des illustrations mais il pourrait y avoir des photos du système robotino / kinect.
|
|
|
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Contexte mal présenté, sujet flou. Scénario d'usage à préciser. Pas de contact avec les encadrants avant la présentation.
| Page de Wiki vide.
| Aucune liste de matériel.
| Compte-rendu rapide du travail. Ce compte-rendu est inquiétant. Il ne semble y avoir aucun résultat depuis le début du projet. Un module a été abandonné sans que le module en question n'ait été décrit ou que la raison de l'abandon ait été précisé. Attention votre projet est en voie d'échec.
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Doublant
| Page de Wiki assez vide.
| Aucune liste de matériel.
| Le robot centaure est en plus mauvais état maintenant qu'au début du projet. Vous semblez avoir une nouvelle fois abandonné votre projet. Des ajouts mineurs au Wiki le 19/02/2018.
|
|
|
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Présentation très correcte.
| Pas de réponse à la question difficile. Page Wiki un peu vide.
| Pas de matériel à commander.
| Un Wiki incomplet alors que la feuille d'heures est actualisée. Vous semblez toujours bloqués sur les problèmes d'étalonnage !
|
|
|
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Doublant
| Wiki avec quelques informations sur le travail accompli depuis fin novembre : étude sur modbus et labview. Quelques coquilles.
| Aucune liste de matériel.
| Très peu d'illustrations. Texte mal formaté et avec des coquilles intolérable à ce niveau d'étude. Le compte-rendu donne l'impression d'une méthode de travail très brouillonne.
|
|
|
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Présentation sans support. Trouver des concurrents indirects. Pas de scénario d'usage.
| Page Wiki vide.
| Aucune liste de matériel.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Analyse très correcte.
| Page Wiki bien tenue. Ajoutez des illustrations.
| Quelques éléments sur le matériel dans la page Wiki mais aucune liste avec références.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Presque à jour. Vous n'aviez pas des cartes à faire fabriquer à l'extérieur ?
|
|
|
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Exercice bien réalisé.
| Page Wiki très complète. Ajoutez des illustrations.
| Une liste probablement pas exhaustive.
|Exceptionnel ! Très illustré, bien rédigé, le travail de recherche est très bien décrit. Je ne suis pas un fan de la mise en gras d'un quart du texte et la syntaxe Wiki n'est pas vraiment utilisée mais c'est du détail?
|
|
|
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Doublant
| Page Wiki vide.
| Pas de matériel à commander.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Erasmus
|
|
| Projet en échec constaté.
|
|
|
|-
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (17/01) !! Séance 2 (24/01) !! Séance 3 (31/01) !! Séance 4 (7/02) !! Séance 5 (14/02) !! Séance 6 (21/02) !! Séance 7 (7/03) !! Séance 8 (14/03) !! Séance 9 (21/03) !! Séance 10 (28/03) !! Séance 11 (4/04) !! Séance 12 (11/04) !! Séance 13 (18/04)
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|Quentin Boëns / Henri Carlier
|E304
|E304/305
|E304
|E304
|E304
|C201
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|Ji Yang
|E306
|E303
| Pas de salle 
|E301
|E306
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexis Viscogliosi / Abass Ayoub
|C008
|C008
|E304 Alexis Viscogliosi Absent excusé pour entretien stage
|C008
|C008
|C201
|C201
|C201
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Paul Ribeiro / Mehanna Naïf
|E303
|E301
|A204 Absents 
|E301
|E301 puis B309 puis B207
|E301
|E301
|C201
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Antoine Gosse
| E306
| E306
| E306
| E306
| E306
| E306
| E306
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Maëva Delaporte / Simon Blas
| E304 
| E304 
| E304 
| E301 
| E301 
| E301 
| E301 
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Baptiste Cartier
| E306
| E301
| E306
| E301
| E301
| E301
| E306
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Amine El Messaoudi / Simon Feutrier
| E301
| E301
| C201
| C201
| B207
| C201
| C201
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Jade Dupont
|E304
|E304
|E304
|E304
|E304
|Absence Maladie
|E304
|E304
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Thomas Cunin / Thibault Cattelain
| E304
| B306/E304
| Pas de salle (E304 - A305)
| E301
| E301
| E301
| E301
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Rémi Mairesse / Gustave Roux
| E304
| E301
| Pas de salle 
| E304
| E304
| E304 / C201
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Oumaima Naanaa
|E302
|E304
|E304
|E304
|E304
|E304
|E304
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Lirui Zhang / Lihe Zhang
| E304
| E304
| E304
| E304
| E304
| E304
| E304
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Lijie Yao / Keren Qiang
| E303
| E304
| E304
| E304
| E304
| E304
| E304
| E304
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Maxime Creteur / Gao Fan
|E303
|E301
|A204 Absents 
|E303
|B309 puis B207
|E301
|E301
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Amaury Knockaert / Fabrice Taingland
| E304
| E304
| E304/E302
| C203/E306
| E306/E304
| Forum stages euratech/E304
| E304

|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Matthieu Delobelle
| E306
| E306
| E303 - C201
| E306 - C201
| E304
| E306
| E306
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Benjamin Canu / Ganix Etcheguibel
| E306
| E306
| E306
| E306
| E306
| Forum Euratech jusque 17h E306
| E306
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Taky Djeraba / Thomas Hubert
| E306
| E306
| Pas de salle 
| E306
| E306
| E306
| E306
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Jean-Baptiste Watine / Antoine Untereiner
| E306/C201
| E301
| Pas de salle (C201) 
| C205
| C205/E301
| C205/E301
| E301
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Transley Gracias / Camille Saad
| E306
| E306
| E305
| E306
| E306
| E306
| E306
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Xavier Chenot / Rodolphe Toin
| E306
| E306
| E306
| E306
| E306
| E306
| E306 puis C201
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Antoine Duquenoy / Anthony Durot
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Eloi Zalczer / Justine Senellart
|E302/E306
|E302/E306
|E304/E302
|E304/E302
|E306/E302
|Hors Polytech/E302
|E302/E304
|E302
|
|-
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Damien Narbais / Zoé Briois
| E306
| E301
| Pas de salle (E301)
| E304 + 17h réunion C00X
| C205
| E304 + 17h réunion C00X
| A317
| E304
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Hugo Delbroucq / Nicolas Havard
| E301
| INRIA
| Pas de salle (INRIA)
| E301
| E301 puis E304
| E301
| E301
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Claire Vandamme / Alexandra Villa
|C008
|C008
|Hors Polytech/B106 Pas de salle Absentes 
|C008
|C008
|Bureau de Mr Pekpe/E306
|C008
|C008
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Florian Le Foll
| E301
| E301
| (Pas de salle) E303
|E303
|E303
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Carval Amaury/ Prud'Homme Geoffrey
| fabricarium
| fabricarium puis Hors Polytech
| E304
| E301
| Carval E306 - Preud'homme E301
| E301
| Carval C20X - Preud'homme Fabricarium
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Erwan Dufresne
| E302/E306
| E301
| E304
| E301
| E302
| E306
| E302
| Fabricarium
|-
| PP1 [[IMA4 2017/2018 PP1|Robot hexapode pour escalier]]
| Eduardo Gomez
| C201
| C201
| C201
| Fabricarium
| Fabricarium
| C201
| C201/Fabricarium
| C201/Fabricarium
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|}

Discussion:Projets IMA4 SC & SA 2017/2018

2018-03-07T13:58:44Z

Zbriois : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Analyse du projet || Retour sur l'analyse || Matériel || Mi-parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Présentation sans supports, bonne analyse de la concurrence. Par contre le scénario d'usage est à revoir en précisant l'usage pour le particulier.
| Le scénario est précisé mais aucune réponse aux questions difficiles "gestion des températures et procédure d'entretien".
| Rien.
| Si le contenu du Wiki reflète la quantité de travail fourni, c'est inquiétant.
|
|
|
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Présentation focalisée sur les réseaux de neurones. Exercice mal compris (pas d'introduction du contexte, pas de scénario d'usage).
| Toujours pas d'analyse de la concurrence, ni de scénario d'usage. Pas de réponse aux questions difficiles "quel est le matériel ? quel est le protocole ? quelles sont les entrées du réseau de neurones ?".
| Une liste mais il manque des références vers les fournisseurs agréés (voir page de l'an dernier).
| Illustrez votre Wiki avec des schémas ou des photos de votre montage. Décrivez mieux votre plateforme de test et les résultats obtenus. Essayez de corriger les problèmes de français.
|
|
|
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Exercice correctement réalisé.
| Pas de réponse aux questions difficiles "Architecture de la source d'énergie (nombre de chemins d'énergie ?)".
| Rien.
| Vous devriez avoir quelques éléments sur la réalisation. Complétez votre Wiki.
|
|
|
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Présentation focalisée sur la création du site Web. Effort fait pour rédiger un scénario d'usage.
| Réponses aux questions mais l'analyse de la consommation est imprécise. 
| Du matériel listé dans la page Wiki mais à reporter en bas de la page des projets de cette année avec des références valides.
| Un effort de documentation mais illustrez par des schémas, des pages de l'application et des tests.
|
|
|
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Exercice correctement réalisé. Scénario d'usage à préciser sur la partie réseau de capteurs.
| Scénario d'usage non précisé. Pas de réponse à la question difficile.
| Du matériel listé mais sans référence, êtes-vous sur que le matériel n'a pas besoin d'être acheté ?
| Très bonne description de l'avancé du projet. N'hésitez pas à solliciter votre encadrant direct en cas de blocage !
|
|
|
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Pas de support. Exercice très bien réalisé.
| Pas de réponse aux questions difficiles "quelle alimentation ? comment faire pour différencier les briques ? comment les briques vont-elles communiquer ? quelle sécurité vis-à-vis des enfants ?"
| Pas de liste de matériel.
| Très bonne description de l'avancé du projet. Faites un effort de formatage du texte (par exemple en utilisant des sous-titres plutôt que de souligner des lignes).
|
|
|
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Rien à signaler (juste une confusion entre le MSP430 et le CC430).
| Questions difficiles évacuées. 
| Du matériel listé mais sans référence.
| Une bonne description de l'avancé du projet.
|
|
|
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Un peu rapide, exercice réalisé. 
| Pas d'analyse de la concurrence. Peu d'effort de rédaction. Des coquilles. Une réponse rapide à la question difficile.
| Du matériel listé mais pas forcément exhaustif et sans référence valide.
| Très bonne description de l'avancé du projet. Wiki agréable à lire.
|
|
|
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Doublant
| Doublant
| Page Wiki vide, pas de liste de matériel.
| Une bonne description de l'avancé du projet. Essayez de mieux formater votre texte pour une meilleure facilité de lecture.
|
|
|
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Présentation acceptable mais avec des supports non soignés. Pas d'analyse de la concurrence, pas de scénario d'usage.
| L'analyse de la concurrence et le scénario d'usage ont été ajoutés. Par contre pas de réponse aux questions difficiles "quelle sera l'autonomie de la balle et quel sera le système de rechargement ?".
| Pas de liste de matériel.
| Rien sur l'avancé du projet au 18/02/2018. Wiki mis à jour en catastrophe le 19/02/2018. Peu d'informations, seul le routage d'une carte semble avoir été entrepris.
|
|
|
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Présentation acceptable mais avec des supports non soignés. Trouver des concurrents indirects. Une histoire mais pas de scénario d'usage.
| Page Wiki modifiée après la présentation. Une réponse incomplète à la question difficile. Trop de coquilles pour ce niveau d'études.
| Pas de liste de matériel.
| Bonne description du travail. Cinq séances pour faire chauffer une résistance, n'est-ce pas trop ?
|
|
|
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Doublant
| Doublant
| Aucune modification de la page Wiki depuis début octobre.
| Une bonne description de l'avancé du projet. Projet encore dans la phase de prototypage. Comment vous comptez recevoir une carte SIM ?
|
|
|
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Supports très textuels, pas de scénario d'usage mais une rédaction sur l'intérêt psychologique, pas vraiment de partie "concurrents".
| Un effort pour trouver des "concurrents", pas de réponses aux questions difficiles "combien de LEDs ? quelle alimentation pour quelle autonomie".
| Pas de liste de matériel.
| Le travail est a peu près décrit mais la page Wiki ressemble a un brouillon.
|
|
|
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Bonne présentation orale. Utilisation du bluetooth peu convainquant. Pas de scénario d'usage. Un "concurrent" trouvé.
| Concept de scénario d'usage non compris. Une réponse à la question difficile très rapide et non convaincante.
| Une liste de matériel dans la page Wiki mais à insérer dans le tableau en bas de la page principale. Pas de référence (voir sur la page de l'an passé).
| Le travail avec le prototype pilote de LEDs est très bien décrit et de façon agréable à lire. Par contre le schéma du futur circuit est très mal engagé. Il faut commencer par faire un schéma plus précis du collier.
|
|
|
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Support assez corrects, sujet non entièrement compris, scénario d'usage minimal.
| Un problème dans le scénario d'usage : les conteneurs doivent être lancés sur un serveur. Une réponse acceptable à la question difficile.
| Pas de matériel particulier.
| Rien sur l'avancé du projet. Aucun travail ?
|
|
|
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Analyse très correcte.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Compte-rendu du travail très lapidaire et parfois illisible à cause des coquilles. Le Wiki ne donne pas l'impression que le projet avance.
|
|
|
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Présentation trop impécise, pas vraiment de scénario d'usage. Par contre des concurrents ont été présentés.
| Un scénario d'usage éloigné de la future utilisation. Trop de coquilles dans ce scénario. Réponse à la question difficile.
| Une liste du matériel mais pas dans la page principale. Pas de référence (voir page de l'an passé).
| Compte-rendu non à jour au 18/02/2018 alors que la feuille d'heures est à jour. Le Wiki manque d'illustration, par exemple donnez le schéma du circuit. Des informations sur la carte en gestation.
|
|
|
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Analyse très correcte. Un concurrent assez peu en rapport avec les essaims de robots mais dans la ligne des dispositifs de déminage.
| Pas de question difficile.
| Liste du matériel. Préciser pour le chassis.
| Impossible de connaître l'avancé du projet à la lecture du Wiki. N'êtes-vous pas entrain de vous perdre dans vos problèmes avec FreeRTOS ?
|
|
|
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Objectif mal expliqué. Exercice réalisé.
| Mieux définir l'objectif suite à la visite en entreprise. Pas de réponse à la question difficile.
| Aucune liste de matériel.
| Bonne description du travail. Votre Wiki manque d'illustrations sur un sujet qui le permet.
|
|
|
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Excellente présentation et excellent travail préparatoire, Scénario d'usage à préciser, trouver des concurrents.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Attention quand vous dites qu'un ATMega328p n'a pas assez de sorties pour commander 8 oscillateurs, il dispose tout de même de plus de 20 E/S.
|
|
|
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Exercice réussi. Cependant précisez les acteurs dans le scénario d'usage.
| Pas de modification du scénario. Pas de réponse à la question difficile.
| Rien à redire sur la liste de matériel.
| Description du travail correct, des illustrations. Essayez de formater avec la syntaxe Wiki.
|
|
|
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Analyse très correcte.
| Réponses aux questions difficiles.
| Aucune liste de matériel.
| Le travail effectué est décrit. Un nombre de coquilles non acceptable, la lecture en devient difficile. Utilisez la syntaxe de formatage du Wiki.
|
|
|
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Sujet se prêtant peu à l'exercice mais très bonne présentation. Sujet travaillé.
| Pas vraiment de question, la suggestion est noté dans la page Wiki.
| Pas de matériel à commander.
| Description du travail un peu rapide (DNS leak quesako ?). Rédaction en cours au moment de la lecture du Wiki.Effort de rédaction entre le 18/02/2018 et le 19/02/2018. Il manque des sections mais le travail effectué devient lisible.
|
|
|
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Analyse très correcte.
| Pas de réponse aux questions difficiles "Comment démarrer l'imprimante à distance ? Comment sera calibrée la plaque d’impression ?
Comment la plaque va se fixer sur le sol ? 
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Il est possible de mettre une copie d'écran de l'application de plus. Pas la peine de vous tirer dans les pattes.
|
|
|
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Le projet ne semble pas encore avoir été sérieusement étudié.
| Net effort de documentation de la page Wiki. Pas de réponse directe à la question difficile sur la Kinect mais une discussion sur le problème posé.
| Aucune liste de matériel.
| Très bonne description du travail. Des illustrations mais il pourrait y avoir des photos du système robotino / kinect.
|
|
|
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Contexte mal présenté, sujet flou. Scénario d'usage à préciser. Pas de contact avec les encadrants avant la présentation.
| Page de Wiki vide.
| Aucune liste de matériel.
| Compte-rendu rapide du travail. Ce compte-rendu est inquiétant. Il ne semble y avoir aucun résultat depuis le début du projet. Un module a été abandonné sans que le module en question n'ait été décrit ou que la raison de l'abandon ait été précisé. Attention votre projet est en voie d'échec.
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Doublant
| Page de Wiki assez vide.
| Aucune liste de matériel.
| Le robot centaure est en plus mauvais état maintenant qu'au début du projet. Vous semblez avoir une nouvelle fois abandonné votre projet. Des ajouts mineurs au Wiki le 19/02/2018.
|
|
|
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Présentation très correcte.
| Pas de réponse à la question difficile. Page Wiki un peu vide.
| Pas de matériel à commander.
| Un Wiki incomplet alors que la feuille d'heures est actualisée. Vous semblez toujours bloqués sur les problèmes d'étalonnage !
|
|
|
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Doublant
| Wiki avec quelques informations sur le travail accompli depuis fin novembre : étude sur modbus et labview. Quelques coquilles.
| Aucune liste de matériel.
| Très peu d'illustrations. Texte mal formaté et avec des coquilles intolérable à ce niveau d'étude. Le compte-rendu donne l'impression d'une méthode de travail très brouillonne.
|
|
|
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Présentation sans support. Trouver des concurrents indirects. Pas de scénario d'usage.
| Page Wiki vide.
| Aucune liste de matériel.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Analyse très correcte.
| Page Wiki bien tenue. Ajoutez des illustrations.
| Quelques éléments sur le matériel dans la page Wiki mais aucune liste avec références.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Presque à jour. Vous n'aviez pas des cartes à faire fabriquer à l'extérieur ?
|
|
|
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Exercice bien réalisé.
| Page Wiki très complète. Ajoutez des illustrations.
| Une liste probablement pas exhaustive.
|Exceptionnel ! Très illustré, bien rédigé, le travail de recherche est très bien décrit. Je ne suis pas un fan de la mise en gras d'un quart du texte et la syntaxe Wiki n'est pas vraiment utilisée mais c'est du détail?
|
|
|
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Doublant
| Page Wiki vide.
| Pas de matériel à commander.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Erasmus
|
|
| Projet en échec constaté.
|
|
|
|-
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (17/01) !! Séance 2 (24/01) !! Séance 3 (31/01) !! Séance 4 (7/02) !! Séance 5 (14/02) !! Séance 6 (21/02) !! Séance 7 (7/03) !! Séance 8 (14/03) !! Séance 9 (21/03) !! Séance 10 (28/03) !! Séance 11 (4/04) !! Séance 12 (11/04) !! Séance 13 (18/04)
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|Quentin Boëns / Henri Carlier
|E304
|E304/305
|E304
|E304
|E304
|C201
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|Ji Yang
|E306
|E303
| Pas de salle 
|E301
|E306
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexis Viscogliosi / Abass Ayoub
|C008
|C008
|E304 Alexis Viscogliosi Absent excusé pour entretien stage
|C008
|C008
|C201
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Paul Ribeiro / Mehanna Naïf
|E303
|E301
|A204 Absents 
|E301
|E301 puis B309 puis B207
|E301
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Antoine Gosse
| E306
| E306
| E306
| E306
| E306
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Maëva Delaporte / Simon Blas
| E304 
| E304 
| E304 
| E301 
| E301 
| E301 
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Baptiste Cartier
| E306
| E301
| E306
| E301
| E301
| E301
| E301
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Amine El Messaoudi / Simon Feutrier
| E301
| E301
| C201
| C201
| B207
| C201
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Jade Dupont
|E304
|E304
|E304
|E304
|E304
|Absence Maladie
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Thomas Cunin / Thibault Cattelain
| E304
| B306/E304
| Pas de salle (E304 - A305)
| E301
| E301
| E301
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Rémi Mairesse / Gustave Roux
| E304
| E301
| Pas de salle 
| E304
| E304
| E304 / C201
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Oumaima Naanaa
|E302
|E304
|E304
|E304
|E304
|E304
|E304
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Lirui Zhang / Lihe Zhang
| E304
| E304
| E304
| E304
| E304

|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Lijie Yao / Keren Qiang
| E303
| E304
| E304
| E304
| E304
| E304
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Maxime Creteur / Gao Fan
|E303
|E301
|A204 Absents 
|E303
|B309 puis B207
|E301
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Amaury Knockaert / Fabrice Taingland
| E304
| E304
| E304/E302
| C203/E306
| E306/E304
| Forum stages euratech/E304

|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Matthieu Delobelle
| E306
| E306
| E303 - C201
| E306 - C201
| E304
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Benjamin Canu / Ganix Etcheguibel
| E306
| E306
| E306
| E306
| E306
| E306 Forum Euratech jusque 17h
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Taky Djeraba / Thomas Hubert
| E306
| E306
| Pas de salle 
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Jean-Baptiste Watine / Antoine Untereiner
| E306/C201
| E301
| Pas de salle (C201) 
| C205
| C205/E301
| C205/E301
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Transley Gracias / Camille Saad
| E306
| E306
| E305
| E306
| E306
| E306
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Xavier Chenot / Rodolphe Toin
| E306
| E306
| E306
| E306
| E306
| E306
| E306
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Antoine Duquenoy / Anthony Durot
| E306
| E306
| E306
| E306
| E306
| E306
| E306
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Eloi Zalczer / Justine Senellart
|E302/E306
|E302/E306
|E304/E302
|E304/E302
|E306/E302
|Hors Polytech/E302
|E302
|-
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Damien Narbais / Zoé Briois
| E306
| E301
| Pas de salle (E301)
| E304 + 17h réunion C00X
| C205
| E304 + 17h réunion C00X
| A317
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Hugo Delbroucq / Nicolas Havard
| E301
| INRIA
| Pas de salle (INRIA)
| E301
| E301 puis E304
| E301
| E301
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Claire Vandamme / Alexandra Villa
|C008
|C008
|Hors Polytech/B106 Pas de salle Absentes 
|C008
|C008
|Bureau de Mr Pekpe/E306
|C008
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Florian Le Foll
| E301
| E301
| (Pas de salle) E303
|E303
|E303
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Carval Amaury/ Prud'Homme Geoffrey
| fabricarium
| fabricarium puis Hors Polytech
| E304
| E301
| Carval E306 - Preud'homme E301
| E301
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Erwan Dufresne
| E302/E306
| E301
| E304
| E301
| E302
| E306
| E302
|-
| PP1 [[IMA4 2017/2018 PP1|Robot hexapode pour escalier]]
| Eduardo Gomez
| C201
| C201
| C201
| Fabricarium
| Fabricarium
| C201
| C201/Fabricarium
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|}

IMA4 2017/2018 P44

2018-02-21T17:06:57Z

Zbriois : /* Février : Séance 2 - 14/02/18 */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
|
|
| 3
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
|
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
|
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
|
|
|
|
|
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Cznny (mais le résultat dépend de la qualité de l'image donc à tester), d'un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là risquent liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

=Documents Rendus=

IMA4 2017/2018 P44

2018-02-21T16:45:33Z

Zbriois : /* Feuille d'heures Février */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
|
|
| 3
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
|
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
|
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
|
|
|
|
|
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Cznny (mais le résultat dépend de la qualité de l'image donc à tester), d'un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là risquent liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,
::à la reconnaissance de la caméra par un OS linux.

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

=Documents Rendus=

IMA4 2017/2018 P44

2018-02-21T16:45:13Z

Zbriois : /* Feuille d'heures Février */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
|
| 3
|
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
|
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
|
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
|
|
|
|
|
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Cznny (mais le résultat dépend de la qualité de l'image donc à tester), d'un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là risquent liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,
::à la reconnaissance de la caméra par un OS linux.

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

=Documents Rendus=

IMA4 2017/2018 P44

2018-02-21T16:44:27Z

Zbriois : /* Feuille d'heures Février */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
| 3
|
|
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
|
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
| 4
| 8
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
|
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
|
|
|
|
|
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Cznny (mais le résultat dépend de la qualité de l'image donc à tester), d'un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là risquent liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,
::à la reconnaissance de la caméra par un OS linux.

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

=Documents Rendus=

IMA4 2017/2018 P44

2018-02-21T16:38:32Z

Zbriois : /* Février : Séance 3 - 21/02/18 */

__TOC__
 

=Présentation générale=

==Description==

L’Association de Robotique de Polytech Lille a pour but principal de participer à la RoboCup, compétition internationale de robotique, dans la Logistic League. Pour l'instant une '''machine de production''' (MPS) est identifiée par un AR Tag (QR Code). Le but de ce projet est de réussir à identifier une machine par une autre façon, sans utiliser les tags, mais en identifiant les structures de production qui sont positionnées sur chaque MPS. Il y en a 5 types:
* une Base Station à 3 tours de stockage pour chaque couleur de base ;
* une Cap Station à un rail de dépôt pour l’ajout de bases ;
* une Delivery Station à 3 voies de stockages pour les produits finis ;
* une Ring Station à 2 structures pneumatiques de dépose de cap ;
* une Storage Station à 1 structure en étagère assez haute.
[[Fichier:Base_station.jpg]][[Fichier:Cap_station.jpg]][[Fichier:Delivery_station.jpg]][[Fichier:Ring_station.jpg]][[Fichier:Storage_station.jpg]]

Chaque machine à 2 types de côté: actif, large où le robot interagit ou ignorés, étroit où il n'y aura pas d’interaction.

On a la liberté du '''choix du moyen de vision''': une ou deux caméras (stéréo vision), une Kinect, un scanner laser, une Intel SR300 ... mais il faudra veiller à choisir un système efficace et robuste.

Ce sujet permettra d'aborder les notions de développement logiciel en C et Python, du framework robotique ROS, mais également le travail en équipe et pourquoi pas la participation à une compétition internationale de robotique en avril (Open German à Magdebourg, Allemagne).

==Objectifs==
L'objectif principal de notre projet est donc d'analyser '''le plus rapidement possible''' et avec une '''fiabilité maximale''' face à quelle machine de production le robot se situe. Il faudra donc trouver une caractéristique unique pour chaque machine de production afin de les différencier le plus rapidement possible. Et si ce n'est pas possible (si 2 machines sont trop semblables) pouvoir comparer l'image vue par le robot avec les caractéristiques visuelles générales de chaque MPS.
Ainsi la storage station est facilement identifiable par sa taille mais les autres MPS semblent relativement semblables aux premiers abords. Une analyse en détail de leurs dimensions va nous permettre d'évaluer s'il serait possible de les différencier facilement. Par exemple la cap station pourrait être identifiée par son rail. On pourrait également s'appuyer sur les différences de profondeur de certaines zones des MPS pour les différencier, grâce au capteur infra rouge notamment .

Lors de la compétition 3 minutes maximum sont allouées à la phase d'exploration.

Il s'agira de reconnaissance spécifique: identifier une MPS en particulier sur une image.

=Analyse du projet=

==Positionnement par rapport à l'existant==
Il y a de nombreux projets et de plus en plus de projets sur la reconnaissance d’objets par traitement d’image, notamment dans la recherche. Ces projets sont le plus souvent axés sur un axe industriel , comme pour ce projet. Ou sur une utilisation dans la vie quotidienne: robot humanoïdes, reconnaissances d’objets de formes basiques (cubes …) comme dans certaines compétitions de robotique.
Comme ce sera le cas pour nous, grand nombre de ces projets ne fonctionnent que dans des conditions particulières: un nombre d’objets limité et un environnement connu. En effet il est très difficile de programmer un robot pour qu’il puisse reconnaître tous les objets existants.
Une difficulté importante pour la reconnaissance d’objets sont les variations: de luminosité, de taille de l’objet, de son orientation …
De nombreuses applications de détection d’objets sont développées sur l'OS ROS.

==Analyse du premier concurrent==
L’API CLOUD VISION de Google permet de comprendre le contenu d'une image en intégrant de puissants modèles de machine learning dans une API facile à utiliser. Cloud Vision classe les images rapidement dans des milliers de catégories (par exemple, "bateau", "lion", "tour Eiffel").
L’avantage de la solution présentée par notre projet et de pouvoir reconnaître les objets plus précisément, en effet il ne s’agit pas de savoir que c’est juste une MPS comme pourrait le faire cette API mais de préciser de quelle MPS il s’agit.
L’avantage de CLOUD VISION est qu’il peut concerner un domaine plus large et est plus applicable à différentes compétitions. En effet l'API Vision s'appuie sur la puissance de la fonctionnalité de recherche de Google Images pour trouver des entités thématiques, elle permet donc par exemple de reconnaître des logos.

==Analyse du second concurrent==
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4029636/
Ce projet s’appuie sur une '''Kinect''' comme nous pouvons envisager de le faire. La Kinect est ici utilisée pour reconnaître les contours de l’objet.
Le projet réalisé par Carlos Astua, Ramon Barber, Jonathan Crespo, et Alberto Jardon décrit dans cet article met en avant la '''difficulté à reconnaître un objet en fonction de la position''' du robot.

==Scénario d'usage du produit ou du concept envisagé==
Après des semaines d'intense préparation le Robotino de l'association de robotique de Polytech Lille est prêt à entrer en piste pour l'épreuve de Logistique de la Robocup 2018. Il s'agit d'une compétition en 1 contre 1 où l'objectif est de marquer le plus de points en un temps imparti.
Sa première mission et celle qui fait référence à notre projet est la phase d'exploration: il va devoir analyser les 14 machines de production présentes sur la piste (emplacement et orientation aléatoire) pour définir leur type. Chaque équipe est associée à 7 MPS.
Le robotino va donc se déplacer face à chaque MPS et l'analyser par le traitement d'image pour repérer de quelle type de machine il s'agit. Pour repérer ces machines et leur position il a un temps imparti de 3 minutes.

==Réponse à la question difficile==
'''Comment communiquer avec la Caméra?''' 
Il nous faut un moyen de communication qui nous permette d'une part de récupérer ce que voie la caméra, de pouvoir le traiter et de pouvoir comparer ces informations avec ce que nous savons sur les MPS.
Le plus difficile est de trouver comment traiter les informations récupérée via la caméra. Cela sera rendu possible par l'utilisation d'une RaspberryPi alimentée par le robotino.

=Préparation du projet=

==Cahier des charges==
L'objectif est de permettre au Robotino de différencier 5 machines de production connues d'avance dans le cadre d'un challenge de robotique. Les caractéristiques principales de l'environnement sont également connues d'avance.
Pour cela nous possédons les modélisations en 3D des MPS au format WRL (juste ici https://github.com/robocup-logistics/full-size-models/tree/master/mps). L'objectif est donc de pouvoir sur place la MPS située face au robot avec les informations que nous connaissons sur les 5 types de MPS, au moyen d'une kinect vraisemblablement.

 
L'objectif final est que notre projet fonctionne de la manière suivante :
<ol type=1>
<li>Récupérer l'image vue par la caméra(profondeur)</li>
<li>Extraire les contours</li>
<li>Comparer avec les contours connus des MPS</li>
<li>Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino</li>
<li>Sinon se placer sur un autre côté de la machine puis retour étape 1.</li>
</ol>

Pour cela nous devrons:
<ol type=i>
<li>Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition</li>
<li>Extraire les contours de ces images(formes, nombre de formes, placement)</li>
<li>Si après avoir analysé les 4 faces de la MPS il n'y a aucune correspondance à plus de 70%, faire la moyenne des correspondances pour les 4 faces pour chaque MPS et choisir celle qui a le taux de correspondance le plus élevé (*)</li>
</ol>

Remarques: 
- Si une machine a déjà été reconnue autant de fois qu'elle se trouve sur le terrain (information connue préalablement) on effectuera pas de comparaison avec les images de celle-ci puisque c'est inutile (optimisation du temps) 
- Si a un moment donné, il y a le même taux de correspondance pour 2 MPS après l'analyse des 4 phases, envoi des 2 ID au Robotino. A la fin de l'analyse on pourra déduire le vrai ID puisqu'on connaît le nombre de MPS de chaque type présentes sur le terrain. 
- (*) Sauf si le taux de correspondance est inférieur à 40% on envoie "on ne sait pas".

==Choix techniques : matériel et logiciel==
Pour le choix du moyen de prise d'image:
<ol type=i>
<li>la stéréo vision (utilisation de 2 caméras) nécessite l'acquisition d'au moins 2 images de l'objet à mesurer de 2 points de vues différents. Après la prise de vue de la MPS les coordonnées d'image (couple stéréoscopique) des points à mesurer sont déterminées sur chaque des images puis mises en concordance. Pour déterminer les dimensions de l'objet il est nécessaire détalonner le système de mesure.
Problématique: étant donné la taille du robot par rapport à celle des MPS, sera-t-il possible de prendre les 2 images de l'objet en laissant le robot immobile face à la MPS (en plaçant les 2 caméras à des endroits différents du robot) ? Si ce n'est pas possible il faudra donc que le robot se déplace par rapport à la MPS, ce qui rendrait le processus de reconnaissance plus long.</li>

<li>la kinect possède une caméra RGB ainsi qu'une caméra infrarouge, cette caméra infrarouge permet de mesurer les différences de profondeur.
Avantage: Avoir une image infrarouge avec les différences de profondeur des objet présents dans le visuel du robot pourrait nous être très utile pour différencier les différents MPS.
Problématique: la caméra RGB et la caméra infrarouge ne sont pas situées au même endroit sur la kinect, nous auront donc 2 prises de vues non superposables. Serait-il possible d'utiliser uniquement la caméra infrarouge ? Ou de synchroniser les 2 images ?

Kinect V1 - Champ de vision :
Champ de vision horizontal : 57 degrés 
Champ de vision vertical : 43 degrés 
Marge de déplacement du capteur : ± 27 degrés 
Portée du capteur : 1,2 m – 3,5 m </li>

Kinect V2 - Champ de vision :
Champ de vision horizontal : 70 degrés 
Champ de vision vertical : 60 degrés 
Portée du capteur : 0,5 m – 4,5 m 

<li>la caméra Intel® RealSense™, notamment la SR300, possède tout comme la Kinect une caméra couleur, une caméra infrarouge et un émetteur infrarouge.
Portée en profondeur: 0.2m à 1.5m</li></ol>

Malheureusement ces caméras nécessitent une connexion en USB 3.0, ce qui n'est pas possible avec la RaspberryPi. C'est pour cela que nous souhaitons nous tourner vers le kit de développement d'Intel contenant une caméra R200 et une carte de prototypage bénéficiant elle d'un port 3.0. Notamment car les concurrents de RaspberryPi proposant une port 3.0 le font à un prix beaucoup plus élevé.

'''Matériel :''' 
*Intel® RealSense™ Robotic Development Kit:
**Intel RealSense R200 Camera
**AAEON UP Board (Intel Atom™ Processor x5-Z8350, Intel HD Graphics, 4GB DDR3L-1600 memory, 32GB eMMC storage)
**USB 3.0 Type A Female to Micro USB Type B Male Adapter
**USB 3.0 Type B Male to Micro USB Type B Male Cable
**5V 4A Power supply
https://click.intel.com/intelr-realsensetm-robotic-development-kit-2445.html

==Liste des tâches à effectuer==
<ol type=1>
<li>Connexion de la caméra à la carte</li>
<li>Fonction pour récupérer l'image vue par la caméra</li>
<li>Fonction permettant l'extraction des contours sur cette image</li>
<li>Extraction des contours d'après les modélisations 3D à notre disposition</li>
<li>Fonction de comparaison</li>
<li>Connexion de la carte au Robotino</li>
<li>Fonction permettant l'envoi de l'id de la machine reconnue au Robotino</li>
<li>Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS</li>
</ol>

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures Janvier==

{| class="wikitable"
!Tâches Janvier !! Séance 1 !! Séance 2 !! Séance 3 !! Total
|-
| Analyse du projet
| 6
|
|
| 6
|-
| Mise en place du protocole de reconnaissance
| 1,5
| 3
|
| 4,5
|-
| Utilisation de la profondeur d'image
|
| 2
|
| 2
|-
| Solution IBM - Watson
| 0,2
|
|
| 0,2
|-
| Caméra (choix, configuration..)
| 1
| 1
| 4
| 6
|-
| Gestion des fichiers image (format, récupération, traitement ...)
| 0,2
|
| 3
| 3,2
|-
| Caractéristiques carte (alimentation..)
|
| 1
| 2
| 3
|-
| Algorithme détection lignes et bords
|
|
| 1,5
| 1,5
|-
| ''Wiki''
| 6
| 3
|
| 9
|-
| '''TOTAL'''
| 14,9
| 10
| 10,5
|'''35,4'''
|}

==Janvier: Séance 1.0==
* Prise en main su sujet / mise en place du CDCF,
* Analyse concurrentielle,
* Analyse matérielle,
* Réponse aux questions difficiles/vagues.
==Janvier: Séance 1.1 - 15/01/18==
* Nous nous orientons vers le choix de la Kinect 360, avec la possibilité de '''combiner Kinect, ROS et Raspberry'''.
* Mise en place de la méthode pour reconnaître une MPS:
:le robot se met “face” à la MPS
:si reconnaissance de la MPS avec un pourcentage de concordance correct
::communication au Robotino de l'id de la machine
:sinon analyse d'une autre face de la MPS
::on associe/compare alors les probabilités obtenues pour la 1ère face avec celles de la 2ème
::si on a toujours pas un pourcentage de concordance assez élevé
:::analyse d'une 3ème face et ainsi de suite…
:fin au bout de 4 faces repérées
* Mise à jour du wiki
* Mise en place d'un document partagé pour les comptes-rendus des séances et le planning horaire
==Janvier: Séance 1.2 - 17/01/18==
* Après réunion avec les tuteurs nous avons pu récupérer les fichiers des modélisations 3D des MPS (au format WRL)
:étant donné que toutes les MPS ont une partie basse similaire on pourra centré le traitement d'image pour la différenciation sur la partie haute.
* Amélioration du protocole de reconnaissance:
:récupération de la surface de l'objet grâce au fichier .WRL
:récupération des points infra-rouge de la caméra (mesure de profondeur)
:récupération d’une photo 2D prise avec la caméra
:on pourrait essayer de faire un programme qui passe un plan 3D en 2D →a t'on vraiment besoin de la couleur ? ou on se concentre surtout sur la forme des objets ?
:ainsi on pourrait faire une 1ere comparaison avec photo 2D (si gain de temps par rapport au 3D d'un point de vue traitement d'image)
:avec pourquoi pas du machine learning sur les pièces 2D
:si le taux de comparaison <70%
::on garde le taux de comparaison obtenu en mémoire
::on passe à la comparaison 3D (utilisation du machine learning ? Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)
::si taux de comparaison toujours <70%
:::même protocole avec une autre face
:si taux de comparaison >70%
::fin de l'algorithme de reconnaissance et envoie de l’ID de la MPS au robotino

==Janvier: Scéance 1.3 - 18/01/18==
On va se baser sur de la reconnaissance d'image 2D et non 3D comme imaginé au début.
*Solution possible, ''mais non adapté à notre problématique'', pour la reconnaissance d'image avec un outil externe:
**celui de google (https://cloud.google.com/ml-engine/)
**celui d’IBM (https://www.ibm.com/watson/services/visual-recognition/ )

----
* Comment placer la Kinect pour voir toute la partie haute de la MPS :
:champ de vision de la Kinect V1:
::champ de vision horizontal : 57°
::champ de vision vertical : 43°
::portée du capteur : 1,2 m – 3,5 m
:on a alors :
[[Fichier:Positionnement_kinect1.jpg|300px|center]]
:on en déduit :
[[Fichier:Positionnement_kinect3.jpg|350px|center]]
:avec:
::x la longueur, largeur ou hauteur de la MPS
::α le champ de vision horizontal ou vertical de la caméra
::d la distance entre le capteur et la MPS

==Janvier: Séance 2.0 - 22/01/18==
*Avancement sur le pseudo-code:
signal_robotino = variable envoyée par le robotino à la RaspberryPi, on considère qu’il envoie 1 pour indiquer qu’il est bien positionné face à la PMS et que l’analyse peut démarrer et 2 pour indiquer qu’il a bien changé de face tab = tableau 5 colonnes (une pour chaque MPS) et 2 lignes (la première correspondant à l’id de la MPS et la seconde au nombre de MPS restantes à trouver), initialisé avec le nombre de MPS présentes au départ sur le terrain pour chaque type 

main() {
while (signal_robotino==0) {
wait;
}
recuperer_image_camera();
extraction_contour();
comparaison_avec_donnees(MPS_a_analyser);
}

recuperer_image_camera() {
//récupère l’image vue par la camera sous un format permettant le traitement par notre programme
}

extraction_contour() {
//extraction des contours de l’image vue par la camera
//les mets dans un fichier MPS_a_analyser
}

comparaison_avec_donnees(fichier MPS_a_analyser) {
fichiers contenant les contours connus des MPS: MPS_1, MPS_2, MPS_3, MPS_4, MPS_5;
int id=0;
int taux_compare=0;
for (i=1, i++, i<5){
if (tab[i-1][1]>0) {
if (compare(MPS_a_analyser,MPS_i))>taux_compare){
taux_compare=compare(MPS_a_analyser,MPS_i);
id=i;
}
}
if (taux_compare>=70) {
envoi_robotino(id);
modifier_tab(id);
}
if(taux_compare<70) {
envoi_robotino(7);
// on lui indique qu’il doit changer de face
while (signal_robotino!=2) {
wait;
}
recuperer_image_kinect();
extraction_contour();
signal_robotino=1;
comparaison_avec_donnees(MPS_a_analyser);
}
envoi_robotino(int id) {
envoi variable id au robotino;
}
modifier_tableau(int id) {
for (i=1; i++; i<=5) {
if (id=tab[i]) {
tab[i]=tab[i]-1;
}
}
}
}
} 
Il faudra penser à écrire une fonction qui vérifie bien que la caméra et la carte sont bien connectées.
Il manque le tableau pour mémoriser les taux de comparaison
==Janvier: Séance 2.1 - 24/01/18==
* Mise à jour du wiki,
* Rendez-vous avec les tuteurs, suite auquel il faudrait :
:trouver la distance pour laquelle la Kinect voit toute la partie haute de la MPS (minimum 0,80m) et vérifier si la profondeur du laser correspond
::--> '''voir séance 3.1'''
:estimer si la Raspberry à une puissance de calcul suffisante
::--> '''voir séance 2.2'''
:On va communiquer avec le robotino via une connexion sans fil
:voir comment on alimente la Raspberry et la Kinect (avec le Robotino ?)
::->effectivement possibilité d'alimentation grâce au Robotino, voltages à comparer pour pouvoir adapter l'alimentation.
:nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

==Janvier: Séance 2.2 - 25/01/18==
*Recherche des caractéristiques requises pour la carte électronique.
**Objectifs
***Etre performant pour pouvoir utiliser des algorithmes de machines learning --> deep learning compatible si RAM > 128M0
***Pouvoir assurer l'alimentation de la carte
*Recherche des caractéristiques de la caméra --> portée minimale pour les mesures de distance = 0,5 m (avec la kinect)

==Janvier: Séance 3.0 - 29/01/18==
*Affinement de notre choix matériel, nous souhaitons nous orienter vers:
::Raspberry 3 (alimentation 5V, 2.5A)
::Kinect V2 (alimentation avec adaptateur fourni ou utilisation d’un hub usb avec sa propre alimentation)
*A quelle distance de la MPS faudra-t-il placer la Kinect V2 ?

::champs vision Kincet V2 : 70,6°*60°

::dimension MPS 70cm*35cm*x

::donc pour x=70cm et alpha=70,6° on a d=60cm

::donc pour x=35cm et alpha=60° on a d=35cm

Or capteur profondeur fonctionne sur [50cm ; 450cm]

Donc on place le robot a minimum 50cm donc on fait l’hypothèse qu’on se placera toujours a 60-65 cm → recadrage d’image nécessaire pour la largeur dans ce cas
::'''cf. schéma séance 1.3'''

==Janvier: Séance 3.1 - 31/01/18==
*Problème de choix matériel:
:les caméras que nous pourrions utiliser nécessitent toutes une connectique en USB 3.0 alors que les cartes Raspberry ne possèdent pas de port USB 3.0
:donc nous nous orientons vers un kit de développement Intel
:qui contient une caméra '''SR-200''' aux caractéristiques:
::format image couleur : 77*47*70 / 77*43*70 D*V*H (Diagonal, Vertical, Horizontal)
::format image IR : 70*46*59
*Nouveau calcul de la distance nécessaire entre la MPS et le Robotino:
::Couleur
:::donc pour x=70cm et alpha=70° on a d=61cm
:::donc pour x=35cm et alpha=70° on a d=30,5cm
::IR
:::donc pour x=70cm et alpha=59° on a d=71cm
:::donc pour x=35cm et alpha=59° on a d=35,5cm
'''cf. schéma scéance 1.3'''
 
*Comment détecter les bords contours d'une MPS sur l'image renvoyée par la caméra ?
:possibilité d'utiliser la librairie OpenCV qui possèdent des fonctions de traitement d'image,
:il sera nécessaire d'appliquer un filtre sur notre image avant traitement, notamment
::- Laplace
::- Sobel
::- Canny

==Feuille d'heures Février==

{| class="wikitable"
!Tâches Février !! Prévisionel !! Séance 1 !! Séance 2 !! Séance 3 !! Séance 4 !! Total
|-
| ''Wiki''
| 2
|
|
|
|
|
|-
| 1.Créer une banque d'image pour chaque MPS
| 3
|
|
|
|
|
|-
| 2.1.Détection des contours
| 6
|
|
|
|
|
|-
| 2.2.Détection des bords
| 6
|
|
|
|
|
|-
| 2.3.Détection des formes
| 14
|
|
|
|
|
|-
| 3.Stockage des informations pour chaque MPS
| 4
|
|
|
|
|
|-
| 4.Connexion et récupération de l'image prise par la caméra
| 2
|
|
|
|
|
|-
| 5.Comparaison avec la banque d'images
| 8
|
|
|
|
|
|-
| 6.Connexion et envoie des résultats au Robotino (ID machine + machine suivante ?)
| 2
|
|
|
|
|
|-
| '''TOTAL'''
| 47
|
|
|
|
|
|}

==Février : Séance 1 - 07/02/18==

* Décomposition du code avec prévision du temps nécessaire à la réalisation
* Possibilité d'utiliser un filtre de Cznny (mais le résultat dépend de la qualité de l'image donc à tester), d'un filtre de Prewitt.
* Documentation sur les fonctions findcontours et drawcontours de la librairie openCV
* Problématiques:
::avec l'extraction des contours on risque d'avoir un "dessin" trop précis (à cause des fils ...), trop de détails pour que l’algorithme de comparaison donne des résultats probants.
::on pourrait chercher à reconnaître des formes précises (carrés, rectangles) mais dans ce cas là risquent liés à l'orientation du robot par rapport à la machine
* Réunion avec les tuteurs
::caméra acquise: BlasterX Senz3D
::nécessité d'un 25 V -> 5V pour alimenter la caméra à partir du Robotino
::validation de l'utilisation des filtres
::validation de la possibilité de ne sélectionner que les points de telle à telle profondeur

==Février : Séance 2 - 14/02/18==
* Premières tentatives de communication avec la caméra peu concluantes:
::difficultées liées à l'utilisation d'une VM,
::au téléchargement correct de la librairie openCV,
::à la reconnaissance de la caméra par un OS linux.

==Février : Séance 3 - 21/02/18==
* Connexion avec la caméra établie (utilisation d'openCV2, python 3.4.0 et Ubuntu 16.04)
* Test des différents filtres: 
[[Fichier:Comparaison_filtres.png]] 
(un test face à une MPS viendra bientôt remplacer celui-ci) 
A noter que le filtre de Canny prend en compte 2 arguments:
::- seuil bas
::- seuil haut
Il permet d'éliminer des faux contours. En prenant en compte l'intensité du gradient et sa direction, il permet d'éliminer un pixel qui pointe vers 2 valeurs supérieure car ce n'est pas un maximum local. Ensuite il effectue un seuillage par hystérésis. On commence par sélectionner les points qui dépassent le seuil haut et on applique ensuite le seuil bas en ne conservant que les composantes connexes qui contiennent un point au-dessus du seuil haut. 
En résumé: (en vert on conserve après filtrage, en orange on ne conserve pas.) 
[[Fichier:canny1.jpg]]

* Éléments pouvant être utiles au projet (à tester au cours des prochaines séances):
::- Extreme Points (topmost, bottommost, rightmost and leftmost)
::- cv2.getAffineTransform et cv2.warpAffine qui permettent une transformation affine

=Documents Rendus=

Fichier:Comparaison filtres.png

2018-02-21T16:36:45Z

Zbriois :