9 réponses à ce sujet

[soussou63]

Bonjour,

J'envisage un robot à base Rpi que j'ai déjà.
L'idée est de faire un quadripode qui serait autonome niveau déplacement avec une vision par camera.

Aprés un petit calcul rapide, il me faudrai 13 servos minimum (3 par patte et 1 pour la camera).
Le Rpi est il suffisant (moyennant un peu d'interfacage) pour commander autant de servos dans les deux sens de fonctionnement ?

La vision pourrait être assurée par une bête webcam d'occasion que j'ai branchée sur le Rpi en usb.
Néanmoins coté détection, je ne suis pas sur non plus des performances que l'on peut attendre.
J'ai testé la librairie OpenCV qui est trés prometteuse mais beaucoup trop lente en détection d'objet sur le Rpi (6 sec minimum pour passer tous les filtres). Avez vous d'autres idées sur les mécanismes de détection / analyse d'une image ?

(Le minimum serait la détection d'une couleur qui pourrait indiquer implicitement une direction).

L'autre question est le poids de la bete et l'architecture squelette, j'envisageai de faire les pattes en pate fimo mais j'ai peur que ca soit un peu lourd, sinon ca sera alu evidé (mais faudra que je trouve une fraiseuse ...)

Voila en gros l'idée du projet, les contraintes que j'ai identifié. J'attends vos points de vue sur le sujet.

Bonne journée

[NooTe]

Tu devrais ajouter un deuxième servo pour la camera et faire un tilt/pan (haut/bas +gauche/droite)
Pour un 'simple' filtre couleur openCV devrait s'en tiré assez bien, la détection de blob et de couleur sont facile a faire.
Si tu cherches une balle (un objet rond et de couleur uni ou presque ^^), une détection de cercle par algo de houth est aussi rapide (toujours avec opencv).
Malheureusement, le gros point faible de la RPI c'est le calcul en flottant (pas de vrai FPU... c'est simulé par le proc)
Mais il me semble aussi qu'opencv a ajouter les calculs par GPU... a voir

Par contre, prevoit aussi une carte d'IO special Servo... ou une arduino que tu contrôleras en port "software" serie : la rpi n'a que 12 ou 16 I/Os il me semble... et tu aura un problème pour alimenter tes 13/14 servos.

[modified]
Ah... j'ai dit une anerie il y a un fpu hardware sur le proc ! il faut juste penser a utiliser les bons paramétrages de compilation

[Mike118]

En tout cas je vais suivre de très près ce que tu fais ! J'espère qu'on pourra s'aider mutuelement car je souhaite moi aussi faire de l'open CV sur raspberry !

[soussou63]

Mais il me semble aussi qu'opencv a ajouter les calculs par GPU... a voir
Par contre, prevoit aussi une carte d'IO special Servo... ou une arduino que tu contrôleras en port "software" serie : la rpi n'a que 12 ou 16 I/Os il me semble... et tu aura un problème pour alimenter tes 13/14 servos.

La derniere raspbian inclue la gestion du FPU je crois.
Oui opencv 2.4 dispose d'optimisation GPU mais seulement une api cuda pour les GPU NVidia.
Concernant les servos oui que ce soit le Rpi ou l'arduino uno, il semblerai que le nombre de sortie numérique de base soit insuffisant par contre apparement certains pins (sorties analogiques par exemple) sont récupérables sur l'un comme sur l'autre.

Pour OpenCV l'une des contraintes est les perf du Rpi mais aussi le passage par l'USB de la vidéo décompressée (ce qui fait dans le meilleur des cas du 10Fps), quelqu'un connait il un moyen d'interfacer directement un capteur sans passer par l'USB ?

Coté électronique, je suis un peu a la ramasse au niveau commande des servos et j'aurai bien besoin d'un petit cours, d'éclaircissements sur les commandes etc. (des liens qui vont bien ??? )
Les servos se commandent par impulsions ok ... admettons un servo 5v, la position centrale est définie pour 0v ? Si oui quid de la position 'négative' et du retour a l'origine ?
Quel est l'intérêt du potentiomètre sur les servos hormis la détection (interne au servo) de fin de course ?

Bonne journée

[Mike118]

Coté électronique, je suis un peu a la ramasse au niveau commande des servos et j'aurai bien besoin d'un petit cours, d'éclaircissements sur les commandes etc. (des liens qui vont bien ??? )
Les servos se commandent par impulsions ok ... admettons un servo 5v, la position centrale est définie pour 0v ? Si oui quid de la position 'négative' et du retour a l'origine ?
Quel est l'intérêt du potentiomètre sur les servos hormis la détection (interne au servo) de fin de course ?

Bonne journée

En fait pour commander un servo tu envois un signal composées d'impulsions modulé en largueur. En théorie il faut envoyer un signal periodique de periode 20ms de temps haut compris entre 0.9 et 2.1 ms . Avec 0.9 correspondant à 0° et et 2.1 à 180°. En pratique, les servo n'étant pas parfait il faut jouer entre 0.6 et 2.6 a peu près j'en ai même un où les 180° s'atteigne avec un temps haut de 3,1ms ...

Le potentiomètre sur les servo permet la détection interne de la position du servo, cela sert pour la "boucle retour" car le système est asservis. Tu ne demande pas à un servo de s'ouvrir ou de se fermer un peu plus, tu lui demande d'aller exactement à une position donnée ! En fonction de sa position et de la position qui lui est demandé il bougera ou se maintiendra en position. Si tu envois un signal de temps haut nul : il ne bougera pas mais ne se maintiendra pas non plus en position !

J'espère que cela t'aura aidé ! à bientôt !

[soussou63]

Donc, si j'ai bien compris, 1 seul registre numérique est suffisant pour commander un servo dans toutes ses positions (en fonction du temps haut dans le signal généré).

Quelques informations supplémentaires :
http://hackaday.com/2012/08/18/an-adafruit-raspberry-pi-extravaganza/
Le RPi ne dispose que d'une sortie PWM, pour contrôler de nombreux servos, il faut comme pour l'arduino utiliser un driver du genre PCA9685 qui apporte 16 sorties PWM. Le driver est directement commandé via l'I2C.
Nous pouvons alors atteindre 16 servos commandés avec l'arduino / RPi et 1 driver. (via l'I2C ont pourrai apparemment cascader jusqu’à plus de 60 drivers).

[inovasong]

Bonjour,


Je vais suivre de pret ton travail car j'ai moi même commandé 2 RPI vB pour faire d'une part un ordinateur embarqué sur mon robot et d'autre part pour faire un serveur.
je ne sait plus où mais j'ai lu que MJPG-STREAMER pouvait envoyer de la vidéo en streaming a 25fps avec une charge CPU de 10%, donc pourquoi pas déporter le traitement de l'image sur un autre ordinateur ?

J'attend avec impatiente la suite de ton travail.

bon courage.

[soussou63]

Bonjour,


Je vais suivre de pret ton travail car j'ai moi même commandé 2 RPI vB pour faire d'une part un ordinateur embarqué sur mon robot et d'autre part pour faire un serveur.
je ne sait plus où mais j'ai lu que MJPG-STREAMER pouvait envoyer de la vidéo en streaming a 25fps avec une charge CPU de 10%, donc pourquoi pas déporter le traitement de l'image sur un autre ordinateur ?

J'attend avec impatiente la suite de ton travail.

bon courage.

Bonjour,

Ben nous sommes dans le même cas moi aussi j'ai commencé a m'interresser au Rpi pour la partie serveur.
En effet sur le RPi la solution la plus performante semble MJPG-STREAMER pour la capture vidéo. Mais pour la capture seulement lorsque la webcam utilise la compression sur USB.
Si tu dois capturer en raw pour faire du traitement d'image la bande passante usb est limite ...
Donc les autres idées étaient : caméra directement interfacée sans passer par l'usb (je n'ai aucune info la dessus) en gardant en tete que la puissance du Rpi est limite pour opencv ou comme tu le suggeres, de faire faire le traitement par une autre machine.
Dans le dernier cas, on perds le coté 'autonome' du robot, et on ajoute une charge supplémentaire niveau alimentation de l'engin avec le systeme de transmission (BT ou Wifi) à moins de garde un cable ethernet en "cordon ombilical' qui servirai a l'alimentation et au transfert de données (via un éclateur ou un injecteur poe).

[inovasong]

Bonjour,

Ben nous sommes dans le même cas /> moi aussi j'ai commencé a m'interresser au Rpi pour la partie serveur.
En effet sur le RPi la solution la plus performante semble MJPG-STREAMER pour la capture vidéo. Mais pour la capture seulement lorsque la webcam utilise la compression sur USB.
Si tu dois capturer en raw pour faire du traitement d'image la bande passante usb est limite ...
Donc les autres idées étaient : caméra directement interfacée sans passer par l'usb (je n'ai aucune info la dessus) en gardant en tete que la puissance du Rpi est limite pour opencv ou comme tu le suggeres, de faire faire le traitement par une autre machine.
Dans le dernier cas, on perds le coté 'autonome' du robot, et on ajoute une charge supplémentaire niveau alimentation de l'engin avec le systeme de transmission (BT ou Wifi) à moins de garde un cable ethernet en "cordon ombilical' qui servirai a l'alimentation et au transfert de données (via un éclateur ou un injecteur poe).

Ok je comprend bien le problème,

As tu creusé du coté de la nouvelle camera qui devrais sortir ce mois ci ou le mois prochain, pour la raspberry pi => clubic
peut etre un debut de solution je ne sait pas ?

[soussou63]

En fait le projet est a la base un projet pour un niveau lycée (bon avec des personnes très douées par contre) donc nous avons des contraintes de délais etc ...
De plus il faudra justifier de tous les choix et du fonctionnement de chaque partie. Il est donc délicat de réutiliser un framework ou toute autre architecture clé en main.
Je fais donc un appel aux habitués qui ont déjà eu ce genre de demandes, a quoi se limiter pour que le projet soit réalisable et que nous puissions bien expliquer les différentes parties convenablement.

Exemple, l'usage du Rpi implique l'explication du choix linux, du CLI, des notions réseau et terminal distant . . .

Edit : La caméra Rpi a l'air trés interressante !