Ayant, dans le cadre de mes études, développé un logiciel de contrôle pour la plateforme WifiBot, j’ai réalisé que le concept était très prometteur, et permettait de s’initier facilement à la robotique. Son prix étant décourageant pour un particulier, je me suis mis en tête de réaliser une plateforme semblable, la moins onéreuse possible, à base de Raspberry Pi :
L’ensemble ne m’aura couté que 80€ (Raspberry Pi inclus).
Cet article décrit toute la construction du WifiBotBerry, et en particulier l’installation et le paramétrage des logiciels utilisés….
Hardware
Le WifiBotBerry est un robot 3 roues : les 2 roues avant sont motrices, et mues par des servomoteurs de modélisme TowerPro MG995, modifiés pour pouvoir effectuer une rotation continue (un servomoteur normal ne peut pivoter que sur 270°), comme un moteur normal, mais qui ne nécessite pas d’électronique de puissance, celle-ci étant intégrée. Cette modification est décrite sur le site du FABLAB de Dijon. Les servomoteurs modifiés sont fixés au châssis avec des colliers plastiques et du double face, mais une fixation plus sérieuse ne ferait pas de mal ! Les roues des servomoteurs ont été achetées sur ebay.
La roue arrière est une roue folle, comme une roue de caddy, elle est capable de pivoter sur elle même, et ne fait que suivre le mouvement imposé par les roues motrices. Ce type de roues est vendu en magasin de bricolage.
Le châssis métallique et la coque utilisés sont en fait un ancien boitier de disque dur externe STOREX CLUB-U2350. L’ensemble mesure exactement 16cm de coté par 4 cm de haut et abrite le Raspberry Pi, cerveau du robot, ainsi qu’une batterie pourvue de 2 ports USB, normalement prévue pour recharger un appareil USB :
La batterie est disponible sur ebay pour une dizaine d’euros sous le nom 12000mAh USB Batterie. Elle présente l’avantage d’offrir 2 ports USB capable de fournir simultanément 2.1A pour le premier, et 1.0A pour le second.
Les fils d’alimentation des servomoteurs (marron pour le -, rouge pour le +) sont reliés à une prise USB branchée sur la batterie, tandis que les fils de commande (orange sur mes servos) des servomoteurs gauche et droit sont respectivement connectés aux GPIO23 et 24 ( pins 16 et 18 du connecteur GPIO du Raspberry).
Le Raspberry Pi utilisé est un modèle B, pour ses 2 ports USB : le premier reçoit un dongle Wifi TL-WN725N (avec le recul, je le déconseille, il est pas cher, mais sa portée est très limitée), tandis que le second port est utilisé pour la webcam (une Microsoft Lifecam il me semble).
Software
Toute les actions décrites ici ont été réalisées avec la distribution Raspbian. Même si tout devrait fonctionner à l’identique sur une autre distribution, je ne peux pas le garantir.
Etape 0 : Installer le dongle wifi.
Si, comme moi, vous possédez un dongle TP-LINK TL-WN725N v2, vous êtes probablement également en grande difficulté pour le faire fonctionner avec votre Raspberry Pi. La solution ( et par solution, j’entends les bons drivers 🙂 ) se trouve sur ce topic du forum Raspberry. A la fin du premier post est proposé un petit script shell, qui se charge de télécharger et d’installer automatiquement le bon pilote.
Etape 1 : Contrôler les servomoteurs.
Le logiciel ultime lorsqu’il s’agit de contrôler des servomoteurs depuis un Raspberry Pi s’intitule ServoBlaster. Sans rentrer dans les détails, il est capable de piloter plusieurs servomoteurs simultanément, de façon très stable quelque soit l’utilisation du CPU, en s’appuyant sur le module DMA. Une page du FABLAB de Dijon lui est consacrée. Tout d’abord, récupérer l’archive du projet PiBits (dont ServoBlaster fait partie) sur sa page github. (bouton « download ZIP ») Une fois l’archive extraite sur le raspberry, on s’intéresse au dossier ServoBlaster/user. Dans le fichier init-script, modifier la ligne suivante :
OPTS="--idle-timeout=2000"
pour obtenir :
OPTS="--p1pins=16,18 --idle-timeout=1000 --step-size=5"
Cela signifie que lorsque ServoBlaster démarrera, il contrôlera les servomoteurs reliés aux pins 16 et 18 du connecteur GPIO du Raspberry, les signaux seront générés avec une précision de 5 µs, et ServoBlaster arrêtera automatiquement les servomoteurs si aucune commande ne lui est transmise pendant 1 seconde (pratique pour éviter de voir le robot foncer en ligne droite en cas de problème) Lancer la compilation puis l’installation de ServoBlaster grâce aux commande suivante :
$ make $ sudo make install
A cet instant, pour vérifier que tout fonctionne bien, il suffit de saisir la commande suivante, et le servomoteur gauche doit tourner :
$ echo 0=150> /dev/servoblaster
Idem pour le droit :
$ echo 1=150> /dev/servoblaster
Si aucun des servomoteurs ne fonctionne, saisir la commande suivante :
$ cat /dev/servoblaster-cfg
Le texte suivant doit alors s’afficher :
p1pins=16,18 p5pins= Servo mapping: 0 on P1-16 GPIO-23 1 on P1-18 GPIO-24
Si c’est le cas, ServoBlaster est bien démarrer, il s’agit vraisemblablement d’un problème de branchement des servomoteurs. Sinon, reprendre cet étape depuis le début. Si tout va bien, passer à l’étape 2 🙂
Etape 2 : Réglage du points de repos.
Une fois que ServoBlaster est configuré, il faut identifier le point de repos des servomoteurs, c’est-à-dire la valeur pour laquelle ils ne tournent pas. Commençons par le servomoteur gauche. Pour cela, il faut jouer avec la commande suivante, en faisant varier la valeur val. Le point de repos devrait se trouver entre 200 et 300.
$ echo 0=val> /dev/servoblaster
Recommencer pour le servomoteur droit, avec la commande suivante :
$ echo 0=val> /dev/servoblaster
Les deux valeurs sont normalement très proches, mais pas nécessairement identiques. Les noter soigneusement.
Etape 3 : Premier test avec termcontrol
Récupérer l’archive du projet BotBerry, en cliquant sur le bouton download sur cette page.
Dans le fichier servocommand.c, modifier les lignes suivantes :
#define IDLELEFT 253
#define IDLERIGHT 249
en remplaçant respectivement les valeurs 253 et 249 par les valeurs des points de repos des servomoteurs gauche et droit.
Si vous utilisez un clavier querty, remplacer également les valeurs « z », »s », »q » et « d » dans le fichier termcontrol.c par « w », »s »,a » et « d »
Compiler, et lancer l’exécutable termcontrol généré :
$ make $ ./termcontrol
Normalement, le robot devrait se piloter avec les touches Z,Q,S,D. Si les commandes semblent inversées par rapport aux mouvement du robot, modifier la ligne suivante du fichier servocommand.c :
//#define INVERTDIRECTION
en
#define INVERTDIRECTION
puis recompiler, et relancer le fichier termcontrol. Les commandes devraient maintenant être correctes
Etape 4 : Mise en place du logiciel wifibotserver
Toujours dans le même dossier, installer le programme wifibotserver :
$ sudo make install
Ce programme permet au BerryBot de se comporter comme un robot WifiBot d’ancienne génération. Le contrôle du robot se fait en transmettant les commande sur le port 15020 TCP. 2 octets doivent être transmis, le premier correspondant à la roue gauche, et l’autre à la route droite, sous la forme 1SVVVVVVV ou S indique le sens de rotation ( 1 = vers l’avant, 0 = vers l’arrière ) et les 6 bits VVVVVV correspondent à la vitesse de rotation, 0 signifiant l’arrêt, et 63 la vitesse maximale.
Le protocole de commande étant le même que l’ancienne génération de WifiBot, il est possible de tester les programmes de pilotage sur l’ancien logiciel de simulation WifiBot.
Etape 5 : Pilotage avec le logiciel WifiBot Control
Ce logiciel est disponible ici, et permet de contrôler tout WifiBot, d’ancienne ou de nouvelle génération, d’afficher le flux video du robot, et la valeur de ses capteurs (inutilisé sur le BerryBot).
Il doit être compilé avec Qt 5, et a été testé avec succès sous Windows 7, Linux (Ubuntu), et Android. Une fois lancé, il suffit de saisir l’adresse IP du Raspberry, de sélectionner « Simple protocole » et de cliquer sur connect. Le BerryBot peut alors être contrôlé au clavier (avec Z,Q,S,D), à la souris, ou avec une manette de Xbox360 lorsque le programme s’exécute sous Windows.
Les boutons de gauche permettent le contrôle du robot à la souris, tandis que les boutons de droite permettant le contrôle d’une webcam motorisée.
Etape 6 : Ajout de la video, avec MJPG-Streamer
Toute la procédure à suivre est décrite sur le site du FABLAB de Dijon.
Une fois l’installation terminée, il est possible d’accéder à l’interface web de MJPG-Streamer en saisissant l’adresse suivante dans un navigateur web : http://ADRESSE_IP_RASPBERRY:8080
Etape 7 : Enjoy
Conclusion
Si vous avez survécu jusqu’à l’étape 7, c’est fini, votre BerryBot devrait être pleinement opérationnel. N’hésitez pas à le customiser, à modifier mon code, etc…, je serai plus que ravi de publier vos améliorations.
Toutes les images du projet WifiBotBerry :
Et pour finir, une petite vidéo du monstre :
Au final, je suis plutôt satisfait du résultat, le BerryBot fonctionne bien, le seul point noir est le dongle wifi actuel, qui offre une portée et un débit trop limités. Si l’occasion se présente, je le remplacerai par un dongle avec une antenne déportée, fixée sur la coque.
6 Commentaires
Passer au formulaire de commentaire
Bonjour,
très bel article!
J’aimerai savoir si la batterie utilisée tient bien la charge car au regard des leaders des batteries comme Anker, les prix proposés défis toute concurrence.
Ainsi, quelle est la durée effective de la batterie?
Merci pour votre réponse.
Auteur
Bonjour,
je met la batterie en charge, et je fais un test d’endurance dès que possible (dans la journée, ou demain)
Auteur
Avec le robot, j’ai plus de 4h d’autonomie.
Même autonomie avec 2 smartphones récents en jeu + charge + data.
J’estime la capacité réelle plus proche des 7000-9000mAh que des 12000mAh annoncés
slt,
En lisant ton article, y a un truc qui me travaille tu peux m’expliquer cmt tu as branché les servos moteur stp ? merci 😉
Auteur
Salut brayan,
Chaque servo possède 3 fils : 2 fils d’alimentations ( +5V et Masse ), ainsi qu’un fil de commande.
Les fils +5V et Masse des 2 servos sont reliés directement aux pins +5V et Masse d’un connecteur USB, qui est branché sur la batterie.
Chaque fil de commande est branché sur un pin GPIO du Raspberry, ( pins 16 et 28), qui génère les signaux de commandes.
ça te semble plus clair ?
Ouais c’est parfait merci, je suis entrain de construire un drone avec 4 moteurs et je passe par une carte qui peut gérer jusqu’à 16 servos et/ou moteurs.
C’est pour ça j’avais du mal à voir comment tu les contrôlais !
En tout cas merci, je ne pensais pas que tu pouvais les contrôler sans une interface entre servos – raspberry 😉