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)


Re: highspeed wireless
Pilier de la communauté
Inscrit:
13/10/2005 10:06
De haute-savoie (74)
Messages: 1162
Hors Ligne
J'ajoute qu'en effet un protocole comme le CAN ou l'AX25 sont très robustes (c'est étudié pour) comparé à un RS485.

Posté le : 06/11/2013 12:01
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 effet, je n'avais pas fait le calcul, mais il y a un truc qui cloche.
A chaque mise à jour, je dois avoir 5 trames de maximum 70 octets (mais en pratique elles font 40 à 50 octets).

Je sais que le format n'est pas du tout optimisé, du fait de l'utilisation de caractères ascii et non pas des données brutes.
Par exemple si la position du robot est à 100mm, au lieu d'envoyer un seul octet, j'en envoie 3.

Ce qui fait au max 350 octets, soit 2800 bits, disons 3000, la com ne devrai prendre que 3ms donc au grand maximum, et en pratique (1,6ms à l'heure actuelle).
Je vais devoir jeter un œil à ce qui se passe, et trouver les 5 à 6ms perdues qui peuvent changer la donne.
Peut être ce soir, ou demain si j'ai le temps.

Posté le : 06/11/2013 12:20
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
oui clairement ton protocole n'est pas du tout adapté pour transmettre rapidement les informations. Tu a choisi un langage scriptuel utilisé pour transmettre des infos généralement qui n'ont aucune criticité de timing. Ce n'est pas du tout un protocole optimisé pour du bus de terrain et de la communication temps réel. Je pense que tu pourrais diviser par 10 ou 20 la quantité de données en retravaillant ton protocole.
Si tu veux un gain substantiel il te faut revenir à un encodage binaire standard pour réduire de manière significative la quantité d'infos à transmettre. En terme d'architecture, cela serait plus cohérent de faire cela et d'utiliser un protocole moins véloce et ainsi avoir moins d'ennuis par ailleurs. Plus on transmet vite, plus on s'expose à des problèmes et a des complexifications.

Du coup, avec 9600 bauds tu pourrais largement transmettre toutes tes infos et ton architecture système se simplifierait de manière conséquente !
Il faut te demander si l'investissement que nécessiterait cette migration ne serait quand même pas un gros atout pour la suite de ton développement.

Concernant tes stratégies des robots, si tu as écrit des trucs je suis preneur. C'est toujours intéressant ce type d'expérience. Et c'est du partage que nait l'émulsion d'idées constructives...

Stéphane

Posté le : 06/11/2013 13:34
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
Le gain de temps est en effet à envisager et à relativiser, de là à diviser par 10 ou 20, ça me semble énorme.
Prenons un cas concret: la position du robot 1.
Admettons qu'il se trouve en (X=1000,18; Y=2222,45; Angle=123,45).
Dans mon format ça donne:
G11 N1 X1000.18 Y2222.45 A123.45 B0 F1\n
soit 39 octets, [B0 indique que le robot n'est pas bloqué, F1, que le mouvement est terminé]

En utilisant un format plus approprié, j'aurai 1 octet pour identifier le type de donnée (ici la position du robot), 1 octet pour indiquer le numéro du robot (ici 1), 2 octets pour la position en X, 2 octets pour Y, 2 octets pour l'angle, un octet pour indiquer un blocage et/ou la fin du déplacement, soit 9 octets, je suis donc au quart en y laissant de la précision et de la lisibilité, ce n'est pas négligeable.

Pour ce qui est des stratégies, j'ai un algo de pathfinding qui fonctionne plutôt bien, et est assez rapide.
Il est basé sur un A* (quadrillage du terrain en carrés de 100mm, ce qui donne 600 cases, et il calcul la succession de cases à emprunter pour rejoindre la destination, puis l'ensemble est lissé afin d'éviter les bonds de cases en cases mais de regrouper toutes les cases alignées en un seul mouvement), le tout prend quelques 20 ou 30ms à calculer.

Ensuite, pour la sélection des actions à effectuer, je n'ai rien de propre, l'an dernier, c'était la première fois que j'utilisais ce genre d'algo, il a donc été développé au fur et à mesure des besoins, patché de tous côté pour gérer les cas particuliers, mais rien n'a encore été remis au propre de ce côté pour le moment, l'écriture de la stratégie de cette année en sera l'occasion de factoriser tout ça et d'y apporter quelques améliorations.
Dans le principe, c'est un tableau de structure, chacune représentant une action, avec (dans le désordre) les coordonnées du point ou doit commencer l'action, le nombre de points qu'elle rapporte, un coef magique, un pointeur vers la fonction exécutant l'action, un octet indiquant si l'action a déjà été exécutée, si elle est bloquée, inaccessible...une valeur indiquant si besoin le moment du match à partir duquel l'action peut être réalisée.

Avant d’exécuter une action, l'algo va parcourir ce tableau et calculer pour chaque action, un 'poids' en se basant sur le nombre de points rapportés par l'action, le distance qui sépare le robot de l'action, le coef magique...puis il choisis celle qui a le 'poids' le plus élevé et l’exécute. Elle passe ensuite au status 'terminee', puis re-calcul les poids des actions....

A intervalle régulier (200ms) l'algo de recherche de chemin, est ré-exécuté, il re-calcul un chemin joignant la position actuelle du robot et sa destination, au besoin il envoie un nouveau point de passage à la carte d'asserv afin d'éviter un obstacle (ce qui occupe environ 6% du CPU, qui passe presque 80% de son temps en tâche d'attente sous FreeRTOS).

Par contre, dans ton message de 11h58, tu parles de 80ko en 8ms...c'est moi ou il y a une erreur de calcul quelque part?


Posté le : 06/11/2013 15:34
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
Une trame donnant la position aura j'imagine toujours le même format. De combien as tu besoin de type de trames différents ? Tu n'es déjà pas obligé de coder le type de trame sur un octet. 4 bits ça fait déjà 16 types de trames possibles.
Idem pour le nombre de robots. Est-ce que tu prévois d'avoir 256 robots pour que tu code l'info sur 8-bits ?

Ensuite qu'elle est la résolution et la gamme réellement nécessaire sur tes positions et angles ?

N'ayant pas ces infos je prends quelques hypothèses : Gamme X et Y : de 0 à 8,19m, angle 0-360°, nombre de robots max = 8
Si je reste en entiers, on pourrait coder ta trame ainsi

ID trame = 4 bits
N° robot = 3 bits
X = 14 bits (résolution = 8,19m / 8192 = 1 mm)
Y = 14 bits (résolution = 8,19m / 8192 = 1 mm)
angle = 12-bits (0 à 3600, résolution = 0,1° (tu peux encore gagner 2-bits si ta résolution peut augmenter à 1°. (car déjà mesurer mieux que 1° n'est pas facile, donc à quoi bon transmettre une résolution plus grande ?)

Total trame = 47 bits
Même si on augmente les résolutions ou les gammes de mesure pour X et Y, on va augmenter de 2-4 bits pas bien plus aussi on restera en dessous de 50 bits

Si maintenant tu veux des résolutions et des gammes moins limitées, alors tu peux aussi tout passer en float. Cela donne
ID trame = 4 bits
N° Robot = 3 bits
X = 32 bits
Y = 32-bits
angle = 32-bits

Total = 103 bits soit plus du double. Cela vaut la peine de réfléchir.

Maintenant fais l'exercice en prenant tous les types de trame, en particulier les plus longues et calcule la taille réelle d'une trame que tu formates comme ça au niveau bit (la fonction de conversion est super simple à faire et rapide à éxecuter). En gros tu prends des valeurs dans ton code, et tu les convertis en nombre de bits nécessaire pour garder ta résolution. Situ as beaucoup d'infos que tu as codé sur des octets alors qu'il ne faut que quelques bits, tu va gagner beaucoup.

Ton protocole actuel avec 39 octets prends donc 312 bits, soit un rapport 6.6 avec la première solution. Pas négligeable.

Maintenant si je conserve ma première intention de 47-bits, à 9600 bauds, cela donne 4,89 ms pour transmettre le tout.... à 9600 bauds ! Alors que tu dis qu'il te faut 8ms à 1 Mbaud !!! Y a malaise, non ?

Il est important, voire primordial que tu définisses pour chaque valeur la valeur min, max et la résolution. Cela te donnera le nombre de bits réellement nécessaire. Inutile d'avoir des variables permettant d'avoir 1mm de résolution sur 44km si ton robot se déplace de 2m max !
C'est là qu'il te faut travailler selon moi, plutôt que sur une technologie de transmission à plus haut débit...

Stéphane

Posté le : 06/11/2013 17:42
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
et bien sûr rien ne t'empêche d'avoir dans ton code tes variables en float si cela te chante. Le tout est de convertir tes variables internes en un format pour transmettre et non pas transmettre la variable telle quelle. Car bien sûr ta variable dans ton CPU fera 16-bits même si tu n'en utilise que 9, mais on s'en moque. Alors que dans le protocole il est utile voire nécessaire de ne transmettre que ce qui est nécessaire.

Aussi, tu peux t'amuser avec un algo de compression de donnée. Il y a des techniques simples et rapide qui peuvent comprimer facilement quelques %. De quoi gagner 4-5 bits sur une trame de 50 bits par exemple. Ca n'a l'air de rien, mais ce n'est pas négligeable...

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


Re: highspeed wireless
Accro
Inscrit:
28/09/2005 11:53
De In Space
Messages: 157
Hors Ligne
Bonsoir,

Pour infos, le guide de sélection lextronic donne ceci : http://www.lextronic.fr/P1033-modem-radio-packet-sp2-433-160.html
pour un debits annoncé de 160KB/s

le guide : http://www.lextronic.fr/R1506-guide-de-selection.html

En espérant que ca peut aider :o)

Posté le : 06/11/2013 18:43
“Tomber est permis ; se relever est ordonné.” proverbe russe
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
Attention, les débits annoncés sont les débits physiques et pas les débits de données. Que ce soit dans ce cas, dans l'AX25, le Wifi ou autre, il y a ce que l'on appelle l'overhead. C'est à dire toutes les données de protocole dans lesquelles sont encapsulées les données utiles. Par exemple, adresses, CRC, parités, etc..
Dans tous les protocoles, il faut en tenir compte.

Dans l'exemple précédent où je disais qu'à 9600 bauds cela prenait 4.8ms, c'était uniquement pour les données utiles. Il faut ajouter les bits (bytes) du protocole lui-même bien sûr.... C'est la raison pour laquelle sur un réseau ethernet on ne va jamais à 100 Mbits/s de débit utile, que sur l'USB on ne vas jamais à 480 Mbits/s utiles, et sur le wifi encore moins ! Dans certains cas, l'overhead peut s'avérer plus important que les données elles-mêmes
C'est la raison pour laquelle le choix d'un protocole n'est pas anodin en fonction des contraintes que l'on a.. A priori, plus un protocole est simple, plus le ratio overhead/données utiles sera faible...

Stéphane

Posté le : 07/11/2013 13:52
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]