Nouveau modèle 3D

Tout en travaillant sur l'animation de mon robot, j'essaye d'améliorer le problème conceptuel de la dernière patte. Voici pour l'instant comment je vois la chose :

Concept de robot avec augmentation de la liberté du pied

Ici, le pied peut désormais se tourner vers le centre comme ceci :

En le voyant comme ça, je pense qu'il est peut-être un tout petit peu long...

Mais il peut aussi aller chercher plus loin lorsqu'il avancera grâce à une allonge plus grande.

La patte peut aller chercher plus loin, les mouvements pourrons être plus fluides.

Il ne me reste donc plus qu'à modéliser une vraie patte plutôt qu'un bloc et à le réaliser. Pour cela, j'ai pensé à une impression 3D pour quelque chose de très personnalisé. Reste à voir le prix que cela coûtera.

Modélisation 3D de Belma

Généralement, c'est plutôt lors de la conception du produit que le rendu 3D est utile. En ce qui me concerne, je n'aurai pas fait comme tout le monde en modélisant mon robot après l'avoir construit. Voici donc le résultat :

Belma en 3D !

Malgré qu'il manque la carte ArbotiX, les trous des deux plaques du corps, les câbles et les vis, je vais m'arrêter la dans la modélisation car le but est surtout de créer l'animation qui me sera (je l'espère) utile pour réaliser l'animation séquentielle.

Un problème de conception

Je profite d'ailleurs de ce post pour soulever justement un problème de conception qui risque de me poser des soucis même si je n'en suis pas sûr à 100%. En fait, le pied de Belma peut se tourner à l'horizontal voir même complètement vers le haut. D'ailleurs, cela ne me sera sans doute jamais utile de lever le pied plus haut qu'à l'horizontal.

Pied à l'horizontal

Par contre, dans l'autre sens, le pied va bien à la verticale mais pas vraiment beaucoup plus. Alors même si on peut facilement imaginer un mouvement complet du robot en prenant en compte cette contrainte, j'ai bien peur que cela puisse me causer du soucis.

Un degré de liberté handicapant ?

Ceci est donc à méditer. Peut-être qu'il faudrait que je revoie ce point en inversant le sens du servomoteur pour que son pied soit manipulé directement par le moteur et non qu'il fasse partie intégrante du pied comme on peut le voir sur beaucoup de projets de Quadropods et d'Hexapods sur le net.

Weekend difficile

Ce weekend, j'ai commencé à étudier les déplacements de Belma. Une étape qui démarrais plutôt bien grâce à NUKE, une librairie utilisant la cinématique inverse. J'ai réussi à faire avancer Belma sans trop de difficultés même si le résultat était assez chaotique (je vais d'ailleurs éviter la performance en vidéo). La où ça commence à coincer c'est lorsqu'il faut pratiquer soit même la théorie. En effet, avant Belma, je n'en avait jamais entendu parler. Or, je ne suis pas du tout satisfait du résultat de NUKE. Je trouve que les mouvements ne sont pas fluides, pas lisses, pas naturels.

Mais revenons à la cinématique inverse. Un mot assez barbare mais qui permet pourtant de prévoir les mouvements d'un membre s'il souhaite atteindre un point. La théorie n'a rien de simple surtout que je n'ai trouvé justement pratiquement que de la théorie sur le net et peu de pratique et que cela ne concernait que de la théorie 2D alors que je travaille en 3D.

Néanmoins, je me suis tout de même arrêté sur un article assez bien rédigé que je vais vous résumer en français (http://freespace.virgin.net/hugo.elias/models/m_ik2.htm).

Prenons l'exemple de ce membre à 2 axes.

Membre à deux axes. Le point rouge, c'est l'objectif.

Le point rouge étant l'objectif, la cinématique inverse doit nous permettre de savoir de combien de degrés doit être a et b pour que le point bleu arrive sur le point rouge.

Alors comment faire ? Il existe deux méthodes, une méthode qui donnera le résultat directement et l'autre qui va s'approcher de l'objectif par étapes successives. Comme nous sommes en robotique et que le mouvement doit être assez lisse, je vais employer la seconde méthode que je vais appeler "la méthode simple".

La méthode simple !

Simple comme boujour (ou pas), voici comment faire.

Prenons ce graphique :

Objectif, toujours le point rouge !

Dans cette position, si on tourne l'axe A un tout petit peu, cela va déplacer le point bleu vers a et si on tourne l'axe B un tout petit peu, cela va déplacer le point vers b. Pour que le point rencontre sa cible, il faut pourtant qu'on aille dans la direction de t. On voit donc bien que tourner B sera inutile vu que le mouvement sera perpendiculaire. Par contre, tourner A va nous approcher de notre objectif.

Second graphique maintenant, plus aléatoire :

Vous ai-je précisé que l'objectif était le point rouge ?

Ici, en regardant les vecteurs a et b, on remarque que les deux nous rapprocherons de la cible mais que b sera plus efficace que a. Il faut donc tourner les deux axes mais B un peu plus que A.

Méthode de programmation

Comment vais-je représenter cela en code ?
Pour l'instant, je n'y ai que peu réfléchis mais je crois que le mieux serait de travailler avec un logiciel de modélisation 3D (il doit bien y avoir les éléments de l'AX-12 modélisés quelque part sur le net) puis de l'animer par cinématique inverse pour en sortir une séquence de 16 ou 32 positions en fonction de la fluidité requise. Chaque séquence représentant une commande (avancer, reculer, tourner, etc.). Reste à voir si j'ai le niveau pour faire de l'animation 3D. C'est pas gagné mais ce sera pourtant la prochaine étape de mon projet ;)

Mesure de distance avec PING)))

Pour mesurer la distance, j'utilise un capteur "PING)))" de chez parallax. En fait, ce capteur dispose d'un émetteur et d'un récepteur sonore pour mesurer le temps entre l'envoi et le retour. La distance se mesure alors en fonction de la vitesse du son dans l'air.

Un peu de théorie.

Regardons ce capteur de plus près grâce à la fiche technique.

Méthode de mesure du capteur.

Le capteur dispose de 3 pinoches. Une Vdd (de 5V, ça tombe bien, c'est la tension fournie par les entrées/sorties de l'ArbotiX), une masse et une pour le signal. D'après ce schéma, il faut envoyer une impulsion pour recevoir un impulsion écho d'un certain temps. Voyons cela de plus près.

Détails sur le mode opératoire du capteur PING))).

Il faut donc envoyer une impulsion de 5µs. 750µs plus tard, le capteur répondra par une impulsion comprise entre 115µs et 18.5ms (nous donnant la distance). La prochaine capture pourra se faire 200µs plus tard.

Pour calculer la distance, une formule est également donnée dans la doc. On remarque alors que c'est en fait celle du son :

Tc = températeure en °C

Il faudrait donc, pour être précis avoir un autre capteur de mesure de la température et d'appliquer la formule. Pour l'instant, je ne vais pas aller jusque là et considérer que chez moi, il fait environ 20°C. Soit 331.5 + (0.6*20) = 343,5 m/s. N'oublions pas d'ailleurs que la mesure concerne l'aller-retour, soit deux fois la distance à mesurer.

Voyons maintenant le branchement sur la carte. 

Branchement des capteurs. Le PING))) se branche sur une IO digitale.

Branchez donc le capteur sur une des entrées sorties digitales. L'avantage sur l'ArbotiX (contrairement à l'Arduino) c'est que chaque entrée/sortie dispose également d'un VCC et d'un GND. Du coup, vous pouvez utiliser directement des connecteurs 3-pin. Dans les exemples suivants, mon capteur sera branché sur D7.

Programme de test

Comme j'ai appris à utiliser un XBee, je ne vais pas m'embêter avec des câbles et l'utiliser directement pour la communication série (la console quoi).

Voici donc le programme pour mesurer la distance :

int png = 7; // position du PING)))

void setup()
{
    // Démarrage du réseau série. Les modules XBee sont configurés en 38400bps. 
    Serial.begin(38400);
}

void loop()
{
    // Si on a des données sur le port série
    if(Serial.available() > 0)
    {
      // lecture de la donnée reçue
      int incomingByte = 0;
      incomingByte = Serial.read();
      if (incomingByte == 114) // 114 = touche "r"
      {
        long temps, distance;
          
        // Mesure de la distance
        pinMode(png, OUTPUT); // pin signal en mode sortie
        
        // Envoi d'une impulsion
        digitalWrite(png, LOW); // initialistion à 0.
        delayMicroseconds(2);
        digitalWrite(png, HIGH); // envoi impulsion
        delayMicroseconds(5);    // durant 5µs
        digitalWrite(png, LOW);  // remise à 0
        
        // Ecoute de la réponse
        pinMode(png, INPUT); // mode entrée pour écouter la réponse
        
        // pulseIn mesure le temps d'une impulsion en microsecondes
        temps = pulseIn(png, HIGH); 
        
        // conversion en cm
        distance = tempsSonoreEnCentimetres(temps);
        
        
        // écriture dans la console XBee
        Serial.println();
        Serial.print("Temps : ");
        Serial.print(temps);
        Serial.print(" microsecondes.");
        Serial.println();
        Serial.print("Distance : ");
        Serial.print(distance);
        Serial.print(" cm.");
        Serial.println();
        
        // Attente 200µs (temps entre les mesures)
        delayMicroseconds(200);
      } 
      
    }
}

long tempsSonoreEnCentimetres(long tempsEnMicroSecondes)
{
  // D'après la formule = 343,5m/s, soit 0,03435 cm / microseconde
  // Soit divisé par 28,99
  // Sachant que le signal va faire un aller retour, on le divise par deux
  return tempsEnMicroSecondes / 29 / 2;
}

Pour effectuer une mesure, il vous suffit d'envoyer "r" par le réseau série XBee, donc dans le terminal de X-CTU. Le résultat sera le suivant :

Mesure de distance avec une ArbotiX !

Voilà, le robot pourra bientôt se repérer avec ses 4 capteurs de distance parallax ! D'ailleurs, j'ai trouvé le résultat particulièrement précis (testé à 20cm, 40cm et 1m).

XBee : Hello World !

Les modules XBee sont des petits modems assez fascinants de par leur simplicité d'utilisation dans un univers embarqué, surtout si vous utilisez l'IDE Arduino (avec le shield adéquat) ou tout simplement ma divine ArbotiX.

Hello World

Le module XBee est directement connecté au port série de l'ATmega644P si bien qu'une simple commande "Serial." utilisera directement la communication XBee si vous en avez branché un. Alors si vous avez placé un autre XBee en écoute de l'autre côté, votre réseau fonctionnera comme par magie. De cette façon, on pourrait alors facilement imaginer un réseau de deux robots communicants (avec serial.print et serial.read)

En ce qui me concerne, je souhaite juste pouvoir lire la sortie de l'XBee connecté à mon USB Explorer. Pour cela, ouvrez X-CTU, connectez vous au XBee et utilisez l'onglet terminal.

Ensuite, il suffit juste de faire un tout petit programme pour la lecture et envoyer une réponse :

// valeur lue
int myData = 0;

void setup()
{
    // Démarrage du réseau série. Les modules XBee sont configurés en 38400bps. 
    Serial.begin(38400);
}

void loop()
{
    // Si on a des données sur le port série
    if(Serial.available() > 0)
    {
        myData = Serial.read();
        Serial.print("Hello World !");
    }
}

Dans le terminal, si on appuie sur une touche, on obtiendra alors :

Hello World sur XBee ;)

MAGIE =)

Reveil de Belma

Avec ses deux moteurs branchées à l'arrache (il me manque toujours deux câbles AX-12 que j'attends de recevoir), j'ai tout de même permis à Belma de se lever sur ses quatres pattes au moyen de PyPose. Comme vous pouvez le remarquer, la mise au repos est un peu violente (c'est surtout que j'ai oublié de passer par l'étape intermédiaire, mais chut). J'arrête par contre là les tests car les petits câbles volants se sont détachés un peu trop souvent, provoquant des résultats totalement aléatoires sur le réseau AX-12.
Mais oublions les mots et laissons place au moment tant attendu, la naissance de mon Quadropod !

Recharger une batterie LiPo

Recharger une batterie au Lithium Polymère n'est pas chose aisée. En effet, ses batteries sont plus légères, plus petites et de plus forte capacité que les NiMH mais sont assez capricieuses. Elles doivent être soumises à des règles strictes sous peine de perdre leurs avantages ou pire, de carrément devenir HS.


La batterie
La caractéristique la plus importante d'une LiPo est le nombre de cellules qui va nous permettre de connaître sa tension de sortie sachant qu'une cellule délivre 3.7V. Une batterie de 3 cellules délivre par exemple 11.1V.
Ensuite, sa capacité. Celle-ci est directement proportionnelle à sa taille et exprimée en mAh. Dans le cadre d'un projet de robotique comme le miens (12 servomoteurs), une batterie de 2000mAh devrait être suffisante.


Le chargeur
Pour charger une batterie LiPo, pas de secret, il faut un chargeur spécifique capable de charger des batteries en mode "balance charging". C'est à dire capable de contrôler séparément les tensions des différences cellules tout en chargeant.


La charge
Une batterie LiPo dispose en plus de son connecteur +/-, un connecteur spécial à brancher sur votre chargeur. Une fois que votre chargeur sera positionné en mode "balance charging", il pourra alors mesurer en temps réel le voltage des cellules et les additionner pour connaitre le voltage total.
En ce qui concerne ma batterie, c'est une 11.1V de 3 cellules et de capacité 2000mAh. En théorie, elle doit donc être chargée en 11.1V à 2A durant 1 heure environ. Cependant, elle est capable de charger à 4A, la charge devrait donc durer environ 30 minutes (35-40 minutes en pratique).
Une fois que vous aurez configuré votre chargeur, celui-ci va commencer par vérifier que la tension de votre batterie est correcte (c'est à dire environ 9-10V pour une 11.1). Si c'est le cas, il va envoyer l'ampérage que vous lui aurez demandé (4A dans mon cas) jusqu'à qu'une cellule atteigne 4,2V, soit 12,6V pour mes 3 cellules. Puis, il va baisser l'ampérage progressivement en vérifiant que le voltage de chaque cellule est toujours de 4,2V. Si celui-ci baisse, alors il remontera un tout petit peu l'ampérage. Et ceci jusqu'à atteindre zéro ampères. A ce moment là, votre batterie sera chargée.


Que faire si la vérification de tension ne passe pas ?
Il arrive parfois que la vérification de tension de votre batterie ne passe pas. C'est le cas notamment si votre batterie a été stockée pendant longtemps ou que celle-ci à du fournir un courant trop élevée (un court circuit par exemple). Pour résoudre cela, rechargez votre batterie en mode NiMH durant quelques minutes en contrôlant son voltage (qui va monter progressivement) jusqu'à atteindre environ 3,2V par cellule. Cela ne devrait pas durer plus de 3 minutes. Au dessus de 5 minutes, votre batterie est foutue.

Configuration des XBee avec X-CTU

Les XBee sont des petits modules absolument géniaux qui permettent de créer un réseau de communication série sans-fil. Cependant, pour pouvoir les utiliser, il faut d'abord passer par une étape de configuration.
Pour cela, vous aurez besoin d'un XBee USB Explorer :

L'USB explorer. USB à gauche et XBee à brancher sur le dessus.

Avant de commencer, il faut brancher l'explorer au PC au moyen d'un câble USB qui est généralement fourni. Si vous êtes sur Windows 7, les drivers seront installés automatiquement. Sinon, vous pouvez les télécharger sur le site FTDIChip.com.
Une fois installés, il faut installer le logiciel X-CTU qui permet de communiquer avec tous les produits de la marque Digi.
Commencez donc par brancher votre XBee sur la carte. Un petit voyant rouge s'allume vous signalant que la carte est installée. Lancez alors X-CTU et configurez l'onglet "PC Settings" de la manière suivante :

• Baud : 9600
• Flow Control : NONE
• Data Bits : 8
• Parity : NONE
• Stop Bits : 1

Et cliquez sur "Test / Query" pour vérifier que la communication passe.

Configuration initiale de X-CTU avec le module XBEE (XB24).

Maintenant, commençons les choses sérieuses. Allez dans l'onglet "Modem Configuration" pour configurer le module. En fait, un module XBee utilise un vieux protocole de modem en série. Vous savez, les 56k... Donc, chaque élément en vert correspond à une zone que vous pouvez configurer. Ces zones sont nommés par la commande "AT" qu'il faut lui envoyer pour y accéder. Par exemple ATBD correspond à la vitesse exprimée en bauds.

Configuration d'un XBee.

La plupart des zones sont utiles mais en ce qui nous concerne, nous allons nous intéresser à 4 zones. La première, ATID est l'identifiant de réseau. Cet identifiant va permettre à différents réseaux XBee de coexister. Par défaut, sa valeur est de 3332. Il vaut donc mieux le modifier et en choisir un commun entre tous nos XBee. Choisissez donc le numéro que vous souhaitez.

Une fois que nos XBee sont tous sur le même réseau, il va falloir créer un réseau de communication. C'est à dire que chaque XBee possède un identifiant (ATMY) et une destination (ATDL). Avec 2 XBee, c'est plutôt simple :)

Enfin, il reste donc la vitesse, soit ATBD. ArbotiX demande une vitesse de 38400bps.

Exemple avec deux XBee :

XBEE1 : ATID : 1234, ATMY : 1, ATDL : 2, ATBD : 5

XBEE2 : ATID : 1234, ATMY : 2, ATDL : 1, ATBD : 5

Pour chaque paramètre à changer, cliquez dessus puis sur "Write".


Enfin, il y a tout de même un autre paramètre qui pourrait éventuellement vous intéresser. Il s'agit de ATCH qui correspond au canal de communication sur la fréquence 2.4Ghz. En effet, cette fréquence est utilisée par presque tous les appareils du monde des jouets et du modélisme. Donc si vous remarquez que la communication passe mal lorsque votre fils/cousin/pote/voisin joue avec sa voiture téléguidée, il ne vous reste plus qu'à changer de canal sur tous vos XBee.

Montage du robot

Aujourd'hui, je me suis attaqué au montage du robot. A commencer par le perçage des plaques du corps. Je ne pourrais pas dire que c'était une tâche très aisée car les petits trous dans les angles sont très difficile à aligner. D'ailleurs, certains ne pourrons pas être vissés. La suite a juste pris du temps. Vissage, vissage et encore vissage. Par chance, je n'ai pas eu de problèmes au montage, tout est rentré dans l'ordre. Il me manque juste deux câbles AX-12.
Voici quelques photos du montage.

Vissage des pattes. Etape relativement courte comparé au vissage des composants des pattes :)

Montage de la plaque inférieure. Le robot a l'air d'être un bipède sur cette photo !

Fin du montage sans les câbles. Cette position sera celle de Belma quand elle sera éteinte.

Branchement d'un câble AX-12 entre fémur et tibia.

Ajustement des pattes pour la photo. Les moteurs non-alimentés portent difficilement le poids du corps.

Prochaine étape, montage de la batterie et confection des connecteurs pour la recharger facilement.

Construction du robot, prémices de conception

Je ne suis clairement pas un bricoleur. Du coup, mes outils de bricolage se limitent à une perceuse, des tournevis, quelques limes, un niveau, un mètre... Bref, vraiment pas grand chose. Juste de quoi faire quelques étagères dans mon appartement. Quoiqu'il en soit, pour Belma, il va falloir que je trouve quelques idées ultra simples à faire et si possible sans outil ou presque. Notamment pour les pieds qui devrons pouvoir gripper sur du parquet et le corps qui devra supporter la carte contrôleur.


Le support de carte contrôleur
Voici ce à quoi devrait ressembler le support de la carte.

Le futur corps de Belma. Une simple plaque d'aluminum.

Un pote m'a fourni ces belles plaques en aluminium brut qui devront accueillir l'arbotiX. Elles me semblent de bonne taille pour y ajouter un ou deux interrupteurs d'allumage. Entre les deux plaques, je pourrais ajouter le HUB pour y cacher les câbles ainsi que la batterie que le robot devra porter. Il ne me reste plus qu'à faire les trous pour fixer la carte et les futurs AX-12.


Construction d'une patte
Les pattes seront donc à 3 degrés de liberté (3DOF dans le jargon comme "degrees of freedom"). La partie fémur/tibia pourra être parfaitement à l'horizontal, tandis que le pied sera un peu décentré.

Une patte de mon robot. Durée de montage : 1 heure environ avec ses 31 vis.

Pour le pied, j'ai pris des supports pour pied de chaise en caoutchouc que j'ai rempli de colle de pistolet à colle. Pour l'instant, ça a plutôt l'air de bien tenir. On verra à l'usage. Si jamais ça devait se décoller, je pense qu'il faudra que j'ajoute une vis au centre.

Coder sur Arduino

Développer sur une plateforme Arduino est un jeu d'enfant si vous avez quelques connaissances en informatique. 


Le principe est le suivant : Vous avez 3 parties principales. La première est présente dans tous les langages informatique. Il s'agit de déclarer les fichiers entête ou librairies que vous souhaitez utiliser grâce au mot clé "include".

#include <Ethernet.h>

Dans cet exemple, vous utiliserez sans doute des fonctions réseau :)


La seconde partie s'appelle le setup. C'est la partie qui vous permet de déclarer comment la carte doit considérer telle ou telle broche.


Exemple avec une LED :

Vous branchez une LED sur la broche 13.

La carte Arduino ne peut pas deviner que vous avez branché une LED sur cette broche. Il faut donc le lui dire grâce au setup.

void setup() 
{                
  pinMode(13, OUTPUT);     
}

La fonction "pinMode" signale à la carte que vous voulez changer de mode à une broche. En l'occurence ici, 13. "OUTPUT" signale tout simplement que c'est une sortie.


La troisième partie concerne le programme. Celui-ci est appelé loop car il sera exécuté en boucle tant que la carte sera alimentée. Le nombre d'exécutions du loop par seconde est fonction du temps que prends votre code à être exécuté et de la fréquence du chip.


Pour faire clignoter la LED, vous écrirez donc :

void loop() 
{
  digitalWrite(13, HIGH);
  delay(1000);
  digitalWrite(13, LOW);
  delay(1000);
}

La fonction "digitalWrite" applique ou enlève une tension de 5V dans une broche. digitalWrite(13, HIGH) va donc appliquer une tension de 5V sur la broche 13 et donc allumer la LED.
La fonction "delay" provoque une pause où le paramètre est exprimé en millisecondes. Donc ici, une pause de 1 seconde.


C'est assez simple non ?


Pour avoir plus de détails sur les fonctionnalités de l'IDE Arduino, je vous invite à consulter le site officiel. Vous pouvez également trouver un tas de tutoriels sur le net, notamment les excellentes vidéos de Jeremy Blum.

Communication avec un AX-12

Le bus Dynamixel qui permet de communiquer avec les AX-12 possède l'avantage de pouvoir  relier les servomoteurs en série. C'est à dire que vous n'aurez besoin de brancher qu'un seul câble à vôtre carte contrôleur.

LE plus gros avantage des AX-12. Le branchement en série.

Cependant, vous allez me dire, comment faire alors pour les contrôler séparément ?

En fait, chaque servomoteur possède une micro mémoire qui contient ses informations et ses paramètres comme le voltage, la température ou la vitesse de rotation. Certaines parties sont accessibles en écriture et c'est d'ailleurs ce qui va permettre de les faire tourner. Une de ces mémoires contient un identifiant qui, tout comme le ferai une adresse IP, va nous permettre de les distinguer sur le même bus. La valeur d'identifiant est comprise entre 0x01 et 0xFF nous laissant une marge de 254 servomoteurs sur le même bus.

La mémoire interne d'un AX-12. L'ID se trouve en position 0x03.

Comme tous les AX-12 sont livrés avec un ID de valeur 1, il va falloir les changer. Pour cela, pas de mystère, il faut soit tout faire à la main (en récupérant une librairie compatible avec notre langage de programmation favori comme le C++ par exemple et en envoyant la commande sur le bus. Si ça vous intéresse, vous pouvez consulter le manuel complet ici), soit faire son feignant (comme moi) et télécharger l'outil adéquat nommé "RoboPlus". La dernière version est téléchargeable sur le site officiel.

Pour communiquer directement avec un AX-12 à partir de votre PC, il va vous falloir un USB2Dynamixel ainsi qu'une alimentation de 11V environ. En ce qui me concerne, j'utiliserai la batterie de mon futur robot. Vous devrez ensuite créer un petit montage très simple :

Montage d'un AX-12 en USB. PIN#1 et PIN#2 sont à connecter sur une alimentation d'environ 11V.

Lancez ensuite RoboPlus puis choisissez "Dynamixel Wizard". Sélectionnez ensuite le port COM où votre USB2Dynamixel est connecté (généralement c'est le seul qui n'est pas utilisé). Si vous ne savez pas sur quel port COM il est connecté, vous pouvez toujours essayer "auto detect". Cliquez ensuite sur "Start Searching" puis "Stop searching" dès qu'il aura trouvé votre AX-12 connecté.

Cliquez ensuite sur le servomoteur détecté. Vous apercevrez alors sur la droite les informations mémoires et vous pourrez alors en modifier certaines.

Modification de l'ID d'un AX-12.

Voilà, profitez en alors pour changer l'ID ;)

Modifiez ensuite l'ID de tous vos AX-12 un par un pour que chacun possède un identifiant unique. N'oubliez pas d'écrire sur chacun son numéro sinon vous serrez bon pour tout recommencer ☺

AX-12 identifiés. Désolé mon appareil photo à craqué sur le focus :)

N'hésitez pas à vous intéresser aux autres valeurs. Elles permettent de modifier pas mal de choses comme le mode continu "Wheel".

Installation des outils

Pour commencer, il faut s'équiper des logiciels nécessaires pour la programmation. Sachant que j'utiliserai les outils fournis avec l'ArbotiX, j'ai besoin des fichiers suivants (je travaille principalement sous Windows 7) :

• Visual Studio Express : pour développer en C/C++/C#. C/C++ car les librairies AX-12 sont développés en C. C# si je veux créer facilement des interfaces Windows.
• Python : pour développer en Python. Des outils fournis par le créateur de l'ArbotiX (Mike Ferguson) ont été développés en Python. Du coup, pas le choix même si je n'y connais rien dans ce langage :)
• wxPython et PySerial : le premier pour créer facilement des interfaces graphiques et le second pour permettre à Python de communiquer avec un port série (comme l'USB).
• Arduino : l'IDE/SDK pour développer les applications à télécharger dans le chip de l'ArbotiX. C'est un langage propre à Arduino mais qui ressemble beaucoup au Java/C#.
• Les librairies ArbotiX : disponibles sur la page "Getting Setup" de l'ArbotiX. Il s'agit des librairies propres à la carte, notamment pour contrôler les AX-12. Le téléchargement contient également l'application PyPose qui facilite la programmation des servos en enregistrant leur position à un instant T. Un petit raccourci assez pratique même si je devrait de toute façon commencer par apprendre à les capturer moi-même (bon, chut, je sais déjà le faire mais pas sur Arduino).
• La librairie RoboControllerLib : pour ajouter des librairies propres à l'ArbotiX afin de contrôler des capteurs, moteurs et surtout, le pad ;)

L'interface de développement Arduino. Simple mais efficace.

A partir de là, il suffit de suivre un peu la page GettingSetup afin de savoir où et comment installer tout ça.

Réception du Matos !

Et voilà, ma commande est arrivée ! En seulement 3 jours, c'est assez impressionnant... mais première mauvaise nouvelle, il manque 3 des 4 capteurs PING))). Le temps de régler l'affaire avec les vendeurs de Trossen Robotics, je pourrais toujours faire mes tests avec le premier capteur reçu.

Largement de quoi m'éclater ;)

C'est parti !

La commande est passée...

Bien que les boutiques de robotique commencent à se multiplier en Europe, les revendeurs Bioloid restent très rare et surtout un peu trop chers. La plupart du temps, c'est surtout des cartes et shields Arduino (fabriquées en Italie) qui sont vendus. J'ai donc passé ma commande auprès de http://www.trossenrobotics.com/ hier soir. Une boutique qui se trouve aux Etats-Unis. Espérons maintenant que les douanes ne vont pas demander leur chèque.

Et le gagnant est...

Les dés sont jetés. Je possède déjà des AX-12+, j'ai un appartement avec tapis et je trouve qu'il y a plus de challenge à faire un robot qui n'embarque pas de PC. Ce sera donc vers Robotis que je m'orienterai.


La carte mère
Une ArbotiX. C'est une carte très polyvalente, destinée au monde de la robotique, à la fois compacte, compatible avec les AX-12+ et les API Arduino de façon native. Elle coûte un peu moins de 80€. 

Elle a tout d'une grande.

Elle dispose de 3 bus pour AX-12+. Pour un Quadropod, il m'en faudrait 4, j'y ajouterai donc un HUB :

HUB Bioloid.

Ce HUB me permettra éventuellement d'ajouter une tête ou un bras plus tard.
L'ArbotiX possède 32 ports d'entrée/sortie dont 8 peuvent être utilisés en entrées analogiques. Cela me permettra d'y ajouter les capteurs nécessaires directement sur la carte.  Enfin, la carte dispose d'un bus série sur laquelle on peut mettre une plateforme de communication sans fil (appelé Xbee) d'une portée de 100m. En fait, cette carte devrait se suffire à elle même pour contrôler la totalité du Robot.


Les servomoteurs
Des AX-12+. Fleuron de l'univers Robotis. Un servomoteur de très bonne facture. Sa simplicité en font une aubaine pour les fans de robotique. 

L'AX-12+. Un petit bijou de servomoteur.

Voici ses principaux avantages :

• Excellent rapport qualité/prix
• Branchements en série. Inutile de tous les brancher sur la carte principale.
• Nombreux capteurs intégrés (vitesse, voltage, charge, température)
• Sécurités intégrées si la température est trop élevée par exemple.

Le Pad

Le pad est prévu pour fonctionner avec le module Xbee de l'ArbotiX. C'est donc encore un raccourci de facilité que je n'hésite pas à emprunter. Les difficultés ne manqueront pas par la suite alors autant les limiter un maximum par mes choix techno en utilisant des produits compatibles.

Le Pad avec son module sans-fil XBee.

Ce Pad est intéressant car il possède deux joysticks ainsi que 8 boutons. Il est alimenté par 4 piles LR6.

Les capteurs

Pour l'instant, je vais me limiter à 4 capteurs de distance. Je serai donc sans boussole ni gyroscope. Si besoin, j'y ajouterai plus tard un capteur type boussole pour éventuellement appliquer des corrections de positionnement.

Le capteur sera de type sonar. Plus performant qu'un capteur de type IR au niveau distance et précision mais moins rapide à cause de la vitesse du son. J'ai bien trouvé des capteurs de distance de type lasers mais beaucoup trop onéreux.

Mon choix s'est donc arrêté sur un "Parallax PING))) Ultrasonic Range Sensor" capable de mesurer une distance entre 2cm et 3m ce qui est tout à fait honnête.

Un nom barbare mais cela devrait faire l'affaire.

L'angle de vue de ces capteurs est faible (de l'ordre de 20°) ce qui est plutôt une bonne nouvelle car cela m'évitera les erreurs de calcul. Par contre, il faudra surement multiplier les mesures. Autre point, les spécifications constructeurs préconisent de mesurer la température ambiante car les résultats de distance peuvent varier. Je vais faire l'impasse pour l'instant vu que je devrais l'utiliser dans un environnement à température stable (18-23°C).

Choix techniques

Bon. Je ne sais pas encore à 100% vers quoi m'orienter. J'ai donc des centaines de possibilités concernant le squelette de mon futur robot. Un robot sur roues ? sur pattes ? Un gros robot ? Un tout petit ? Les questions fusent dans ma tête depuis des semaines. Voici les principales bases qui m'attirent.


TurtleBot
Ce petit robot basé sur un Roomba 5XX est vraiment alléchant.

TurtleBot. Un aspirateur aux pieds...

Il est simple et peut évoluer de centaines de manières. Grâce à sa base, il dispose déjà de nombreux capteurs et sa tête Kinect multiplie ses possibilités. Il embarque également un eeepc (que je possède déjà) et il dispose de pas mal de place pour ajouter d'autres éléments. Un bon choix je pense pour un projet comme le miens où je n'ai pas encore d'idée fixe sur le sujet.


Robotis
La technologie Robotis a de génial sa simplicité et ses performances. Sans vouloir acheter un kit Robotis, les servomoteurs AX-12+, les modules de communication ainsi que la communauté impressionnante suffisent à me conquérir.

Robotis. Des robots qui ressemblent souvent à ça.

L'avantage pour ce genre de robot est que je peux lui octroyer des pattes sans difficulté grâce à la librairie NUKE. Par contre, les cartes embarquées sont obligatoirement petites et peu performantes. Un ordinateur devra sans doute être présent en tant qu'assistant si je veux le doter de technologies comme la cartographie.
Second avantage et pas des moindres, il est compatible Arduino. Et là, c'est sans doute la plus grande communauté du monde en terme de domotique.

Projet : Belma.

Ce blog débute la longue histoire de Belma. Un robot autonome doté d'une micro-intelligence. Sa conception, sa naissance et son évolution seront comtés ici même.


Belma est mon premier robot. Même si ma passion pour la robotique n'est pas d'aujourd'hui et que j'ai déjà réalisé quelques micro-projets.


Mon objectif principal est la programmation plus que l'électronique. Même si cette dernière me sera sans doute indispensable dans certains cas, mes choix technologiques se porterons vers des solutions qui demandent peu d'électronique. Je n'ai pas trop envie de m'embêter à créer des cartes et monter des schéma (traumatisé par l'école ^^).


Afin de démarrer mon fil rouge, voici ce que je compte faire avec Belma.


Déplacement
N'ayant fait aucun choix technologique actuellement (même si j'ai bien quelques idées), Belma devra bien sûr pouvoir se déplacer de façon autonome. Sur roues ou mieux, sur pattes. Cette dernière étant un peu plus onéreuse et complexe mais intéressante.
Je souhaite que Belma puisse se déplacer en autonomie mais aussi au moyen d'une manette. Aussi, elle devra disposer d'une fonction sans fil.


Repérage/navigation
Bien entendu, Belma devra disposer de capteurs. Suffisamment performants pour mesurer des distances de façon précise entre quelques centimètres à plusieurs mètres. Ceci afin qu'elle puisse avoir son propre système de navigation.


Reconnaissance
Une partie que j'aimerai pouvoir ajouter à mon robot est la reconnaissance. Reconnaître des visages et réagir en fonction. Pouvoir les suivre ou s'en éloigner. Cette étape ne sera possible que si Belma embarque un ordinateur portable ou que celui-ci communique avec pour la piloter.


Manipulation
Cela pourrait être intéressant si Belma disposait d'un moyen de manipulation. Une pince, un bras... Les idées sont nombreuses.


Communication
Je n'ai pas encore trop réfléchi à cette partie mais Belma pourrait avoir un haut-parleur pour parler ou simplement émettre des sons. Et pourquoi pas imaginer un module de reconnaissance vocale ? Mais là encore, il lui faudra de la puissance de calcul et cette fois, obligatoirement embarqué (je n'imagine pas parler dans un PC à coté, cela manquerai de naturel).