Balancier Robo

Da ich solche dinger irgendwie fazinierend finde wollt ich mich auch mal mit so einem Balancier Robo probieren
(deswegen zu gepolanten projekten weil bis her fast niochts geklappt hat)
Nun Zum Aufbau
2 Legomotoren +2 räder
gestell aus lego
rn-control zum regeln
als sensor habe ich einen sharp ir abstandsensor

nun mein Problem ich hab mit reglung bis auf 2 punkt reglung und 4 punktreglung noch nicht viel gemacht und immer nach gefühl gehandelt
das scheint hier garnicht mehr zu helfen es ruckelt wie verückt bis der aufbau auseinander fliegt
welche art von reglung ist sinvoll?
und wo gibt es verständliche infos zu dem thema
(bei wiki wird man in meinen augen glatt erschlagen)
desweitern hab ich noch einen beschleunigungssensor("robonova 2-axis accelerometer" mit dem ich noch nicht gearbeitet habe.
aber im zweifel auch zum einsatz kommen könnte.

ein wii nunchuck wäre auch noch zur verfügung aber das habe ich in bascom noch nicht ausgewertet bekommen (ist aber machbar)

fals notwendig kann ich auch den aktuellen code hier mal posten aber der ist grad auf einem anderen rechner.
mfg thomas

Regeltechnisch sind folgende Sache wichtig bei ein Balancierroboter :
1. Mesung Winkel gegenueber Boden. IR Sharp geht, ist aber langsam und nicht lineair (40 ms minimal). Idealerweise sind gyro-sensor + acc sensor für driftkompensierung.
2. Massentragheit um die Radachse. Wie hoher, wie trager die Regelung kan sein. In Praxis kan der Roboter mit ein hohes Schwerpunkt gebaut werden.
3. Eine PWM regelung mit minimal 2 Factoren : Ein ist die absolute Winkelfehler, zweite ist die actuelle Drehgeschwindigkeit. Das sieht dan so aus : PWM = a*Winkelfehler + b*Drehgeschwindigkeit.
So habe ich das gemachthttp://www.youtube.com/watch?v=a1Efg...layer_embedded

"Dieses Video enthält Content von UMG. Es ist in deinem Land nicht verfügbar. "
a muss probiert werden
drehgeschwindigkeit meinst du den aktuellen pwmwert?
der könnte doch auch gehen
ich habe keine aktuelle drehzalmessung

wie kann man a und b wenigstens abschätzen?

hab nun das nunchuck am rn-.controll zum laufengebracht das hat einen geringen drift (vom gefühlher nicht festellbar)

diese art von reglung kann aber wegkippen oder? so dass er immer weiter beschleunigt auch wenn er umgekippt ist
eine abruch bedinung wäre sicher sinvoll
a*maximalerwinkelfehler<255 wäre doch eine sinvolle überlegung oder?
die masse des robos und die länge sorgt für trägheit der regelkreis einschlieslich der motoren ist wesentlich schneller.

Diese video soll functionieren : http://www.youtube.com/watch?v=9WiQm...layer_embedded
Drehgeschwindigkeit meine ich wie schnell fallt der Robby um momentan. Das ist dan die actuelle Winkelgeschwindigkeit. Normalerweise ist das was den Gyro ausgibt. Wen sie nur eine Winkelmessung haben mussen sie das differenz zwischen zwei Messungen dafur nehmen : Erste Messung gibt ein Winkel von 5°. Zweite Messung, 100 mS spater gibt eineWinkel von 10°. Dan ist ihre Winkelgeschwindigkeit (10°-5°)/0.1sek = 50°/sekunde.
PWM wert ist das was sie an ihre Motor schicken (zwischen +100% und -100%)
Die Factoren a und b wirden mit "trial and error" eingestellt. In prinzip fangst du an mit b=0, a immer vergrosseren bis der Robby anfangt zu oscillieren. Dan b hochdrehen bis er wieder stabil werd. Da gibt noch eineig knackpunkten, wie "stick slip". Ers mus du rausfinden bei welke PWM wert die Motoren anfangen zu drehen, sag mal zwischen -18% und +18% passiert nichts. Diese "dead zone" muss du softwaremassig ueberbrucken, da eine balancierrobby immer um das nulpunkt regelt. Fiel Erfolg !

da muss man echt staunen was da geht
ok ich probiers
danke das du das so schön erklärst hab mir das eine nummer schwieriger vorgestellt.

das "dead zone" problem habe ich mitbekommen ^^

am ende wird noch eine akku spannung kompensation nötig sein oder?

am anfang kann ich ja +0 rechnen wenn er osziliert geht erstmal was und ich werde weiter motiviert um dann auich den nächsten schritt zu schaffen

Hi
also ich hab da mal ein Link zu balancierenden Robotern gefunden den ich ziemlich gut fand: https://docs.google.com/viewer?a=v&p...zhiZmE1N2M4Y2U

Ich hoffe ich konnte helfen.

KR-500

sehr interresant
aber noch mal eine grundlegend frage ist es leichter einen hohen oder einen flachen robo zu banalcieren?
einen langen stab auf dem finger kann man ja schlislich leichter balancieren als einen kurzen

Zitat:

---

Zitat von Thomas$

... grundlegend frage ist es leichter einen hohen oder einen flachen robo zu banalcieren? ...

---

Das mit dem langen, hohen Stab ist richtig. Ansonsten gilt: es kommt auf die Schnelligkeit der Regelung an - insbesonder im Verhältnis zur Schwingungsdauer des Roboters. Selbst völlig unstabile "Dinge" (Beispiel: Kampfflugzeuge - bemannt und unbemannt - sind heute total unstabil = für Menschen praktisch unfliegbar) können stabilisiert werden, wenn Sensorik, Datenverarbeitung und Aktoren schnell genug sind.

ok bis zum schwingen hab ich es geschafft er fängt dann an sich weiter aufzuscghaukeln
ist a vlt schon zu groß geraten?
soll ich mal ein viedo machen das man die symptome besser deuten kann?
wenn er um den null punkt regelt dann stimmt das auch ziemlich gut
aber dann schlägt er aus und reagiert über

Zitat:

---

Zitat von Thomas$

sehr interresant
aber noch mal eine grundlegend frage ist es leichter einen hohen oder einen flachen robo zu banalcieren?
einen langen stab auf dem finger kann man ja schlislich leichter balancieren als einen kurzen

---

Hast Du schon richtig erkannt aber probiere einmal nur einen Besenstiel ohne Besen dran und dann mit Besen (Oben). Umgekehrtes Pendel. Die hoch gesetzte Masse wirkt durch ihre Trägheit "Beruhigend".

Gruß Richard

ja hab ich schon verschiedenes probiert.
hc denk immer so was ich schaffe könnte der robo auch hinbekommen
wo ich dran scheiter hat der robo noch weniger chancen ^^

jetzt hatsich der nunchuck doch irgendwie mit als feher quelle heruasgestellt.
dort woi es anfängt so stark zu ruckeln bis was kaputt geht liefert der nunchuck fast utopische werte die mechanisch nicht möglich sind.
soweit kann der robo nicht umkippen.
kann es sein das der nunchuck sich von motoren beinflussen läst?
so gut scheinen die lego motoren nicht entstört geworden zu sein.

als code zum auslesen des nunchuck habe ich mich des codes von radbruch bedient
https://www.roboternetz.de/phpBB2/ze...r=asc&start=22
seite 2 (final code)

Hasst du nur die Daten von Nunchuck ? Hat der Nucnchcuk ein Gyro, oder nur Beschleunigungssensoren ? Du brauchts absolut ein Gyro, da die Beschleunigung Sensoren auch reagieren auf Lineaire Beschleunigung.
Ihre Winkelmessung soll auch schon richtig messen ohne Balancieract. Bei rein hin und her schaukelen ohne Verdrehung soll der Winkel stabil sein !!
Der eigentliche Winkelmessung (Gyro + Acc) war fur mich eigentlich das schwierigste Kapitel. Ich habe das hin bekommen ohne Kalman, aber mit festes Anteil von ACC + integration von Gyro. Meine code ist in C, bist dur deran interessiert ?

Hallo

Zum Nunchuk in Bascom: Hast du das beachtet:
https://www.roboternetz.de/phpBB2/ze...=389925#389925

In der ersten Version wurden die Werte nicht richtig umgerechnet, hier stimmt dann die Auswertung:
https://www.roboternetz.de/phpBB2/ze...=389966#389966

Gruß

mic

Ja wäre ich
c versteh ich nur zum schreiben ist es mir zu schwierig

ich hab mal den code von mir angehangen.

das man von nmunchuck beides winkel und beschläunigung bekommen kan weis ich den mit der lib zum arduino giung es da konnte man beides nutzen
acc und pitch und roll

nur das was in dem code rauskommt scheint ein winkel zu sein der aber irgendwie noch von der beschleunigung beeinflusst wird
so wie ich den eindruck hab.

dann tritt noch ein merkwürdes verhalten auf wenn ich den robo kippe und die räder frei drehen lassen
die räder bschleunigen und bremmsen etwas aber total unsytematisch. der winkel war gleich geblieben und die werte hatten auch gestimmt. (hab sie im terminal ausgeben lassen)

http://www.arduino.cc/playground/Main/WiiChuckClass
nur noch den teil in bascom übersetzen

"
int readRoll() {
return (int)(atan2(readAccelX(),readAccelZ())/ M_PI * 180.0);
}

// returns pitch in degrees
int readPitch() {
return (int) (acos(readAccelY()/RADIUS)/ M_PI * 180.0); // optionally swap 'RADIUS' for 'R()'
}
"
jetzt weis ich auch wozu man das acc_z gebrauchen kann ^^