Un réseau sans-fil avec des XBee

Les modules XBee sont des circuits de communication sans-fil utilisant les protocoles 802.15.4 et Zigbee, permettant de réaliser différents montages, d’une liaison série RS232 classique à un réseau maillé (mesh) auto-configuré.

Un composant XBee série 1 coûte désormais moins de 20 euros.

Différents protocoles ont été implémentés sans que le packaging - désormais reconnaissable entre tous avec ses coins coupés - ne change. Il faut donc faire attention sur la série que vous utiliserez : le 802.15.4 des débuts jusqu’aux nouvelles Séries 2, ZNet 2.5 et ZB Zigbee. Les modules de séries différentes ne peuvent pas communiquer entre eux.

Selon les modèles et les pays, ils utilisent la bande des 2,4 gigahertz (comme le Wifi ou le Bluetooth) ou les 900 MHz. Selon leur puissance, ils émettent à une distance comprise entre 30 mètres et 1,5 kilomètre.

Ils sont développés à l’origine par la société Maxstream, devenue Digi. Vous pouvez toujours trouver en vente les premières séries du module marquée Maxstream.

Le débit peut atteindre 250 kbps, mais si on les utilise pour réaliser une liaison série sans fil, les débits standards sont compris entre 9600 bps à 38400 bps. La vitesse et la bande passante ont des effets sur les erreurs de transmission et ne sont pas possibles à obtenir dans tous les environnements.

Matériel pour un premier test

Nous allons utiliser ici des modules de la série 1, qui porte le nom du protocole IEEE : "802.15.4" (moins évolué que Zigbee mais déjà bien pratique). Pour l’usage que nous en ferons dans cet article, le modèle n’a pas d’incidence et vous pouvez réaliser ces mêmes tests avec une version 2 ou supérieure (à condition d’utiliser des XBee de la même série bien sûr).

Documentation technique

Le minimum à savoir est... minimal, car il faut surtout s’occuper de connecter les modules à vos équipements, et pas du tout besoin de savoir comment le protocole sans-fil fonctionne. C’est un peu comme pour un câble série : vous devez savoir quelle est la patte qui émet et la patte qui reçoit sans forcément vous préoccuper de la façon dont le courant électrique va traverser le fil de cuivre, même si certains devront s’en préoccuper pour des utilisations particulières.

Cette simplicité est un des principes qui ont fait le succès de ces modules, et que la société qui les conçoit s’emploie à conserver. Mais bien sûr on va aussi exploiter les possibilités de point-à-point ou de maillage (1 XBee écoutant plusieurs XBee).

Pour le détail, une datasheet est disponible sur le site de Digi ou des différents distributeurs.

Interfaces

Nous avons besoin d’interfacer le XBee avec des microcontrôleurs (pour que les robots communiquent entre eux) et aussi avec un simple PC (pour avoir une possibilité de télécommande ou de télémétrie.

Pour se connecter avec un microcontrôleur, on va simplement relier les pattes RX,TX de notre µC aux pattes Din et Dout et alimenter le module en 3,3 volts. Quelques autres pattes sont intéressantes, nous les détaillerons ultérieurement.

Voici le schéma réalisé par Yannick pour son propre circuit. Vous pouvez vous en inspirer pour votre propre microcontrôleur mais notez que c’est vraiment simple du côté XBee, il n’y a aucun composant supplémentaire.

Alimentation

L’intérêt du protocole 802.15.4 est d’être fait pour une puissance faible, avec une consommation réduite permettant de conserver un équipement autonome pendant une année, contrairement aux équipements Bluetooth par exemple.

Donc l’alimentation est un point essentiel. Au début, c’est vrai que ce 3,3 volts est un peu embêtant, car nous sommes habitués à utiliser des composants TTL en 5V (comme nos cartes à base de microcontrôleurs Atmel). Mais on s’y fait très bien et de plus en plus d’équipements sont en 3,3 volts.

En attendant, il existe des adaptateurs entre 5v et 3,3v. Et Yannick nous propose un circuit permettant d’alimenter en 3,3 volts un module XBee à partir d’une pile grâce à un convertisseur DC-DC "step-up" (le Max856 de chez Maxim) :

Shield XBee pour Arduino

Comme nous utilisons parfois des cartes Arduino, nous pouvons également utiliser une carte d’extension dédiée aux modules XBee qui ajoute des leds, un convertisseur 3,3 volts et des cavaliers de configuration permettant de conserver la liaison USB-série : le "Arduino Xbee shield".

Son utilisation est très simple : il faut mettre les cavaliers vers l’intérieur (i.e. selon inscription "XBee/USB", se mettre en position "Xbee") et désormais les pattes RX/TX de votre Arduino sont connectées au Shield XBee. Cela implique que vous devez changer de position (USB) quand vous voulez reprogrammer la carte.

Interface avec un ordinateur

Pour se connecter à un ordinateur (PC ou Mac), on réalise très facilement un circuit adaptateur en connectant un chip USB/série au module XBee. On trouve pour quelques euros des circuits à base de FTDI qui en plus offrent des leds indiquant la mise sous tension, la transmission / réception et l’appariement avec un autre module, toutes ces choses pratiques qu’on oublie souvent.

Mais si vraiment vous voulez le faire vous-même, suivez l’exemple très bien présenté de Totof :

• Un adaptateur USB pour XBee dans un boitier

Jouons avec les modules XBee

Il est temps de laisser de côté tous ces fils, ces câbles, ces composants et de passer aux travaux pratiques, avec un peu de logiciel.

Premier test

Par défaut, les circuits XBee sont faits pour se trouver tous seuls, s’apparier et fonctionner en liaison série. Les paramètres sont les suivants : 9600 bauds, pas de parité, pas de contrôle de flux, 8 bits et 1 bit de stop. On va le constater avec une Arduino.

Côté Arduino, rien d’autre que ce code :

void setup()
{
  Serial.begin(9600);
}

void loop()
{
  Serial.print('H');
  delay(1000);
  Serial.print('L');
  delay(1000);
}

Et côté PC, le bon vieil hyperterminal :

Le résultat est bluffant, puisqu’on dispose pour 30 euros d’une communication série sur plus de 100 mètres. Ce qui permet déjà de ressortir tous ses projets de mesure de température, alarme de boite aux lettres, etc..

Et pour un robot, on peut envisager de le contrôler ou de recevoir des tonnes de télémesures sans s’emmeler dans des fils qui s’enroulent autour :)

Second test

Mais que se passe-t-il si on utilise 3 modules ? Pour ce test, on va écrire un code avec un identifiant unique pour chacun, et un compteur.

int xbee_id = 0x01;   // ou 0x02

int count1 = 0; 
int count2 = 0;
int count3 = 0;

Chacune des cartes mobiles émet son adresse toutes les secondes.

  // toutes les secondes, envoie mon code
  Serial.write(xbee_id);
  delay(1000);

Lorsqu’il reçoit un code, tout module doit incrémenter le compteur correspondant :

      case 0x01:
        count1++;
        break;
      case 0x02:
        count2++;
        break;
      case 0x03:
        count3++;
        break;

Le module relié au PC permettra d’interroger chacun des modules embarqués sur une Arduino pour connaitre la valeur de leurs compteurs, en envoyant ’ ?’ sur la liaison série.

    int reception = Serial.read();
    switch(reception) {
      case '?':
        Serial.print("(");
        Serial.print(count1);
        Serial.print(",");
        Serial.print(count2);
        Serial.print(",");
        Serial.print(count3);
        Serial.println(")");
        break;
        ...
    }

Ainsi, on va pouvoir observer ce qui se passe en allumant et éteignant successivement un ou plusieurs modules.

Une fois chargé les programmes dans chacune des Arduino (en pensant à passer en mode USB pour le transfert et à changer l’ID dans le code avant compilation), on peut ouvrir un terminal série (ici, Docklight pour visualiser les valeurs décimales, hexadécimales ou ASCII) et observer ce qui se passe.

Tout d’abord, le GRAND avantage des XBee, c’est que les programmes ne plantent pas quand la connexion série est rompue, par exemple quand on éteint un des modules : la liaison série sur le microcontrôleur n’est pas ouverte avec un module précis mais avec le module XBee directement connecté, qui lui reste alimenté puisque branché sur la même alimentation. C’est vraiment pratique car le plus embêtant dans une liaison série classique, c’est de débrancher la carte et de faire planter tout le programme par une bête exception (ok, ça peut se gérer mais bon...)

Voici le résultat en images de ce second test. On a paramétré Docklight pour qu’il envoie le caractère ’ ?’ sur la liaison série du module USB toutes les 5 secondes.

Tout d’abord, on va allumer l’Arduino 01 : au bout de 2 secondes, on commence à recevoir ses "bips" (c’est notre Spoutnik moderne) puisqu’on observe 5 "01" (1 par seconde) dans la console en mode hexadécimal.

On éteint l’Arduino 01 et on allume l’Arduino 02 :

Pareil, 5 ’02’ sans avoir rebooté le module connecté à l’USB ! après un temps de démarrage de quelques secondes (promis, la prochaine fois je sors l’analyseur logique).

Premier test "critique" : on rallume l’Arduino 01, les deux sont donc allumées en même temps, soit 3 modules XBee en fonction. C’est éloquent : on reçoit à la fois les 01 et les 02 sur notre module branché au PC.

Second test "critique" : qui de la réception ? On va émettre depuis le PC l’identifiant ’03’ (Docklight nous permet de le faire juste en cliquant sur un bouton paramétré) :

Et bien ça marche : on s’aperçoit que les deux cartes Arduino ont incrémenté leur compteur n°3, preuve que le caractère a été reçu par les 2 modules.

Conclusion

On a donc SANS AUCUNE CONFIGURATION fait communiquer ensemble 3 cartes distantes de plusieurs mètres, de manière bidirectionnelle et multi-réception : ce qu’un module envoit, tout le monde peut le recevoir.

Il est donc désormais facile d’imaginer de contrôler des robots mobiles en envoyant à la fois des consignes communes de synchronisation puisque chacun des XBee va recevoir le message, ou bien en envoyant l’identifiant du module ciblé, d’en contrôler un en particulier, tout en laissant les autres robots libres de connaître les consignes envoyées.

C’est un grand progrès qui est accessible à tout le monde. On verra prochainement comment protéger tout ça en limitant la réception à des modules appariés, ou à un groupe de modules qui partage le même identifiant de groupe.