Regelung fürs Geradeausfahren
Hallo!
Ich bin schon eine Weile dabei, daran zu basteln, dass mein Asuro endlich gerade aus fährt. Nach einigen Misserfolgen (vor allem bei der Geschwindigkeitsmessung) bin ich jetzt zumindest so weit, dass ich so ca. die Geschwindigkeit messen kann.
Dann wollt ich was schreiben, dass die beiden Geschwindigkeiten immer gleich geregelt werden. Ich kenn mich leider bei Regelungen nicht sonderlich gut aus, deswegen hab ich mal nur ein Programm geschrieben, was mir die Leistungen von einem Rad erhöht und von anderen erniedrigt(Also wenn das linke schneller ist => links weniger Leistung und rechts mehr Leistung) Hab mir dann die Geschwindigkeiten in LabView ausgeben lassen und halt aufzeichnen lassen. Das Ergebnis ist nicht zufriedenstellend. Ich wollt jetzt fragen ob da wer einen besseren Vorschlag zur Regelung hat. Danke schon mal!
mfg theodrin
Hab jetzt gscheite Regelungen benutzt
Hallo!
Ich hab jetzt einmal einen PI-Regler programmiert und einen PID-Regler. Bin mit dem Ergebnis vom PI-Regler eigentlich überrascht worden. Das hat recht gut funktioniert. Ich hab da so eine kleine Teststrecke von 8 Meter Länge und 1 Meter Breite. Da wollte ich halt das mein Asuro durchkommt ohne an die Seitenwände anzustoßen. Mitn PI-Regler hab ichs eigentlich oft geschaft. Also bei 3 Versuchen hab ichs immer einmal geschaft. Da hab ich mich gleich recht gut gefreut. Dumm war nur dass am Anfang immer ein Rad schneller war als das andere. Das hab ich nicht wegbringen können. Aber dann ist er eigentlich ziemlich schön gelaufen. Nicht immer exakt gerade, leicht geschwenkt, aber er hat den Korridor geschafft. Die Versuche wo er es nicht geschafft hat, ist er meistens bei 5-6 Metern angefahren.
Mitn PID-Regler ist es eigentlich schlechter gegangen, aber vielleicht muss ich da noch die Werte der Regelung ändern. Da hat er es nur mehr 1 mal bei 4-5Versuchen geschafft. Sonst ist er auch so bei 5 Metern gescheitert. Selten ist er ganz dumm gefahren.
Ich werd jetzt morgen das Programm vom Henk probieren. Schauen wir mal was sich da tut.
Ach übrigens: Ich hätte gerne wenn mir jemand bei meiner Geschwindigkeitsbestimmung hilft. Ich vertrau der nämlich nicht ganz. Sie funktioniert nur von einem Leistungsbereich von 130-190 richtig. Ich könnts sie euch mal zeigen. Vielleicht habt ihr bessere, oder könnt mir bei meiner helfen, dass sie "immer" geht.
mfg theodrin
Leider hat dein geradeausfahrprogramm nicht funktioniert
Hallo Henk!
Dein Geradeausfahrprogramm hat leider nicht funktioniert. Es hat zwar so ausgeschaut als würde er versuchen zu regeln, aber es war immer ein Rad schneller als das andere, aber konstant. Also hat dein Programm bei mir einen konstanten Fehler programmiert. Tut Leid, aber so hab ich meine Teststrecke nicht überwinden können. Da hat meine PI-Regelung noch etwas besser funktioniert. Aber das kann ja daran liegen, dass du vielleicht konstante Werte da reinprogrammiert hast, die nur auf deinen Asuro zutreffen. Vielleicht gehörten die bei mir geändert. Na ich schau mal ob ich mit meinem Regelprogramm weiterkomme.
mfg theodrin
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo theodrin,
dass ist ja Schade....
Mmmm....
Dass Program ist geeignet fur Asuro mit Odorader mit 6 Schwarz/Weiss flachen.
Da sich beim fahren die Odowerte durch wechselndes Umgebungslicht andern benutze ich ein festes durch experimentieren gefundene hysteresis von 40 Odowerte. Dass heisst, die hochste und niedrigste Odowerte bei jedem vorbeigehendes Odoflach wird gespeichert. Bewegt sich die momentane gemessene Wert kleiner als aximum-minus-40 oder grosser als minumum-plus-40 dann wird dass wie ein gultiges weiss/schwarz oder schwarz/weiss ubergang interpretiert.
Aber jetzt kommt's:
Weil sich die Odorader durch dass hin und her gleiten auf die Axen naher-an und weiter-weg vom infrarot systeem bewegen andert sich die gemessene Odowert so um die 300 !!!
Da muss ich mein ganzes Prinzip vielleicht uber bord schmeissen.
Meine Asuro fahrt vermutlich ganz gut weil ich die Infrarot Sender und Empfanger umgebogen habe damit die infrarot Strahlung besser ausgerichtet ist und die gemessene Werte weiter aus einander liegen.
Aber daruber bin ich mich noch nicht sicher.
Meine Asuro Odowerte sind: (im Halbschatten):
- Linkerrad weiss naher/weiter 50/400
Linkerrad schwarz naher/weiter 750/750
Rechterrad weiss naher/weiter 35/280
Rechterrad schwarz naher/weiter 615/645
Da sieht mann dass gleiten uber die Axe die reflektierung vom weissen Flach erheblich beeinflusst.
Vielleicht sollte die Hysteresis grosser sein.
Kannst Du vielleicht mal deine min/max odowerte schicken? (program auf meinen Homepage) und dann die 4 Werte posten so wie ich die ach gemessen habe?
Wenn dein Program fertig ist mochte ich es auch mal testen.
Gruss
Hab ein ganz anderes Prinzip gewählt
Hallo Henk!
War grad fort. Mittagessen und für die Schule lernen. Das muss man auch mal machen. Ich hab mir gerade deine Messung durchgelesen und musste an meine Versuche denken.
Ich hab auch mal so gemessen wie du, zwar nicht so genau, eher einfacher.
Das hat nie funktioniert wenn sich die Helligkeitswerte geändert haben. Ich hab immer den Asuro auf so etwas gestellt, damit die Räder den Boden nicht berühren und dann hab ich getestet. Auf dem Prüfstand hat es immer toll funktioniert, aber wie ich auf dem Boden gefahren bin, ist Blödsinn rausgekommen.
Da hab ich gewusst, dass die geänderten Helligkeitswerte schuld sein müssen. Also hab ich vor jeder Geschwindigkeitsmessung Helligkeitswerte gemessen und so wusste halt mein Asuro wann grad weiß und schwarz ist. Das hätte super funktioniert, nur war dann meine Geschwindigkeitsmessung viel zu langsam. Bevor ich einmal die Geschwindigkeit gemessen habe, ist Asuro schon mindestens 35-40cm falsch gefahren. Wenn ich nur 50cm Platz habe ist das ungenügend.
Dann wollte ich die Geschwindigkeit mit den Flanken messen. Das hat nicht funktioniert.
Jetzt mess ich die Geschwindigkeit ganz anders. Ich nehm in einem Feld 100 Odowerte auf und speichere sie dort. Dann schau ich mir einen Wert an und die darauf folgenden. Z.B: Wert 1 und Wert 10-Wert 15 vergeicht er dann. So in etwa. Dann schaut er ob sich dabei die Werte über einer bestimmten Grenze geändert hat. Die bleibt ja so ungefähr gleich, egal ob hell oder dunkel. Dann schaut er wie viele SchwarzeißÜbergänge stattgefunden haben.
Es ist nicht perfekt, dass wusste ich von Anfang an, aber ich war nach drei falschen(eine Methode hab ich noch probiert) eine Trotz-Methpde, von der ich nicht viel erwartet habe. Aber von Leistung 130-190 funktioniert die Geschwindigkeitserfassung und darüber und darunter seltsamerweise nicht.
Code:
#define ANZ 100
#define ABT 2
while(tsys<650)
//Ein mal abtasten ca.200, 2mal ca.500, dreimal ca. 650, usw.
{
ta=Gettime(); //Zeitmessung Anfang
for(i=0; i<ANZ; i++) //Beginn Werte in Feld einzulesen
{
Msleep(2);
OdometrieData(dataodo);
feldlinks[i]=dataodo[0];
feldrechts[i]=dataodo[1];
}
te=Gettime();
t=te-ta;
for(i=0;i<=(ANZ-ABT); i++) //Schwarz-Weiß-Messung
{
ists=uebertraglinks;
uebertraglinks=0;
for(a=0;a<=ABT; a++)
{
abweichung=feldlinks[i]-feldlinks[i+a];
if(abweichung > 100 || abweichung < -100)
{
ists++;
}
if(ists >= (ABT))
{
flankelinks++;
i=i+ABT;
ists=0;
}
}
if(i==(ANZ-ABT))
{
uebertraglinks=ists;
}
ists=0;
}
for(i=0;i<=(ANZ-ABT); i++)
{
istsr=uebertragrechts;
uebertragrechts=0;
for(a=0;a<=ABT; a++)
{
abweichungr=feldrechts[i]-feldrechts[i+a];
if(abweichungr > 100 || abweichungr < -100)
{
istsr++;
}
if(istsr >= (ABT))
{
flankerechts++;
i=i+ABT;
istsr=0;
}
}
if(i==(ANZ-ABT))
{
uebertragrechts=istsr;
}
istsr=0;
}
vl=((flankelinks*60000)/t)/40;
vr=((flankerechts*60000)/t)/40;
flankelinks=0;
flankerechts=0;
tse=Gettime();
tsys=tse-tsa;
}
Vielleicht kannst du ihn verbessern, oder mir sagen, dass er doch Müll ist, aber er funktioniert teilweise wie gesagt.
bis später
mfg theodrin
Liste der Anhänge anzeigen (Anzahl: 2)
Hallo,
@theodrin
- Vielleicht kannst du ihn verbessern, oder mir sagen,
dass er doch Müll ist, aber er funktioniert teilweise wie gesagt.
ich mochte gerne etwas mehr Kommentar dazu lesen...
irgendwo scheint mir dein Program etwas zu kompliziert
Du schreibst: drei Methoden, ich bin jetzt bei 15 oder 16...;-)
Bei jedem Methode lernt sich wieder etwas neues.
@waste
Ich hab dein Program ausprobiert.
Da fahrt die Asuro erstaunlicherweise gerade.
Interessant, wenn mann dass eine Rad mehr oder
weniger blokkiert dreht sich dass andere Rad
gleich langsamer!
Finde dass ein einfaches robustes Program.
Aber wenn der Asuro an das Fenster heran kam
hort er auf gerade zu fahren.
Dein Program arbeitet mit festen vergelichswerte
fur die Odometrie. Da sollte vielleicht noch
etwas variabeles dazu kommen.
@jeden
Ich mochte meinen Prinzip noch mal besser studieren.
Ich mochte gerne wissen warum meine Odometriemessung
z.B. bei theodrin nicht geklappt hat.
Wenn ihr wollt, ladet mal mein neues test Program
dass hier zugefugt ist und schick mir bitte eure
Odometrie daten.
Dass zugefugte Program macht folgendes:
- Asuro startet mit ein durchschnitt geschwindigkeit
- nach 1 Sekunde fahren messt er 250 mal beide odometriewerte
(jeden millisekunde) Die messung daurt 0,25 Sekunde
- Asuro haltet
- startet Hyperterminal
- drucke auf eine beliebige Asuro Taste
- Asuro sendet die gemessene Daten zum Hyperterminal
Schick mir mal bitte die Daten.
Die gemessene Werte sind die 8 hochsten bits vom
10 bit Werte. So Werte von 0 bis 255 werden erscheinen.
Mit Microsoft Excel kann mann dann einfach ein Grafik
daraus machen.
Oder gucke sonst auf meine website. Dort kan
mann dass Program bekommen und meine
Grafiken anschauen.
http://home.planet.nl/~winko001/index.htm
(Logging Odometer values to Hyperterminal)
Ich hab eine Grafik versucht hier zu zu fugen.
Gruss
Henk
Liste der Anhänge anzeigen (Anzahl: 1)
Arexx-Henk,
ich habe mit deinem Programm meinen ASURO getunt. =P~
Code:
Left min/max, right min/max values
1. +00066 +00202 +00138 +00212 // Test dunkel
2. +00061 +00199 +00135 +00209 // Test mit Licht
3. +00007 +00140 +00007 +00134 // Test 2 cm unter meiner Schreibtischlampel
4. +00009 +00199 +00011 +00195 // Test " " + Haube auf Lichtschranke
5. +00056 +00201 +00105 +00205 // Test " " + Haube + schwarzen Filzstift auf der Encoderscheibe.
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo flobot,
erst einmal herzlich willkommen hier im Forum.
Dein Ansatz zur Geradeausfahrt finde ich nicht schlecht. Leider ist nicht immer alles so einfach wie es scheint.
Ich habe mal ein paar Fotos (Film ist zu viel Datenzeugs) angehängt um dir mal das Problem mit meinem Asuro zu zeigen.
Bei mir ist der rechte Motor miserabel (Tschuldigung, einige von euch wissen das schon.), so dass mein Asuro immer mit einer Rechtskurve startet wenn man nichts dagen tut.
Trotzdem ist dein Ansatz auch bei meinem Asuro ungefähr nach 3 Metern funktionsfähig und der Asuro fährt recht ordentlich geradeaus. Klasse Arbeit!
Was ich an deiner Lösung besonders toll finde, ist dass die Reglung ja einen interessanten Ansatz zum lösen des Umgebungslichtproblems hat.
Hierzu ist meines Wissens nach noch kein 'herzhafter' Versuch im Forum aufgetaucht. Ich habe auch gleich eine dicke Taschenlampe zum ärgern vom Asuro rausgekramt und bin echt begeistert wie klein die Abweichungen vom rechten Weg dann sind. Licht aus machen und freudig den geraden Weg sehen war auch nicht schlecht.
Natürlich kommt jetzt nach dem Lob auch gleich das große Fragezeichen in Form von 2 Anmerkungen.
Wenn du auch den Asuro benutzt, hast du als CPU den ATmega8 eingebaut. Das Ding hat gerade mal 1K-Byte RAM.
Du hast in deinem Program aber schon 2 int-Variablen (a 2 Byte) als Array mit jeweils 500 Elementen angelegt. Somit benötigst du eigendlich 2 * 500 * 2 Byte. Ist ein bisschen zu viel. Ich habe bei mir im Programm das ganze über popSize=220 auf 'nur' 880 Byte reduziert. Dann bleibt noch ein Rest für die anderen Variablen und hoffentlich genug für den Stack übrig.
Als 2-tes finde ich deine geschachtelte Schleife in der Funktion findMd sehr 'brutal'. Du loopst mit deinen 500 aus popSize immerhin 250.000 mal da drin rum. Ist es wirklich sinnvoll den Median zu berechnen? Wäre hier ein Mittelwert nicht genauso gut?
Nun noch eine kleine Überschlagsrechnung zu deiner Frage zum Takt der Odometriedaten.
Überschlagen deshalb, da ich nicht zu jedem Maschinenbefehl nachgesehen habe, ob da 1 oder 2 oder auch mal 3 Takte verballert werden.
Ich habe im compilierten Output einfach mal nur die Assemblerbefehle gezählt. Das sind die Angaben mit dem T dahinter.
Deine Loop über OdometrieData
popSize * (29T + 1 * OdometrieData)
Funktion OdometrieData
31T + 2 * ADC
ADC-Wandlung (Hier ist die Zeitangabe recht genau. Maximal plus einen Quarz-Takt)
Quarztakt (1/8Mhz) * 64 (ADC-Vorteiler-In-Init) * 13
(Die 13 gilt ab der 2.ten Wandlung nachdem ADEN eingeschaltet wurde. Für die erste Wandlung muss da ne 25 hin. Vergessen wir das mal ganz schnell wieder, ist ja Haarspalterei)
Ergibt ca.:
ADC-Wandlung = (1 / 8000000) * 64 * 13 = 0,000104 Sekunden
Funktion OdometrieData = 31T + 2 * 0,000104 = 0,000211875 Sekunden
Deine Loop = 500 * (29T + 1 * 0,000211875) = 0,10775 Sekunden
Die Loop in findMd müsste ca. folgende Zeiten haben:
500 * (10 + 2 + 500 * (6 + 17) + 33) = 5772500 Takte = 0,7215625 Sekunden
In Summe verbrennt dein Programm also ca.
2 * findMD + 1 * Loop-Odometrie = 1,55 Sekunden für eine Schleife im Main
Wenn ich für popSize 220 einsetzet, komme ich auf ungefähr 0,68 Sekunden.
Wenn ich die Zeit mal nehme und ein bisschen weiterrechne kommt da folgendes raus:
Ich weiss von meinem Asuro, dass ich ungefähr eine Differenz von 50 in MotorSpeed brauche um halbwegs gerade zu fahren.
Somit brauche ich also ca. 25 mal die Main-Loop. Das sind dann ca. 17 Sekunden.
Da ich die Startgeschwindigkeit mit 150 angegeben habe sollten danach ungefähr die Werte für links und rechts von 125 und 175 rauskommen.
Wenn ich nun schätze, dass ich bei diesen Werten ca. 20 cm pro Sekunde zurücklege und dann knapp 17 Sekunden brauche, müsste mein Asuro nach ca. 340 cm geradeaus fahren.
Scheint also mit meinen oben geschätzten 3 Metern ganz gut im Rennen zu liegen.
So, ich hoffe hier niemanden allzu stark gelangweilt zu haben.
@flobot: Mach weiter so mit guten Ideen.
Liste der Anhänge anzeigen (Anzahl: 1)
hi,
ob das rad dreht oder nicht weiß man ja, weil man das pwmsignal kennt, man kann auch was einbauen, dass sich der wert um mindstens 50 oder sowas ändern muss, damit der neue mittelwert berechnet wird. man kann auch die anzahl der werte zum mitteln von der aktuellen geschwindigkeit abhängig machen, je langsamer, desto mehr werte. aber ich denke, dass sollte auch ohne anpassung kein problem sein(siehe skizze). der mittelwert steigt bei z.b. 10 werten schnell an, sodass die beiden nächsten peaks gut erkannt werden. deswegen auch auf eine feste anzahl der letzten werte begrenzen.
sonst mal die idee mit der ableitung probieren, da sollten solche probleme nicht auftreten.
ein problem könnten periodische lichtänderungen von außen werden.
mfg jeffrey
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo zusammen. (hier wird es ja richtig aktiv!)
Zitat:
Zitat von Torr Samaho 2
einmal "dunkel" (LED aus) und einmal "hell" (LED an) messen
Eigendlich spielt uns hier die Hardware einen Streich, da die Schaltung auf dem ASURO es 'offiziell' nicht zuläßt die Odometrie-LED's auszuschalten und gleichzeitig eine Messung zu machen.
Ich hatte vor einiger Zeit mit folgenden Macros schon mal versucht die Hardware zu überlisten: (Geht auch)
Code:
#define LED_RAD (1 << PD7)
#define PIN_RAD_OUTPUT DDRD |= LED_RAD
#define PIN_RAD_INPUT DDRD &= ~LED_RAD
#define LED_RAD_ON PIN_RAD_OUTPUT; PORTD |= LED_RAD
#define LED_RAD_OFF PIN_RAD_OUTPUT; PORTD &= ~LED_RAD
#define LED_RAD_DARK LED_RAD_OFF; PIN_RAD_INPUT
Hier habe ich DREI Zustände für die LED am RAD: ON, OFF und DARK
Der Trick an der Sache ist, dass ich den Port-Pin als Eingang setze. Somit ist da kein definiertes Signal vorhanden und der Pin 'floatet', soll heissen er passt sich der Spannung von ausserhalb an.
Code:
Für die linke Seite der Odometrie sind im Schaltplan nun folgende Bauteile beteiligt:
VCC an R18 an Port C1 (AD-Wandler)
an R18 an T11 (Odo-Sensor) an Masse
an R18 an D15 (Brems-LED) an R19 an Port D7 (FLOATEND also wenig Einfluss)
an R22 an D13/D14 (Odo-LED) an Masse (STROM)
Wir haben also den Odo-Sensor über den R18 mit Spannung versorgt, ohne über Port D7 Strom auf die Odo-LED zu geben und die Odo-LED zum 'hellen' leuchten zu bringt. Es fließt nur noch Strom über R18/D15/R19/R22 und D13/D14 durch unsere Odo-LED. Dieser Strom ist KLEINER als über Port D7 und somit lassen sich 2 Messungen mit unterschiedlich starker Beleuchtung durch die Odo-LED durchführen.
Mit dieser Methode habe ich auch schon einige Messwerte bekommen.
Siehe EXCEL-Anhang (pure Nettodaten mit einer kleine Hilfe zu den einzelnen Diagrammen bzw. Daten)
Leider kann ich aktuell, und zur Zeit der Datenaufnahme, mit den Daten nichts anfangen, da sie nicht so sind, dass ich daraus eine direkte Berechnung des zu benutzenden Schwellwertes hinbekommen.
Zitat:
Zitat von jeffrey
ich denke nicht, dass das funktioniert, weil man ja nicht weiß, ob zwischen ein und ausschalten ein farbwechsel stattgefunden hat.
Interessanter Einwand, da muss ich mal drüber nachdenken.
Hallo stochri,
auch dein Eintrag ist wie immer eine Überlegung wert.
Ich bin allerdings, aus haarspalterischen Gründen, insgesamt gegen eine Mittelwertbildung egal in welcher Form. (Mal sehen, wann ihr mich doch dazu bringt.) Mein Grund für den Ansatz mit der Hell- / Dunkel-Messung ist, dass ich ohne eine Bewegung versuchen will den Mittelwert zu bekommen. Bewege ich den ASURO ohne den Mittelwert zu kennen, verliere ich (bis jetzt) meistens zwei bis drei Takte der Scheibe. Da jeder Helligkeitswechsel aber 1,5 mm Fahrweg bedeutet sind das schon über 3 mm Positionsverlust.
(Und schon wieder einmal) Rechter Motor ist Schrott. Somit fährt mein ASURO immer NUR links an und damit habe ich einen nicht zu unterschätzenden fehlerhaften Drehwinkel, der dann den Nikolaus bei Tag und Nacht zerstören würde.
EDIT: 08.09.06 09:20 Ich hatte mich bei den LEDs mit der Beschreibung vertan. Odo-LED und Brems-LED vertauscht. Ist nun korrigiert.
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo Leute,
gut dass man Kollegen hat.
Anstatt, wie bei der Linienverfolgung, Hell- und Dunkelwerte von einander abzuziehen, meinte der Kollege, Hell- und Dunkelwerte mal zu dividieren. Die Ergebnisse sahen zwar auch nicht besonders vielversprechend aus, aber folgendes ist dabei rausgekommen:
Sortiert man die Mittelwerte der DUNKELWERTE aufsteigend und trägt das Ergebnis der Division Mittelwert(Hell) / Mittelwert(Dunkel) in einer XY-Ansicht in Excel ein, bekommt man folgende Kurve:
Liste der Anhänge anzeigen (Anzahl: 1)
.. und weiter im Text:
Excel kann auf diese Kurve eine Trendlinie erzeugen. Ich habe eine 'Polynomische' Trendlinie mit 'Reihenfolge' 6 erzeugt. Sie passt am besten auf die Messwerte. Excel liefert dabei die Formel y = 9E-17x^6 - 3E13x^5 + 4E-10x^4 - 2E-07x^3 + 9E-05x^2 - 0,0155x + 1,2523 um diese Trendlinie zu berechnen. Nimmt man nun diese Formel und läßt Excel sie berechnen, kommt aber totaler Schrott dabei heraus, da die Faktoren für die einzelnen Exponenten leider nur mit einer Stelle angegeben werden.
Ausserdem möchte ich bezweifeln, dass wir dem ASURO so eine Formel zum rechnen vorwerfen sollten.
Der nächste Schritt von mir war dann, dass ich einfach eine X-Spalte (Dunkelwerte) von 0 bis 900 in 25'er Abständen angelegt habe und dazu die Y-Werte aus der Excel-Trendlinie 'abgeschrieben' habe. Hierrauf noch eine Trendlinie (auch 'Polynomische' mit 'Reihenfolge' 6) durch Excel legen lassen und die 'abgeschriebenen' Y-Werte so angepasst, dass diese Kurve mit der Trendlinie übereinstimmt.
Diese Tabelle habe ich dann in allen, in den Reitern hinterlegten, Messwerten benutzt um die Schwelle für die Odometriemessung zu berechnen und in die echten Messdaten einzutragen.
In den Reitern 017H01m100 und 018H00m100 sind Messwerte die NICHT zur Ermittlung dieser Tabelle beigetragen haben. Sie zeigen, dass es zumindest da funktioniert.
Weiterhin habe ich mir die Daten dann nochmal angesehen und den Hysteresewert abgeschätzt und auch schon mal in der folgenden Tabelle eingetragen.
Folgende Tabelle ist entstanden: (Zu finden im Anhang im Reiter Formel Spalte I, L und M von Zeile 3 bis 39).
Code:
Dunkel Faktor Hysterese
0 1,000 2
25 0,790 2
50 0,600 2
75 0,460 2
100 0,350 2
125 0,270 2
150 0,220 2
175 0,175 2
200 0,150 5
225 0,135 5
250 0,132 5
275 0,130 5
300 0,128 5
325 0,131 10
350 0,135 10
375 0,138 10
400 0,142 10
425 0,145 10
450 0,150 25
475 0,158 25
500 0,168 25
525 0,177 25
550 0,188 25
575 0,205 50
600 0,225 50
625 0,250 50
650 0,275 50
675 0,300 50
700 0,340 50
725 0,390 50
750 0,430 50
775 0,495 50
800 0,560 50
825 0,650 50
850 0,750 50
875 0,870 50
900 1,020 50
Achtung: Für Dunkel = 0 und ab Dunkel = 900 wird der Faktor 1 bzw größer. Eigendlich bedeutet dies, dass der Odo-Messwert MIT unserer LED-Beleuchtung dunkler werden muss als wenn die LED-Beleuchtung aus ist. Was ist hier falsch??? (Ich habe allerdings als maximalen Dunkelmesswert bis jetzt erst 818 bekommen. Wirklich dunkle Dunkelkammer. Und für strahlenden Sonnenschein als Minimum 28. So dass auf dieser Seite möglicherweise kein Problem auftreten wird.)
Noch habe ich kein Programm geschrieben, in welchem diese Daten genutzt werden. Ich bin mir auch ziemlich sicher, dass die Kurve im unteren Bereich (10 bis 150) noch viel zu wenig echte Messwert hat um tatsächlich korrekt zu liegen, da gerade in diesem Bereich die Steigung der Kurve besonders groß ist, so dass hier Fehler auch große Auswirkungen haben. Wahrscheinlich muss die Tabelle in diesem Bereich auch noch mehr Zwischenwerte bekommen. Dafür lassen sich bestimmt Zwischenwerte im Bereich 350 bis 700 eliminieren.
Hier können noch, auf Teufel komm raus, Messkurven gesammelt werden ;-)
Fazit:
- Dunkelmessung machen
- In der Tabelle den besten Eintrag aus Spalte 'Dunkel' suchen
- Faktor und HYSTERESE der Tabelle entnehmen
- Dunkelmessung mit Faktor multiplizieren. Ergebniss ist SCHWELLWERT
- Hellmessung machen
- Mit Schwellwert und Hysterese, mit bekanntem Code, den Tik-Zähler berechnen.
(Wenn das mal gut geht.)
@jeffrey
Stimmt, meine Methode merkt nicht, dass sich das Rad schon weitergedreht hat. Dein Einwand ist immer noch gültig. (Geständnis: Ich habe da immer noch nicht nachgedacht.) Vielleicht ist dein Vorschlag mit dem Startwert aus der Dunkelmessung und den Mittelwerten da hilfreich.
Liste der Anhänge anzeigen (Anzahl: 3)
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.
