[RefBoxComm] Renvoie intempestif d'ordre machine déjà affectué

[ValentinVERGEZ]

Je sais et je constate qu'un ordre de préparation machine est envoyé de manière répétitive pour éviter que l'ordre soit perdu à cause d'un problème de communication.

L'ennui c'est que malgré le fait que la machine ait pris en compte cet ordre, il continue d'être envoyé. Ce qui devient problématique dès qu'on a récupérer la pièce ... la machine se prépare alors à ré-exécuter le même ordre.

Problème constaté en simulation.
OUI ON PEUT AJOUTER UN CAP SUR UN PUCK EN SIMU !!!
L'ordre est peut-être traité très / trop vite en simu. Je n'ai pas du tout regardé le code, je remonte le problème tel que je l'ai constaté.

[vcoelen]

Non justement c'est bizarre, le code de la refBox (ligne 193 de refBoxComm.cpp) ne prévoie actuellement d'envoyer les messages de préparation qu'une seule fois (et non périodiquement), un mode burst est prévu mais non implémenté. Ensuite à la charge de l'exécuteur de tâche, normalement, de vérifier que l'ordre est bien reçu (via le feu) et de renvoyer s'il le faut.
J'ai relu le code rapidement du SendScheduler et RefBoxMessage et pour l'instant je ne vois pas d’où peut venir le bug. Je regarde ça en détail dès que possible, mes premiers tests avec la refBox n'avaient pas posé de problème.
Est-ce que tu envoies l'ordre directement via le service du nœud refBoxCom?

[ValentinVERGEZ]

Oui j'ai fait un rosservice call.
J'essaierai sans doute avec un des tools refbox, donc en bypassant le noeud et je te dirai ce qu'il en est.

C'est important pour la suite, évidemment, mais ce n'est pas encore bloquant pour moi pour l'instant.

[vcoelen]

Ok, c'était pour être sûr que tu n'étais pas passé par l’exécuteur, par exemple.
Avec la refBox seule sans simulateur, je ne pouvais pas tester grand chose, si tu me confirme que la version courante du simulateur est fonctionnelle (celle sur notre dépôt?) je pourrais, peut-être, débuguer ce week-end.
Si tu peux m'indiquer les branches à utiliser sur les deux dépôts (simu et robocup-pkg) et les launchfiles à lancer, ça m'aiderai beaucoup :)

[ValentinVERGEZ]

Je bosse toujours dessus, je te donne la version exacte sur laquelle j'ai eu le problème :
robocup-pkg : work/val/sim/rework_oct2016 (4e6e658)
robotino-pkg : work/valentin/integrateFestoChanges (9f1052a)
gazebo-rcll : work/val/rework_oct2016 (f9a2423)

Je lance la simu avec le launchfile test_simulator.launch. Pour l'instant y'a RefBoxComm dedans sur le robotino1.

J'utilise joystick_teleop_node pour déplacer le robot et actionner le gripper. Il se lance avec son launchfile et le paramètre robot:=robotino1 (pour publier cmd_vel & co dans le bon namespace).
R1 pour close gripper. L1 pour open gripper. Un puck sera pris s'il est le plus proche et à moins de 5cm du gripper (configurable dans gazebo-rcll/plugins/cfg/config.yaml)
J'ai ajouté des params button_r1 et button_l1 pour re-mapper les bons index aux gâchettes R1 et L1 de ta manette. Je parle là des index des boutons dans le message du topic /joy.

[ValentinVERGEZ]

Bon le tool refbox c'est pas super pertinent. Tant qu'on ne l’interrompt pas il continue, semble-t-il, de publier l'ordre. Si on interrompt le binaire, alors la refbox ne dit plus recevoir les message.

Et si je passe par la refbox, en ayant les logs, j'ai ce genre d'erreurs qui s'affichent :
Receive error from 127.0.0.1:4446: Deserialization fail: Message type 2000:110 not registered

[vcoelen]

D'accord merci pour la procédure de test :)

Oui les tools sont souvent très basique. J'ai pas eu le temps encore de tester, j'ai juste re-parcouru le code de refBoxComm et je ne comprend pas...

Pour le message d'erreur, ça veut dire que la refbox reçoit un message qu'elle ne connait pas. C'est le plus souvent dû à l'un des deux cas :

• Soit il y a une différence de version entre le programme envoyant le message et la refBox et dans ce cas l'un des deux communique un message non connu par l'autre
• Soit l'un des deux programme cherche à communiquer de manière chiffrée et pas l'autre, dans ce cas les déserialisation des messages échangés sur le chanel privé échouent

Le type 2000:110 correspond aux messages RingInfo ?!?
Ce message n'est pas dans la doc est ne sert probablement qu'au fonctionnement de la simulation, dans ce cas ce serait bizarre qu'il soit envoyé par un robot sur le port 4446