Latence Liaison Raspberry - Arduino

Bonjour,

je sais pas si je suis dans la bonne section, mais je pense que mon problème révèle plus de la programmation qu'autre chose,

Pour expliquer vite fait mon projet j'ai concocté une petite image sur paint (en pièce jointe, oui c'est pas fou ahah).

 

 projet.png   187,5 Ko   3 téléchargement(s)

 

En gros, l'ordinateur envoie un message par mqtt au raspberry qui le récupère pour l'envoyer à l'arduino (par usb) pour controler les moteurs et le capteur ultrason.

Le problème c'est que je n'ai aucune latence entre ordinateur/raspberry mais une énorme entre raspberry/arduino !

Je sais pas vraiment d'où cela vient, je vous partage donc les codes raspberry et arduino qui vont avec

 

code arduino : 

 

 

 

 

 

 

code raspberry:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import paho.mqtt.client as mqtt
import os
import serial
import time

def connectionStatus(client, userdata, flags, rc):
	mqttClient.subscribe("gpio/motors")

def messageDecoder(client, userdata, msg):
	global ser
	message = msg.payload.decode(encoding='UTF-8')
	if message == "avancer":
		message = "avancer"
	elif message == "reculer":
		message = "reculer"
	elif message == "arret":
		message = "arret"
	elif message == "gauche":
		message = "gauche"
	elif message == "droite":
		message = "droite"
	ser.write(message)
	
ser = serial.Serial("/dev/ttyACM0")
mqttClient = mqtt.Client("raspi")
mqttClient.on_connect = connectionStatus
mqttClient.on_message = messageDecoder

mqttClient.connect("192.168.43.210")

mqttClient.loop_forever()

Merci de m'avoir lu,

cordialement,

enlève le delay(500) dans ton code. 
Si tu veux vraiment attendre ce temps là utilise une autre façon "d'attendre" sans bloquer la loop 

je l'ai effacé et rien n'y fait :/

J'ai remis le baudrate à 9600 et toujours pareil,

je pense que le problème vient du programme python sur le raspberry, j'ai remarqué que les messages s'envoyaient par bloc, c'est à dire que quand je le fais avancer avec mon interface graphique, le raspberry les a bien comme il faut, en direct, mais quand ce dernier renvoie le message à l'arduino, il envoie "avancer" et "arret" en même temps, je sais pas si c'est compréhensif, sinon je fais une vidéo en direct au pire.

 

Afin de clarifier mes propos, si j'ajoute un time.sleep(1) à la fin de la fonction "MessageDecoder" sur le raspberry, tout est bien séparé, mais le problème c'est qu'il y a un décalage de 1 secondes

Bonjour,

je ne connais pas mqtt, et je ne suis pas sur de déjà avoir essayé d'utiliser le port sériel en Python (je l'ai déjà fait en c++).

Vue ce que tu décris, j'aurais tendance à croire que la communication est bufférisée : tu écris des données dans le buffer, et à un moment donné (par exemple quand le buffer est assez plein, après un certain emps ou je ne sais quoi), le buffer est effectivement envoyé.

Si c'est ça, regarde s'il n'existe pas une commande "flush" (ou un autre nom) qui permet de forcer d'envoyer le contenu du buffer vers le port série.

Bonjour,

je ne connais pas mqtt, et je ne suis pas sur de déjà avoir essayé d'utiliser le port sériel en Python (je l'ai déjà fait en c++).

Vue ce que tu décris, j'aurais tendance à croire que la communication est bufférisée : tu écris des données dans le buffer, et à un moment donné (par exemple quand le buffer est assez plein, après un certain emps ou je ne sais quoi), le buffer est effectivement envoyé.

Si c'est ça, regarde s'il n'existe pas une commande "flush" (ou un autre nom) qui permet de forcer d'envoyer le contenu du buffer vers le port série.

 

j'ai pas du tout compris comment ça marche :/

En gros, les communications sont généralement lentes par rapport aux vitesses de calcul.

Du coup, si tu envois tes données 1 octet à la fois, tu vas passer beaucoup de temps à attendre que tes données soient effectivement envoyées.

La solution qui a été trouvée, est de stocker les données à envoyer dans une file d'attente(le buffer), et quand il y en a assez (ou qu'on le demande explicitement), alors on envois tout ce qu'il y a dans le buffer en un seul coup. ça va beaucoup plus vite.

 

A titre de comparaison, imagine le courrier d'une entreprise.

Sans buffer, dès qu'un employé a fini de rédiger une lettre, il vas à la poste la poster, ce qui prend pas mal de temps.

Avec le buffer, on pose une caisse (le buffer) au secrétariat ou les employés peuvent déposer leurs lettres à envoyer (ça leur prend beaucoup moins de temps). Une fois que la caisse est plaine, la secrétaire s'occupe de l’amener à la poste.

Mais si un employé a un courrier très urgent à envoyer, alors il demande à la secrétaire d'amener la caisse à la poste, même si elle n'est pas encore pleine : ça prend plus de temps, mais au moins c'est fait immédiatement. Cette action correspond au "flush" (il me semble que la traduction française serait "tirer la chasse d'eau").

 

 

Mon hypothèse est que tu as un buffer (la caisse), alors que tu voudrais que tout ton courrier parte immédiatement. Si c'est ça, alors il faut soit que tu te débrouille pour ne pas avoir de buffer, ou que tu lance la commande "flush" pour forcer à tout envoyer.

 

Je sais pas si j'ai été plus clair cette fois.

C'est dommage, j'arrive pas à lire ton code arduino.

J'ai édité son message. 

Merci Mike.
Pour moi il manque juste les séparateurs: les retours chariots. Les commandes de lecture d'une ligne en mode texte lisent jusqu'à voir arriver une fin de ligne ou bien tombent en timeout. Ces séparateurs limitent la quantité de données mise en buffer dont parle Sandro. Cest un début de protocole de communicarion ^^ C´est peut être pour ça que tu as ces délais de fou. Readline et println https://www.robot-ma...no-uno-via-usb/

Merci pour votre aide les gars, je vais essayer chaque réponse et voir comment ça évolue, je vous tiens au courant !