<<SubscribeTo(WikiValerian,WikiSeb,WikiSgnb,BarBichu,WikiCarlos,)>>
Sommaire
La carte mère
La configuartion
L' OS
Le système d'exploitation choisi est Linux, plus précisement une distribution Debian.
Ce choix résulte de la grande souplesse d'utilisation et de programmation, ainsi que de la stabilité approuvée de cet environnement logiciel.
La programmation
Le language
Les drivers
La reconnaissance d'images
Initiée lors d'un TER, et codée sous Matlab, elle est e train d'être portée en C pour être utilisée sur la carte mère.
Les cartes d'asservissement
Le projet se compile en faisant make ou make test.
En C
- axdll.c est la bibliothèque permettant de parler avec les cartes Axina. Il n'y a qu'une seule méthode exportée, c'est la commande axina qui permet de discuter avec une carte Axina. Bref, c'est du bas niveau. Elle comprend un mécanisme de lock monocommande avec des IPC. Cela permet de ne pas avoir à gérer le fait que l'on ne peut pas envoyer une commande avant de recevoir la réponse de la précédente. Par contre, il faut gérer le fait qu'un périphérique ne peut pas accepter certaines commandes entre deux autres commandes.
- commandes.c est un début d'implantation haut niveau en C. Elle est incomplète, je suis passé en Python ensuite car la gestion des erreurs sans mécanisme solide d'exceptions est une horreur
- test.c est un programme permettant de tester cette implantation haut niveau.
- krobotd.c est un début de tentative de serveur pour piloter le robot : on lui envoie une commande, il transmet au robot et renvoie la réponse. C'était pour gérer correctement les accès concurrents. À la réflexion, on fait mieux en Python et il y a sans doute moyen d'éviter une bonne partie du code en utilisant des trucs un peu plus modernes pour communiquer (XML RPC ?).
Python
L'interface C/Python est faite avec Swig qui permet de générer facilement des interfaces entre plusieurs langages. Le fichier axina.i comprend cette interface. En gros, on obtient une interface pour la commande axina().
Après avoir importé un module avec import, on peut obtenir de l'aide. Par exemple : Toggle line numbers
- 1 import recepteur 2 help(recepteur)
- axina.py est le fichier Python généré par Swig. Il contient donc les constantes et la commande axina sous le nom axina.cmd.
- recepteur.py permet de piloter de manière générique un récepteur. On l'initialise en prenant en paramètres le numéro du port série, l'adresse du récepteur et sa configuration initiale. Ensuite, on peut envoyer des commandes avec recepteur.cmd qui est un wrapper autour de axina.cmd mais qui gère les erreurs en tentant de réinitialiser correctement la carte. On voit l'utilité des exceptions !
- moteur.py permet de piloter un moteur. Chaque commande doit être suivie d'un moteur.do.
- js2ai.py et jsttl.py permettent de piloter les capteurs d'entrée/sortie et les actionneurs correspondant. lssmc.py pilote une carte servo (c'est non documenté comme bidule).
- krobot.py propose des commandes de haut niveau pour piloter le krobot. Des threads sont lancés pour mettre à jour la position et gérer le retournement automatique des palets. C'est un peu goret, mais ça marchait bien jusqu'à l'intervention du limeurfou.
Exemple
On peut regarder balayage.py. Problèmes
Il y a deux gros problèmes :
- les cartes sont capricieuses, il faut donc beaucoup de codes et d'essais pour trouver comment les apprivoiser. Malgré ça, parfois ça plante et on ne peut plus réinitialiser sans couper le courant. Ces problèmes n'existent plus sur le bus USB. Le [WWW] code source a été adapté pour utiliser celui-ci et le code gérant les caprices de cartes a été retiré.
- il est très dur d'obtenir la position du robot, même sans prendre en compte le problème de patinages : les moteurs sont indépendants et on est obligé de démarrer l'un avant l'autre et le bus est pas mal lent. On peut tenter de rattraper l'erreur, mais a priori, la loi suivie n'est pas claire et n'est pas linéaire, ni en la vitesse, ni en l'accélération. Bref, on a finalement abandonné espoir de savoir exactement où on était.
- o
Et mettre deux acceléromètres pour intrégrer et déduire la position ? -- DréBon 2007-04-27 09:32:59
- o
- il est très dur d'obtenir la position du robot, même sans prendre en compte le problème de patinages : les moteurs sont indépendants et on est obligé de démarrer l'un avant l'autre et le bus est pas mal lent. On peut tenter de rattraper l'erreur, mais a priori, la loi suivie n'est pas claire et n'est pas linéaire, ni en la vitesse, ni en l'accélération. Bref, on a finalement abandonné espoir de savoir exactement où on était.