Open Bidouille Robot

Qu'est-ce qu'Open Bidouille Robot (OBR) ?

Open Bidouille Robot est un micrologiciel pour arduino, permettant la gestion de moteurs, capteurs, servomoteurs, entrée numériques et sorties numériques. En d'autres termes, OBR sert à la création de robot, via un arduino. Une fois compilé et installé sur la carte, il faut configurer OBR (via le PC par exemple) en envoyant une série de commandes. Une fois configuré, on peut toujours le reconfigurer (ajouter/enlever des servomoteurs, changer la vitesse maximum d'un moteur, etc...), mais aussi le piloter. Lorsqu'on demande à un moteur de tourner, OBR va vérifier dans la configuration s'il est lié à d'autres objets (capteurs, entrées, sorties...), et verrouiller ou non le moteur (de même pour une sortie tout ou rien, et un servomoteur). De cette manière, nous pouvons créer des systèmes de fin de courses, en liant plusieurs choses (ex : le moteur ne peut tourner que si le capteur vaut moins que x, et que l'entrée n°y est à 0).

Pourquoi ce projet ?

A la base, j'ai été à l'Open Bidouille Camp (d'où le choix de reprendre ce nom pour le projet) de 2012, où j'ai rencontré une connaissance qui voulais faire un robot démineur sans savoir programmer. Je partais donc avec un engin sur roues, avec un bras motorisé au dessus, mais non pilotable. De base, je devais donc coder un programme sur un arduino Mega2560, permettant de piloter les moteurs inclus dans l'engin. il y a peu, j'ai mis de côté le robot démineur pour me concentrer sur les robots en général. C'est donc de là que m'est venu l'idée de coder un système modulable, et adaptable à tous types de robots.

Communication avec OBR

La communication avec OBR suit une norme qui lui est propre, sous la forme : "[AdresseEnvoyeur|AdresseDestinataire]OBR_COMMANDE-PARAMETRES\n" Le protocole est assez strict, mais simple :

- La communication se fait via les ports séries, en 57600 bauds.
- Le dialogue se fait via des commandes, avec (au max) trois paramètres, et deux adresses (envoyeur et destinataire)
- Toutes les commandes ont un retour, même si ce n'est qu'un "OK"
- Un message peut passer par plusieurs cartes, il y a un système de routage, d'où l'obligation des adresses
- Seul la commande de demande de connexion n'a pas d'adresse, mais la réponse en a une (On ne sais pas à qui on se connecte, mais on sait qui nous répond)
- Le réseau peut se constituer d'un maître, épaulé par deux esclaves (pour augmenter le nombre de PIN), une télécommande, et un PC.
- Il y a donc 5 adresses : 1=PC, 2=Télécommande, 3=Maître, 4=Esclave1 et 5=Esclave2.
- Il ne peut pas y avoir deux périphériques du même type, comme deux PC, ou deux télécommandes.
- Le maître, l'esclave1 et l'esclave2 sont distincts, et ne peuvent pas changer (définit à la compilation). De ce fait, les adresses des PIN allant jusqu'à 255, on peut déterminer le N° du PIN (pour 234, c'est 34) et le N° de la carte (pour 234, c'est l'eclave2).
- Les connexions peuvent se faire en série, les commandes seront routées pour arriver à bon port.

Exemple de connexion entre le PC et le maître : PC <===========> {Esclave2 <=> esclave1 <=> Maître} : L'esclave2 recevra le message, le transmettra à l'esclave1, qui le transmettra au maître. c'est le chemin inverse que fera la réponse.

Ce qu'OBR sait faire pour le moment

Pour le moment (version 0.4), OBR ne sait pas faire grand chose, si ce n'est gérer les connexions entre arduinos, télécommandes et PC. Les commandes sont fonctionnelles, et on peut connaître le nom du robot, ainsi que sa version d'OBR installé. Une session administrateur est gérée, on peut l'utiliser (mot de passe par défaut : 2560) pour configurer le robot. Lorsque l'administrateur se connecte, la LED 13 s'allume pour dire que la configuration est susceptible d'être modifiée.

Ce qu'il sera sensé faire plus tard

Dans le futur (version 1.0), OBR devra toujours gérer les connexions automatiquement et à chaud, mais aussi enregistrer les configurations dans l'EEPROM, pour s'en servir lors du pilotage (l'EEPROM sera copié dans différents tableaux en RAM au démarrage).