Bonsoir,
Je relance ce post que j’avais créé il y a quelques temps (et un peu abandonné faute de temps à consacrer sur le sujet…)
Pour résumé, afin de remplacer snap qui est trop click-o-drome à mon goût et nuit à mon initiation sur poppy je voulais développer une une solution en mode plus “programmatique” avec la même approche client/serveur ce qui est quasiment le cas via un mode cli et une approche scriptable simple en javascript via node.js/npm.
Basiquement, je me base sur l’API REST exposée par le serveur http pour accéder aux registres des moteurs en lecture/écriture pour créer des commandes basiques, commandes ensuite chaînables ce qui me permet de piloter les moteurs ainsi que de les interroger sur leurs états.
La solution me paraît pas mal, plutôt utile, tout du moins bien adaptée aux réfractaires aux interfaces graphiques/clicks et simple, je tâcherai de la mettre sous github/npm quand certains détails seront réglés (rédiger un ersazt de documentation, certaines parties de code honteuses, etc…)
Mais j’ai encore quelques “problèmes”/incompréhensions auxquels je n’arrive pas à répondre; les voici:
1/ ma première requête suite à la mise sous tension du poppy finit systématiquement en timeout, et ce peu importe la valeur de ce timeout, même grande, sur ma requête, alors que les suivantes passent toujours, même directement enchaînées. Cela donne l’impression que la première requête faite après mise sous tension doit “impliquer” quelque-chose côté serveur (sic) puis le mode de fonctionnement est correct. je pourrais contourner cela en “créant” une fonction de type init() qui lancerait une requête “bidon” afin de palier ce problème, mais j’ai probablement raté quelque-chose,
2/ idem lors de la mise sous tension:
- je perds systématiquement les valeurs liées à la vitesse (registre ‘moving_speed’ qui est alors à 0,
- le registre ‘goal_position’ est systématiquement lui à la valeur 150.
Est-ce que les valeurs ne sont pas persistantes dans les registres? Bref tout est normal (la valeur 150, m’interpelle quand même ). Bon d’un autre côté, je ré-initialise tout cela en une petite ligne de commande donc…
3/ J’effectue des rotations sur les moteurs avec une option permettant d’attendre que la position cible soit atteinte (ou non). L’algo est très simple:
a/ j’initialise la valeur ‘goal_position’,
b/ puis, à intervalle temporel régulier (de l’ordre de quelques centaines de ms), j’interroge le moteur cible sur sa position courante (registre ‘present_position’), calcule le delta et en dessous d’une valeur seuil (2degrés, valeurs purement empirique), rends la main.
Mais cela ne fonctionne pas systématiquement et fréquemment, il y a une forte incertitude sur la position courante retournée en “interrogeant” le registre ‘present_position’ suite à un mouvement. L’incertitude est de l’ordre de 5/10 degrés, ce qui est plutôt gênant ici, et il faut “attendre” quelques bonnes secondes après une rotation d’un moteur pour que ce type de requête renvoie la “bonne” valeur pour ce moteur.
Est-ce du aux moteurs xl-320 qualifiés de “low-cost” i.e. la “précision” laisse-t-elle à désirer??
J’ai contourné le problème en calculant un delta entre la position courante à l’itération n et n-1 qui doit être proche de zéro: Il semble que le retour de la requête sur le registre ‘present_position’, même s’il ne retourne pas la position exacte attendue, tends vers une valeur donnée. Cela fait le job mais n’est pas bien “propre” (aka pleinement satisfaisant), j’ai l’impression d’avoir raté quelque-chose…
Bref, quelques problèmes pas insurmontables, plutôt de l’ordre du détail, mais qui me laissent penser que je n’ai pas compris quelques points sur poppy/les moteurs alors que les concepts semblent simples…
Merci d’avance,
N.