Version du 7 février 2018 à 16:06

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

Feuille d'heures Janvier

Janvier: Séance 1.0

• connaissance/mise en place du CDCF
• analyse concurrentielle
• analyse matérielle
• réponses aux questions difficiles/vagues

Janvier: Séance 1.1 - 15/01/18

• choix de la kinect360

• possible kinect - ROS - Raspberry

• Choix du CDCF pour reconnaitre une MPS
  • le robot se met “face” à la MPS
  • si il trouve → s'arrête
  • sinon refais sur une autre face
  • associe les probabilités de la 1ere face et la 2eme
  • si toujours pas de pourcentage assez élevé
  • fais sur une troisième face et ainsi de suite…
  • fin au bout de 4 faces repérées

• WIKI mis à jour

• Excel pour séances et nombres d’heures passées

Janvier: Séance 1.2 - 17/01/18

• format fichier MPS 3D .wrl
• ne prendre que les points associés à la partie haute

• Code en plusieurs parties :
  • récupération de la surface de l'objet avec fichier wrl (plan 3D)
  • récupération des points infra-rouge de la kinect
  • récupération d’une photo 2D prise avec la kinect
  • 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
• 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

Placement de la kinect pour voir toute la partie haute de la MPS :

Champs de vision de la kinect V1:

• Champ de vision horizontal : 57 degrés
• Champ de vision vertical : 43 degrés
• 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); 

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

   //extraction des contours de l’image vue par la camera
   //les mets dans un 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(iint d) {
           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

• Wiki
• rendez-vous avec tuteur
  • trouver distance pour laquelle la kinect voit toute la partie haute de la MPS (minimum 0,80m) + vérifier si profondeur du laser correspond ok - S7
  • raspberry à une puissance de calcule suffisante ? ok - S7
  • echange de données par réseau
  • utilisation de ROS kinetic et ubuntu 16.0.4
  • voir comment on alimente la raspberry et la kinect - avec le robotino ? ok ? demander confirmation

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

• Choix :
  • raspberry 3
    • alimentation 5V, 2.5A
  • kinect v2
    • alimentation avec adaptateur fourni
    • ou utilisation d’un hub usb avec sa propre alimentation
• distance pour placer la kinect V2
  • champs vision kincet v2 : 70,6 * 60 degrés
  • dimension MPS 70*35*x
  • donc pour x=70 et alpha=70,6 on a d=60cm
  • donc pour x=35 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

Janvier: Séance 3.1 - 31/01/18

• Problème usb 3.0
  • choix d'un kit de développement intel
• Algorithmes pour la détection de bord et de contour (à revoir + librairie OpenCV) :
  • Laplace
  • Sobel
  • Canny
• Camera SR-200
  • Couleur : 77x47x70 / 77x43x70 DxVxH (Diagonal, Vertical, Horizontal) :
  • IR : 70x46x59
    • 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

Feuille d'heures Février

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

Documents Rendus