Pro Bot 128 / Projekt: Motorsteuerung verbessern

[Schmirk]

Der heutige Tag endet mit der Erkenntnis:

Ich hab zwar keine Lösung aber ich bewundere das Problem...

Habe die oben beschriebene Funktion zur Einstellung folgender Werte und Ausgabe über das LCD zum laufen gekriegt:

P, I, D Werte
Startspeed
Delay (nach Abarbeitung der Reglerfunktion)
Strecke in cm

Am Ende kann ich nun mit den voreingestellten Werten per Druck auf den linker oder rechten Bumper mit den voreingestellren Werten die entsprechende Strecke vorwärts oder rückwärts fahren.

Nach Beendigung der Fahrt zeigt mir das LCD außerdem diese Werte:

-berechnete Soll-Encoderticks gem. Strecke

-durchschnittliche IST-Encoderticks berechnet aus (Encoderticks links+rechts)/2

-IST-Encoderticks links und rechts

-Abweichung von IST-Encoderticks links und rechts zu SOLL-Encoderticks als Absolut- und Prozentwert.

Hat sich insofern schon mal gelohnt, als dass ich dabei viel gelernt habe im Hinblick auf eine spätere Menüführung über das LCD (Case Abfragen, Variablen als Flags setzen um das LCD zu löschen, Ausgabe von Variablen auf dem LCD etc.)

Allerdings bin ich bei der Einstellung der PID-Parameter nun mehr als ratlos und muss wohl meinen Reglercode bzw. die Radencoder in Frage stellen. Folgende (paradoxe) Entdeckung hab ich nämlich gemacht:

Das Delay habe ich testweise auf 0 gelassen. D.h. wenn die Regelschleife abgearbeitet ist, fängt sie direkt wieder von vorne an.

PID-Werte=0
Abweichung zwischen SOLL und IST-Ticks (links bzw. rechts) beträgt laut Auswertung bei 200cm Strecke und Vollspeed grade mal +0,04%, auch unter Last.
Allerdings fährt der bot eine Bananengrade...

PID-Werte ungleich 0
Sobald ich beginne die Reglerwerte hochzufahren entsteht bei den linken IST-Ticks eine gemessene Abweichung von +3 bis 10%.
Bei den rechten IST-Ticks verhält es sich anders herum, hier ist die Abweichung -3 bis 6%.
Jedoch fährt der Bot unter Last nun mehr oder weniger grade.

Sobald ich den I-Anteil erhöhe fängt der Bot an immer kleinere Kreise zu drehen. Das bedeutet doch eigtl. das der I-Anteil immer größer wird und der Regler dadurch übersteuert?

Hat jmd. einen Tipp für mich, wo ich mit der fehlersuche beginnen sollte?

Werde die Tage mal meinen Reglercode von "Altlasten" befreien und hier posten. Hoffe irgendwo steckt einfach nur ein dummer Denk- oder Programmierfehler der hier direkt jmd. ins Auge sticht... :-/

[Rabenauge]

I ist der Integral-Anteil.
Der tut-erst mal nichts, ausser beobachten.
Tut sich eine Abweichung auf, dann schaut er auf die Uhr und, je länger die Sache nicht behoben wurde, umso stärker greift er ein.
Daher wirkt I auch immer erst verzögert, bei den heutigen Rechengeschwindigkeiten merkt man das allerdings nicht.

Meiner Meinung nach braucht man für so nen Roboterchen zum geradeaus-fahren lange keinen PID-Regler. Selbst ein Bogen mit, sagen wir, nem Meter Raduis dürft sich auch so beizeiten ausgleichen lassen. Ganz perfekt kann es ohnehin nicht gehen, da du dann nicht nur die encoder-Ticks zählen kannst (was ist nämlich in der Zwischenzeit?), sondern echt eben auch noch die Zeiten zwischen den Ticks möglichst genau messen müsstest.
Und auch dann gibts noch Abweichungen: lass eins der Räder nen paar Millimeter mehr Umfang haben, als das andere (nix neues bei Billigrädern, wie sie überall verbaut werden), schon nutzen die Encoder überhaupt nichts mehr-die können das nämlich gar nicht erkennen.
Dazu müsste man dann schon was unabhängiges haben-Kompass, Gyroskop oder so.
Wenn dein Roboter immer in die selbe Richtung abhaut, dann würd ich im übrigen mal in genau die Richtung schauen: mechanische Ungenauigkeiten. Eventuell verpasst einfach einer der Encoder hin und wieder nen Tick?

Und: du sagst, mit I-Anteil fährt er ne Spirale: bist du sicher, dass die Regelung richtig herum regelt?
Sowas kann nämlich tatsächlich "kippen"- dann kann auch falsch rum gesteuert werden (durch Übersteuern z.B).
Das _kann_ durchaus extrem werden- bei meinem Mini-Segway war das mal so schlimm, dass ich das Ding mit den Händen nicht mehr halten konnte.

[Schmirk]

das mit der mechanischen ungenauigkeit ist auf jeden fall ein teil des problems. die räder sind mit einem ring an der achse befestigt. ein paar millimeter mehr oder weniger spiel und schon läuft das eine rad tlw. nicht mehr an. weiterhin muss ich die encoderscheiben nochmal überarbeiten. die CNY70 "schleifen" nach und nach die markierung ab.

Beim Reglercode muss ich mur meine Variablen nichmal genau anschauen. nicht, dass dort eine überläuft oder die falschen vorzeichen hat.
dabei fällt mir ein: hab gestern den übergabeparameter für den speed an die funktion von integer ( mit vorzeichen) zu byte (OHNE vorzeichen) geändert. ich depp... war nochmal den ganzen code durchgegangen und hab mir gedacht: der speed kann ja sowieso nur 0-255 annehmen. wird aber glaub ich intern auch als regelvariable verwendet. vlt. denk ich aber grad auch nur falsch, weil meine neuronen noch kein koffein bekommen haben. heute abend mal schauen.

[Rabenauge]

Hm-kann man das Ding aufrüsten?
Dir scheint ja eine Menge dran zu liegen, dass er wirklich präzise geradeaus fährt.
Da würd ich kurzerhand nen Gyroskop hinzufügen. Damit sind mechanische Unzulänglichkeiten Geschichte. Ist nämlich so: wenn sich eins der Räder minimal weiter aussen als das andere befindet, kannst du das mit reiner Drehzahlmessung _nicht_ mehr ausregeln, spätestens Kurven werden dann immer schief.
Wenn du nen I2C-Bus hast, wäre ne MPU 6050 preiswert zu haben- die tut den Job, und hat zudem noch ein Acclerometer drauf- kann man auch immer mal brauchen.