Version du 12 février 2018 à 14:42

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.

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 :

1. Récupérer l'image vue par la caméra(profondeur)
2. Extraire les contours
3. Comparer avec les contours connus des MPS
4. Si il y a correspondance à plus de 70%, envoyer l'id de la machine au Robotino
5. Sinon se placer sur un autre côté de la machine puis retour étape 1.

Pour cela nous devrons:

1. Créer plusieurs vues des différentes MPS à partir des modélisations 3D à notre disposition
2. Extraire les contours de ces images(formes, nombre de formes, placement)
3. 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é (*)

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:

1. 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.
2. 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

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 < br/>

3. 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

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

1. Connexion de la caméra à la carte
2. Fonction pour récupérer l'image vue par la caméra
3. Fonction permettant l'extraction des contours sur cette image
4. Extraction des contours d'après les modélisations 3D à notre disposition
5. Fonction de comparaison
6. Connexion de la carte au Robotino
7. Fonction permettant l'envoi de l'id de la machine reconnue au Robotino
8. Fonction permettant l'envoi de la demande au Robotino de se déplacer pour visualiser une autre phase de la MPS

Calendrier prévisionnel

Réalisation du Projet

DÉSOLE WIKI MOMENTANÉMENT EN CHANTIER

Feuille d'heures Janvier

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

programme qui passe plan 3D en 2D → besoin de la couleur ? surtout forme objets ?

1ere comparaison avec photo 2D (si gain de temps) - machine learning sur piece 2D

si reconnaissance <70%

sinon passe à la 2eme comparaison

span style="color:red">2ème comparaison : fichier 3D - points relevés avec la kinect - machine learning sur piece 3D ? On prend que la profondeur ?

(Si oui, algorithme pour reconnaissance d’image et entrainement avec une base de données)

Si Pourcentage entre les machines reconnus >70% algo fin et renvoie de l’ID de la MPS sinon --> refait la même chose avec une autre face

Si <70% garde analyse en pourcentage et efface points kinect

Janvier: Scéance 1.3 - 18/01/18

• Solution pour code :

faire avec photos 2D

essayer avec l’outil de google (https://cloud.google.com/vision/?hl=fr - https://cloud.google.com/ml-engine/)

reprendre le code

enlever la dernière couche

mettre les photos d’une machines

obtenir un vecteur (correspond au coefficient des noeuds)

repasser ce vecteur dans l’algorithme

essayer avec l’outil d’IBM (https://www.ibm.com/watson/services/visual-recognition/ ) avec 20 photos → donne déjà assez bon résultat

transferred learning --> pas pour nous

• 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 :

on en déduit :

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

-> fait à la séance ... (7?)

estimer si la Raspberry à une puissance de calcul suffisante

-> fait à la séance ... (7?)

echange de données par réseau

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.

nous avons également discuté de l'utilisation de ROS kinetic et d'ubuntu 16.0.4

Janvier: Séance 2.2 - 25/01/18

• caractéristiques + alimentation raspberry --> deep learning compatible si RAM > 128M0 --> suffisant pour machine learning avec raspberry 2 et 3
• caractéristiques + alimentation kinect: portée minimale pour les mesures de distance = 0,5 m

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

faudrait qu'on mette un schéma

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=70 et alpha=70 on a d=61cm

donc pour x=35 et alpha=70 on a d=30,5cm

IR

donc pour x=70 et alpha=59 on a d=71cm

donc pour x=35 et alpha=59 on a d=35,5cm

faut mettre schéma

• 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

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

• Décomposition du code avec prévision du temps nécessaire à la réalisation
• Réunion avec les tuteurs
  • caméra acquise

Février : Séance 2 - 12/02/18

=Documents Rendus=