Pro Bot 128 / Projekt: Motorsteuerung verbessern

[Rabenauge]

Zusammen mit deiner mechanischen Stosstange wiederum, hm. Probiers halt mal.
Aber pass auf, dass du dir dabei nicht die Getriebe schrottest-diese Zahnräder sind zwar nicht schlecht, aber nicht grade unverwüstlich.

Bessere Motoren bedeutet nen Totalumbau oder: ne Kiste dieser Spielzeugmotoren aus allen möglichen Quellen zusammenkaufen, und dann zwei "bessere" raus sortieren. die Dinger sind so billig, dass keiner nen ersthaftes Datenblatt für hat, und die gibts auch in diversen Varianten.
Es lohnt nich so wirklich....
Und mal ehrlich: braucht man wirklich 255 Fahrstufen?
Die meisten meiner Modellflug-Regler haben die nicht mal annähernd.

[Schmirk]

Also meine Stoßstangen-Konstruktion sieht zwar ganz gut aus und federt einen aufprall auch schön ab, jedoch werden die taster nicht zuverlässig ausgelöst. hab das iwie schon befürchtet.

das bumper-konzept vom rugwarrior find ich ziemlich gut. würde aber bedeuten, dass ich entweder die haube jedesmal abnehmen müsste, um an die taster zu kommen und diverse ausschnitte für die Sensoren bräuchte oder ich muss alles auslöten und mit steckverbindern direkt an der karroserie installieren. beides keine schöne vorstellung, da aufwendig... aber generell für später denkbar.

die gefühlte verlangsamung der motoren kam durch zu niedrige akkuspannung. letzte nacht erstmal aufgeladen.

habe in einem artikel zur drehzahlregelung beim ct-bot gelesen, dass die dort einfach drei geschwindigkeiten (slow,normal,fast) vorgeben und die PID werte je nachdem differieren. das problem habe ich auch festgestellt. werte die bei langsamer fahrt gut regeln sind für vollgas ungeeignet und umgekehrt. werde wohl meinen code versuchen umzuschreiben.

zum einen will ich die regelung per timer-isr aufrufen und zum anderen nur drei grundgeschwindigkeiten zulassen mit entsprechenden PID-werten.

bei den neuen motoren dachte ich wenn halt an baugleiche, jedoch keine noname, sondern z.b. igarashi oder motraxx tuning motoren vom großen C.

mir würde es erstmal reichen, wenn der bot überhaupt einigermaßen geradeaus fährt. dieses festbeißen an einem thema ohne nennenswerte besserung führt bei mir dazu, dass ich iwann die lust verliere und andere baustellen stillstehen. bin leider nicht so ein crack wie z.b. waste der sprungantworten misst und den regler im simulator parametrieren kann. allerdings geht mir dieses empirische verfahren langsam auf den s***. besser, besser, besser aber nicht gut, schlechter, voll daneben....

[Rabenauge]

PID-Regler richtig justieren erforderd Geduld, wenn man keiner der genannten Cracks ist.
Bin ich auch nicht.
Gibt da aber nen Trick: bastele mal vorübergehend drei Potis ran, und lies die von deinem Bordrecher aus- damit verstellst du zur Laufzeit einfach mal P, I und D und guckst, was passiert.
Falls du keine entsprechenden Eingänge frei haben solltest, leg mal was anderes dafür _vorübergehend_ lahm, das erleichtert die Sache extrem!
Fang mit P an-mit P alleine sollte die Regelung bereits halbwegs funktionieren, I kommt später (damit reagiert sie dann scheinbar schneller), und zuletzt kannst du Feintuning mit D betreiben.
Versuch trotzdem, gleich drei Potis _irgendwie_ ran zu bekommen, denn jeder Parameter beeinflusst die anderen auch wieder.
Mit der Methode hast du die Parameter in ner halben Stunde grob raus.

Ob es qualitativ hochwertigere Motoren in _dieser_ Bauform (weiss nicht, wie die genau im Probot verbaut sind, ob da "ähnlich" auch geht) gibt, weiss ich nicht, ich hab ne ganze Menge kleinerer, aber wesentlich besserer Motoren aus dem Modellbau da- keiner von denen würde wirklich passen ohne etliche Bastelei. Das hatte ich mir beim kleinen Lamborghini schon angesehen- zu viel Aufwand (und obendrein fraglich, ob das Ding mit mehr als der doppelten Leistung noch kontrollierbar wär, die Reifen taugen auch nix).
Wenn du welche bekommst, wieso nicht.
Bessere Motoren können nich schaden. Pass aber auf den Stromverbrauch auf, ich schätze, die Motorsteller wirst du nicht soo einfach tauschen können (wobei man die Dinger u.U huckepack aufdoppeln kann, hab ich auch schon mal gemacht).

[Schmirk]

gut das du es sagst!

das mit dem einstellen während der laufzeit hatte ich schonmal begonnen.
hab dazu einen fest verbauten taster an einem interrupt so programmiert, dass er einen der werte hochzählt bei tastendruck. hat aber durch das prellen des tasters und bis dato in ermangelung einer anzeige dazu geführt, dass ich nie genau wusste, welcher wert tatsächlich eingestellt ist. habe mir damals mit den 4 leds auf der mittleren platine und ner case abfrage eine 4 bit binär anzeige programmiert. da für den d anteil aber meist höhere werte gefragt sind und - wie du grad bestätigt hast - ein wert den anderen beeinflusst, bin ich damit nicht zum ziel gekommen.

deinem vorschlag folgend probiere ich nun folgendes in code umzusetzen:
1. endlosschleife für gradeaus fahrt
2. timer isr abfrage, ob einer der bumpertaster gedrückt ist. muss das dann wohl softwaremäßig entprellen.
3. button interrupt

mit dem button kann ich dann zwischen PID und geschwindigkeit wechseln.
mit bumper links jeweiliger wert -1 und bei geschwindigkeit -10
bumper rechts werte erhöhen

und das ganze gebe ich auf dem lcd aus. könnte auch noch error und die errechneten regelwerte bzw. den speed links und rechts anzeigen lassen. fürchte aber das dadurch die regelung ohne diese zusätzlichen aufgaben wieder anders reagiert...

- - - Aktualisiert - - -

werde auch nochmal den ansatz mit der drehzahlregelung testen. aktuell macht mein code folgendes:

funktion (strecke, drehung, speed)

encoder ticks für strecke in cm oder drehung in grad berechnen, z.b. 3500 ticks für 3m geradeaus.

schleife bis (ticks links+ticks rechts)/2=ticks strecke

error=ticks links-ticks rechts

d.h. beide motoren werden über eine größe geregelt. komme ohne last (aufgebockt) so auch bis auf wenige ticks bei beiden encodern an den ticks strecke wert. unter last im fahrbetrieb sieht das aber wieder ganz anders aus...

mit einer drehzahlregelung, die die soll-ticks pro geschwigkeit mit den ist-ticks vergleicht, könnte ich beide motoren unabhängig voneinander regeln bis die strecken ticks erreicht sind.

wie macht denn eun oberallgeier das bei seinen autonomen dosen? steht bedtimmt auch iwo im thread aber bin grad zu faul zum suchen

[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.