Regelung fürs Geradeausfahren

[stochri]

Hallo Sternthaler,
beim Überfliegen Deiner Excel-Datei radS.xls ist mir aufgefallen, dass bei höheren Umdrehungsgeschwindigkeiten das Signal ziemlich zerhackt wirkt.
Das habe ich auch schon mal bei meinen Messungen beobachtet. Mir scheint die Abtastrate für die Analogwerte zu niedrig um das Signal vollständig zu erfassen.

Deshalb ein Vorschlag, der die Messung wesentlich verbessern könnte:

Abtastrate deutlich erhöhen ( Interruptroutine in Assembler schreiben ? )

Gruss,
stochri

[Sternthaler]

Hallo stochri,
ich habe mal 3 Diagramme angehängt, damit wir uns über das gleiche Unterhalten.

1. rads-002H6m000-langsam.jpg
2. rads-005H7m100-schnell.jpg
3. OdoHellDunkel-009H9m100-sehr-hell.jpg

In allen Diagrammen habe ich von Exel jetzt mal die * an den Messpunkten zeichnen lassen. Da sieht man, wie schnell/langsam ich messe.

Zerhackt finde ich nur Diagramm 3.
Dort ist allerdings der Extremfall mit tierisch schönem Sonnenschein zu sehen. (Y-Kurve hat sehr kleine Werte) Hier gibt es auch mit meinen neuen Rechnungen weiterhin die meisten Probleme.

Assembler ist ja gut, aber zum einen lese ich die Sensoren erstmal im Interrupt-Betrieb, und zum anderen habe ich ganz bewusst eine Bremse eingebaut, da die LED's nicht schnell genug an und aus gehen. -> Stom an, LED fängt gemütlich mit einer Ladekurve an Licht zu machen. Stom aus, LED dimmt 'langsam' herrunter. Dieses Verhalten habe ich mit dem Oska gemessen und habe in der Timer-Funktion einige defines zum bremsen eingebaut damit die LED's eben genügend Zeit bekommen so richtig an bzw. aus zu sein.
Im Moment sehe ich aber in meinen Kurven noch nicht, dass ich an der Grenze mit der Geschwindigkeit liege, da ich pro Halbwelle immer noch viele Messdaten bekomme.

[upaucc]

ich habe auch nochmal eine Frage bezüglich waste's ersten codes:

      OdometrieData(data);
      if ((data[0] < 550) && (flagl == TRUE)) {flagl = FALSE; wegl++;}
      if ((data[0] > 650) && (flagl == FALSE)) {flagl = TRUE; wegl++;}
      if ((data[1] < 550) && (flagr == TRUE)) {flagr = FALSE; wegr++;}
      if ((data[1] > 650) && (flagr == FALSE)) {flagr = TRUE; wegr++;}

werden flagl und flagr nicht einfach nur benutzt damit die zähler gleichzeitig loslegen?
man könnte sie doch auch weglassen, dann werden doch auch jeder übergang von hell-dunkel gezählt oder nicht?

[Sternthaler]

Hallo upaucc,
blätter doch noch mal eine Seite in diesem Thread zurück. Ich hatte dort schon mal eine Erklärung zu den Flags abgeliefert.
Vielleicht findet waste ja die richtigen Worte um es verständlicher zu erklären, wenn du damit nicht zurande kommst und evl. doch noch mal nachfragen musst.

[dorothea]

Liebe geradeaus-Regler,

hatte auch so ein ähnliches Programm entworfen und würde gerne dem 3-Meter-Problem dadurch entkommen, dass ich den Offset zwischen dem Vorgabewert vom linken und vom rechten Rad im Permanentspeicher abspeichere.

Gibt es eine Möglichkeit, den Permantentspeicher des Prozessors aus C heraus anzusprechen? Beim Flashen kann ich ja schließlich auch das Programm permanent speichern - also vielleicht geht das auch mit Daten?

Die Idee ist also, den Asuro mal eine Zeit regeln zu lassen und ihn dann dazu zu bringen, dass er sich das, was er beim Regeln gelernt hat, bis zum nächsten Start merkt, damit er dann nicht wieder von vorne anfangen muss, seinen I-Anteil zu lernen.

[stochri]

Hallo Dorothea,

das Eeprom des ATmega8 kannst Du von C aus ansprechen. Die entsprechenden Routinen sind im AVR-Lib-C Manual ( google ) beschrieben ( eeprom.h muss eingebunden werden ).

Gruss,
stochri

[damaltor]

genau. den flash-speicher wirst du nicht einfach knacken können. allerdings kannst du auch einfach die richtigen werte experimentell bestimmen und dann ins eeprom schreiben. 512 bytes speicher ist zwar nicht viel, aber für sowas mehr als genug.

oder du verwendest einfach die go() funktion =)

[stochri]

Hallo Zusammen,

heute habe ich mal mit dem Oszilloskop die beiden Signale der Radencoder nachgemessen. Dabei bin ich zu folgender Erkenntnis gelangt:

1. Die Signale sind zerhackt, wenn sich das Codescheibenzahnrad entlang seiner Achse hin und her verschieben kann. Die Signalampltue ist am besten, wenn sich das Codescheibenzahnrad möglichst nahe an der IR-Diodes befindet. Ich habe das Problem dadurch gelöst, dass ich einen Draht auf die Platine glötet und so gebogen habe, dass er die Zahnräder von außen nach innen drückt.

2. Die Signalamplituden der beiden Fototransitoren sind unterschiedlich, weil sich die Sendedioden an unterschiedlichen Stellen bezüglich der Radachsen befinden. Auf einer Seite sitzt die Sendediode an der Radachse auf der anderes Seite sitzt der Fotodransistor an der Radachse. Wie ich das Signal der schlechten Seite verbessern kann, weiss ich noch nicht. Man könnte aber für beide Seite softwaretechnisch unterschiedliche Schwellen einführen.

So weit erst mal,
stochri

[damaltor]

eine kleine unterlegscheibe, von aussen auf die achse geklebt, oder ein spannring o.ä. helfen auch gegen die bewegung der räder. auch ein kleiner draht, der zu einem U gebogen wurde, und der auf das ende der achse geklemmt wird, geht.
man kann viel an den werten ändern (zum angleichen) indem man (vorsichtig) die led bzw den transistor ein wenig nach aussen oder innen biegt.

[austin2power]

Wieso hat eigentlich noch keiner 'ne Fast-Fourier-Transformation für die Frequenzerfassung der Odometriedaten benutzt?

Sollte doch das zuverlässigste und flexibelste sein, da es ermöglicht, den Offset herauszufiltern, und als Endergebnis die Grundfrequenz ausspuckt, demnach wären Umgebungslichtwechsel und Radstillstand kein Problem mehr - theoretisch die sauberste Lösung.

Viele Grüße
Henning