Un "GPS" indoor par caméra

[jumab]

Salut tout le monde!

Je sais que les compétences sont variées sur ce forum, j'en profite donc pour partager avec vous un projet dans lequel je me lance, qui est plutôt au-delà de mes compétences actuelles, mais c'est tant mieux, j'aime bien apprendre sur du concret!

L'objectif à terme est de réaliser des salles de véhicules RC indoor, entièrement automatisées pour une mise à disposition du public 24h/24. (jeu en réseau local et/ou en ligne, suivant la capacité du réseau, fibre ou non)

Sur tous les points sensibles qu'il va me falloir traiter, il y en a un sur lequel je suis particulièrement débutant, c'est la reconnaissance d'images.

J'ai de nombreux critères techniques à définir, essentiellement au niveau matériel (le logiciel... c'est logique!), je vais donc poser mes différents points de réflexion ci-dessous, si jamais quelqu'un se sent de taille à m'aider... je suis preneur!

L'objectif est de géolocaliser, en 3D et avec une précision centimétrique, la position de tous les véhicules présents dans une salle, avec un certain nombre de caméras.
Premier point important, il faut pouvoir mettre beaucoup de caméras (au flair, au minimum une dizaine, pour une salle pas si grande que ça...), ce qui impose de conserver un coût par unité raisonnable.
Un impératif incontournable: viser une latence record. (si tout le process, jusqu'à la commande envoyée aux véhicules, prend plus de 150/200ms, c'est mort)


Les caméras:

Autant que possible, j'aimerais utiliser des caméras HD, à minima 1 280x720 pixels.
Les raisons sont évidentes, c'est ce qui amènera la précision du positionnement, je ne me suis pas encore lancé dans de trop fastidieux calculs, mais localiser de manière centimétrique un petit objet situé à plusieurs mètres me semble quasi-utopique avec une résolution plus faible. (peut-être qu'en rognant sur le champ de vision, c'est jouable, mais ça reste une solution de dépannage. J'ai en plus dans l'idée de pouvoir modéliser la carte des terrains avec les caméras, plus la résolution est grande, meilleur sera le rendu)

Il y a aussi la question du type de caméra à utiliser, dans mes recherches je suis notamment tombé sur des caméras sans filtres IR (pour la vision nocturne), je me demande s'il ne serait pas plus facile d'identifier une bonne led IR sur ce type de caméra (en environnement éclairé par lumière artificielle, on doit pouvoir prévoir un éclairage sans IR), qu'un code couleur quelconque avec une caméra classique.

Peut-être existe-t-il encore d'autres types de filtres/montages qui permettraient de simplifier la chose?

Sur le type de capteur, j'ai compris que les capteurs CCD sont meilleurs dans les environnements à faible luminosité, mais ils sont déjà chers dans les faibles résolutions, si je veux du HD à prix abordable il me semble que ce sera du CMOS (réflexion peut-être sans objet, si l'astuce de l'IR fonctionne)


Le traitement des données:

Là, ça se corse...

-Solution 1: je peux réfléchir très très longtemps pour monter un système assez costaud pour envoyer tous mes flux HD (au moins une dizaine!) sur une ou plusieurs grosses cartes graphiques, qui traiteront les données.

-Solution 2: je peux envisager de mettre un micro-contrôleur relativement puissant sur chacune des caméras, pour lui faire extraire uniquement les pixels qui nous intéressent, puis les envoyer rapidement à un pc central qui s'occupera de calculer la position finale des objets.

La solution 1 m'embêtes un peu, surtout parce que ça va certainement m'imposer d'aller acheter des équipements type "Rolls Royce du Réseau", que l'on va me faire payer un prix sans commune mesure avec la réalité du travail fourni...
De plus, un tel système sera probablement plus compliqué à configurer pour chaque nouveau circuit que la solution 2.

C'est pourquoi, dans la mesure du possible, j'aimerais m'orienter vers cette solution.
Du coup, ayant vu que la communauté Raspberry utilise une caméra HD avec un plutôt bon rapport qualité/prix, qui existe en plus en version sans filtre IR, cela me semble une bonne base de réflexion...

Reste à savoir si l'un des modèles de Raspberry serait à même de réaliser le traitement voulu dans le temps imparti, là il va falloir que je me penches de plus près sur le programme pour pouvoir calculer la chose, je me rapprocherais bien évidemment de la communauté Raspberry en temps voulu, si je bute sur des éléments plus techniques.

Voilà pour une entrée en matière, vous aurez compris que c'est un projet ambitieux qui va me prendre un moment et me faire emprunter de nombreux chemins, tous commentaires bienvenus, y compris ceux qui m'aideraient à ne pas me tromper de route!

[BlueDragon]

http://devernay.free.fr/publis/decrouez-rfia2012.pdf

[croco31]

@jumab:
"L'objectif est de géolocaliser, en 3D et avec une précision centimétrique, la position de tous les véhicules présents dans une salle, avec un certain nombre de caméras.
Premier point important, il faut pouvoir mettre beaucoup de caméras (au flair, au minimum une dizaine, pour une salle pas si grande que ça...), ce qui impose de conserver un coût par unité raisonnable.
Un impératif incontournable: viser une latence record. (si tout le process, jusqu'à la commande envoyée aux véhicules, prend plus de 150/200ms, c'est mort)"

Partir directement sur une solution caméra (en 3D en plus) me semble tendre vers un gros développement (au boulot j'ai déjà eu l'expérience de ce genre de problème en robotique) surtout avec des latences de 150ms.

Il faudrait quelques précisions supplémentaires pour voir si la solution "caméra" est la seule:
- quels types de véhicules ? Dimensions ? Vitesse de déplacement ?
- s'ils roulent au sol (à confirmer)  pourquoi 3D ? Car vouloir de la 3D implique de la stéréovision si usage seulement de caméras.
- taille de la salle et sa hauteur ? Cela conditionne les angles de vue des caméras.
- quid des problèmes de masquage des véhicules ? D'autres objets fixes dans la salle ?
- besoin de repérage individuel de chaque véhicule ?

Un peu plus de détails de ce problème aiderait.
Cordialement.

[jumab]

Hello croco31!

Alors, tous types de véhicules, de la voiture au drone, en passant par le bulldozer ou la motoneige!  
Les dimensions seront le plus petit possible, disons des véhicules d'environ 10x10cm. (sauf peut-être les bulldozers, mais c'est secondaire)
Vitesse de déplacement, je pars sur une base de 50km/h maxi, sachant que c'est une valeur que l'on atteindra seulement avec des très grands circuits, et que l'accélération maximale sera probablement un critère plus exigeant que la vitesse maxi (m'enfin, si on est capable de travailler à 30fps, ça ne devrait pas être un problème).

-Il y aura des drones, donc 3d.
-Taille de la salle, pas trop immense, je pars du principe que je n'aurais jamais un objet à plus de 3m de l'objectif, pour rester sur des caméras abordables.
-problèmes de masquages de véhicules: c'est pour ça que je veux pouvoir utiliser pleins de caméras pas chères, c'est pour multiplier les points de vues, pour avoir une redondance suffisante pour ne pas être embêté.

-besoin de repérage individuel des véhicules: oui, avec un petit peu de souplesse néanmoins, la localisation servira essentiellement à 2 applications:
1) conduire les véhicules en full auto, à vitesse lente, pour les ramener au garage entre chaque run, pour changer les batteries, puis les conduire à nouveau sur la grille de départ, alignés tout nickel.
2) vérifier en temps réel la position des véhicules contrôlés par les joueurs, afin d'implémenter des automatismes pour empêcher d'accéder à tel ou tel endroit.
Le principal objectif de cette 2eme fonction est de pouvoir interdire de manière au minimum approximative l'accès à certaines zones, par exemple pour empêcher les bulldozers d'aller faire mumuse dans le lac du décor...
Puis, si cette fonction est assez précise et rapide, on peut même imaginer limiter les accidents, en prévenant les crash contre les décors de manière logicielle.


Tu verrais un concurrent potentiel aux caméras?
Pour la latence, je suis volontairement un peu exigeant, il me semble que même si on avait 0.5s de latence on s'en sortirait pour les applications "basiques", mais c'est un peu dommage, ce sera lent et incompatible par nature avec la fonction "anti-accidents à haute vitesse".

Après, si tu as un peu d'expérience dans les caméras, tu pourras peut-être m'aider à y voir plus clair, je patauges un peu pour l'instant!

J'ai surtout du mal pour l'instant à faire mon choix au niveau du standard d'encodage vidéo sur lequel j'ai intérêt à travailler.
2 grandes familles, analogique ou numérique, pour l'instant j'ai beaucoup étudié la simplicité des normes analogiques (PAL surtout), l'avantage c'est que je vois très bien comment on pourrait faire les filtrages dont j'ai besoin, à une vitesse probablement rapide, l'inconvénient c'est que ces normes sont limitées en résolution, j'ai encore un peu de mal à comprendre mais il me semble qu'une caméra HD est tout simplement inexploitable sur ces normes, non? (question de nombre de pixels).
Les normes numériques HD quand à elles sont... trop nombreuses!
Quel bordel!
De plus la majorité d'entre elles introduisent des cycles de compression/décompression, ce qui amène de la latence en plus, c'est vraiment pas facile de s'y retrouver!

Il me semble maintenant évident que les normes numériques HD nécessiteront probablement un traitement sur des grosses bécanes, tandis qu'avec un bon vieux PAL je devrais pouvoir faire la majorité du tri sur des uC.

Bref, je continue de fouiller, je suis en train de lire un document intéressant sur le sujet pour ceux que ça intéresse: le signal vidéo analogique et numérique.

Ps: merci pour ce document intéressant BlueDragon, mais de loin bien plus compliqué que ce que j'ai en tête! ^^
Ps2: m'est venue une idée que je trouve géniale pour filtrer facilement et précisément un objet que l'on veut localiser: le blanc!
Un signal PAL code les couleurs de 0v=noir à 0.7v=blanc, le blanc plus que blanc est extrêmement rare dans un décor, une balle de ping pong blanche avec une ou plusieurs led super blanche dedans, un filtrage du signal en gommant tout ce qui est plus bas que 0.6**v, et le tour est joué!
Bien sûr, le même genre d'astuce doit se trouver facilement aussi en numérique, faut que je continue à comprendre les normes d'encodage...

[croco31]

Ouh là , c'est plutôt ambitieux comme projet

mais pas choquant il faut viser loin pour arriver à quelque chose (sauf si on s'épuise vers un objectif inatteignable).
Cela se fait dans les matches de foot, donc c'est faisable, mais avec des moyens importants je pense (je ne connais pas le détail).

Je pense que les caméras pas chères prévues risquent de ne pas être à la hauteur.

J'espère que tes compétences en électronique/informatique sont suffisantes, surtout en informatique/traitement d'image.

Quelques conseils:
- en utilisant du traitement d'image, il serait plus accessible de viser du pseudo-2D: des trucs qui se déplacent sur une surface plane. Un drone vu du haut semble aussi se déplacer en 2D et éventuellement une mesure de sa taille apparente pourrait donner son altitude.
Dans ce cas une grille de caméras en vue verticale au plafond de la salle pourrait couvrir tout le terrain, en le découpant en carrés plus petits, chacun étant traité par un processeur ou l'image étant envoyée à un serveur qui reconstruit la mosaïque complète (un PC puissant je pense). Le plan pixel reconstitué représente alors directement la surface.

- envisager d'utiliser des illuminateurs infrarouges IR et des pastilles réflectrices montées sur chaque véhicule. Ceci produira des points brillants facilement discriminés par seuillage de l'image. Cela peut marcher aussi avec des pastilles blanches très réflexives et des projos blancs dans le visible et travailler en Noir et Blanc dans ce cas. Des caméras pas chères voient l'infrarouge (j'en ai d'ailleurs une dans un nichoir à mésange). Eventuellement un réflecteur en tiret pourrait aider pour connaître l'orientation du véhicule si nécessaire, si la caméra donne assez de résolution pixel.