Après avoir remonté la bébête, on va faire un tour du côté du soft.
A défaut d’avoir compris le rôle de ’’botserver’’ (nous y reviendrons), on utilise la bonne vieille méthode. Je me connecte à la RasPi et comme indiqué dans la doc, procède à
sudo apt-get update && sudo apt-get install aisoy-raspberry
Tout semble se passer correctement. Il est maintenant temps de commencer à programmer un peu 😛
Premiers essais logiciels
Question doc, on trouve un Hello World qui... fait dire "Hello world" à Aisoy, et la doc de la lib C++ générée avec Doxygen. Elle a le bon goût d’inclure des exemples de code Python. Ca c’est une bonne nouvelle. Par contre, est-ce un trait d’humour ou bien une connaissance approximative de l’Anglais : le programme ne s’appelle pas HelloWorld mais HelloWord, et c’est d’ailleurs le message qui est donné à prononcer à Aisoy. A moins que ce ne soit une dévotion à Microsoft Office...
Sauf que les exemples sont faux ou pas à jour. Par exemple, la doc de mouthPrint() dans la classe Actuator oublie juste de préciser que les minuscules ne sont pas affichées. J’ai mis du temps avant de comprendre pourquoi mes messages n’apparaissaient pas.
Après mise à jour via botserver (voir plus loin), la nouvelle version de la lib affiche tout le texte en majuscule, la lib se chargeant visiblement de la conversion des caractères.
Autre gag : la documentation de mouthDraw(). On y parle de plusieurs dimensions de la matrice et l’exemple fourni ne fonctionne pas. Pour une bonne raison : contrairement à ce que dit la doc, un point éteint doit être représenté par un ’0’ et pas par un blanc. J’ai l’impression que la phrase qui évoque les 14 premiers points de je ne sais pas quoi n’est pas à sa place et appartient à une autre méthode (celle qui cause d’image peut-être).
Ca rame
On avance cependant progressivement, et ça marchouille. Je dis "marchouille" car je trouve que ça rame de chez ça rame 🙁
Ayant ajouté quelques traces dans le Hello World, je constate que certaines instructions mettent plusieurs secondes à s’exécuter. Et pourtant la charge CPU n’est que de 40 à 60%. Même ssh présente des lags insupportables. On se croirait sur une Arduino en train d’essayer de calculer une convolution cubique sur une image Landsat [1].
Petite analyse de ce côté d’ailleurs : top nous indique que le plus goinfre de tous les process est le node ROS qui gère la caméra. Il y en a d’ailleurs 2 ou 3 dont je ne perçois pas le rôle pour le moment, et je décide donc de les retirer de la liste de ceux qui sont lancés au démarrage.
Une solution
Ca se passe où ?
Dans /opt/ros/fuerte/stacks/aisoy_launch/launch/aisoy.launch. Ca ne s’invente pas, mais avec un peu de logique ça peut se trouver :
- le script init nommé ros fait appel à roslaunch aisoy_launch aisoy.launch, qui signifie qu’on lance la séquence aisoy.launch contenue dans le stack aisoy_launch
- /opt/ros/fuerte/ : c’est tout simplement la release de ROS qui est installée (pas de première jeunesse d’ailleurs, car la version actuelle est hydro, soit deux niveaux après, sachant qu’il semble s’écouler au moins 6 mois entre deux releases)
- stacks/ est le répertoire de stockage des stacks, (unité de distribution dans le monde ROS)
CQFD
Une fois ce petit ménage effectué en mettant en commentaire les démarrages de nodes qui ne nous intéressent pas pour le moment, notre Aisoy est beaucoup plus réactif, la RasPi étant revenue à un comportement plus habituel. Il faudra chercher pourquoi une telle lenteur si la CPU n’est pas à 100%. Peut-être une mémoire à 100% qui tente de paginer sur la carte SD. Pas glop du tout si c’est ça.
De la méca en perspective
Au hasard de mes essais, je me rends compte que le mouvement vertical de la tête ne se fait pas. On entend pourtant bien le servo, mais la tête ne fait que tressauter. Problème mécanique, ou bien est-ce celui dont le câble était endommagé ? Il va falloir ressortir les tournevis, et ouvrir la tête aussi. Avec les cache vis ça risque de promettre quelques crises 😕
Au passage
En cherchant comment faire aller la bébête un peu plus vite, j’ai essayé de comprendre comment elle se comporte si on se passe des services de ROS. Si ces frameworks sont très bien car ils s’occupent d’un tas de choses pour vous, et vous permettent de vous concentrer sur vos problèmes à vous, ils sont aussi assez gourmands, surtout quand ils en font plus que ce dont vous avez réellement besoin.
Un peu de retro-engineering m’a permis de découvrir le protocole de communication entre la RasPi et le jetpack. Ca se retrouve dans les sources d’un module dénommé freedom_node.py qui implémente la ROS-ification des capteurs et actionneurs sous contrôle du jetpack. Plus de détail [par ici].