Hi,
ich sehe das auch noch als Konstruktives scheitern.
Kann jemand(uli?) was dazu sagen warum man encoder am Rad Braucht?
Und gibt es ein Pendant zum rb35 mit encoder?
(für mich ist der rb35 so gut weil er über einen l293 steuerbar ist und mit verschiedenen Gertrieben liederbar ist und es noch direkt Montagewinkel dazu gibt).
Und dann nochwas essentielles....ich habe den Akku(und damit das Hauptgewicht)möglichts weit unten angebracht für einen tiefen Schwerpunkt.
Ist ein hoher/tiefer schwerpunkt eher gut oder schlecht für die Stabilität?
@Manfred:
Hallo Manfred, mehr Daten habe ich für die Simulation nicht gebraucht. Die Hauptarbeit liegt allerdings in der Aufstellung der DGLen des Systems.
Ich wollte eigentlich über Ostern einen Artikel dazu schreiben -aber wie das so ist.....
Ach übrigens: Herzlichen Glückwunsch zum Geburtstag nachträglich.
@Involut:
Hallo Involut,
die Inkrementalgeber brauchst Du nur, wenn der Robbi auf der Stelle balancieren soll. Ohne Rückkopplung der Weginformation wandert er sonst in der Gegend herum, was aber nicht weiter schlimm ist. (Fürs erste).
Der Akku muß nach oben. Schau Dir das Bild von meinem UCBalBot im Album an. Oder besser, nimm Dir einen Besen und probier mal diesen zu balancieren.
Je höher der Schwerpunkt, um so langsamer das System .
Hi,
wenn der Akku oben ist ist das ganze schon wesentlich "weniger instabil".
Gibt es eine Doku zum UCBalBot?
Und welchen Algorhytmus hast dum Regeln benutzt?
eine vollständige Doku kommt demnächst. Vorab ein paar Bilder in meiner gallery.
Der Regler ist ein klassischer digitaler Zustandsregler mit dem ich die gemessenen (bzw geschätzten) Zustandsgrößen für den Winkel phi, die Winkelgeschwindigkeit phi_dot, den Weg x und die Geschwindigkeit x_dot entsprechend gewichtet zurückführe.
Hallo Jungs!
Verfolge eure Diskussion jetzt schon länger, weil ich auch gerade informationen zum balancierenden 2-rad-roboter sammle! Eure Überlegungen mit dem Pendel und dem Schlauch mit den Drucksensoren sind garnicht schlecht! Es gibt da nämlich fertige Lösungen, die ganau das machen. Man kommt insgesamt billiger weg, als würde man ein Gyroskop und ein Accelerometer benutzen, wegen der umständlichen Zusatzbeschaltung.
Gebt doch mal bei google "Inclinometer" ein. Das ist quasi ein Neigungsmesser, der aber im gegensatz zum Gyro keine Drift hat! Es gibt eine Lösung, den "NS9" von GEMAC, die quasi ein Pendel darstellt. Allerdings Mini. Kostet 109,-€. Da gibts auch ein schönes Evaluation-Board zu! Ne andere Lösung ist eine flüssigkeitsbefüllte Röhre, auf beiden Seiten quasi hochgebogen. Dann wird kapazitiv die Füllhöhe beider Seiten gemessen und verglichen! Dann bekommt man nen Winkel raus. Hab da mal geguckt, gibts ab ~40$. Ist doch eigentlich besser als Gyro+Accelerometer+Kalman-Filter, oder!? So hat man ein Bauteil, das einem -je nach dem- parallel oder seriell (oder analog) direkt den Winkel ausgibt!?
Sagt mir mal bitte beischeid, was Ihr von der Lösung haltet!
Der naheligende Verdacht ist der, dass ein Sensor nach dem Prinzip schwingt oder zu langsam ist.
Dämpfen kann man ihn, aber nach der Kurve sieht es so aus, als könnte man schon nach 200ms ablesen, dass der Roboter umgefallen ist.
Gibt es denn Erfahrung mit der Reaktionsgeschwindigkeit für den vorliegenden Fall? Mir schein er etwas zu langsam. Zur Not kann man natülich einen Fächer oder einen Besen an den Roboter montieren, aber für 109Eu wäre das dann schon eine deutliche Einschränkung.
Ich lasse mich aber auch gerne überzeugen.
Manfred
Zitieren
Berechtigungen
Lesezeichen