- LiFePO4 Speicher Test         
Seite 3 von 7 ErsteErste 12345 ... LetzteLetzte
Ergebnis 21 bis 30 von 67

Thema: Regelung fürs Geradeausfahren

  1. #21
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    13.07.2004
    Ort
    bei Stuttgart
    Alter
    42
    Beiträge
    760
    Anzeige

    Praxistest und DIY Projekte
    hallo,
    was haltet ihr davon z.b die letzten 10 werte zu mitteln, um so einen dynamischen mittelwert zu erhalten, so kann dann auch auf lichtänderungen während der fahr reagiert werden. oder dass man den nulldurchgang der ableitung bestimmt, um so die extrema zu bestimmen, für die geschwindigkeitsmessung ist es ja egal, ob ein feld weiß oder schwarz ist, es ist nur wichtig zu wissen, ob man in der mitte des feldes ist.
    als regler würde ich mal pd verwenden, das ist gut gegen die schwingungen, kann durch den fehlende i anteil aber zu bleibender eegelabweichung, sprich einem langsamen wegdriften führen.
    mfg jeffrey

  2. #22
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    Hallo jeffrey,
    die Idee sieht erst mal gut aus.
    Wenn man sich die Daten aus dem Diagramm von Arexx-Henk hier im Thread aber mal ansieht (und selbst schon solche Daten erzeugt hat), sieht man an dem Diagramm, dass Arexx-Henk bzw. sein Asuro da relativ langsam gefahren ist. --> Ergibt eben viele Messpunkte in einer Periode. Dein Vorschlag nur über 10 Messwerte zu mitteln, verschiebt die 'Mittellinie', also unseren Schwellwert für Hell-Dunkel-Wechsel, bei diesen Daten recht häufig. Bleibt aber tatsächlich immer schön zwischen den Spitzen. Wenn aber der Asuro mal so richtig Gas gibt, dann bekommen wir mal gerade 5 bis 7 Messungen (80 Takte/Radumdrehung Scheibe) pro Periode. Reicht eigendlich um daraus so halbwegs einen brauchbaren Mittelwert zu bilden.
    Nun aber das Problem. Der Asuro fährt extrem langsam oder steht sogar bzw. blockiert. Wenn man nun weiter mitteln würde, dann verlagert sich unser Schwellwert im Extremfall nach ganz oben oder unten. Damit können wir aber im weiteren, wenn der Asuro wieder fährt, nichts mehr anfangen da es jetzt wieder etwas dauert bis der Durchschnitt wieder im Mittel liegt. Also zählen wir erst mal keine Helligkeitswechsel und so verlieren wir schon wieder ein paar Takte.
    Ich bin mir auch sicher, dass kein Regler dieses Problem lösen wird, solange der Ansatz Daten zu sammeln und 'irgenwie' auszuwerten nichts davon weiss, ob überhaupt sinnvolle Daten kommen.

    Hier muessen wir meiner Meinung nach noch ein bisschen weiter grübeln.
    Lieber Asuro programieren als arbeiten gehen.

  3. #23
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    13.07.2004
    Ort
    bei Stuttgart
    Alter
    42
    Beiträge
    760
    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
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken asuro_220.jpg  

  4. #24
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    12.06.2005
    Ort
    Südwestdeutschland
    Beiträge
    1.147
    Blog-Einträge
    3
    Hallo Sternthaler

    Nun aber das Problem. Der Asuro fährt extrem langsam oder steht sogar bzw. blockiert. Wenn man nun weiter mitteln würde, dann verlagert sich unser Schwellwert im Extremfall nach ganz oben oder unten.
    Folgender Vorschlag:

    Maximum und Minimum verwenden.

    Es wird eine Mittelwertspeicher für Maximalwerte und ein Mittelwertspeicher für Minimawerte erzeugt.

    Ein Messwert wird dem Maximalwertspeicher zugeschlagen, sobald er 25 Digits über dem Minimalwertspeicher liegt.

    Nach wenigen Umdrehungen müsste dann die obere und untere Schaltschwelle gefunden sein.

    Gruss,
    stochri

  5. #25
    Benutzer Stammmitglied
    Registriert seit
    04.11.2005
    Alter
    45
    Beiträge
    43
    Hallo,
    um die Störungen durch Fremdlicht wegzubekommen, könnte man doch einmal "dunkel" (LED aus) und einmal "hell" (LED an) messen. Die Differenz ist dann der wahre Wert.
    Gruss

  6. #26
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    13.07.2004
    Ort
    bei Stuttgart
    Alter
    42
    Beiträge
    760
    hi,
    um die Störungen durch Fremdlicht wegzubekommen, könnte man doch einmal "dunkel" (LED aus) und einmal "hell" (LED an) messen. Die Differenz ist dann der wahre Wert.
    ich denke nicht, dass das funktioniert, weil man ja nicht weiß, ob zwischen ein und ausschalten ein farbwechsel stattgefunden hat.
    mfg jeffrey

  7. #27
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    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.
    Angehängte Dateien Angehängte Dateien
    Lieber Asuro programieren als arbeiten gehen.

  8. #28
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    13.07.2004
    Ort
    bei Stuttgart
    Alter
    42
    Beiträge
    760
    hi sternthaler,
    deine idde mit dem bestimmen der werte im stand ist ja ganz gut, dann weiß man auch, dass kein farbwechselstattfindet.
    meine ideen zielen eher darauf ab lichtwechsel während der fahrt, z.b wenn er vom schatten in die sonne fährt, oder so zu kompensieren, weil dann die am anfang ermittelten werte ja auch nicht mehr stimmen. eine möglichkeit wäre beides zu kombinieren, sprich am anfang led an und aus, um von anfang an einen an die umgebungsbedinungen angepassten startwert hat, und dann während der fahrt auf die mittelwert methode zu wechseln.
    mfg jeffrey

  9. #29
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    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:
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken 1-messdunkelquotient.jpg  
    Lieber Asuro programieren als arbeiten gehen.

  10. #30
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    .. 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.
    Angehängte Dateien Angehängte Dateien
    Lieber Asuro programieren als arbeiten gehen.

Seite 3 von 7 ErsteErste 12345 ... LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

fchao-Sinus-Wechselrichter AliExpress