XBee / XBee PRO

Echangez ici sur vos idées ou vos problèmes concernant vos circuits électroniques et électriques.
Discuss here the problems concerning your electronic and electrical circuits.
User avatar
goldorak
Posts: 94
Joined: Thu 17 Aug 2006, 11:38

XBee / XBee PRO

Post by goldorak » Sun 24 May 2015, 18:27

Salut,
J'aimerais savoir si dans la communauté des roboticiens il y a beaucoup de monde qui a déja utilisé le modules radio dites "XBee".
En particulier j'aimerais avoir un retex (retour d'experience) concernant les modules XBee PRO 868.
Merci d'avance pour vos réponses!
Goldorak

User avatar
VK
Posts: 23
Joined: Sun 01 Jun 2014, 14:54
Contact:

Re: XBee / XBee PRO

Post by VK » Wed 27 May 2015, 09:40

RCVA utilise du XBee (pro ?), j'ai entendu qu'ils envoient 10x chaque trame pour augmenter la fiabilité.

Je suis intéressé par les retours d'expérience aussi.

User avatar
Nirgal
Posts: 242
Joined: Mon 25 Oct 2010, 20:05
Contact:

Re: XBee / XBee PRO

Post by Nirgal » Thu 28 May 2015, 08:09

Nous utilisons des modules XBee Pro à 2,4Ghz...
Donc je suis hors sujet... mais je réponds quand même...

Mon retour d'expérience : n'utilisez pas le "mode standard" (où le module transfert les octets un par un... quand il en a envie...) Les octets peuvent même arriver dans le désordre...j'ai pas vraiment compris pourquoi !!! (ça fait drôle la première fois...)
Mieux vaut utiliser le mode API, dans lequel il est possible de transmettre en BROADCAST ou en MONOCAST, une trame COHERENTE de xx octets... qui est réémise par le module jusqu'à ce qu'elle soit acquittée (avec bufferisation et timeout)... On peut aussi envoyer sans acquittement et bufferisation (les amateurs de réseaux comprendront mieux sous les termes UDP et TCP...)
Le débit utile n'est pas super élevé... mais pas de souci pour des messages très haut niveau ("salut petit robot, je viens de faire le clap", "est-ce que je peux venir scanner un gobelet adverse ou est-ce que ca va gêner ta trajectoire ?", "oui, vas-y, j'ai plus besoin de passer par là")

Par contre, nous nous imposons une "règle d'or" : la communication ne doit jamais être indispensable... mais considérée comme du "bonus".
Si elle tombe, tout choix par défaut doit permettre de mettre quand même des points...
Quand un robot se trouve devant un élément manipulé par l'autre, il y reste seulement s'il en reçoit régulièrement l'autorisation... et s'en va si l'autre robot lui demande... ou si la com XBEE s'avère défaillante.

Pas de problème de cet ordre constaté lors des coupes cette année.

L'an dernier, j'ai sniffé les canaux pendant deux séries de matchs...
Quelques équipes étaient sur le même canal que nous... mais une seule "floodait" (µART, pour ne pas les citer).
Le fait d'avoir un identifiant de réseau sur 16 bits réduit nettement les risques d'être sur le même... (à condition sans doute de choisir autre chose que 1234...)
Nirgal
Robot-ESEO

Erasme
Posts: 7
Joined: Wed 17 Apr 2013, 19:43
Location: ENAC (Toulouse)

Re: XBee / XBee PRO

Post by Erasme » Thu 28 May 2015, 14:43

Nirgal a été plus rapide que moi, je suis globalement d'accord avec ce qu'il a dit, mais je vais quand même vous faire profiter du pavé que j'ai écrit (y'a pas de raison que j'ai écrit ça pour rien :D ).

Nous utilisons les Xbee (2,4 GHz aussi, mais je pense que c'est la même chose pour les autres) depuis maintenant quelques années (mais ils n'ont malheureusement jamais vraiment servi en match, pour cause de gros robot presque terminé).
Nous n'utilisons pas les version pro, donc je ne peux rien te dire sur les entrée-sorties.
Question de pure curiosité au passage, pour quelle application as-tu besoin de 80 km de portée ?

Tout d'abord, sur le fonctionnement du Xbee lui-même :

Pour ceux qui ont fait du réseau (je renvoie les autres à la page wikipedia sur le modèle OSI, lien à la fin), un Xbee s'occupe des couches 1 à 3 (physique, MAC/LLC, réseau). Nous n'utilisons au club que les fonctionnalités liées aux couches 1 et 2, donc je ne me prononcerai pas sur les fonctionnalitées de réseau (routage...).

Au niveau radio, le Xbee utilise de l'étalement de spectre à séquence directe (DSSS, lien à la fin ), une méthode qui permet d'augmenter très fortement la robustesse de la transmission. Nous n'avons pas eu de problèmes de portée au club, y compris quand notre robot était intégralement en tôle d'aluminium de 2mm ou dans une armoire métallique fermée. Il y avait toujours assez de fuites EM pour que le signal passe. Faut être raisonnable aussi hein, dans une boite métallique étanche au 2,4 GHz ça ne passera pas. En temps normal la portée n'était pas un problème à l'intérieur d'une même pièce, donc je ne pense pas qu'il y aie de difficulté sur une table de 2m*3m. Pour finir avec une anecdote sur la portée, l'équipe du laboratoire drone de notre école utilise des Xbee pour ses vols d'essais.
Nous n'avons pas pu utiliser pleinement notre lien Xbee en match, donc je ne pourrai pas me prononcer sur leurs perfomances en Olympe, mais l'année dernière au cosec ou cette année en athéna nous n'avons pas eu de problèmes de brouillage (alors que le wifi était souvent à la ramasse dans la même gamme de fréquences). Si besoin, on peut changer de canal et ajouter un cryptage.

Au niveau MAC, les Xbee gèrent les transmissions, acquittements et retransmissions éventuelles de paquets (CSMA/CA, cf 802.15.4). Les paramètres par défaut sont assez efficaces (nous n'en avons surtout pas essayé d'autres, et comme les résultats étaient satisfaisant nous nous en sommes contentés). On peut attribuer une addresse à chaque module, soit sur 16 bits, soit sur 64 bits (16, ça fait déjà 65536 possibilités).

Ensuite, sur l'utilisation et l'interfaçage avec le reste du robot :

Le module Xbee communique en UART. Attention, la vitesse de transmission qu'on spécifie dans les paramètres du Xbee est celle de l'UART, pas celle de la partie radio (qui est fixée). Autre spécificité, à cause d'une sombre histoire de diviseur de fréquence, l'UART du Xbee ne fonctionne pas exactement à 115200 bauds, mais à 111111. Pour les arduino ce n'est pas un problème (on peut spécifier des vitesses UART arbitraires dans Serial.init()). Par contre, sur linux, je n'ai pas trouvé de moyen simple de le faire. Dans ce cas, deux possibilités :
* soit fonctionner à une vitesse plus basse (57800 posait quelques problèmes aussi, en dessous ça allait),
* soit configurer l'UART en 115200 8N1 sur le Xbee et 115200 8N2 sur linux (hack trouvé je ne sais plus où sur internet, qui marche pas trop mal)
En fait, j'ai l'impression que nous perdions plus de messages à cause de la liaison UART qu'à cause du lien radio.
Remarque : dans une transmission, il faut prendre en compte le trajet des données et tous les liens traversés pour diagnostiquer le comportement. On passe au final 2 fois
sur de l'UART.
(appareil 1) <--uart--> (Xbee 1) <--radio--> (Xbee 2) <--uart--> (appareil 2)
Remarque 2 : il ne serait pas obligatoire de spécifier la même vitesse UART sur tous les Xbee du réseau. Je n'ai pas testé parce que tous nos microcontrôleurs supportent le 111111 bauds, mais je suis assez confiant là dessus.

Il existe deux modes de commande du Xbee : le mode "API" et le mode "série" :
* En mode série ("serial link replacement" je crois), le Xbee ne fait que recopier ce qui rentre dans sont UART sur la sortie de l'UART d'un autre module Xbee. Pas d'acquittement. Pour changer les paramètres du Xbee (par exemple le destinataire), c'est pas pratique et très long. Je conseille de ne l'utiliser, comme son nom l'indique, que pour remplacer un lien série point à point et parce qu'on a la flemme d'utiliser le mode.
* En mode API, il faut transmettre touts ses instructions (changements de paramètres) et messages à envoyer dans un format de trame bien spécifique. C'est plus contraignant, mais cela permet d'envoyer facilement les messages à un récepteur un particulier (comme ça pas d'interruption sur les autres), d'obtenir des informations sur le status de la trame envoyée (bien transmise sur l'UART, acquittement par le Xbee recepteur)... Des librairies existent pour ça (même si on a au final recodé la nôtre "from scratch").

Comme la couche MAC est entièrement gérée par le module Xbee, l'utilisateur n'a pas accès à certaines informations. Par exemple, il n'est pas possible d'avoir l'instant exact d'arrivée d'un message. Cela, couplé au fait qu'un même message peut être retransmi automatiquement plusieurs fois (donc la durée de transmission n'est pas constante), empêche de faire de la synchronisation de précision. À la louche, je dirais que le mieux qu'on puisse faire est de l'ordre de 10 ms. Cela nous a posé problème car on a besoin pour un système d'avoir une synchro avec une précision de l'ordre de 10 µs. On a du le résoudre avec un signal externe.

Le débit est assez limité (c'est de toutes façons au maximum celui de l'UART), donc ne compte pas transmettre des images dessus. La taille des messages aussi est limitée (de l'ordre de 100 O je crois, de toutes façons nous on utilise des messages de 64 octets).
A titre d'exemple, l'envoi et la réception d'un message de 64 octets via des Xbee connectés en UART à 115200 bauds prends 16 ms.




Là où mon avis diverge de celui de Nirgal c'est sur sa règle d'or. Attention, je reconnaît qu'elle est parfaitement raisonnable et très prudente, et je ne blâmerai personne pour l'utiliser.
Cependant, je considère le Xbee comme un lien comme un autre (UART, I²C, CAN...). Il a peut-être des taux de pertes plus élevés que les autres, mais refuser de dépendre des "communications" équivaut pour moi à refuser de dépendre de tous les autres liens série, ce qui veut dire n'utiliser qu'un seul calculateur et uniquement des capteurs qui y seraient reliés directement (pas d'ultrasons en I²C ou autre). Il faut partir du principe qu'il y aura des pertes de messages, des données corrompues, des dé-séquencements et il faut mettre en place des checksums et autres retransmissions, et coder nos applications de telle manière à être robuste à ces problèmes. Si si, des pertes de messages sur I²C ça c'est vu (muprhy aime les parasites de moteurs au démarrage).
Nous utilisons un réseau (au sens niveau 3, cf lien OSI) fait maison qui nous permet de transmettre de manière transparente des messages vers n'importe lequel de nos micro-contrôleurs, quel que soit le nombre de liens qui les sépare, par exemple (beagleBone IA)<--uart-->(LPC propulsion)<--I²C-->(Arduino actionneurs)<--bluetooth-->(PC de debug).
Le dimensionnement et l'architecture on été réalisés en fonction des applications et des débits qu'elles vont générer (par exemple, nous voulions un lien direct entre la propulsion et l'IA pour minimiser les délais). Ce que nous faisons pour les messages critiques (ordres de propulsion par exemple) est de les retransmettre tant qu'on n'a pas reçu d'acquittement (et là je parle d'acquittement de bout de bout, pas d'acquittement au niveau liaison).
L'avantage, c'est que ça simplifie énormément la programmation et apporte énormément de modularité. Par exemple, pour tester l'IA en simulateur, il "suffit" d'envoyer ses messages à un simulateur de propulsion. Autre exemple : l'IA tourne sur un PC, on a un bel affichage graphique pour le debug/les démos, et les messages sont envoyés par bluetooth.

(il convient peut-être à ce niveau de préciser que je suis justement doctorant en réseau, donc mont point de vue est assez orienté :wink: ).




https://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI
https://en.wikipedia.org/wiki/Direct-se ... d_spectrum

User avatar
GARGAMEL
PMI
Posts: 1184
Joined: Tue 14 Jun 2005, 17:16
Location: Ville d'Avray
Contact:

Re: XBee / XBee PRO

Post by GARGAMEL » Thu 28 May 2015, 15:37

VK wrote:RCVA utilise du XBee (pro ?), j'ai entendu qu'ils envoient 10x chaque trame pour augmenter la fiabilité.

Je suis intéressé par les retours d'expérience aussi.
L'an dernier mon équipe utilisait le pro 868 kHz avec beaucoup de problèmes. Peut-être trop de puissance avec phénomène de saturation ??

Cette année on est revenu au XBee S1 à 2.4 Ghz. et ça marche sans problème en mode point à point avec adresse du partenaire sur 16 bits.
Notre confiance dans ce matériel a été totale. Au point que le start du gros robot était commandé par XBee à partir du petit robot.
Pour le débogage du gros robot un adaptateur XBee-USB avec carte arduino a permis d'afficher sur l'écran d'un PC toutes une série d'infos en temps réel (Score, nombre d'objets embarqués, position, état de la tache en cours) ainsi que l'historique des taches. Ca a donné un plus considérable à Cédric pour la mise au point du programme manager du gros robot.
Last edited by GARGAMEL on Thu 28 May 2015, 16:05, edited 1 time in total.
RCVA: Robot Concept Ville d'Avray
http://www.rcva.fr

Erasme
Posts: 7
Joined: Wed 17 Apr 2013, 19:43
Location: ENAC (Toulouse)

Re: XBee / XBee PRO

Post by Erasme » Thu 28 May 2015, 15:43

GARGAMEL wrote: L'an dernier mon équipe utilisait le pro 868 kHz avec beaucoup de problèmes. Peut-être trop de puissance avec phénomène de saturation ??.
Est-ce que vous avez essayé de diminuer la puissance d'émission ? sur les 2.4 GHz je crois qu'il y a un paramètre pour ça, ça doit aussi être le cas sur les 868.

User avatar
GARGAMEL
PMI
Posts: 1184
Joined: Tue 14 Jun 2005, 17:16
Location: Ville d'Avray
Contact:

Re: XBee / XBee PRO

Post by GARGAMEL » Thu 28 May 2015, 15:56

Erasme wrote:
GARGAMEL wrote: L'an dernier mon équipe utilisait le pro 868 kHz avec beaucoup de problèmes. Peut-être trop de puissance avec phénomène de saturation ??.
Est-ce que vous avez essayé de diminuer la puissance d'émission ? sur les 2.4 GHz je crois qu'il y a un paramètre pour ça, ça doit aussi être le cas sur les 868.
Bien sûr. Même au niveau 0 de puissance (10 dBm autant que je me souvienne), les problèmes subsistaient.
Je pense que le niveau 0 du XBee Pro est déjà supérieur au niveau 4 du XBee 2.4 GhZ. A vérifier ?
RCVA: Robot Concept Ville d'Avray
http://www.rcva.fr

User avatar
pwet
Posts: 476
Joined: Mon 29 May 2006, 10:33

Re: XBee / XBee PRO

Post by pwet » Thu 28 May 2015, 16:56

Erasme wrote:Si si, des pertes de messages sur I²C ça c'est vu (muprhy aime les parasites de moteurs au démarrage).
Laisse moi deviner... des liaison I²C cartes à cartes je présume ? J'interviens au cas où de malheureuses âmes qui liraient ce message auraient l’incroyable idée de croire qu'une liaison synchrone, à la base conçue pour ne pas dépasser le périmètre d'un PCB, puisse se faire au moyen de câbles dans un environnement au bruit CEM bien incertain.
Erasme wrote:Là où mon avis diverge de celui de Nirgal c'est sur sa règle d'or. Attention, je reconnaît qu'elle est parfaitement raisonnable et très prudente, et je ne blâmerai personne pour l'utiliser.
Cependant, je considère le Xbee comme un lien comme un autre (UART, I²C, CAN...). Il a peut-être des taux de pertes plus élevés que les autres, mais refuser de dépendre des "communications" équivaut pour moi à refuser de dépendre de tous les autres liens série, ce qui veut dire n'utiliser qu'un seul calculateur et uniquement des capteurs qui y seraient reliés directement (pas d'ultrasons en I²C ou autre).
Tu peux considérer qu'une communication sans fil équivaut à une communication filaire dans la mesure ou dans les deux cas des contrôles d'erreurs doivent s'appliquer pour tendre vers un taux d'erreur nul. Mais tu dois aussi comprendre que dans le contexte de la coupe notamment, une liaison filaire correctement conçue peut fonctionner (très raisonnablement) sans contrôle d'erreur alors qu'une liaison sans-fil avec tous les contrôles d'erreurs imaginables (soft) peut ne pas fonctionner du tout. Je pense que votre désaccord est juste situé sur ces subtilités, et je me range totalement du coté de Nirgal.

Autre chose, d'après ce que tu dis, je comprend ton raisonnement de la manière suivante :
- Les communications sans fil sont proscrites
- Les communications sans fil sont des liens série
- Donc les liens série doivent être proscrits

Ben... non ! Ce n'est pas logique ! Et quand bien même tu enlèverais de ton robot les communications séries affectées par des parasites CEM, tu ne serais pas à l'abris que d'autres signaux puissent être affectés également. C'est pas pour rien qu'on essaye assez souvent de numériser les signaux analogiques au plus près du capteur et non du calculateur :)
Membre de OMyBot : Tant qu'ça roule, c'est cool !
http://www.omybot.com
Ex-membre de l'ISTY2000 (Institut de Science et Technique des Yvelines)
Ex-membre du CRIC (Club de Robotique de l'IUT de Cachan)

Erasme
Posts: 7
Joined: Wed 17 Apr 2013, 19:43
Location: ENAC (Toulouse)

Re: XBee / XBee PRO

Post by Erasme » Thu 28 May 2015, 18:45

pwet wrote: Laisse moi deviner... des liaison I²C cartes à cartes je présume ? J'interviens au cas où de malheureuses âmes qui liraient ce message auraient l’incroyable idée de croire qu'une liaison synchrone, à la base conçue pour ne pas dépasser le périmètre d'un PCB, puisse se faire au moyen de câbles dans un environnement au bruit CEM bien incertain.
Je n'irai pas dire le contraire. Après, l'I²C ressemble quand même énormément au CAN dans sa modulation et le reste de la couche physique, il manque juste un peu de CRC (ce qui est compensé par un checksum au niveau supérieur chez nous). Ce qui joue aussi c'est la qualité des câbles (très...artisanale chez nous), et les capas d'antiparasitages (non soudées :evil:), la qualité du circuit ... Nous avons aussi eu plus de problèmes avec de l'UART qu'avec de l'I²C. Pourquoi pas d'autres technologies (CAN justement) ? Principalement pour ne pas introduire une technologie de plus dans tout ce qu'on utilise déjà au club (et pour ne pas avoir à changer tous nos microcontrôleurs) alors que les performances de nos systèmes actuels sont satisfaisantes.
Mais on s'éloigne du sujet.
pwet wrote: Et quand bien même tu enlèverais de ton robot les communications séries affectées par des parasites CEM, tu ne serais pas à l'abris que d'autres signaux puissent être affectés également. C'est pas pour rien qu'on essaye assez souvent de numériser les signaux analogiques au plus près du capteur et non du calculateur :)
Parfaitement ! C'était une tentative de démonstration par l'absurde, je suis entièrement d'accord qu'il faut numériser au plus tôt les signaux, et donc utiliser des liens série, et donc ne pas se priver de sans-fil.
pwet wrote: Mais tu dois aussi comprendre que dans le contexte de la coupe notamment, une liaison filaire correctement conçue peut fonctionner (très raisonnablement) sans contrôle d'erreur alors qu'une liaison sans-fil avec tous les contrôles d'erreurs imaginables (soft) peut ne pas fonctionner du tout.
C'est justement le "ne pas fonctionner du tout" qui me chiffonne. Je n'ai pas eu l'occasion d'observer un black-out total de 90 secondes avec le Xbee (ni même de black-out du tout en fait, mais je manque de statistiques). Et le contrôle d'erreur ne fait pas tout, il faut aussi ajouter des acquittements, des retransmissions, un contrôle de l'ordre des messages...
Mais je comprends parfaitement qu'une liaison filaire est quasiment garantie (temps de propagation, pertes...), alors que le sans fil est plus aléatoire, ce qui fait peur. Tout va dépendre après de ce que tu peux tolérer dans tes applications (sachant que si tu retransmet, une perte n'est qu'un délai).
pwet wrote: Autre chose, d'après ce que tu dis, je comprend ton raisonnement de la manière suivante :
- Les communications sans fil sont proscrites
- Les communications sans fil sont des liens série
- Donc les liens série doivent être proscrits
Je le vois plutôt dans l'autre sens :
- pourquoi proscrire les liens sans-fil ?
- parce qu'ils sont peu fiables.
- Mais ils sont aussi fiables que les autres. (<- c'est mon avis personnel hein :wink: )
- Il faut donc proscrire les autres aussi.

Après ils ne faut pas me faire dire plus que ce que j'ai dit : chaque lien a ses propriétés intrinsèques, et je n'irai jamais utiliser un lien sans fil pour commander la propulsion (la fiabilisation via retransmissions se fait au dépend de la latence par exemple). Il y a, comme pour tout, un dimensionnement à faire quand on décide de sa topologie et de où passeront quelles applications.

Le but de ma remarque était double :
- tenter de tordre le cou cette idée que les liens sans fil ne sont pas fiables, et qu'il faut faire sans. C'était vrai il y a quelques années quand ils fallait tout se taper à la main, mais maintenant il y a des circuits intégrés qui font ça très bien (sinon le gros robot de RCVA serait resté dans les stands au moins une fois sur tous les matchs de la coupe, je ne crois pas que cela aie eu lieu).
- tenter d'expliquer pourquoi avoir une architecture de réseau partagée par tous les microcontrôleurs et autres raspberry est modulaire et pratique.

antoine_cvra
Posts: 446
Joined: Mon 27 Aug 2007, 18:05
Location: Suisse

Re: XBee / XBee PRO

Post by antoine_cvra » Thu 28 May 2015, 19:26

Euh la modulation / PHY de CAN et I2C ont pas grand chose en commun, rappel:
  • CAN se base sur une paire différentielle, I2C sur des signaux "standards". CAN a donc une meilleur CEM.
  • CAN est asynchrone, I2C est synchrone.
  • I2C est master-slave, CAN est multi-master.
  • CAN dispose d'arbitration de bus avec des priorités fixées. Ce qui se passe si 2 noeuds écrivent simulatnément sur le bus est défini par la spec, pas par l'impédance des câbles.
Un peu plus qu'un CRC à un niveau supérieur donc. D'ailleurs pas mal de protocole "haut niveau" sur CAN rajoutent encore un CRC supplémentaire si le message fait plus qu'un paquet (8 bytes).

Donc là dessus je rejoins l'avis de pwet: I2C ca va bien pour relier 2-3 chips sur un PCB, mais dès que tu passes sur des fils entre deux cartes la fiabilité va en prendre un coup.

User avatar
pwet
Posts: 476
Joined: Mon 29 May 2006, 10:33

Re: XBee / XBee PRO

Post by pwet » Thu 28 May 2015, 19:45

Heu oui je suis assez d'accord avec Antoine.
Erasme wrote:Le but de ma remarque était double :
- tenter de tordre le cou cette idée que les liens sans fil ne sont pas fiables, et qu'il faut faire sans. C'était vrai il y a quelques années quand ils fallait tout se taper à la main, mais maintenant il y a des circuits intégrés qui font ça très bien (sinon le gros robot de RCVA serait resté dans les stands au moins une fois sur tous les matchs de la coupe, je ne crois pas que cela aie eu lieu).
Et justement, le contre argument que j'ai à ça est notre propre expérience des modules tout fait de chez Microchip "MiWi"... Apres beaucoup de travail sur les contrôles d'erreurs, nous arrivions en condition de labo à 0% de trames perdues. A la Ferté, dans le Cossec pour l'homologation, non seulement on était plutôt à 90%/95% de trames perdues mais surtout les modules finissaient par crasher rapidement, fréquemment, et de façon erratique nécessitant de passer par un reset hard pour fonctionner de nouveau... Je crois qu'on a vraiment pas eu de chance, et que si on avait utilisé du Xbee les choses se seraient déroulées autrement, cependant on l'a payé très, très cher, tellement qu'on est devenu particulièrement frileux de la RF à la coupe.
Membre de OMyBot : Tant qu'ça roule, c'est cool !
http://www.omybot.com
Ex-membre de l'ISTY2000 (Institut de Science et Technique des Yvelines)
Ex-membre du CRIC (Club de Robotique de l'IUT de Cachan)

Erasme
Posts: 7
Joined: Wed 17 Apr 2013, 19:43
Location: ENAC (Toulouse)

Re: XBee / XBee PRO

Post by Erasme » Thu 28 May 2015, 23:07

antoine_cvra wrote: ...
  • I2C est master-slave, CAN est multi-master.
  • CAN est asynchrone, I2C est synchrone.
  • CAN dispose d'arbitration de bus avec des priorités fixées. Ce qui se passe si 2 noeuds écrivent simulatnément sur le bus est défini par la spec, pas par l'impédance des câbles.
Pour l'aspect multi-master et l'arbitrage, je te renvoie vers http://www.i2c-bus.org/MultiMaster/ (on l'utilise justement comme ça). Pour l'aspect synchrone je ne comprend pas la différence que ça va avoir sur ce qui nous intéresse (la fréquence du signal "clock" de l'I²C est indépendante de celle de l'horloge du microcontrôleur si c'est de ça dont tu parles). Je suis honnêtement intéressé par la différence que ça peut faire d'un point de vue des interférences.
Il est cependant vrai que je me suis laissé emporter, je n'ai pas fait attention au fait que ça tourne sur une paire différentielle.
Mais on s'égare encore (et c'est ma faute :( )
pwet wrote: Et justement, le contre argument que j'ai à ça est notre propre expérience des modules tout fait de chez Microchip "MiWi"... Apres beaucoup de travail sur les contrôles d'erreurs, nous arrivions en condition de labo à 0% de trames perdues. A la Ferté, dans le Cossec pour l'homologation, non seulement on était plutôt à 90%/95% de trames perdues mais surtout les modules finissaient par crasher rapidement, fréquemment, et de façon erratique nécessitant de passer par un reset hard pour fonctionner de nouveau... Je crois qu'on a vraiment pas eu de chance, et que si on avait utilisé du Xbee les choses se seraient déroulées autrement, cependant on l'a payé très, très cher, tellement qu'on est devenu particulièrement frileux de la RF à la coupe.
Et l'argument pour, c'est que ça marche pour d'autres, en particulier avec les Xbee en 2,4 GHz. C'est bien d'avoir votre retour d'expérience, comme ça on sait à quoi s'en tenir avec les MIWI. C'est vraiement dommage que ça aie été aussi douloureux pour vous :( .

Si j'avais conclu du problème qu'on a eu avec l'i²C que les liaisons séries ne marchaient pas et que j'avais recommandé de ne pas s'en servir, on aurait fait un robot entièrement mécanique :lol:. Au lieu de ça, plutôt que de blâmer le concept, on a regardé ce qui ne marchait pas, on a réglé le problème au niveau élec et on s'est assuré qu'au niveau soft on était capable d'y survivre. Et maintenant ça marche, nos messages vers la propulsion passent dessus.

Après, la question Xbee vs MIWI vs autres, c'est certainement la même que I²C vs CAN vs autres. Différents outils pour différents besoins, qui marchent dans certaines conditions et pas d'autres.

Erasme
Posts: 7
Joined: Wed 17 Apr 2013, 19:43
Location: ENAC (Toulouse)

Re: XBee / XBee PRO

Post by Erasme » Thu 28 May 2015, 23:09

Malgré nos divergences d'opinion philosophiques, c'est bien d'avoir des retours techniques de plusieurs équipes sur ça.
Pour résumer et répondre à la question de goldorak sur les XBee-like, ce qu'on a jusque là, si je ne me trompe pas, c'est que dans les conditions de la coupe :
  • Les XBee pro en 868 MHz, ça ne marche pas bien
  • Les XBee (pro) en 2,4 GHz, ça marche bien
  • Les MIWI, ça marche bien en test à la maison, mais pas dans le COSEC
Si d'autres veulent compléter la liste, allez-y !

arno
PMI
Posts: 732
Joined: Wed 23 Jun 2004, 21:51
Location: Un peu partout...

Re: XBee / XBee PRO

Post by arno » Fri 29 May 2015, 00:42

Erasme wrote:Pour l'aspect synchrone je ne comprend pas la différence que ça va avoir sur ce qui nous intéresse (la fréquence du signal "clock" de l'I²C est indépendante de celle de l'horloge du microcontrôleur si c'est de ça dont tu parles). Je suis honnêtement intéressé par la différence que ça peut faire d'un point de vue des interférences.
Sur un bus synchrone, il faut que le coup de clock tombe au bon moment par rapport à la présence des données.
Les problèmes de propagation du signal dans les câbles (pouvant être de longeur légérement différente donc temps de propagation différent, et tous les soucis d'adaptation de ligne) font que tu peux créer un décalage entre tes deux signaux clock et data, et donc pourrir tes données à l'arrivée du câble, c'est d'autant plus risqué que tu vas vite/que tes câbles sont longs.
Tu as aussi le problème de "diaphonie" ("cross-talk") où étant donné que chaque ligne passe des données différentes, elles se perturbent entre elles, au risque que l'impulsion du coup de clock fasse apparaitre un 1 sur la ligne de donnée par exemple. Sur une paire différentielle, c'est le même signal qui se propage sur les deux (seulement inversé, mais les mêmes fronts), donc tu as peu de diaphonie.

Une ligne asynchrone n'a pas autant ces problèmes, d'où le fait que tous les bus rapides ou longs sont de ce type (et différentiels en général): CAN, USB, HDMI, Ethernet je pense, ou encore la paire différentielle du SATA remplacant les 40 fils du bus parrallèle de l'IDE par exemple. Parce qu'à ces vitesses là, ça devient impossible de synchroniser tous les signaux, alors qu'une liaison asynchrone utilise le quartz du récepteur pour se recréer sa ligne d'horloge.
Je ne suis pas expert, si d'autres veulent me corriger, n'hésitez pas.

User avatar
alf@
Posts: 319
Joined: Sat 13 Aug 2011, 12:12
Location: Neuilly sur seine
Contact:

Re: XBee / XBee PRO

Post by alf@ » Fri 29 May 2015, 10:14

Et pendant ce temps là nous on utilise un bus RS485 faisant transiter des paquets adressés de 8 octets contenant des messages simples pour transmettre des ordres d'actions au sein du robot.
Coté RF une com' xBee est prévue entre les robots, mais on ne l'a pas encore utilisé. comme on garde nos cartes d'une année sur l'autre ça sera peut-être implémenté un jour, du coup merci pour les retours sur les ref qui passent à la coupe pour ces petits modèles.
Membre de l'équipe Goldorak, Ancien d'Eceborg: pour la méca, pour l'elec mais surtout pour le meilleur comme pour le pire,amis à vie avec Murphy!
Retrouvez moi sur mon twitter. Vous pouvez aussi me croiser à l'ECE Paris, à l'Electrolab et... dans la rue.

Post Reply