UART mémoire pleine ( raspberry python)

bonjour à tous,

voila je reçois d'un périphérique extérieure des paquets (115200 bps ) qui représente la distance entre le peripherique et l'obstacle en face, et je les recois sur ma raspberry via le port serie.
les distances sont cohérentes, mais par exemple si je met ma main devant il faudra plusieurs secondes avant de me donner la nouvelle distance... j'espere que vous comprennez mon probleme car mon explication est peut etre pas trop clair...

Je pense que le soucis viens de mon stockage d'octet de l'uart de ma raspberry qui est surchargé. ca expliquerait le temps d'attente pour la nouvelle distance, je ne peux pas arrété malheuresement le périphérique ou mettre un delay entre chaque envoie, non je recois tout en paquet... je dois donc trouver un moyen de vider la mémoire de de l'uart de ma raspberry pour recevoir les nouvelles donnees mais je ne sais pas comment faire ...

avez vous une idée, je code python pour info
voici mon extrait de code :

Code:

---

1 2 3 4 5

import serial ser = serial.Serial('/dev/ttyAMAO',115200,timeout=5) reception=ser.read()

---

merci d'avance

Bonjour,

Citation:

---

Envoyé par cosmoff

voici mon extrait de code :

Code:

---

1 2 3 4 5

import serial ser = serial.Serial('/dev/ttyAMAO',115200,timeout=5) reception=ser.read()

---

---

L'extrait de code est probablement trop raccourci. Lecture d'1 octet sur un port série avec un timeout de 5s (le timout est peut-être à l'origine du problème d'ailleurs), c'est tout ce qu'on peut lire... difficile de se faire une idée.

Il faudrait aussi donner les références du capteur et décrire avec un exemple de ce qui est envoyé sur le port série (format des données).

j'utilise un scanner laser RPlidar:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

port=serial.Serial("\dev\ttyAMA0",115200,timeout = 1) port.write("\xa5\x20")#begins scanning [...] while True: line="" line= port.read(5)#on attend 5 octet if (len(line==5)) : distance,angle=point_Polar(line)# la fonction nous retourne une distance et un angle print distance,angle

---

je pense pas que le timeout soit le probleme car je recois bien les distances et angles mais le probleme est que mon programme est assez gros donc des que mon programme recois les paquets, le temps d'éxécuter les instructions pas mal de paquet vont etre en attente dans le buffer et donc je perd en rapidité, je sais pas si tu comprends mon probleme

en faite je lis bien sur mon terminal les distances et angles environ 360 en 2 secondes mais si je met ma main devant le laser ca va afficher la distance laser-main qu'au bout de 10 secondes car la donnée distance laser-main est tres loin dans le buffer

Salut,
C'est très bizarre ton problème.
Quand tu écris "je lis bien sur mon terminal les distances et angles environ 360 en 2 secondes" ça me paraît déjà très lent, voir trop lent. Surtout avec un bauderate de 115900 bits/s.

Dans la doc de ton scanner, il t'envoi combien d'octet par seconde ? Tu as un lien ?

http://rplidar.robopeak.com/download.html

il n'est pas sur le net:( faut télécharger le SDK puis ensuite va dans doc/en.US/_interface_protocol

sur la donc technique il m'envoie 115200 bauds soit 14400 octets par seconde

je peux t'envoyer mon code complet si tu le desires

j'ai utilisé la raspberry d'un ami avec 4 processeurs ( pour info j'ai la b+ avec 1 processeur) et je recois les données beaucoup beaucoup plus rapidement, ma raspberry B+ serait donc pas assez rapide :( ??

Au vu de la doc ça devrait pédaler rapidement (si tu regardes les trames tu verras qu'elles ne sont pas énormes.)
Est ce que tu as vu que dans rplidar_sdk_v1.4.5\sdk\app\ultra_simple\ tu as une application de démontration (en mode console) ?

As tu essayé de compiler avec GCC ce source pour le tester avant de te lancer avec python ?

Si non, peux tu commencer par là et nous faire un retour ?

ps1 : je connaissais le principe de détection LIDAR mais je ne savais pas qu'il existait des modules tout fait ! Ca coûte cher ?
ps2 : je ne connais pas encore assez bien le langage python pour trouver un problème dans ton code (quand j'étais dans l'électronique je ne faisais que du C et pour mes loisirs, je suis entrain d'apprendre JAVA et après je comptais passer à python.)

A très vite.

Salut,

j'ai eu le "soucis" récemment pour un projet ou je recevais des données en continu par la liaison série sur laquelle je ne lisais que toutes les 10 secondes.
moralité:
- la première lecture était correcte.
- la deuxième lecture qui intervenait 10 secondes plus tard me lisait en fait la trame qui était arrivée seulement quelques milisecondes après la première.
- la 3e (au bout de 20 secondes) me lisait la 3e trame qui était arrivée très peu de temps après la premiere...
- et ainsi de suite... plus le temps pasait, plus le décalage augmentait.

je pense que tu as le même soucis et la solution est plutôt simple: l'écriture dans le buffer se faisant plus vite que la lecture de ce même buffer, il suffit de vider le buffer avant de faire une lecture pour avoir des données fraiches.
regarde du coté des méthodes flush* de la classe Serial, ça devrait t'aider

TRYPH, voila c''est ce que je veux faire : rafraichir le buffer mais je n'arrive pas. j'ai essayé avec un flush :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

port=serial.Serial("\dev\ttyAMA0",115200,timeout = 1) port.write("\xa5\x20")#begins scanning [...] while True: line="" port.flushOutput()# vide le buffer line= port.read(5)#on attend 5 octet if (len(line==5)) : distance,angle=point_Polar(line)# la fonction nous retourne une distance et un angle print distance,angle

---

port.flushOutput()# vide le buffer
mais ca n'a malheureusement aucun effet :( ca ne rafraîchie pas mes données :(

@vincent petit pour le RPLIDAR il coute environ 350 euros mais bon c'est un télémetre laser donc peu cher par rapport aux autres

je dois avouer que j'ai pas bien saisi la différence entre flush, flushInput et flushOutput. et j'ai pas trouvé d'info qui explique pourquoi on a un buffer en entrée et un buffer en sortie.

ceci dit, dans mon cas, un flushInput a réglé le problème.
par contre ça fait que tu peux te retrouver à lire en plein milieu d'une série de données et qu'il faut pouvoir gérer ce cas.

en lisant vite fait la doc du bouzin, je me dis qu'il va falloir se méfier avec les flush car ils peuvent intervenir en plein milieu d'un paquet de données et comme tu n'as aucun moyen de repérer le début d'un paquet de 5 octets, si tu te contentes de prendre les octets 5 par 5 en supposant qu'ils correspondent à chaque fois à un unique paquet entier, tu risques de te retrouver avec des valeurs abérantes.

en gros je vois 3 solutions pour t'en sortir:
- soit tu arrives à suivre la cadence imposée par le télémètre et à lire et traiter toutes les données qu'il t'envoie (pas dit que ça soit possible avec du Python sur RasPi)
- soit:

1. tu commences le scan
2. tu lis autant de données que nécessaire (probablement des mesures sur 360°)
3. tu stoppes le scan
4. tu vides le buffer
5. tu commences un nouveau scan
6. etc...

- soit tu débrouilles sans flush et tu gardes le compte des octets reçus pour savoir ou commencent les paquets de données. c'est le plus compliqué, mais aussi le plus réaliste je pense.

---

pour expliquer la 3e solution:
admettons que tu commences ton scan, tu reçois donc 7 octets de "Response Descriptor" puis une suite de paquets de 5 octets.
tu commences donc par lire les 7 premiers octets, tu initialise une variable reste (par exemple) à 0, puis à chaque fois que tu fais une lecture:
- tu lis tout ce que contient le buffer et tu lui enlève ses (5-reste) premiers octets
- tu fais un modulo 5 sur la taille des données récupérées pour savoir le nombre d'octets que tu a en trop (tu as 4 chances sur 5 que le dernier paquet soit tronqué) et tu gardes le resultat dans la variable reste
- tu vires les reste derniers octets des données récupérées, tu gardes les N*5 derniers octets du résultat (N étant le nombre de mesures que tu veux lire).
- tu te retrouves donc avec N paquets entiers

par exemple:
- 1e lecture: reste=0, taille des données lues=1548483 octets

tu enlèves 5 octets au début (5-0, tu as donc maintenant 1548478 octets)
tu calcules le modulo : 3 (1548478 % 5) que tu stocke dans la variable reste
tu enlèves 3 octets à la fin
tu te retrouve avec 1548475 octets de données bien calées dont tu peux récupérer mettons 100 mesures (soit les 500 deniers octets)
tu ignores le reste

- 2e lecture: reste=3, taille des données lues=12451 octets

tu enlèves 2 octets au début (5-3, ce sont les 2 octets restant du paquet tronqué à la lecture précédente, tu as donc maintenant 12449 octets)
tu calcules le modulo : 4 (12449 % 5) que tu stocke dans la variable reste
tu enlèves 4 octets à la fin
tu te retrouve avec 12445 octets de données bien calées dont tu peux récupérer encore 100 mesures
tu ignores le reste

- etc...

Citation:

---

Envoyé par cosmoff

http://rplidar.robopeak.com/download.html
il n'est pas sur le net:( faut télécharger le SDK puis ensuite va dans doc/en.US/_interface_protocol
sur la donc technique il m'envoie 115200 bauds soit 14400 octets par seconde

---

Désolé, je n'ai pas vraiment envie de télécharger la documentation :)
115200 bauds, ça veut bien dire 14400 octets par seconde, mais ça ne veut pas dire que tu vas recevoir 14400 toutes les secondes. Ca donne juste la vitesse d'arrivée des données quand tu en reçois. Ce que tu ne nous dis pas, et c'est peut-être parce que tu ne le sais pas, c'est la fréquence d'envoi des paquets par le télémètre. Il envoie un paquet toutes les 2 secondes ? Plus, moins ? Combien exactement ? C'est variable selon la distance mesurée, selon les variations de cette distance ? Peux-tu régler cette fréquence ?

Citation:

---

Envoyé par cosmoff

j'ai utilisé la raspberry d'un ami avec 4 processeurs ( pour info j'ai la b+ avec 1 processeur) et je recois les données beaucoup beaucoup plus rapidement, ma raspberry B+ serait donc pas assez rapide :( ??

---

Honnêtement, je ne pense pas. Un micro-contrôleur Cortex-M à 120 / 180 MHz reçoit sans problème un tel flux de données.

Citation:

---

Envoyé par cosmoff

mon programme est assez gros donc des que mon programme recois les paquets, le temps d'éxécuter les instructions pas mal de paquet vont etre en attente dans le buffer et donc je perd en rapidité, je sais pas si tu comprends mon probleme

---

Le problème est peut-être là justement : que fais-tu quand tu reçois un paquet ? Ton application est peut-être mal structurée. As-tu essayé de faire une application très simple qui ne fait qu’afficher les paquets reçus ? En gros, le code que tu montres, fonctionne t-il correctement si tu ne fais tourner que lui et pas le reste de ton gros programme ?

Citation:

---

Envoyé par cosmoff

en faite je lis bien sur mon terminal les distances et angles environ 360 en 2 secondes mais si je met ma main devant le laser ca va afficher la distance laser-main qu'au bout de 10 secondes car la donnée distance laser-main est tres loin dans le buffer

---

Tu lis 360 valeurs en 2 secondes ? Si au lieu de mettre ta main devant, tu passes devant le détecteur mais un peu plus loin que collé à lui ?

La solution des flush est très mauvaise, car comme cela a été dit, tu risques de flusher au milieu d'un paquet. Vu la taille d'un paquet (5), il est possible que tu n'es pas d'en-tête clairement définie te permettant de te recaler. Mais peut-être que oui ?

Le problème de fond est sans doute l'architecture du programme ou alors en effet que le Raspberry est trop lent, mais pas pour recevoir, pour effectuer autant de traitement sur autant de données.

En relisant la doc, il y a un bit important a regarder dans le premier octet.

Le bit 0, qui s'appelle 'S', si il est a 1 indique que tout ce qui est entrain d'arriver appartient a une mesure sur 360° (il est entrain de tourner mais n'a pas encore fait un tour). Encore d'après la doc, que je ne trouve pas très clair, le bit S passe a 0 pour indiquer qu'on débute une autre lecture (donc le LIDAR refait un nouveau tour)

Je pense qu'il faut lire continuellement le flux entrant tant que S est a 1 (ou a 0) et seulement après tu seras sur d'avoir 360 données.

En complément de ce que j'ai écrit et comme le dit Bktero

Le temps que tu fasses :

Code:

---

1 2 3

if (len(line==5)) : distance,angle=point_Polar(line)# la fonction nous retourne une distance et un angle print distance,angle

---

Plusieurs paquets de données sont déjà parti du LIDAR, vu la vitesse du bauderate (115900), et quand tu refais

Code:

---

line= port.read(5)#on attend 5 octet

---

Ce n'est pas le degrés suivant que tu lis mais celui bien plus loin.
Exemple : tu lis par exemple l'angle 1° puis au prochain tour de boucle, c'est l'angle 10° qui va être lu puisque le LIDAR n'attends pas et il balance ses données que tu ais fini ton calcul ou non

Quand tu mets ta main devant le LIDAR, par exemple à 7 degrés, et au vu des échantillons que tu lis poncutellement sur le port série, le LIDAR va devoir faire plusieurs tour avant de voir ta main d'où le delai de réaction très long que tu constates

Bktero, met le doigt sur quelque chose d'important aussi, ton Raspberry n'est pas un système temps réel, c'est un OS qui exécute des pleins de tâches en parrallèle et rien ne te dit que Raspbian (je suppose) n'est pas entrain de faire autre chose pendant que des paquets de données arrivent du LIDAR et si tu en rates ça explique pourquoi tu constates cette lenteur.


!!! pour info je ne maîtrise pas ce langage !!!
En python, n'as tu pas le moyen non pas de lire 5 octets mais de lire le nombre complet d'octet dans le buffer de ton port série ?
Ca ne serait pas inWaiting() qui fait ça ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

port=serial.Serial("\dev\ttyAMA0",115200,timeout = 1) port.write("\xa5\x20")#begins scanning [...] #faire tant que des données sont dans le buffer d'entrée du port série while port.inWaiting() : line="" #initialisation line = port.read(port.inWaiting())#on lit le nombre d'octet présent dans le buffer #il faut modifier le if pour gérer les troncatures ou les données a moitié reçu if (................) : distance,angle=point_Polar(line)# la fonction nous retourne une distance et un angle print distance,angle

---

Je n'ai pas suivi le sujet mais je voudrais juste relever un possible amalgame :

Citation:

---

Envoyé par Vincent PETIT

Plusieurs paquets de données sont déjà parti du LIDAR, vu la vitesse du bauderate (115900), et quand tu refais

---

Le baudrate à 115900 indique la vitesse à laquelle les données vont transitées sur le média mais ne saurait présumer en rien de la fréquence d'émission de ces données par la source.

On peut très bien émettre les données à 115900, mais n’émettre qu'une donnée toutes les 3h.
Attention à ne pas se mélanger les pinceaux

La fréquence d'émission des données doit certainement se trouver dans la doc de l'appareil

Citation:

---

Envoyé par sevyc64

On peut très bien émettre les données à 115900, mais n’émettre qu'une donnée toutes les 3h.
Attention à ne pas se mélanger les pinceaux

La fréquence d'émission des données doit certainement se trouver dans la doc de l'appareil

---

C'est justement ce que j'ai compris de la doc.
Il y a plusieurs mode de communication, il y en a un, tu envois une requête et tu obtiens une seule réponse. Un autre mode permet de demander un scanne en continue et c'est le bit 'S' qui indique si les données font parties d'une mesure sur 360 degrés.

A+ ;)