Lunette à vision augmentée : Différence entre versions

Version du 25 février 2013 à 12:56

Introduction

Dans le cadre de notre dernière année à Polytech, nous avons dû nous atteler à un projet de fin d’étude durant le mois et demi qui a suivi le retour de notre semestre à l’étranger. Dans ces conditions, nous avons choisi le sujet "Lunette à vision augmentée". En effet, ce sujet est plus dans une optique Systèmes Communicants et a attiré notre curiosité (suite, par exemple, à l’annonce des Google glasses, de l’Oculus Rift de Valve...). Nous allons donc voir à travers ce Wiki le déroulement par semaine de ce projet.

Présentation du projet

Le but de ce projet est de mettre en œuvre une caméra à l'aide d'un Arduino et/ou d’une nanoboard FPGA XILINX (carte Altium). L’objectif étant d’afficher l’image soit sur un écran LCD prévu pour Arduino soit sur un moniteur d'ordinateur. L’un des objectifs finaux étant d’afficher, en surimpression, du contenu comme l'état de capteurs (accéléromètre, température, ...) sous forme de texte, d'images, dynamiques ou non.

Matériel à disposition

OV662 Image Sensor

Pour effectuer ce projet, nous avions plusieurs instruments et matériaux à disposition. En voici une liste détaillée:

• Caméra CA88 : caméra 1/4” avec sortie digitale 8 ou 16 bits. Le capteur d’image OV6620 est de type CMOS. Cette caméra est configurable via un bus I2C (résolution, FPS, Gamma, gain, balance des blancs...).
• Nanoboard Xilinx, Spartan 3 (FPGA).
• Arduino Atméga 2560.
• Ecran LCD Color Shield Phillips (de chez Sparkfun) pour arduino.
• Un analyseur logique.
• Un accéléromètre ADXL3xx (pour Arduino).
• PC + 2 moniteurs.

• logiciel Altium Designer version 9 puis 10 (différents problèmes sont intervenus lors des compilations…)
• logiciel Arduino.

Séance

Semaine du 14/01 au 18/01

• Etude du matériel
• Etablissement d'un cahier des charges
  • Etudes des possibilité
  • plus tendance à travailler sur le FPGA, à longs termes, que sur le arduino (capacité de calculs)
• Fonctionnement de la caméra:
  • mode RGB
  • Résolution 352x288
  • Un pixel de caméra par couleur
  • Chaque pixel est codé sur un octet
  • Organisation spatiale et envoie de données pas très intuitif
  • Configuration par I2C => utilisation d'un arduino atméga pour le faire car c'est plus simple que sur FPGA
• Fonctionnement de l'écran LCD
  • un pixel est RGB => envoie de 12 bits, 4 bits par couleur

Semaine du 21/01 au 25/01

• Configuration I2C de la caméra

 void config_cam(){      //I2C pour config camera
 Wire.begin(); // join i2c bus (address optional for master)
 
 Wire.beginTransmission(0xc0); // transmit to device #192 CA88
 Wire.write((uint8_t) 0x12);     // soft reset
 Wire.write((uint8_t) 0xa4);
 delay(100);
 
 Wire.write((uint8_t) 0x12);
 Wire.requestFrom( 0xc0, 1);
 Serial.print("lecture : ");
 Serial.println("%d", Wire.read());
 
 Wire.write((uint8_t) 0x11);     // vitesse = 2 i/s
 Wire.write((uint8_t) 0x3F);
 //delay(1000);
 Wire.write((uint8_t) 0x12);     // RGB
 Wire.write((uint8_t) 0x2C);
 //delay(1000);
 Wire.write((uint8_t) 0x13);     // 8 bit mode
 Wire.write((uint8_t) 0x21);
 //delay(1000);
 Wire.endTransmission();
 }

• Test de lecture des données via le port série du Arduino.

=> on voit des données mais le logiciel plante après un peu de temps, cela est surement du à la vitesse de transmission.

On décide donc de passer sous Altium Designer avec un embeded projet pour avoir accès à un terminal (et programmation en C). => on affiche des données. On analysera cela la semaine suivante.

Semaine du 28/01 au 1/02

À partir des résultats de la semaine précédente, nous avons tenté d'obtenir uniquement une image (toujours sur le terminal). Pour cela, on s'est synchroniser sur une nouvelle image en attendant un front montant de VSYN (signal de synchronisation d'une nouvelle image). Puis il a fallu prendre en compte le signal HREF (un niveau haut indique qu'on se situe toujours sur une même ligne de l'image et un front descendant indique la fin d'une ligne). Après ce test, nous n'avons plus rien observé sur le terminal. Il semblerait que la synchronisation ne fonctionne pas.

On a donc décidé de lire les signaux de synchronisation à la place des données. On a bien observé des valeurs qui varient, il y a donc bien des changements d'état de ces signaux. On a tenté de comptabiliser le nombre de changement de ces signaux sur un nombre de lecture donnée. On a remarqué que pclk gardait toujours l'état 1. Nous avons, par la suite tenter d'obtenir une bonne synchronisation mais sans succès.

Semaine du 4/02 au 8/02

Semaine du 11/02 au 15/02

Semaine du 18/02 au 22/02