Fahrtregler auf Arduino Basis

Alex

Den Timer immer durchlaufen lassen (auch überlaufen lassen) und den Wert des Timers zuerst bei einer steigenden und danach bei einer fallenden Flanke am Eingangspin abspeichern. Der Abspeichervorgang wird durch Verwendung des externen Interrupteingangs ausgelöst, wobei du das Triggerevent (steigende bzw. fallende Flanke) ja einstellen kannst. Aus der Differenz ergibt sich die Pulsbreite multipliziert mit einem Skalierungsfaktor, der sich aus der zeitlichen Dauer eines Timerschrittes ergibt und damit direkt von der Taktfrequenz und dem Prescalerwert abhängig ist.

IBF

Zunächst wundert mich, dass der Interrupt den ganzen Puls von "einem High" bis zum "nächsten High" blockiert. Sonst wäre es ja nur maximal 2ms und keine 20ms.

Die 20ms sind definitiv ? Ausgemessen?

Ansonsten könnte ich die Methode empfehlen, die ich mache. Aber es ist halt "aufwändig".

Die Arbeitsschleife wird ständig durchlaufen. Für den Status von Deinem Puls hast Du eine Statusvariable. Da ist ein Wert eingetragen, der sagt, an was die Pulserfassung "gerade arbeitet".

Status 0: Das Signal ist "0". Du wartest darauf, dass ein Puls eintrifft.
Wenn Status=0 und Puls=1: Jetzt geht's los. Timer starten (=0) oder den aktuellen Timerwert merken, wenn es ein "Rundumlauf-Timer" ist. Dann den Status auf "1" setzen.
Status = 1: Der Puls-Start wurde bemerkt, Timer ist gestartet. Signal = 1. Jetzt warten, dass das Signal wieder "0" wird.
Wenn Status = "1" und Signal=0: Das Signal ist soeben auf 0 gegangen. Zweiten Timerwert merken (bei Rundumlauf-Timer) oder (bei einem gestartetem Timer) den Zielwert des Timers merken. Timer stoppen. Status auf "2" setzen.
Status = 2: Signal ist jetzt vollständig da und die Timerwerte können ausgewertet werden. Nach der Auswertung: STatus auf "0" setzen und wieder warten, bis der nächste Puls auftritt.

Wie kriegt man das alles mit? : Du muss Dein Programm in einzelne "Scheibchen" unterteilen. Also für jeden Prozessschritt eine kleine Unterroutine anspringen. Und jetzt kommt der Gag: Zwischen dem Anspringen der Unterroutinen springst Du grundsätzlich immer eine einzige Routine an: nämlich die, die den Eingangsport überwacht und abhängig von dem Statuswert die Entscheidungen trifft, wie's weitergeht (=Timer starten/stoppen, Timerwerte merken, Statuswerte verändern,...)

Heißt: Dein Programm wird jetzt etwas länger, weil in praktisch jeder zweiten Zeile das Kommando "Call CheckPulse" steht.
Das ist zugegebenerweise etwas umständlich, aber es funktioniert. Die Technik, wenn man ohne Interrupt einen Puls überwacht bzw. abfragt nennt man "Pollen".

Jetzt kommt bestimmt die Frage, warum so oft die Unterroutine zum Pulserfassen anspringen? => Im Prinzip genügt es ja zunächst mal, pro Schleifendurchlauf die Pulsüberwachung einmal anzuspringen und auszuwerten. Geht. Aber nicht gut. Denn von einem zum nächsten Anspringen muss der Rest in Deinern Arbeitsschleife abgearbeitet werden. Und das dauert. Das heißt, dass Du ein Eintreffen des Pulses oder ein Abschalten des Pulses zu spät erfasst. Somit stimmt die gemessene Zeit nicht. Und somit ist Dein Empfängersignal falsch gemessen. Der Motor würde ständig die Geschwindigkeit ändern (jittern). Darum also so oft wie möglich in der Arbeitsschleife den Eingangspuls abfragen.

// Edit:
Hab' gerade gesehen, dass Alex ein Stückchen schneller war.

Gizmo

Ich habs damals genau wie Alex vorgeschlagen gemacht und das empfinde ich als die bisher beste Variante. Der Vorteil ist beim AVR die wenigen paar Zeilen die dafür notwendig sind und das funktioniert echt prima. Der noch viel größere Vorteil für mich war und ist dass ich mit einem Pin ALLE Kanäle eines Empfängers erfassen kann wenn man an das Summensignal im Empfänger kommt.

Übrigens bin ich an jedem Spektrum Satellitenempfänger interessiert der irgendwer übrig hat und nicht mehr benötigt.

Gizmo

Zitat

Wie kriegt man das alles mit? großes Grinsen : Du muss Dein Programm in einzelne "Scheibchen" unterteilen. Also für jeden Prozessschritt eine kleine Unterroutine anspringen. Und jetzt kommt der Gag: Zwischen dem Anspringen der Unterroutinen springst Du grundsätzlich immer eine einzige Routine an: nämlich die, die den Eingangsport überwacht und abhängig von dem Statuswert die Entscheidungen trifft, wie's weitergeht (=Timer starten/stoppen, Timerwerte merken, Statuswerte verändern,...)

Dafür hab ich mir nen kleinen Scheduler für kooperatives Multitasking geschrieben den ich immer mal wieder missbrauche wenn keine Echtzeit gefordert ist...

Krümmel

So Platiene ätzen Teil 2. Diesmal ist die Steuerplatiene dran.
Diesmal habe ich auf weniger Toner eingestellt und die Leiterbahnen sind super geworden. Nur das mit dem Bügeln habe ich noch nicht so raus. Musste wieder mit dem Edding nachhelfen. Hoffe diesmal sind alle Leiterbahnen drauf und verschwinden nicht. Momentan ist das Ätzbad noch am aufheizen. Was etwa ne Stunde dauert.
Ich melde mich nach dem Bohren nochmal.

Krümmel

So ich renne mal wieder voll gegen eine Wand. Wenn nicht sogar einem ganzen Bunker.
Das Problem was ich habe ist, wenn ich mit Port polling (?) das Signal von Empfänger einlese geht das ganz wunderbar. Aber wenn ich ein zweites Signal einlesen will haut nichts mehr hin. Ich bekomme nur Werte von 6240 µS. Verwende ich nur eine Leseroutine bekomme ich meine Werte von 1000-2000µS. Was mache ich falsch?

int Kanal_1 = 2; //RC Eingang Motor 1
int Kanal_1_high_low; //aktueller high oder low wert
int Kanal_1_high_low_alt; //alter high oder low wert
long Startzeit_Kanal_1; //startzeit
long elapsedTime_1; //vergangene zeit = 1-2ms

int Kanal_2 = 4; //RC Eingang Motor 1
int Kanal_2_high_low;
int Kanal_2_high_low_alt;
long Startzeit_Kanal_2;
long elapsedTime_2;

void setup()
{
  Serial.begin(9600);
  pinMode(Kanal_1, INPUT); //Pin2 als Eingang setzen
  pinMode(Kanal_2, INPUT); //Pin4 als Eingang setzen
}

void loop()
{
  Serial.println(elapsedTime_1);

  //MOTOR 1
  //-----------------------------------------------------------------------------------------------------

Kanal_1_high_low = digitalRead(Kanal_1); //lese Pin und speicher den wert
  if (Kanal_1_high_low == HIGH && Kanal_1_high_low_alt == LOW) //ist ein übergang von low nach high?
{
Startzeit_Kanal_1 = micros(); //setze startzeit ( http://arduino.cc/en/Reference/Micros )
Kanal_1_high_low_alt = Kanal_1_high_low; //schreibe aktuellen pin status in den alten
}

  else if (Kanal_1_high_low == LOW && Kanal_1_high_low_alt == HIGH) //ist ein übergang von high nach low?
{
elapsedTime_1 = micros() - Startzeit_Kanal_1; //errechne den zeitwert 1-2ms
Kanal_1_high_low_alt = Kanal_1_high_low; //schreibe aktuellen pin status in den alten
}

  //MOTOR 2
  //-----------------------------------------------------------------------------------------------------

Kanal_2_high_low = digitalRead(Kanal_2); //lese Pin und speicher den wert
   if (Kanal_2_high_low == HIGH && Kanal_2_high_low_alt == LOW) //ist ein übergang von low nach high?
{
Startzeit_Kanal_2 = micros(); //setze startzeit
Kanal_2_high_low_alt = Kanal_2_high_low; //schreibe aktuellen pin status in den alten
}

  else if (Kanal_2_high_low == LOW && Kanal_2_high_low_alt == HIGH) //ist ein übergang von high nach low?
{
elapsedTime_2 = micros() - Startzeit_Kanal_2; //errechne den zeitwert 1-2ms
Kanal_2_high_low_alt = Kanal_2_high_low; //schreibe aktuellen pin status in den alten
}
}

Alex

Ich würde sagen, dass Statement

Code

Serial.println(elapsedTime_1);

ist auf jeden Fall kritisch.

Du hast eine Baudrate von 9600 Baud. Bei 8 Daten, 1 Start, 1 Stoppbit gibt das eine Bytedatenrate von 960 Bytes/Sekunde. Das bedeutet, dass die Übertragung eines einzelnen Zeichens 1.04 ms dauert. Die Übertragung von 4 Zeichen (was bei einer Angabe der Pulsdauer in us der Fall ist - 1.5 ms = 1500 us) dauert demzufolge 4,16 ms. Nachdem du das bei jedem Schleifendurchgang überträgst ist zu erwarten, dass da einige Pulse untergehen.

Vorschlag:
1) Schraub die Baudrate hoch - 115200 Baud.
2) Übertrage nur jeden 5ten Wert.

Krümmel

Das ist egal welche Baudrate ich verwende. Es geht alles nicht. Wenn ich aber nur ein Kanal einlese geht das alles ohne Probleme. Nur beim zweiten nicht. Und ein Summensignal möchte ich nicht verwenden.

IBF

Zitat

Original von Krümmel
Das ist egal welche Baudrate ich verwende. Es geht alles nicht. Wenn ich aber nur ein Kanal einlese geht das alles ohne Probleme. Nur beim zweiten nicht. Und ein Summensignal möchte ich nicht verwenden.

Mal nachgebohrt: Wie stellst Du das fest? Löscht Du den Bereich aus dem Code oder wird der ausge-"false"t ?

Bei solchen Such-Rätseln mache ich immer gerne die Gegenproben. Also:
1)
Kanal 1 und 2 gleichzeitig aktiv. => Laut Deiner Aussage geht da kein Kanal mehr
2)
Nur Kanal 1 aktiv. Kanal 2 ist ausgefalset. => Geht laut Deiner obigen Aussage
3)
Nur Kanal 2 aktiv. Kanal 1 ist ausgefalset. => Geht das jetzt? Wenn nicht, dann liegt es nicht an dem gemeinsamen Betrieb, sondern irgendwie am Kanal 2.

Mag sein, dass ich etwas übervorsichtig bin, aber ich traue den Compiler-Herstellern nicht so sonderlich über den Weg....
Probier mal aus, wenn Du den Verknüpfungsterm etwas mehr klammerst. Vielleicht hilft das bei der Eingrenzung der Fehlerursache...

Von Dir:
if (Kanal_1_high_low == HIGH && Kanal_1_high_low_alt == LOW)

Mein Vorschlag:
if ((Kanal_1_high_low == HIGH) && (Kanal_1_high_low_alt == LOW))

Dann:
Du gehst bei den Leseroutinen gleich mal in die Vollen. Keine Ahnung, ob Du vorher die beiden "Alt-Variablen" noch auf High oder Low setzt.
Angenommen Du startest die Routine jungfräulich und der Compiler hätte Dir die beiden Alt-Variablen auf Low gesetzt. Dann liest Du Deine Porteingänge und stellst fest, dass das Signal Signal Low ist. Passiert nichts. Wenn das Eingangssignal High wäre, würdes Du Deine Zählervariable (Startzeit) setzen. Diese Zeit kann falsch sein, denn Du hast ja gerade erst mit der Routine angefangen. Aber: Der Puls würde hier nur zu kurz gemessen, nicht die 6000ms.

Also mal weiter gesponnen:
Wenn Deine Alt-Variable auf High gesetzt ist und Du startest die Routine, dann wird beim ersten Einlesen des aktuellen Signals und "Low" die Differenzzeit ausgemessen. Aber in der Variablen für die Startzeit steht nichts (bzw. Blödsinn) drin. Denn es wurde nie ein High-Puls vom Empfänger gemessen und somit eine Zeit in die Variable für die Startzeit eingetragen. Die Berechnung der elapsed-Time kann also auch eine Überlauf produzieren.

Mein Tipp also: In der Initialisierung alle Variablen erst mal auf einen ungefährlichen Wert setzen. Also sowohl die Alt-Variablen auf Low als auch die beiden Variablen für die Startzeit und die elapsed-Zeit auf 0. => Nur reine Vorsichtsmaßnahme, damit Du nicht einem eventuellem Phantom hinterherjagst.

Angenommen, Du hättest einen falschen Pin beim Empfänger gewählt, dann würden diese Variablen nie neu berechnet. Statt einem Blödsinn steht dann immer noch "0" drin. Sowas hilft beim Fehlersuchen im Programm schon mal weiter...

Mit dem Einwand von Alex: Ja, Du kannst hier den UART ganz leicht überfahren. Normalerweise dürfte er die restlichen Prozesse nicht blockieren, aber wer weis das schon...
Hast Du eine Möglichkeit, den Zustand der seriellen Übertragung zu prüfen? Heißt: Gibt es bei "Serial.xxx" eine Statusvariable? Wenn ja, dann steht da garantiert drin, ob der serielle Port gerade am Versenden ist, oder ob er "frei" ist. Mit einer If-Abfrage also nur dann einen neuen Wert eintragen, wenn der Port frei ist.

Alex

Im Grunde ist bei der seriellen die Frage, ob da ein Ringbuffer und Interrupts werken oder eine Routine des Musters

Code

void Serial::println(uint8_t const length, uint8_t const *data) { 
...
for(uint8_t i=0; i<length; i++) {
 if(Serial.readyToSend()) {
  Serial.sendByte(data[i]);
 }
 Serial.waitForByteToBeSend();
}
Serial.sendByte('\n');
...

Reinhards Hinweise bzgl Klammersetzung und auf die nicht-initalisierten Variablen kann ich mich ebenfalls nur anschließen.

Krümmel

Habe den Fehler gefunden. Mein Programm funktioniert. der Fehler lag an dem "langsamen" COM Port. Ich habe die Baudrate auf 115200 ehrhöht und nur den Wert eines Kanals ausgegeben. Bei zwei gibt es wieder ärger mit dem blockieren.
Jetzt könnte es eigentlich langsam an die Regelung gehen........
Dank krankenschein habe ich ja jetztst genug Zeit aber kein ruhiges Ohr (Gehörgangsentzündung). Da ist man nach 2 Jahren mal wieder schwimmen und dann das....

IBF

Oha.... denn eigentlich sollte ein serieller Port schon fähig sein, "parallel" zu anderen Aufgaben seine Daten aus der Leitung zu schubsen. 115kBaud sind halt leider etwas störempfindlich, vor allem wenn Du ein paar Leiterbahnen weiter die Amperes gepulst fließen lässt. Da jubelt jede EMV-Prüfung...

Wie Alex schon vorgeschlagen hat, gib' halt einfach nur jeden x-ten Wert aus, dann kannst Du auch mehrere Zeichen senden, ohne dass der serielle Port überläuft.

O.o.t.:
Beim Baden solltest Du halt warmes Wasser verwenden und nicht im Polarmeer baden. *Scherz* *Immer-Diese-Survival-Trainings*

Gute Besserung !

Krümmel

Ich habe mich jetzt auf jeden 500sten Wert beschränkt. Aber Arduino hat wohl die angewohnheit nichts parallel zu machen .
Jetzt kämpfe ich aber gerade mit meiner Steuerung. Wenn das so weiter geht maschier ich gleich mit nem Panzer irgendwo ein .
Die Super simpel MOSFet feindliche Steuerung funktioniert. Sobald aber PINS mit einer IF Abfrage gesetzt werden sollen geht nichts mehr.
Also teste ich gerade mal wieder ein anderes Konzept.

Alex

Ich habe schon einmal ein Modul für die serielle Kommunikation mit Ringbuffer für ein Arduinu Uno Board implementiert, siehe:
https://github.com/lxrobotics/EM4…_Arduino/UART.c
Grundsätzlich sollte es kein Problem sein, dieses Modul in dein Arduino-Programm einzubinden und anstelle der vor Arduino bereitgestellten Implementierung der seriellen Schnittstelle zu verwenden.

Krümmel

Ich steig zwar nicht durch deine Programmhäppchen durch werde mich aber ncohmal damit befassen.
Erstmal habe ich andere Probleme. Wer weis warum ich nur in Case 1 oder 2 reinkomme obwohl die Signale zwischen 1000 und 2000 liegen?

if (elapsedTime_1 <999 elapsedTime_1 >2001)
{
Kanal_1_Status = 0;
}
else if (elapsedTime_1 <1200) //Der Bereich zwischen 1000µS und 1200µS wird auf 255 gesetzt d.H. Vollgas vorwärts
{
Kanal_1_Status = 1;
}
else if (elapsedTime_1 <=1420 elapsedTime_1 >=1570)
{
Kanal_1_Status = 2;
}
else if (elapsedTime_1 >1800) //Der Bereich zwischen 1800µS und 2000µS ist Vollgas rückwärts
{
Kanal_1_Status = 3;
}
else
{}

switch (Kanal_1_Status)
{
case 0: //Failsafe
// statements
break;
case 1: //vorwärts
if (digitalRead(Bruecke1_rueckwaerts == HIGH) digitalRead(Bruecke1_vorwaerts== LOW))
{
digitalWrite(Bruecke1_rueckwaerts, LOW);
delayMicroseconds(50);
digitalWrite(Bruecke1_vorwaerts, HIGH);
delayMicroseconds(50);
}
break;
case 2: //neutral
if (digitalRead(Bruecke1_rueckwaerts == LOW) digitalRead(Bruecke1_vorwaerts== LOW))
{
digitalWrite(Bruecke1_rueckwaerts, HIGH);
digitalWrite(Bruecke1_vorwaerts, HIGH);
delayMicroseconds(50);
}
break;
case 3: //rückwärts
if (digitalRead(Bruecke1_rueckwaerts == LOW) digitalRead(Bruecke1_vorwaerts = HIGH))
{
digitalWrite(Bruecke1_rueckwaerts, HIGH);
delayMicroseconds(50);
digitalWrite(Bruecke1_vorwaerts, LOW);
delayMicroseconds(50);
}
break;
}

Alex

Zitat

Original von Krümmel
Ich steig zwar nicht durch deine Programmhäppchen durch werde mich aber ncohmal damit befassen.

Ich wollte schon länger mal einen Artikel über die AVR UART im Hinblick auf interruptgesteuertes Senden und Empfangen mit FIFOs schreiben - jetzt hab ich den Task ein wenig höherpriorisiert: http://www.lxrobotics.com/avr-serielle-s…lle-arduino-uno . Weiters habe ich ein Arduino-kompatibles UART Modul mitsamt Arduino Testsketch auf mein GitHub Repositry hochgeladen, viel Spaß damit

Zu deinem Code - sind da nicht ein paar Klammerfehler?
...(digitalRead(Bruecke1_rueckwaerts) == HIGH)...
Weiters verstehe ich nicht, wieso du zuerst (anscheinend von einem Eingang) liest, und gleich danach auf denselben Pin (wie auf einen Ausgang) schreibst, ohne dass dazwischen der Modus umgeschalten wird (Selbst mit Umschalten erschließt sich mir der Sinn nicht).

Krümmel

Der soll die Ports nur Setzen, wenn sie noch nicht gesetzts sind. Sonst werden in jedem Durchlauf ja 100µS verschwendet. Und da ich mit Rampen arbeiten will ist das nicht gerade wenig.
Mit den Klammer das funktioniert. Nur ich komme nicht in den Case 0 oder 3 rein. Sondern nur in 1 und 2.

Alex

Zitat

Original von Krümmel
Mit den Klammer das funktioniert.

Kann ich mir einfach nicht vorstellen. Die Funktion digitalRead(pin_nummer) wird mit der Nummer eines Pins als Argument aufgerufen (siehe http://arduino.cc/de/Reference/DigitalRead ). So wie bei dir die Klammern stehen vergleichst du aber eine Pinnummer mit LOW bzw. HIGH und das Ergebnis dieses Vergleichs wirfst du der Funktion digitalRead als Argument für die Pinnummer vor. Das Ergebnis der digitalRead Funktion ist laut Beschreibung auf jeden Fall HIGH oder LOW und kennt keinen Fehlerrückgabewert. Damit kommen am Ende gültige Werte heraus - mein Tipp: Die if-Abfrgen bei Case 1 und 2 werden auf diese schräge Art und Weise erfüllt, bei Case 3 nicht. Vmtl sind HIGH und LOW als Integer definiert, sonst würde (sollte) der Compiler eine Fehlermeldung/Warnung ausgeben.

EDIT: Nochmal kurz überdacht: Sollten HIGH als 1 bzw. LOW als 0 definiert sein so würde der Zustand der RX und TX Pins der seriellen Schnittstelle ausgelesen werden - nachdem du die Pulsbreite überträgst ist auf der TX Leitung auf jeden Fall heftige Aktivität - Mit allen weiterführenden Effekten ...

Krümmel

So da die mir die Idee mit dem Satelliten gefällt, habe ich mich mal im Netz nach beispielen umgeschaut. Da die bei Ardupilot und Multiwii Satelliten verwenden musste es also auch Beispiele geben.
Gesucht und eine schöne Library gefunden.
Das schöne an den Satelliten ist die kompakte Bauweise, die digitale Übertragung und die Tatsache das das Failsafe schon im Satelliten integriert ist. Ein weiterer Vorteil ich brauche mich nicht mit der "ungenauen" und komplizierten verarbeitung der Pulsmessung auseinandersetzen. Somit bleibt hoffentlich mehr Rechenleistung für den Rest über.
Da im moment kein Raptor o.ä. ins Haus steht und ich schon angefangen habe einen Regler zu bauen, baue ich eben kleiner.
Vielleicht aber auch nur vielleicht baue ich auch eine Programmierbox um Kanäle zu zu ordnen oder einen Kreutzmischer zu aktivieren oder auch nicht. Failsafe: lasthold/off usw.Mal sehen was die Zeit bringt.

Theoretisch brauche ich nur den Datenframe auf meine gewünschten Kanäle abhören, umrechnen und die H-Brücken ansteuern. Bei der Hardware bräuchte ich dann etwas Hilfe.

Nur mal ne Frage rein Interessenshalber. Welche Funktionen wären euch wichtig? Plug´N´Play oder einstellbar? Wenn mit welchen Funktionen?

IBF

Zitat

Da im moment kein Raptor o.ä. ins Haus steht

Mike, was tust Du !
Lass doch mal die Spielereien und fang mit einem Raptor an. Bis zum MMM dürften es noch mehr als zwei Monate sein und innerhalb von vier Wochen lässt sich ein Raptor schaffen. => Also... *MorePowerToYou* (Zitat eines früheren Professors von mir)