Butées servo moteur

Bonsoir,
Je suis aussi preneur d’un décryptage!
Autre exemple extrait de InMoov3.Deep.AB.V7.py….encore plus mystérieux:
leftArm.omoplate.setMinMax(10,82)
leftArm.omoplate.map(0,180,36,135)

Yo !
setMinMax indique au servo de ne jamais franchir ces limites physiques
map va redéfinir des valeurs virtuelles au servo ( souvent calquées sur le setMinMax ) . Utile pour standardiser des positions, en attendant une méthode de standardisation par angle

Bonsoir,
La premiere méthode, c’est lorsque j’utilise InMoov01 qui est doté de servo Corona avec MRL version 107, C’était normalement la bonne méthode.
head.eyeX.setMinMax(0,180)
head.eyeX.map(0,180,60,110)

La deuxième méthode, c’était pour InMoov02(Deep), lorsque je testait, j’utilise des servo MG91, avec MRL version récente qui avait subi une refonte bizarre concernant les minmax et mapping
head.eyeX.setMinMax(60,110)
head.eyeX.map(0,180,60,110)

Enfin si c’est concernant mes scripts.
A savoir que InMoov02(Deep), c’est ma version beta.

la méthode servo.map(minInput, maxInput, maxInput, maxOutput) convertie un intervalle d’entrée (input) que l’on veut utiliser en valeur de sortie (output) qui sera envoyer au servo.

Il est inutile de faire un servo.setMinMax() puis la command servo.map() puisque servo.map() ecrasera la commande servo.setMinMax()

voici comment ca fonctionne sous le capot

par défault, il y a un map(0,180,0,180) qui est réglé pour le servo.
servo.setMinMax(60,110) reglera les valeurs de sortie(output), donc est l’équivalent a map(0,180,60,110)

il y a eu des changement dans le fonctionnement de map() entre la version 107 et les versions récente. Ce qui explique pourquoi la version pour inMoov01 était nécessaire. Mais dans les versions récente, seule une ou l’autre des commandes est nécessaire. Pour InMoov02, les deux commandes donne le meme résultat.

Gael utilise un range arbitraire de 0 (position minimal) a 180 (position maximal) qui sera converti (position minimal du servo) a (position maximal du servo).

Pour ma part, j’utilise un map différent. En entré, j’utilise l’angle que je souhaite avoir et en sortie, la position que le servo doit prendre pour atteindre cet angle. donc mes maps ressemble a ceci
shoulder.map(46,180,46,180) -> signifie que pour avoir un angle de 46°, le servo doit aller en position 46, mais aucune valeur inférieur a 46 ne sera accepté (min).
bicep.map(5,60,5,80) -> pour un angle de 5°, le servo va en position 5, pour un angle du coude de 60°, le servo doit aller en position 80.

Notez que mes map() ne permettent pas d’utiliser les gestures de gael sans modification. Je tente seulement d’illustrer le fonctionnement de la méthode map()

Hello,

Si cela peut vous aidez, je vous joint ma feuille excel gérant la conversion des valeures de Gaël vers les valeurs de mon InMoov (Airwin), les commandes pyton sont automatiquement calculées, il suffit de copier/coller le code colonne P et Q dans votre script Python InMoov3.Deep.AB.V7.py. En théorie vous devriez être proche à l’échelle de vos degrés de liberté des mouvements des gestures existants.

ATTENTION : la confiance n’excluant pas le contrôle… je vous invite à bien vérifiez les valeurs par rapport à vos InMoov, je décline toutes responsabilité de casse :-), je n’ai pas encore tout checké…

C’est une base à améliorer.

• This reply was modified 8 years ago by Sebastien.

Comme je comprends vite!
leftArm.omoplate.setMinMax(10,82)
leftArm.omoplate.map(0,180,36,135)

10 et 82 sont les limites min et max mécaniques du servo que je trouve en utilisant MRLServo que je ne dépasserais jamais en définissant setMinMax. Donc ici pour une variation de 0 à 180° du curseur le débattement du palonnier du servo sera de 72°…facile jusque là

Le “map”: 0,180 définissent un débattement virtuel de 180°….une échelle
Le “36”: écrase le min 10°. 36° est la position basse de l’épaule et dois-je en conclure que je n’utilise pas la plage 10-36°…(le bras rentrerai dans le corps)
Le “135”…. une erreur de frappe? sans importance puisque je ne dépasserai jamais 82°!
OU plus subtile, on redéfinit une échelle de 0 à 99 (135-36) dont j’ai du mal à comprendre l’intérêt/la relation avec les 72° de débattement mécanique.
comme Christian le montre bicep.map(5,60,5,80) -> pour un angle de 5°, le servo va en position 5, pour un angle du coude de 60°, le servo doit aller en position 80
ou extrait du tableau excell de Sébastien :leftArm.rotate.map(40,180,60,120) quel avantage de réduire l’échelle de 40.
Je vois bien que c’est une histoire de pente de courbe!Mais concrètement sur la levée du biceps ou la rotation du bras???
Je suis pas sûr de vous faire comprendre ce que je ne comprends pas! Je poste quand même.

@Pierrick

Par rapport au tableau excel, je prends comme référentiel la configuration de Gaël afin d’être au plus proche des mouvements qu’il à créée.

Si on prend l’exemple du rotate la config dans son script est :
leftArm.rotate.setMinMax(40,180) => pas utile comme l’a indiqué christian
leftArm.rotate.map(40,180,60,142)

Cela implique que les mouvements créés dans l’espace angulaire 40 à 180 degrés sont reproduit
par inmoov Gaël sur la plage de fonctionnement 60 à 142 degrés.

Sur mon robot j’ai préféré limiter la plage de fonctionnement entre 60 et 120 degrés par sécurité…

Si dans ses gestures Gaël à un ordre de rotate à 40 degrés,
sur son robot le bras va se positionner à 60 degrés réel (son min) et un ordre à 180° sur 142 degrés réel position du servo.

Pour mon inmoov l’ordre 40° va positionner le bras à 60° et l’ordre 180 à 120 degrés.
J’ai 60 degrés de débattement, contre 82 chez Gaël, mes mouvements sur cette base auront juste un petit peu moins d’amplitude (22°),
mais j’exploite au max la plage de fonctionnement que j’ai autorisé.

Pourquoi partir à 40°… mystère :-), cela devait correspondre au min du premier InMoov de gaël.

On ne perd pas vraiment 40°, c’est un angle min non utilisable mais il est essentiel dans le mapping car
supposons à l’inverse que je décide de mettre 0 – 180° en mapping sur ma plage 60 – 120.

Quand un mouvement va envoyer un ordre de rotation à 40 degrés, le mapping va le convertir en 73°, ce qui ne correspond pas à mon min de 60 degrés
je vais donc restreindre dans ce cas largement l’amplitude des mouvements.

Voila, du moins c’est comme cela que j’ai compris le truc…
Bon en me relisant je me dit que c’est peut être pas très claire, un petit dessin aurait peut être été plus simple 🙂

J’ai eu une discussion un jour avec Kevin sur la façon de standardiser les positions.
J’avais évoqué la possibilité d’utiliser un positionnement par pourcentage avec la formule suivante :

//user setup -> real servo value
My_Min_Head_Value=10
My_Max_Head_Value=80
…

//Static gesture -> percent value for all  :

i01.moveHead(X_HEAD) ->  always 0 to 100%
…
Exemple
if X_HEAD=0 ( 0% ) -> user value ( servo value to send ) is : 10
if X_HEAD=10 ( 10% ) -> user value ( servo value to send ) is : 17
if X_HEAD=50 ( 50% ) -> user value ( servo value to send ) is : 45
…
( (My_Max_Head_Value – My_Min_Head_Value) * X_HEAD / 100 ) + My_Min_Head_Value
(if My_Max_Head_Value – My_Min_Head_Value > 0 else invert calc )

Kevin a indiqué qu’il était préférable d’utiliser une méthode de standardisation par angle

CalibratedAngle = (ModelAngle * Gain + Offset) % 360

C’est peut être l’occasion de rouvrir un sujet, pour avoir une nouvelle méthode de maping ?

Oui très bonne idée.
Je n’ai pas d’avis tranché sur la manière de faire techniquement, l’objectif est de pouvoir partager des mouvements créer par la communautés et pouvoir les faire reproduire au mieux par chaque inMoov.

Je vois peut être une étape intermédiaire de documentation des positions “Physique” correspondant aux angles min/Max

Ex : X° = tête à droite / Y ° = tête à gauche
V° = position regard bas / T° = position regard haut

Ca permettrait de régler sur la même base nos robots et ajuster la configuration du sens de rotation des servos (horaire ou anti-horaire) par inversion des angles de début et fin ou autres…

Joyeuses fêtes de Noël à tous.

@Anthony

la fonction map que j’utilise fait exactement la meme chose que la formule que t’as donner kevin

prends pour mon bicep:
map(5,60,5,80)

le range 5-60 correspond au range d’angle que avoir au coude.
le range 5-80 correspond a la position que le servo doit prendre.

donc le calcul qui s’effectue pour determiner l’angle x pour une position du servo donné

X = ((80 – 5) / (60 – 5)) / position du servo

position du servo = (((80-5) / (60 – 5)) * (angle – 5)) + 5
(gain) * (model angle) + (offset)

le modulo est pour s’assurer que les valeurs sont entre 0 et 360

• This reply was modified 7 years, 12 months ago by Christian.
• This reply was modified 7 years, 12 months ago by Christian.

perfect ! merci pour la confirmation du calcule de la fonction map
Comment réagit la fonction si je demande une valeur d’angle hors range
( si on s’amuse avec les curseur par exemple )
Le map va faire bouger le servo au delà du range ?
C’est pour la gestion des bobos dus aux limites physiques.
comment gérer les limites physique en plus de la standardisation des angles en gros

les limites des curseurs prennent leur valeurs selon les paramettres du map définie. Dans le cas de mon bicep, je peux aller de 5 a 60 avec le curseur. Tu peux pas dépasser 🙂

Si un script demande d’aller au dela des limites (moveTo(180)) le logiciel affichera: clipping 180 to 80 et la valeur 80 sera envoyé au servo