highspeed wireless [Forums - Hardware]
highspeed wireless [Forums - Hardware]
Pseudo Pass se souvenir de moi     Créer un compte
ARTICLES et TELECHARGEMENTS ~ FORUMS ~ LIENS  
 
             
 
Recherche
 
   
 

Parcourir ce sujet :   1 Utilisateur(s) anonymes



(1) 2 »


highspeed wireless
Accro
Inscrit:
29/08/2006 10:42
De cambrai
Messages: 658
Hors Ligne
Bonjour à tous,

Je suis un peu hors sujet, mais ça fera peut être vivre un peu le forum.

Voilà, je suis à la recherche d'une liaison wireless type UART (ou autre) <-> wireless <-> UART (ou autre) capable de passer au moins 1Mbps.
L'appli ne change pas (toujours le robot), dans lequel j'ai un bus RS485 à 1Mbps (j'étais à 2, mais par sécurité il est repassé à 1) permettant un échange de données et d'ordres entre différentes cartes.
Hors dans le cas de l'utilisation d'un second robot, l'idéal serai de pouvoir faire passer ce bus par les airs, afin que ce second robot ne paraisse qu'une extension du premier, et ainsi de pouvoir continuer à espionner les messages échangés pour le debug.

Le principe des modules Xbee est sympa, le problème c'est le débit, à 115k, ça va vite bourrer en entrée. Donc je cherche quelque chose dans le même genre, mais plus rapide.
J'ai cru lire, que des modules Bluetooth passent 4Mbps, quelqu'un a-t-il déjà testé? Qu'en est-il pour faire du multi-points? Bi-directionnel?

Je peux très bien avoir un petit uC en entrée/sorties des modules afin de décoder les messages et les renvoyer sur le bus au bon débit/format si besoin.

Mici,
Maverick

Posté le : 05/11/2013 11:40
Transférer la contribution vers d'autres applications Transférer


Re: highspeed wireless
Pilier de la communauté
Inscrit:
13/10/2005 10:06
De haute-savoie (74)
Messages: 1162
Hors Ligne
salut
tu as quoi comme données à transmettre qu'il te faille un tel débit ? 1Mbits/s c'est énorme, tu peux passer carrément plusieurs flux vidéo !

Stéphane

Posté le : 05/11/2013 21:20
Transférer la contribution vers d'autres applications Transférer


Re: highspeed wireless
Pilier de la communauté
Inscrit:
13/10/2005 10:06
De haute-savoie (74)
Messages: 1162
Hors Ligne
pour ce type d'échange entre cartes, as tu regardé le CAN ? Cela se prete mieux je pense que le RS485 dans ce cas là.
Par contre il n'y a pas de CAN wireless !

Par contre si tu dois échanger en multipoint, alors le protocole AX25 peut être intéressant, mais par contre tu n'auras pas ce genre de débit...

Stéphane

Posté le : 05/11/2013 21:21
Transférer la contribution vers d'autres applications Transférer


Re: highspeed wireless
Modérateur
Inscrit:
24/09/2005 13:30
De 04110 - VACHERES- FRANCE
Messages: 1494
Hors Ligne
Il va te rester que le WiFi...

Yvan

Posté le : 05/11/2013 21:28
Le houblon, c'est bon pour la récupération.
Transférer la contribution vers d'autres applications Transférer


Re: highspeed wireless
Accro
Inscrit:
29/08/2006 10:42
De cambrai
Messages: 658
Hors Ligne
En fait, c'est pas vraiment le volume, mais plutôt le fréquence de mise à jour.

Pour schématiser, j'ai une carte principale qui gere la stratégie, les actions, l'évitement des adversaires.
Autour gravitent plusieurs cartes (identiques) pour "la puissance" (asservissement, moteurs, servos, capteurs...)
Chacune de ces cartes est reliée au Bus principal.
Les messages s'échangent sous forme de messages type GCODE.
Toutes les cartes reçoivent tous les messages, et chacune traite ceux qui lui sont adressés.

Les cartes puissance, sont interrogées chacune leur tour avec 10ms intervalle.
Hors, entre la question et la fin de la réponse, je suis à 7 ou 8ms à 1Mbits/s (j'avais 4ms à 2Mbits/s).
Avec 4 cartes, j'ai une mise à jour toutes les 40ms, à une vitesse de 1m/s,le robot a déjà parcouru 40mm...
Si je réduis le débit, je dois donc réduire la fréquence de mise à jour de l'ensemble.

Je pensais bien au Wifi, mais avec un doute sur la complexité de la mise en place et le délai de transmission ajouté, bien qu'avec un avantage non négligeable pour le debug directement via le Wifi du PC.

Pour Stephane, pour le CAN, j'y ai regardé (enfin rapidement), le choix porté sur du RS485 est dû à l'utilisation de uC sans module CAN, un simple UART suffisait.
Mais aussi car le RS485 n'est utilisé que pour la possibilité de multipoint. Sans respect du protocole, un perso est utilisé comme suit:
:1G0X1000Y1000

:1 adresse de la carte destinataire (facultatif dans le cas ou toutes les cartes sont ciblées)
G0 deplacement en marche avant
X1000Y1000 coordonnées à rejoindre

Avec le CAN (à ce que j'en ai tiré d'une lecture très rapide) ou de 'IIC, j'étais obligé d'utiliser une adresse et un format donné, ici je suis libre de mettre en forme mes messages en fonction de ce que je veux envoyer et à qui l'envoyer.
Pour le Debug, un simple max485 + ft232 et hop, un renifleur facile de tout ce qui se passe, une appli C# et j'ai un visuel sur la position du robot, des actionneurs, une représentation graphique du chemin qu'il veut prendre pour éviter les obstacles (pathfinding), les choix d'actions qu'il fait, pourquoi...Et je peux à mon tour lui envoyer des ordres "humain readable". Tout le monde est au courant de tout ce qui se passe et peur agir en conséquence.

Et là, je me retrouve coincé à faire deux robots.
Je pourrai ne pas passer par le bus, pour le second robot, faire qu'il ai son propre bus sans liaison avec le premier, mais les lier permet de n'avoir qu'une seule stratégie qui considère le second robot comme une partie du premier sans distinction si un capteur se trouve sur l'un ou sur l'autre, il est interrogé de la même manière de façon transparente.

Je pourrai écrire un roman sur ce développement qui m'a vraiment fait plaisir à faire si ça vous intéresse.

Je vais continuer mes recherches, voir du côté du Wifi.

Merci,

Posté le : 05/11/2013 22:42
La perfection est atteinte non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer....
(A de St EXUPERY)
Transférer la contribution vers d'autres applications Transférer


Re: highspeed wireless
Pilier de la communauté
Inscrit:
13/10/2005 10:06
De haute-savoie (74)
Messages: 1162
Hors Ligne
Pour le CAN, il y a en effet un format donné, mais qui est ultra simple. C'est multipoint et peut avoir des débits très intéressants. C'est ce qui est utilisé dans les voitures ou certains autres modes de transport ainsi que sur des machines industrielles. Le principe est généralement que les calculateurs diffusent leurs messages à intervalles réguliers et définis selon un scheduler. Chaque noeud peut avoir une messagerie complexe et chaque message peut être paramétré avec une période différente. Les clients lisent ces messages. Si le client n'est pas concerné alors il ne lit pas. CE qui est bien avec le CAN c'est la gestion de l'arbitrage qui est bien faite. Pour de la communication multipoint câblée c'est je pense le plus adéquat des protocoles qui reste simple à mettre en oeuvre et très performant.
Le diagnostic est facile grâce à des softs qui font la démodulation du protocole et dans lequel on peut même directement mettre toute la messagerie du système pour avoir des info en clair qui s'affichent type Vector CANalyzer, mais il y y a des outls gratuits pour ça ou à très bas cout. (zeroplus par exemple).

Coté hardware, il faut un controleur CAN qui peut être dans un MCU ou extérieur via SPI ou UART (par exemple Microchip MCP2515 mais il y en a d'autres), puis un driver de ligne comme pour n'importe quel protocole. Il existe des drivers dédiés pour des applications (fault tolerant, haut débit, etc...)
Par contre je ne pense pas que cela se prete bien au wireless. Car dans tous les cas, il faut moduler le signal sous un format qui va garantir à la fois le débit et la correction d'erreur. On va tomber sur des modulations amplitude et phase type QAM qui ne sont pas évidentes à mettre en oeuvre pour le néophyte sans utiliser un composant spécialisé.

Pour la partie wireless, le Wifi a l'avantage d'être tout fait mais à l'inconvénient d'être monopoint me semble t'il, même s'il existe dans le protocole des adresses dites de broadcast. Voir si cela peut te sauver la mise mais j'en doute. A mon avis ce n'est pas la solution pour ce que tu veux faire, en particulier si tu veux respecter des pings courts. Mais sûrement qu'en bricolant on y arriverait.



Ce qui se prête le mieux en terme de protocole pour ce que tu veux faire je pense que ce serait l'AX25. C'est fait pour. Initialement prévu pour fonctionner à 1200 bauds puis 9600 bauds maintenant pour les radioamateurs, il y a peut être moyen de le porter plus haut mais pour ton usage je ne pense pas que cela soit bien nécessaire. Ce protocole communément appelé Packet Radio est largement utilisé par les radioamateurs sur des distances très longues (possibilité d'utiliser un noeud comme un répeteur dans le protocole pour faire des réseau maillés). Il existe des libs toutes faites pour gérer en soft depuis un simple UART. Ensuite on peut ajouter un circuit modem, ou le faire en soft. Là aussi tu trouveras des sources sur le net.
Le débit ne sera pas élevé, mais les pings devraient être pas mal du fait de la simplicité du protocole. A priori c'est ce dont tu as besoin en priorité.
Les radioamateurs utilisent encore largement ce protocole pour des laisons de plusieurs milliers de km, avec des satellites, etc.. C'est très robuste et efficace comme protocole. Il y a par dessus des couches supplémentaires possible pour faire des BBS, de l'APRS (Automatic Position Report System), du transfert de fichier, etc... A 9600 bauds on fait déjà beaucoup de choses quand c'est bien exploité !

Côté diagnostique et outils de supervision, il y a une multitude de softs sur PC sous win ou linux, totalement gratuits pour afficher le protocole en utilisant la carte son comme entrée, ou un modem RS232 si tu le souhaites. Les softs sous carte son sont désormais le standard pour la modulation/démodulation des signaux numériques en radio, pour les amateurs mais aussi pour les professionnels. Sous Linux, AX25 est déjà incorporé dans les distributions.

Enfin tu as toujours la possibilité de faire un protocole toi même. Tu finiras pas faire quelque chose de proche de l'AX25 qui reste très simple mais parfaitement abouti, et tu passeras beaucoup de temps à écrire et valider ça. C'est la raison pour laquelle je t'encourage à regarder l'AX25 de près.

Pour la couche matérielle il existe des modems en 1200 bauds qui font ça du genre TCM3105 ou FX614, qui ne sont que des modems. Le protocole reste à coder. Il faut évaluer s'il vaut mieux utiliser un de ces modems AX25 ou s'il vaut mieux se le faire...

Description en français : http://f6css.free.fr/ax25_gen.html
et : http://f6css.free.fr/prot_ax25.html
la description officielle et complète du protocole : http://www.tapr.org/pdf/AX25.2.2.pdf

exemples d'implémentation :
http://slepp.ca/projects/ax25-modem/
http://sourceforge.net/projects/openax25/

http://www.google.ch/url?sa=t&rct=j&q ... RTvDyWw-Q&bvm=bv.55980276,d.ZGU


a+
Stéphane

Posté le : 06/11/2013 10:12
Transférer la contribution vers d'autres applications Transférer


Re: highspeed wireless
Pilier de la communauté
Inscrit:
13/10/2005 10:06
De haute-savoie (74)
Messages: 1162
Hors Ligne
Pour la partie matérielle tu peux utiliser un MCU n'importe lequel et un composant du genre CC1020 de chez TI (http://www.ti.com/lit/ds/symlink/cc1020.pdf)
qui fait à la fois la partie modem et la partie radio ! Deux chips...
Il ne te reste plus que le protocole à implémenter en soft... Il faut avouer que c'est une solution élégante je pense

exemple avec CC1020 : http://www.aero.iitb.ac.in/pratham/otherdocs/Comm%20Saurabh.pdf

encore un lien avec description du protocole pour MCU : http://svn.jonathanwagner.net/html/group__TNC.html

Enfin les outils sur PC :
http://www.dxzone.com/catalog/Software/Packet/


Posté le : 06/11/2013 10:24
Transférer la contribution vers d'autres applications Transférer


Re: highspeed wireless
Accro
Inscrit:
29/08/2006 10:42
De cambrai
Messages: 658
Hors Ligne
Salut Stephane,

Merci pour les info.
En effet, le CAN pourrai le faire, cela demandera pas mal de modifs, mais pourquoi pas. La gestion des collisions est intéressante, c'est un peu ce qui manque sur le RS485, mais comme je travail avec un "maitre" qui interroge des "esclaves", je m'arrange pour laisser le temps de réponse entre les questions et éviter ainsi les conflits.

Pour ce qui est de l'AX25, ça semble sympa, mais à 9600 bauds, soit un facteur de 100 avec ce que j'utilise actuellement, ça risque de coincer. A l'heure actuelle pour mettre à jour toutes les infos d'une carte esclave, il me faut environ 8ms, à 9600 bauds, il m'en faudrait donc 800, en supposant que je n'ai qu'une seule carte à mettre à jour, j'aurai donc sa position tous les 800mm, sur une table de 2m*3m avec 4 robots dessus, ça va vraiment pas le faire.
Pour cela autant mettre un module Xbee à 30€, tout est fait, plus qu'a envoyer les données, c'est sécurisé, multipoints, et je peux monter à 115k.

Pour avoir discuté hier soir avec Charly, l'idée d'une telle communication n'est peut être pas si bonne que ça.
Je vais peut être me tourner vers un second robot "intelligent" lui aussi, et les deux n'échangeront que des infos tactiques de haut niveau, afin de réduire le volume de données à échanger et d'assurer ainsi la fiabilité.
Cela implique pas mal de contrainte (2 robots à reprogrammer en cas de changement de tactique, doubler la carte IA et la détection d'adversaire).
Au lieu de lui dire: monte le bras, ouvre la pince, descend le bras, ferme la pince. Il lui dira: Prend l'objet à telle position.

Les protos des cartes multifonctions (réalisés à un prix 'donné' ont été expédiés, je vais déjà avoir ça à valider) la couche supérieure se fera ensuite.

Je vous tiens au jus.
A+
Maverick

Posté le : 06/11/2013 10:43
La perfection est atteinte non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer....
(A de St EXUPERY)
Transférer la contribution vers d'autres applications Transférer


Re: highspeed wireless
Pilier de la communauté
Inscrit:
23/10/2005 11:40
De Aix les Bains (73)
Messages: 1918
Hors Ligne
Citation :

maverick59 a écrit :
2 robots à reprogrammer en cas de changement de tactique, doubler la carte IA et la détection d'adversaire).

pour le premier probleme : un bootloader via le wireless
pour le deuxieme probleme : tu peux aussi le voir comme "solution 2 fois plus intelligente avec 2 fois plus de detection d'adversaire !

Posté le : 06/11/2013 11:17
Mieux vaut marcher dans la bonne direction que courir dans la mauvaise
Transférer la contribution vers d'autres applications Transférer


Re: highspeed wireless
Pilier de la communauté
Inscrit:
13/10/2005 10:06
De haute-savoie (74)
Messages: 1162
Hors Ligne
j'ai du mal à appréhender cette si grosse quantité de donnée pour communiquer entre deux robots ? Qu'à tu donc à échanger comme info qui prenne autant de place ?
tu dis qu'il te faut 8ms à 1 Mbits/s ! Cela fait 80ko octets de data toutes les 8ms !!! Sérieusement, on peut passer plusieurs flux vidéo là dedans !

Je pense que c'est là qu'il faut travailler pour revenir à des débits plus simples à gérer en wireless. 9600 bauds pour un système de controle temps réel c'est pas si mal. Cela fait 768 octets en 8ms. Si ce ne sont que des positions et un peu de télémétrie, tu dois bien pouvoir te débrouiller avec quelques centaines d'octets, non ? Les positions ne doivent prendre que quelques octets je pense. Donc quelles sont les autres infos que tu as besoin d'échanger aussi rapidement ? Voir peut être si ton encodage et ton protocole sont bien optimisés pour ton application ou si ton scheduling des messages est lui aussi optimisé, car moi cela me parait étonnant que tu ne puisse as t'en sortir avec quelques kbauds pour connaitre la position entre deux robots. Après certaines autres données que tu échanges n'ont peut etre pas besoin d'être rafraichies aussi rapidement que la position, si ?

Par ailleurs attention. Un zigbee ou autre affiché à 115kbauds ne correspond pas à 115kbauds de data. Dans ces protocoles il y a beaucoup d'overhead. C'est à dire de trames liées au protocole et non pas au transfert de données. Donc prudence.

Une application poids lourd sur laquelle j'ai travaillé utilisant un bus CAN échangeait quelques 3000 messages différents entre 12 calculateurs en chargeant à moins de 40% un bus 250 kbauds, et dans ce protocole était échangées les infos de vitesse moteur ou véhicule à 10ms sur lesquelles étaient appliquées des statégies de controle, type PID et on a jamais saturé le bus...

peux tu dérire un peu plus tes échanges ?

Posté le : 06/11/2013 11:58
Transférer la contribution vers d'autres applications Transférer



 Haut   Précédent   Suivant
(1) 2 »



Vous pouvez voir les sujets.
Vous ne pouvez pas débuter de nouveaux sujets.
Vous ne pouvez pas répondre aux contributions.
Vous ne pouvez pas éditer vos contributions.
Vous ne pouvez pas effacez vos contributions.
Vous ne pouvez pas ajouter de nouveaux sondages.
Vous ne pouvez pas voter en sondage.
Vous ne pouvez pas attacher des fichiers à vos contributions.
Vous ne pouvez pas poster sans approbation.

[Recherche avancée]


Powered by XOOPS© The XOOPS Project
Contacter les administrateurs

highspeed wireless [Forums - Hardware]