arduino sans fil, quelles solutions?

[valochonchon]

Bonjour,

Je travail sur un projet pour lequel je doit contrôler trois cartes arduino (2 uno et une mega) branchées à de multiples relays et moteurs et une quatrième carte contrôlant une horloge.
Mon panneau de contrôle est lui aussi basé sur arduino (mega).

Après quelques essais sur xbeeZB, je commence à penser que je devrais peut-être trouver une autre solution.
En effet, les objets que je cherche à contrôler doivent s'inscrire dans des sequences musicals, et ainsi les ordres donnés par le panneau de contrôle (une sorte de boite à rythme...) doivent être interpréter immédiatement par chaque module.

Par ailleurs, l'installation est faite pour du théâtre, ainsi une portée de 10 à 20 mètre est suffisante.

Ma question est la suivante, quel support de communication serait le plus adapté pour ce projet? sachant que:
-la communication se fait en sens unique; panneau de contrôle vers modules (x4).
-les informations peuvent être communiquées soit sous la forme d'une trame répétée continuellement, soit sous la forme d'ordre ponctuels.
-le but est de contrôler l'état de 5x8 relay, 5x4 moteur bidirectionnel et un des 5 mode de l'horloge.( pour donner un ordre d'idée des variable à manipuler...)
-le micro-contrôleur du panneau de contrôle est déjà relativement affairé, mais peut supporter de courtes interruptions. Les modules, eux on tous les temps d'interpréter des erreurs etc... leur programme est très basic.
-l'important est d'obtenir une bonne rapidité d'execution.(pouvoir envoyer/executer un ordre toutes les 5ms par exemple serait convenable)

En espérant ne pas être confus dans mes explications, merci d'avance.
-----

[r4ph]

Bonjour et bienvenue sur Futura,

Pour quelle raison penses tu devoir trouver une alternative aux Xbee? Pour en avoir déjà utilisé, vraiment je ne peux que les recommander! Cela dit n'importe quel transmetteur RF à 433Mhz ou autre à quelques sous sur ebay pourront probablement faire l'affaire. En revanche la programmation des récepteurs est un peu tricky. Ya mille et un exemples sur le web. Peut-être as tu plutôt une question sur un éventuel protocole, pour différencier les récepteurs?

[valochonchon]

Salut,

Tout d'abord, merci pour ta réponse.

J'ai passé quelques jour à tenter de configurer mes modules radio (XB24-Z7PIT-004 si ça peut aider) sans obtenir de résultats suffisants.

Tout d'abord en AT, avec le coordinateur en broadcasting. Les temps de latences sont définitivement trop long, sans parler de la quantité de transmissions qui se perde dans la nature lorsque que je commençais un peu à pousser le débit. (un problème de buffer si j'ai bien compris...)

Ensuite, je me suis pencher sur le mode API. Via la librairie xbee-api pour arduino mais les commandes ralentissent trop le programme du panneau de contrôle.
Puis finalement j'ai créer un code qui fabrique les trames pour le mode API d'après la doc et d'autres codes pompés sur le net. Mais j'ai Jamais réussi à le faire marche correctement. Ne serait-ce qu'en faisant marcher le panneau de contrôle et en essayant de récupérer les donné sur l'ordi via un xbee explorer.

Bref, après quelques lectures sur le sujet, j'ai l'impression que la façon don fonctionne le protocole ne corresponds pas l'utilisation que je veux en faire. Et principalement pour des questions de débit et de synchronisation de mes différents modules.

Pour toi, cela semblerait tous de même faisable avec des xbee?

[antek]

En 433 MHz simple on peut fabriquer son propre protocole facilement.
A 9600 bps (air-rate) j'envoie au moins 8 octets toutes les 15 ms avec un µC très occupé.

[A voir en vidéo sur Futura]

[r4ph]

En tout cas on peut dire que tu as essayé! C'est vrai que dans mon cas j’utilisais le Xbee "émetteur" en standalone, sans uC, programmé pour envoyer cycliquement (100ms) des états de ses entrées (digital et analog). Le "récepteur" récuperais les données avec des trames API. On est loin des 5ms dont tu as besoin. De quel poids de donnée parle t'on?

antek à la meilleure solution je pense...

[alainav1]

Bonjour,
juste une piste
la commande infrarouge pour ces distances c'est pas mal ?
c'est facile à programmer et c'est fiable .
cordialement
Alain

[valochonchon]

Merci pour tous ces conseils...

Concernant les infrarouge, Alainav1, un ami à moi a déjà bosser avec pour une spectacle théâtral, il m'a dis qu'il avait perdu 10 ans d'espérance de vie sur ce projet, le résultat final ressemblait vaguement à une partouze de robot.
Le problème réside dans la diversité et la puissance des éclairages déjà présent sur scène, ça parasite le système à coup sûr...

Pour ce qui est du poids en terme de donné:
Le protocole de commande que j'ai déjà mis en place en vue d'une liaison sérielle est basé sur des instructions de 8 octets avec:
-2 octets d'ouverture de message
-1 octet stipulant la nature de la commande
-5 octet pour le contenue de la commande.
Ca c'est dans l'idée d'un système qui enverrai des ordres de façon ponctuel.

Dans une autre configuration ou une trame qui contient tous les états des relays et moteurs serait envoyer de façon constante et où les modules se mettrait ajouter après avoir reçu deux ou trois fois la même trame ça donnerait:
-+/- 2 octets ouverture du message
-5 octets, états des relays.
-5 octets, états des moteurs.
-1 octet vitesse des moteurs.
-1 état de l'horloge.
Ca fait une peut plus de donnés mais j'ai le sentiment que ce serait plus stable de gérer ça de cette façon tant au niveau de l'interpretation coté module que de la synchronisation.

Evidemment pour mois cela n'est que purement spéculatif, je suis totalement novice face à ce type de dispositif.

Par ailleurs, même si la solution d'Antek semble la plus performante, j'ai peur qu'elle ne puisse pas subvenir entièrement à mes besoins.
J'ai beau chercher je n'arrive pas à trouver un dispositif qui permettrait de mettre en place une trame diffuser en continue et exécuter via des "internal interrupts" qui permettrait de n'avoir qu'une variable à modifier pour diffuser un changement d'état pour mes modules.

Dans tous les cas merci pour ces réponses ça m'aide à me poser les questions différemment.

[r4ph]

Ir ou RF les deux ont leurs forces et faiblesse, voir ce que le demandeur en pense...

edit: j'ai oublié le refresh...

[r4ph]

Tu peux mixer les 2 modes en mettant un système d'adresse dans la trame. L'émetteur s'adresse seulement à un récepteur en particulier (adr 1 à 4) ou en broadcast à tous (adr 0xFF). dans le deuxième cas, les recepteurs savent qu'il doivent interpréter la trame différemment.

A priori, le 433MHz n'est pas fait (légalement) pour une émission continue. Dans l'enceinte d'un théâtre faut voir. Mais c'est sur que tu aura moins de problè,e en continu avec la synchro des récepteurs.

Un bon tuto à propos des modules cheaps: http://www.romanblack.com/RF/cheapRFmodules.htm

Si tu veux j'ai une ébauche de projet de trame utilisant la méthode décrite plus haut mais il faudra le modifier. Il ya pas mal de bytes dans ma trame et se sera lent par rapport au 5ms. Mais ça marche pas mal.

[USMC]

Hello,

Et du Wifi ça ferait pas l'affaire ?
Le délais de transmission devrait être plus court non ?

J'ai trouvé une référence : ESP8266. Il y a surement mieux mais jette un coup d’œil pour voir.
A+

Cordialement

[r4ph]

Mais la solution en lien avec l'IDE et les fonctions Arduino, je pense pas ça va le faire. Tu as surement meilleur temps d'essayer avec l'uart.

Wifi, pourquoi pas il y a beaucoup d'exemple avec l'ESP8266. Perso jamais essayé...

[antek]

Par ailleurs, même si la solution d'Antek semble la plus performante, j'ai peur qu'elle ne puisse pas subvenir entièrement à mes besoins.
J'ai beau chercher je n'arrive pas à trouver un dispositif qui permettrait de mettre en place une trame diffuser en continue et exécuter via des "internal interrupts" qui permettrait de n'avoir qu'une variable à modifier pour diffuser un changement d'état pour mes modules.

"trame diffusée en continu" ??
Peux-tu détailler les données utiles que doivent recevoir chacun des 4 modules ?

MODULE_1
- vitesse moteur 1
- sens moteur 1
- relais 2 OFF

MODULE_2
- etc

Je pense qu'on peut gagner du temps sur l'envoi de chaque commande.
Par contre est-il impératif d'envoyer une commande toutes les 5 ms (200 fois par seconde) ?

[valochonchon]

Bonjour,

Je me prête à l'exercice mais j'ai réalise hier qu'il y a effectivement une solution pour diminuer drastiquement le débit nécessaire, je m'étendrait la dessus plus bas.

Ainsi:
Module 1 (arduino mega)

3-3 cartes de 8 relais (3 bytes soit 1bit par relais)
1-vitesse moteurs (la même vitesse pour tous les moteurs et pour tous les moteur donc un byte dans la trame suffirait pour tous les modules, soit un byte)
3-3 cartes de 4 moteurs (les moteur contrôlent l'ouverture et la fermeture de portes qui est géré par chaque modules grace à des interrupteur de fin de course, ainsi pour chaque moteur 2 bit sont nécéssaire, 00=moteur stop, 01=moteur ouvre, 10=moteur ferme, 11=moteur fait faire des aller retour à la porte. donc 3 bytes soit 2 bit par moteur)

Module 2(arduino uno)
1-1 cartes de 8 relais (1 byte soit 1bit par relais)
0-vitesse moteurs(0 byte, déjà compté plus haut)
1-1 cartes de 4 moteurs (1 bytes soit 2 bit par moteur)

Module 3(arduino uno)Idem
1-1 cartes de 8 relais (1 byte soit 1bit par relais)
0-vitesse moteurs(0 byte, déjà compté plus haut)
1-1 cartes de 4 moteurs (1 bytes soit 2 bit par moteur)

Module 4(arduino uno, horloge)
1-mode horloge.(7 mode différents un byte devrait suffire)


La solution qui vise à mixer la méthode trame et la méthode ordre est ingénieuse mais dans certaine cas elle ne sera pas valide car pas moment elle demanderai de soumettre trop d'ordre simultanément.


Pour en revenir à la solution à mon problème mais qui n'est pas vraiment la solution au problème posé, je dois m'attarder un peu sur la nature du dispositif.

Comme évoqué plus haut le panneau de contrôle fonction comme une sorte de séquenceur/boite à rythme qui doit orchestrer les modules pour qu'ils produisent des séquences musicales grace à l'allumage et l'extinction des différents objets actionnés par les relays.

Ainsi, on a des séquence de 4 à 32 temps (step), la durée de chaque temps varie selon le tempo (100ms à 1500ms) et chaque objet à un ratio faisant varié sa durée d'allumage par temps (0ms à tempo). C'est ce principalement ce ratio qui fait que le système nécessite un débit important.
Par exemple pour des temps de 100ms il peut m'arriver d'avoir à commander jusqu'à 16 extinction...(c'est le pire cas en fait...mais bon, il faut toujours envisager le pire.)


Dans mon cas je pense que le début de la solution est la suivante:

-Reproduire une partie du code séquenceur/panneau de contrôle dans chaque module, de manière à ce qu'ils puissent ordonner par eux-même les extinctions. En l'occurence le système de timing, le contenue des séquences, la valeurs des ratios d'extinction etc...
-Inclure dans la communication l'ordre de passé aux temps suivants.
-Reformuler le dialogue entre les module et le panneau de contrôle de façon à que les ordres venant du panneau n'affecte plus directement l'état des relays et moteur, mais les variables qui permettent à chaque module de les animer.(Je ne sais pas si c'est très clair...) C'est à dire à chaque fois que j'appuie sur un bouton du panneau cela affecte les mêmes variables coté panneau et coté module.

Avec ça il devrait être possible d'envoyer des ordre sur 4 ou 5 bytes, seulement lorsque bouton et pressé ou lorsqu'il y a un changement de temps. Soit grand max 30 ou 40 ordre/ms dans le cas d'un potard actionné sur le panneau.

En somme beaucoup de joie et d'amusement en perspective, une belle refonte de code!

En tous cas merci pour toute vos réponses, ça aide bien.

Antek, Si tu as une ébauche du protocole dont tu parle plus haut à céder, je suis fort intéresser.

En ce qui concerne l'ESP8266, je suis aller fouiller rapidement. Je ne sais pas si j'ai tout bien compris, n'y a-t-il pas de temps de latence assez important? Dans les exemple que j'ai vu cela n'avait pas l'air de produire des systèmes très réactifs. Quelqu'un a déjà testé?

[valochonchon]

Bonjour,

Je me prête à l'exercice mais j'ai réalise hier qu'il y a effectivement une solution pour diminuer drastiquement le débit nécessaire, je m'étendrait la dessus plus bas.

Ainsi:
Module 1 (arduino mega)

3-3 cartes de 8 relais (3 bytes soit 1bit par relais)
1-vitesse moteurs (la même vitesse pour tous les moteurs et pour tous les moteur donc un byte dans la trame suffirait pour tous les modules, soit un byte)
3-3 cartes de 4 moteurs (les moteur contrôlent l'ouverture et la fermeture de portes qui est géré par chaque modules grace à des interrupteur de fin de course, ainsi pour chaque moteur 2 bit sont nécéssaire, 00=moteur stop, 01=moteur ouvre, 10=moteur ferme, 11=moteur fait faire des aller retour à la porte. donc 3 bytes soit 2 bit par moteur)

Module 2(arduino uno)
1-1 cartes de 8 relais (1 byte soit 1bit par relais)
0-vitesse moteurs(0 byte, déjà compté plus haut)
1-1 cartes de 4 moteurs (1 bytes soit 2 bit par moteur)

Module 3(arduino uno)Idem
1-1 cartes de 8 relais (1 byte soit 1bit par relais)
0-vitesse moteurs(0 byte, déjà compté plus haut)
1-1 cartes de 4 moteurs (1 bytes soit 2 bit par moteur)

Module 4(arduino uno, horloge)
1-mode horloge.(7 mode différents un byte devrait suffire)


La solution qui vise à mixer la méthode trame et la méthode ordre est ingénieuse mais dans certaine cas elle ne sera pas valide car pas moment elle demanderai de soumettre trop d'ordre simultanément.


Pour en revenir à la solution à mon problème mais qui n'est pas vraiment la solution au problème posé, je dois m'attarder un peu sur la nature du dispositif.

Comme évoqué plus haut le panneau de contrôle fonction comme une sorte de séquenceur/boite à rythme qui doit orchestrer les modules pour qu'ils produisent des séquences musicales grace à l'allumage et l'extinction des différents objets actionnés par les relays.

Ainsi, on a des séquence de 4 à 32 temps (step), la durée de chaque temps varie selon le tempo (100ms à 1500ms) et chaque objet à un ratio faisant varié sa durée d'allumage par temps (0ms à tempo). C'est ce principalement ce ratio qui fait que le système nécessite un débit important.
Par exemple pour des temps de 100ms il peut m'arriver d'avoir à commander jusqu'à 16 extinction...(c'est le pire cas en fait...mais bon, il faut toujours envisager le pire.)


Dans mon cas je pense que le début de la solution est la suivante:

-Reproduire une partie du code séquenceur/panneau de contrôle dans chaque module, de manière à ce qu'ils puissent ordonner par eux-même les extinctions. En l'occurence le système de timing, le contenue des séquences, la valeurs des ratios d'extinction etc...
-Inclure dans la communication l'ordre de passé aux temps suivants.
-Reformuler le dialogue entre les module et le panneau de contrôle de façon à que les ordres venant du panneau n'affecte plus directement l'état des relays et moteur, mais les variables qui permettent à chaque module de les animer.(Je ne sais pas si c'est très clair...) C'est à dire à chaque fois que j'appuie sur un bouton du panneau cela affecte les mêmes variables coté panneau et coté module.

Avec ça il devrait être possible d'envoyer des ordre sur 4 ou 5 bytes, seulement lorsque bouton et pressé ou lorsqu'il y a un changement de temps. Soit grand max 30 ou 40 ordre/ms dans le cas d'un potard actionné sur le panneau.

En somme beaucoup de joie et d'amusement en perspective, une belle refonte de code!

En tous cas merci pour toute vos réponses, ça aide bien.

Antek, Si tu as une ébauche du protocole dont tu parle plus haut à céder, je suis fort intéresser.

En ce qui concerne l'ESP8266, je suis aller fouiller rapidement. Je ne sais pas si j'ai tout bien compris, n'y a-t-il pas de temps de latence assez important? Dans les exemple que j'ai vu cela n'avait pas l'air de produire des systèmes très réactifs. Quelqu'un a déjà testé?

[r4ph]

On récapitule
-1byte commun vitesse de moteur
-6 byte pour module 1
-2 bytes module 2
-2 bytes module 3
-1 byte module 4

12 bytes de datas en tout, répétés au plus rapide toutes les 100mS

Rajoute à ça un byte de synchro et un byte de start. Puis tu envoie tout l'un derrière l'autre. Chaque module sait que les datas qui le concernent sont x bytes reçus après le start.
Forme de la trame SYNC, START, VITESSE, MOD1RELAIS1-8, MOD1RELAIS9-16, MOD1RELAIS17-24, MOD1MOT1-4, MOD1MOT5-8, MOD1MOT9-12, MOD2RELAIS1-8, MOD2MOT1-4, MOD3RELAIS1-8, MOD3MOT1-4, MOD4HORLOGE

100mS/14bytes/9bits = 0,8mS maximum

fréquence minimum de l'uart = 1265 Bps... A augmenter bien sur, dépendant de la qualité de la transmission RF et du délai acceptable, mais si la validité de la nouvelle valeur reçue est synchronisée sur le dernier byte reçu, tous les modules seront synchrones.

[r4ph]

Synchrone entre eux je veux dire. Il y aura un délai avec le séquenceur...

[antek]

Pas tout compris. Tes modules sont éloignés de quelle distance entre eux ?
Chaque module reçoit ses ordres indépendamment des autres?

Concernant les ordres envoyé en RF, ils sont de 2 sortes :
1 - les ordres direct (relais on/off, vitesse moteur, sens moteur)
2 - les ordres de séquence (mouvement porte avec allumage en fin de course, flash lumière avec génération son, etc)
Jusque là j'ai bon ?

Ensuite sur combien de bit veux-tu coder la vitesse moteur ?
Je propose de se limiter au minimum acceptable (5 bit, 7 bit ?).

[antek]

Ce qu'on appelle module c'est un récepteur suivi d'une ou plusieurs cartes ?
Excuses- moi pour ces questions triviales mais pour proposer des solutions vaut être sûr d'avoir bien compris !
J'attend les réponses ç ces 2 post pour proposer.