Contrôle informatique : Player, Stage et compagnie
Une part importante du travail que j’ai effectué jusqu’à maintenant sur ce projet concerne la partie logicielle du robot. Comme je l’avais prévu et expliqué dans mes premiers posts (ici), le contrôle du robot est en effet confié en grande majorité à l’informatique embarquée.
Le cœur du système est constituée du serveur Player, exécuté dans un environnement linux (Ubuntu 8.04). Player est un serveur TCP-IP de contrôle robotique, distribué sous lience GNU. Son principe est de répondre aux requêtes d’un un client-contrôleur et de lui fournir toutes les méthodes utiles pour le contrôle des capteurs et actuateurs du robot. Pour sa configuration, Player utilise un fichier de qui définit les interfaces disponibles pour le contrôle du robot, et instancie pour chacune de ces interface les drivers nécessaires en décrivant leurs propriétés et leurs méthodes d’accès au matériel.
Le client quant à lui se contentera de se connecter au serveur, de récupérer la liste des interfaces disponibles, et de travailler avec pour déplacer le robot, lire les capteurs, etc…
Exemple de code client en java tiré de mes premières expériences:
robot = new PlayerClient (« localhost », 6665);
posi = robot.requestInterfacePosition2D (0, PlayerConstants.PLAYER_OPEN_MODE);
if (frontSide <= MAX_WALL_THRESHOLD ) {
posi.setSpeed (0, 0);
}
Bon, tout ceci n’est pas forcement évident comme fonctionnement au début mais ce principe de séparer l’interfaçage du matériel et le logiciel de commande est très puissant et vraiment très souple!
Concrètement, l’écriture du driver (qui se fait en C++) est commencée et j’ai utilisé Stage, l’indispensable complément de Player, pour simuler des petits bouts de code en Java (suivi de mur, déplacement aléatoire, etc…)
La suite du développement côté contrôleur se fera en Python, pour plein de bonnes raisons que je n’ai pas le temps de développer ici pour l’instant. (Player est fourni de base avec des « Python-bindings)
A bientôt pour des exemples de code !
Le python c’est bon, codez en !
Si j’ai bien compris, tu te concentres en premier sur l’aspect software de ton robot, soit ce que tu maitrises le mieux (et de loin).
N’est-ce pas un peu « dangereux »? N’est-ce pas repousser les difficultés (méca, et électroniques) à plus tard? N’as-tu pas peur de t’enfoncer dans du « virtuel », à force de vouloir modéliser et simuler ton robot, plutôt que de le réaliser?
C’est un peu provocateur comme message, mais on aimerai voir du concret plutôt que des méthodes soft.
Rhoooo… comment qu’il me recolle les pieds sur terre celui-là…
Tu as tout à fait raison, je suis bien conscient que de passer du temps sur l’informatique (je ne suis pas développeur pour rien…) repousse d’autant la partie « concrète » de la réalisation et peut aussi rendre beaucoup moins intéressante la suivie de ce blog.
Les aspects électronique et mécanique ne sont pas pour autant totalement délaissés, et mes prochaines séances de boulot devraient concerner la base roulante du robot donc avec un peu de chance, vous aurez la chance de voir un truc rouler d’ici pas trop longtemps
A bientôt !
[...] Le programme qui commande la carte moteur est développée en C++ sous CodeBlocks à l’aide des librairies graphiques wxWidget, associés au driver de la carte U2C de Diolan compilé sous forme de librairie partagée. Cette interface permet de communiquer avec les différentes cartes à base de PIC via le bus I²C (contrôle moteur, alimentation principale et carte d’interface générale), d’y envoyer des commandes et de lire des valeurs. Les fonctions développées dans cette interface seront par la suite regroupées au sein du driver Player (cf ce post décrivant le système : Contrôle informatique : Player, Stage et compagnie) [...]