Segway per RC

Zitat:

---

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

Zitat:

---

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 mit 4100U/min. Ich habe ein dreistufiges Getriebe dran welches das Spiel je Stufe nochmal verdoppelt und unnötig Kraft der Motoren raubt.

Zitat:

---

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.

Zitat:

---

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

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.

Zitat:

---

Zitat von 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?

---

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.

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

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

Zitat:

---

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

---

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.

Zitat:

---

Zitat von Rabenauge

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

Zitat:

---

Zitat von Rabenauge

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.

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

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?

Zitat:

---

Zitat von Rabenauge

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.

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.