Après un certain temps d’utilisation je rencontre potentiellement des problèmes de timeout en effectuant des requêtes via l’api rest, notamment quand les moteurs sont dans l’état ‘stiff’.
Dans les logs affichés dans la partie “What’s happened” sur le site web du robot, j’ai effectivement une palanquée de messages indiquant une erreur pour obtenir les positions des moteurs.
En procédant à une reconfiguration de mes moteurs cela règle le problème mais c’est fastidieux (il faut débrancher tous les câbles des moteurs).
Cela serait pour savoir si:
Le fait de régler ce problème via la config des moteurs est un pur hasard,
Si non, que fait exactement cette étape?
Je n’ai pas vraiment d’idées quand aux timeouts; j’envoie probablement/sûrement de temps en temps de mauvais types de valeurs.
J’avais remarqué que l’api rest ne renvoyait pas de message d’erreur dans ces cas là alors que celle servie par snap semble moins permissive (un message d’erreur est alors retourné et je suppose alors qu’aucune action d’écriture n’est faite.
Je me demande alors si en envoyant un mauvais type, l’on en peut pas alors écraser accidentellement d’autres valeurs des registres (liées à la partie com par hasard).
Si c’est une voie possible, y-a-t-il un moyen plus simple de ré-initialiser les registres, même ceux non accessible via l’api rest (cf. documentation des xl 320 ici) ?
Si non, une idée??
Je n’ai pas d’élément de réponse sur le reset registres en eux-même, si ce n’est qu’en effet le reset moteur règle parfois des problèmes incongrus, sans pouvoir en dire plus.
En revanche souvent avec les moteurs qui vieilissent ce sont les câbles qui deviennent défectueux et altèrent le signal, causant de multiples erreurs dans les journaux comme ici.
arfff, un problème côté matériel ne m’a même pas effleuré l’esprit…
Ce qui est étrange c’est qu’une ré-initialisation des moteurs a, a priori, résolu le problème ou peut-être le fait d’avoir rebranché les câbles “correctement” à peut-être joué aussi; j’impose parfois à mon ergo des activités de contortionistes, ceux-ci ont pu “bouger” de leur slot.
Donc pas de moyen de diagnostique simple purement logiciel?
Moins simplement qu’on le voudrait en tout cas. Le bon fonctionneemnt de l’électronique ne tient parfois pas à grand chose.
Je pense que pour répondre précisément à la question il faudrait procéder de façon empirique, peut-être pour le prochain moteur défectueux, vérifier l’état de tous les registres, les changer un par un en comparant avec un moteur fonctionnel, etc.
Il y a sur ce même forum quelques feedbacks d’utilisateurs qui ont eu des expériences un peu incongrues avec les registres et ràz moteur. Peut-être que quelqu’un d’autre aura une idée plus précise sur la raison du problème.
En investiguant, je pense avoir identifié 2 “problèmes”: l’un de mon code (pb transpilation js pour le web/lib axios), l’autre, qui nous intéresse ici (enfin moi ) ressemble au moins plus à une limite/pb de perf du côté de l’api rest http.
j’ai plus l’impression que le problème vient des requêtes, de leur fréquence, et du choix de l’api rest (http ou snap) qui semble jouer aussi.
Pour situer le contexte, ma partie requesting est découplée par moteur/registre: j’ai une requête par registre/moteur. Ce qui correspond à l’approche “naturelle” de l’api rest http.
Je teste en effectuant en toile de fond des requêtes pour:
les positions toutes les 150ms,
pour les autres registres (vitesse, état ‘compliant’, stiff’) toutes les 300ms.
Cela donne un ordre de grandeur pour les fréquences utilisées mais influe finalement peu. Ceci permet d’obtenir les valeurs des registres mes moteurs en ‘live’.
Je peux lancer 2/3 instances de ce client simultanément donc multiplier le nombre de requêtes, ras.
Avec un autre client, je passe mes/des moteurs en ‘stiff’ et réalise quelques écritures dans les registres (position, vitesse, etc…) => apparition des problèmes (requêtes en timeout/requêtes exécutées alors que mes processes sont stoppées (!), etc. bref plein de comportement weird et aléatoire).
De manière semi-empirique j’obtiens les observations suivantes:
api ‘http’ => donc c’est problématique,
api ‘snap’ => cela s’améliore grandement, mais des requêtes échouent relativement fréquemment, tout du moins suffisamment pour rendre l’utilisation “pénible”,
api ‘snap’ + regroupement des moteurs dans l’interrogation des requêtes comme cette api le permet ( /motors:m1;m2:/get/registre) => résultat ok.
En conclusion, j’aurais tendance à penser que le problème viendrait plutôt du serveur pour l’api rest http et finalement changer d’api rest et utiliser celle exposée par snap qui me paraît plus ‘robuste’ au moins à la charge.
Pour vérifier si les câbles et l’alim peuvent être source de problèmes il vaut peut-être mieux tester un script directemant dans Jupyter Notebook, plutôt que d’ajouter une surcouche REST qui risque de mélanger les problèmes. Quitte à le laisser tourner des heures afin d’accumuler des stats sur le nombre de timeouts
Qu’entend-t-on par “client” ici ? Un client lancé avec 2/3 instances sans problème et un autre qui pose problème => je ne saisis pas bien ce dont on parle ici
Des bugs liés à la concurrence des requêtes existent peut-être : la concurrence de Tornado + celle des threads Pypot ne fait certainement pas bon ménage. Par la nature mécanique du robot les requêtes sont longues à s’exécuter et des requêtes concurrentes sur les API peuvent facilement s’empiler et rentrer en conflit => il serait intéressant d’écrire des tests unitaires testant spécifiquement la concurrence (volontaire ? )
L’API Snap n’est pas RESTful, c’est un hack pour être compatible avec Snap, et ce n’est pas vraiment souhaitable. Elle est vouée à péricliter, au profit d’une API REST. Donc la considérer comme une solution à des maux ne me semble pas une bonne idée
Au fait, j’ai une approche de type boîte noire pour le poppy à laquelle je peux accéder via les 2 api servies appelé ‘http’ (port 8080) ou ‘snap’ (6969) pour reprendre la terminologie utilisée dans la documentation (ma préférence allant aussi à la première…)
2 moyens différents d’accès au poppy mais ensuite, je suppose que cela se base sur les même briques logiciels (pypot).
Pour les tests: 2/3 clients: arfff, désolé, plus clairement n fois le même process envoyant des requêtes en lecture sur les registres pour tester les api en charge du robot => ok.
Puis, simultanément, j’envoie des requêtes en écriture (vitesse/position/état stiff compliant) et là, les problèmes arrivent, comme évoqué précédemment.
En permutant de l’api ‘http’ vers ‘snap’, cela (semble) résout le problème et de manière simple et rapide (quelques lignes de codes à changer, c’est immédiat de mon côté) tout en conversant une approche “boîte noire” vis-à-vis du poppy i.e. ne pas s’immiscer dans des considérations de type concurrence de requête en gérant une queue en amont, threads pypot/ tornado, ou autres (d’ailleurs python c’est bien un serpent?)
Reste tout de même la volonté de comprendre le problème, tout du moins de l’identifier: matériel/logiciel (moi ou dans l’ergo)
J’ai enfin la solution, enfin je reproduis et contourne maintenant systématiquement.
Le mode opératoire était biaisé + fausse piste sur les timeouts dans les logs (je les ai toujours mais cela ne semble plus poser de problème) qui me poussait vers une analyse eronnée.
C’est plus un problème de réseau, et au moins notamment de dns /redirection (réseau avec une livebox, et en utilisant soit ‘poppy.local’ (Zeroconf) ou un hostname configuré dans le dns de la box pour le poppy).
En résolvant en amont le hostname dans mon code et en utilisant l’adresse IP pour les requêtes plutôt que laisser la box gérer cela, cela règle tous les problèmes.
Ce qui est étonnant, c’est le comportement: j’ai une brique commune en js que je peux utiliser:
via node en ligne de commande,
soit en la transpilant pour l’intégrer dans un site web (plus de lien avec node alors).
Les observations:
Sur la même machine, lancer soit n scripts nodes => comportement ok.
Sur la même machine, servir via un serveur web et lancer n browser web=> comportement ok.
En lançant sur une même machine à la fois un script node et un browser web vers le site (j’ai servi celui-ci sur une autre machine en utilisant nginx afin de ne plus dépendre de node) et en mode CLI => les problèmes apparaissent et les requêtes échouent fréquemment et aléatoirement.
Client web et script nodes lancés sur des machines différentes => comportement ok.
) ressemble au moins plus à une limite/pb de perf du côté de l’api rest http.
