Zitieren@Bammel
Ok Sorry ich hör auf damit!
@waldichecker... ich beobachte die jezze schon länger.. sag mal was sollen immer diese unnützen und sinlossen kommentare? postgeil?
@Bammel
Ok Sorry ich hör auf damit!
Ein winziger Schritt in die richtige Richtung: Motortreiber auf Null wenn Sollfahrt (=iy12PWM) Null ist UND Motortreiber auf Bremsen, wenn der PwM-Sollwert UNTER Null ist, bringt eine winzige Verbesserung in der Reproduzierbarkeit. Leider weiß ich immer noch nicht, ob jemand diese Verzögerungstaktik auch schon angewendet hat.
Der Wald vor lauter Bäumen . . . .:
Viel wichtiger erscheint mir derzeit ein anderes Detail. Im Code (siehe Posting vom 18 Jul 2009, 12:34) ist gezeigt, dass meine Regelungsroutine als Sollwert die Fahrgeschwindigkeit (vom "main" bzw. der zugehörigen "NIR" Nicht-Interrupt-Routine) in der Dimension mm/s bekommt. Daher muss die aktuelle Istgeschwindigkeit in tupsi - also die Zeit zwischen dem vorletzten und dem letzten Odometrie-Interrupt - ebenfalls in mm/s umgerechnet werden. Blödsinn generell und besonders, dies in der ISR zu machen, das ist mir mittlerweile klar.
Die Vorgabe in stupsi (= S oll-tupsi) würde mir die Division "8300 / tuspi" ersparen. Damit komme ich mit der Regelung zeitnäher an den Messzeitpunk, ok, ist weniger bedeutungsvoll, erspare aber einiges an Rechenzeit. (Auszug aus einer Mail an einen Kollegen): Nicht genug der Divisonen: meine Regelungsparameter Kp, Ki und Kd werden ja auch alle „rein-dividiert“. Also Rechenzeitbedarf satt. Gerade überlege ich, was passiert, wenn ich die Geschwindigkeitsvorgabe an die Regelung schon in stupsi mache – das lief früher so (stupsi = Soll tupsi = S oll T imer U nits P er S ensor I nterrupt) und es war wohl bloß die Freude nach einer anschaulichen Führungsgröße, die diese Änderung brachte. Schwachsinn ! ! ! Also wird wieder geändert , Zeit vergeht – und nix Sinnvolles geschieht. So ist das Leben.
Ciao sagt der JoeamBerg
Der Sprung - in der Schüssel oder in den Überraum? ? ?
Für eine gute Regelung braucht man genaue Motordaten.
Zur Kontrolle der aktuellen Eigenschaften der Motoren vom MiniD0 bietet sich die Aufnahme der Sprungantwort an. Keine Frage. Die Sprungantwort hatte ich schon mal ermittelt. Schon damals war mir eine kurze, heftige Drehung in Richtung Motor34 des Gefährts aufgefallen - das ist in Fahrtrichtung eine linke Kurve, Motor 34 ist der Motor, der an den Ausgängen 3Y + 4Y des L293D hängt. Diese Drehung beim Start stellte ich dieser Tage wieder fest. Nachbesserungen am Motor und am Getriebe brachten keine merkliche Besserung, ein anderer Motor oder ein neues Getriebe waren auch etwa so gut oder so schlecht. Offensichtlich ist mein Motor12 eine optimale Ausnahme meines Motorenparks. Mehrere genaue Messungen der Sprungantwort zeigten dieselbe Tendenz: Der langsamere Motor läuft etwa 1 .. 3 ms später an als der schnelle. Dies wurde auch nach Tausch der Motoransteuerungen festgestellt - ein Softwareproblem wurde erstmal nicht vermutet.
................Bild hier
................Zeitabstände zwischen zwei Encoderinterrupts beim Anfahrvorgang beider Motoren. Aufnahme im Abstand von je 1/2 ms.
................Als Sprungfunktion wird 5 ms nach Start der Aufzeichnungen die Motor-PWM auf 255 gesetzt.
Vermutung: Die PWM läuft nicht simultan an.
Der deutliche Verzug beim Motorstart von Mot34 deutete darauf hin, dass die PWM für den Motor34 den übergebenen Wert (vorzugsweise) erst einen Zyklus nach der PWM für Mot12 übernahm: Die PWM wird zusammen mit anderen Initialisierungen gleich nach den Ports gestartet und auf "beide Motoren stop" gesetzt. Laut Atmel-doc gilt für OCR0x: "Update at Bottom" => damit können die beiden Werte für zwei aufeinanderfolgende PWM-Zyklen wirksam werden. Beim geltenden Prescaler sind das rund 1 ms Zyklusdauer. War hier doch die Softwarekonstruktion falsch?
Änderung: NUR für die Aufnahme der Sprungantwort wird OCR0x auf 255 gesetzt, BEVOR der PWM-Timer initialisiert wird. Jetzt starten beide Motoren "gleichzeitig" - das Ergebnis ist reproduzierbar gut.
................Bild hier
................Der höhere Endwert der Geschwindigkeit ist hier auf frisch geladene Akkus zurückzuführen.
Die Sprungfunktion wird für Messzwecke also im Rahmen des Möglichen simultan gestartet. Die Motorcharakteristiken bewirken trotzdem ein Nachhinken des Mot34 beim Anlauf, obwohl der Motor bei Maximaldrehzahl einen Tick schneller läuft. Beides ist aus dem zweiten Diagramm gut abzuleiten.
Bei Verwendung der Regelung wird hier vieles ausgeglichen, daher sind Auswirkungen nur in wenigen Sonderfällen markant, möglicherweise ein Grund für die mäßige Funktion des früher gezeigten Balancierers. Bei dem muss ja dauernd Fahrtrichtung gewechselt werden, da ist ein Versatz von einer Millisekunde schon erkennbar.
Erkenntnis: eine sehr schnelle PWM-Frequenz ist mit Blick auf die Regelung empfehlenswert. Bei meiner derzeitigen Auslegung ist eine schnellere PWM-Frequenz nicht mehr möglich. Am Timer0 hängt der Interrupt für die CIR-perei und die ADC-Messung sowie mit einem Prescaler die Regelung.
Ganz allgemein ist zu vermuten, das ähnliche Probleme bei ähnlichen Lösungen auftreten. Davon dürfte die genaue Funktion einer Odometrie beeinflusst werden.
Geändert von oberallgeier (17.10.2016 um 19:21 Uhr) Grund: neuer bilderservo
Ciao sagt der JoeamBerg
Hallo alle,
ich fürchte fast, dass die vielen Sprungantworten schon jetzt zuviel sind. Aber die Antwort auf "Motor ein" ist leider nur die halbe Wahrheit. Höchstens. Da ich mittlerweile in meiner Regelung bei einer theoretischen Stellgrösse kleiner als Null den Motor elektrisch bremse, wollte ich natürlich mal wenigstens eine ungefähre Vorstellung darüber haben, was sich beim Ausschalten des Motors bzw. bei den unterschiedlichen Arten der Verzögerung tut.
Daher also nochmal drei "Sprung"antworten. Der Anfahrsprung ist klar - PwM auf Maximum, hier also 255. Der Ausschalt"sprung" ist ja weniger klar, es gibt mehrer Möglichkeiten. Die reine und wahre Sprungfunktion ist "volle Bremse" - das ist bei meinen Betrachtungen unten aber erst die dritte Variante. Die hier präsentierten Messungen - alle mit Betonung auf das Abfahren der Motoren - habe ich ohne Last gemacht, die Räder hingen also in der Luft. Sowohl die Antwortfunktion beim Anfahren als auch beim Abfahren bzw. Bremsen sind erwartungsgemäß im tatsächlichen Fahrbetrieb deutlich anders: die positive Beschleunigung ist durch die Massenträgheit des Dosenroboters etwas verzögert, im Schubbetrieb ist die Verzögerung ebenfalls geringer, deutlich geringer als beim Anfahren. Die Ergebnisse unter Last habe ich hier nicht bereitgestellt - wer das wissen will, kann es per PN erfahren, es ist kein Geheimnis. Ich fürchte halt ein bisschen, dass ich das Thema zu sehr strapaziere. Daher auch die Diagramme nur als Link.
Die erste Variante in den Diagrammen ist eine Art abgestuftes "Fuß-vom-Gas" nehmen, schnell, aber nicht plötzlich, sprich: nach Bremsbeginn wird etwa alle 5 ms der PwM-Stellwert um 25 dekrementiert. 5 ms sind etwas kurz, weil bei mir die Regelung mit ca. 100 Hz läuft. Damit ist aber die Tendenz gut zu sehen.
Zweite Variante ist "Gas-sofort-ganz-weg" - ein wirkliche Sprungfunktion, sprich: der PwM-Stellwert wird zu Beginn der Verzögerung sofort auf Null gesetzt.
Dritte Variante ist "Volle-Bremse" - eine zweite, mögliche Sprungfunktion, sprich: zum Bremsbeginn wird bei vollem PwM-Stellwert die aktive (elektrische) Motorbremsung eingeschaltet.
Variante1 und V2 unterscheiden sich praktisch nicht in der Steilheit der Verzögerung. Allerdings tritt die Verzögerung beim gestuften Absenken der PwM mit deutlicher Verspätung von ca. 30 ms ein. Das bedeutet im Vergleich der Diagramme: schaltet man den Motor (!!bei meiner Hardware!!) fast 30 ms später ab als gestuft "Gas wegzunehmen", dann entsteht trotzdem eine praktisch synchrone Verzögerung. Das war überraschend.
Vielleicht nutzen diese Ergebnisse jemandem. Immerhin scheint es hier neu zu sein.
PS. Nun ist auch eins sichtbar: die Maximalgeschwindigkeit des MiniD0 ist mit den getunten
Hackeservo-Getriebemotoren knapp über 500 mm/s.
Geändert von oberallgeier (17.10.2016 um 19:26 Uhr) Grund: neuer bildserver
Ciao sagt der JoeamBerg
Moin moin.Zitat von oberallgeier
Das frage ich mich auch schon länger. Leider bin ich kein Regelexperte,
kann mich aber schwach erinnern einmal etwas von gegenseitig verschränkten Reglern gelesen zu haben. Was immer das auch sein mag.
Ein Denkansatz währe möglicherweise die Regelabweichung des jeweilig
anderen Reglers mit einfließen +/- lassen? Oder einen Übergeortneten
3. Regler der nur für die Differenzen der untergeordneten zuständig ist
und dessen ist/Soll Vorgaben beeinflusst? Fragt sich nur wie mann dann
noch eine Kurve fahren können soll?
Gruß Richard
Genau so sieht mein derzeitiger Entwurf aus. In der Kurve muss eben die kurvenäussere Übergeschwindigkeit berücksichtigt werden.
Meine praktische Erprobung steht noch aus - ich habe mich in der letzten Zeit praktisch ausschließlich mit der oben genannten Regelungsproblematik "Was tun bei Stellwertvorgabe < 0" beschäftigt. Diese Frage steht ja in unmittelbarem Zusammenhang mit dem sauberen Abstimmen zweier Antriebe. Durch diese "Nebentätigkeit" bin ich mittlerweile ziemlich firm zum Thema "Bremsen von kleinen DC-Motoren mit Motortreibern" durch zahlreiche (oder zahl - lose?) Sprungantwort-Aufnahmen zu Brems-Sprungfunktionen. Und seit ganz kurzer Zeit kann ich meinen Zweiräder auch recht sauber stoppen bis zum Stillstand - aktiv stoppen, nicht auslaufen lassen (es lohnt sich dabei, wenn man gute Erfahrung mit Booten der Klasse über 10 to hat).
Sobald ich die übergeordnete Regelung zwischen den beiden Antrieben im Griff habe, werde ich dazu wieder schreiben.
Ciao sagt der JoeamBerg
Klar, die Bremsen nicht so schnell.Ich habe eben etwas gegoogelt,
viel ist nicht dabei herausgekommen außer ein Blockdiagramm bei denen
die ist-werte von 2 Reglern gekreuzt auf die Regelwerte geführt werden.
Gruß Richard
Bei Kreuzungen jeglicher Art gibt es ein Vorfahrtsproblem. Das wird nur dann problemlos, wenn die Vorfahrt geregelt ist.
Ciao sagt der JoeamBerg
Bei Kreuzungen jeglicher Art gibt es ein Vorfahrtsproblem
Nicht wenn "Werner" mit dem Messer zwischen den Zähnen
unterwegs ist.
Gruß Richard
Berechtigungen
Lesezeichen