Bonjour à tous!

Voilà, je souhaiterai refaire une pseudo souris optique. L'idée, c'est d'utiliser une caméra, et de faire du traitement de l'image pour en déduire le déplacement de l'élément centrale, et donc déduire la vitesse de la caméra(associée à un télémètre). c'est pour recaler les vitesses dans un asservissement.
Bon, si on me donne tout le travail tout fait, je dis pas non, cependant, je pense pas que ça le soit. mais vous semblez très bien vous y connaitre dans le domaine. J'aimerai donc vous demander conseil:qu'utiliseriez pour faire ce projet?
fpga?µc?PC embarqué? un os? lequel? quelle fréquence minimum? quel langage? des librairies conseillées? quel type de caméra?..
Pour le moment, je sais ce que je veux, mais je ne sais presque pas comment. Mais je sais que je pourrai m'adapter à la meilleur solution^^

salut l'ami H0x7d0 !

ton projet tel que tu le decris ressemble etrangement à l'ancetre du pointeur des interfaces graphiques modernes ayant adopté depuis lors la souris...
il s'agirait d'apres ce que j'avais lu , des recherches qui etaient faites il y a fort longtemps (puis au centre PARC de Xeros entre-autres qui avait débouché sur leur ordinateur ALTO de 1973/74)

je n'ai pas trouvé les liens à ce sujet, mais j'avais du lire ça dans un livre traçant l'historique d'apple...
c'etais juste pour souligner que comme c'est une vieille histoire, en cherchant bien, on devrait pouvoir trouver des algorithmes.
c'etait une camera ou plusieurs observant l'index d'une personne qui pointait vers un ecran geant, dans lequel on voyait la fameuse fleche de la souris qui se recalait toujours en plein dans la ligne de mire de l'index... (enfin, il me semble avoir lu quelque chose d'approchant...)

------

au sujet de la caméra , ma petite analyse me conduirait vers l'emploi d'une camera dédié au sport pour la rapidité, la stabilité et la qualité de l'image.


-----

pour les librairies , ce que j'ai lu ici meme, c'est que en openGL tu devrais trouver une foule de trucs interessants, à ce sujet.

------

regardes à tout hasard dans l'acquisition optique de mouvements
par exemple

-
phil

Merci beaucoup de ta réponse
C'est vrai que ça fait un baille que je ne suis pas venu^^
( oui, les humanoïdes ne servent toujours à rien héhé )


Le soucis, c'est le temps de compression/décompression. C'est soit une usb, auquel cas l'image n'est pas compressée il me semble, et a marcherai avec un pc embarqué(j'ai pas envie de me casser la tête à faire un pilote webcam pour µc). Il y a aussi des caméras qui envoient directement du RGB en numérique, et derrière, il faudrait alors un fpga/mµ pour recueillir et traiter l'info. Et je sais quels sont les bonnes caméras pour avoir le moins de parasites possibles sur l'image.

Le projet, c'est moins de comprendre un monde qui bouge, que decomprendre le mouvement sur un monde qui stagne. Donc en fait, je me suis souvenu de cybrina(orthographe?) qui, je je me souviens bien de la japan expo, peut voire l'environnement en 3d. Elle peut ainsi détecter des objets, et donner leur distance.
Pour cela, il faut 2webcam(facile!), et traiter l'image pour: détecter des similitudes, et déterminer la différence entre les deux. Pour Cybrina(orthographe), cette différence permet de détecter des distances.
Dans mon cas, un algorithme très similaire permettrai de prendre une image, prendre la suivante, comparer les 2, et voire la distance parcourue. Je n'ai pas besoin de quelque chose de très rapide, ce système servirait juste à recaler les vitesse déterminées pas intégration d'accéléromètres.
donc en fait, tout mon travail est presque déjà fait, mais par contre, je ne sais pas comment vous l'avez fait, ce que vous en pensez(si maintenant que c'est fait, vous imaginez de meilleurs solutions)...

ps: oui, c'est là honte, toutes ces questions pour quelqu'un qui travaille sur des chipsets vidéo...

pour les objets,je pense que deux webcam pour detecter l'objet et un télémetre orientable devrait faire l'affaire
sinon,avec une référence,tu peux peut etre te servir des paralaxes non?

merci de ta réponse

Je vois pas à quoi me servent 2 caméras: il me faut dériver le mouvement, donc connaitre le mouvement. pour ça, une caméra suffit. Il me suffit de connaitre la "parallaxe" entre 2 images consécutives(avec bel et bien un télémètre) pour connaitre la vitesse du système. Mais mon souci, c'est comment je l'obtiens, cette parallaxe, et la question la plus urgente, c'est quel est le matériel le mieux adapté pour connaitre ça

Au cas où ça peut te donner des idées voici le coeur d'une souris :

http://www.farnell.com/datasheets/30596.pdf

Tu met un téléobjectif devant et c'est bon

pas bête du tout le télé-objectif, c'est vrai qu'il faut que l'angle de vue soit très faible
Et le datasheet assez "amusant sur la fin", mais a n'explique pas leur algorithme pour détecter du mouvement...
Par contre, ST en font aussi(avec des datasheets publiques 3x moins remplies(mais faut voire la taille des documents qu'on a en interne^^)) Je vais certainement me renseigner à mon boulot leurs idées, et éventuellement prendre contacte avec les équipes s'occupant de ces chips.
Par contre, je reste ouvert à toutes vos idées

salut vous, ..... et toi..oui, toi , dans le fond! (héhé)


@Thot : P*t* la vache ! je ne connaissais pas ce type de composant tout prêt ! tu m'en bouches un coin, là... je me demande si on ne pourrait pas utiliser ça à d'autres fins , comme detecter un glissement entre une main artificielle et ce qu'elle touche..

@H0x7d0: désolé, plus le sujet est compris par moi, et donc plus il devient précis, et plus je me sens creux. alors plutot que de t'aiguiller vers des solution que je ne connais pas vraiment je te présente une petite gamberge improvisée, si à tout hazard ça peut te donner des idées:
puisque il s'agit d'une camera embarquée dans un robot mobile , tu fais une acquisition rythmée par des prises de vue successives (photos) séparées les unes des autres toujours par une meme durée d'intervalle. (on est bien d'accord que c'est simplement un fonctionnement normal d'une camera pendant un tournage).
donc si tu ne choisi de prendre que 2 images pour les comparer, tu te fiches pas mal du mouvement en fait. ça restreint comme tu dis l'analyse à une vulgaire comparaison pour en déduire les différences significatives premettant d'evaluer une vitesse de deplacement de l'ensemble de ce qui est obervé (le milieu dans lequel se meut le robot)
ce deplacement est codé "naturellement" entre ces 2 images, avant et apres en connaissant le temps écoulé entre les 2. il faut donc reconnaitre simplement le vecteur dans l'espace.
pour le moment je n'ai fait que redire ce que tu souhaites , à la maniere dont je le comprends.
-
alors mon idée c'est que pour chacun de ces 2 points de vue , il y a une meme chose obervée, mais avec des perspectives et une echelle differente à chacune des images (positions des points de fuites)
si tu isoles ces parametres, tu peux ensuites les oublier dans ta comparaison pour ne comparer que choses sans perspectives par exemple...ou peut etre le contraire.... c'est à dire ne comparer que les points de fuites...voir les principes de dessin en perspective...
regarde ça pour te donner une idée de ce que je veux dire:
http://dessin3d.canalblog.com/archives/perspective_oblique/index.html
http://dessin3d.canalblog.com/archives/perspective_aerienne/index.html

et regarde ça aussi : (comment faire une acquisition des points de fuite)
CORESA-PointsDeFuiteVersionFinale.pdf

phil.

Alors j'ai des infos. Déjà la filière de chez ST qui fait ça, elle est en train de mourir, on ne sait pas où ils sont.
Ensuite, comment ça marche le capteur: c'est de la simple corrélation entre 2 images, en verticale et en horizontale.
On a 2 matrices de pixels, pour 2 images successives. On additionne chaque lignes, sur chacune des 2 images, on a donc 2 tableaux à une dimension. On calcule le déphasage entre les 2 images, en testant la corrélation des tableaux pour chaque déphasages. Pour une valeur, la corrélation sera bien meilleur que les autres, ça donne le déplacement "vertical". On recommence avec l'horizontal.
Ce qui est génial, c'est que c'est un algo très régulier. le souci, c'est que ça marche moins bien quand le robot tourne(mais ça, il suffit d'une boussole). Avoir une grande résolution n'est donc pas utile(ni conseillée en fait^^).
niveau vitesse de calcul, si on utilise un matrice 100x100, il faut faire:
2*(100*100 additions) +100 corrélations(pour chacune 100 soustractions(pour la différence des tableaux), 100 additions(pour évaluer cette différence) et 100 comparaisons(pour trouver la comparaison la plus minime)),
donc 50 000 opérations environ, En codant ça mal, on atteint les 500 000, donc je pense qu'on peut inclure l'algo dans un pc embarqué, sans trop de problème(500k opération sur 400 000k opérations possibles à la seconde, ça devrait marcher )

Cette histoire de point de fuite, ça me semble très intéressant, mais mon cerveau n'est pas encore capable de tout bien comprendre. Va falloir que je lise, relise et laisse digérer^^

Je crois que c'est 2 méthodes complémentaire: moi ça marche bien avec des images "lointaines", pour avoir un fond "plat", alors que la tienne à besoin de volume. ta méthode me semble meilleur pour un robot, mais je peux pas l'appliquer^^(tant que mon cerveau ne l'aura pas digérée au moins^^)

Si on en met de chaque côté du centre de rotation d'un robot, on en déduit le déplacement de deux points périphériques... d'où la rotation du robot, si tu parlais de robot mobile à roues.

salut H0... etc... (Thot est inclus dans "etc.." héhé , ça veut dire EtCompagnie)

superchouette cette petite explication de detection de mouvement à partir de 2 images plates (sans perspectives).
avec ce principe, tu peux tester ton algo juste en baladant une petite fenetre sur ton ecran. pour voir si à tout hazard , ça detecte bien le bon vecteur.

mais alors , peut etre que avec un ecran de telephone mobile equipé de cam, on plaque sur l'ecran le circuit intégré de detection de mouvement (Agilent ADNS-2051 Optical Mouse Sensor), et le tour est joué ! ? non?
et peut meme avec 2 tel mobiles orientés dans 2 directions differentes (90° par exemple), on puissent en deduire la rotation du robot et sa translation....

sinon, au sujet des images avec des perspectives :
le principe est qu à partir d'une photo , tu parviennes à suivre toutes les lignes visibles, en les extrapolant. et ce afin de faire ressortir une ligne d'horizon et les points de fuites.
une fois que tu as obtenu ça, avec un algo du genre deformation photoshop en tirant sur les coins, je me dis que tu devrais pouvoir en quelque sorte transfomer cette image initialement en perspective en image sans perspective , tout à fait comme tu le souhaites pour ta methode. il suffit d'eloigner les points de fuite au maximum, et la deformation de l'image tendra à rendre quasi paralleles toutes les lignes xyz.
et ensuite, apres ça, il faut toutefois travailler sur l'echelle. pour faire coincider les 2 images au moins pour retrouver une meme zone.
c'est ça que je voulais dire quand je disais d'annuler les parametres des points de fuite...


phil

j'ai mieux encore , les mecs !
tu poses une souris optiqu sur l'ecran d'un telephone mobile pendant son affichage en mode cam.... et voilà !
bon, il faut essayer, pour voir si ça marche... qui a une souris optique? si j'en trouve une , je vous dis ça..

AArgh ! la vieille souris optique de l'imac de ma femme envoi un faiseau, alors peut etre que le capteur n'est reglé que sur cette lumiere là... zut ... je vais bien voir....


...
bon , b'en voilà, j'ai essayé avec cette vielle souris (elle a 10 ans) , et ça ne marche pas.
elle ne voit pas le contenu de l'ecran qui reste opaque pour elle..
en recouvrant la led, ça ne marche pas non plus, à moins que ce soit la lentille aussi à modifier.
mais je pense que cette souris est dans les cas mentionné dans la doc du CI (639 nm LED illuminator source) .... donc avec un ecran normal , ça ne marche pas! il faudrait presque que l'ecran soit en NB ou monochrome version 639nm...


phil

le coup du telephone, c'est exactement mon idée. un téléphone Androïd, avec donc caméra et boussole. Je me demande, si on peut pas détecter la rotation avec mon système en fait, il va falloir que je fasse des test lorsque j'aurai mis ça en place.

Sinon, mettre une souris sur un écran de téléphone, ça a trois énormes défauts: la sycro de la fréquence de l'écran et cellle de la souris,le capteur ne verra pas tout l'écran, si tu pose la souris dessus, ce sera certainement par bloc de 3x3 pixels, si tu recule, ne serait-ce que de 2mm ta souris, elle commence à voire flou. Et un dernier éventuel défaut, c'est que l'écran est actif, je suis pas sûr que la caméra marche bien en lui envoyant de la lumière.
Ah et les souris en tant que tel on un système ergonomique qui fait des calculs sur l'accélération pour que ça marche bien avec les hommes: sur ton ordinateur, lorsque tu bouges ta souris d'un point A à un point B, lorsque tu vas vite, la souris va plus loin que lorsque t'y vas doucement. Et ce calcul est fait au sein de la souris.
(raison pour laquelle il y a si peu de souris à la coupe de france de robotique, pour détecter la position absolue du robot)

Comme on m'a expliqué en cours avant hier, l'idée n'est pas mauvaise, il n'y a pas de mauvaise idée^^. Mais aujoud'hui, l'idée est moins adaptée que de faire le traitement via un téléphone quasiment fait pour.

pour ton histoire de point de fuite, j'avais compris ça autrement: comparaison de coordonnée de points de fuite. Si on a deux images décalée, le point de fuite sera décalé, mais sera théoriquement le même objet. et via ce décalage, connaitre le décalage du capteur (enfin décalage des 3 points de fuite)

La mon souci va devenir comment connecter le téléphone à d'autres contrôleurs. Je crois que ça va être la honte, mais le bluetooth sera certainement plus simple que l'usb^^^

L'usb est simple a utiliser. Il ne s'agit finallement de rien d'autre qu'un port COM. Et pui un bon fil, ça vaut toutes les hondes du monde

J'aimerai bien que ce soit aussi simple...j'ai commencé à lire un livre sur les pilotes sous linux, et ça m'a traumatisé. J'ai retenu que "printk"...
Par contre, on peut utiliser un microcontroleur comme "clé usb", en pointant sur des registres du contrôleur(pour éviter d'utiliser une mémoire supplémentaire)
mais c'est loin d'être utilisable tel quel^^...enfin pas à ma connaissance^^
mais +1 pour les fils. Je sais qu'on peut avoir de l'i2c et de l'uart sur le neo freerunner (que j'aurai utilisé s'il avait une caméra incluse), surtout que j'ai un ami qui bosse en interne dessus.

Je me suis un peu plus renseigné sur la liaison, et effectivement, avec les PICs par exemple, on peut avoir une pseudo liaison série. Sauf qu'il faut le pilote microchip sur le PC. Et mettre ce pilote sur téléphone, ou un OS bizarre c'est pas évident. Mais même si je le trouve pour android, l'usb sur téléphone n'est utilisable qu'en esclave. C'est absolument nul, mais bon...