Fiche de proposition de projet: https://bvdp.inetdoc.net/data/docs/Fiche_Projet_Tutore2009.doc

Titre : Ajout de fonctionnalité de vision et de cartographie de l’environnement à un système de drone d’extérieur.

Mots clés : Drone, traitement d’images, systèmes embarqués

L’objectif est d’embarquer différents systèmes d’acquisition d’images à bord d’un drone utilisant le système paparazzi développé à l’ENAC (http://paparazzi.enac.fr/wiki/Main_Page) et d’acquérir des séquences d’images afin de générer des cartes composites géoréférencées. Les stagiaires devront développer des fonctionnalités logicielles de traitement des données et les intégrer au sein du système paparazzi. Sujet large avec possibilité de l’orienter plus spécifiquement en fonction des compétences des stagiaires.

Développement en langage C/C++ pour cible PC, microcontrôleur ARM7 et Gumstick. Système d’exploitation Linux. Compétences en Vision par ordinateur et Optimisation appréciées mais pourront être acquises pendant le stage.

Equipement drone du LAAS-CNRS (drone Nirvana). PC embarqué (PicoITX) et Gumstick. Appareil photo numérique CANON, Caméra analogique sans fil et carte d’acquisition USB. Stations PC sous linux pour le développement.

Projet Long 3e annee ENSEEIHT/GEA-AII:

1. michael rischmuller
2. benjamin rouanet
3. didier quirin

michael.rischmuller@etu.enseeiht.fr, benjamin.rouanet@etu.enseeiht.fr, didier.quirin@etu.enseeiht.fr

Convention d'accueil a voir avec eux et Maria David la responsable de departement GEA qui est au courant:

Maria DAVID Téléphone : 05 61 58 82 57 E-mail : Maria.David@enseeiht.fr

anais martin (PERSONNEL LAAS) s'occupe des stagiaires amartin@laas.fr absente jusqu'au 4 janvier. Vous pouvez envoyer votre mail à personnel@laas.fr.

demander si ils sont francais ou CEE —→ OUI, sinon CV+ date et lieu de naissance + nationalité + programme du stage+sujet de 10 à 15 lignes

faire une convention de stage à l'enseeiht a faire signer par raja en 3 exemplaires

Ordre du jour:

-Présentation des problématiques

  génération de cartes
  mosaiquage pour modèle de sol plan, traversabilité 2D1/2
  vraies cartes 3D? soit cartes eparse+ triangulation soit carte de type surface (Modèle Numérique de Terrain)
  faciliter l'obtention des cartes
  déterminer les propriétés de la carte: taille et résolution fixée ou taille et résolution a partir des images
  faciliter le géoréférencement des cartes
  synchro
  choix des images valides/utiles (estimation du flou: 

flou_rfia.pdf_13062005.pdf

  refaire une raie pendant laquelle il y a eu un problème (améliorer fonction de navigation)
  IHM

-Présentation des outils

  drone paparazzi, cellule, gps, attitude, IMU ? (enregistrement et synchro?) 
  caméra, appareil photo numérique  (video ou photo, déclenchement?, synchro?), modèle géométrique, distorsions radiales, étalonnage géométrique
  étalonnage Caméra/robot
  station sol, bus Ivy, modules, CamL
  GIS, SRTM  http://grass.osgeo.org/wiki/HOWTO_import_SRTM_elevation_data
  JAFAR, C++ et Ruby, module traversability
  IHM avec QT (s'inspirer de ueye_demo, sur sony?)
  sba et bundler?

-Développement d'une interface graphique pour la création de cartes

  On reste sur des cartes de type mosaiques planes pour l'instant
  Le programme doit être constitué de plusieurs modules, de manière à pouvoir l'étendre facilement par la suite

-1 module pour l'acquisition des données

  Différents types d'images en entrée (jpeg, raw, nommage différent, fichiers video avec différents codec...); 
  Frame rate variable, images associées à des poses si déclenchement de l'acqusisition avec la tiny, 
  sinon interpoler les poses en fonction du frame rate. Pour la lecture des images/videos: OpenCV, imageMagic, ffmpeg...?
   

  Un fichier de log paparazzi: Début de décodage et d'affichage dans le soft suivant:  

https://bvdp.inetdoc.net/data/trajectoire.zip

  Définir les  début et fin de séquence soit à partir du log soit à partir des images
  Gestion de la synchro entre le log et les images (afficher les 2)
   

-1 Module pour l'affichage des cartes

  Représentation possibles des cartes en mémoire:
     -1 bitmap haute résolution résultat du recalage
     -les différentes images acquises et les transformation associées (pratique si on zoom sur une zone)
     -plusieurs bitmap à différentes résolutions
     -1 carte globale ou une carte par raie
  Dans un premier temps, calcul des images par le CPU en utilisant des applications d'homographie
  Dans un second temps, Benjamin souahaite peut etre utiliser OpenGL pour le rendu accéléré 
  (attention à la gestion de la mémoire de la carte video pour les textures, limitation à des images 2048*2048 à vérifier). 
  Vieux sujet de TP d'openGL à l'ENSEEIHT: 

tp1syntheseimageopenGL.zip

-Un peu d'optimisation (utilisation de la librairie de bundle adjustment)

-utiliser Git pour gérer les versions du projet; CREER UN DEPOT SUR UNE MACHINE LAAS!!!

-utilisation des ordinateurs portables perso.

  Achat de disque externe pour stocker un système linux commun émulé avec virtualbox (version proche de 3.0.12).
  Bertrand doit préparer un linux nettoyé.
 

-Utiliser KDevelop comme environnement de développement.

  QT pour la gestion d'interface de l'application. 
  Décrire l'interface par du code pour pouvoir la modifier dynamiquement.
  

-Faire rapidement un petit projet avec quelques boutons etc… pour voir ce qui est faisable…

-explication de base des lois de commandes de paparazzi

   Michael souhaiterai contribuer à l'amélioration des fonctions de navigation pour refaire un rail mal acquis.
   éventuellement porter le code d'affichage de carte sur le arm juste pour obtenir l'info de visibilité. 

-Conventions de stage transmises au service du personnel du laas qui les fait signer et les transmet par courrier à l'enseeiht

Pas de réunion…

Pas de réunion… le créneaux a été déplacé au jeudi et Bertrand est en surveillance d'examen

réunion a l'enseeiht, en salle B301 de 14 à 18h pour un TP de vision

sujet: sujet_TP_stereo_2010.pdf

fichiers: TOOLBOX_calib_TP2007.zip

réunion a l'enseeiht, en salle B301 de 14 à 18h pour un TP de vision

Réunion au LAAS, administration (carte acces, carte cantine, etc…)

doc srtm: SRTM

spécification du programme

entrées/sorties

installation des machines virtuelles et du système linux

adresses mac pour comptes informatiques:

michael.rischmuller@etu.enseeiht.fr

MAC eth: 00-1E-EC-56-F2-70

MAC wifi: 00-19-7E-0F-D1-63

benjamin.rouanet@etu.enseeiht.fr

MAC eth: 00-1E-33-23-BE-B4

MAC wifi: 00-1E-64-08-41-A8

didier.quirin@etu.enseeiht.fr

MAC eth: 00-1B-63-38-C0-88

MAC wifi: 00-1C-B3-BC-43-EE

Version haute qualité (1.4 Go): mvi_0068.avi

Version basse qualité (80Mo): videofaclq.avi

fichiers logs associés: https://bvdp.inetdoc.net/data/avions/09_11_27__10_52_18.data et https://bvdp.inetdoc.net/data/avions/09_11_27__10_52_18.log

décollage a 22 secondes sur la video et atterrissage a 12min 12 (732secondes) → 710 secondes de vol

dans le plan de vol ca correspondrait à 215 s jusqu'à 735 s mais apparament la video prend de l'avance sur le log

il faudrait avant de lancer l'avion rester immobile qq secondes pour bien voir vitesse nulle dans le log paparazzi, idem apres attero. On peut aussi faire qq gros mouvement en roulis/tangage avant et apres le vol pour recaler d'apres l'attitude

stockée aussi sur machine borderouge dans /local/users/bvandepo/videofac

Thèse de master de Norman Juchler, Homographies, documentation du module JAFAR Traversability: https://bvdp.inetdoc.net/data/docs/JuchlerNorman-MasterThesis-TraversabilityAssessment.pdf

documentation OpenCV en ligne: http://opencv.willowgarage.com/documentation/cpp/index.html

bonnes infos, notamment pour lire des videos: http://www.cs.iit.edu/~agam/cs512/lect-notes/opencv-intro/opencv-intro.html#SECTION00051000000000000000

présentation irit: http://www.irit.fr/~Gael.Jaffre/LOGICIELS/OPENCV/pres_opencv_irit.pdf

http://www.discover.uottawa.ca/~qchen/my_presentations/A%20Basic%20Introduction%20to%20OpenCV%20for%20Image%20Processing.pdf

sur borderouge, openCV dans:

/usr/include/opencv/cxcore.h
/usr/include/opencv/cxcore.hpp

regarder si la camera est commandable par la tiny (par cable usb?) sinon utiliser servo moteur sur le shutter

-utiliser Git pour gérer les versions du projet; CREER UN DEPOT SUR UNE MACHINE LAAS!!!

URGENT: Régler les PID de l'autopilote pour qu'il n'oscille pas en vertical

1) détection du flou
2) incohérence géométrique
  soit par mesure de distance sur les 4 coins de l'image reprojetés sur la mosaïque / a la précédente image

  soit par décomposition de l'homographie, mais il faut connaître les paramètres intrinsèques et le plan du sol...

3) nombre de points d'intérêt détectés et appariés
4) analyse du log paparazzi pour voir quand la navigation a été mauvaise
4) analyse du log paparazzi pour ne traiter que les images des raies (optionnel, on doit aussi pouvoir traiter des séquences intermédiaires si on le veux)

il faut dans le cas ou il y a problème, refaire l'estimation sur une autre paire d'images…

si il y a trop d'images successives mauvaises, générer une nouvelle mosaïque

Générer des films directement sans passer par des images intermédiaires: http://www.cs.iit.edu/~agam/cs512/lect-notes/opencv-intro/opencv-intro.html#SECTION00051000000000000000

utiliser sba pour raffiner l'estimation: http://www.ics.forth.gr/~lourakis/sba/

essayer le soft: http://phototour.cs.washington.edu/bundler/

http://phototour.cs.washington.edu/bundler/bundler-v0.3-manual.html

confirmer la bonne rectification sur 1 fichier avec parametres grands → OK

Attention!!! si la rectification fait apparaitre des pixels vides dans l'images, il faut ABSOLUMENT les traiter comme tels pour la détection des points d'interet et surtout pour l'ajout aux cartes/mosaiques

Eventuellement on peut tricher en n'utilisant que le rectangle englobé de la partie de l'image rectifiée disponible

Drone utilisant le système paparazzi: http://paparazzi.enac.fr/wiki/Main_Page

faire un soft en langage C qui à partir de:

1. >1 video acquise à bord d'avion
2. >1 fichier config pose relative + param camera (dont dist radiale)
3. >1 log paparazzi (avec des messages de début et fin rails en option), la position vient du GPS, l'orientation soit du capteur infrarouge, soit d'une centrale inertielle
4. >1 fichier SRTM (altitude sol, pour savoir sur quoi reprojeter)

genère une mosaique (image composite):

1. > 1 image HR bitmap
2. > selection automatique des images utiles de la video (pour avoir un recouvrement suffisant) → copie vers repertoire, avec les poses associées, de manière à pouvoir régéner la mosaique à partir de ces données
3. > Raffinnage par Bundle Adjustment à postériori

1. > Générer des mosaiques en gris ou couleurs

je pense que la phase P1 est réalisable pendant un projet long. J'ai déjà écrit ou fait écrire pas mal de code. il faudrait réorganiser le tout et ajouter quelques fonctionnalités pour que l'obtention des cartes se fasse sans trop d'intervention de l'opérateur. concernant le traitement d'image, je dispose déjà d'un module en C++ développé au laas permettant de faire le mosaiquage (recalage géométrique) des images mais il faudrait l'améliorer. notamment j'aimerai bien que les images floues soient détectées et éliminées pour ne pas contaminer la carte. Aussi dans un premier temps j'aimerai évaluer la possibilité d'effectuer le recalage uniquement sur la base des informations GPS et capteur d'orientation…

Ensuite, il faudrait évaluer la portabilité de cet algo (basé GPS et orientation) sur le microcontroleur ARM de l'autopilote afin d'avoir à bord une carte simplifiée indiquant quelle partie de l'environnement a été cartographiée. Il serait alors possible d'envisager la phase P3, le ARM déclenchant l'acquisition des images en fonction des besoins.

donc concernant le traitement d'image:

1. utilisation d'outils existants (module JAFAR du LAAS)
2. calcul de transformation à appliquer en fonction d'infos GPS + orientation + caméra utilisée
3. calcul d'images à partir de plusieurs images auquelles on applique une transformation géométrique
4. estimation de la netteté d'une image

concernant le traitement de données autres que les images:

1. récupération des infos de l'autopilote (soit dans les fichiers de log soit en direct pour traitement à bord)
2. gestion de fichiers de paramétrages (par exemple pour indiquer la caméra, son orientation relativement à l'avion, la zone à cartographier etc…)

Le stage devra également permettre d'obtenir des cartes sans nécessiter énormément de place sur le disque dur. Il sera donc intéréssant de:

1. charger les images à mosaiquer depuis un fichier video: (ajouter au module image de jafar: pour lire un flux video depuis un mpeg, utiliser la fonction cvcapturefromfile utilise fcapture sous linux)
2. précalculer une look up table de rectification radiale à appliquer aux images
3. appliquer les corrections à la volée
4. gérer les images n&b et couleur sans nécessiter de conversions
5. eventuellement couper les fichiers vidéo pour ne stocker que les parties utiles (vérifier compatibilité avec plusieurs caméra,codec etc…)

Egalement, il sera interessant de découpler les traitements:

1. calcul des homographies interimages (a partir de données en grey)
2. affichage de stats sur les homographies calculée (nombre de points matchés, cohérence avec telemétrie,…)
3. calcul du plan horizontal (IMU, ???? ) pour savoir sur quoi reprojeter les images (la 1° image n'est pas une bonne base de reprojection)
4. génération de cartes mosaiques entre intervales de numéros d'images (dimensions de la carte connue grâce au précalcul des homographies, ou grace aux données de pose de caméra), couleur ou grey
5. génération de cartes de traversabilité entre intervales de numéros d'images (dimensions de la carte connue grâce au précalcul des homographies)
6. génération de videos couleur ou grey

Lecture d’une vidéo AVI Il est possible de lire une séquence d’images à partir d’un fichier vidéo. Pour chaque étape, une image de type IplImage est automatiquement allouée (puis libérée) en mémoire.

/* Variables */
IplImage *im;
CvCapture *avi;
/* Ouverture de la video */
avi = cvCaptureFromAVI("ma_video.AVI");
while(cvGrabFrame(avi)) 
 {
 im = cvRetrieveFrame(avi);
 /* Traitement de l’image */ 
 }

?

pour éviter l'enregistrement intermediaires des images sur le disque puis la conversion avec mplayer

J'ai un code C pour la rectification des distorsions radiales. l'integrer à un module jafar pour pouvoir rectifier les images à la volée, en ajoutant le précalcul de la transformation. prévoir l'interpolation bilinéaire en stockant 4 valeurs par pixels pour pondérer.

en decouplant l'estimation de pose et le calcul de traversabilité, il n'est plus possible d'utiliser la détection des zones non traversables pour determiner les outliers pour l'estimation d'homographie

cela ne remet pas tout en cause mais il faut donc calculer la traversabilité en même temps que les homographies et stocker les résultats dans des images, qui seront ensuite mosaiquées lors du calcul de la carte de traversabilité

Données et matériel disponibles

Il faut récupérer les fichiers de log paparazzi et les synchroniser avec la séquence video.

Récupérer le parser de fichier log (écrit en quel langage?) sinon en refaire un simple…

Données et matériel disponibles

video à télécharger: video_vol_capture6_divx4-avc-500Kbps.avi

Le PC station sol doit récupérer les messages paparazzi en provenance de l'avion et utiliser ceux indiquant la pose de la caméra.

L'équipement embarqué à bord de l'avion doit pouvoir déclencher la prise de vue (commande shutter mécanique ou electronique?) Il doit décider seul à quel moment acquérir les images pour couvrir la zone à cartographier. Le bitmap de la zone à cartographier et le rectangle englobant le losange (voir fonction losange survey). La fonction losange survey pourra etre modifiée pour refaire un rail si l'avion ne l'a pas effectué correctement

La partie selection des images doit pouvoir tourner en temps réel sur le ARM, un bitmap binaire (taille des cellules à définir) représente les zones déjà observées.

La récupération des images sur le PC doit se faire le plus simplement possible, indépendamment de l'appareil utilisé (notamment concernant les noms de fichiers, les numéros d'images de début et fin)

Quelle est la cadence max d'acquisition des images sur la carte sd de l'appareil photo….

Problématiques:

1. > Communication ARM Tiny/ Gumstick?
2. > Que faire tourner sur la gumstick?
3. > Quelle camera embarquer?

Image Mégapixel non comprimée d'une caméra USB Ueye

faut il embarquer les infos SRTM sur la tiny pour la zone à cartographier? Quel volume de données? est ce que l'altitude moyenne ne serait pas suffisante (ou alors take off alt?)?

Estimer les images qui sont floues pour ne pas les traiter et contaminer la mosaique

georeferencement sur base google: définitions des correspondances à posteriori (anchors), Eventuellement réflechir à un moyen d'intégrer cela dans le bundle adjustment (une correspondance de point pour une image contraint la pose correspondante)

gestion multirésolution, rendu en ligne, etc…

http://www.gigapan.org/

http://postproduction.digitalmedianet.com/articles/viewarticle.jsp?id=173174

1. Récupérer les informations du fichier log (attitude, GPS) + fichier SRTM + calibrage caméra pour chaque point
2. Extraire les images du flux vidéo en fonction du signal snapshot (pour ne pas extraire les images inutiles) il faut également dater ces images
3. Appliquer une fonction de correction pour éliminer la distorsion radiale sur les images
4. Synchroniser les fichiers images avec les données du fichier log, si il n'y a pas de donnée au moment de l'image, faire une moyenne pondérée
5. Créer une structure de donnée comprenant le pointeur pointant l'image + toutes les données ( SRTM, GPS, Attitude)
6. Calculer le point de départ et de fin en fonction des courbes de vitesse
7. L'utilisateur pourra également choisir le point de départ lui même en cliquant sur la courbe de vitesse
8. Calcul des homographies en chaque point
9. Générer la mosaïque avec les images créées
10. Enregistrer la mosaïque sous différents format (choisi par l'utilisateur) bmp, jpeg, png . . .

1. Possibilité de décimer des images qui posent problèmes.
2. Détecter les images qui sont flou et ne pas les prendre en compte
3. Créer une image avec la trajectoire de l'avion + des petites imagettes sur la trajectoire à une fréquence faible
4. Permettre à l'utilisateur d'enregistrer une partie de la carte seulement
5. Permettre à l'utilisateur d'éliminer des images en cliquant simplement dessus apres l'avoir visualisée en grand pour vérifier que c'est celle ci qui pose problème
6. Permettre de faire des zooms sur la mosaïque générée
7. Afficher des statistiques pour permettre de savoir si le vol effectué à permis d'avoir des données exploitables

Comment synchroniser le fichier log avec la séquence vidéo car les 2 ne sont pas sur la même base temps et ils sont complètement indépendant l'un de l'autre

je vous ai créé un dossier avec acces complet sur borderouge:

/local/users/bvandepo/mosaic/

pour copier depuis chez vous:

scp nom_fichier_local login@borderouge:/local/users/bvandepo/mosaic/

pour se logger

ssh  login@borderouge
cd /local/users/bvandepo/mosaic/

pour copier vers chez vous

scp  login@borderouge:/local/users/bvandepo/mosaic/nomfichier_distant dossier_chez_vous

n'ecrivez QUE dans ce dossier et eventuellement des sous dossier!

pour acces depuis l'exterieur, ecrire borderouge.laas.fr

decrypter log et STRM

Pour SRTM: definir les zones max de la carte. Calculer la valeur moyenne d'altitude du sol.

Pour LOG: créer tableau en modifiant z

note norme codage:

format nom fonction la fonction est notée f_mafonction noter en commentaire parametres d'entree et de sortie

exemple:https://bvdp.inetdoc.net/wiki/doku.php

int f_SRTM ( int xmax; int ymax; *fichierSRTM ) {

//paramètres d'entrée:
//paramètres sortie:
//rôle fonction:

}

mode TYPE=uint8 UNIT=byte_mask

utm_east TYPE=int32 UNIT=cm

utm_north TYPE=int32 UNIT=cm

course TYPE=int16 UNIT=decideg

altitude TYPE=int32 UNIT=cm

speed TYPE=uint16 UNIT=cm/s

climb TYPE=int16 UNIT=cm/s

itow TYPE=uint32 UNIT=ms

utm_zone TYPE=uint8

gps_nb_err TYPE=uint8

CameraSnapShotNumber TYPE=int32

phi TYPE=float ALT_UNIT=deg UNIT=rad ALT_UNIT_COEF=57.3

psi TYPE=float ALT_UNIT=deg UNIT=rad ALT_UNIT_COEF=57.3

theta TYPE=float ALT_UNIT=deg UNIT=rad ALT_UNIT_COEF=57.3

On peut les télécharger avec plusieurs résolution 250 m, 1 km … http://srtm.csi.cgiar.org/

Probleme : Les fichiers sont tres lourd une fois décompressé : une vingtaine de Giga

Trouver une solution pour récupérer les données a travers un serveur car le temps de traitement d'un tel fichier serrait trop long pour obtenir une simple moyenne de l'altitude du sol survolé.

Il est possible de télécharger des plus petites partie de fichier Srtm qui font une vingtaine de méga compressé, voici le lien : http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp

Le fichier est de format TIFF accompagné d'un fichier TFW qui a cette structure :

Le fichier *.TFW a cette structure:

X pixel dimension: Largeur dans l'unité du pixel X (Quand on ne connaît pas la distance, on tatonne)

Rotation sur les lignes: 0 pour les bonnes images

Rotation sur les colonnes: 0 pour les bonnes images

Y pixel dimension: Valeur souvent négative (Inverse de l'X pixel dimension)

Coordonnée en X du point d'origine

Coordonnée en Y du point d'origine

http://www.siteduzero.com/tutoriel-3-146390-avant-propos.html