Segway per RC

[Rabenauge]

Hallöle.
Bin auch mal wieder hier- ich tummele mich derzeit eher im Arduino-Forum.
Das aber passt eher hier her...

Folgendes hab ich vor:

Ich möchte einen Segway als RC-Modell bauen.
Nicht zu gross, aber auch nicht klein: "Masstab" 1:4.
Dafür gibts Gründe- dazu später mehr.

Zur Erklärung: ich will _kein_ masstabsgerechtes Modell eines originalen Segway bauen, sondern nur nen Karren, der so funktioniert, wie diese Dinger das eben tun.
Gesteuert werden soll er vorerst (vielleicht lasse ich mir dazu später noch was handlicheres einfallen) mit meiner ganz normalen RC-Anlage: MX-12, 40MHz.
Natürlich will ich nen Standard-Empfänger einbauen, die liegen hier in gewissen Stückzahlen herum.;)
Gesteuert werden soll die ganze Fuhre praktisch wie ein RC-Auto: ein Kanal fürs Fahren (Geschwindigkeitsregelung, evtl. vor-und rückwärts), ein zweiter Kanal übernimmt die Lenkung.
Balancieren, und die Steuerkommandos entsprechend interpretieren soll ein Arduino.
Warum der?
Weil ich mit den Dingern nun schon ein Weilchen herumspiele, weil sie praktisch "plug&play" sind, weil sie mich billiger kommen als was selber zu braten.
Ich weiss, dass es effektiver, "günstiger" und so weiter geht- wenn man die entsprechende Ausrüstung schon _hat_. Ich hab sie nicht, aber zwei Arduino Mega 2560-Clones, Stückpreis nen 15er...dafür löt ich nix selber.:cool:
Der eine der beiden wird in nen Modellschiff wandern, und dort gewisse Zauber auslösen, das ist anderswo schon beschrieben, so weit ich bin.
Der zweite liegt hier herum, und wird zum herummurksen benutzt.
In den Segway wird wahrscheinlich "nur" ein R3-Nachbau kommen, denn der ist locker ausreichend- spart aber Platz!
Gibts für nen Zehner- dafür krieg ich nicht mal ne Platine geätzt...

Was soll konkret in die Maschine: Zwei Motoren, logisch. Keine Bürstenlosen, auch logisch (ich denke, da bräuchte man welche mit Sensoren, da die anderen kaum ausreichend feinfühlig anlaufen, und _das_ würde mein Können einfach überfordern).
Dafür aber wohl mit Getriebe- das macht mich nicht so ganz glücklich (Spiel etc.), wird sich aber nicht vermeiden lassen.
Dazu der Bordrechner.
Dazu ein Sensor, der das Balancieren sicherstellt- ein MPU 6050 ist auf dem Weg zu mir.
Der RC-Empfänger natürlich.
Wahrscheinlich eine bequem, quasi im vorbeifahren, ablesbare Akku-Füllstands-Anzeige. Nein: keine Telemetrie, die brauch ich nicht. Vielleicht ne LED-Anzeige, oder gar ein kleines, hübsches Display, was auch noch nen Kilometerzähler (oder andere, unnötige Spielereien) beinhaltet.
Ein Akku. Da würde ich gerne entweder sechszellige Racingpacks benutzen, oder LiPo`s, die idealerweise als 3s- beides liegt ausreichend hier herum. Insgesamt aber wärs schön, so viel Betriebszeit hinzubekommen, wie eben geht (ohne nen extra Anhänger für weitere Akkus, versteht sich).
Der Pilot: Tom*
Weitere Spielereien wie Licht, Hupe (hätte Tom gerne, am liebste natürlich ne Polizeisirene- Kinder halt) usw. nach Lust, Laune und Geldbeutel.
Die Bordspannung könnte ich mittels Spannungswandlern anpassen, die Dinger gibts inzwischen ja spottbillig, und liefern bei Eingangsspannungen von bis zu 35V beliebig einstellbare Ausgangsspannungen bei 2A...

Ich peile ganz grob ein Kampfgewicht der kompletten Fuhre zwischen 2 und 2.5 Kilo an, das dürfte halbwegs realistisch sein.
Wichtig ist: das Gerät soll outdoorfähig sein, und es wäre schön, wenn wenigstens gemütliches Schrittempo erreicht würde.

Wahrscheinlich werde ich erst einen, weniger aufs Aussehen angelegten, Prototypen bauen, und wenn der anständig läuft, machen wir das Ganze vorzeigbar.

Eine, ziemlich wichtige Frage ist noch nicht geklärt, und hier wärs schön, wenn ihr bisschen mitredet:
Welche Antriebe sollte ich einbauen?

Richtig toll wären umgebaute Servos, aber reichen die wirklich für so ein Ding noch??
Ich meine: hier gehts, wenn es nicht bergab geht, immer bergauf- also bisschen Leistung muss da schon dasein.
Für die Ansteuerung der Antriebe hätte ich noch was in der Kramkiste:
Ein Motorshield für den Arduino. Das könnte zwei Servos direkt ansteuern..oder auch zwei andere Motoren (ich glaub, sogar vier, aber so viele kommen ja gar nicht rein), auch zwei Schrittmotoren wären damit möglich- nur denke ich, auch die laufen nicht weich genug an.
Ausserdem: soll ja nix kosten, wie üblich...Allerdings liefert das Motorshield, nur 600mA bei max 10 Volt- das gibt gerade mal 6W pro Motor.
Wovon ich keine Ahnung habe ist, die benötigte Ausgangsleistung so leidlich zu überschlagen. Meint ihr, das reicht?
Fürs Balancieren bestimmt, aber um dann noch, mit, sagen wir, 4km/h auch bergauf fahren zu können?

Räder werd ich wohl aus dem RC-Car-Bereich benutzen, wüsste einfach nix gescheiteres- Durchmesser irgendwo um die 10cm.



*Tom ist mein Universalpilot. Den habe ich vor Jahren angeheuert für meine Crackerbox, er ist im "Masstab" 1:4, rund 45cm gross.
Mit vollem Namen heisst er übrigens Tom Sawyer. Hat vielleicht jemand schon mal gehört... ;)
Tom ist ein nettes Kerlchen, aber er langweilt sich, da er nur selten raus kommt. als er von diesen Segways hörte, meinte er, sowas braucht er auch.
Schliesslich kann er- da er im Grunde ne schnöde Puppe ist (er hört das nicht gern) nicht laufen- aber fahren wohl!
Der Bursche wiegt nen knappes Kilo- ist also, für seine Grösse, nicht übergewichtig. Er schwimmt sogar- das wurde bei einer Gelegenheit, auf die ich nicht näher eingehen möchte, schon getestet.;)

Sodele. Was haltet ihr davon, und welche Antriebe würdet ihr einbauen, wenn (bei mir üblich...) Ebbe in der Kasse ist?
Wobei: das, was es nun eben kosten muss, werd ich ausgeben, da gibts keine Frage, ich hab keine Lust, an dem Ding später andauernd herumzureparieren, weil ich am falschen Ende gespart hab. Es soll ein praxistaugliches Spielzeug werden.

[Manf]

Eine so nette ausführliche Geschichte zum Einstieg ist schön.
Trotzdem erst einmal eine kurze Antwort. Die Leistung ist Kraft mal Weg pro Zeit.
Da wären einmal die 2,5kg mal 9.81 m/s² in Newton. Üblicherweise nimmt man 30% davon wenn es leicht beschleunigt bergauf geht.
Dazu kommt die Geschwindigkeit von 1m/s.
Das wären dann 10W (mechanisch am Rad).
Elektrisch sind das mit Getriebe mindestens doppelt so viel und vielleicht noch einen Aufschlag für das Balancieren mit seinen schnellen Bewegungen.

[Rabenauge]

hm, danke schon mal.
Ich denke, das wird mit Servos nix.

Wie wären die: http://www.pollin.de/shop/dt/ODE1OTg2OTk-/Motoren/DC_Getriebemotoren/Gleichstrom_Getriebemotor_PGM_37DC12_77.html ?
Ist das einzige, was ich bisher- zu erträglichen Preisen- gefunden habe, wo Spannung und Drehzahl grob passen würden.
So wie ich das sehe, sind das Motoren der "400er" Baugrösse, da wäre man etwas flexibel...

[RoboHolIC]

Die Abtriebsdrehzahl von etwa 1U/sec erscheint mir zu träge und langsam für einen Ballanceakt. Aber das ist nur ein Bauchgefühl. Vielleicht macht dein Pilot mit seinem "Körpergewicht" ja, dass es schnell genug ist.

[Rabenauge]

Kennst du dich mit inversen Pendeln aus?
Man braucht umso weniger Energie, je schneller man reagiert.
Idealerweise sollte die Regelung so schnell sein, dass das Gaze scheinbar völlig ruhig steht. Entsprechend kleine Kräfte brauchts dann auch.
Was diese Getriebe angeht, hatte ich gehofft, jemand kennt die und kann mir sagen, ob da beispielsweise stärkere Motoren anbaubar sind- ich dachte da eventuell an Motoren der 400er Baugrösse- die sollten definitiv ausreichen.
Gestern ist übrigens der MPU 6050 eingetroffen, werd heute mal gucken, was der so macht..

[Rabenauge]

Sodele.
Da ich heute meine Ruhe hab, hab ich nen bissken gebastelt: nen Prototyp. Inspiriert von jemandem aus dem Arduino-Forum, aus LEGO-Teilen.:)Ist im Grunde ein leicht modifizierter Roverbot aus dem Mindstorms-RCX-Set.
War erstaunlich einfach, die Arduinoteile ins Lego zu integrieren-ob das Absicht war??:p
Der hat den riesigen Vorteil, dass ich schonmal an der Software bauen kann, denn das Arduino-Motorshield kann die beiden LEGO-Motoren (ausm RCX-Set, schon fast Raritäten) ganz problemlos ansteuern-die ziehen max. 500mA.
Da es Getriebemotoren sind, sind die nun keine Präzisionswunder, aber ich hab schon mal nen seeeehr simplen LegWay gebaut gehabt- und der funktionierte auch so leidlich.
Praktisch ist der LegUinoWay einsatzfertig- wenn er denn schon Software hätte, die ihm balancieren erlaubt (RC-Empfänger hab ich auch noch keinen dran, aber der passt immer noch rauf).

Wie man Motoren mit dem Ding ansteuert, ist mir auch schon klar (ich hab das Motorshield bisher nie wirklich benutzt gehabt, mangels Einsatzideen, ist aber wirklich easy), und der MPU6050 läuft- dank Kalman-Filtern gibt er sehr hübsch die absoluten Winkel in der X- und Y-Achse aus.
Der nächste Part wird für mich etwas schwieriger: ich muss da irgendwie PWM-Regler einbauen.
Die hab ich, wie ich zugeben muss, bis _heute_ nicht kapiert...glaube, das wird mal Zeit..

Achja: an ner RC-Version hab ich die Tage auch schonmal gebastelt, mir sind da zwei Getriebe aus nem 1:16er Modellpanzer eingefallen, die nutzlos herumliegen. Sollten stark genug sein, aber obs gehn wird....abwarten.
Allerdings brauche ich für die stärkere Treiber, ich hab da was mit runden 5A bei 7.2V in Erinnerung...das wird dieses Jahr wohl nix mehr.

[Rabenauge]

Und weiter, das wird der Abschluss für heute, fürchte ich...

Die PID-Regler sind eingebaut.
Und: sie laufen auch.
Praktische Tests haben ergeben: naja. :cool:
Da muss noch reichlich getunt werden, von alleine balanciert das Teil noch lange nicht.
Dafür aber kann man ihn, indem man ihn in die entsprechende Richtung kippt, schon auch dorthin fahren lassen-> das Prinzip funktioniert also schonmal.
Leider komm ich jetzt nicht mehr weiter: die "Wunderbatterien" (hatte ich eigentlich auch für was völlig anderes, weniger stromfressendes gekauft) streichen die Segel. Hängt das Board noch zusätzlich am USB, reicht der Saft, aber _das_ möcht ich meinem Rechner dann doch nicht antun. Und Segway am Netzteil ist...naja, auch nicht das Wahre.
Ja: ich _könnt_ da jetzt umbauen, und einen meiner Racingpacks benutzen, das würd schon gehn, aber ich hab das Batteriefach so schön eingebaut- ich mags nicht rausrupfen.
Ausserdem haben die LEGO-Motoren 9V lieber. Der Unterschied ist deutlich, ich musste ganz schön an der PWM-Ausgabe spielen, ehe die Regelung überhaupt genug Kraft rausgegeben hat.

Ein Problem hab ich noch gar nicht in Angriff genommen: das Ding muss sich irgendwie selber kalibrieren.
Das tut es nicht, im Grunde schaut der Sensor lediglich, ob er waagerecht liegt-und wenn nicht, wird was unternommen.
Das ist allerdings praktisch unbrauchbar, da das so nur funktionieren kann, wenn der SegDuinoWasauchimmer gleichmässig beladen ist, also der Schwerpunkt genau über der Achse- anderenfalls wird er _immer_ davonlaufen- in die Richtung, in der er schwerer ist.
Das geht so mal nicht, das Ding muss sich automatisch _unter_ seinen Schwerpunkt fahren, nur dann wirds endgültig funktionieren.

[Rabenauge]

So. Wieder einige Tage gespielt-mich zwischendurch nen paarmal im eigenen Code verfangen- und inzwischen klappt es sehr gut.
Ich behaupte mal, dass ich inzwischen nen PID-Regler zu 80% verstehe.
Das Balancieren funktioniert inzwischen so weit, dass ich dem Teil neue Software einspielen kann, während er- per USB-Kabel am Rechner hängend- balanciert. Auf nem kleinen Kuchenbrett- mehr Platz hab ich hier am Tisch nicht.:cool:
Allerdings hats noch ne kleine Nachrüstung gegeben: ich hab ihm ein Brettchen engebaut, was mehrere Potis trägt, damit ich den Regler mehr oder weniger im Betrieb justieren kann- das vereinfacht die Sache wesentlich.

Es ist noch keineswegs so, dass er nun immer völlig ruhig steht, ich benutze momentan zwei Sätze Regelparameter, bei Abweichungen von bis zu nem halben Winkelgrad (der Mpu gibt Resultate im Hundertstel Gradbereich) wird ein Satz Parameter benutzt, die die Regelung sanfter arbeiten lassen-wird die Abweichung grösser, wird nen Regel-Gang hochgeschalten.
Den Tip habe ich im Arduino-Forum bekommen, ich meine, wenn der PID _perfekt_ justiert ist, braucht man es nicht, aber es macht die Geschichte halt robuster.

Das Batteriefach ist auch rausgeflogen- ich betreibe den XYZ-Way nun mit nem Racingpack aus meinen RC-Modellen, dass reicht bei den LEGO-Motörchen nen halben Tag, und ist in ner halben Stunde wieder voll.
Ich deke, in ein, zwei Tagen hab ich das Bürschlein so weit, dass er brav stillsteht, auf Befehl. Dann kann ich mich weiteren Dingen widmen, bin am überlegen, ob ich dem kleinen nicht einfach mal einen Infrarot-Sensor anstöpsele, dann kann ich ihn per Fernbedienung herumfahren lassen später.
Die RC-Anlage würd ich ihm ungerne anbauen, meine Empfänger tun gerade Dienst in anderen Modellen und die wirkliche RC-Version soll ja sowieso grösser werden.

[Rabenauge]

So. Der LEGO-Kram ist raus aus der Geschichte nun.
Hab in der letzten Zeit ein bisschen gesägt, geschliffen, geklebt, gelötet und ...so weiter eben.
Inzwischen ist der Prototyp-ich sage mal, rohbaufertig.
Und: er fällt schon selten um- allerdings ist die Regelung noch nicht Top- das geht noch besser, da bin ich sicher (mal ehrlich: ich hab das Programm, was ich für diese Version ja umschreiben musste, kaum ne Stunde bearbeitet bisher).
Angetrieben wird das Ungetüm derzeit von zwei Getriebemotoren aus nem HL-Panzer- die lagen da so rum, sind zwar etwas grösser als ichs gut finde (und noch viel lauter als ichs gut finde), aber kräftig genug und schnell genug.
Als Rechenknecht ist ein kleiner Uno an Bord- den Mega brauchts laaange nicht, so viel ist zu dem Ding ja nicht zu.
Angesteuert werden die Motoren über eine Treiberplatine, die es so um nen Zwanziger in China gibt- kann bis zu 40V und 15A- das genügt.
Ansonsten ist da noch ein RC-Racingpack (ich hab noch die richtig tollen, wirklich robusten NC-Akkus) an Bord-sechs Zellen, 7.2V- klappt auch gut.
Fehlen noch der RC-Empfänger (der wäre schon da aber erstmal will ich, dass die Kiste alleine ruhig steht, dann kümmern wir uns ums fahren), ein kleines Display und ein paar Spielereien, wie ein Spannungsteiler um den Akku zu überwachen-wär blöd wenn das Ding mangels Strom unterwegs umfällt.
Und anständige Räder: momentan schaukelt das Teil auf Modellmotorrad-Rädchen umher, die mir aber ein bisschen zu klein sind. Power haben die Motoren allemal genug-und besser aussehen würds auch.
Tom hat auch schon mal probebalanciert vorhin: sein Urteil: Coole Kiste aber bisschen besser kriegst das ja wohl hin??
Recht hatter- hoffe ich doch.

In diesem Sinne....

[Rabenauge]

Aktueller Stand der Dinge...
Tom übt schon mal- wie man sieht, noch mit Stütze..;)
Aber der Bursche ist schon recht stolz auf sein Vehikel und nervt andauernd, wanns denn nun endlich fertig wird.
Naja- bisschen wird es noch dauern, zum einen weil noch gar kein Rc-Empfänger an Bord ist, zum anderen, weil die Regelung zwar gut, aber noch lange nicht _richtig_ gut arbeitet- ich will, dass das Ding, im Stillstand, auch wirklich still steht.

Eigentlich war_dieses_ Vehikel nur zum Testen gedacht, aber inzwischen hab ich so das Gefühl, dass es mit kleineren Abwandlungen schon nahe an der Endfassung ist. Vielleicht zum Schluss noch hübsch mit Edelholzfurnier verkleiden, würde zu Toms Outfit passen.
Natürlich wird auch die Motorsteuerung noch abgedeckt, aber im Moment hab ich kein Sperrholz da, und oben auf die Säule soll noch ein kleines Display- richtig toll wären da Mini-Nixies (also richtige Röhren) aber die sind mir dann doch zu schade für. Ein winziges OLED-Display ist auf dem Weg zu mir, wenn das da reinpasst, kommts drauf und fertig.
Ja- und andere Räder. Etwas grösser (der Outdoor-Fähigkeit wegen, so in etwa 1:10er Monstertruck wahrscheinlich) und auch breiter- sieht einfach besser aus. Vielleicht dann noch unnützes wie Schutzbleche oder so, mal gucken. Erstmal musses funktionieren.

[Rabenauge]

Inzwischen ist mir das Display auch vor die Türe gefallen, so eins: http://www.ebay.de/itm/2013-CRIUS-CO-16-OLED-Display-Module-V1-2-for-MWC-MultiWii-Flight-Controller-/281221985327?pt=LH_DefaultDomain_77&hash=item417a22f42f

Bin begeistert ob der Grösse, des Preises und natürlich der Leistungsfähigkeit. Das Ding spricht fliessend I2C, hat wirklich eine gestochen scharfe Anzeige (das Kontrastverhältnis ist jenseits GUT und BÖSE), und schnell isses auch noch. Dazu "masstabsgerecht", die Anzeige selber ist 25x14mm gross, da bringt man noch etliche Zeilen Text unter!

Nachteil: auch das Ding braucht nen bisschen Speicher- der UNO wollts nicht mehr wissen, da ja sowieso etliches an Rechnerei anfällt.. Drum habe ich jetzt den MEGA 2560 eingebaut, der hat genug. Ausserdem löst er mir noch nen paar andere Probleme, die ich beim UNO hätte umschiffen müssen:
Der Ständer wird von nem Servo bedient, aber die Servobibliothek legt auf zwei Pins die PWM lahm, das ist beim MEGA nicht so und:
da ich die RCReceiver-Bibliothek von Wilfried Klaas benutze, kann ich am MEGA problemlos vier RC-Kanäle auswerten.
Mal sehen, was der Spieltrieb damit anfangen wird.

Tom ist jedenfalls begeistert von dem kleinen Digitaltacho...
Ich auch.

[dj_cyborg]

Glück Auf Arzgebirgler,

das sieht ja schon mal Klasse aus. Warte schon gespannt auf ein Video von Toms erster Testfahrt.
Viel Erfolg!

mfG
Mario

[Rabenauge]

So-inzwischen haben sich einige Kleinigkeiten getan, es ist weitere Hardware verbaut worden.
Da das Dispay mir den Bordrechner doch ganz schön ausbremste, hab ich es vorerst deaktiviert und alles noch mal neu geschrieben.
Später wird es wieder aktiviert, aber im Betrieb wohl eher mit statischer Anzeige-kann während der Fahrt sowieso keiner ablesen, bei 3mm Schriftgrösse (wenn überhaupt).
Im Stand ist genug Zeit, da kans dann was vernünftiges malen. :)
Dafür hab ich an der Verkehrssicherheit gearbeitet (ich brauch das, immer wenn ich auf programmieren mal keine Lust hab muss ich schrauben, bohren, löten oder irgendwelche Späne machen ;) ): von nem Modellpanzer lag noch ein Scheinwerfergehäuse rum, da wurde gleich ein hübsches Rücklicht draus. Es fungiert zugleich als Einschaltkontrolle, da es direkt am Akku hängt- beim programmieren wird der TomWay ausschliesslich über USB versorgt, da ist es aus), so sehe ich sofort, wenn ich das Gerät versehentlich scharf geschalten hab- wäre hier auf dem Tisch keine so gute Idee.
Damit Tom später auch im finstern rumfahren kann (er meinte, er würde ja auch mal gross und wenn er dann ne Freundin hat und abends..man brauchts eben), hab ich ihm gestern noch eine dieser billigen Taschenlampen (kam nen wahnsinnigen Euro) besorgt, aus der wird ein Scheinwerfer gebastelt, neun weisse LED`s- das sollte reichen. Passt auch von der Grösse her gut dazu- kaum Arbeit und kost kaum was.
Wie ich das Ding ansteuere weiss ich noch nicht genau, entweder muss ich nen Relais ranfrickeln oder was mit Transistoren basteln. Da könnte ich dann auch gleich ein Tagfahrlicht machen- eine der LED`s immer an, dei anderen nur im dunklen, sowas irgendwie.
Da ich ja momentan kein Display dran habe (dran isses und bleibts natürlich auch, aber es sagt halt nix) hab ich im Armaturenbrett noch ne kleine LED eingebaut, die ich derzeit für gewisse Anzeigen benutze (momentan geht sie an, wenn die Regelung auf Vollgas ist, hilft mir beim einstellen).

Was das balancieren angeht: es geht voran. Rekord bisher war rund ne halbe Minute ohne dass ich oder die nächste Wand eingreifen musste. Gut, aber lang noch nicht gut genug.
Die Regelung braucht mehr Vorhalt- mal sehen ob ich das schaffe.
Momentan warte ich allerdings auf Bauteile: inzwischen sind da doch einige Kabel und Steckerchen in dem Ding, und alles irgendwie locker um den Mega rum verteilt- das hört mir auf.
Ich werd mir ne passende Streifenraster-Platine machen, die sämtliche Anschlüsse plus bisschen Zubehör (z.B. nen Spannungsteiler um den Akku überwachen zu können) enthält- sozusagen ein TomWay-Shield.:)
Dann kann ich auch vernünftige Kabelbäume basteln und es sieht weit aufgeräumter aus in der Kiste.

[Rabenauge]

Sodele. Nicht, dass jemand denkt, ich hätt aufgegeben- ich doch nicht.:cool:

Prinzipiell ist das balancieren inzwischen so gut (gewesen, dazu gleich mehr), dass ich den Roller nahezu unbeaufsichtigt in die Bude stellen kann.
Zugegeben, ein bisschen Platz ist von Nöten, aber ich denke, viel besser wird es mit diesen Getrieben nicht werden. Spielfreiere kosten aber auch gleich heftig was- von daher leb ich damit erstmal. Immerhin isses ein Prototyp.

Nachdem ichs ums verrecken nicht ausreichend schnell hinbekam, drei RC-Kanäle sauber einzulesen, hat sich rausgestellt, dass die RCReceiver-Lib einen Bug hatte. Der ist nun behoben und: `s funktioniert prächtig. 3 Kanäle einlesen braucht ne halbe Millisekunde, so wird das was.
Trotzdem hab ich den Roller erstmal wieder nahezu komplett zerlegt, denn die Hauptplatine (die zum aufstecken auf den Mega mein ich) muss ich doch noch mal neu machen. Durch nen paar Änderungen wurd sie nicht besser und sie war auch nicht soo optimal- die neue wird viiiel besser (hoff ich).

Ausserdem gibts neue Räder: stammen von Absima, und sind Buggyräder für nen 1:8er, mit Strassenprofil.
Dreimal so breit wie die Motorradrädchen, und mehr Durchmesser. Tom findet die Dinger saucool, ich hab _diese_ ausgewählt, weils die billigsten waren, die es im 2er-Pack bei Conrad gab. ;)
Sehen trotzdem durchaus nett aus, also..
Um aber diese Ungetüme ranzubekommen, ist etwas feinmechanische Bastelarbeit nötig: die zu den Rädern gehörenden 17mm-Sechskant-Mitnehmer haben ne 8er Bohrung, die auf meine Getriebeausgänge perfekt passen würde- aber die Getriebewellen schauen nur nen cm aus dem Chassis- die sind viel zu kurz.
Da ich später alles noch zerlegen können will, muss da also ne Hülse drüber, und die mit nem Stift...naja. Kriegen wir schon hin.
Zeitlich passt es gut: die nötigen Teile (Kugellager sollte mir die Postfrau heute zuwerfen) hab ich dann beisammen, und auseinander genommen ist sowieso grade alles. Bastelwetter ist auch-> perfekt.

Da die grösseren Räder logischerweise etwas weniger Drehmoment bringen werden, werd ich anschliessend die Regelung mit neuen Parametern versehen müssen, das ist mir klar- darum oben das "gewesen". Ich denke, es wird sogar besser gehen, denn mit den kleinen Rädern hatte ich recht exotische Werte für Kp und Ki- die deuten drauf hin, dass die Antriebe entschieden zu stark waren. Das dürfte sich durch grössere Räder ein bisschen relativieren.
Insbesondere den P-Anteil des PID-Reglers musste ich sehr niedrig einstellen, damit nicht gleich alles flattert.

Achja: ich brauch eine einfache Schaltung (mir schwebt da irgendwie nen Transistor und ein, zwei Widerstände vor, mehr nicht), mit der ich den Hauptscheinwerfer schalten kann. Und zwar so, dass ich mit nem Arduino-Digitalpin (dimmen ist unnötig) 5V rausschicke und damit dann 7,2V vom Akku zu den LED`s schalte- ich will die insgesamt neun LED`s nicht über den Ardunio-Spannungswandler laufen lassen.
Sollte doch möglich sein, oder?
Ist, zugegebenermassen, nicht meine Stärke, sowas...jemand nen Tipp?

[RoboHolIC]

Zu den LEDs:

Für den Hauptscheinwerfer sind es vermutlich weisse LEDs, Flussspannung vermutlich nicht unter 3V. Akkus gehen von etwa 8,4V runter bis 6V (etwa 1V je Zelle), d.h. es werden nichtmal zwei LEDs in Reihe betreibbar sein. Dann wären das 9x20mA=180mA. Mit einem TO92-NPN- oder MOSFET direkt gegen Masse schalten, das wäre das einfachste. Leicht ausführbar, leicht verständlich.

Die zwischen etwa 8,4V und 6V schwankende Akkuspannung bewirkt an den Vorwiderständen aber einen Spannungsabfall zwischen 3V (eher noch etwas weniger) und 5V. In dem selben Verhältnis schwankt auch der LED-Strom und damit die Helligkeit. Wenn das toleriert wird, dann ist gut.

Ansonsten ein Low-Drop-Regler für 4,5-5V und angepasste Vorwiderstände.
Wenn etwas Ladungsmenge gespart werden soll, wäre ein Stepdown mit derselben Ausgangsspannung oder sogar ein Hochsetzsteller, damit man über den Maximalwirkungsgrad der erstgenannten Lösung von etwa 50% hinauskommt.

[Rabenauge]

Ja, danke. *kopfkratz

So kompliziert machen wir das bitte nicht: im Grunde isses mir Wurst, wie hell die Lampe wirklich leuchtet, die ist fürs System genauso unnötig wie die Hupe.

Aber richtig: es sind weisse LED`s. Ich hab dafür eine dieser 1€-Plastiktaschenlampen geschlachtet, die hat 9 Stück von drin. Verkabelt sind die nun in zwei Gruppen (um sowas wie Tagfahrlicht bzw. Fern-und Abblendlicht zaubern zu können- einfach nur weil ich genug freie Puins für solche Spielereien hab)..
Die LED`s sind immer parallel geschalten, also 1:3 und 1:6.
Und: eigentlich isses egal ob die nun mit voller Helligkeit leuchten oder nicht- aus Erfahrung weiss ich, dass man RC-Modelle selbst mit wirklich guten, anmontierten Scheinwerfern im Dunklen eh nicht fahren kann- das funktioniert nur im Nahbereich, also echt nicht wichtig.

Nun der Rest: der Bordrechner ist ein Arduino Mega 2560. Der hat einen eingebauten Spannungsregler, der aber nicht allzu viel kann.
Dort kommen (über Vin) die 7.2V Nennspannung (es sind 6 NC-Zellen) rein, somit hat das Board stabile 5V.
Die kommen auch an den digitalen Pins heraus, wenn ich die auf High setze aber: würd ich dort direkt die LED-Gruppen anschliessen, denke ich, den eingebauten Spannungsregler zu überfordern, der versorgt schon den Mega, das Oled-Display und den Sensor.
JA: im Grunde könnte ich einfach einen der beliebten, billigen Spannungsregler einbauen, die es beim freundlichen Chinamann für 1.50 gibt aber erstens: es ist erstaunlich wenig Platz in dem Ding inzwischen, zweitens will ich aus naheliegenden Gründen den Mega _nicht_ mit 5V füttern (dann müsste ich ihm jedes Mal den Akku kappen zum programmieren) und alleine für nen paar LED`s halt ich so nen Regler für etwas übertrieben.
Daher mein Plan: die 5V aus den digitalen Pins einfach in nen Transistor schicken (mit Basiswiderstand, ist klar), und der soll mir dann bitteschön die LED`s direkt gegen den Akku schalten. Die LED`s bekämen natürlich passende Vorwiderstände, und gut wärs.
Der Stromverbrauch der Sache ist allerdinge relativ uninteressant- bisher hat der Akku durchaus mehrere Stunden durchgehalten, und wenn es nun (die grossen Räder sind inzwischen dran, die werden etwas mehr brauchen) eben effektiv ne halbe Stunde Fahrzeit gibt- ist das auch genug. Falls nicht, kann ich den NC-Pack (es ist nen ganz normaler Racingpack) immer noch proglemlos gegen einen LiPo tauschen.

Gefallen würde mir die Schaltung mit dem npn: http://c-kolb.bplaced.net/projekte/elektronik/grundlagen/transistor/transistor_npn_pnp.php
Die köntne ich nämlich auch ganz einfach auf meiner Hauptplatine gleich mit aufbauen.
Isses wirklich so einfach?

[RoboHolIC]

Gefallen würde mir die Schaltung mit dem npn: http://c-kolb.bplaced.net/projekte/elektronik/grundlagen/transistor/transistor_npn_pnp.php
Die köntne ich nämlich auch ganz einfach auf meiner Hauptplatine gleich mit aufbauen.
Isses wirklich so einfach?
Ja, ist es.
Die Abwägungen hast du ja gemacht. Und wenn du sogar die LED-Ströme noch 2/3 zu 1/3 aufteilst, dann kommt es auch mit der Stromtragfähigkeit der im Link genannten TO92-Transistoren ganz locker hin, die empfohlenen Typen sind OK. Ströme/Vorwiderstände aber bitte auf die maximale Spannung frisch geladener Akkupacks auslegen und auf die Verlustleistung der Widerstände achten.

[Rabenauge]

Na fein.
Gestern hab ich die Adapter für die Monsterräder fertig bekommen, dann gehts ja voran....
Tom würd gerne seinen diesjährigen Osterspaziergang motorisiert unternehmen, mal sehen, obs für erste Ausflüge noch reicht.
In ein, zwei Tagen hab ich die neue Platine fertig, denke ich, dann kann ich weiter an der Software arbeiten.

[Rabenauge]

Hat funktioniert.
Ich kann nun die beiden Lichter (sind in einer Lampe, aber eben doch zweie) einzeln per software schalten- super.
Die Platine ist, bis auf den Servoanschluss, nun fertig und: alles läuft.
Die reparierte RCReceiver-Lib arbeitet nun wunschgemäss ohne mir irgendeine nötige PWM zu blockieren, und ist so schnell dass mans praktisch gar nicht merkt.
Tom ist bereits wieder auf seinem Roller und hat schon ne gute Stunde weg- die Regelung musste ja, wegen den grösseren Rädern, neu justiert werden. Geht, wie ich finde, feinfühliger als vorher- wahrscheinlich war das Drehmoment der Getriebe für die kleinen Räder doch etwas zu üppig.
Nun werd ich mal wieder bisschen an der Software rumbasteln...

[Rabenauge]

Sodele. Es fährt nun. Und zwar gesteuert.
Lenken hab ich noch nicht hinbekommen (habs auch noch gar nicht allzu intensiv probiert, morgen ist ja auch noch ein Tag), aber vorwärts und rückwärts funktionieren schon.
Sogar erstaunlich gut: ich verschiebe lediglich den Setpiont der Balanceregelung per Fernsteuerung etwas (natürlich proportional zur Knüppelstellung), und da die Fuhre dann automatisch aus dem Gleichgewicht kommt, fährt sie los. Das steuern funktioniert genau wie beim richtigen Segway: lehnt man "sich" (den Steuerknüppel halt) mehr oder weniger nach vorn, wird entsprechend gefahren. Nach hinten auch- so kann man sogar richtig gut bremsen.
Macht so richtig Spass- nur übertreiben darf mans nicht, weil die Regelung nur ca. innerhalb 7-8 Grad sicher arbeitet, im Moment. Wird es zu doll, musss mans entweder nen stückweit manuell aussteuern (auch das tut man ja beim Original automatisch), oder es macht *bautz.

[Rabenauge]

Hm, ganz so einfach isses dann doch nicht- es gab ein paar (momentan kleinere..) Rückschläge.

-während mit den Kleinen Rädern keinerlei ernsthafte Probleme bereiteten, tuns die grossen dann doch: die brauchen mehr Drehmoment, das war klar. Der Haken dabei: die Getriebe könnens liefern, aber sie werden weich dabei. Ein Zahnrad rutschte bereits etwas auf der Abtriebswelle durch. Hab es erstmal verklebt und hoffe, das reicht, aber gegebenenfalls muss ich auf stabilere Getriebe umrüsten- die gibts auch in Vollmetall-Ausführung.

- der Stromverbrauch ist deutlich gestiegen. Habs zwar nicht gemessen, aber während ich mit den kleinen Rädern nen paar Bastelnachmittage am Stück rumspielen konnte, muss ich den Akku nun jeden zweiten Tag laden- geschätzte Betriebszeit aber immer noch deutlich jenseits ner halben Stunde, also ausreichend.

- die Regelung treibt mich noch in den Wahnsinn.
Aus unerfindlichen Gründen muss ich extrem hohe I-Werte benutzen, während P sehr niedrig sein muss.
Den I-Anteil kapier ich einfach nicht- je höher er ist, umso schneller wird ausgesteuert.
Widersinnig...?

[Rabenauge]

Keiner ne Meinung zu dem Regelungs-Problem?
Na gut.
Werd mich da schon durchwursteln, da gibts ein paar halbe Ideen zu.

Inzwischen bin ich so weit, dass ich den Roller per Fernsteuerung einigermassen gezielt fahren kann: Fahrsteuerung vor-und rückwärts und auch ne rudimentäre Lenkung sind bereits programmiert.
Rudimentär deshalb, weil lediglich das kurvenäussere Rad beschleunigt wird. Während der Fahrt reicht das im Grunde aus, aber ich mach das natürlich noch ordentlich.
Ausserdem kann er, mit dieser Lösung, im Stand praktisch kaum drehen: zwar funktioniert es auch dann, aber durch Korrekturen der Balanceregelung dreht er natürlich sofort zurück. Da kommt ne andere Strategie.
Aber: ich habs geschafft, in meiner engen Bastelbude hier gestern ne 8 zu fahren- unfallfrei. ;)
Heute will ich mal auf den Wäscheboden, da ist mehr Platz. Die Keycam kommt mit, ich hoffe, die kriegt da was brauchbares hin.

Inzwischen nen paar aktuelle Fotos von vor ner Stunde:

[Rabenauge]

Das Video ist grauenhaft- obwohl noch genug Licht auf dem Wäscheboden war, meinte die Keycam wohl es sei keines- aber man erkennt doch: die Kiste fährt.
http://youtu.be/blV54p4a2oU

Wie man sieht, ist aber noch jede Menge zu tun.
Die Stürze rührten ausnahmslos daher, dass ich kluges Köpfchen die Regelung begrenzt hatte (wollt damit im niedrigen Bereich eine bessere Auflösung erreichen)- und somit ab einer gewissen Fahrgeschwindigkeit die Regelung also nicht mehr arbeiten kann.
Das muss geändert werden.
Ausserdem müssen die beiden Sätze Regelparameter, mit denen ich momentan arbeite (bei geringer Neigung wird mit johem Ki, und niedrigem KP gearbeitet, bei grösseren Abweichungen ist Ki niedriger, aber Kp höher, das soll ein überreagieren verhindern und tuts auch noch besser aufeinander abgestimmt werden.
Dadurch, dass ich wieder an der Regelung rumgespielt habe, ist auch die RC-Kontrolle nicht soo gut, wie sie sein könnte.

Also: noch ne Menge Arbeit...

[dj_cyborg]

Hallo Rabenauge,

danke fürs Video, den Fahrgeräuschen zu Urteilen schwingt wohl Toms Fahrzeug noch etwas um den Sollwert. Ich würde dir gerne helfen nur bekomme ich meinen Legoprototyp nicht mal sauber zum stehen. Mich würde mal ein code schnipsel für deine PID-Regelung und den Filter der Gyro und Accel-Werte interessieren, evtl. kann dir dann auch ein Experte einen Tipp geben. Hast du jetzt was zur Drehzahlmessung angebracht?

mfG
Mario

[Rabenauge]

Als Filter benutze ich die Kalman-Bibliothek für Arduino.
https://github.com/TKJElectronics/Example-Sketch-for-IMU-including-Kalman-filter

Die liefert aus dem 6DoF gleich schön die absoluten Winkelgrade, bezogen auf die Senkrechte.
Auch der PID-Regler ist ne fertige Bibliothek: http://playground.arduino.cc/Code/PIDLibrary

Momentan arbeite ich da mit einer Samplezeit von 50ms- die wäre weiter runter zu setzen, bringt aber dann nicht mehr wirklich ne Verbesserung.
Hatte sie auch schon auf 10ms...
Ich denke, wenn man die Zeit zu weit runtersetzt, kann der Regler nicht mehr viel tun, da er ja ständig neu kalkuliert wird.

Übrigens: ich hab auch den ersten Prototyp mit Lego gebaut: zwei Motoren vom RCX-Set, Arduino, Motorshield und den Sensor, den ich jetzt auch benutze. Dazu nen 7.2V Racingpack (in dem LEGO-Ding reicht der zwei Wochen..).
Funktionierte ganz gut, um die PID-Parameter einzustellen, war noch ein LCD-Display dran und nen Satz Potis, mit denen ich Kp, Ki und Kd mal direkt einstellen konnte.
Wichtig bei dem Ding war alledings die richtige Übersetzung. Zu lang, reicht die Kraft nicht (bzw. dann war der Antrieb nicht kräftig genug um schnellstens auszuregeln). Immerhin laufen die LEGO-Motoren eigentlich ja mit 9V.
Und: es ist mit niedrigem Schwerpunkt schwieriger! Hatte das Ding dann mal auf Hochkant-Form umgebaut, da wird die ganze Regelung deutlich toleranter.

Eine Drehzahl-oder Wegmessung gibts nicht, dafür ist gar keine Sensorik vorhanden-ich könnt also maximal die Fahrwege aufaddieren, was nicht allzu genau würde. Allenfalls könnte man aus dem Beschleunigungssensor noch Bewegungsdaten rausfischen.
Wenn sich rausstellen sollte, dass es ohne wirklich nicht geht, dann muss ich halt irgendwelche Geber nachrüsten, z.B. Lichtschranken an die Getriebe oder Räder.
Ich denke aber immer noch, das ist nicht nötig.

Und ja: im Video pendelt er mehr als schön wäre- aber ich kriegs nicht wirklich gut hin (besser hatte ichs allerdings schon), wenn ich die Regelung so einstelle, dass er ruhiger steht, wird sie bei Störungen zu aggressiv.
Das hatte ich vorher: kleine Störungen fing er schön ab, und auch ziemlich schnell, aber wehe es gab ne grössere, dann übersteuerte er sofort dermassen, dass er sich nicht mehr abfangen konnte.
Ich hatte nämlich vorher schon versucht, nen Video da zu machen: auf dem ziemlich rutschigen Bodenbelag (irgendwas, Lineoleum oder so nen Zeugs) ging es zu wie auf Schmierseife- ging gar nicht.
Die Reifen taugen für _den_ Untergrund auch nicht so wirklich, zum einen sind sie recht hart (da "federn" eher die Felgen mit als die Reifen), und zum anderen- naja, es waren die billigsten Räder in der Grösse, die es paarweise gab beim Conrad.
Die Motorradreifen waren um Welten weicher. Aber mir halt zu klein-ich find die "Monsterräder" toll an dem Ding.

Momentan weiss ich nicht genau, woher die Pendelei wirklich rührt, das muss ich erst noch erforschen: dadurch, dass ich an der Regelung noch einiges geändert hatte, ists gut möglich, dass die umgerechneten RC-Signale nun grad nicht wirklich passen (das ist etwas umständlich, da die eingelesenen RC-Steuerungswerte passend skaliert werden), Fakt ist: die RC-Steuerung in dem Video hat in Wirklichkeit lausig funktioniert. Bei den Tests nen Tag vorher, ging das viel besser. Man muss halt genau den Bereich finden, in dem man den virtuellen Schwerpunkt recht sorglos nach vorn oder hinten schieben kann.

Ich geb auch zu: gestern hab ich nix mehr an der Software gemacht, hatte keine Lust. Mir war eher nach mechanischen Basteln, und nun hat das Ding auch noch nen Tankverschluss (da kommt die Ladebuchse dahinter), die Hupe hat ne verchromte Verkleidung und einige Gewinde der Abdeckungen, die vorher einfach M3-in-Sperrholz-leimgehärtet waren, sind nun mit Messing-Gewindeeinsätzen versehn.
Und die von aussen zugängliche USB-Buchse hat auch ne Abdeckung bekommen, da sie direkt hinter dem linken Rad sitzt- für draussen wäre das sonst nix.
Ab und zu muss ich einfach "greifbare" Dinge bauen...

- - - Aktualisiert - - -

Grade hat mir jemand vorgeschlagen, es mal mit zwei PID-Reglern zu versuchen.
Einen für kleinere Störungen, und nen zweiten, um schlimmere Fälle auszuregeln.

Im Prinzip tu ich das bereits, alleerdings läuft es auf dem selben Regler, es werden nur die Parameter Kp, Ki und Kd geändert:


float reglerP = 2.1;
float reglerI = 220.1;
float reglerD = 0.10;
float reglerAggP = 15.0;
float reglerAggI= 100.0;//90
float reglerAggD= 0.2;//0.4

Verwurstet wird das dann so:


double abw = abs(sollWert+genullterWinkel);
if (abw<4)
{
radAchse.SetTunings(reglerP,reglerI,reglerD);
digitalWrite(ledGelb,LOW);
}
else
{
radAchse.SetTunings(reglerAggP,reglerAggI,reglerAg gD);
digitalWrite(ledGelb,HIGH);
}

Aktuell werden bei Abweichungen von vier Grad andere Parameter benutzt, die allerdings eher beruhigend wirken:

Ki ist sehr hoch (setz ichs runter, dauert es ewig, ehe das Fahrzeug ausbalanciert ist), bei grösseren Abweichungen führt das allerdings zu extremem Übersteuern. Wirklich extrem, dann kann man das Ding selbst mit der Hand kaum noch festhalten.
Deshalb ist AggI deutlich kleiner, dafür aber AggP (irgendwoher muss schliesslich die kraftvolle Ausregelung kommen) dann höher.

Durch die "aggressiven" Parameter wird dieses starke Übersteuern weitgehend unterdrückt, und die Regelung fängt sich binnen zwei, drei Pendelbewegungen wieder. Dank dann höherem P-Anteil funtioniert das auch ziemlich sicher.

Vermutlich liegt in der Gegend des Codes auch noch der Hase im Pfeffer: das ist einfach noch nicht alles optimal aufeinander abgestimmt.
Richtig schön wären Rampen, die die Werte gleitend ineinander übergehen lassen. Mal sehn, ob ich das versuche.

[RoboHolIC]

Hallo, Rabenauge.

Zum einen fällt mir auf, dass du zwar von einem PID-Regler sprichst, aber nie den D-Anteil diskutierst, der üblicherweise die schnelle energische Gegensteuerung gegen Soll-Ist-Differenzen ausmacht (Prinzip: "Wehret den Anfängen"). Vielleicht ist das aber bei dem Segway auch ganz anders - ich habe bisher buchstäblich keinerlei eigene praktische Erfahrungen mit Regelungen.

Zum anderen habe ich schon gestern ein wenig im Netz gesucht und eine Studienarbeit zum Inverspendel - so der wissenschaftliche Oberbegriff von Segways & Co. - gefunden: http://www.heuler.net/stud/pendel/html_program/node3.html . Da stehen Begriffe wie "nichtlineare Regelungstechnik", "Fuzzy-Controller" und "neuronaler Regler" drin, bloss kein PID-Regler. Das Inverspendel ist ja in sich instabil und erfordert stets ein Überkorrigieren, wenn die Fahrgeschwindigkeit nicht immer höher werden darf. Vielleicht ist das die Aufgabe für den D-Anteil?

Ich wollte das gestern noch nicht posten, um nicht nach Klugs....... zu klingen. Vielleicht liegt dort aber die Erklärung für deine Probleme. Gut möglich, dass der Segway mit PID-Regler nur in bestimmten technischen Konstellationen leidlich funktioniert, aber sehr empfindlich auf Änderungen an Systemkomponenten reagiert.

Einen Nicht-Umfaller haben ja schon einige hier erfolgreich gebaut; die Balancierer sind dann doch eher seltener. Ich wäre ja mit einem eigenen Nicht-Umfaller schon recht zufrieden.

Wie sieht's eigentlich mit der Massenverteilung bzw. Schwerpunkt bei deinem Segway aus? Auf einem 1,5t-Pkw wird man keinen Bleistift balancieren können; ein Stielbesen dagegen ist vergleichsweise leicht auf der Hand zu halten. Das Balancieren geht umso leichter, je dynamischer der Aktuator und je höher der Schwerpunkt des Pendels ist.

[dj_cyborg]

Hallo,

ich habe mir Gestern diese Excel-Simulation hier (http://www.youtube.com/watch?v=dPkFMeiUni4) nach gebaut um mal zu sehen welcher Wert welche Auswirkungen hat. Ich fand`s ganz hilfreich um das ganze besser zu verstehen. Damit lässt sich auch das von RoboHolIC angesprochene "Überkorrigieren" gut darstellen.

Ich glaube bei mir liegt es zur Zeit am zu großen Spiel in den LEGO-Zahnrädern, die Drehrichtungsänderung ist einfach zu "ruppig".

Bei mir ist das aber auch so, dass das Verhalten besser wird wenn P=kleiner ist, I=größer, und D=0.

Anbei mein Arbeitsstand.


'************************************************* ******************************
'************************************************* ******************************
'**************************** BALANCE BOT V1.0 *********************************
'************************************************* ******************************
'************************** 18.03.2014 by CYBORG *******************************
'************************************************* ******************************
'************************************************* ******************************

'****************************** Allgemein **************************************

$regfile = "m88adef.dat"
$crystal = 8000000
$hwstack = 48
$swstack = 48
$framesize = 48
$baud = 500000

'**************************** MPU-6050 GYRO ************************************

Config Scl = Portc.5 'Configure i2c SCL
Config Sda = Portc.4 'Configure i2c SDA

Declare Sub Mpu6050_write(byval Regadr As Byte , Byval Wert As Byte)
Declare Function Mpu6050_read(byval Regadr As Byte) As Byte
Declare Function Mpu6050_temp() As Single
Declare Function Mpu6050_accel(byval Mpu6050_const_h As Byte , Byval Mpu6050_const_l As Byte) As Single
Declare Function Mpu6050_gyro(byval Mpu6050_const_h As Byte , Byval Mpu6050_const_l As Byte) As Single

Dim Mpu6050_h As Byte
Dim Mpu6050_l As Byte
Dim Mpu6050_int As Integer
Dim Mpu6050_real As Single

Dim Mpu6050_chip As Byte
Dim Mpu6050_in As Byte
Dim Mpu6050_tmp(6) As Byte

Const Mpu6050_adr = &HD0 '&H68 ist 7-Bit-I2C-Adresse
Const Mpu6050_adr1 = &HD1
Const Mpu6050_who_am_i = &H75
Const Mpu6050_pwr_mgmt_1 = &H6B

Const Mpu6050_temp_h = &H41
Const Mpu6050_temp_l = &H42

Const Mpu6050_accx_h = &H3B
Const Mpu6050_accx_l = &H3C
Const Mpu6050_accy_h = &H3D
Const Mpu6050_accy_l = &H3E
Const Mpu6050_accz_h = &H3F
Const Mpu6050_accz_l = &H40

Const Mpu6050_gyrox_h = &H43
Const Mpu6050_gyrox_l = &H44
Const Mpu6050_gyroy_h = &H45
Const Mpu6050_gyroy_l = &H46
Const Mpu6050_gyroz_h = &H47
Const Mpu6050_gyroz_l = &H48

Dim Mpu6050_stemp As Single
Dim Mpu6050_accx As Single
Dim Mpu6050_accy As Single
Dim Mpu6050_accz As Single
Dim Mpu6050_gyrox As Single
Dim Mpu6050_gyroy As Single
Dim Mpu6050_gyroz As Single

'****************************** MOTOR - PWM ************************************
Config Timer1 = Pwm , Pwm = 10 , Compare_a_pwm = Clear_up , Compare_b_pwm = Clear_up , Prescale = 64

Motor_a_front Alias Portb.0 'Motor1 vorwärts
Motor_a_back Alias Portd.7 'Motor1 rückwärts
Motor_b_front Alias Portd.6 'Motor2 vorwärts
Motor_b_back Alias Portd.5 'Motor2 rückwärts


Config Motor_a_front = Output
Config Motor_a_back = Output
Config Motor_b_front = Output
Config Motor_b_back = Output


Motor_a_front = 0
Motor_a_back = 0
Motor_b_front = 0
Motor_b_back = 0

Wait 1

Dim Pwm_middle As Single
Dim Pwm_start As Single
Dim Pwm_limit As Integer

Dim Accel_middle As Single
Dim Accel_step As Single
Dim Accel_filter As Single
Dim Accel_revfilter As Single

Dim Gyro_middle As Single
Dim Gyro_step As Single
Dim Gyro_filter As Single
Dim Gyro_revfilter As Single

Dim Main_middle As Single


Pwm_middle = 0
Pwm_start = 0 '220
Pwm_limit = 1023

Accel_step = 200 '200
Accel_filter = 10 '10
Accel_revfilter = Accel_filter - 1

Gyro_step = 20 '20
Gyro_filter = 60 '60
Gyro_revfilter = Gyro_filter - 1

'****************************** PID - REGLER ***********************************
Declare Function Pid(byval Pid_ist As Single) As Single
Const P = 0.15
Const I = 0.7
Const D = 0.0


Dim Pid_soll As Single
Dim Pid_error(3) As Single
Dim Pid_ist As Single


Pid_soll = Pwm_middle

'****************************** Hauptprogramm **********************************

Mpu6050_chip = Mpu6050_read(mpu6050_who_am_i) 'Wer ist es?
If Mpu6050_chip = &H68 Then
Print " mpu6050 gefunden... "
End If

Call Mpu6050_write(mpu6050_pwr_mgmt_1 , 0) 'aus dem sleep-modus holen
Dim S As Single
Print " Neustart... "
Wait 1


Dim Z As Integer

Do

'ACCEL FILTER
Accel_middle = Accel_middle * Accel_revfilter
Mpu6050_accx = Mpu6050_accel(mpu6050_accx_h , Mpu6050_accx_l)
Mpu6050_accx = Mpu6050_accx * Accel_step
Accel_middle = Accel_middle + Mpu6050_accx
Accel_middle = Accel_middle / Accel_filter

'GYRO FILTER
Gyro_middle = Gyro_middle * Gyro_revfilter
Mpu6050_gyroy = Mpu6050_gyro(mpu6050_gyroy_h , Mpu6050_gyroy_l)
Mpu6050_gyroy = Mpu6050_gyroy * Gyro_step
Gyro_middle = Gyro_middle + Mpu6050_gyroy
Gyro_middle = Gyro_middle / Gyro_filter

'ACCEL + GYRO
Main_middle = Accel_middle - Gyro_middle

'PID
'Print "Ist " ; Main_middle ; " Soll " ; PID_ist
Main_middle = Pid(main_middle)

'PWM ermitteln
Z = Abs(main_middle)
Z = Z + Pwm_start

If Z > Pwm_limit Then
Z = 0
End If

'Drehrichtung festlegen
If Main_middle < Pwm_middle Then

Motor_a_front = 1
Motor_a_back = 0
Motor_b_front = 1
Motor_b_back = 0

Pwm1a = Z
Pwm1b = Z


Elseif Main_middle > Pwm_middle Then

Motor_a_front = 0
Motor_a_back = 1
Motor_b_front = 0
Motor_b_back = 1

Pwm1a = Z
Pwm1b = Z

End If


Loop

'**************************** MPU-6050 Functions *******************************
'****************************** MPU-6050 WRITE *********************************
Sub Mpu6050_write(regadr As Byte , Byval Wert As Byte)
I2cstart
I2cwbyte Mpu6050_adr
If Err = 0 Then
I2cwbyte Regadr
I2cwbyte Wert
End If
I2cstop
End Sub

'****************************** MPU-6050 READ **********************************
Function Mpu6050_read(regadr As Byte) As Byte
Mpu6050_in = 0
I2cstart
I2cwbyte Mpu6050_adr
If Err = 0 Then 'ACK empfangen
I2cwbyte Regadr
I2cstart
I2cwbyte Mpu6050_adr1
I2crbyte Mpu6050_in , Nack
End If
I2cstop
Mpu6050_read = Mpu6050_in
End Function

'****************************** MPU-6050 TEMP **********************************
Function Mpu6050_temp() As Single
Mpu6050_h = Mpu6050_read(mpu6050_temp_h)
Mpu6050_l = Mpu6050_read(mpu6050_temp_l)
Mpu6050_int = 256 * Mpu6050_h
Mpu6050_int = Mpu6050_int + Mpu6050_l
Mpu6050_real = Mpu6050_int * 0.294117647058823529411764705882 'vgl. S. 31 von RM_MPU-6000A.pdf
Mpu6050_real = Round(mpu6050_real)
Mpu6050_real = Mpu6050_real * 0.01
Mpu6050_real = Mpu6050_real + 36.53
Mpu6050_temp = Mpu6050_real
End Function

'***************************** MPU-6050 ACCEL **********************************
Function Mpu6050_accel(mpu6050_const_h As Byte , Mpu6050_const_l As Byte) As Single
Mpu6050_h = Mpu6050_read(mpu6050_const_h)
Mpu6050_l = Mpu6050_read(mpu6050_const_l)
Mpu6050_int = 256 * Mpu6050_h
Mpu6050_int = Mpu6050_int + Mpu6050_l

'1 g entspricht 2^14 = 16384 bei Standard-Range 2g; also Beschl = accel_x_int*9.81/16384

Mpu6050_accel = Mpu6050_int * 0.00059875

End Function

'***************************** MPU-6050 GYRO ***********************************
Function Mpu6050_gyro(mpu6050_const_h As Byte , Mpu6050_const_l As Byte) As Single
Mpu6050_h = Mpu6050_read(mpu6050_const_h)
Mpu6050_l = Mpu6050_read(mpu6050_const_l)
Mpu6050_int = 256 * Mpu6050_h
Mpu6050_int = Mpu6050_int + Mpu6050_l

'1 g entspricht 2^14 = 16384 bei Standard-Range 2g; also Beschl = accel_x_int*9.81/16384

Mpu6050_gyro = Mpu6050_int * 0.00763358778625954198473282442748

End Function

'***************************** MPU-6050 READ ***********************************
Read_gyro:

I2cstart
I2cwbyte Mpu6050_adr
I2cwbyte Mpu6050_gyrox_h
I2crepstart
I2cwbyte Mpu6050_adr1

I2crbyte Mpu6050_tmp(1) , Ack
I2crbyte Mpu6050_tmp(2) , Ack

I2crbyte Mpu6050_tmp(3) , Ack
I2crbyte Mpu6050_tmp(4) , Ack

I2crbyte Mpu6050_tmp(5) , Ack
I2crbyte Mpu6050_tmp(6) , Nack

I2cstop

Return


'******************************* PID Functions *********************************
'******************************** PID -Regler **********************************
Function Pid(pid_ist As Single ) As Single

Local P_temp As Single
Local I_temp As Single
Local D_temp As Single



'P-Anteil
P_temp = P * Pid_error(3)
P_temp = P_temp + Pid_ist

'I-Anteil
I_temp = Pid_error(3) - Pid_error(2)
I_temp = I_temp * I

'D-Anteil
D_temp = Pid_error(3) + Pid_error(2)
D_temp = D_temp + Pid_error(1)
D_temp = D_temp * D

'PID-Errors
Pid_error(1) = Pid_error(2)
Pid_error(2) = Pid_error(3)
Pid_error(3) = Pid_soll - Pid_ist
'Print "Err1" ; PID_error(1) ; " Err2 " ; PID_error(2) ; " Err3 " ; PID_error(3)


'PID-Anteil
Pid = P_temp + I_temp
Pid = Pid + D_temp
'Print "PID " ; PID ; " IST " ; PID_ist

End Function

mfG
Mario

[Rabenauge]

@RoboHolIC: Mein Segway ist stabil.
Das Ding kann auf sagen wir nem knappen Meter, stehen, bis der Akku leer ist.
In der Zeit fällt er kein einziges Mal um.
Woran ich arbeite ist das Gewackele- das will ich weg haben und denke auch, das geht noch-zumindest beinahe.
Die Stürze im Video kamen ausnahmslos daher, dass ich zu schnell gefahren bin (ich schrieb es schon: die Regelung war auf, glaub ich nen PWM-Wert von 180 begrenzt)- wenn man dieses Tempo erreicht hat, kann die Regelung einfach nicht mehr ausgleichen, wenn da keine Reserven sind.

Auch stürzt er, genau wie die Originale, immer dann zuverlässig, wenn er gegen ne zu hohe Kante gerät.
Dagegen gibts praktisch kein Mittel: wenn der Schwerpunkt einmal vor der Achse ist, und nicht mehr nach vorn gefahren werden kann, ists aus.

Aber: beispielsweise frontal (auch rückwärts) gegen ne Wand fahren kann er noch abfangen!
Im Video sieht man das mit dem Klammerkörbchen: macht ihm absolut nix aus. Später (das war leider nicht im Bereich der Kamera) ist er auch noch gegen ne Wand gefahren. Ohne Sturz.

Den D-Anteil erwähnte ich wenig, das stimmt denn: der ist abartig klein. Ja: der kann um die Mitellage herum dämpfend wirken, aber ich hab momenten nen Kp-Wert von 2.1- da ist schon Kd >0.3 tödlich.
Ich habs mal versucht, meine Überlegung war: Kp und Kd höher, müsste in etwa was ähnliches bewirken wie der sehr hohe Ki-Wert.
Ne, das klappt nicht, ausser heftigem Übersteuern kam da nix raus.
Die Ursache ist mir inzwischen halbwegs klar: das Ding kippt nicht _schnell_. Der Schwerpunkt liegt nen Stück über den Rädern, er kippt also recht "gemächlich"- und damit ist Kd praktisch nutzlos, da der D-Anteil nur auf schnelle Änderungen heftig reagiert.
Und fürs dämpfen um die Mittellage herum bringt es auch kaum was, das hab ich mehrmals hoffnungsvoll versucht.

Das von dir erwähnte Überkorrigieren ergibt sich eigentlich von alleine. Fahrkommandos werden so gegeben, dass der Schwerpunkt verschoben wird. Beim richtigen lehnt man sich nach vorne, damit gerät das Ding aus dem Gleichgewicht und _muss_ losfahren. Dabei stellt sich aber von selber wieder ein stabiler Zustand ein, da die Regelung auch dann arbeitet.
Da mein Tom das nach vorne lehnen nicht drauf hat, mache ichs andersherum: ich verschiebe den Sollwert (den virtuellen Schwerpunkt, sozusagen) etwas nach hinten- der Effekt ist der selbe: der "Soll-Schwerpunkt" ist hinter dem tatsächlichen, das _kann_ die Regelung nur dann ausgleichen, wenn das Ding vorwärts fährt.
Da der verschobene Schwerpunkt sich nun nicht weiter ändert, erhöht sich auch die Geschwindigkeit nicht weiter- die Regelung arbeitet ja dagegen!
Das ist wirklich so einfach, wie es klingt.

Ich hatte schon "bessere" Parameter als im Video, damit war das fahren die helle Freude: schön proportional die Geschwindigkeit erhöhen, verlangsamen- gabs kein Fahrkommando mehr, rollte er gemächlich aus, und bremsen war genauso einfach: etwas "fahrt rückwärts" und das Ding stand auf dem Punkt (naja, fast).
Leider hatten diese Regelparameter aber unschöne Nebenwirkungen: bei grösseren Störungen schaukelte sich alles extrem auf...
Das hab ich momentan in Griff, indem ich bei grösseren Abweichungen andere Parameter benutze. Aktuell ist der Übergang dazwischen noch das problematischste...bin aber ja noch lang nicht fertig.
Ausserdem habe ich noch gar keine Strategie (bzw. nix dazu in der Software) um einen Überlauf zu verhindern: das Teil _muss_ von selber bremsen, bevor die Gasregler am Ende sind-damit dort noch ne Reserve fürs balancieren bleibt.
Praktisch werd ich das _erstmal_ so lösen, dass ich einfach die steuerbare Geschwindigkeit begrenze, ist nicht der optimale Weg, aber nen einfacher.
Momentan kann man im Prinzip endlos lange "Vollgas" fahren-aber dann nicht mehr anhalten, weil dazu die Regelung in Vorhalt gehen müsste. Und das kann sie nicht mehr, wenn die PWM-Werte schon auf max. sind.

@Mario: Excel und ich- das ist nen sehr unheilige Mischung. Habs mir zwar angesehn aber da waren lauter böhmische Dörfer...;)
Sorry, da hab ich echt keine Ahnung von.

Das Getriebespiel ist übrigens so tragisch nicht: mein TomWay hat auch ordentlich welches. So 3-4 Grad kann man die Räder drehen ohne dass sich die Motoren auch nur rühren. Beim LegoWay wars eher weniger- ich hatte da nur einstufige Getriebe benutzt.
Die NXT-Motoren kenn ich nicht wirklich, aber die vom RCX kommen mit ner mittleren Untersetzung schon mit so ner Fuhre gut zurecht- anfangs hatte ich die grossen Räder direkt auf die Motoren gesteckt, das ging auch, frass aber ganz schön Strom und gelegentlich fehlte dann doch etwas Kraft.

Von deinem Programm versteh ich auch nur die Hälfte (bin halt nen fauler Arduino-Programmierer geworden *zugeb), aber: mit welcher Frequenz steuierst du die Motoren an?
Ich hatte bis vor kurzem die normale Arduino PWM benutzt, die läuft nur so mit ca. 500Hz- hab inzwischen aber den Timer umgestellt und steuere die Motoren aktuell mit rund 3.5KHz an- summt kaum noch, und das Ganze läuft weicher-bild ich mir jedenfalls ein.

Wie schnell läuft dein Programm? Es macht wirklich nen grossen Unterschied- darum wird auch mein Display derzeit im Betrieb nicht aktualisiert- das dauert ewig- und bremst mir die Regelung enorm aus.
Irgendwer sagte mal, zwischen 4 und 7ms pro Durchlauf sollen wohl noch gehen- ich bin bei knapp 3.5ms.

[RoboHolIC]

@ Rabenauge:
Danke für deine geduldige ausführliche Erklärung. Ich wollte dein Tom-mobil nicht schlecht reden.
Was du speziell zum D-Anteil und dem langsamen Kippen geschrieben hast, ist nachvollziehbar. Was den großen "Rest" betrifft, warte ich noch auf Erkenntnisschübe.

Aber noch eine andere Sache:
Woher kann es kommen es, dass die LCD-Ausgabe den Regler ausbremst? Werden der oder die Regler denn nicht im Interrupt abgearbeitet? Oder hat das mit den Arduino-Bibliotheken zu tun?

[Rabenauge]

Nein, die Regelung ist nicht interruptgesteuert. Auf die Idee bin ich noch gar nicht gekommen...:-k
Ehrlich gesagt, ist die so gut, dass ich direkt mal gucke, ob das noch geht.
Möglicherweise kommen mir da einige Bibliotheken wirklich in die Quere aber falls nicht, ists allemal ne richtig gute Idee.

Und zum schlechtreden: Das Ding ist mehr oder weniger erstmal drauf los gebaut worden. Anfangs wollte ich ganz andere Motoren benutzen, war mir aber nicht im klaren, ob die nun optimal wären, und _dann_ fiel mir ein, dass ich da noch diese Panzerantriebe übrig hab und als ich das nächste Mal hingesehn hab, hing da schon etwas Sperrholz dran und...dann passten zufällig die Motorrad-Räder einigermassen dran -naja.
Im Grunde ist er einfach aus Resten zusammengewürfelt.
Hätte man das Teil von Anfang an kompletter durchkonstruiert, wäre einiges anders gelaufen.
Aber: die Lösung funktioniert. Mit kleinen Schwierigkeiten, aber es geht.
Gekostet hats trotzdem mehr, als ursprünglich gedacht, aber das ist gewöhnlich so..liegt aber auch daran, dass ich da eben gewisse Ansprüche habe. Wollte eigentlich als Display am liebsten Mini-Nixies (wegen dem zu Tom passenden Look) verbauen, davon bin ich aber abgekommen weil die Dinger nunmal empfindlich sind, obendrein recht teuer und keiner weiss, ob man in zwei Jahren noch welche bekommt (soweit ich weiss, werden _keine_ mehr hergestellt)...dann gab mir jemand den Tipp mit diesem winzigen Oled-Display und drinne wars. Hat ja, da es grafikfähig ist, auch ganz andere Möglichkeiten als Nixies..

Würd ich den TomWay heute noch mal bauen, würd ich vermutlich die Rechenlast aufteilen: zwei MiniDuinos rein (Arduino Mini oder Nano), einen für die Motorensteuerung, bzw. fürs balancieren, den anderen für den Rest.


So- aber nun guck ich mal nach den Interrupts- keine Ahnung ob ich das noch hinkriege aber das ist allemal nen Versuch wert.

[dj_cyborg]

@Mario: Excel und ich- das ist nen sehr unheilige Mischung. Habs mir zwar angesehn aber da waren lauter böhmische Dörfer...
Sorry, da hab ich echt keine Ahnung von.

No Problemo.


Das Getriebespiel ist übrigens so tragisch nicht: mein TomWay hat auch ordentlich welches. So 3-4 Grad kann man die Räder drehen ohne dass sich die Motoren auch nur rühren. Beim LegoWay wars eher weniger- ich hatte da nur einstufige Getriebe benutzt.
Die NXT-Motoren kenn ich nicht wirklich, aber die vom RCX kommen mit ner mittleren Untersetzung schon mit so ner Fuhre gut zurecht- anfangs hatte ich die grossen Räder direkt auf die Motoren gesteckt, das ging auch, frass aber ganz schön Strom und gelegentlich fehlte dann doch etwas Kraft.

Leider sind meine LEGO-Motoren noch eine Generation älter. Ich benutze die 2838 (http://www.philohome.com/motors/motorcomp.htm) mit 4100U/min. Ich habe ein dreistufiges Getriebe dran welches das Spiel je Stufe nochmal verdoppelt und unnötig Kraft der Motoren raubt.


Von deinem Programm versteh ich auch nur die Hälfte (bin halt nen fauler Arduino-Programmierer geworden *zugeb), aber: mit welcher Frequenz steuierst du die Motoren an?
Ich hatte bis vor kurzem die normale Arduino PWM benutzt, die läuft nur so mit ca. 500Hz- hab inzwischen aber den Timer umgestellt und steuere die Motoren aktuell mit rund 3.5KHz an- summt kaum noch, und das Ganze läuft weicher-bild ich mir jedenfalls ein.

Die Frequenz beträgt ~61Hz, wenn ich den Prescaler noch weiter runter drehe summt mein L293D und läuft ruckelig. Hab auch deine 500 und 3500Hz versucht, mit dem gleichen Ergebniss.


Wie schnell läuft dein Programm? Es macht wirklich nen grossen Unterschied- darum wird auch mein Display derzeit im Betrieb nicht aktualisiert- das dauert ewig- und bremst mir die Regelung enorm aus.
Irgendwer sagte mal, zwischen 4 und 7ms pro Durchlauf sollen wohl noch gehen- ich bin bei knapp 3.5ms.

Lt. meiner Pseudo-Messung sollten das weniger als 3ms sein.

Was mich noch interessieren würde:
-wo hast du deinen MPU6050 angebracht? Auf Mitte/Höhe der Antriebsräder?
-Welche Drehzahl hat dein Antrieb nach dem Getriebe?
-Welchen Durchmesser haben deine Räder?

Danke.

Glück Auf
Mario

[Rabenauge]

Erstens: ich glaub, Interrupts bringen doch keine Verbesserung im Programmablauf denn: für ne ISR-Routine ist Sensor einlesen, Regelung berechnen und Motoren ansteuern um Welten zu lang, und wenn ich nur nen Flag setze was in der Hauptschleife abgearbeitet wird, gewinne ich nix, da auch das nur abgefragt würde, wenn grade Zeit ist.
Oder seh ich das falsch?

Zu deinen Fragen: auf den neueren Fotos sieht man den Sensor: er ist ca. in Mitte der Lenksäule angeordnet, also etwas vor und deutlich über der Achse.
Ich hatte ihn mal genau zwischen den Achsen-und fand nicht, dass sich da was verbessert, da der Kalman-Filter ja sowieso Beschleunigungs-und Kreiselwerte zusammen verwurstet.

Allerdings hatte ich ohnehin vor, den, als Gegenprobe, da unten noch mal reinzubauen..
Werd das vielleicht nachher mal machen, die Halterung dafür reinschrauben, den Sensor ran, ist keine grosse Sache.

Die Drehzahl der Räder weiss ich nicht wirklich- hab eben mal ne Markierung angebracht und hm-irgendwas zwischen zwei und zweieinhalb Umdrehungen/s, bei Vollgas. Da die Motoren "unbekannter Herkunft" (halt was in der 3xxer Baugrösse) sind, kann ichs nicht genauer sagen. Zumal es diese Getriebe in mehreren Ausführungen und mit verschiedenen Motoren gibt. Hab die Dinger irgendwann mal so bekommen, von daher hab ich da keinerlei Angaben.
Raddurchmesser ungefähr 105mm.

[RoboHolIC]

Erstens: ich glaub, Interrupts bringen doch keine Verbesserung im Programmablauf denn: für ne ISR-Routine ist Sensor einlesen, Regelung berechnen und Motoren ansteuern um Welten zu lang, und wenn ich nur nen Flag setze was in der Hauptschleife abgearbeitet wird, gewinne ich nix, da auch das nur abgefragt würde, wenn grade Zeit ist.
Oder seh ich das falsch?
Also, es gibt da ein Credo, das besagt, die ISR müsse unbedingt so kurz wie möglich sein. Ich halte das für Quatsch. Jegliche Codeanteile, die innerhalb einer bestimmten Zeit x im Hauptprogramm abgearbeitet werden müssen, können prinzipiell in der ISR abgearbeitet werden; alle weniger wichtigen Funktionseinheiten dann in den Lücken zwischen den ISR-Läufen, so schnell es eben geht. Auf diesem Wege erreicht man ein Timing der systemwichtigen Funktionen, das verlässlich stabil wie auf Schienen abläuft. Das hat fast nur Vorteile.
Allerdings kann ich nicht für deine Programmiersituation sprechen: Ich programmiere alle Firmware von Null weg in Assembler oder übernehme eigene Codeteile maßgeschneidert. So habe ich ich die volle Kontrolle über den Programmablauf.

[Rabenauge]

Das Problem ist: wenn man die ISR zu lang macht, bzw. sich deren Ablauf zu lang gestaltet, können bereits neue Interrupts verpasst werden.

In meinem Fall bringt es nur dann was, wenn ich etwa alle 3ms den Interrupt auslöse. Dann muss der Sensor gelesen werden (die Regelung braucht zwingend frische Ergebnisse anders funktionierts gar nicht), die Regelung kalkuliert werden, dann ein eventuell gesteuertes Offset dazu gerechnet werden und dann die Ergebnisse noch für die Motoren aufbereitet werden.
Das ist in, sagen wir, vier ms durchaus zu schaffen, ich hätte da also nen schönen Takt nur:
Das Display beschreiben dauert rund 100ms- dafür wäre gar keine Zeit, da ja mittendrin bereits wieder die Regler-Interrupts kämen.
Und ob das gut gehn würde, den Schreibzugriff stückweise durchzuführen über I2C??

[Che Guevara]

Hi,

also ich hab jetzt nicht alles genau durchgelesen, aber was mir gerade dazu einfällt:
4 ms für die Regelung halte ich für sehr lange, auch wenn es wohl funktioniert / funktionieren sollte.
Ich hab eine Multicopter Software geschrieben, die Kompass, Gyro, Acc, RC und GPS ausliest und dann die Motoren ansteuert, das ganze innerhalb 1.5ms bei 32MHz (ATXMega).
Dabei ist es natürlich von Vorteil, keine Fließkommazahlen zu verwenden, sondern alles wenn möglich auf Integer aufzubauen. Das bringt einen enormen Vorteil und ist bei geeigneter Skalierung der Werte überhaupt kein Problem.
Wenn ich es jetzt richtig im Kopf habe, verwendest du einen MPU6050?? Mit einem MPU6000 hättest du die Möglichkeit, ihn per SPI auszulesen, was bei 16MHz für 14 Registern (6x ACC, 6x Gyro, 2x Temperatur) ca. 30us dauert. Momentan wirst du dafür wohl schon ca. 500us brauchen (per I2C)?!

Vielleicht ist es dir ja eine Hilfe ;)
Gruß
Chris

[RoboHolIC]

Das Problem ist: wenn man die ISR zu lang macht, bzw. sich deren Ablauf zu lang gestaltet, können bereits neue Interrupts verpasst werden.Ich verstehe, was du meinst. Das ist aber von der Struktur deines Codes abhängig: Wenn alles Nötige in 3ms im Hauptprogramm (ausserhalb der ISR) bearbeitet wird, dann reichen auch in der (einzigen?!) ISR 3ms dafür.


Das Display beschreiben dauert rund 100ms- dafür wäre gar keine Zeit, da ja mittendrin bereits wieder die Regler-Interrupts kämen.Das braucht ja auch kein schnelles und starres Zeitraster! Nur das soll in die ISR, was auch in der recht kurzen Zeit gemacht werden muß.


Und ob das gut gehn würde, den Schreibzugriff stückweise durchzuführen über I2C??
Naja, halt entweder stückchenweise oder gar nicht. Bei nur 100kHz schafft man es in etwa 0.4ms, eine Deviceadresse, eine Registeradresse, das Nutzbyte mit und das Nutzbyte ohne das Enable-Signal für das LCD zu übertragen. Nach jeweils 3ms ist in fast allen Fällen auch ohne Busy-Check am LCD ein nächster Zugriff zuverlässig möglich.
Mittels State Machine kann man die Übertragung zum LCD-Betrieb noch feiner granulieren, wenn man den (einzigen vorhandenen) I2C-Bus splittet. Dafür gibt's angeblich I2C-Multiplexer (keine Erfahrung).
Wenn man am I2C-Bus ohne Clock Stretching auskommt, was in der Regel der Fall ist, kann man auch den I2C-Takt des Controllers wechselweise auf einen der beiden/mehreren Slaves lenken und so mehrere Verbindungen offen halten, quasi verschiedene "Threads". Das benötigt ein Oder-Gatter mit OC-Ausgang pro I2C-Kanal (ob es das wohl gibt???) Im Kopf klappt das prima, ich hab's aber weder gebaut noch getestet.

[Rabenauge]

@Chris: na soo viel schlechter wie du bin ich dann doch gar nicht- der Mega 2560 läuft nur mit 16MHz.. ;)
Nein: mir ist natürlich klar, dass das auch schneller geht aber- das hab ich nicht drauf, geb ich offen zu.
Und: ich denk nicht, dass es nötig ist, das einzige "Zeitproblem" was ich habe, wäre das Display während der Fahrt zu aktualisieren.
Mal ehrlich: wozu? Das Ding hat ne Diagonale von nem knappen Zoll- es ist 15x25mm "riesig" und Tom hat den Kopf genau drüber.
Auch wenns irgendwie geil wäre, wenn der Tacho funktionieren würd- ablesen kann den sowieso keiner.
Also lege ich mich deswegen nun nicht besonders krumm. Zumal diese Ausgabe auch noch praktisch völlig nutzlos wäre.
Das Einzige, was Sinn macht, ist es, ab und zu mal den Akkustand zu aktualisieren- und das reicht auch im Stand, weils während der Fahrt eben eh keiner ablesen kann.

Und nein: ich brauche für: Sensor auslesen (per I2C, richtig), die Daten durch den Kalman-Filter jagen, mit dem Resultat die Regelung berechnen, RC auslesen, die dort gewonnenen Werte zur Regelung dazuwursteln und das Ganze an die Motoren schicken nur 3.5ms.
Nicht länger- also nen kompletten Programmzyklus.
Was ich momentan nicht genau weiss (aber schon denke) ist, dass in der kurzen Zeit der Sensor wirklich auch jedes Mal gelesen wird (baue ich ne Ausgabe auf die serielle Konsole ein, dann hab ich dort bei jedem Durchlauf nen etwas anderen Wert), zudem käm ansonsten ne Fehlermeldung, die nicht auftaucht.
Mein Fazit dazu: es geht schnell genug. Also warum auf Krampf da noch mehr rauskitzeln (ich glaub nicht, dass die Motoren so schnell überhaupt reagieren können). Da bau ich nur Mist...

Bin übrigens grade dabei, mir eine Strategie auszudenken, wie ich verhindere, dass die Geschwindigkeit zu hoch wird. Im Kopf funktionierts schon mal-aber das hatte ich schon öfter... ;)

[Rabenauge]

Sodele.
Das mögliche Fahrtempo ist nun limitiert.
Auch lenken klappt etwas besser- aber im Stand noch immer nicht, dort fehlt einfach noch ne Logik dahinter. Durch das andauernde Gependele (was sich systembedingt nun mal nicht vermeiden lässt) dreht er dauernd wieder zurück.
Das muss ich logisch so aufdröseln, dass im Stand einfach "anders" gelenkt wird als während der Fahrt.
Soweit bin ich noch nicht, aber es ist mir schon (leider nur in der zu dunklen Bude für die Keycam) einige Male gelungen, um ein Rad Vollkreise zu "fahren" -> mit minimaler Fahrtvorgabe klappt das.
Auch, ob das limitieren des Tempos ausreicht weiss ich noch nicht- hier drin ists einfach zu eng. Muss ich mir mal ein grosszügiges, einigermassen ebenes, und ruhiges Testgelände suchen die Tage..

Was mich inzwischen aber nervt: der Neutralpunkt. Er schwankt geringfügig (in der Gegend um 0.2 Winkelgrade)- immer dann, wenn ich den Roller mal offen hatte ist da ne leichte Verschiebung. Manchmal jedenfalls. Das heisst dann immer neu trimmen.
Entweder bau ich mir da nen Spindeltrimmer ein für die Feinjustierung, oder ich mache da eine autotrimmung per Software-wüsste allerdings nicht, wie. Das hab ich schon mal versucht gehabt(einfach ne Zeitlang die Regelung beobachten und dann ggf. nachstellen)- mit jämmerlichem Ergebnis allerdings.

Weiss jemand, wie _andere_ das machen?

[RoboHolIC]

Das muss ich logisch so aufdröseln, dass im Stand einfach "anders" gelenkt wird als während der Fahrt.
Lenkst du noch immer mit einem Rad? Dann würde jeder Lenkeingriff aktiv eine Störung des Gleichgewichts erzeugen. Wenn beide Raddrehzahlen/PWM-Werte gegenläufig um ein Delta verändert werden, sollte eigentlich-theoretisch-im-Prinzip kein Ungleichgewicht erzeugt werden - sofern der Sensor mittig über der Achse montiert ist (und die effektiven Drehpunkte unter den breiten Reifen tatsächlich symmetrisch liegen).

Apropos Lenkung: Ist der Gleichlauf der Motoren tatsächlich so gut, dass du noch gar keinen Bedarf für die Drehzahlregelung hast? Ich denke da an oberallgeier's Dosen, die ungeregelt einen ziemlich miesen Geradeauslauf aufwiesen.

[Rabenauge]

Offiziell lenkt er inzwischen mit beiden Rädern-aber die Wirkung ist nicht ganz so, wie erwartet. Zugegeben: wenn mans mal ordentlich programmieren würde...momentan ists ne "Bastellösung" (die eigentlich funktionieren sollte, und es prinzipiell auch irgendwie tut), geht noch besser. Muss ich mich echt mal ne Stunde ransetzen..
Und: ja, die Störungen gibts natürlich, weil ein Rad (weils schneller dreht..) die Fuhre natürlich aus dem Gleichgewicht bringt. Macht aber nix: die Regelung fängt das mühelos ab.
Selbst bei kleinsten Fahrkommandos ist das Ding erstaunlich friedlich (Kreiselkräfte?-> kann ich mir bei den leichten Rädchen nicht so recht vorstellen..), da merkt man echt nix mehr von der Balanceregelung. Im Stand schon!

Und nein: perfekt ist der Gleichlauf nicht. Sind billige Getriebemotoren, bestückt mit noch billigeren Motoren. Mal zieht er bisschen rechts weg, mal nach links- aber innerhalb akzeptabler Grenzen( bei Geradeausfahrt vielleicht 5cm auf nen Meter), das Teil soll ja gelenkt werden, da korrigiert man das sowieso automatisch. Ist nicht so wirklich der Rede wert..
Was aber hilft: die breiten Räder. Mit den früheren, schmalen, lief er nicht so gut gradeaus.
Ich seh da jetzt nicht wirklich Handlungsbedarf.

[RP6conrad]

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?title=Balancerende_robot

[RoboHolIC]

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.

[Rabenauge]

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

[RoboHolIC]

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.

[Rabenauge]

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

[RoboHolIC]

Wenn man den schiebt, kullert er einfach los, und fängt sich dann, rollt auch wieder ungefähr zurück.. 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?
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 ...

[Rabenauge]

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.

[RoboHolIC]

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

[Rabenauge]

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...:cool: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.

[RP6conrad]

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

[RoboHolIC]

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!Feedback der Motoren bzw. PWM auf den/die Sensoren? Müssen die Sensorsignale stärker gedämpft werden? Oder mechanisch vom Chassis entkoppelt?

Wie steif steht Tom eigentlich auf seinem Mobil? Falls er jeder Regelbewegung hinterherpendeln und damit den Schwerpunkt verändern kann, macht es die Regelungsaufgabe nicht leichter.

Hast du auch das youtube-Video gesehen, wo jemand auf einem Lego-Segway einen stilisierten Lego-Fahrer montiert hatte, der per Fernsteuerung nach vorne und hinten geneigt werden konnte, wie es ein realer Fahrer auch tut? Mir ist aber nicht klar, ob das regelungstechnisch einen Unterschied macht. Und auch nicht, ob das hier weiterhilft.