Sensor für balancierenden 2-Rad Roboter

Hallo Involut,

Kopf hoch. Es gibt folgende Lösungen:

1. Die Baugruppe von Rotomotion (http://www.rotomotion.com/prd_REV2.4.2DOFA.html), diese besteht aus einem Gyro CG16, einem 2-achs Accelerometer ADXL311, präsizen OPs (Z-Board)und einem vollständigen ATmega32-16MHz, MAX231, Tachoschaltung, Spannungsregler und 11 Servoanschlüssen. Beides kostet jetzt fertig US$ 299,- (Früher gab es den Bausatz für 149,-)

2. Den Bauteilen ADXRS150EB und ADXL311JE z.B. von Sander für ca. 110,- EURO plus OPs etc.

3. Dem Mini Gyro von Conrad für 35,- EURO plus ADXL311JE plus OPs etc.

Das es mit diesem Gyro nicht geht, wurde nie behauptet. Man muß nur eine konstante Eingangspulsbreite erzeugen und die Ausgangspulsbreite messen. Diese ist ein Maß für die Drehrate. Wie die Drift zu beherrschen ist wurde schon im Forum beschrieben.

Lösung 1. und 2. habe ich in meinem UCBalBot bereits mit Erfolg eingesetzt.

Gruß
Ulli

Hallo Involut,

nochmal zu Deiner letzten Nachricht.

Nur mit Abstandssensor bekomme ich die Balancierregelung meines UCBalBot auch nicht stabil. Man braucht immer auch die Drehrate.

Gruß
Ulli

Hi und vielen Dank für die Aufmunterung.
Rein Finnaziell kommt nur den Minigyro von Conrad in Frage.
Kann man sich das so vorstellen das man (ich benutzte AVR+BAscom)
das "DING" wie ienen Servo anspricht ,ihm etwa Position 100 angibt, und dann am Ausgang eine Pulbreite(mit Timer0?) asuliest und aus der Differenz die Drehrate(Winkelgeschwindigkeit?) bekommt,diese Integriet und so den Winkel(relativ?) erhält?
Oder kennt jemand vieleicht ein Tutoril o.ä. welches dies Frage erübrigt?

mfg

Inv

Hallo Involut,

genau so funktioniert es, was den GYRO betrifft. Mit halber Pulsbreite ansteuern und dann messen, dann hat man die Drehrate oder auch Winkelgeschwindigkeit. Theoretisch kann man die Winkelgeschwindigkeit integrieren und erhält so den Winkel.
Praktisch geht das jedoch aufgrund der Drift des Sensors nicht ! Der so ermittelte Winkel driftet ebenfalls und der Robbi fällt schon nach einigen Sekunden "auf die Nase". Deshalb braucht man einen Referenzwinkel und muß beide Signale fusionieren. Dann geht es. Die Fusion kann man mit einem complementary filter, einem Kalman Filter oder einem Beobachter machen. Hierzu habe ich bereits im Forum etwas geschrieben.

Was für ein Roboter baust Du denn gerade ?
Wenn Du mir die technischen Daten schickst, könnte ich das ja mal mit meinen MATLAB-Programmen simulieren und weitere Tips geben.
Gruß
Ulli

Hi,
ich möchte einen auf Räder Balancierenden Robo bauen wie der nBot(oder zumindestens annährend;))
ICh habe 2 RB35 Motoren mit Rädern(ca5cm Radius) eine Holzplatte und ein AVr Board mir l293 als treiber.Dazu eine Gewindestange als Ausleger an Welcher der Gdp12 hängt.
Ertser Versuch mit rb35 1:100---->eher Schlecht
Dann 1:30 Motoren ----> gaaaaaanz mies.
Heute aben oder Morgen werde ich die 30*30 cm Multiplex(2cm dick)
durch eine Sperrholplatte ersetzten(20*45*1 cm) erstzen.
Diese Hochkant nehmen und hofen das die Gewichtsparniss zusammen mit dem geösseren Trägheitsmomwnt das ganze Stabilisiert.
Wenn die Ergebniss mit dem Sharp Entfernungssensor erfolgfersprechend sind schau ich mal ob ich 35 euro für den Gyrokreisel opfern kann.
Also für eine Simulation und jede andere Hilfe bin ich natürlich sehr dankbar.

mfg

Involut

Nachdem der ASURO ja recht verbreitet und leicht reproduzierbar (beschaffbar) ist dachte ich es wäre ganz nett, es auf den ASURO anzuwenden. Einige Datenhaben wir ja auch schon.

Vielleicht kann auch jemand noch die Beschleunigungsdaten des ASURO messen.
Manfred

Hi,
ich gebe gerne alle Arten von Erfahrungen weiter.
Aber der ASURO ist sowas von überteuert,da muss man kein armer Studnet sein um 50 euro zuviel zu finden.
Ich bin trotzdem gespannt ob man das hinbekommen ihn aufrecht zu halten.
Ein ASURO der auf 2-Rädern Balanciert ist auch 50 euro Wert (denke Ich).
Wenn das "hier"(oder anderswo) jemand hinbekommt "HUR AB"!.
Aber wie gesagt 50€ "nur zum Experimentieren" it echt zu viel.

mfg

Involut

Hi Involut,

wie schwer ist der Robbi ? Wo liegt der Schwerpunkt, wo sitzt die Batterie ? Wie schwer sind die Räder ? Welchen Abstand mißt Du, wenn der robbi in Sollposition steht ? Die RB 35 haben keine Inkrementalgeber oder ähnliches. Balancieren auf der Stelle wird damit nicht funktionieren.

Übrigens finde ich den ASURO nicht zu teuer.
Wenn man bedenkt, daß z.B 2 RB 35 Motoren schon ca 25,- Euro kosten. Dann kommt noch die Platine hinzu, 2 DC Steller, LEDs, Handbuch usw..

Gruß
Ulli

Hi Involut,

genauer gesagt braucht man für eine Simulation u.a. diese Daten:


Gruß
Ulli

...ich guck mal ob ich die zusammenkriege.

Hallo

Wollte das ja mit einer Servoregelung und einem Pendel mit Encoder machen.
Aber wenn ich so überlege, wird das vermutlich nicht gehen.

Weil die Steuerung wird immer so regeln , dass der Bendel gleich bleibt.
Wenn ich jetzt aber so Starte, dass der Robot aus der Balanz ist, wird er immer den gleichen Zustand beibehalten wollen.
Also immer nachregeln, weil der Robo kippt.

Man bräuchte einen Sensor, der mal sagt, ob der Robo im Gleichgewicht ist!!
Also die linke Seite gleich ist wie die rechte.
Wenn jetzt die linke Seite 1kg schwerer ist als die rechte Seite, müsste er so schräg stehen, dass sich das wieder ausgleicht.

Aber mit welchem Sensor geht das?
Dachte vielleicht an einen Dehnmessstreifen auf der Stütze.
Wenn die Belastung an der Stütze am wennigesten ist, ist der Robo im Gleichgewicht ?!

?

Hi,
Ich hab mal 2 Foros gemacht.
Stabil ist der noch lange nicht.
Er verzögert den unweigerlichen fall nur etwas.
Ich werde wohl nochwas am Algorithmus feieln müssen.

mfg

Involut

Foto2 ...und 15 zeichen braucht man ja

Hi Involut!
Könntest Du ein Video posten?

Also diese Daten hier für ASURO, und reichen die? Fehlt noch was?

Code:

---

System: ASURO  Autor: Ulrich Czarkowski 02.11.04
changes: 14.03.2005 15:20
Masse und Abstände auf ASURO angepasst

Konstanten
g  = 9.81;          Gravity(m/s^2)
r  = 0.019;              Radius of wheel(m)
Mw = 0.015;              Mass of wheel(kg)
Mp = 0.126;              Mass of body(kg)
Iw = 0.0000010;      Inertia of the wheel(kg*m^2)
Ip = 0.000164;      Inertia of the body(kg*m^2)
l  = 0.02583;        Length to the body's centre of mass(m)

Motorkonstanten,
lt Datenblatt Igarashi 2025-02
mit Getriebeuntersetzung i = 5*5
Km = 0.00654 *25;        Motor torque constant (Nm/A)
Ke = 0.006087/25;    Back EMF constant (Vs/rad)
R  = 16;                      Nominal Terminal Resistance (Ohm)

---

Hi Uli,
wenn es ohne Inkrementalgegeber nicht geht war das ja von anfang an zum Scheitern verurteilt..... Schade!
@Florian
wenn du unbedingt sehen willst wie er Umfällt?

mfg

Involut

Zitat:

---

Zitat von Involut

wenn du unbedingt sehen willst wie er Umfällt?

---

Naja, das könnte man analysieren!
Außerdem sind die ersten "Gehversuche" auch sehr interessant! :o)

...mpg ist hier Verboten.Wer will kann das Viedeo(<100KB) per mail haben.
Aber darauf sieht man nur wie der Robo umfällt....kläglich versagt... ](*,) ](*,) ](*,) ](*,)

Ich würde es gerne sehen! ;o)
florian@cer-online.de

@Florian..Du hast post

@Mafred habe deine PN bekommen und probiere es mal mit .ace

Danke, habs erhalten!
Allerdings funktionieren die Videos nicht!
Brauche ich ein spezielles prgramm dafür!?

*edit*
Jetzt funktionierts! :o)

Na also, für eine ersten Schritt eine ganze Menge.
Freut mich, dass es weitergeht.

Manfred
Aus Kapazitätsgründen kann man die Dateien nach weiteren Schritten dann wieder löschen.

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?

mfg

Involut

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

Gruß
Ulli

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?

mfg

Involut

Hallo Involut,

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.

Gruß
Ulli

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!

Gruß,
Markus

Hab direkt mal noch ein paar Links:
http://www.usdigital.com/products/t4/ - kostet ~70$
http://www.gemac-chemnitz.de/pages/d...-1-1-D-NS9.pdf - kostet, wie gesagt - 109€ + Mehrwertsteuer

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

Welche Kurve meinst du? Die beim Inclinometer für 70$? Das andere hat eine Ansprechzeit von 350ms... Das dürfte doch reichen, oder?

Ich habe zunächst mal die Kurve hier gesehen, das ist aber der für 70Eu.

Der kommt mir schon ein bisschen langsam vor. Der Sensor ist ja nicht das einzige Glied mit Verzögerung und einige Regelschwingungen im Film vorne hatten eine Perodendauer von einigen Herz.

Langsamer wird es mit einem kleineren Roboter auch nicht werden.

Manfred

Bild hier  

@brinkee:

Leider sind die klassischen Neigungssensoren mit etwa 350ms Einschwingzeit viel zu träge, um einen kleinen 2 Rad Roboter alleine stabilisieren zu können. D.h., man muß auf jeden Fall einen Komplementärfilter oder ein Kalman Filter einsetzen.
Zumindest ging das bei meinem UCBalBot mit 1,2 kg Masse nicht anders.

Ich hatte mir z.B. die Sensoren von Seika: http://www.seika.de/ genauer angeschaut. Aber auch die kosten über 90 Euro und sind damit uninteressant.

Für die Balancierregelung des ASURO wären die Sensoren zudem noch viel zu groß.

Was für eine Ansprechzeit haltet ihr denn für vernünftig, bzw. wie verhält es sich beim UCBalBot?

Zitat:

---

Zitat von brinkee

Was für eine Ansprechzeit haltet ihr denn für vernünftig, bzw. wie verhält es sich beim UCBalBot?

---

Hallo brinkee,

die "Drehrate" meines UCBalBot beträgt bis zu 36°/100ms. Beim ASURO ist sie etwa doppelt so groß (vgl Berechnungen von Manf).
Beim UCBalBot habe ich zwei Wege ausprobiert, die zum Ziel führten:
1. Ein ADXRS300EB -Gyro und ein GP2D02 oder -120 PSD-Sensor.
2. Statt des PSD - Sensors ein Beschleunigungssensor von AD, den ADXL311 und Fusion der beiden Sensorsignale per Komplementärfilter.

Hallo Ulli!
Hab mal ein bisschen gesucht und (fast) gefunden, was du meinst!
Das ADXRS300EB ist doch bloß das Evaluation-Board, oder? Kostet der Sonsor an sich wirklich nur 30$? Und das Accelerometer nur 4,25$? Das ist nicht viel!
Sag, dieser Komplementär- bzw. Kalman-Filter von dem ihr immer sprecht, ist das ein elektronisches Bauelement oder bloß Softwareseitig implementiert!?

Gruß,
Markus

Zitat:

---

Zitat von Anonymous

Hallo Ulli!
Hab mal ein bisschen gesucht und (fast) gefunden, was du meinst!
Das ADXRS300EB ist doch bloß das Evaluation-Board, oder? Kostet der Sonsor an sich wirklich nur 30$? Und das Accelerometer nur 4,25$? Das ist nicht viel!
Sag, dieser Komplementär- bzw. Kalman-Filter von dem ihr immer sprecht, ist das ein elektronisches Bauelement oder bloß Softwareseitig implementiert!?

---

Hallo Markus,

Richtig. Aber das sind 1000er Preise von AD. Als Normalbürger muß man deutlich mehr bezahlen. Der ADXRS300 ist nur im BGA Gehäuse erhältlich, das kann man als Hobbyelektroniker kaum auflöten, daher empfiehlt sich das EV-Board.
Das Komplementärfilter könnte man auch mit OPs aufbauen, leichter und flexibler geht es aber mit Software.

Hallo Leute

Habe jetzt meinen Versuch doch noch gemacht ..
(versprochen zu Ostern :-) )

Bild hier  

70 Watt Motor.. (Hatte keinen anderen)
links oben, das schwarze, ist ein Encoder.
Daran hängt ein Pendel zur Lagekontrolle.

Das Ganze an einer Gecko-Servoendstufe.

Leider funtioniert das Ganze doch nicht so recht :-k

Das Pendel, pendeld viel zu sehr 8-[

Das Ganze kommt sofort ins schwingen und schaukelt sich auf.

Vermutlich geht das wirklich nur mit so einem Beschleunigungssensor
:-k

Roberto

Hier noch ein kleiner Videoclip (MPG, ca. 1MB) der zeigt wie es nicht geht: http://www.ErKipptUm.de/ersterVersuch.mpg

Dass das Ding nicht ganz umkippt liegt nicht an der ausgeklügelten Regelung, sondern an der abstützenden Bodenplattte.
Der gesamte Aufbau ist sehr provisorisch. Die Platine mit dem ADXL zur Winkelmessung habe ich einfach nur da wo gerade Platz war mit Kreppband angeklebt, das RN-Control ebenfalls.
Dass der Beeper vom RN-Control im PWM-Rhytmus des ADXL mitsummt, weil er am selben Port hängt, verbessert die Messgenauigkeit wahrscheinlich genausowenig wie der schlecht zentrierte Akku das Gleichgewicht fördert.

Neben der Mechanik und der Elektronik ist auch in der Programmierung noch genug Spielraum für Optimierungen um die Hoffnung noch nicht ganz aufzugeben.

Code:

---

Do
  Pulsein Ist , Pind , 7 , 0           
  If Ist < Soll_min Then
        Call Vor()
  Elseif Ist > Soll_max Then
        Call Zurueck()
  Else
        Call Stopp()
  End If
Loop

---

Auf dem Video schlecht zu erkennen aber reproduzierbar ist, dass er sich immerhin schon ab und zu mal für fast eine Sekunde relativ aufrecht hält. (wenn man ihn vorsichtig hinstellt, klappt das allerdings auch im abgeschalteten Zustand ;-) )

Hallo recycle,

das sieht doch schon ganz gut aus. Mit einer Zweipunktregelung kann man überhaupt nicht mehr erwarten.
Probiere es doch mal mit einem P-Regler.

Zitat:

---

Das Pendel, pendeld viel zu sehr

Das Ganze kommt sofort ins schwingen und schaukelt sich auf.

Vermutlich geht das wirklich nur mit so einem Beschleunigungssensor

---

Hallo Roberto,
hast du es mal mit einem Dämpfer versucht ?