Adafruit 9685 pouvoir positionner le servo en degré

[bruno71]

Bonjour

suite à un projet de facetracking avec reconnaissance faciale et un couplage à jarvis pour la synthèse vocale et la reconnaissance vocale
cela devrait être sympa de suivre quelqu'un qui rentre dans la pièce et l'identifie, lui rappel les choses prévue de la journée etc ...

bref coté jarvis, cela fonctionne bien et la reconnaissance vocale aussi.
coté tracking, la gestion des servos est à la base un projet qui avait été reéalisé avec servoblaster ( avec commande servo(numservo, angle) .. qui, utilisant les gpios du pi et de ce fait avec la reconnaissance faciale en même temps sature les traitements et rends les mouvements des servos super lents.

après avoir bien exploré le net, je n'ai pas trouvé le moyen de positionner mes servos avec un angle précis sous python avec l'adafruit 9685
il y a bien des solutions, mais ils utilisent un arduino à la place de l'Adafruit et pour des raisons de simplicité n'utiliser que le Pi et le 9685, la librairie pour arduino a fonction "map" qui fait la conversion pulse, dégré en fonction des servomin et servomax

si cela existe en c pour l'arduino,je n'arrive pas à croire qu'il n'y a rien en python !!! c'est fou ça !

est ce que quelqu'un aurait la formule de conversion qui va bien et qui me simplifierai grandement la tâche.

d'avance merci à vous amis bricoleurs

Bruno

[swisscore]

Tu as pas meilleur temps d'utiliser un moteur pas à pas ? avec cela tu sais que un pas = x° et tu peux y aller comme ça

Sauf erreur la gestion du moteur pas à pas se fait tout part soft, avec un interface de puissance entre deux selon le moteur que tu as (un simple ULN2003 pour les plus petits)

[spourre]

Tu as pas meilleur temps d'utiliser un moteur pas à pas ? avec cela tu sais que un pas = x° et tu peux y aller comme ça

Sauf erreur la gestion du moteur pas à pas se fait tout part soft, avec un interface de puissance entre deux selon le moteur que tu as (un simple ULN2003 pour les plus petits)

AMHA, ça sera encore pire. je peux me tromper mais les symptômes décrits me font irrésistiblement penser à une "surcharge" du CPU du Raspberry.
Je ne connais pas le logiciel de reconnaissance faciale utilisé (ça m'intéresse pour un projet en cours de cogitation) mais, pour ce que j'en sais, ça consomme pas mal de temps CPU.

Comme l'auteur ne jure que par le python (langage interprété) qu'il veux piloter ses servomoteurs aussi avec le même (piteux) python et que, de plus, Linux n'est pas (et ne revendique pas) être "temps réel", cela n'a rien de surprenant (le Raspberry donne l’ordre quand il peut).

Le choix de la carte d'Adafruit n'est pas un mauvais choix car cette carte possède sa propre horloge (donc les signaux sont plus précis ) et ne demande du Raspberry qu'un ordre de mouvement (le Raspberry est déchargé de la génération du signal de commande).

Si vous prenez des moteurs pas-à-pas et que vous confiez au Raspberry le soin de les piloter par soft, le pauvre va être encore plus sollicité.
Je ne vois que 2 solutions pour améliore les performances (en gardant le Raspberry et la carte Adafruit:

1) Porter un maximum de ces logiciels vers un langage compilé (genre C ou C++).
2) Utiliser les extensions "temps réel" de Linux.

Aucune de ces solutions n'est triviale et comme le PO demande une solution "Python" et que je n'en connais pas, je ne suis donc pas intervenu directement.

Sylvain

[destroyedlolo]

Salut,

AMHA, ça sera encore pire. je peux me tromper mais les symptômes décrits me font irrésistiblement penser à une "surcharge" du CPU du Raspberry.

En fait non, car controler moteur classique se fait par une base de temps (pendant x uSeconde il tourne) alors que le moteur pas-a-pas se controle par la position (il tourne dans le sens x d'un cran et se stabilise à la dite position jusqu’à l'ordre suivant). Donc un moteur pas-a-pas reste précis même si les timings sont pourris mais à l'inconvénient d'avoir une vitesse maxi plus réduite.

Linux n'est pas (et ne revendique pas) être "temps réel", cela n'a rien de surprenant (le Raspberry donne l’ordre quand il peut).

• Il y a des options RT dans le kernel qui améliorent les choses (j'ai vu après coup que tu en parle aussi )
• si tu met une priorité inférieur au logiciel de reconnaissance, tu gagnera en réactivité sur le soft de controle du moteur (même s'il ne sera jamais aussi précis qu'un moteur pas à pas)
• il me semble qu'en jouant avec les cgroups, il est possible de restreindra la reconnaissance sur 3 coeurs et réserver le 4e pour le temps réel ... jamais essayé car je trouve ca vraiment très crade.
• en dernier ressort, est encore plus crade, il est possible de créer un module kernel et dans ce cas, tu ne dépend plus de la charge CPU.

1) Porter un maximum de ces logiciels vers un langage compilé (genre C ou C++).

Même si je suis un fervent défenseurs du C(++) et des langages compilés pour des raisons évidentes de perf, je pense qu'ici ca ne suffira pas : la reconnaissance faciale est TRES gourmande en calcul flottants et/ou matriciels et le CPU doit etre maltraité par d'incessantes IRQ venant de ses FPU donc ca ne changera pas grand chose.

Je partirai donc plus vers du pas à pas.

A+

[bruno71]

Merci pour vos avis
Si j'utilise python c'est simplement parce que la plupart des exemples trouvables sont en python, et que je n'ai pas les compétences pour coder en c.
Cela fonctionne très mal côté mouvements car des variables sont tronquées .pour faire fonctionner le code, j'ai remplacé servo blaster dans les codes par une fonction grossière utilisant le 9685 d'Adafruit mais j'ai l'impression que vu que le cpu est à 25% donc un coeur.donc le code pousse le cpu à 100%

Les seuls codes ou les déplacements du pan tilt sont super rapide sont ceux dont les détections faciales sont calculée par le pc.
Côté logiciel, opencv est utilisé dans mon cas sur le pi3.


Je continue mes recherches et vous tiendrai au courant et merci pour vos avis

A bientôt.

[spourre]

Salut,

AMHA, ça sera encore pire. je peux me tromper mais les symptômes décrits me font irrésistiblement penser à une "surcharge" du CPU du Raspberry.

En fait non, car controler moteur classique se fait par une base de temps (pendant x uSeconde il tourne) alors que le moteur pas-a-pas se controle par la position (il tourne dans le sens x d'un cran et se stabilise à la dite position jusqu’à l'ordre suivant). Donc un moteur pas-a-pas reste précis même si les timings sont pourris mais à l'inconvénient d'avoir une vitesse maxi plus réduite.
....

[*]si tu met une priorité inférieur au logiciel de reconnaissance, tu gagnera en réactivité sur le soft de controle du moteur (même s'il ne sera jamais aussi précis qu'un moteur pas à pas)
...

1) Porter un maximum de ces logiciels vers un langage compilé (genre C ou C++).

Même si je suis un fervent défenseurs du C(++) et des langages compilés pour des raisons évidentes de perf, je pense qu'ici ca ne suffira pas : la reconnaissance faciale est TRES gourmande en calcul flottants et/ou matriciels et le CPU doit etre maltraité par d'incessantes IRQ venant de ses FPU donc ca ne changera pas grand chose.

Je partirai donc plus vers du pas à pas.

A+

Salut,

Déjà, on a bien la même analyse du problème (surcharge CPU par la reconnaissance faciale).
Par contre, on diverge sur 2 points:
-) servomoteur (SV) versus moteur pas à pas (PAP)
-) compilé versus interprété.

Je te rappelle que je répondais à la proposition de swisscore:

Tu as pas meilleur temps d'utiliser un moteur pas à pas ? avec cela tu sais que un pas = x° et tu peux y aller comme ça

Sauf erreur la gestion du moteur pas à pas se fait tout part soft, avec un interface de puissance entre deux selon le moteur que tu as (un simple ULN2003 pour les plus petits)

qui propose donc de supprimer la carte Adafruit et de piloter les moteurs PAP par soft, avec juste une interface de puissance, par les GPIO.
Tu noteras au passage que personne n'a mentionner les moteurs "conventionnels" puisque le PO parle de servos et swisscore de PAP.

Le moteur PAP même le plus simple (2 phases) et même sans chercher la précision des dem-pas, demande de respecter une chronologie précise pour avancer.
Il doit aussi être associé soit à un capteur de position, soit à une séquence d'initialisation, sinon, même en comptant les pas et même en postulant l'absence de glissement ou de patinage dans la chaîne cinématique, le programme ne connaîtra pas la position.
Je ne suis pas du tout convaincu que cela soit plus "léger" à gérer pour le Raspberry que d'écrire une poignée d'octets sur le bus I2C et de laisser la carte Adafruit piloter les servos.

Quant au dernier passage, surtout venant de quelqu'un qui se présente comme un ardent défenseur du C(++), il me laisse perplexe.
Je ne vois vois qu'un binaire compilé (multithreadé + interruption) pour satisfaire ce niveau d’exigence sur le temps de réponse.
Parce que même si ça ne suffit pas compte tenu de la charge CPU des algo de reconnaissance faciale, ça me semble quand même la première étape avant d'envisager un passage a un RTOS:

https://en.wikipedia.org/wiki/RTLinux
https://www.blaess.fr/christophe/2016/0 ... erry-pi-2/

Je ne vois vois qu'un binaire compilé (multithreadé + interruption) pour satisfaire ce niveau d’exigence sur le temps de réponse.

Sylvain

[spourre]

Merci pour vos avis
Si j'utilise python c'est simplement parce que la plupart des exemples trouvables sont en python, et que je n'ai pas les compétences pour coder en c.
...
Les seuls codes ou les déplacements du pan tilt sont super rapide sont ceux dont les détections faciales sont calculée par le pc.
Côté logiciel, opencv est utilisé dans mon cas sur le pi3.


Je continue mes recherches et vous tiendrai au courant et merci pour vos avis

A bientôt.

Bonsoir,
A aucun moment je n'ai critiqué votre choix du python mais comme je n'avais pas de solution répondant à votre question, je ne suis pas intervenu directement.
Que cela fonctionne bien sur un vrai PC (architecture Intel ou AMD), ne me surprend pas.
C'est une solution souvent adoptée pour ne pas devoir gérer les contraintes du "temps réel". On prend une machine surpuissante, on n'optimise rien, et on fait le pari que les délais de traitement seront compatibles . Parfois ça fonctionne.
Le problème est que le Raspberry (fusse le PI 3) n’est pas un PC comme la communication (mensongère) de la fondation voudrait le laisser croire. Il a la puissance d'un smartphone basique ce qui n'a rien à voir avec un I3, 4 ou 5.

OpenCV est une bibliothèque avec des API (interfaces) vers Python, C, C++. Avez-vous développé le programme de reconnaissance faciale ?
(moi, j'aimerai bien pouvoir reconnaître la présence de pigeons (rats volants) sur mon balcon).

Bonne chance pour vos recherches

Sylvain

[destroyedlolo]

Salut,

La seule et unique chose que je disais, c'est que même si le passage en compilé ne peut qu'améliorer les perfs (et encore, ca dépend surtout du ratio du temps passé dans les parties bytecode par rapport à celui passé dans les librairies qui sont elles déjà en binaire natif), il reste peu probable (conditionnel) qu'on arrive pas au niveau de perfs attendues du fait charge FPU et vectoriel engagées.

De plus, avec des grosses charges de calculs, il faut s'assurer de la température du CPU et qu'il ne réduise pas ses propres perfs pour rester dans sa zone de sécurité.

[bruno71]

Merci pour vos avis
Si j'utilise python c'est simplement parce que la plupart des exemples trouvables sont en python, et que je n'ai pas les compétences pour coder en c.
...
Les seuls codes ou les déplacements du pan tilt sont super rapide sont ceux dont les détections faciales sont calculée par le pc.
Côté logiciel, opencv est utilisé dans mon cas sur le pi3.


Je continue mes recherches et vous tiendrai au courant et merci pour vos avis

A bientôt.

Bonsoir,
A aucun moment je n'ai critiqué votre choix du python mais comme je n'avais pas de solution répondant à votre question, je ne suis pas intervenu directement.
Que cela fonctionne bien sur un vrai PC (architecture Intel ou AMD), ne me surprend pas.
C'est une solution souvent adoptée pour ne pas devoir gérer les contraintes du "temps réel". On prend une machine surpuissante, on n'optimise rien, et on fait le pari que les délais de traitement seront compatibles . Parfois ça fonctionne.
Le problème est que le Raspberry (fusse le PI 3) n’est pas un PC comme la communication (mensongère) de la fondation voudrait le laisser croire. Il a la puissance d'un smartphone basique ce qui n'a rien à voir avec un I3, 4 ou 5.

OpenCV est une bibliothèque avec des API (interfaces) vers Python, C, C++. Avez-vous développé le programme de reconnaissance faciale ?
(moi, j'aimerai bien pouvoir reconnaître la présence de pigeons (rats volants) sur mon balcon).

Bonne chance pour vos recherches

Sylvain

Bonsoir Sylvain
pas de soucis pour le remarque sur le langage... , je ne me suis pas senti offensé car je suis conscient de mes limites en programmation.
chacun à ses points forts et sur d'autres points ou on s'arrange comme on peut (on se rattrape au branches comme ont dit ... )
Pour la présence de pigeons, la détection de formes, d'objets est assez performante avec un peu de code comme le lien cité ci dessous. allez sur Github pour récupérer le code et l'éditer... ça donne une bonne idée
le gars l'a fait pour des souris...après il faut adapter par rapport au projet final... photo du pigeon ou distributeur de coup de pied au c...

Github:
https://github.com/colinlaney/animal-tracking

vidéo:
https://www.youtube.com/watch?v=GebcshN4OdE

à bientôt
Bruno

[spourre]

Bonsoir Bruno,

Merci pour les liens, je vais creuser ça à tête reposée.
C'est un projet qui "mûrit", en background.
Ici, nous sommes envahis de pigeons sur les 2 balcons. C’est une horreur et pas grand chose les effarouche.
Même en étant présent sur le balcon, au moment de la nidification, il n'est pas rare d'en trouver en train d'apporter des brindilles sous la table du salon de jardin.
Il faut vraiment foncer dessus et claquer dans les mains pour les faire déguerpir.
Quand j'habitais encore chez mon chat, alors qu'il se prélassait sur son fauteuil, ils venaient bouffer ses croquettes. On a même trouvé un œuf et plus tard un pigeon dans sa caisse (avec une porte à bascule). Si on s'absente un peu, au retour on trouve le balcon squatté et recouvert de fientes, de plus, il font un baroufle du diable en roucoulant. Mais on a pas le droit de les tirer (même au plomb ou de les empoisonner (en plus ils crèvent dans des endroits pas possible et ça pue et attire les mouches).
L’idée qui me trotte dans la tête et qui me permettrait de "justifier" mes achats auprès de mon ministre des finances, est de faire un petit robot qui reconnaîtrait la présence du pigeon (pas des mésanges qui ont un nichoir) pour les éloigner soit par un bruit, soit par un tir laser (pointeur faible puissance). et qui reviendrait à la niche, pour se recharger (comme les aspirateurs robot).
Au vu des problèmes de charge CPU que vous mentionnez, je me doute que mon pauvre B+ ne suffira pas.

Cordialement

Sylvain