ThomasKl Geschrieben May 9, 2012 at 19:55 Geschrieben May 9, 2012 at 19:55 Das Szenario lässt sich als Regelkreis beschreiben. Wenn man oft genug die Geschwindigkeit ändern kann, wird vermutlich ein P (roportional) Regler, wie von Plenz beschrieben reichen. Also die neue Geschwindigkeit wird proportional zur Abweichung des tatsächlichen Wertes vom Sollwert berechnet. Das Problem hierbei ist, dass man immer dem Sollwert hinterherläuft und ihn "nie" erreicht, aber unendlich nahe kommt :-). Ansonsten wird man die neu berechnete Geschwindigkeit zusätzlich zu diesem Proprotionalteil nochmal abhängig von der D(ifferenz) eines tatsächlichen Wertes zu seinem vorhergehenden erhöhen. Die Erhöhung soll im Prinzip die erwartete Bewegung ausgleichen, sodass man direkt zum Sollwert kommt und ohne sich ihm ständig von einer Seite zu nähern. Zitieren
Plenz Geschrieben May 10, 2012 at 14:54 Autor Geschrieben May 10, 2012 at 14:54 Das Szenario lässt sich als Regelkreis beschreiben. Korrekt erkannt, das Ding regelt sich selbst. Ebenso korrekt ist die Sache mit der Abweichung. Ich gehe davon aus, dass die interne Stabilisierung der Kamera diesen Rest ausgleicht. Zitieren
Nic Geschrieben May 10, 2012 at 15:15 Geschrieben May 10, 2012 at 15:15 Verstehe, kann mir aber jemand erklären auf welches Bezugssystem die RPY-Winkel ermittelt werden ? Worauf referenziert sich der IMU, jetzt ist alles im Lot und er ist waagerecht ausgerichtet ? Zitieren
ThomasKl Geschrieben May 10, 2012 at 15:31 Geschrieben May 10, 2012 at 15:31 Soweit ich das verstanden habe kommt die absolute Referenz vom Magnetfeld der Erde, dessen Richtungsvektor wird beim Kalibrieren gespeichert. Zitieren
Nic Geschrieben May 10, 2012 at 16:03 Geschrieben May 10, 2012 at 16:03 Aha, das habe ich mir auch schon gedacht, aber dann wird er ev. durch die Motoren und deren Magnetfeld, wenn diese unterschiedlich angesteuert werden, Einfluß auf den Magnetometer bekommen !? http://www.tinkerforge.com/doc/Hardware/Bricks/IMU_Brick.html#imu-calibration Zitieren
ThomasKl Geschrieben May 10, 2012 at 18:44 Geschrieben May 10, 2012 at 18:44 wie beschrieben muss man dass wohl im fertigen Aufbau ausprobieren, eventuell lässt sich das IMU auch etwas entfernt von den Motoren anbringen. Zitieren
Plenz Geschrieben May 18, 2012 at 12:31 Autor Geschrieben May 18, 2012 at 12:31 wie beschrieben muss man dass wohl im fertigen Aufbau ausprobieren, eventuell lässt sich das IMU auch etwas entfernt von den Motoren anbringen. Ich fürchte, das wäre zu umständlich. Die Motoren beeinflussen zumindest den Kompass meines Smartphones schon bei einer Entfernung von 20 cm. Ich hoffe, ich kriege es hin, nur die Kreiselfunktionen des IMU auszuwerten und die Magnetfeldfunktionen zu ignorieren. Zitieren
Nic Geschrieben May 21, 2012 at 10:17 Geschrieben May 21, 2012 at 10:17 Die RPY Ergebnisse orientieren sich nach dem NS-Magnetfeld der erde, wonach soll sonst die Winkelabweichung sich beziehen. Um das Kalibrieren kommt man nicht herum. Interessant wirds wenn unterschiedl. Drehzahlen gefahren werden, dann dürfte die Kalibrierung ev. verschieden sein. Zitieren
Plenz Geschrieben June 9, 2012 at 16:51 Autor Geschrieben June 9, 2012 at 16:51 Nun, wo der IMU-Brick dank der dafür notwendigen Formeln endlich die richtigen Verdrehungswinkel hergibt, ging es an die Praxis. Ich musste feststellen, dass die Getriebemotoren ziemlich träge sind. Dies besserte sich ganz erheblich, nachdem ich die Impulsfreuqenz des DC-Bricks schrittweise von 15.000 Hz auf 500 Hz gesenkt hatte. Klar, man hört jetzt ein ständiges Singen, aber dafür haben die Motoren jetzt richtig Power. Noch tiefer zu gehen hat allerdings wenig Nutzen, bei 200 Hz traten spürbare Vibrationen auf. Und trotzdem ist das alles immer noch viel zu langsam. Und wenn ich die Geschwindigkeit der Motoren erhöhe (also dass sie noch schneller und entschiedener auf Verdrehungen reagieren), dann fangen sie an, sich aufzuschaukeln. Und wenn ich dann bei Conrad sehe, dass es Servos gibt, die eine 45°-Drehung in 1/10 Sekunde schaffen (die kosten aber auch entsprechend), dann denke ich, ich sollte das alles noch mal völlig umstricken. Zitieren
Plenz Geschrieben June 18, 2012 at 19:28 Autor Geschrieben June 18, 2012 at 19:28 Am Wochenende habe ich ein komplett neues Gerät gebaut, diesmal mit Servos. Es funktioniert auch schon im Prinzip, aber die Umrechnung von Winkeln aus dem IMU-Brick in Impulse für die Servos (wie an anderer Stelle erwähnt, "missbrauche" ich dafür meine DC-Bricks) lässt noch zu wünschen übrig. Beim Experimentieren und Justieren stellte ich fest, dass der eine Servo sehr heiß geworden war - und anscheinend hat das Getriebe eine Macke abgekriegt. Also muss ich das Projekt erst mal auf Eis legen, bis ich einen neuen Servo habe. Hier ein aktuelles Bild: Zitieren
Plenz Geschrieben March 2, 2013 at 21:18 Autor Geschrieben March 2, 2013 at 21:18 Der letze Stand der Entwicklung: stärkere Servos eingebaut, neu programmiert mit VB .Net statt Python. Hier eine ohne großen Aufwand. Zitieren
AuronX Geschrieben March 4, 2013 at 09:52 Geschrieben March 4, 2013 at 09:52 Das ist ja ein grandios gutes Ergebnis Hätte nicht gedacht, dass das so gut geht. Zitieren
FabianB Geschrieben March 4, 2013 at 10:13 Geschrieben March 4, 2013 at 10:13 Wow ich muss sagen, ich hätte diese schnelle Reaktionszeit nicht erwartet. Natürlich wackelt das Bild ein kleines Bisschen, aber die Verzögerung der Ausgleichsbewegung ist im Spiegelbild nicht zu sehen. Zitieren
Plenz Geschrieben March 4, 2013 at 11:59 Autor Geschrieben March 4, 2013 at 11:59 Danke für die Blumen Ich finde allerdings, dass einem beim Zuschauen immer noch reichlich schwindelig wird, aber das wird vielleicht besser, wenn das Motiv (Boot und Landschaft) weiter weg von der Kamera ist. Jetzt muss erst mal ein Praxistest gemacht werden. Das kann aber noch dauern, bis ich eine Halterung für mein Boot gebaut habe und bis draußen Segelwetter ist... Zitieren
AuronX Geschrieben March 4, 2013 at 13:19 Geschrieben March 4, 2013 at 13:19 Na schlecht wird einem meiner Ansicht nach, weil sich die Höhe der Kamera ändert. Du korrigierst ja nur Roll und Pitch, aber keine Verschiebung der Kamera... Zitieren
Plenz Geschrieben March 4, 2013 at 15:09 Autor Geschrieben March 4, 2013 at 15:09 Na schlecht wird einem meiner Ansicht nach, weil sich die Höhe der Kamera ändert. Du korrigierst ja nur Roll und Pitch, aber keine Verschiebung der Kamera... Das juckt mich am allerwenigsten, denn je weiter das Motiv entfernt ist, desto weniger hat das eine Auswirkung aufs Bild. Eine Korrektur würde einen gigantischen Aufwand bedeuten, denn diese Apparatur soll hintem am Boot an einem ca. 2 m langen Arm befestigt werden, und wenn es ordentlich Wellen gibt, dann kann sich die Kamera schon um einen halben Meter auf und ab bewegen. Außerdem würde eine Korrktur der Bewegung erst dann wirklich eine Verbesserung des Bildes bringen, wenn Roll und Pitch restlos ausgeglichen wären - was ich inzwischen für illusorisch halte, zumindest für den Aufwand, den ich bereit bin zu treiben. Zitieren
AuronX Geschrieben March 4, 2013 at 18:00 Geschrieben March 4, 2013 at 18:00 Wollte nicht sagen, dass du das tun solltest ^^ War mehr als Erklärung gedacht warum dir bei den Testbildern schwindelig werden könnte Zitieren
Plenz Geschrieben September 21, 2014 at 09:29 Autor Geschrieben September 21, 2014 at 09:29 So, liebe Leute... hiermit erkläre ich dieses Projekt für beendet. Die Ergebnisse waren unbefriedigend, und das bei einem zu großen Aufwand, denn es gehört ja immer noch ein Notebook dazu, das die Bricks und Bricklets steuert. Inzwischen stellte ich fest, dass ich dabei war, das Rad zum zweiten Mal zu erfinden. In der Quadrokopter-Szene gibt es längst fertige und hochentwickelte Controller für eben diese Aufgabe. Es gibt sogar Controller mit zwei IMUs, und die Steuerbausteine für Brushlessmotoren sind auch gleich dabei. Das Notebook braucht man nur noch einmalig zum Einrichten und Kalibrieren. Auf dieser Seite habe ich eine (englische) Beschreibung und ein Demo-Video. Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.