Acquisition Capteur linéaire CCD (Mono-ligne)

[invite1632952d]

Bonjour à tous !

Depuis quelques temps je réfléchis au pourquoi du comment de l'acquisition de données provenant d'un capteur CCD mono ligne. Mon but est de tracker une source IR très précisément à l'aide de deux capteurs mono ligne, l'un pour l'axe X et l'autre pour Y, tout ça au maximum d'image par seconde (Théoriquement, avec le capteur que j'ai choisi, 8000 ips. J'ai bien dit théoriquement, si je n'obtiens que la moitié, je ne vais pas bouder).

Pour le capteur, je dispose de l'UPD3739 ( http://www.alldatasheet.com/datashee...C/UPD3739.html ). C'est un capteur de 5000px, qui peut fonctionner au maximum à 40Mhz (Divisé en deux sorties de 20 Mhz). Je ne souhaite PAS capturer l'image entière du capteur à chaque scan, je ne souhaite récupérer que les pixels dépassant un certain seuil.

D'après diverses recherches, autres forums, il semblerait qu'un pic ne soit pas assez rapide pour faire le boulot, qu'il faille plutôt se tourner vers une solution à base de FPGA.

Pour résumer, d'après ce que j'ai compris :

- On génère les deux horloges pour le capteur CCD
- A la sortie du capteur CCD, analogique, on met un comparateur de tension (Un LM360 par exemple, ayant un temps de réponse très court) pour ne laisser passer que les pixels très éclairés, on fait arriver ça sur une entrée digitale du FPGA
- On le stocke dans la ram
- Et, on va dire 50 fois par secondes, on envoie tout le contenu de la ram à l’ordinateur, par usb/Serial, récupéré par un programme en C++ (J'ai besoin de ce rythme là au minimum, 50 fois par secondes, chaque échange pouvant contenir plusieurs " images " ne contenant que les pixels éclairés)

Vais-je dans la bonne direction ? Ou je me plante complètement ?

Merci d'avance pour vos avis
-----

[invite1632952d]

(Je met permet de remonter le sujet car j'ai d'autre questions qui serait plus d'ordre générale, mes excuses aux modérateurs si il est interdit de remonter son post de cette manière là)

N'ayant jamais expérimenté dans le domaine des FPGA, j'hésite sur le choix de la board par rapport à mon projet (Qui - Ce ne serait pas drôle sinon - doit être le moins onéreux possible, vu que je compte dédoubler le système pas mal de fois).

J'ai vu qu'il existait les boards Papilio ($49) : http://papilio.cc/index.php?n=Papilio.Hardware (Pas mal d'explications sur le site, bien documenté)
Dans une autre catégorie, les boards plus générale pour faire de l'expérimentation ($79) : http://www.digilentinc.com/Products/...90&Prod=BASYS2 (Je n'ai pas besoin d'avoir tout ça sur la board, mais la clock monte jusqu'à 100 Mhz, ça pourrait être un avantage ? Et la documentation a l'air relativement complète aussi)
Et enfin on tombe dans les méandres d'Ebay, avec pas mal de petites boards dans ce genre là : http://shop.ebay.fr/i.html?LH_TitleD...4&LH_PrefLoc=2 A des prix très interessant (Et en plus, du 5v, parfait pour être alimenté par l'ordinateur).

Pour acquérir des infos à 20Mhz, faut-il que mon FPGA soit cadencé au plus du double ? Du triple ?

Merci d'avance !

[jiherve]

Bonjour,
le traitement gagnerait à être fait entièrement en digital car de toutes les façons il faudra tout numériser donc un ADC rapide c'est bien, echantilloner au quadruple est une bonne idée.
Pour les kits il n'y a que l’embarras du choix Xilinx ou Altera, Lattice, Actel.
JR

[invite1632952d]

le traitement gagnerait à être fait entièrement en digital car de toutes les façons il faudra tout numériser donc un ADC rapide c'est bien

Merci pour votre réponse, mais cela voudrait dire que ma solution avec un comparateur de tension (LM360 par exemple) pour ne laisser passer que les pixels très éclairés ne fonctionnerait pas ? Car d'après ce que j'ai compris, le LM360 pourrait jouer le rôle d'un ADC (Dans le sens où il reçoit de l'analogique et ne ressort que du digital).

Merci !

[A voir en vidéo sur Futura]

[jiherve]

Bonsoir,
si bien sur mais c'est un ADC un bit or la localisation d'une source demande un traitement plus sophistiqué, la tache ayant généralement l'allure d'une gaussienne il faut pour en trouver le centre un peu plus de finesse dans la mesure.
JR

[invite1632952d]

Bonsoir,

Ha ! Oui oui bien sûr, en réalité je comptais traiter ça dans la partie ordinateur. Par exemple le FPGA envoit des paquets de frame à l'ordinateur, et une frame ressemblerait à (2801,2802,2803) qui signifierait que les pixels 2801, 2802 et 2803 dépassent le seuil, ensuite j'en déduis le centre.

Je pense qu'il est plus profitable de " seuiller " dès l'acquisition plutôt que de s'emcombrer d'un ADC 8 bits par exemple qui renverrait une image pleine avec des variantes, puisque le programme de l'ordinateur va de toute manière la contraster, puis la seuiller, puis trouver le centre.

(L'acquisition se fait dans un studio, pas de risque de perturbations lumineuse, ou autre)

Plus tard, je pourrai peut-être envisager d'avoir l'image du capteur en entier, pour l'agrandir et bénéficier des souspixels, mais pour le moment une résolution de 5000px me suffit.

Merci

Si quelqu'un a des conseils sur les modules FPGA, je suis toujours preneur, je n'ai absolument aucune idée de la puissance nécessaire à mon projet (Il faut acquérir 4 sources à 20 Mhz, car il y a deux capteurs CCD et deux sorties par CCD).

[jiherve]

Bonsoir,
reflechis un peu et tu comprendras que tu te trompes;
imagine deux profils triangulaires un dont le sommet est à gauche l'autre à droite mais d'amplitudes égales et un autre rectangulaire du même tonneau , ton comparateur fourni les mêmes info mais pas de bol le centre de la tache n'est pas le même.
too much to learn!!!
JR

[invite1632952d]

Bonsoir,

Hmmmm, je ne suis pas sûr de comprendre, mais c'est peut-être ce à quoi j'avais pensé, j'ai fait un petit schéma pour m'ôter le doute :



(En rouge le résultat)

C'est vrai que le résultat ne sera pas le même, mais j'avais pensé que c'était négligeable ? (Bien qu'il soit en effet dommage de sacrifier ce détail vu le prix de l'ensemble)

Merci d'avance, désolé d'avoir un peu de mal :/

[jiherve]

Bonsoir,
avec un profil triangulaire à gauche le max doit être entre le premier et le deuxième pixel , à droite entre le second et le troisième et avec du carré au milieu.
c'est cependant peut être insignifiant pour ton application, personnellement je préfère digitaliser au mieux et traiter ensuite, bien faire au début économise pas pas mal ensuite.
JR

[inviteaca451ba]

C'est quoi le montage optique devant tes deux barettes CCD?
Si tu mets une lentille devant ta barette, l'image d'une source ponctuelle ne viendra se former sur la barette que si elle est dans le plan formé par l'axe optique de la lentille et l'axe de ta barette. Donc en gros tu verras ta source sur les barette X ou Y que si elle est située dans deux plans de l'espace. En dehors des ces deux plans, tu ne la verras pas.
Enfin sous réserve que j'ai bien compris ton montage.

Tu pourrais peut-être utiliser une caméra CCD du commerce sur laquelle tu aurais retiré le filtre IR. Les CCD sont TRES sensibles au l'infrarouge.
Tu peut aussi étudier le fonctionnement de la Wiimote: elle peut traquer 4 points à 100Hz il me semble. Jette un oeil sur la page Wikipedia.

[invite1632952d]

jiherve -> Evidement, j'aimerai moi aussi digitaliser au mieux, c'était pour procéder par étapes et ne pas accumuler toutes les difficultés d'un coup.

Jerome.jh -> Je réfléchis encore à la question au niveau de l'optique, je sais que c'est possible (De telle caméra existe dans le commerce), et j'ai vu il y a quelques temps une image obtenue grâce à un système similaire (Mais qui servait à un robot qui lui servait à identifier les obstacles autour de lui). Peut-être à l'aide d'une lentille anamorphique extrême, je rentre chez moi dans quelques jours et j'ai un petit stock de lentille pour tester tout ça. Si tu as des idées, de l'inspiration, je suis toujours preneur

J'utilise déjà actuellement depuis plusieurs années des caméras CCD pour ce genre de projet, j'ai commencé avec une petite DV par firewire (Trèèès lourd comme on peut s'y attendre), puis je suis passé aux wiimotes (Très grosse limite de résolution à cause de la taille native du capteur, 320/240, sans parler du nombre de sources limité à 4 et le bluetooth n'est pas forcément un +) et enfin actuellement aux caméras PSeyes de la Playstation 3 (Sans le filtre IR) + filtre ne laissant passer que les IR (640 / 480 à 75Hz, 320 / 240 à 175Hz, possibilité d'en connecter pas mal au PC si on les ports usb et le PC qui suivent, implémentation en C++, j'analysais tous les points avec openCV).

Sauf qu'aujourd'hui, j'aimerai concevoir un système beaucoup plus performant -> Identification des points (D'où mon besoin d'un framerate extrêmement élevé (4000Hz), les leds seront synchronisé et allumés à tour de rôle par RF, donc plus il y aura de leds moins le framerate final de l'application sera élevé, ça dépendra des configurations), une grosse résolution (5000 / 5000 natif), pas de traitement PC (Ou minime, en tout cas ce sera toujours moins que d'analyser une image entière), possibilité d'interfacer une vingtaine de caméra (Pour les premier prototypes, ce sera 4) sur un seul PC...

Voilà

[inviteaca451ba]

OK je vois que tu sais où tu vas
Pour l'optique, peut-être une lentille cylindrique devant chaque capteur, mais ça n'est qu'une supposition ...

[invite8f57f819]

Salut,
Pour la partie optique, Il faut dimensionner l'objectif principal à partir du champ à couvrir.
Ensuite tu peux partager le faisceau via un cube séparateur qui créer l'axe Hz et Vert.
Attention à la formation de l'image dans l'axe ortho au CCD il faut qu'ellle soit largement plus grande que la hauteur pxl.
pour ne pas être trop sensible au mouvement. Sinon utilise une lentille Cylindrique pour créer une tache elliptique.

[inviteaca451ba]

T'aurais un schéma ou des liens pour le montage avec cube séparateur?

[invite1632952d]

Ça m’intéresse aussi, merci !

[invite1632952d]

Petite update du projet, que j'avais mis en pause suite à des résultats complètement incohérent d'un vieil oscilloscope analogique (Qui n'était pas assez rapide ?), j'ai testé sur un oscilloscope numérique récent d'une école d'un pote et là miracle, exactement le bon résultat à la sortie du capteur, les drivers et mon code FPGA fonctionne

J'ai finalement décidé d'utiliser un ADC (ads825) 10 bits, j'attends le PCB d'expérimentation et je soude tout ça (Du SSOP, ça va être coton). Du côté optique, je n'ai toujours pas trouvé de solution (Du moins pas de solution low cost), voilà mes résultats de recherche, si quelqu'un a des idées, ou des fournisseurs...

Pour revenir à l'électronique, je me pose quelques questions à propos de la communication avec le serveur qui sera en RJ45. J'ai trouvé ça :

http://www.fpga4fun.com/10BASE-T0.html

Directement à partir du FPGA, mais apparemment, quelque chose comme ça http://www.futurlec.com/Mini_Ethernet.shtml serait plus performant (En terme de vérification de paquet envoyé, etc). Et c'est là que je commence un peu à sombrer, la programmation pour le FPGA est quand même plus obscure qu'un bon vieux petit microcontroleur, je pensais peut-être à en interfacer un avec le FPGA, qu'en pensez-vous ? A condition bien sûr que je ne perde pas trop de " temps " en communication (Capteur -> ADC -> FPGA -(SPI)> Microcontroleur -> Ethernet -> Serveur). Ce serait uniquement par facilité de programmation (Librairie Ethernet déjà toute faite, plus simple d'implémenter le choix d'IP dynamique). Et puis par la suite, il est probable que chaque caméra dispose de deux ports ethernet (Les modèles pros ont cette fonctionnalité), pour pouvoir connecter par exemple 4 caméras en série à un seul port ethernet du serveur, voilà pourquoi le code sous FPGA me fait un peu peur...

Merci d'avance pour vos suggestions