Evitement/Odométrie par caméra

[joubinours]

Bonjour les robots !

L'an passé, avec Projet Tech Legacy, on a essayé de faire un système d'évitement/odométrie par caméra. On a un premier démonstrateur que l'on a pu embarquer dans un robot à la coupe ( et qui a permis de nous homologuer) ! Rien de bien novateur, si ce n'est l'assemblage d'outils déjà existants, tout ça dans le but d'améliorer la fonction de perception de l'environnement du robot.

En PJ la présentation du projet, on espère que ça pourra vous inspirer

Les codes seront bientôt sur notre Git, le lien sera fournit bientôt.

Toute remarque, question, idée est la bienvenue !


+<3

Joub'

[arno]

Toute remarque, question, idée est la bienvenue !

Merci pour cette présentation, le sujet est très intéressant, et vos résultats très encourageants !
Je ne suis pas capable d'en faire un dixième sur le traitement vidéo donc je ne peux qu'applaudir et difficilement ajouter des idées...

En revanche, plus dans mon domaine, concernant la page (26) "prototype", il semblerait plus pratique d'utiliser SystemD qui est justement prévu pour gérer les services tels que celui ci et éviter les "kill" à la main, mais plutôt passer par un "systemctl stop evitement"/"systemctl start evitement". Si ça peux vous intéresser, il s'agirait de faire quelque chose comme dans cet exemple : https://forum.odroid.com/viewtopic.php? ... 20#p201384

Sinon, en page 24, vous présentez une image contenant une fenetre graphique d'openCV. Est ce que cela était fait juste pour illustration, ou est-ce que le programme tourne réellement avec une fenetre graphique en temps normal ? Avez vous essayé de ne pas afficher cette fenêtre et de garder un programme fonctionnant en console seulement, pour voir si il y a un potentiel gain de performances ?

[joubinours]

Salut

Merci pour ton retour ! Je ne connaissais pas système D personnellement, je vais essayer, ça a l'air en effet un peu plus adapté. J'ai l'impression que l'on peut surveiller le service et le relancer si il plante, ce qui m'intéresse

L'affichage opencv prend du temps, mais aussi le partage de bureau (la RP3 gère un serveur vnc).
Pour le moment, l'évitement est calculé à plus de 10Hz avec ces services parasites. Si on veut passer à deux caméras pour avoir tout le champs autour du robot en visuel, ou embarquer plus de traitement d'image, le temps de calcul va commencer à poser probleme. Mais je n'ai pas mesuré l'impact en temps des affichages.
De plus, il faut savoir que les images sont sauvegardées pour rejeu de l'algo apres le match.

À approfondir donc ...

J'espère avoir répondu à ta question

[arno]

J'espère avoir répondu à ta question

Parfaitement, merci
Ca veut dire que si vous aviez besoin de monter un peu la résolution (comme sous-entendu page 24), il y a un potentiel de garder plus ou moins les mêmes fréquences de rafraîchissement, en optimisant le système.

Sinon, je repense à un truc, lorsqu'on avait nous même fait quelques tests avec une webcam, il y a "quelques" années (2012 ?) : dès que le robot était en mouvement, les images devenaient vite floues. Le pire étant bien entendu en virage, où en moins d'une seconde, on peut faire un tour sur soi même.
Avez vous une caméra qui a un temps de pose suffisamment réduit pour limiter ce phénomène (notre webcam était particulièrement pourrie, et loin des perfo des capteurs actuels) ? Ou avez vous mis en place des limitations pour ne pas traiter les images pendant les virages ou autres opérations trop rapide ?

Et pour systemD, il y a moment d’aller très loin, jusqu'au démarrage automatique de services lorsqu'une connexion à un port est demandée... En tout cas, pour des usages simples comme le votre, ça devrait parfaitement répondre à votre besoin. Il faut juste comprendre que start/stop concerne la session en cours (donc appliqué en live), et que enable/disable concerne le démarrage automatique au prochain reboot (indépendant de start/stop donc).

[joubinours]

Coucou

Le problème de la WebCam, c'est qu'elle passe par le bus USB (2 à l'époque ?), qui est plutôt lent par rapport au bus de la RP3 qui est MIPI_CSI2 (cf PJ).
Avec ce bus, qui est issu du monde du téléphone (où justement il ne faut pas que les vidéo aient trop de flou de bougé), le débit est bien plus important ce qui permet d'augmenter la fréquence d'acquisition.

La question reste aussi : a-t-on besoin de l'évitement quand on tourne sur soi-même ?

J'essaye systême D !!!

[arno]

Le problème de la WebCam, c'est qu'elle passe par le bus USB (2 à l'époque ?), qui est plutôt lent par rapport au bus de la RP3 qui est MIPI_CSI2 (cf PJ).
Avec ce bus, qui est issu du monde du téléphone (où justement il ne faut pas que les vidéo aient trop de flou de bougé), le débit est bien plus important ce qui permet d'augmenter la fréquence d'acquisition.

J’espérais aussi que ça soit bien mieux que ce qu'on avait testé !

La question reste aussi : a-t-on besoin de l'évitement quand on tourne sur soi-même ?

Techniquement, si la caméra est trop limitée, le flou est toujours présent dans une certaine mesure (à cause des vibrations, transferts de poids avants/arrière, le fait que le robot sur lequel est la cible bouge aussi...), c'est juste que c'est extrêmement marqué dans les virages.

[joubinours]

Salut arno,

Désolé pour le temps de réponse

Effectivement, ce flou pose problème lorsque la vitesse relative de la cible est trop grande. Après, on reste avec un imager qui est vraiment élémentaire et "vieux" : le temps d'intégration est "long",et le rapport signal sur bruit, médiocre. Surtout par rapport à l'état de l'art des imagers actuels.

Le module caméra coutant 25 euros, je pense que l'objectif représente bien 2/3 du prix du module. Pour une caméra, qui est un capteur assez complexe au final, on est clairement sur une solution ultra low cost. Il y a moyen d'investir dans un capteur performant, qui éliminera facilement ce problème.

[william25]

Salut arno,

Désolé pour le temps de réponse

Effectivement, ce flou pose problème lorsque la vitesse relative de la cible est trop grande. Après, on reste avec un imager qui est vraiment élémentaire et "vieux" : le temps d'intégration est "long",et le rapport signal sur bruit, médiocre. Surtout par rapport à l'état de l'art des imagers actuels.

Le module caméra coutant 25 euros, je pense que l'objectif représente bien 2/3 du prix du module. Pour une caméra, qui est un capteur assez complexe au final, on est clairement sur une solution ultra low cost. Il y a moyen d'investir dans un capteur performant, qui éliminera facilement ce problème.

Ouais mais un capteur performant ça monte à combien?