Bonjour,
Nous sommes en train d’assembler notre poppy belge.
Question pratique : lors de la déclaration des moteurs sous herborist, ne faut-il pas indiquer les angles limites (-180° à +180° par défaut)?
Un peu la même question mais pour snap! : existe t-il une liste des angles conseillés pour chaque degré de liberté pour ne pas “forcer” sur les moteurs lorsque l’on passe de la simulation au test réel?
On a cherché… mais on a pas trouvé dans la doc
Merci d’avance pour votre aide !
Hello,
We are assembling our belgian Poppy.
practical question: when reporting engine under Herborist, should we not specify limit angles (-180 ° to + 180 ° default)?
Nearly the same question for snap! : Is there a list of recommended angles for each degree of freedom not to “force” on the engines when passing from the simulation to the real world?
We looked for… but didn’t found it in the database
You are right but if you use the standard python package for the humanoid, the motors are automatically configured. Angle limit are indicated in the config file:
The same config file is used for Snap! so it won’t be a problem either
Merci pour cette réponse rapide
C’est marrant : r_hip_y et l_hip_y ne sont pas limités de la même façon (respectivement -85;+105 et -104;+84)
C’est la première fois que je programme sous Snap!, et connaitre la limite des angles me permet d’éviter de perdre du temps à comprendre pourquoi ca ne bouge pas comme je m’y attendais
Bonjour,
je continue ma découverte de Poppy.
Dans le fichier des débattements cité par @Matthieu ci-dessus, on trouve
"angle_limit": [
-134,
3.5
pour r_knee_y.
Or, sous snap! pour commander la simulation V_REP, c’est plutôt -3.5, +134 qui fonctionne pour r_knee_y, comme pour l_knee_y… ce qui parait assez logique sur notre Poppy 1.0, puisque les moteurs sont montés dans le même sens…
J’ai vu le “orientation”: “indirect”, en dessous, mais je ne comprends pas pourquoi les angles sont du coup incorects sous Snap!..
Cette différence provient d’une des mise à jour matérielles?
L’URDF qui a été utilisé pour faire le robot dans VREP est probablement faux sur les moteurs r_knee_y, abs_x, et bust_x, du coup cela a été changé de façon logicielle…
Ok… Donc, si je prépare une série de mouvements via snap! (je ne suis pas du tout programmeur ), et que je la lance sur le robot plutôt que sur la simulation, l’inversion n’est pas automatique ?
Ou alors le code “controllers” que citait @Matthieu était celui du robot physique, et il fallait que je l’inverse pour utiliser la simulation, et c’est réinversé de façon logiciel si je l’utilise sur le robot?
Je me sens à la frontière des mondes
De toute facon, si j’ai bien compris, les moteurs sont protégés de facon logicielle contre le dépassement d’angle matériel… Donc pas de risque de casse…
Pour V-REP/URDF il se passe des choses obscures dans la génération des axes du coup on a du faire un patch logicielle pour changer ça.
Cependant, ce n’est pas visible pour l’utilisateur, il ne devrait pas y avoir de difference quand on commande le robot en utilisant python ou snap! sur le robot réel ou simulé.
Ensuite sur le fichier de config, un moteur indirect veut dire que la manière dont il est physiquement placé rend son sens de orientation indirect https://fr.wikipedia.org/wiki/Sens_de_rotation Du coup, pypot gère ça en appliquant un facteur -1 sur les commandes.
C’est pour ça qu’en tant qu’utilisateur tu vois (-3.5, +134) qui correspond au débattement possible dans le repère du robot.
), et que je la lance sur le robot plutôt que sur la simulation, l’inversion n’est pas automatique ?