Kugelroboter

[kehrblech]

Hallo,

nachdem ich mich schon mal mehr oder weniger erfolgreich mit dem Thema "Balancieren" beschäftigt (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=40871) 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 (http://www.youtube.com/watch?v=eyPzZ4DNlMo) 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

[Willa]

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 (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=44744&postdays=0&postorder=asc&start=0)
Könntest du mal umschreiben wie du den Komplementärfilter aufgebaut hast? Was hast du für Filter für die Gyro- / ACCsignale? Grenzfrequenz?

[Thomas$]

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?

[kehrblech]

Den Komplementärfilter habe ich hier (http://forum.mikrokopter.de/topic-5795.html) abgeguckt. Bloß eben die Konstanten verändert bis der Winkel ganz gut stimmt.

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.

[Willa]

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

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

[Florian]

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

[kehrblech]

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.

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.

[Besserwessi]

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.

[4apaev]

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

[kehrblech]

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.

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.

[vohopri]

Hallo Jan,

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

grüsse,
Hannes

[021aet04]

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

[kehrblech]

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.

[Klingon77]

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

[ähM_Key]

@kehrblech:
Schönes Projekt!

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

[kehrblech]

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


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.



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.

[ähM_Key]

Woher weißt du eigentlich von welcher Kamera die Fotos sind?
Steht in den EXIF's.

[4apaev]

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

[kehrblech]

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.


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.

[kehrblech]

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.

[recycle]

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.

[recycle]

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.




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?

[kehrblech]

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.

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

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.

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.

[recycle]

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



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

[kehrblech]

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.

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.

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.

[4apaev]

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

[kehrblech]

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.

[Willa]

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.

[kehrblech]

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/FlightCtrl?action=AttachFile&do=get&target=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?

[damaltor]

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

[Willa]

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

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.

[kehrblech]

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.

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.

[4apaev]

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

[kehrblech]

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.

[micky_ficky]

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.

[kehrblech]

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.

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.

[Willa]

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

[micky_ficky]

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

[kehrblech]

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.

[kehrblech]

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.

[micky_ficky]

Schonmal probiert was passiert wenn de an deinen Roboter einfach oben hin n Besenstiel schraubst? Soll in Ruheposition einfach gerade nach oben zeigen.
Sieht nicht schön aus, aber für Versuchszwecke möglich.

Wenns dann funktioniert is deine Konstruktion zu instabil. Mehr Gewicht und ein höherer Schwerpunkt (bei deinen Roboterausmaßen is n Besenstiel sicher nicht nötig, da tuts auch was kleineres. war nur n Beispiel) sollten da schon viel helfen.

Ansonsten bleibt die Frage wie sehr er in eine Richtung kippt bei vorgegebener Geschwindigkeit. Bzw hast du mal versucht als Zielgeschwindigkeit nicht P*x sondern einen niedrigeren Wert zu nehmen (edit: gemeint ist hier: kleinerer Wert für P als den momentan verwendeten)?

MfG Daniel

[kehrblech]

Das Gewicht verändern ist wahrscheinlich keine gute Idee, denn dann muss der PID-Regler für den Winkel neu eingestellt werden, dass dauert erstmal.

Bzw hast du mal versucht als Zielgeschwindigkeit nicht P*x sondern einen niedrigeren Wert zu nehmen (edit: gemeint ist hier: kleinerer Wert für P als den momentan verwendeten)? P steht hier für den P-Regler und den habe ich, wie auch an allen anderen Regler-Anteilen, oft verändert. Ich glaube eher, dass das Regelmodell völlig falsch ist. Also dass ich z.B. auch noch die Beschleunigung einbauen muss. Nur weiß ich leider nicht wie.

[micky_ficky]

Was sind denn so die maximalen Winkel die dein Bot auslenken soll? Im Prinzip is das Regelmodell ja das selbe wie bei einem umgekehrten Pendel (nur is der Schwerpunkt eben viel niedriger, und damit ist das ganze deutlich instabiler), und damit da n lineares Modell funktioniert das eine optimale Regelung zulässt, darf die Auslenkung aus der Ruhelage nicht größer als 5° sein. Ist aber schon ewig her das ich das gelesen habe, keine Garantie. Aber such mal nach umgekehrtem Pendel bei www.gidf.de da dürfte es recht viel dazu geben.

Ich glaub auch nicht, dass du den Regler groß anpassen musst, wenn du die Masse n bissle größer machst. Wichtig ist ja eigentlich nur n höherer Schwerpunkt als ne größere Masse. Wenn de irgendwas rummfahren hast probiers einfach mal. Dünner Stab (z.B. von nem Drachen oder so) und obendrauf ne Kugel aus Alufolie (die dann aber auch massiv ;) ) sollte schon helfen.
Und selbst wenn de den Regler n bissle anpassen musst, besser als wenns gar net geht ;)

MfG
Daniel

[micky_ficky]

Ich hab grad nochmal darüber nachgedacht wie dein Bot regelt...

Woher weiß er das er x cm vom Ziel entfernt ist? Ist da ein absolutes Ziel gemeint, oder eher ne Position des Bots auf der Kugel?

Ich geh mal davon aus, dass ne absolute Position gemeint ist. Dann müsste man es doch so machen, dass man die Maximale stabile Bot Geschwindigkeit (also die aus der dein Bot auch sicher wieder abbremsen kann) rausfindet, und von Ruhelage auf diese Geschwindigkeit beschleunigt. Dann musst du den Beschleunigungsprozess (bzw dann auch dasselbe zum Bremsen) regeln, und sobald du auf der richtigen Geschwindigkeit bist, das ganze einfach nur halten.

Ansonsten hast du ja bei großer Entfernung zum Ziel ne sehr große Geschwindigkeit, aus der dein Bot evtl nicht mehr zurück in die GGW-Lage kommt.

MfG
Daniel

[kehrblech]

Es gibt keine Grenzgeschwindigkeit die der Roboter maximal erreichen darf, weil diese abhängig vom aktuellen Winkel ist.
Im Prinzip is das Regelmodell ja das selbe wie bei einem umgekehrten Pendel (nur is der Schwerpunkt eben viel niedriger, und damit ist das ganze deutlich instabiler), und damit da n lineares Modell funktioniert das eine optimale Regelung zulässt, darf die Auslenkung aus der Ruhelage nicht größer als 5° sein. Ist aber schon ewig her das ich das gelesen habe, keine Garantie.
Mein Roboter hat sogar einen sehr hohen Schwerpunkt. Wenn man den Roboter mit einem Invertierten Pendel vergleicht, muss man den Durchmesser des Balls als Pendellänge ansehen. Allerdings gleicht mein Roboter eine Schräglage etwas anders aus, als so ein Pendel. Auf den ersten Blick sieht es gleich aus, aber weil der Ball im Verhältnis zum Roboter eine höhere Masse hat, als das normalerweise bei Invertierten Pendeln üblich ist, verhält er sich auch etwas anders. Ein Invertiertes Pendel kann übrigens deutlich weiter als nur bis 5* ausgelenkt werden, das hängt alles vom Antrieb ab. Hätte man einen unendlich starken Antrieb, könnte man jeden Winkel <90° wieder aufrichten.

Dünner Stab (z.B. von nem Drachen oder so) und obendrauf ne Kugel aus Alufolie (die dann aber auch massiv Zwinkern ) sollte schon helfen. Eher nicht. Ein solcher Stab verbiegt sich nämlich leider beim Balancieren und schwingt mit, sodass er eher stört als nützt.

Ist da ein absolutes Ziel gemeint, oder eher ne Position des Bots auf der Kugel? Es ist die Entfernung gemeint, die der Roboter seit dem Start auf der Kugel zurückgelegt hat.

[micky_ficky]

Es gibt keine Grenzgeschwindigkeit die der Roboter maximal erreichen darf, weil diese abhängig vom aktuellen Winkel ist.

Natürlich gibts diese Grenzgeschwindigkeit. Wenn der Ball so schnell rollt, dass der Antrieb deines Bots gerade noch genausoschnell in die der Rollrichtung entgegengesetzte Richtung fahren kann (sodass der Bot sozusagen den Winkel hällt). Das ist dann deine Grenzgeschwindigkeit.
[edit] Bei näherem nachdenken ist das nicht ganz richtig, da bei gehaltenem Winkel die Kugel immernoch beschleunigt. Muss nochmal drüber nachdenken wie das dann aussieht. allerdings muss es so ne Geschwindigkeit geben, bei irgend einer Geschwindigkeit dürfte der Bot ja einfach nicht mehr nachkommen.




Im Prinzip is das Regelmodell ja das selbe wie bei einem umgekehrten Pendel (nur is der Schwerpunkt eben viel niedriger, und damit ist das ganze deutlich instabiler), und damit da n lineares Modell funktioniert das eine optimale Regelung zulässt, darf die Auslenkung aus der Ruhelage nicht größer als 5° sein. Ist aber schon ewig her das ich das gelesen habe, keine Garantie.
Mein Roboter hat sogar einen sehr hohen Schwerpunkt. Wenn man den Roboter mit einem Invertierten Pendel vergleicht, muss man den Durchmesser des Balls als Pendellänge ansehen. Allerdings gleicht mein Roboter eine Schräglage etwas anders aus, als so ein Pendel. Auf den ersten Blick sieht es gleich aus, aber weil der Ball im Verhältnis zum Roboter eine höhere Masse hat, als das normalerweise bei Invertierten Pendeln üblich ist, verhält er sich auch etwas anders. Ein Invertiertes Pendel kann übrigens deutlich weiter als nur bis 5* ausgelenkt werden, das hängt alles vom Antrieb ab. Hätte man einen unendlich starken Antrieb, könnte man jeden Winkel <90° wieder aufrichten.
Ich sag ja auch nicht, das es dann gar nicht mehr geht. Aber du bekommst für das verhalten deines Pendels nur ne Näherungsweise korrekte lineare DGL wenn der Winkel kleiner 5° ist. Und die lineare DGL brauchst du eben -soweit ich weis- um ne einfache optimale Regelung hinzubekommen.
Der Vergleich mit dem Pendel hinkt bei näherer Betrachtung tatsächlich. Ich sollte meine Ad hoc Modelle mit mehr Sorgfalt wählen ;)
[edit]Übrigens müsste doch der Schwerpunkt von der Mitte des Balls aus gerechnet werden oder? Wenns um eine Auslenkung geht ist die bezogen auf den Ballmittelpunkt.



Ist da ein absolutes Ziel gemeint, oder eher ne Position des Bots auf der Kugel? Es ist die Entfernung gemeint, die der Roboter seit dem Start auf der Kugel zurückgelegt hat.
Die Geschwindigkeit steigt also proportional zum Weg, gegebenenfalls bis unendlich? Dann is klar das er kippt.

[micky_ficky]

Hier neue Antwort da es mit dem davor nicht wirklich viel zu tun hat.

Ich hab mir mal n paar Gedanken über die grundsätzliche Funktionsweise gemacht, da mich das Thema doch zunehmend interessiert (finde den Bot einfach Klasse).

Interessant wäre zu anfangs: wieviel wiegt denn der Bot, wieviel der Ball? Wäre für die Trägheitsmomente ganz interessant.

Das Prinzip vom Balancieren und Fahren von 2-Rad Bots basierend auf dem invertierten Pendel is mir recht klar.
Ich verstehe auch das Balancieren auf der Kugel, was ja bei dir auch schon recht gut klappt.

Einzig im gezielten Bewegen der Kugel sehe ich ein prinzipielles Problem, das nichts mit Regelung oder Sensoren zu tun hat.
Es ist mir noch nicht genau gelungen das Problem das ich da habe in Worte zu fassen. Deshalb würd ich gern erstmal deine Strategie verstehen.

Zur genaueren Kommunikation hab ich dazu mal ne kleine Skizze im Anhang eingefügt.
Angenommen, du willst den Ball in positiver x-Richtung Bewegen, wie sieht dann deine Strategie für die Räder aus?
In welche Richtung Drehst du die Räder (positiver(in w-Richtung) oder negativer Drehsinn)? Der Wagen soll denke ich um einen bestimmten Winkel von der Ruhelage abgelenkt werden, um zu beschleunigen. Nach rechts oder links?
Was ist deine Strategie zum halten der Geschwindigkeit? Die zum Abbremsen?

Damit ich deine Überlegungen dann gut nachvollziehen kann, brauch ich die oben genannten Gewichte des Bots und des Balls.

Ich habe nämlich die Befürchtung das ne gezielte Bewegung mit den vorhandenen Mitteln gar nicht möglich ist. Soweit ich das bisher durchdacht habe liegt das Problem daran, dass es nicht möglich ist, über eine Achse ein direktes Drehmoment an den Ball zu bringen (so wie es beim invertierten Pendel genutzt wird), sondern eben indirekt über die Räder deines Bots.

[kehrblech]

Interessant wäre zu anfangs: wieviel wiegt denn der Bot, wieviel der Ball?Der Roboter ca. 2kg, den Ball schätze ich auf 500-600g.

Angenommen, du willst den Ball in positiver x-Richtung Bewegen, wie sieht dann deine Strategie für die Räder aus? Ich gebe dem Roboter eine bestimmte Geschwindigkeit vor, mit der er in die x-Richtung fahren soll. Er vergleicht diese Geschwindigkeit mit seiner aktuellen Geschwindigkeit, die er über Sensoren messen kann. Je nach Abweichung von der Soll-Geschwindigkeit verändert er seine Schräglage. Ist er zu langsam, kippt er etwas in Fahrtrichtung, wenn er zu schnell wird, kippt er in die andere Richtung.
Ich habe nämlich die Befürchtung das ne gezielte Bewegung mit den vorhandenen Mitteln gar nicht möglich ist. Soweit ich das bisher durchdacht habe liegt das Problem daran, dass es nicht möglich ist, über eine Achse ein direktes Drehmoment an den Ball zu bringen (so wie es beim invertierten Pendel genutzt wird), sondern eben indirekt über die Räder deines Bots.Es ist auf jeden Fall möglich den Ball gezielt in eine Richtung zu lenken, wenn man dem Roboter mit der Fernsteuerung "hilft". Dabei gebe ich nur Soll-Winkel vor. Da der Roboter sowohl seinen Winkel, als auch die Geschwindigkeit messen kann, sollte es schon möglich sein, ihn selbstständig auf einer Position zu halten. Ist halt eine Frage der Regelungstechnik.

[micky_ficky]

Das Problem das ich sehe ist die Sache mit dem Winkel...
Sobald du deinen Bot aus der Ruheposition rauskippst (soweit eben das das Drehmoment das er erzeugt groß genug ist um den Rollwiderstand zu kompensieren), beschleunigt der Ball in die Richtung in die er gekippt ist.
Da der Bot davor aber mehr oder weniger ruht, und aus dieser Lage erstmal beschleunigen muss um seinen Winkel zu ändern, wirkt davor schon ein Drehmoment (das sogar recht groß ist, da der Bot 4 mal so schwer ist wie der Ball), dieses aber genau in die entgegengesetzte Richtung, in die du eigentlich fahren möchtest. Wenn die Steuerung nun hergeht und die Geschwindigkeit misst, und feststellt das sie in die falsche Richtung geht, beschleunigt er den Bot weiter, um den Winkel so zu erhöhen das die Geschwindigkeit in die richtige Richtung geht.
Ich denke das ist hauptsächlich das Problem das du hattest, als dein Bot immer vom Ball gefallen ist.
[edit] Kleiner Fehler im Denkansatz bei mir: der Ball beschleunigt schon in die falsche Richtung, aber du hast ja deine Geschwindigkeit über nen Beschleunigungssensor im Bot bestimmt, der sich in die richtige Richtung bewegt. Muss den Punkt nochmal überdenken.

Ein weiteres Problem tritt auf wenn man das oben genannte Problem gelöst hat. sobald der Bot einen gewissen Winkel erreicht hat beschleunigt er immer weiter. Du müsstest also an dem Ball wieder nach oben fahren, so dass das Drehmoment gerade noch so den Rollwiderstand und den Luftwiderstand kompensiert, also die Beschleunigung zu 0 wird. Wenn du nun aber am Ball nach oben fährst, wirkt der Antrieb wieder ein Drehmoment aus - diesmal so, das der Ball weiter in die richtige Richtung beschleunigt, also unter Umständen zu schnell wird.

Ich hab mal versucht ein Bewegungsmodell dafür zu erstellen, merke aber das meine Kenntnisse in Theoretischer Physik etwas eingerostet sind.

Ich denke nun auch das die gezielte Bewegung des Bots möglich ist, aber auch recht schwierig, und wahrscheinlich nicht mit einem normalen PID Regler möglich.

Hoffe das da jetzt n paar halbwegs brauchbare Ideen dabei waren, evtl hilfts dir ja. Genaueres wenn ich mal wieder zuviel Freizeit hab ;)

MfG
Daniel

[kehrblech]

der Ball beschleunigt schon in die falsche Richtung, aber du hast ja deine Geschwindigkeit über nen Beschleunigungssensor im Bot bestimmt, der sich in die richtige Richtung bewegt.
Nein, ich messe die Geschwindigkeit der Motoren mit Inkrementalsensoren, mit Beschleunigungssensoren würde das durch die doppelte Ableitung recht schnell sehr ungenau werden.
Die Richtung stimmt schon. Ich muss aber nochmal die Lochscheiben überarbeiten, da haben manche Löcher nicht den gleichen Abstand, sodass die gemessene Geschwindigkeit nicht gerade konstant ist. Wer hat eine Idee, wie ich die gleichmäßig in die Scheibe bekomme? Ich habe leider kein Spezial-Werkzeug, nur normale Bohrer, Sägen, ...

[jeffrey]

Hallo,
funktioniert das ganze denn für kleine geschwindigkeiten? dann wäre es doch möglich anstatt nen p-regler einfach nen 3 punktregler zu nehemen. sprich bei abweichung von der sollposition soll der bot mit konstanter geschwindigkeit in richtung der soll posiion fahren.
außerdem denke ich, dass der roboter immer versuchen sollte oben in der mitte auf dem ball zu bleiben, und nicht in einem konstantem winkel, weil dort kann er ja nur kräfte gegegn die schwerkraft aufbringen, wenn er den ball beschleunigt.
mfg jeffrey

[micky_ficky]

Nein, ich messe die Geschwindigkeit der Motoren mit Inkrementalsensoren, mit Beschleunigungssensoren würde das durch die doppelte Ableitung recht schnell sehr ungenau werden.
Die Richtung stimmt schon.
Das Problem über die Bestimmung durch die Inkrementalgeber is halt, dass du damit die Geschwindigkeit des Bots hast, diese aber nicht unbedingt mit der des Balls übereinstimmen muss. Btw, du musst einmal integrieren und nicht 2 mal Ableiten.
Aber nochmal zur Richtung: wenn du aus der Ruhelage raus beschleunigen willst, dürfte die Trägheit des Bots größer sein als die des Balls => der Ball rollt nach hinten (in die falsche Richtung). Sobald der Bot nen Winkel erreicht hat, aus dem herraus er den Ball beschleunigt, passt die Sache. Dann musst ihn solang auf nem vernünftigen Winkel halten bis der Ball fast die gewünschte Geschwindigkeit hat, und den Bot dann wieder hoch in die Position bringen die ihn gerade den Rollwiderstand kompensieren lässt (was den Ball noch mal weiter beschleunigt).


Ich muss aber nochmal die Lochscheiben überarbeiten, da haben manche Löcher nicht den gleichen Abstand, sodass die gemessene Geschwindigkeit nicht gerade konstant ist. Wer hat eine Idee, wie ich die gleichmäßig in die Scheibe bekomme? Ich habe leider kein Spezial-Werkzeug, nur normale Bohrer, Sägen, ...
Kommt drauf an was für ne Präzision du gerne hättest. Ansonsten würd ich die Metallscheibe durch eine aus Plexiglas (weiß net genau wie dein Sensor arbeitet, eben aus nem Material das durchsichtig für deinen Sensor ist) ersetzen, und dann am PC ne Folie machen, die aus nem schwarzen Kreis mit weißen Strichen in Konstanten Winkelabständen besteht, und die aufkleben. Damit müsstest ne vernünftige Präzision hinbekommen.

[kehrblech]

Btw, du musst einmal integrieren und nicht 2 mal Ableiten. Hast recht, da habe ich nicht nachgedacht.
Kommt drauf an was für ne Präzision du gerne hättest. Ansonsten würd ich die Metallscheibe durch eine aus Plexiglas (weiß net genau wie dein Sensor arbeitet, eben aus nem Material das durchsichtig für deinen Sensor ist) ersetzen, und dann am PC ne Folie machen, die aus nem schwarzen Kreis mit weißen Strichen in Konstanten Winkelabständen besteht, und die aufkleben. Damit müsstest ne vernünftige Präzision hinbekommen.Super Idee! Die Präzision reicht locker.

[micky_ficky]

Übrigens, wollte ich eigentlich schon früher mal schreiben:
Hast mal drüber nachgedacht deinen Ball leer zu machen und dann mit z.B. Bauschaum wieder "aufzupumpen"? Dann hättest das hüpfen weg, und die höhere Masse könnte sich auch sinnvoll auf die Steuerung des Bots auswirken.

MfG
Daniel

[kehrblech]

Mmh, Bauschaum? War das nicht das Zeug, was sich wahnsinnig ausdehnt, wenn es trocknet? Nicht dass dann der Ball platzt :-s

Ich habe jetzt neue "Lochscheiben" am Roboter. Eigentlich haben die gar keine Löcher mehr, sondern nur noch Striche. Dadurch kann der Roboter jetzt genauer seine Geschwindigkeit messen. Das Balancieren ging schon etwas besser, aber jetzt sind erstmal wieder die Akkus leer ](*,)

[micky_ficky]

Bauschaum war ein Beispiel, keine Ahnung wie der sich beim austrocknen verhällt. Gegebenenfalls etwas weniger rein. Allerdings ist mir grad noch eingefallen, dass der wahrscheinlich eh net austrocknet, mangels Luftzufuhr. Aber n Befüllen mit irgend nem Schaum der fest wird wär sicherlich gut. Evtl weiß da ja einer was geeignetes... :)

MfG
Daniel

[kehrblech]

So, ich habe noch einen kleinen Fehler im Programm gefunden. Ich habe den D-Anteil an zweimal berechnet, mit verschiedenen Werten. Dabei wurde der richtige Wert vom falschen überschrieben. Kleiner Fehler, große Wirkung: Der Roboter balanciert viel ruhiger. Er schwingt sich zwar immer noch auf, aber schon viel langsamer.

[Bammel]

wegen dem bauschaum. wenn man zweikomponenten schaum nimmt trocknet der auch ohne luft aus. man muss nur vorher das volumen der balls errechnen udn dann die dehnung des schaumes beachten und dnan die menge reinfüllen...

[Waldichecker]

Hey,
wollte auch mal das mit den Balencieren bauen. Bin aber noch nicht dazu gekommen :cheesy:

Gruß

Siehe links!

[kehrblech]

Hallo,

es gibt wieder Fortschritte. Der Roboter kann zwar noch nicht besser balancieren, aber ich lasse ihn währenddessen alle wichtigen Daten (Winkel, Position, Geschwindigkeit,...) auf einer SD-Karte speichern. Nach dem Balancieren kann ich dann genau sehen, was er wann gemacht hat.

Jetzt versuche ich den Positionsregler neu zu entwerfen. Ich lasse dazu den Roboter balancieren und steuere ihn mit der Fernsteuerung so, dass er auf einer Stelle bleibt. Mit der Fernsteuerung gebe ich einen Soll-Winkel vor.
Auch dieser Soll-Winkel wird auf der Karte gespeichert. Ich habe also sowohl die Eingangssignale (Winkel, Position, Geschwindigkeit) des Positionsreglers, als auch das Ausgangssignal (Soll-Winkel), aber es fehlt der Regler selber (ICH bin der Regler, indem ich den Soll-Winkel mit der Fernsteuerung vorgebe). Aber wie kann ich den Regler entwerfen? Es geht nicht darum die Reglerparameter einzustellen (da habe ich schon so viel probiert, ich glaube nicht, dass es eine gut funktionierende Einstellung gibt), sondern darum einen völlig anderen Reglertyp zu benutzen. Wahrscheinlich weiterhin ein PID-Regler, aber vielleicht mit anderen Eingangssignalen. Oder gibt es noch andere Reglerarten, die man für so eine Aufgabe gut benutzen könnte?

[oberallgeier]

... gibt es noch andere Reglerarten, die man für so eine Aufgabe gut benutzen könnte?Ein Wundermittel (angeblich) gibt es für komplexe Regelungsaufgaben: der Beobachter. Was ist das? Neben einem digitalen Regler normaler Bauart programmiert man ein Modell der Regelstrecke mit ihren physikalischen Eigenheiten (Masse, Reibung etc). Dieser virtuelle Aufbau bewegt sich erstmal wie der reale Aufbau und wird von einem weiteren Regler geregelt. Eventuelle Unstetigkeiten, Unstimmigkeiten, Nichtlinearitäten und all so ein Zeugs lassen sich nun durch Vergleich der virtuellen mit der realen Maschine dazu verwenden, die Regelungsparameter in Echtzeit zu verstellen. Anwendung z.B. bei komplexen Industrierobotern, wo z.B. unterschiedliche Auslenkungen des Roboterarms das System in seinen kinetischen Eigenschaften drastisch verändern.

Das klingt nicht nur nach ziemlich viel Rechenaufwand (und elend viel Programmiererei) - das ist es auch. Für Controller also absolut garnix. Der Nutzen ist nicht immer gegeben: meist sind die "einfachen" Algorithmen tolerant genug.

[kehrblech]

Ich habe es geschafft einen Regler zu entwerfen, der ziemlich gut passt, jedenfalls solange der Roboter langsam bleibt. Wenn er jetzt balanciert bleibt er relativ lange auf einer Stelle, sobald er aber etwas schneller wird, passt der Regler nicht mehr und der Roboter kippt um.
Ich habe jetzt aber leider noch ein ganz anderes Problem:
Die Motortreiber fallen manchmal aus. Das ist nicht völlig neu, aber bis jetzt kam es nur vereinzelt vor. Oft läuft einfach ein Motor nicht, manchmal auch alle nicht. Meistens tritt dieser Fehler mitten beim Balancieren auf, selten auch schon von Anfang an. Ich vermute, dass es an den hohen Strömen liegt, besonders, wenn die Motoren plötzlich umgepolt werden.
Bis jetzt habe ich ausprobiert:
- Reset-Pin direkt auf VCC
- 100nF und 47µF an jeden Motortreiber
- Watchdog aktiviert
- Brown-Out aktiviert

Das hat leider alles nicht geholfen. Es kommt mir auch nicht so vor, als ob der µC einfach resettet. Meistens läuft die Kommunikation über I²C weiter, aber der Motor wird nicht mehr angesteuert. Ich glaube eher, dass z.B. die PWM-Erzeugung aufhört oder manche Pins nicht mehr als Ausgang konfiguriert sind.
Sobald länger als 250ms keine Daten mehr an den Motortreiber gesendet werden, führt der Watchdog einen Reset durch, danach geht wieder alles.
Der µC ist leider an einer schlechten Stelle im Layout. Auf beiden Seiten neben ihm befinden sich die Mosfets für die Motoransteuerung. Kann es sein, dass diese ihn stören?

[kehrblech]

Die Motorausfälle kommen nicht mehr vor. Ich habe einfach etwas Alufolie über den Controller gelegt, natürlich mit Papier dazwischen, damit es keinen Kurzschluß gibt. Danach traten die Störungen nur noch selten auf. Seit ich die I²C-Taktfrquenz von 400000 auf 100000Hz gesenkt habe, hatte ich noch keine Störung.

Außerdem habe ich jetzt neue Gyros. Statt den ENC03R benutze ich jetzt die ADXRS610. Verdammt teuer...
Wenn man sich das Signal anguckt, kann man sehen, dass fast kein Drift mehr vorhanden ist. Beim Balancieren habe ich aber noch keinen Unterschied bemerkt.

[the_muck]

Moin, sehr interessant etwas ähnliches wollte ich auch mal umsetzten, ich habe hier noch 2 ADXRS614 und 2 AD22285 rum liegen die ich mal geschenkt bekommen habe, leider noch nicht auf einer Platine :D. Mal schauen wann ich dazu komme es um zu setzen.

Brauch aber zur zeit eine Idee wie ich sie auch eine Platine bekomme ;) der ADXRS614 sollte doch aber mit +/- 50 °/s für so eine Balancier Anwendung geeignet sein ?!

[Rabenauge]

Interessante Sache, irgendwo habe ich neulich nen einrädrigen Roboter gesehen, der auch gezielt fahren konnte (Kurven bzw. in vorgegebene Richtungen), das mit dem Ball ist ja ähnlich.
Schick...
Übrigens: du könntest einfach den Luftdruck im Ball vorsichtig etwas erhöhen, dann wird der Ball härter- er wird besser rollen (reibungsärmer), aber sich dabei weniger aufschaukeln lassen.
Wäre nen Versuch wert und ist weniger Aufwand als die Schaum-Geschichten.
Wasser einfüllen würde ich auf keinen Fall: das schaukelt sich nämlich auf und du hast _noch_ mehr Probleme.

[kehrblech]

der ADXRS614 sollte doch aber mit +/- 50 °/s für so eine Balancier Anwendung geeignet sein ?!Keine Ahnung, beim AXRS610 wird jedenfalls lange nicht der gesamte Messbereich von +- 300°/s ausgenutzt.

Übrigens: du könntest einfach den Luftdruck im Ball vorsichtig etwas erhöhenDas ist nicht mehr nötig. Der Roboter kann jetzt alleine viele Minuten balancieren. Dabei bleibt er sogar sehr genau auf einer Stelle.
Als nächstes versuche ich gerade den Roboter Hindernissen ausweichen zu lassen. Dazu hat er drei Abstandssensoren, die mit Servos geschwenkt werden. Der Roboter erstellt damit eine "Karte" seiner Umgebung und sucht die Stelle, die am weitesten von allen Hindernissen entfernt ist. Soweit funktioniert es auch schon. Der Roboter hat eine Richtungsangabe und weiß auch wie weit er in diese Richtung fahren soll, nur das Fahren selber schafft er noch nicht (je nach Einstellung fährt er viel zu weit oder fährt erst gar nicht los).

Gruß,
Jan

[Richard]

Bauschaum war ein Beispiel, keine Ahnung wie der sich beim austrocknen verhällt. Gegebenenfalls etwas weniger rein. Allerdings ist mir grad noch eingefallen, dass der wahrscheinlich eh net austrocknet, mangels Luftzufuhr. Aber n Befüllen mit irgend nem Schaum der fest wird wär sicherlich gut. Evtl weiß da ja einer was geeignetes... :)

MfG
Daniel

Bauschaum ist schon O.K den giebt es in 2k = selbsthärtend.
Das geht sehr schnell. Da man ja zum Befllen ein kleines Loch
in den ball machen muß, kann der beim aufschräumen überflussige
Schaum ja wieder austreten. Deb Ball dabei über eine Mülltüte halten
sonst gibt das ne riesen Sauererei! Nach dem Härten einfach abschneiden
und glatt Schleifen. :-)

Gruß Richard

[Richard]

In einen anderen Threat hat jemande diese Teile einfach
(in) die Platine geklebt und dann mit einzelnen Adern von
Entlötlitze die Pad's an Leiterbahnen angelötet. :-)

Gruß Richard

[Thomas$]

das problem mit dem fahren würd ich mal anders probiern schubs den ball mal leicht an dann regelt er ja sich wieder und diesen effekt kannst du dann nutzen. du verlagerst mit einem servo das gleichgewicht und der ball kippt um das zu komppensieren balangsiert er und damit sollte er fahren

[the_muck]

In einen anderen Threat hat jemande diese Teile einfach
(in) die Platine geklebt und dann mit einzelnen Adern von
Entlötlitze die Pad's an Leiterbahnen angelötet. :-)

Gruß Richard

bei den Beschleunigungssensor habe ich das noch hin bekommen :D, aber am Gyro wird das ein Spaß ;).

Na ja das dauert alles noch, ich hatte gestern Abend die Idee einen kleinen Roboter auf meinem Jonglierball fahren zu lassen und habe einfach mal Google an geschmissen und bin hier drüber gestolpert :)...

lg

[oberallgeier]

... Bauschaum ... in 2k = selbsthärtend. Das geht sehr schnell ...Bei "2k" und "sehr schnell" denke ich gleich an unterschiedliche Einfüll- sprich Reaktionszeiten, der Ball wird ja nicht PLÖTZLICH gefüllt. Gibt das nicht ein prächtiges Ei? Weil die Ballhülle ja nicht aus Beton oder gebrannten Ziegeln besteht.

[Richard]

Ich denke das wird gut gehen, der Schaum härtet ja nicht in
Sekunden aus, bleibt also einige (ca 10 Minuten)recht weich.

Es gibt den auch als Schaumkleber, damit werden Dämmplatten
an Hauswänden geklebt. Dieser Schaum dehnt sich NICHT aus,
damit muß der Ball dann (druck (?)) vollgeschäumt werden.
Ob das klappt (?), ich würde eher einen sich ausdehnenden
Schaum verwenden damit die Kogel auch sauber "aufgepummt" wird.


Gruß Richard

[the_muck]

habe die anleitung gefunden für ein Adapterbord

http://www.mikrokopter.de/ucwiki/ADXRS610 ganz unten

[Ceos]

zum befüllen wären 2 löcher wohl besser, eines "unten" zum einfüllen (auch von unten, der schwerkraft halber) und eines "oben" für den den luftauslass ...

das problem bei bauschaum ist doch eher, dass er ziemlich schnell eine feste haut ausbildet und wenn man dann von oben einfüllt, stapelt man würste übereinander zwischen denen vll. noch ne handvoll luftlöcher überbleiben ...

das obere loch dient nur zum entwichen der luft im ball, wenn der schaumstoff oben angekommen ist, wird er mit hocher wahrscheinlichkeit das loch verstopfen und da man unten immer frischen schaum einfüllt wird der einfach herausquellen

[Richard]

Hmm, ich arbeite in der Sicherheitstechnik und wenn mal wieder
so ein paar böse Buben ne Sirene ausgeschäumt haben, ist die
randvoll. Großartig "Luftblasen" bleiben da nicht! Außerdem dürft
das in diesem Fall egal sein, es soll ja überwiegend nur das Federn
b.z.w. Springen vom Ball verhindert werden. Einfach ausprobieren
würde ich sagen, son Kinder Kunststoff Ball kostet nicht die Welt.
2K Bauschaum kann aber etwas Kosten. :-(

Gruß Richard

[josua]

dein bot ist echt der hammer. ich kann zwar nicht wirklich mitreden, aber tolle leistung!!! :)

gruß josua

[rennsocke]

Um das Hüpfen zu ferhindern kann man auch eine Bowlingkugel(oder Bowlingball?) benutzen die sind nur etwas teurer

[kehrblech]

Hallo,

ja, mit einer Bowlingkugel ginge es sicher besser. Dieser (https://www.roboternetz.de/phpBB2/viewtopic.php?p=500177) Roboter zeigt ja, dass es damit sehr gut geht (übrigens sehr interessant, dass der Roboter die gleiche Mechanik verwendet wie meiner. Bis jetzt habe ich immer nur welche mit dem "Inverse Mouse-Ball Drive" gefunden). Allerdings habe ich dann wieder das Problem, dass ich weniger Reibung habe, die Räder würden durchdrehen. Sicher kann man da andere Räder benutzen, die mehr Reibung erzeugen würden.
Aber warum der ganze Aufwand? Es funktioniert mit meinem elastischen Ball jetzt sehr gut. Ich kann sogar ein Wasserglas oder einen Tischtennisball auf dem Roboter balancieren.

Viele Grüße,
Jan

[bronsco]

Hallo zusammen!

@kehrblech: wirklich cool was du da auf die beine - bzw. ball :) - gestellt hast...

ich wollte kein neues thema aufmachen, weil ich denke, dass das ganz gut hier rein passt. ich bin zurzeit noch student und beschäftige mich in einer studienarbeit mit der modellierung und regelung eines solchen balancierenden roboters und hätte da jetzt ein paar fragen:

1) Woher weiß der roboter, was seine nullposition ist? sprich wenn ich ihn auslenke, damit er wieder zum "ursprung" zurückfährt

2) ich habe mittlerweile sehr oft von der drift der gyrosensoren gelesen und das man deswegen (?) zusätzlich die acc noch benötigt. mich würde interessieren, woher diese drift kommt - eine erklärung hab ich nämlich nirgendwo gefunden - und warum das nicht bei den acc auch möglich ist?

3) woher wusstest du, wie stark deine motoren sein müssen?

Danke schonmal!

viele grüße

[kehrblech]

Hallo,

1) Mein Roboter hat Lichtschranken an jedem Rad, mit denen er messen kann, wie sich das Rad bewegt. Damit sollte es möglich sein zum Ursprung zurückzufahren. Ich werte aber gar nicht die Position des Roboters aus. Ich benutze die Lichtschranken nur, um die Geschwindigkeit der Räder zu kontrollieren und eventuell zu korrigieren. Warum mein Roboter trotzdem auf einer Stelle bleibt kann ich nicht erklären, dazu kenne ich mich nicht gut genug mit der Regelungstechnik aus. Der Winkel von meinem Roboter wird nur mit einem PID-Regler gehalten. Zusätzlich werden die Motoren noch mit PI-Reglern auf der richtigen Geschwindigkeit gehalten. Wenn jetzt ein "falscher" Sollwinkel eingestellt ist, der Roboter also nicht versucht exakt gerade, sondern leicht schräg zu stehen, müsste er doch eigentlich immer weiter in eine Richtung wegfahren? Er fährt zwar wirklich los, hält aber seltsamerweise relativ schnell wieder an.

2) Soweit ich weiß, entsteht der Drift hauptsächlich durch Temperaturänderungen. Das ist aber je nach Gyro stark unterschiedlich. Die, die ich jetzt benutze (ADXRS610), haben kaum Drift. Ein Beschleunigungssensor braucht man trotzdem, denn der Gyro liefert nur Winkelgeschwindigkeiten. Wenn die integriert werden, um den Winkel zu berechnen, werden Messfehler aufsummiert, sodass der Winkel schon nach wenigen Sekunden nicht mehr stimmt. Um das auszugleichen benutzt man einen Beschleunigungssensor.

3) Ich wusste es selber auch nicht so genau. Ich hatte vorher schon versucht einen Kugelroboter aus fischertechnik zu bauen, das hat aber nicht geklappt, weil die Motoren zu schwach waren. Ich wollte deshalb kein Risiko eingehen und habe viel zu starke Motoren in diesem Roboter benutzt.

Kannst du mir, wenn du fertig bist, deine Ergebnisse schicken? Ich habe bis jetzt immer nur durch Ausprobieren die Regelung entworfen, ich würde aber gerne wissen, wie es richtig geht.

Viele Grüße,
Jan

[bronsco]

1) das hab ich mir so auch schon gedacht, dass man über die messung der drehzahl der wheels die position bestimmt und so den roboter an ort und stelle hält. so spontan würd ich auch sagen, dass er, um einen sollwinkel ungleich null zu halten, bis ins undendliche fahren müsste...

2) heißt das, dass man einen beschleunigungssensor zur winkelmessung und die gyros wegen der winkelgeschwindigkeit braucht?

ich hab zwar erst mit der arbeit angefangen, kann dir aber dann bei gegebener zeit schon ergebnisse schicken. wird aber einige zeit dauern, da der roboter frühestens ende september fertig sein wird...