Geradeaus fahren: einfachste Lösung = beste Lösung ?

[s.frings]

Hallo alle,

ich habe unterschiedliche Methode ausprobiert, die Fahrt genau geradeaus mit Hilfe der Odometrie zu regeln. Seltsamerweise funktioniert bei mir die primitivste Regelung am Besten, und das finde ich etwas seltsam. Ich hatte es genau umgekehrt erwartet.

Nun bin ich unsicher, ob meine Lösung wirklich die beste ist, oder ob ich einfach noch eine wichtige Alternative ausprobieren sollte.

Für diejenigen, die den NiboBee nicht kennen: Er hat links und rechts separate Motoren, deren Drehzahl durch PWM geregelt wird und mit IR-Lichtschranken gemessen wird. Die Odometrie zählt für links und rechts jeweils einen Counter hoch, und zwar 20 Impulse pro Rad-Umdrehung. Ich schätze mal, das ist so bei fast allen Roboter-Bausätzen. Also spiegeln die Odometrie Counter die gefahrene Strecke wieder.

Folgende Ansätze habe ich versucht:

Ansatz 1
Wenn counter_links > counter_rechts, dann stoppt der linke Motor.
Wenn counter_links < counter_rechts, dann stoppt der rechte Motor.
Wenn beide counter gleich sind, dann werden beide Motoren auf ungefähr gleiche Drehzahl eingestellt (gleiche PWM Werte), Geschwindigkeit je nach Belieben.
Diese drei Bedingungen werden in der Hauptschleife ständig überprüft.

Das war die einfachste Variante, und die hat prima funktioniert. Nun dachte ich mir, daß durch das abrupte Anlaufen und stoppen der Motoren eventuell viel Schlupf entsteht, was die Meßergebnisse der Odometrie verfälscht. Also wollte ich diese Regelung sanfter gestalten:

Ansatz 2
Wenn counter_links > counter_rechts, dann wird der linke Motor etwas langsamer.
Ansonsten wird der Motor wieder etwas schneller (maximal bis zur gewünschten Fahrgeschwindigkeit).

Wenn counter_links < counter_rechts, dann wird der rechte Motor etwas langsamer.
Ansonsten wird der Motor wieder etwas schneller (maximal bis zur gewünschten Fahrgeschwindigkeit).

Diese beiden Bedingungen werden in der Hauptschleife wiederholt abgefragt, wobei ich das Ganze mit und ohne Delay probiert habe.

Diese Variante führt aber leider dazu, dass der Roboter ständig deutlich sichtbar hin und her schwenkt. Je nach Delay Zeit schaukelt sich diese Regelschleife sogar zu einer Schwingung auf, so dass der Roboter nun eher hin und her eiert, anstatt geradeaus zu fahren.

Ansatz 3
In der Hauptschleife wird die Differenz der beiden Odometrie Counter berechnet (kann positiv oder negativ ausfallen). Der Wert der Differenz wird von der gewünschten Fahrgeschwindigkeit für den linken Motors subtrahiert und für den rechten Motor addiert.
Also je mehr der Wagen nach links abweicht, umso stärker lenkt er nach rechts (und umgekehrt).

Das hat ganz schlecht funktioniert. Auch hier eierte mein Fahrzeug mehr herum, als geradeaus zu fahren.

Jetzt frage ich Dich: Welche Methode könnte ich noch ausprobieren? Oder ist meine erste simple Methode schon die ideale?

[Del]

Hi

Ich würde die Impulse über zwei Interrupts zählen lassen und laufend die PWM Werte anpassen lassen, das geht dann ohne ein Delay und dieses hin und her wackeln sollte dann auch nicht auftreten.

Zudem solltest du die beiden Encoder genau aufeinander abstimmten, bzw. die Abweichgung mit nem Osziloskop vergleichen und dann gleich von Anfang an nen Korrekturwert mit einrechnen.

[s.frings]

Meine einfache Regelung produziert definitiv zu viel Schlupf (jedenfalls bei höheren Geschwindigkeiten, wie ich herausgefunden habe).

Ich denke, daß ein sanfter Anlauf und Stop nötig sein wird, egal mit welcher Methode ich den Geradeaus-Lauf regulieren.

[Del]

Denke ich nicht.
Poste doch mal deinen Code.

[erik_wolfram]

Also ich bin mir da auch nicht ganz sicher, aber wenn man es nüchtern Betrachtet:
Methode 1 reagiert sofort - es kommt zu keiner Verzögerung, während
die anderen Methoden langfristiger sind.
Hinzu kommt, dass Methode zwar sehr abrupt ist, aber 1. durch die hohe Taktung des µC kaum merkbar ist, und 2. besitzen die Motoren eine gewisse Trägheit, welche das ganze "abrundet".
Höchstens, wenn man das ganze so programmiert, dass es die Trägheit kompensiert wird man es effektiver gestalten können - dazu müsste man aber entweder viel probieren oder Daten zum rechnen haben(?!).

[Martinius11]

ich würde dir zur 2.Methode raten den ein bischen ausgebessert kann man
damit wahrscheinlich dauerhaft gute ergebnisse erreichen.Du must halt wirklich ein bisschen rumprobieren, aber ich glaube das sich das lohnen würde.

[s.frings]

Jetzt hab ich's hinbekommen, den Code kann man jetzt auch vorzeigen, siehe https://www.roboternetz.de/phpBB2/viewtopic.php?p=494954.

Die Motoren beschleunigen beginnend mit 20% PWM langsam bis zum gewünschten Soll. Falls ein Rad weiter gefahren ist, als das andere, wird dessen Geschwindigkeit (schlagatig) solange auf die Hälfte (verglichen mit dem anderen Rad) reduziert, bis der Odometer-Stand wieder stimmt.

Beim Bremsen wird die PWM Spannung langsam reduziert, bis auf 20%, dann ganz abgeschaltet.

So klappt der geradeaus-Lauf stabil bei jeder Geschwindigkeit.

[Richard]

Les Dir in RN Wissen einmal den Artikel über Regelkreise
b.z.w. PID Regler durch. Damit lässt sich das noch verfeinern.

Gruß Richard

[bantyy]

Hallo,


ich habe unterschiedliche Methode ausprobiert, die Fahrt genau geradeaus mit Hilfe der Odometrie zu regeln.

ich kann Dir nur empfehlen, die beiden Räder unabhängig voneinander zu regeln. Diese Methode führt auch bei mir zum Erfolg. Ein echter PID-Regler ist am stabilsten, ich habe zunächst einen eigenen Regler dafür gebastelt. Ich vermute, dass es sich eigentlich um einen PI-Regler handelt, allerdings nicht nach den klassischen Formeln. Ich werde meine Regelung nochmal mit dem Stellungsalgorithmus vergleichen, dass scheint meiner Umsetzung zu entsprechen.

Ciao bantyy

[Rabenauge]

Passt irgendwie gerade: hattet ihr auch schon das Problem, dass der NiboBee über vorgegebene Entfernungen hinausfährt?

Regelung soll bei mir als nächstes kommen, aber derzeit läuft er immer 1-3 Odoimpulse über die vorgegebene Strecke hinaus.
Praktisch läuft es so ab, dass ich über ein Menü eine gewünschte Entfernung einstellen kann (in 10cm-Schritten), anschliessend den Roboter in Ruhe hinstellen kann und dann einfach Start drücke. Er berechnet, anhand der vorgegebenen Entfernung, wieviele Impulse der Odometrie nötig sind und legt los. Muss dort wirklich ein sehr schlanker Code benutzt werden, damit das hinhaut? An den Drehzahlen kanns nicht liegen, denke ich (ist derzeit nur so schnell, dass er gerade fährt).

[bantyy]

Hallo,


Passt irgendwie gerade: hattet ihr auch schon das Problem, dass der NiboBee über vorgegebene Entfernungen hinausfährt?

Ich gehe davon aus, dass die Bee bei mir auch zu weit fährt.

Theorie: Die Bee ist nicht ohne Masse und hat damit eine gewisse Trägheit. Die Trägheit wird dazu führen, dass sie nachdem die Motoren anhalten, noch etwas weiter fährt.

Praxis (ich habe kein Display angeschlossen): Die Biene fährt bei hoher Geschwindigkeit für gewöhnlich einige cm weiter als bei niedriger Geschwindigkeit. Geschätzt sind es etwa 5-10 cm, hab es jetzt nicht nochmal ausprobiert.

Okay, zugegeben, meine Wegstrecken-Messroutine wird bei höherer Geschwindigkeit ungenauer, allerdings maximal um 2 cm. Und die Abweichung ist _deutlich_ größer.


An den Drehzahlen kanns nicht liegen, denke ich (ist derzeit nur so schnell, dass er gerade fährt).

Regelung soll bei mir als nächstes kommen, aber derzeit läuft er immer 1-3 Odoimpulse über die vorgegebene Strecke hinaus.

Du weißt schon, dass auf 10 cm 17 Ticks erzeugt werden? Ein Tick entspricht also gerade mal 6 mm. Deine 1 - 3 Ticks entsprechen also zwischen 0,5 und 2 cm - und das schiebe ich mal spontan auf Trägheit von Motoren und der Bee selber.

Was Du tun kannst: Die Werte empirisch ermitteln und von dem eigentlichen Sollwert abziehen.

Ciao bantyy

[Rabenauge]

Jetzt, wo du es sagst....ich habe bevor ich das Display gebaut habe, schonmal damit experimentiert und die Biene fuhr _grundsätzlich_ ungefähr 5mm zu weit. Also einen Odoimpuls etwa.
Das ist schlecht, zumal jetzt der Wert zwischen 1 und 3 schwankt, da ist nix mit herausrechnen.
Ok, mal sehen, ob man das mit gezieltem bremsen in Griff bekommen kann, es _muss_ genauer gehen.

[oberallgeier]

... das Problem, dass der NiboBee über vorgegebene Entfernungen hinausfährt ...Dieses Problem hatte ich bei der Biene (noch) nicht eindeutig gesehen - aber ich hatte dieses Thema bei meiner kleinen Dose - MiniD0 - sehr genau vermessen. Dieses Vorgehen ist bei der Biene sinngemäss möglich und ratsam.

Die Antwort heisst Sprungantwort. Sprich: wie schnell ändert sich die Geschwindigkeit, wenn die Vorgabe sprunghaft ansteigt. Messwerte zur Sprungantwort beim Anfahren habe ich hier vorgestellt. (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=463986&sid=04c0032a1b1ac1b5fb543e811d4f48d4#463986) Rabenauge, zu Deinem Thema "... zu weit fahren ..." passen dann die Messungen bei den unterschiedlichen Bremsvarianten, siehe hier, (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=465839&sid=04c0032a1b1ac1b5fb543e811d4f48d4#465839) da sind die Messdiagramme im Text erläutert und verlinkt. Schließlich war ich so weit, dass ich für eine maximale Bremswirkung (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=466776&sid=04c0032a1b1ac1b5fb543e811d4f48d4#466776) voll Gegenschub gab - also den Motor voll auf die "andere" Drehrichtung schaltete. Das im letzten Link verfügbare Diagramm (http://oberallgeier.ob.funpic.de/spr-a_211009-12h40.jpg) - Variante mit Motorbremse - zeigt die Effektivität dieser Bremsmethode. Natürlich muss der Gegenschub abgeschaltet werden, bevor das Gefährt in die Gegenrichtung rollt . . . . . Dein Gefährt mit den vielen Huckepackplatinen dürfte ja auch etwas schwerer sein als der Standard-Bee. Das schlägt sich natürlich in den Regelungsparametern nieder.

Übrigens hatte ich nach diesen Messergebnissen die Arbeit am Regelungsaufbau für MiniD0 vorerst einmal eingestellt - und andere Dinge gemacht. Genau deswegen, weil ich mich ein bisschen an diesen Stop-auf-dem-Punkt-Problemen bei der Odometrie etwas sehr lange aufgehalten hatte und mal die Schn.... voll hatte. Aber man kann mit einer guten Regelung schon ziemlich hübsche Spielchen machen, siehe Video
................http://oberallgeier.ob.funpic.de/test_1730.jpg (http://www.youtube.com/watch?v=MjLqexH6fDQ)
................Testfahrt auf YouTube (http://www.youtube.com/watch?v=MjLqexH6fDQ)

Dasselbe geht eben auch mit der Biene. Allerdings sind die Bienenreifen eher so ne Art Prime´s, die Haftung ist wirklich lausig. Ich bevorzuge Option´s (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=417039&sid=6ef41419e15a9f01cc984f3a27246651#417039) - siehe ab "... Verzögerungen gabs massenhaft ...", das ist nach dem dritten Bild im Link.


... Ich gehe davon aus, dass die Bee bei mir auch zu weit fährt ...Ich hatte mit einem mega328p die Fahrtstrecke einfach gemessen - und offline - will sagen: nach dem Test, im Stillstand - auf das Terminal ausgegeben. So sind die o.g. Diagramme entstanden.

[radbruch]

Hallo

Ich habe bei meiner bee zusätzliche Löcher in die Coderitzel gebohrt und werte für die Odomatry beide Flanken aus. Das erhöht die Auflösung enorm:
https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=482547#482547

Die Geschwindigkeit wird über eine Zeitmessung mit Timer1 zwischen den Flanken ermittelt. Ausgabe der gemessenen Werte erfolgt über ein LCD mit paralleler 4bit-Schnittstelle an den LEDs (ein Beitrag darüber).

Gruß

mic

[bantyy]

Hallo,



... Ich gehe davon aus, dass die Bee bei mir auch zu weit fährt ...Ich hatte mit einem mega328p die Fahrtstrecke einfach gemessen - und offline - will sagen: nach dem Test, im Stillstand - auf das Terminal ausgegeben. So sind die o.g. Diagramme entstanden.

Also erstmal Gratulation - prima, was Du mit Deinem Roboter gebaut hast!

Ich geb zu, dass ich mir erstmal nicht ganz so viel Mühe mit den Details gegeben hatte - ich wollte erstmal, dass die Kiste überhaupt fährt und am besten auch mal geradeaus. Denn natürlich sind Motoren und Getriebewiderstände etc unterschiedlich, so dass sie bei mir mit gleichen PWM-Werten für Links und Rechts ständig eine Kurve gefahren ist. Ist vermutlich auch normal ;-) Und Regelungstechnik habe ich _irgendwie_ bestanden - wie weiß ich doch nicht mehr. Also hab ich mich erstmal ganz doof gestellt und was ganz einfaches gebastelt - und das funktionierte von Anfang an. Darauf aufbauend habe ich eine Motorregelung mit Geschwindigkeitseinstellung, Kurveneinstellung und Streckeneinstellung gebaut. An der Regelung habe ich noch zwei Kleinigkeiten verbessert, das wars.

Ob die Biene nun 2 Radsensorticks drüber läuft oder nicht ist mir eigentlich auch egal - ich muss die Karre ja nicht balancieren. Blöd ist halt, dass das drüber weg schießen Geschwindigkeitsabhängig ist - das stört mich.

Erstmal ist jetzt aber der RC5-Empfänger dran.

Und dann der Linienverfolger.

Und wenn ich dann mal zwischendurch verzweifel, weil ich die Kiste nicht debuggen kann und kein Loggingsystem drin habe, werde ich wohl mal das EEPROM als Datenlogger aktivieren ;-)

Wenn dass alles mal funktioniert, werde ich mir die Regelung noch einmal richtig vornehmen. Denn das ist ein selbstgebastelter Regler - er hat mindestens einen P und einen I Anteil, das D fehlt da noch. Und ob die Parameter optimal gewählt wurden, wag ich mal zu bezweifeln ;-) Immerhin schwingt das System nicht :-)

Ciao bantyy

[bantyy]

Hallo,


Ich habe bei meiner bee zusätzliche Löcher in die Coderitzel gebohrt und werte für die Odomatry beide Flanken aus. Das erhöht die Auflösung enorm:

Darf ich Fragen, wieviel das zum Fahren nützt? Ich nutze tatsächlich auch steigende und fallende Flanken, aber ohne zusätzliche Löcher. Hilft meiner Regelung aus technischen Gründen - die Auflösung wird dadurch allerdings nicht ernsthaft besser.


Die Geschwindigkeit wird über eine Zeitmessung mit Timer1 zwischen den Flanken ermittelt. Ausgabe der gemessenen Werte erfolgt über ein LCD mit paralleler 4bit-Schnittstelle an den LEDs (ein Beitrag darüber).

Bin neugierig: Und wie regelst Du Deine Bienengeschwindigkeit?

Ciao bantyy

[radbruch]

Hallo

Den Vorteil der zusätzlichen Löcher sehe ich in erster Linie in den gleichmässigeren Abständen der Flanken. Das erleichtet es, die Drehgeschwinidkeit zu ermitteln. Und das ist ja wohl die Basis jeder Regelung.

Dass ich das nicht zum Regeln verwende schreibe ich im letzten Absatz im oben verlinktem Beitrag.


Ich nutze tatsächlich auch steigende und fallende Flanken, ... die Auflösung wird dadurch allerdings nicht ernsthaft besser. Doppelte Auflösung sollte man schon als Verbesserung anerkennen.

Gruß

mic

[Edit]
Ach herrje, ganz vergessen und deshalb nicht erwähnt: Das Programm fährt ohne Regelung nur mit Impulszählen ziemlich genau 1000 Impulse weit...

[Rabenauge]

Jo, andere Räder kriegt die Biene eh, die können ja schon beim anfahren durchdrehen.
Letzten Endes schlecht: wenn ich das fahren komplett so in Griff habe, wie ich mir das vorstelle, dann wird das Tempo natürlich gesteigert.
Und dass meine Biene etwas schwerer ist, mag sein, aber tut im Moment nix zur Sache: die Ergebnisse habe ich mit Bienchen in der Hand "erfahren".
Auf dem Boden ist es geringfügig besser (Untergrund Teppich, eben probiert): dort überrollt sie das Ziel nur um ein oder maximal zwei Impulse- da bremst wohl der Schleifer vorne mit.
Aber die Überlegungen scheinen zu stimmen, wenn ich (eben auch schnell probiert) kurz vor dem Ziel deutlich vom Gas gehe, komme ich näher dran.

Die Ergebnisse sind ansonsten unabhängig von der wirklichen Fahrstrecke, ob 10cm oder 20, es ist immer der gleiche Betrag drüber.
Muss wohl wirklich eine Bremse her..*grmbl

[s.frings]

Ich habe jetzt die Theorie der P, I und PI Regler verstanden und sie in der Praxis ausprobiert. Ein bischen schwierig war es, die idealen Konstanten und das ideale Zeitfenster zu finden, was mit aber letztendlich prima gelungen ist. Spricht: Die Regler haben genau so funktioniert, wie sie sollen.

Allerdings hat sich auch herausgestellt, das der Regler trotz einwandfreier Funktion für meine Aufgabe ungeeignet ist. Die Aufgabe war:

Fahre immer wieder in einer geraden Linie eine exakte Strecke vor und zurück, ohne vom Kurs ab zukommen. Fahre ungefähr mit einer vorgegebenen Geschwindigkeit.
Gleiche auch kleine Hindernisse, wie Krümel auf dem Boden, aus.

Der P-Regler ist dafür ungeeignet, weil er zu schnell beschleunigt und zu abrupt bremst. Außerdem hält er die Geschwindigkeitsvorgabe nicht ein (große Abweichung vom Soll).

Der I-Regler war schon deutlich besser, er Regel nämlich die Geschwindigkeit exakt, aber
er reagiert unzureichend auf Hindernisse, weil das linke Rad nicht abbremst, wenn das rechte von einem Hindernis gebremst wird (und umgekehrt).

Der PI-Regler kombiniert je nach Parametrisierung beide Vorteile oder beide Nachteile miteinander. Auf einen idealen Zweig komme ich jedenfalls nicht, hauptsächlich, wegen unzureichender Reaktion auf Hindernisse, wie beim I Regler.

Mein ursprünglicher Ansatz ist diesen drei Regler überlegen:

Beschleunige beim Anfahren sanft, bis zur Soll-Geschwindigkeit. Bremse kurz vor dem Ziel bis auf eine minimale Geschwindigkeit, um dann an der Zielposition endgültig zu stoppen. Vergleiche ständig die Geschwindigkeit beider Räder und bremse das schnellere Rad so lange ab, bis beide sich wieder gleich schnell drehen. Dann beschleunige (bzw. bremse) wieder sanft bis zur Soll-Geschwindigkeit.

Auf jeden Fall war das Ganze für mich sehr lehrreich, auch wenn mich die P, I und PI Regler nicht zum Ziel gebracht haben.

[Richard]

Versuche es einmal mit PID Regler, PD ist auch schon brauchbar PI eher weniger.


Gruß Richard

[radbruch]

Muss wohl wirklich eine Bremse her..

Du kannst ja ganz kurz in die Gegenrichtung fahren. Ersatzteile fürs Getriebe gibts beim C für ein paar €, aber ich denke, ein paar Tests sollten nichts zerstören.

[Rabenauge]

Ich denke, ich versuchs etwas sanfter. Mit Vollgas Rückwärts klappt es auch nicht, das Problem scheint einfach zu sein, dass die Motoren nachlaufen. Auf diese Weise dürfte es genauso schwer sein, auf dem Punkt zu stoppen.
Ich meine: mein Regler in meinem RC-Monstertruck bringt das Ding auch aus jeder Geschwindigkeit auf weniger als nem halben Meter (und das dosiert) zum stehen, _ohne_ dass der Rückwärtsgang eingelegt wird.
Also Vollbremsung, aber mit ABS, muss doch gehen.
Aber ich glaube, dazu dann mal nen neuen Thread, sonst wird das hier zu durcheinander.

[s.frings]

Der P (und PD) Regler hat das Ziel, die Motordrehzal möglichst schnell zu regeln. Genau dies halte ich aber für ungeeignet, denn es führt zu durchdrehenden Rädern beim Anfahren und bremsen.

Wenn ich den Regler mal einfach creativ anders einsetze uum damit die fahrstrecke zu steuern (anstatt die Geschwindigkeit), würde der Roboter nicht mit der gewünschten Geschiwndigkeit fahren 8die ich nämlich selbst bestimmen will) und er würde im Fall eines sehr warscheinlichen Überschwingers zuerst über das Ziel hinaus fahren, um dann wieder rückwärts zurück zurück an die richtige Stelle zu fahren. Das sähe ziemlich böde aus.

Sehe ich das richtig?

[Rabenauge]

Genau das Problem habe ich ja derzeit.
Grob läuft mein Programm so ab:
Am Anfang gebe ich per Fühler die gewünschte Fahrstrecke ein (in cm, wird schön auf dem Display ausgegeben, rückwärts geht auch), wenn ich meine es ist genug, bestätige ich die Eingabe.
Nun rechnet der ATMega die Fahrstrecke in Bieneneinheiten (Odoimpulse) um.
Inzwischen (das Programm wartet an der Stelle bis ich wiederum eine Taste betätige, so kann ich den Roboter bequem hinstellen) hab ich den Roboter an die Startlinie gestellt, die Starttaste betätigt und er fährt los.
Dabei werden mir derzeit ausgegeben: tatsächlich gefahrene Odoimpulse links, tatsächlich gefahrene Odoimpulse rechts und die noch zurückzulegenden Impulse.
Mit dieser Methode stoppt die Biene _immer_ zu spät!
Dank der Displayausgaben kann ich das leicht überprüfen.
Je länger ich drüber nachdenke, umso weniger wundert mich das, denn der Motor dreht sich für vier Odoimpulse (eine Umdrehung des mittleren Rades) gerade fünf mal, das Ding rotiert also schon mit einigen hundert U/min.
Inzwischen ist mir klar, dass es ohne Regelung (mindestens: gezieltes bremsen) nicht funktioniert.
Nun wird bei mir der Trick drin bestehen, eine sichere Bremsstrategie zu finden, die das Teil auf dem Punkt wirklich stoppt.
Wie du sagst: den Überbetrag zurückfahren klappt nur dann, wenn er gross genug ist (genau einen Impuls hab ich nie geschafft), und dann düst die Biene wieder zu weit.
Am Ende landet man bei immer weniger Impulsen, die dann nicht mehr fahrbar sind. Dort fehlt der Biene einfach das Drehmoment, um sehr langsam auch fahren zu können.

Wenn du es nur "leidlich" genau haben möchtest, genügt es, bei den letzten paar fehlenden Streckenzentimetern deutlich vom Gas zu gehen, dann kannst du eine Genauigkeit von nem Zentimeter erreichen, aber für längere Fahrstrecken (mit mehreren Stops oder Rangiermanövern) ist das nicht zu gebrauchen.

[s.frings]

Ich habe dazu beobachtet, da man mit 20% PWM anfahren muss, sonst bleibt der Motor manchmal hängen, selbst wenn man danach mehr "Gas" gibt. Wenn die der Roboter dem Zielpunkt nähert, kann man aber locker auf 10% runter gehen, ohne dass er stehen bleibt.

Um eine exakte Strecke zu fahren, muss man wohl vor dem Ziel die Geschwindigkeit langsam bis zum Stillstand drosseln.

Man könnte natürlich auch bessere Reifen verwenden, aber das wäre ja zu einfach :-)

Worüber ich mir noch nicht so im klaren bin, ist, wie ich eine exakte Strecke fahre, die nicht geradeaus verläuft. Also einen Boden mit einem bestimmten Radius und einer bestimmten Länge. Die dazu nötige Geschwindigkeit und Odometer Impulse kann ich ausrechnen, das ist kein Problem. Aber wie sorge ich dafür, dass der Roboter seinen Kurs korrigiert, wenn ein Motor mal nicht genau so schnell dreht, wie er soll (was ja praktisch ständig der Fall ist).

Beim geradeaus fahren war das noch einfach: Immer wenn eine Seite weniger Strecke gefahren ist, als die andere, dann nehme ich vom schnelleren Motor die Spannung weg, bis die Zähler wieder gleich sind.

Nun soll das auch bei einem Bogen funktionieren, möglichst ohne Fließkomma-Zahlen.

Dieser Roboter ist viel spannender, als ich gehofft hatte. Ich habe schon seit mehr als einer Woche Spaß mit vor- und und zurück-fahren. Meine Frau findet das völlig banal, aber die sitzt ja auch nicht vor der Tastatur.

[Rabenauge]

Das mit der Frau kenne ich, wenn ich meiner Freundin von meinen Fortschritten erzähle, sieht sie mich genauso an wie ihr Hund, wenn ichs _dem_ erzähle. [-(

Und du hast recht, es macht wahnsinnig Spass, richtig spannend.
Ich habe inzwischen etwas probiert:

Gezieltes Bremsen (ein, zwei Odoklicks vor dem Ziel rückwärts) _kann_ funktionieren, aber zu ungenau, damit kriege ich das Ergebnis runter auf ca. einen Odoklick (ich weiss, blödes Wort aber die Variable in meinem Programm heisst nunmal so und ich glaube, irgendwann denkt man einfach in Variablen :-# ), aber das reicht mir nicht.

Im Moment bin ich dabei, ein Stück vor dem Ziel (derzeit zehn Odoklicks, also rund 6cm) das Tempo zu drosseln, so dass bei Zählerstand Null auch die Motoren stehen: funktioniert nicht wirklich.
Obwohl ich in 50er Schritten runterregle (immer einen pro Klick, weil ich mit Halbgas "repräsentativ" arbeite, ergeben sich weiterhin die üblichen Ungenauigkeiten.
Ausserdem gefällt mir diese Lösung nicht: 6cm Bremsweg??
Es _muss_ deutlich kürzer gehen, sonst ist die Variante viel zu unflexibel.
Leider haben beide Varianten einen grossen Nachteil: sie sind im Grunde unkontrollierbar, man kann in Situationen kommen, in denen der Roboter zu früh oder zu spät steht. Es funktioniert mit voreingestellten Parametern so untergrundabhängig, dass ich bei letzter Methode z.B. auf Teppich das Ziel gar nicht erreichen kann, während der Roboter im Freien ( Räder in der Luft) noch immer zu weit "fährt".

Ich denke, da muss ein eigenes Bremsprogramm hinein, was obendrein die Drehzahl überwacht.
Nur habe ich ab und an jetzt schon den Verdacht, dass mitunter Odoklicks "übersehen" werden, weil einfach irgendwas nicht mehr nachkommt- ist das technisch denkbar?
Soweit ich es richtig verstanden habe, erzeugen doch die Odosensoren einen Interrupt, richtig?
Wenn das aber stimmt, dann _müssen_ die ja auch, falls zurzeit eine andere Interruptroutine läuft (nebenbei strapaziere ich in meinem Programm Timer0 ein bisschen), gespeichert und anschliessend richtig aufgerufen werden? Auch richtig?
Leider hab ich nicht genug Ahnung von der Sache, um beurteilen zu können, _Was_ man besser unterlassen sollte, um den Prozessor nicht nennenswert auszubremsen, ich weiss nur, dass Fliesskommaberechnungen richtig dauern können, darum würdest du wohl gerne ohne auskommen? ;)
Es geht, wenn sie nicht in zeitkritischen Momenten erfolgen, und _das_ kann man umgehen, denke ich (bei hindernisfreier Fahrt kann der Prozessor das nebenbei mit erledigen).
Das Problem bei den gespeicherten (und zeitlich später ausgewerteten Odo-Interrupts ist klar: ehe der Prozessor reagieren kann, stimmt der Odowert im Extremfalle nicht mehr, muss also alles fix gehen.

Die Räder sind übrigens absolut nicht das Problem (wobei klar ist, dass dauerhaft bessere rauf müssen), es ist wie ich sagte:

Die Motoren rotieren nach dem Abschalten noch etwas weiter (normal, Masseträgheit) und dadurch wird übers Ziel hinaus gefahren.
Kannst du auch ohne Display testen:
schreib dir eine kleine Routine, die ein Lämpchen anschaltet, _wenn_ der Roboter zu weit "gefahren" ist und lass ihn einfach, wie ichs tu, leer laufen (anheben), dann kannst du Radschlupf ausschliessen.
Immerhin braucht der Motor durch die Getriebeuntersetzung, nur ein und ne viertle Umdrehung, und schon hast du einen Odoklick zu viel auf dem Tacho.

[oberallgeier]

... Worüber ich mir noch nicht so im klaren bin, ist, wie ich eine exakte Strecke fahre ... wenn ein Motor mal nicht genau so schnell dreht ...GENAU diesen Ausgleich erledigt die Regelu ngstechnik, siehe mein Posting von gestern bzw. dort die Links zum Thread, in dem ich diese Arbeiten für meinen Zweiräder beschreibe. Beweis: das dort verlinkte Video mit dem Testlauf (http://www.youtube.com/watch?v=MjLqexH6fDQ) auf YouTube.