Thema PID : Wie hast du die H-Brucke angeschlossen an µ ? Ublich ist PWM an Enable von H-Brucke, 2 Direction wird dan fest angesteuert. Leider gibt diese Ansteurung ein recht schlechtes Regelverhalten : Bei PWM Highg wird der Motor angesteuert, aber bei PWM low lauft den Motor eigentlich frei (H-Brucke ist dan hochohmig). Da gibt keine Bremswirkung. Eine bessere Ansatz ist Enable immer High, eine Dir Eingang fest ansteuern, den zweite Dir eingang bekommt PWM. Damit wird den Motor actif Beschleunigt / Abgebremst und bekommst du eine Drehzahl das lineair mit den PWM variert !! Hat wel ein anderes Nachteil : die Stromaufnahme steigt erheblich.
Mehr info ueber mein Balance bot (leider in Niederlandisch) :http://wiki.robotmc.org/index.php?ti...ncerende_robot
Der für mich im Augenblick interessanteste Aspekt von RP6conrad's Videoclips steckt in der letzten Szene des zweiten Films: Die steile Rampe ohne Richtungswechsel des Antriebsmoments hat der Segway perfekt gemeistert, quasi ohne jegliche Pendelbewegung, während er in der Ebene auf glattem Boden deutlich unruhiger war. Sollte einem das zu denken geben? Und wenn ja, was ???
Wie schon gesagt: eine Beobachtung, keinerlei Kritik.
@RP6conrad: Ich hab mir für die Motorenansteuerung einfach ne fertige Platine besorgt- Ebay, für nen 20er (ungefähr)- die zwei Motoren mit bis zu 15A (glaub, bei 30V). Das Ding bekommt zweimal Digital (0-rechtsrum drehen, 1 linksrum) und 2x PWM. Find die Ansteuerung praktisch, das Ding wird extern mit Strom versorgt und gut isses. Was da alles drauf ist-keine Ahnung, die Chinesen haben die Bezeichnungen der Chips sorgfältig runter gefeilt...
Funktioniert aber tadellos und für den Preis...
@RoboHolIC: das ist ein Phänomen, was meiner auch hat: im Stand pendelt das Ding praktisch immer herum. Aber kaum muss er nen bisschen fahren, ist damit Schluss und er läuft total ruhig. Ich vermute, das hängt mit der Massenträgheit irgendwie zusammen: wenn du nen Besenstiel auf dem Finger balancierst, und läufst dabei, geht das auch besser.
Grüssle, Sly
..dem Inschenör ist nix zu schwör..
Och nääh. Relativistischer Besenstiel, weil bewegte Massen immer höhere Masse kriegen? Spass beiseite: Der Unterschied zwischen stabiler Bergaufwärtsfahrt und unstabilem Pendeln auf der Ebene könnte durchaus Hinweise zur Verbesserung enthalten.
Müssen deine Regler gleichförmig durch die Nullzonen hindurch? Geht dort möglicherweise Zeit verloren, während der der Segway relativ abtriebslos rumdümpelt? Man könnte über eine verbotene Zone nachdenken, z.B. +/- 10% PWM, über die beim Richtungswechsel jeweils hinweggesprungen wird. Das ließe auch nahe der "stabilen Ruhe" auf energischen Widerstand gegen die ersten kleinen Abweichungen hoffen.
Möglicherweise liegt dort der Hase wirklich im Pfeffer: die Motoren laufen erst ab nem PWM-Wert von ~ 20 an.
Die "verbotene" Zone hab ich drin, und zwar momentan wirklich bei +-10. Anfangs hatte ich sie etwas höher (knapp unter 20), aber da gabs immer wieder Ruckler im Bereich um Null.
Ruckeln ists nun nicht mehr, eher ein sachtes Pendeln-so auf 10.15 cm. Aber ich werd da mal noch ein wenig herumprobieren, das könnte lohnen..
Den Lego-Testway hatte ich übrigens soweit: bei den geringsten Änderungen (anschubsen im oberen Bereich) hat der sich regelrecht gegengestemmt...das krieg ich beim Grossen irgendwie nicht so hin. Wenn man den schiebt, kullert er einfach los, und fängt sich dann, rollt auch wieder ungefähr zurück..
Grüssle, Sly
..dem Inschenör ist nix zu schwör..
Das klingt irgendwie nach "aperiodischem Grenzfall". Dann sollte man typischerweise die P-Verstärfung reduzieren, wenn ich mich nicht irre. Vielleicht bin ich auch auf dem Holzweg mit meinen Überlegungen, aber ich komme nicht über den PID-Regler weg. Sicher hast du einiges von anderen Segway-Erbauern gelesen. Sind unter den (bitte verzeih!) wirklich gelungenen Lösungen welche mit PID-Regelung dabei?Zitat von Rabenauge
Ganz weit vorne hatte ich ja eine Studienarbeit verlinkt, die die instabile Stab-Wagen-Regelstrecke als Klassiker für nicht-lineare Regelung oder Fuzzy-Regler etc. bezeichnete.
Wenn ich dich damit nerve oder meine Ahnungslosigkeit dokumentiere, dann lass es einfach durchrauschen ...
Nene- mach mal. Auch wenn ich den einen oder anderen Denkanstoss nicht nutze (sei es, weil ich den schon durchhab, weiss, dass es so nicht geht oder auch, weil ich ihn nicht will), heisst das nicht, dass ich nicht gerne andere Meinungen zum Thema bekomme.
Mir ists allemal lieber, ein paar Leute reden mehr oder wneiger qualifiziert mit, als dass alle die Klappe halten und mich alleine grübeln lassen.
P hab ich bereits sehr weit herunter genommen: da bin ich so bei 2-3 im Normalfall (ab einem bestimmten Kippwinkel werdne andere Parameter benutzt, damit dort schneller zugepackt wird)-im Gegensatz dazu liegt der I-Faktor bei 200!
Meiner Meinung nach sollte man das _eigentlich_ mit mittleren P- und nicht zu kleinen D-Werten in den Griff bekommen (da ja D, bei geringeren Abweichungen, K "dämpft")- aber genau das eben funktioniert bei mir nun überhaupt nicht.
Der einzig funktionierende Weg ist eben dieser abartig hohe I-Anteil- der bewirktm, dass schneller ausgesteuert wird. Ich _kann_ den auch niedriger setzen (schon die Hälfte genügt, im Prinzip) ABER: dann kullert er bei ner Störung nicht einige Zentimeter weit, ehe er sich fängt, sondern nen Meter..
Was andere Lösungen angeht: jap. Die meisten Homemade-Lösungen nutzen offenbar eben PID-Regler, wird auch an allen Ecken und Enden empfohlen-auch die Multicopter (deren Problem zugegebenermassen _etwas_ anders ist).
Das Problem ist: es ist unmöglich, zu beurteilen, wie "gut" die wirklich sind: ich kriegs hin, dass meiner ruhig steht. Kann ich machen, aber wehe das Ding soll dann gezielt fahren!
Leider aber sagt z.B. niemand (hab im Arduino-Forum schon gefragt, da hüllt sich alles in Schweigen) wo die Limits der Dinger sind. Der (offenbar recht gut funktionierende) Balanduino z.B. schaltet sich bei 10 Grad Neigung automatisch ab.
Und wenn ich mir ansehe, wie der fährt (er tuts gut, aber doch immer seeehr vorsichtig), ist auch der wahrscheinlich _nicht_ so feldtauglich, wie ich es nun mal haben will (Stubenratten hab ich genug, der _soll_ draussen fahren können).
Kurz gesagt: stelle ich die Regelung auf "böse"- hält die den Burschen. Aber wehe dann, beim fahren kommt eine Störung, die ihn ausser den erlaubten anderthalb Grad Neigung bringt, dann isser nicht mehr zu halten.
Will ich das aber, kann ich den Regler nicht so aggressiv machen, dann wird alles "schwammiger"- dafür packt ers auch bei drei Grad noch, sich abzufangen-dauert nur etwas.
Das Problem wird extrem, wenn ich ihn einschalte: mit ausreichend aggressiver Regelung schaukelt er sich sofort auf, wenn er nicht vorher ziemlich genau grade hingestellt wird...dumm nur: genau das kann im Freien schon mal auch während der Fahrt passieren, so gross sind die Räder ja nun auch wieder nicht.
Grüssle, Sly
..dem Inschenör ist nix zu schwör..
[klugsch....]Mit etwas Abstand betrachtet könnte man aber sagen, dass dein Balancierer gar keinen PID-Regler hat, sondern einen nicht-linearen Regler, dessen Charakteristik durch jeweils zwei Geradenabschnitte je PID-Parameter grob angenähert ist.[/klugsch....]
Ich tippe mal, dass deine Lego-Vorversion ein besseres Verhältnis zwischen Antriebskräften und Masse des Gefährts hatte als das jetzige TomMobil. Ich habe vorhin im Netz einen Kugelballancierer (ebenfalls LEgo) gesehen: Der arbeitete zwar ziemlich ruppig und war recht zappelig, aber er hielt sich auf kleinen Wegen in der Balance. Ähnliches Verhalten habe ich bei verschiedenen Realisierungen auf Asuro-Basis gesehen. Der ist ja ziemlich leicht und nicht gerade untermotorisiert. Vielleicht kannst du deinem Gefährt (vorübergehend) durch Erhöhung der Betriebsspannung Beine machen, um das zu testen? Eventuell zehren auch die größeren Reifen an der Dynamik des Antriebs. Es wäre schon übel, wenn ein gravierender mechanischer Eingriff nötig würde.
Power ist genug da- das ist sicher. Das Ding kann man kaum festhalten wenn er übersteuert (die Antriebe abwürgen geht nicht)- wie gesagt: Panzerantriebe...Eher zerfliegt da irgendwas als dass die Motoren verrecken.
Beim Lego war es andersherum: der war lange nicht soo stark und-ich fand, der balancierte besser. Aber: er hatte auch ne ziemlich kompakte Masseverteilung. Die hat nun der TomWay nicht gerade: oben mittelschwer (Porzellankopf), unten ziemlich schwer, in der Mitte nicht viel- der LegoWay war eher ein kompaktes Bündel.
Und: der LegoWay hat in jeder Hinsicht entschieden "sanfter" (aber ausreichend kräftig) reagiert- der TomWay geht eher ruppig zu Werke.
Was dem jetztigen meiner Meinung nach fehlt ist eine Art "Dämpfung"- leg ich den Finger auch nur leicht auf die Plattform (da, wo der Tom drauf steht) steht die Kiste ruhig! Dann summen die Motoren ein bisschen vor sich hin (kann ich wegbekommen wenn ich die PWM-Frequenz erhöhe, seh ich aber keinen Grund zu im Moment), und er stemmt sich spürbar gegen. Aber da wackelt nix.
Natürlich gibts dann eine Tendenz, in die Richtung loszukullern (weils ja den Schwerpunkt etwas verschiebt)- aber das ist klar.
Daher auch meine erfolglosen Versuche mit den höheren P-und D-Anteilen. Klappt leider nicht...
Möglicherweise liegt das Übel irgendwo zwischen den "billigen" Getrieben und den ebenso billigen Motoren-ich weiss es echt nicht.
Grüssle, Sly
..dem Inschenör ist nix zu schwör..
Nochmal ueber die H-Brucke : du kannst einfach testen wie die das geschaltet ist : Geschwindigkeit versus PWM messen mit verschiedene PWM Werten. In diesen Graph sehen sie das Unterschied zwischen beide Ansteurungen : Die gelbe Linie hat PWM auf enable, die Purple Linie hat PWM auf die Dir-Eingang. Es ist deutlicht das da ein Riesenunterschied ist in Regelqualitat.
Um meine Balancebot auf die gleiche Stelle zu regelen, ist da noch eine "Mittkuplung" mit die Geschwindigkeit : sobald er losfahrt, wird die gemessene Geschwindigkeit mit in die Regelung genommen. Damit beschleunigt den Robby in diese Richtung, und die Winkel geht dan in die Richtung von "abbremsen". Dafur brauchst du naturlich encoder, aber in Prinzip soll da auch mit die PWM-Werte gehen.
Berechtigungen
Zitieren
Lesezeichen