Kugelroboter

Hallo,

nachdem ich mich schon mal mehr oder weniger erfolgreich mit dem Thema "Balancieren" beschäftigt habe, wollte ich dieses mal einen Roboter bauen, der in zwei Dimensionen das Gleichgewicht hält.
Ich habe also einen Roboter gebaut, der auf einer Kugel (Gymnastikball, ca. 40cm Durchmesser) balanciert. Er besteht fast nur aus einem omnidirektionalen Antrieb und Elektronik.

Um das Gleichgewicht halten zu können, muss er natürlich wissen, wo unten ist. Dazu hat er einen zweiachsigen Beschleunigungssensor (ADXL322) und zwei Gyros (ENC03R). Die Daten der Sensoren filtere ich im Moment noch mit einem Komplementärfilter, das soll aber mal ein Kalman-Filter werden.

Die beiden Balancier-Dimensionen (links/rechts und vor/zurück) werden unabhängig voneinander gesteuert.
Außerdem habe ich noch eine Fersteuerung für den Roboter gebaut, sodass man ihn gezielt in eine Richtung steuern kann. In dieser Fernsteuerung befindet sich ebenfalls ein Beschleunigungssensor, sodass man sie nur in die Richtung kippen muss, in die der Roboter fahren soll.
Das Balancieren funktioniert ganz gut, man muss nur aufpassen, dass der Roboter nicht zu schnell wird, weil er sonst irgendwann nicht mehr schnell genug reagieren kann. Die Funkverbindung zwischen der Fernsteuerung und dem Roboter habe ich mit dem RFM12-Funkmodul gebaut.

Geregelt wird der Roboter mit zwei PID-Reglern, jeder für eine Achse.
Auch die Reglerparameter können über die Fernsteuerung verändert werden. (Fernsteuerung ist vielleicht der falsche Begriff, eigentlich besteht sie nur aus einem Display, einem Funkmodul und etwas Elektronik.)
Während der Roboter balanciert, kann man sich am PC anzeigen lassen in welchem Winkel er gerade meint zu stehen, sodass man den Filter und Regler gut einstellen kann.

Ein kleines Video gibts auch.

Allerdings ist mir noch nicht eingefallen wofür so ein Roboter gut sein könnte. Es macht zwar Spaß ihn zu steuern und es sieht auch lustig aus, wenn er auf dem Ball herumhüpft, aber richtig sinnvoll scheint er nicht zu sein.

Gruß,
Jan

Wow, das ist ja ein super Teil! Schön gebaut und funktionieren tut es auch sehr gut!
Ich habe ein Projekt mit ähnlichen Herausforderungen:
Link
Könntest du mal umschreiben wie du den Komplementärfilter aufgebaut hast? Was hast du für Filter für die Gyro- / ACCsignale? Grenzfrequenz?

tolles projekt sieht super aus und zum zweck es kann vieleicht auf sehr weichem untergrund fahren weil der ball ja sher groß .
hast du mal probiert auf unwegsammen gelände zufahren? wieviel steigung kann man damit fahren?

Den Komplementärfilter habe ich hier abgeguckt. Bloß eben die Konstanten verändert bis der Winkel ganz gut stimmt.

Zitat:

---

Ich habe ein Projekt mit ähnlichen Herausforderungen

---

Ist es bei deinem Projekt eigentlich auch so, dass der Roboter, wenn er einmal etwas schräg liegt immer weiter in diese Richtung kippt (labiles Gleichgewicht)? Das ist mein Hauptproblem: Der Roboter rollt in eine Richtung weg und wird so schnell, dass die Motoren nicht schnell genug sind -> kippt um. Im Moment steuere ich durch kippen der Fernsteuerung dagegen, besser wäre es natürlich, wenn der Roboter das selbstständig tut.

Auf unebenem Gelände habe ich es noch nicht probiert, ich bin froh, wenn der Roboter oben bleibt. Wenn er stabiler läuft werde ich es sicher mal versuchen.

Danke für den Link zum Komplementärfilter. Werde mir das mal genauer anschauen und ggf ausprobieren.

Zitat:

---

Ist es bei deinem Projekt eigentlich auch so, dass der Roboter, wenn er einmal etwas schräg liegt immer weiter in diese Richtung kippt (labiles Gleichgewicht)?

---

Nein, mein Copter schafft es mittlerweile langsam und leicht um den 0° Winkel zu pendeln.
Das umkippen ist aber dann wohl kein Problem deiner Regelung, sondern eine Einschränkung der Aktoren... Da kannst du nur versuchen zu verhindern dass der Roboter zu schnell wird... Oder schnellere Motoren nutzen...

Hey, sehr schönes Projekt!
Habs leider nie so weit geschafft ... aber vielleicht inspiriert Dich ja folgender Link etwas! :)
http://www.msl.ri.cmu.edu/projects/ballbot/

Liebe Grüße
Florian

Zitat:

---

Oder schnellere Motoren nutzen...

---

Ich habe da noch etwas Reserven: bis jetzt sind die Akkus parallel geschaltet. Die Motoren würden aber auch die Spannung aushalten, wenn ich sie in Reihe schalte.

Zitat:

---

aber vielleicht inspiriert Dich ja folgender Link etwas!

---

Hat er schon. Daher habe ich nämlich die Idee. Da mein Versuch, eine Kugel als Rad zu benutzen, wie in dem Link, an der Reibung gescheitert ist, habe ich die Kugel einfach größer gemacht.

Der Komplementärfilter ist nichts besonderes. Das Signal wird auch nicht ganz gut gefiltert. Das wird bei mir auch noch ein Kalman-Filter. Ich wollte jetzt bloß erstmal testen, ob der Roboter grundsätzlich funktioniert.

Der Kalmanfilter ist auch kein Wunderding. In der Regel bekommt man nach relativ kurzer Zeit für Kovarianzmatrix konstante stationäre Werte. Dadurch vereinfacht sich der Filter ungemein. Die Matrixinversion usw. kann dann nämlich mit den konstanten Werten einmal vorab machen und man bekommt auch nichts wesentlich anderes herraus als den Filter oben. Der wesenliche Unterschied ist, dass man Formeln bekommt wie man die beiden Filterparameter berechenen kann, wenn man die Genauigkeit der einzelen Sensoren kennt. Allerdings sind die Angaben zum Rauschen und anderen Fehlern der Sensoren oft nicht gerade sehr genau. Man bekommt also auch mehr eine erste Näherung für die Filterparameter. Für genauere Werte müßte man dann doch wieder probieren.

Aber immerhin hat man über den Kalman Filter einen Weg wie man berechnen kann wie so ein Filter aussehen kann, inclusive der Werte für die Parameter. Außerdem weiss man das der so erzeugte Filter fast optimal ist (sollte asymtotisch optimal sein, wenn ich mich richtig erinnere und ein paar Vorraussetzungen erfüllt sind). Wenn es also damit nicht geht, sollte man eher an den Sensoren arbeiten und nicht versuchen einen anderen Algorithmus zu suchen, denn viel besser gehts nicht.

Hi, die Idee hatte ich auch schon gehabt, aber es ist an die Räder gescheitert. Omniräder das war die Lösung! Super! Damals hatte ich als Amphibien Roboter gedacht. Also Wasser und Grund, aber ich denke es dürfte keine Gummiball sein, weil schon kleine Sprünge sind tödlich.
Und wie du es geschafft hast ist wirklich super!
Grüß
Paul

Ich habe noch ein wenig weiter gebastelt. Der Roboter hat jetzt an den Achsen Lochräder, sodass er erkennen kann, wann er zu schnell wird. Die Auswerteelektronik fehlt noch, ich kann deshalb noch nicht sagen, ob er dadurch besser balanciert.

Zitat:

---

Damals hatte ich als Amphibien Roboter gedacht. Also Wasser und Grund, aber ich denke es dürfte keine Gummiball sein, weil schon kleine Sprünge sind tödlich.

---

Das verstehe ich nicht richtig. Ein Roboter der auf einer Kugel auf dem Wasser balanciert? Oder "nur" auf dem Wasser und dem Grund normal (ohne balancieren) herumfährt?

Ich habe auch Bilder der Fernsteuerung gemacht. Das Display ist von Pollin (120346), der Rest ist die standart µC Beschaltung + RS232 und RFM12.

Hallo Jan,

schönes Projekt. So eine feine Demonstration von Regelungstechnik find ich schon nützlich!

grüsse,
Hannes

Nicht schlecht. Platinen sind gefräst oder geätzt?

Die Platinen sind geätzt. Mein erstes Projekt mit geätzten. Vorher habe ich immer alles auf Lochraster aufgebaut. Um aber bei diesem Roboter SMD benutzen zu können habe ich mir eine Küvette gebaut. Klappt übrigens super, wenn man richtig belichtet.
Für die Platine der Fernsteuerung habe ich 4 Versuche gebraucht.
Beim ersten lag die Belichtungsvorlage nicht richtig auf->Leiterbahnen verschwommen
Beim zweiten habe ich den Atmega32 zu lange und heiß gelötet, einige Leiterbahnen haben sich auch schon gelöst und beim dritten habe ich zu kurz entwickelt.
Beim vierten Versuch hats endlich geklappt.

Auch die anderen Platinen habe ich alle doppelt. Bei denen hat zwar das ätzen gut geklappt, aber der Drucker war falsch eingestellt->alles zu groß.
Ich habe das natürlich erst nach dem Ätzen und Bohren gemerkt.

hi,

ein wirklich schönes Projekt \:D/

Glückwunsch zur gelungenen Umsetzung.


Wenn der Robby mal auf seinem 40 cm Ball richtig läuft (fährt ?) könnte er auf der Oberseite kleine Snack´s servieren.

Im Liegestuhl liegend ist die Höhe wohl optimal.



Was mir aufgefallen ist:

ich würde noch eine kleine Stoßstange um die äußeren Enden der Ausleger anbringen.

Falls der Robby während der Testphase mal in´s "trudeln" kommt und auf den Drehgebern landet verbiegst Du dir die Scheibe und zerstörst ggf. den Sensor.


Bin schon mal gespannt, wie es weitergeht.


liebe Grüße,

Klingon77

@kehrblech:
Schönes Projekt!

(Aber du musst mal den Sensor deiner D70 sauber machen :) )

Zitat:

---

(Aber du musst mal den Sensor deiner D70 sauber machen)

---

Ist nicht meine, gehört meinem Vater. Woher weißt du eigentlich von welcher Kamera die Fotos sind? Ich glaube, dass konnte man irgendwie beim Bild nachgucken, aber ich finde es gerade nicht.

Zitat:

---

ich würde noch eine kleine Stoßstange um die äußeren Enden der Ausleger anbringen.
Falls der Robby während der Testphase mal in´s "trudeln" kommt und auf den Drehgebern landet verbiegst Du dir die Scheibe und zerstörst ggf. den Sensor.

---

Dafür gibt es ganz außen am Roboter die kleinen Profile, die über der Radaufhängung an zwei Schrauben befestigt sind (Nicht die, an denen der CNY37 befestigt ist, sondern der Winkel darüber). Da hake ich kleine Karabiner-Haken ein und hänge den Roboter an meiner Decke auf. Damit kann man natürlich nicht weit fahren, aber es reicht um zu testen, ob es funktioniert.

Zitat:

---

Wenn der Robby mal auf seinem 40 cm Ball richtig läuft (fährt ?) könnte er auf der Oberseite kleine Snack´s servieren.

Im Liegestuhl liegend ist die Höhe wohl optimal.

---

Nette Idee. Dazu muss er aber erstmal sicher funktionieren, bis jetzt ist er noch sehr wackelig.

Zitat:

---

Zitat von kehrblech

Woher weißt du eigentlich von welcher Kamera die Fotos sind?

---

Steht in den EXIF's.

Hallo,
wie gesagt es ist nur eine Vision. Ich denke mit einem bestimmten Offset am Giros es könnte möglich sein Roboter in einem Richtung fahren lassen. Mit einem verpassten Maussensor kann man sogar Richtung bestimmen, und Geschwindigkeit kontrollieren. Maussensor in dem fahl hätte einen geringe und konstanten Abstand.

Grüß
Paul

Offset an den Gyros ist eher schlecht, besser einen Offset direkt am berechneten Winkel. Genau das passiert auch wenn man die Fernsteuerung kippt. Der Sollwinkel wird verändert und der Roboter fährt in eine Richtung. Wenn man ihn das automatisch machen lässt, wird er zu schnell und kippt um.

Zitat:

---

Maussensor in dem fahl hätte einen geringe und konstanten Abstand.

---

Gering vielleicht schon, aber konstant bleibt der ganz sicher nicht, denn der Roboter hüpft manchmal stark auf dem Ball herum.
Der Ball muss aus Gummi sein, damit die Omniwheels genug Reibung haben.

Ich bin jetzt mit der Auswertung der Radsensoren fertig. Der Roboter weiß also wie schnell er fährt. Leider bringt das bis jetzt nicht besonders viel, das liegt daran, dass die Geschwindigkeiten nur mit einer kleinen Verzögerung gemessen werden. Jedesmal wenn die Lichtschranke ein Loch meldet, wird die Geschwindigkeit aktualisiert. Da aber nur 16 Löcher in der Scheibe sind, dauert das selbst bei der Höchstgeschwindigkeit immer noch länger als ein Regeldurchlauf. Leider fehlt mir auch die Richtungserkennung, ich nehme als Laufrichtung immer die, mit der die Motoren im Moment angesteuert werden. Da aber die Motoren nicht sofort auf Richtungsänderungen reagieren, stimmt das nicht immer. Außer zwei Lichtschranken pro Rad fällt mir gerade keine Lösung ein. Da bei meinen Lochrädern aber die Löcher kleiner sind als die Zwischräume dazwischen, müsste ich wahrscheinlich neue machen.

Außerdem habe ich noch ein Problem:
Ich habe mir mal die Daten der Sensoren auf dem PC anzeigen lassen, einmal im Stillstand, einmal beim Balancieren. Wenn die Motoren aus sind, liefert die Sensorplatine einen sehr genauen Winkel. Sobald der Roboter balanciert, habe ich ein sehr starkes Rauschen auf allen Sensoren (ACC-Sensor und Gyro) und deshalb auch auf dem berechneten Winkel.
Da meine Abtastgeschwindigkeit beim Balancieren sehr langsam ist, könnte es natürlich auch sein, dass der Winkel sich einfach so schnell verändert. Schneller kann ich leider nicht abtasten, weil der Roboter mit dem Balancieren sehr beschäftig ist.
Allerdings glaube ich eher, dass es Rauschen ist, weil die Gyros teilweise sehr große Signale liefern, obwohl die Winkelgeschwindigkeit beim Balancieren ziemlich klein bleibt.
Eigentlich erstaunlich, dass der Roboter überhaupt balanciert.

Zitat:

---

Gering vielleicht schon, aber konstant bleibt der ganz sicher nicht, denn der Roboter hüpft manchmal stark auf dem Ball herum.
Der Ball muss aus Gummi sein, damit die Omniwheels genug Reibung haben.

---

Ich glaube du sprichst hier von 2 unterschiedliechen Eigenschaften von Gummi die man auch getrennt betrachten und nutzen kann.
Was die Omniwheels benötigen ist die Reibung, was das Hüpfen verusacht ist die Elastizität. Ein gummibechichtete Kugel aus einemanderen Material könnte weniger hüpfen und trotzdem die nötige Reibung aufweisen.
Ist aber wahrscheinlich schwierig etwas passendes zu finden.

Ich könnte mir vorstellen, dass man das Hüpfen bei einem Gummiball etwas reduzieren kann, wenn man z.B. etwas Wasser einfüllt - habe aber keine Ahnung ob das deinem Zweck entgegenkommt.

Zitat:

---

Ich habe mir mal die Daten der Sensoren auf dem PC anzeigen lassen, einmal im Stillstand, einmal beim Balancieren. Wenn die Motoren aus sind, liefert die Sensorplatine einen sehr genauen Winkel. Sobald der Roboter balanciert, habe ich ein sehr starkes Rauschen auf allen Sensoren (ACC-Sensor und Gyro) und deshalb auch auf dem berechneten Winkel.

---

Bei "Rauschen wenn Motor an" fällt mir als erstes die Entstörung der Motoren ein. Hast du die mit Kondensatoren entstört?
Von Haus aus sind an den von dir verwendeten Motoren ja keine Entstörkondensatoren dran.

Die Motoren die du verwendest ziehen auch reichlich Strom, besonders, wenn Sie beim Balancieren ständig hin - und hergeschaltet werden.
Das könnte sich auch als Störungen auf deine Spannungsersorgung auswirken.
Bei einer Akkuspannung von soweit ich sehe 7,2V könnte ich mir vorstellen, dass die deine Versorgungspannung teilweise sogar unter den von deinem Spannungsregler benötigten Bereich ziehen.
Falls es daran liegt, könnte man mal probieren, ob sich das Rauschen mit einem grösseren Elko reduzieren lässt.

Zitat:

---

Eigentlich erstaunlich, dass der Roboter überhaupt balanciert.

---

Hmm, ja - den Bildern nach müsste der Roboter ohne die Sensoren eigentlich noch besser balancieren ;-)
Kann es sein, dass du vielleicht auch nur irgendwo einen kleinen "Fehler" im Programm zur Ausgabe der Werte gemacht hast?

Zitat:

---

Hast du die mit Kondensatoren entstört?
Von Haus aus sind an den von dir verwendeten Motoren ja keine Entstörkondensatoren dran.

---

Der Kondensator zwsichen den beiden Motorpolen war von Anfang an dran. Die Kondensatoren zum Motorgehäuse habe ich erst bei einem Motor angelötet. Ich hatte das vor dem Einbauen vergessen und jetzt komme ich sehr schlecht dran. Muss ich wohl nochmal alle Motoren ausbauen.

Zitat:

---

Bei einer Akkuspannung von soweit ich sehe 7,2V könnte ich mir vorstellen, dass die deine Versorgungspannung teilweise sogar unter den von deinem Spannungsregler benötigten Bereich ziehen.

---

Das sollte funktionieren. Für die Logik habe ich einen 5V Low-Drop Regler, für die Sensoren einen 3,3V. An den 3,3V hängt außer den Sensoren auch nichts dran, sodass die Spannungsversorgung stabil sein müsste (Kann ich leider nicht messen).

Zitat:

---

Falls es daran liegt, könnte man mal probieren, ob sich das Rauschen mit einem grösseren Elko reduzieren lässt.

---

Nein, dadurch ändert sich nichts.
Eigentlich bin ich mir auch ziemlich sicher, dass das Rauschen nicht von der Elektronik kommt, sondern von der Mechanik. Mein alter Kugelroboter hatte genau das gleiche Problem. Testweise habe ich die Motoren auch mal mit einer extra Stromversorgung laufen lassen, das änderte auch nichts. Die Sensoren werden durch Schwingungen, die von den Motoren übertragen werden gestört. Ich habe die Sensoplatine mit Moosgummi befestigt, dadurch wurde es minimal besser.
Wie funktioniert das eigentlich bei den Quadrokoptern? Da treten doch sicher auch Schwingungen auf.

Zitat:

---

Kann es sein, dass du vielleicht auch nur irgendwo einen kleinen "Fehler" im Programm zur Ausgabe der Werte gemacht hast?

---

Ich wüsste nicht wie das gehen kann. Das Programm weiß ja nicht ob der Roboter gerade balanciert oder nicht. Es zeigt einfach nur die Daten der Sensoren an.

Zitat:

---

Das sollte funktionieren. Für die Logik habe ich einen 5V Low-Drop Regler, für die Sensoren einen 3,3V. An den 3,3V hängt außer den Sensoren auch nichts dran, sodass die Spannungsversorgung stabil sein müsste (Kann ich leider nicht messen).

---

Stimmt, ohne Oszilloscop ist das schwierig. Du könntest höchstens mal die Akkuspanniung messen, während du die Motoren vorsichtig ein wenig abbremst um zu sehen ob sie dabei in die Knie geht.

Zitat:

---

Zitat:
Kann es sein, dass du vielleicht auch nur irgendwo einen kleinen "Fehler" im Programm zur Ausgabe der Werte gemacht hast?

Ich wüsste nicht wie das gehen kann. Das Programm weiß ja nicht ob der Roboter gerade balanciert oder nicht. Es zeigt einfach nur die Daten der Sensoren an.

---

Ok, da habe ich deinen vorherigen Post missverstanden oder etwas falsches reininterpretiert.

Wegen "Da meine Abtastgeschwindigkeit beim Balancieren sehr langsam ist," habe ich irgendwie geschlossen, dass du das Balancieren im Programmcode abgestellt und dadurch eventuell irgendwelchen für die Messung relevanten Code geändert hast.

Zitat:

---

Die Sensoren werden durch Schwingungen, die von den Motoren übertragen werden gestört. Ich habe die Sensoplatine mit Moosgummi befestigt, dadurch wurde es minimal besser.

---

Was passiert denn, wenn du die Sensorplatine mechanisch von den Motoren trennst und nur die Sensorplatine in der Hand bewegst. Mechanische Störungen durch die Motoren müssten dann ja rausfallen, elektrische würden bleiben.

Irgendwie aber seltsam - das Balancieren klappt ja, d.h. so schlecht können die Werte der Sensoren gar nicht sein.
Vielleicht ist das was wir da als Rauschen ansehen ja einfach nur das Blancieren ;-)

Akkus sind noch relativ voll, Lehrlaufspannung so um 7,7V. Wenn ich nur einen Akku benutze, einen Motor schnell laufen lasse und ihn so stark blockiere, dass ich noch keine Angst um die Radbefestigung habe, bricht die Spannung auf ca. 7,4-7,5V ein. Laufen alle Motoren gleichzeitig los, ohne blockierung, geht die Spannung kurz runter, so etwa auf 7,2V.
Wenn ich beide Akkus benutze sollte die Spannung noch höher bleiben. Angeblich kann ein Akku einen Strom von 40A liefern (behauptet der Hersteller, aber die übertreiben manchmal etwas), zusammen also 80. Sollte reichen.

Zitat:

---

Wegen "Da meine Abtastgeschwindigkeit beim Balancieren sehr langsam ist," habe ich irgendwie geschlossen, dass du das Balancieren im Programmcode abgestellt und dadurch eventuell irgendwelchen für die Messung relevanten Code geändert hast.

---

Der Code für die Messung verändert sich dadurch nicht, nur der Interrupt fürs Balancieren springt eben öfter dazwischen, sodass ich die Werte nicht mehr so schnell hintereinander bekomme wie sonst.

Zitat:

---

Was passiert denn, wenn du die Sensorplatine mechanisch von den Motoren trennst und nur die Sensorplatine in der Hand bewegst.

---

Es sieht dann deutlich besser aus, fast keine Störungen mehr. Das was noch übrig bleibt kommt wahrscheinlich von meiner Handbewegung.

Ich habe die Sensorplatine wieder eingebaut und das Balancieren gestartet. Der Roboter fuhr dabei aber nicht auf dem Ball, sondern lag verkehrt herum auf dem Tisch. Die Sensoren haben noch ein paar Schwankungen, aber der berechnete Winkel ist wirklich deutlich besser (Bild). Dass er nicht mit den Beschleunigungssensor übereinstimmt liegt daran, dass der Roboter nicht damit klar kommt, dass er verkehrt herum liegt.
Vielleicht ist das "Rauschen" wirklich nur das Balancieren.

Hallo,
alle letzte Frage. Es ist mir gerade aufgefallen wie du Räder befestigt hast. Ist das nicht besser wäre die Radachse auf 90 Grad zu drehen?
Grüß
Paul

Das verstehe ich jetzt nicht ganz. Meinst du den Winkel zwischen den verschiedenen Rädern? Zwischen zwei Rädern sind das 120°. Wenn man das mit 90° macht bräuchte man 4 Räder.
Oder meinst du die Neigung der Räder? Also, dass die Räder nicht richtig den Boden berühren, wenn man den Roboter auf eine glatte Fläche stellt.
Das ist Absicht, weil die Räder so der Wölbung des Balls angepasst sind.

Hallo,
ich hatte ja oben schonmal nach der Filterung von ACC und Gyro gefragt. Welche Grenzfrequenz hast du für den Tiefpass gewählt? Es ist normal, dass der ACC total rauscht, aber der wird "normalerweise" mit einer fg von ca 5Hz oder so gefiltert. Und Gyros kann man ruhig mit einer fg von 40 Hz betreiben, das schadet einer schnellen Regelung nicht (obwohl man das erst kaum glauben mag). Mit welcher Geschwindigkeit läuft dein Regelkreis? Mein Copter läuft z.B. mit 400 Hz. Das kannst du einfach messen indem du eine Variable jeden Durchlauf um eins erhöhst und wenn 500 erreicht sind, setzt du die wieder auf null und toggelst eine LED. Oder schreibst was auf den Serialport.

Hallo,

Regelkreis läuft mit 100Hz.
ACC-Sensor hat einen Tiefpass mit 50Hz (Ich filtere das Signal aber nochmal in der Software), beim Gyro habe ich keine Ahnung. Da ich sowieso mit Analogtechnik überhaupt keine Erfahrung habe, benutze ich die Mikrokopter Beschaltung. http://mikrokopter.de/ucwiki/FlightC...et=FC_V1_3.gif
Rechts sind die Gyros + Operationsverstärker. Einziger Unterschied ist bei mir, dass ich keinen DAC benutze, sondern den Widerstand R8/12/16 jeweils an den Gyro (Vref) anschließe.
Soweit ich das verstanden habe kann man den Tiefpassfilter in dieser Schaltung nur mit C9/15/17 beeinflussen, ohne dass sich die Verstärkung ändert.
Welche Kapazität entspräche denn 40Hz?

[Edit]:Nach langem rechnen bin ich darauf gekommen, dass der Tiefpass-Filter des Gyros 150Hz haben müsste. Keine Ahnung wie genau ich jetzt darauf gekommen bin und ob es stimmt.
Nach meiner Rechnung bräuchte ich einen Kondensator mit ca. 85nF um auf eine Grenfrequenz von 40Hz zu kommen. Kann das mal jemand nachrechnen?

Hallo Kehrblech, der kleine blaue button über den beiträgen dient zum melden eines beitrages an die moderatoren. ich denke nicht dass du willst dass der beitrag gelöscht wird, deshalb lass ich ihn mal so stehen ;)

grüße
damaltor

Hi!
Ich glaube zwar nicht, dass es dramatische Auswirkungen hat wenn dein Regelkreis nicht viel schneller läuft als die grenzfrequenz des Tiefpasses, aber optimal ist was anderes... Die Abtastung sollte deutlich schneller sein als die Grenzfrequenz, mindestens Faktor 4 rate ich mal. Ausserdem musst du darauf achten, dass du ganz ganz kurz vor dem senden der Motorsollwerte neue Werte aus Gyro + Acc berechnest. Dieser Zeitabstand scheint sehr kritisch zu sein und großen Einfluss auf die Regelgüte zu haben.
Du kannst auch einfach nach dem Opamp noch einen Tiefpass mit R und C einbauen. Das erleichtert die Rechnerei deutlich :-D

Zitat:

---

Ich filtere das Signal aber nochmal in der Software

---

Darauf würde ich - wenn möglich - verzichten. Kostet nur unnötig Rechenzeit, denn das kann auch der Kondensator + Widerstand erledigen.

Zitat:

---

ich denke nicht dass du willst dass der beitrag gelöscht wird, deshalb lass ich ihn mal so stehen

---

Richtig, ich wollte eigentlich editieren, hab aber den falschen Knopf erwischt.

Zitat:

---

Du kannst auch einfach nach dem Opamp noch einen Tiefpass mit R und C einbauen. Das erleichtert die Rechnerei deutlich :-D

---

Ne, dann brauche ich ja eine neue Platine. Ich versuche es mal mit anderen Kondensatoren.

[Edit]: Tiefpass Filter vom ACC-Sensor hat jetzt 5Hz, beim Gyro sind es ca. 35Hz. Die Abtastrate beträgt ca. 630Hz, die Regelung läuft aber nur mit 100Hz. Bislang habe ich keine Veränderung bemerkt.

Hallo,
das angehängte Bild sollte klären was ich meine. Also mit Winkelgetriebe nur Radachse um 90° Grad drehen.
Grüß
Paul

Und wofür soll das gut sein? Nicht nur die Mechanik wird komplizierter, sondern der Roboter kann sich auch noch unkontrolliert um die Hochachse drehen.
Omnidirektionale Antriebe sehen fast immer so aus wie bei meinem Roboter, nur manchmal sind die Räder nicht gleichmäßig verteilt, sodass der Roboter in eine Richtung besonders schnell/kraftvoll fahren kann.

Hi, wenn dich immernoch das Rauschproblem plagt, schau dir doch einfach mal das Spektrum deiner Messungen an.

Eine kleine Schwierigkeit könnte darin stecken das deine Messrate nicht konstant ist (wenn du zu sehr mit den Interrupts unterwegs bist). Kannst du irgendwie ne zeitartige Sache dazu speichern, sag mer mal vergangene Takte oder so?

Das Spektrum dürfte dir dann sagen ob du wirkliches Rauschen vorliegen hast, oder ob du einfach nur irgendwelche Schwingungen von den Getrieben oder so drin hast.

Evtl wärs auch sinnvoll 2 Controller zu benutzen, einen zur Messung und Filterung (Kalman wär wahrscheinlich wirklich gut, wenn du weist wie man die Parameter sauber wählt), und einen zur Regelung. Dann könntest sinnvolle (und konstante) Abtastraten einhalten, was bei jeder Art von digitaler Filterung ja recht dringend notwendig ist.

Nein, das "Rauschen" ist kein Problem. Das war kein Rauschen, sondern einfach nur ein viel zu langsam abgetastetes Signal.
Im Moment versuche ich dem Roboter das selbstständige Balancieren beizubringen, sodass man nicht mehr mit der Fernsteuerung die Position halten muss. Der Roboter soll auf einer Stelle balancieren und auch dorthin zurückfahren, wenn er sich etwas entfernt hat. Ein paar Sekunden klappt das auch, aber dann schwingt er sich auf, pendelt um diese Stelle und wird irgendwann zu schnell. Liegt vielleicht an meinen Reglereinstellungen, da habe ich noch nicht so viel ausprobiert.

Zitat:

---

Evtl wärs auch sinnvoll 2 Controller zu benutzen, einen zur Messung und Filterung (Kalman wär wahrscheinlich wirklich gut, wenn du weist wie man die Parameter sauber wählt), und einen zur Regelung. Dann könntest sinnvolle (und konstante) Abtastraten einhalten, was bei jeder Art von digitaler Filterung ja recht dringend notwendig ist.

---

Es sind zwei Controller. EIn ATmega8 macht die Filterung, ein Mega32 die Regelung und den Funkverkehr. Beides (Regelung und Messung+Filterung) läuft im Interrupt, also mit einer konstanten Abtastrate.

Du hast dir sicherlich was dabei gedacht, Regelung + Datenaufnahme auf zwei µC's zu splitten, aber ist das so optimal....? Ich meine, ein Mega32 sollte eigentlich keine Schwierigkeiten haben alles auf einmal zu machen. Die Datenübertragung von µC1 zu µC2 dauert sicherlich auch ein bisschen. Alle diese Zeiten summieren sich auf und machen deine Regelung langsam. Da kann sie mit 1000Hz laufen, wenn die gemessenen Sensorwerte schon 0.1 Sekunden alt sind bringt das auch nichts mehr.... Ein Kollege hat es geschafft einen MiniQuadrocopter (Achsabstand 155 mm, das ist SEHR klein) mit nur 50Hz Regelfrequenz zum fliegen zu bekommen. Niemand hat vorher geglaubt, dass das möglich ist. Der Schlüssel liegt wohl darin, dass sofort nach dem Erfassen der Sensorwerte, neue Sollwerte an die Regler geschickt werden. Da ist dann die 50 Hz Updaterate nicht so schlimm, denn jeder Motor bekommt im 50Hz Takt die allerneuesten Messwerte.
Nur mal so als Gedankenanstoss.....

@ Kehrblech
Ich hatte es falsch verstanden, wenn der Interrupt von enm Timer ausgelöst wird passts natürlich.

Hat eigentlich mal wer versucht die Datenauswertung mit Messung Filterung und Regelung auf einem FPGA zu realisieren? Das ganze kann ja recht herrlich paralellisiert werden. Müsste dann auch eine sehr gute Regelgeschwindigkeit ohne große Totzeiten ergeben.

Zitat:

---

Alle diese Zeiten summieren sich auf und machen deine Regelung langsam.

---

Die mit Abstand längste Zeit ist eindeutig die Messung selber. Die Datenübertragung (I²C, 400000) ist im Vergleich dazu sehr kurz.
Der ATmega8 (8MHz) für die Messung ist schon voll ausgelastet, damit die Fehler beim Gyro-Integral kleiner werden. Wenn das der Mega32 (16MHz) machen müsst bleibt nicht mehr viel übrig.

Ich komme einfach nicht weiter. Der Roboter schafft es einen bestimmten Winkel zu halten, fährt aber immer in eine Richtung weg und kippt um. Um das zu verhindern, messe ich die Motorgeschwindigkeiten und versuche den Roboter auf einer Position zu halten. Dazu braucht man natürlich auch einen Regler. Und den schaffe ich einfach nicht richtig einzustellen. Im Moment wird abhängig von der Abweichung zur Sollposition eine bestimmte Geschwindigkeit vorgegeben (P-Regler). Die Abweichung von dieser Soll-Geschwindigkeit wird wiederum in einen Winkel umgewandelt (PI-Regler). Bsp:
Wenn der Roboter x cm von der Soll-Position entfernt ist, soll er mit der Geschwindigkeit P*x auf diese Position zufahren. Um diese Geschwindigkeit zu ereichen kippt er gezielt in diese Richtung, bis er schnell genug ist. Je näher er der Soll-Position kommt, desto langsamer soll er werden. Um abzubremsen kippt er leicht in die andere Richtung. Soviel zur Theorie.
Je nach Einstellung des Reglers passiert folgendes:
Entweder reagiert der Roboter nicht stark genug und fährt trotzdem in eine Richtung weg.
Oder er reagiert zu stark und schwingt sich auf, fährt also immer um die Soll-Position herum, immer etwas weiter, bis es auch da umkippt. Eine Mitteleinstellung kann ich nicht finden, es kommt mir eher so vor, dass ich einfach falsche Regler einsetze, bzw. richtige Regler mit falschen Eingangs- und Ausgangsgrößen.

Wie kann ich die Position denn sonst versuchen zu halten? Ich habe keine Idee mehr.