Guten Tag,
Ich bin an einem Projekt mit einem Selbstfahrenden Roboter, der vorne ultraschallsensoren und Microschalter hat (Mit Ardunio Mega). Jetzt würde ich gerne über die Serielle Schnitstelle die Daten von den US-Sensoren und den Mircorschaltern senden und dann in Processing den Roboter und diese Daten visualisieren. Also so wie bei einem Rückfahrwarner (Man soll ein Objekt sehen das den Roboter darstellen soll und dann vorne da wo ein Hindernis ist noch einen roten Balken).
Das Problem ist die Datenübertragung vom Arduino Mega zu Processing. Die Daten kommen bei Processing sehr viel langsamer an als wenn ich den Seriellen Monitor in der Arduino IDE öffne! Da die Daten perfekt in diesem Seriellen Monitor ankommen kann es ja eigentlich nur an processing liegen! Hier mal der Code
Arduino Code:
#include <BIB_Autodrive.h>
#include <BIB_Roboterbedienung.h>
#include <BIB_Motorsteuerung.h>
BIB_Autodrive objekt_autodrive{};
BIB_Roboterbedienung objekt_roboterbedienung{};
BIB_Motorsteuerung objekt_motorsteuerung{};
void setup() {
Serial.begin(9600);
}
void loop() {
String methode = objekt_roboterbedienung.welcheMethode();
Serial.print(methode);
Serial.println(";");
if(methode == "Autodrive"){
objekt_autodrive.set_bool_us_sensor(false);
while(true){
autodrive();
}
}
void autodrive(){
String wert_rechts = String(objekt_autodrive.getStop_rechts());
String wert_mitte = String(objekt_autodrive.getStop_mitte());
String wert_links = String(objekt_autodrive.getStop_links());
String alleDaten = wert_rechts + ";" + wert_mitte + ";" + wert_links;
Serial.print(alleDaten);
Serial.println(";");
}
Hier der Processing Code:
import processing.serial.*;
Serial myPort;
String datenDieKommen;
String modus = "";
void setup(){
size(800,600);
background(0);
noStroke();
fill(120);
String portName = Serial.list()[0];
myPort = new Serial (this, portName, 9600);
datenDieKommen = myPort.readStringUntil('\n');
datenDieKommen = null;
}
void draw(){
if(myPort.available() > 0 ){
datenDieKommen = myPort.readStringUntil('\n');
if(datenDieKommen != null){
println(datenDieKommen);
}
}
}
Aber die Daten werden in Processing total verzögert angezeigt bzw. Processing bekommt die Daten total verzögert.
Vielen Dank für eure Hilfe
RobotersindCool
hallo,
setz doch mal probeweise deine Baudrate auf 115200 (sowohl Arduino als auch Processing Interface und serieller Monitor ), beim Arduino also statt
Serial.begin(9600);
Serial.begin(115200);
je nachdem, was dein Processing auf dem PC schafft, kannst du es auch alternativ mal mit einem Zwischenwert von 38400 versuchen.
(keine Ahnung, warum auch immer von allen Leuten 9600 benutzt wird....)
wenn es dann aber nicht besser ist, muss man weiter suchen.
Hi und Vielen Dank!
Ich musste aber die Bautrate nicht auf mehr einstellen sondern auf WENIGER! Ich glaue es waren zu viele Daten für Processing und es hat nur alle 2 Sekunden aktualisiert! Nun hab ich die Bautrate auf 2400 und es funktioniert super!
Viielen Dank
RoboterSindCool
Das war früher bei vielen Geräten die die höchst mögliche Baudrate. Zudem ist es schon bei DOS die Defaulteinstellung gewesen und wurde bis heute auch bei Windows beibehalten.Zitat von Unregistriert
Bei 9'600 Baud kommt jede ms ein Zeichen rein, wird es nicht rechtzeitig ausgelesen geht es verloren. Per Interrupt ist das kein Problem, aber mit Polling ist das schon ganz schön schnell und es geht gerne mal ein Zeichen verloren.
Was ich nie Verstanden habe ist, wieso die meisten Leute einen Bogen um die Interrupts machen?
MfG Peter(TOO)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
mir sind die unheimlich. Und ich habe noch nichts gefunden, wo durch eine leicht zu verstehende erklärung einem diese nicht plausibel definierbare furcht genommen wird...
gruß inka
jaaa, früher....Das war früher bei vielen Geräten die die höchst mögliche Baudrate. Zudem ist es schon bei DOS die Defaulteinstellung gewesen und wurde bis heute auch bei Windows beibehalten.
Bei 9'600 Baud kommt jede ms ein Zeichen rein, wird es nicht rechtzeitig ausgelesen geht es verloren. Per Interrupt ist das kein Problem, aber mit Polling ist das schon ganz schön schnell und es geht gerne mal ein Zeichen verloren.
Wir reden hier aber von Arduinos mit mindestens 16MHz Takt und UART pots, die auf allen Arduinos mindestens bis zu 115200 baud unterstützen, und bei scheller Ausgabe von Daten mit nur 9600 - da verstopft schnell die Datenleitung. Auch bei UART Kommunikation mit anderen seriellen Geräten ist 9600 viel zu lnagsam.
Finde ich auch, viel zu kompliziert und zu kryptisch, nur wenn es sich absolut nicht vermeiden lässt :-/Was ich nie Verstanden habe ist, wieso die meisten Leute einen Bogen um die Interrupts machen?
super, aber wenn Processing der Flachenhals ist, wäre es besser, den Datenstrom am Arduino runterzuregeln durch delays oder millis, und nicht dem Bus am Arduino mit Gewalt (Serial.begin(2400) ) den Hahn zuzuquetschen bis nichts gar mehr reingehtIch musste aber die Bautrate nicht auf mehr einstellen sondern auf WENIGER! Ich glaue es waren zu viele Daten für Processing und es hat nur alle 2 Sekunden aktualisiert! Nun hab ich die Bautrate auf 2400 und es funktioniert super!
Es ist einfach hier rumzumotzen, wenn man sich hinter einem Gast-Account verstecktjaaa, früher....
Wir reden hier aber von Arduinos mit mindestens 16MHz Takt und UART pots, die auf allen Arduinos mindestens bis zu 115200 baud unterstützen, und bei scheller Ausgabe von Daten mit nur 9600 - da verstopft schnell die Datenleitung. Auch bei UART Kommunikation mit anderen seriellen Geräten ist 9600 viel zu lnagsam.
Die Frage war nach dem WIESO. Und meine Antwort ist WEIL es die Default-Einstellung ist!
Ob Default-Werte sinnvoll sind, wurde nicht gefragt, aber irgendein Wert muss nach der Initialisierung in den Registern stehen.
Ich weiss auch nicht wieso die meisten Leute mit Daten-, Parity- und Stop-Bits und der Baudrate überfordert sind?
Ich bin jetzt seit 1976 beruflich mit der Entwicklung beschäftigt und die serielle Schnittstelle war immer für die meisten ein Horror, auch für Techniker und Ings.
Vermutlich weil man auf beiden Seiten 4 Parameter gleich einstellen muss, damit die Verbindung funktioniert. Nur mit kindlichem Rumspielen bekommt man es eben meist nicht hin.
Hinzu kommt noch, dass es oft mehr als nur 3 Drähte benötigt, da sind noch ein paar Statusleitungen, welche man im einfachsten Fall brücken muss, damit der Sender überhaupt etwas sendet.
Achja, erschwerend ist noch, dass es zwei unterschiedliche Steckerbelegungen gibt, DTE und DCE. Je nach dem sind die Leitungen Pin zu Pin oder man muss sie richtig kreuzen.
Für mich war das nie ein Problem, auch wenn die Verbindung auch bei mir nicht immer beim ersten Versuch funktioniert hat.
Und wo liegt der Unterschied?super, aber wenn Processing der Flachenhals ist, wäre es besser, den Datenstrom am Arduino runterzuregeln durch delays oder millis, und nicht dem Bus am Arduino mit Gewalt (Serial.begin(2400) ) den Hahn zuzuquetschen bis nichts gar mehr reingeht
Mit beiden varianten wird die nutzbare Bandbreite begrenzt. Nur kommt die Herabsetzung der Baudrate ohne zusätzlichen Code aus und lässt sich auch einfach wieder aufheben. Bei Geräten, bei welchen man keinen Einfluss auf den Code hat, ist das Herabsetzen der Baudrate die einzige Möglichkeit, wenn ein Empfänger "überfahren" wird. Wobei es eigentlich noch die genormten Handshakes gäbe!
Und wo ist der Vorteil, wenn man mit delays die Rechenleistung verbrät?
Das ist auch ein Vorteil von Interrupts, so lange der Puffer nicht voll ist, muss man keine Rechenleistung verbraten.
MfG Peter(TOO)
- - - Aktualisiert - - -
Hallo Inka,
Das ist jetzt eher etwas für eine Psychologie-Forum
WAS hast du noch nicht richtig verstanden? Furcht hat man eigentlich nur vor etwas unbekanntem.
Eine Interrupt ruft eigentlich nur ein Unterprogramm auf. Der Aufruf erfolgt halt nur nicht an einer festgelegten Stelle im Programm, sondern wenn ein Ereignis (Signal an Pin, Timer abgelaufen) eintritt.
Kommt jetzt noch darauf an, auf welcher Ebene man das Programmiert und welche CPU verwendet wird. Auf Assemblerebene muss man selber die Register retten und wieder richtig herstellen, sowie den Interrupt quittieren. Reines C nimmt einem die Arbeit mit den Registern schon mal ab. Mit passenden Bibliotheken oder meist auch in BASIC, hat da schon wer die passenden Routinen geschrieben.
So ein Interrupt ist auch nicht anders wie ein Telefonanruf bei der Arbeit. Man muss die aktuelle Arbeit bei Seite legen und den Anruf entgegen nehmen. Nach dem Telefon nimmt man die Arbeit wieder auf. OK, die CPU hat es da einfacher, die vergisst nichts und macht genau beim unterbrochenen Befehl wieder weiter.
MfG Peter(TOO)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
Oh, serielle Schnittstelle kann so schön einfach sein.
Wenn mann nicht durchsteigt, geht man erst mal hin und nimmt den vollen 25 Pin Stecker und holt sich ein paar LEDs und Widerstände.
Dann beide Seiten auf 900 Baud und man kann jede Signaländerung an den LEDs sehen.
Wenn mann dann eine bidirketionale Kommunikation hat dreht man den Speed hoch.
bei 9600 kann man aber nur noch an der Helligkeit der LEDs erkennen ob das passt. Da das eher einer 1kHz PWM Ansteuerung der LEDs entspricht.
Soche "Serial Port Monitor" Stecker gabs auch zu kaufen.
Da heute "fast" alle Computer nur noch USB haben, aber jeder Netzwerkswitch und größerer Router immer noch einen 9 oder 25 Pol Console Anschluß hat.
Ist das bei mir aber auch noch Tagesgeschäft, wenn einer der Spezialisten, Remote mal wieder was totkonfiguriert hat und der Kollege vor Ort auch über fordert ist.
Ist halt kein Plug an Pray, sondern man kann alles noch selbst einstellen.
Hier in dem Fall sollte man aber neben der Baud Einstellung tatsächlich auch das Volumen der erzeugten Daten reduzierten. Zum einen wurde mit den 2400 Baud ja bereits festgestellt, das man die Menge an Daten gar nicht beim Empfänger verarbeiten kann und deshalb die Übertragung drosseln musste. Zum anderen kann in der Zeit ggf. der µC auch was sinnvolleres machen als Daten für Dev0 zu produzieren.
tatsächlich reden wir hier über die Arduino Serial Class und den Arduino UART pins mit nur 2 Kabeln, nämlich TX und RX (und GND), und da brauchen wir uns ja gottseidank um start, stop und parity keine Gedanken zu machen und ich sehe da auch keine Verbindung zu "kindlichem Rumspielen", dafür wurde das Arduino-Serial ( per "Wiring") ja schließlich genau so konzipiert.Ich weiss auch nicht wieso die meisten Leute mit Daten-, Parity- und Stop-Bits und der Baudrate überfordert sind?
Ich bin jetzt seit 1976 beruflich mit der Entwicklung beschäftigt und die serielle Schnittstelle war immer für die meisten ein Horror, auch für Techniker und Ings.
Vermutlich weil man auf beiden Seiten 4 Parameter gleich einstellen muss, damit die Verbindung funktioniert. Nur mit kindlichem Rumspielen bekommt man es eben meist nicht hin.
Hinzu kommt noch, dass es oft mehr als nur 3 Drähte benötigt, da sind noch ein paar Statusleitungen, welche man im einfachsten Fall brücken muss, damit der Sender überhaupt etwas sendet.
[quote] Ob Default-Werte sinnvoll sind, wurde nicht gefragt, [!quote]
Doch, eigentlich war genau das gemeint mit "keine Ahnung, warum auch immer von allen Leuten 9600 benutzt wird....", das bezog sich aufs default 9600 wie Arduino es eingestellt hat und auch auf die sehr häufig unveränderte Übernahme ins eigene Programm
Der Unterschied ist, dass das Arduino Programm jede Mengen Daten versucht in den Serial Buffer reinzuschaufeln, der aber die ganze Ladung nicht durchschaufeln kann bei 2400 baud, sodass der Serial Buffer ständig überläuft. Es werden also unnütz viele Daten produziert, die sich vor dem Serial Buffer stauen, überlaufen und verloren gehen (für dev0, wie i_make_it richtig schrieb). Also war der Vorschlag, die Daten-Masse durch delays etc. zu begrenzen, wenn eh auf der anderen Seite nur ein Bruchteil verarbeitet werden kann - dann kann man ja immer noch mit 2400 baud übertragen aber hat vor den Serial- und Processing-Engpässen nicht ganz so viel Müll produziert.Und wo liegt der Unterschied?wäre es besser, den Datenstrom am Arduino runterzuregeln durch delays oder millis, und nicht dem Bus am Arduino mit Gewalt (Serial.begin(2400) ) den Hahn zuzuquetschen bis nichts gar mehr reingeht
Mit beiden varianten wird die nutzbare Bandbreite begrenzt. Nur kommt die Herabsetzung der Baudrate ohne zusätzlichen Code aus und lässt sich auch einfach wieder aufheben. Bei Geräten, bei welchen man keinen Einfluss auf den Code hat, ist das Herabsetzen der Baudrate die einzige Möglichkeit, wenn ein Empfänger "überfahren" wird. Wobei es eigentlich noch die genormten Handshakes gäbe!
Das ist eben nur die halbe Wahrheit!
Da ist immer auch noch auf der Gegenseite noch was.
Und die Beiden müssen zusammenpassen, damit es funktioniert.
- - - Aktualisiert - - -
Gab es auch noch als Breakout Box zu kaufen.
Mit Drähten konnte man die Verbindungen zwischen den Steckern stöpseln, wie bei einem Steckbrett.
Gab es auch mit Schaltern für die gebräuchlichen Verbindungen (gerade/gekreuzt, Handshake/Nullmodem).
MfG Peter(TOO)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
Berechtigungen
Zitieren
Lesezeichen