Segway per RC

Hm, ganz so einfach isses dann doch nicht- es gab ein paar (momentan kleinere..) Rückschläge.

-während mit den Kleinen Rädern keinerlei ernsthafte Probleme bereiteten, tuns die grossen dann doch: die brauchen mehr Drehmoment, das war klar. Der Haken dabei: die Getriebe könnens liefern, aber sie werden weich dabei. Ein Zahnrad rutschte bereits etwas auf der Abtriebswelle durch. Hab es erstmal verklebt und hoffe, das reicht, aber gegebenenfalls muss ich auf stabilere Getriebe umrüsten- die gibts auch in Vollmetall-Ausführung.

- der Stromverbrauch ist deutlich gestiegen. Habs zwar nicht gemessen, aber während ich mit den kleinen Rädern nen paar Bastelnachmittage am Stück rumspielen konnte, muss ich den Akku nun jeden zweiten Tag laden- geschätzte Betriebszeit aber immer noch deutlich jenseits ner halben Stunde, also ausreichend.

- die Regelung treibt mich noch in den Wahnsinn.
Aus unerfindlichen Gründen muss ich extrem hohe I-Werte benutzen, während P sehr niedrig sein muss.
Den I-Anteil kapier ich einfach nicht- je höher er ist, umso schneller wird ausgesteuert.
Widersinnig...?

Keiner ne Meinung zu dem Regelungs-Problem?
Na gut.
Werd mich da schon durchwursteln, da gibts ein paar halbe Ideen zu.

Inzwischen bin ich so weit, dass ich den Roller per Fernsteuerung einigermassen gezielt fahren kann: Fahrsteuerung vor-und rückwärts und auch ne rudimentäre Lenkung sind bereits programmiert.
Rudimentär deshalb, weil lediglich das kurvenäussere Rad beschleunigt wird. Während der Fahrt reicht das im Grunde aus, aber ich mach das natürlich noch ordentlich.
Ausserdem kann er, mit dieser Lösung, im Stand praktisch kaum drehen: zwar funktioniert es auch dann, aber durch Korrekturen der Balanceregelung dreht er natürlich sofort zurück. Da kommt ne andere Strategie.
Aber: ich habs geschafft, in meiner engen Bastelbude hier gestern ne 8 zu fahren- unfallfrei. ;)
Heute will ich mal auf den Wäscheboden, da ist mehr Platz. Die Keycam kommt mit, ich hoffe, die kriegt da was brauchbares hin.

Inzwischen nen paar aktuelle Fotos von vor ner Stunde:

Das Video ist grauenhaft- obwohl noch genug Licht auf dem Wäscheboden war, meinte die Keycam wohl es sei keines- aber man erkennt doch: die Kiste fährt.
http://youtu.be/blV54p4a2oU

Wie man sieht, ist aber noch jede Menge zu tun.
Die Stürze rührten ausnahmslos daher, dass ich kluges Köpfchen die Regelung begrenzt hatte (wollt damit im niedrigen Bereich eine bessere Auflösung erreichen)- und somit ab einer gewissen Fahrgeschwindigkeit die Regelung also nicht mehr arbeiten kann.
Das muss geändert werden.
Ausserdem müssen die beiden Sätze Regelparameter, mit denen ich momentan arbeite (bei geringer Neigung wird mit johem Ki, und niedrigem KP gearbeitet, bei grösseren Abweichungen ist Ki niedriger, aber Kp höher, das soll ein überreagieren verhindern und tuts auch noch besser aufeinander abgestimmt werden.
Dadurch, dass ich wieder an der Regelung rumgespielt habe, ist auch die RC-Kontrolle nicht soo gut, wie sie sein könnte.

Also: noch ne Menge Arbeit...

Hallo Rabenauge,

danke fürs Video, den Fahrgeräuschen zu Urteilen schwingt wohl Toms Fahrzeug noch etwas um den Sollwert. Ich würde dir gerne helfen nur bekomme ich meinen Legoprototyp nicht mal sauber zum stehen. Mich würde mal ein code schnipsel für deine PID-Regelung und den Filter der Gyro und Accel-Werte interessieren, evtl. kann dir dann auch ein Experte einen Tipp geben. Hast du jetzt was zur Drehzahlmessung angebracht?

mfG
Mario

Als Filter benutze ich die Kalman-Bibliothek für Arduino.
https://github.com/TKJElectronics/Ex...-Kalman-filter

Die liefert aus dem 6DoF gleich schön die absoluten Winkelgrade, bezogen auf die Senkrechte.
Auch der PID-Regler ist ne fertige Bibliothek: http://playground.arduino.cc/Code/PIDLibrary

Momentan arbeite ich da mit einer Samplezeit von 50ms- die wäre weiter runter zu setzen, bringt aber dann nicht mehr wirklich ne Verbesserung.
Hatte sie auch schon auf 10ms...
Ich denke, wenn man die Zeit zu weit runtersetzt, kann der Regler nicht mehr viel tun, da er ja ständig neu kalkuliert wird.

Übrigens: ich hab auch den ersten Prototyp mit Lego gebaut: zwei Motoren vom RCX-Set, Arduino, Motorshield und den Sensor, den ich jetzt auch benutze. Dazu nen 7.2V Racingpack (in dem LEGO-Ding reicht der zwei Wochen..).
Funktionierte ganz gut, um die PID-Parameter einzustellen, war noch ein LCD-Display dran und nen Satz Potis, mit denen ich Kp, Ki und Kd mal direkt einstellen konnte.
Wichtig bei dem Ding war alledings die richtige Übersetzung. Zu lang, reicht die Kraft nicht (bzw. dann war der Antrieb nicht kräftig genug um schnellstens auszuregeln). Immerhin laufen die LEGO-Motoren eigentlich ja mit 9V.
Und: es ist mit niedrigem Schwerpunkt schwieriger! Hatte das Ding dann mal auf Hochkant-Form umgebaut, da wird die ganze Regelung deutlich toleranter.

Eine Drehzahl-oder Wegmessung gibts nicht, dafür ist gar keine Sensorik vorhanden-ich könnt also maximal die Fahrwege aufaddieren, was nicht allzu genau würde. Allenfalls könnte man aus dem Beschleunigungssensor noch Bewegungsdaten rausfischen.
Wenn sich rausstellen sollte, dass es ohne wirklich nicht geht, dann muss ich halt irgendwelche Geber nachrüsten, z.B. Lichtschranken an die Getriebe oder Räder.
Ich denke aber immer noch, das ist nicht nötig.

Und ja: im Video pendelt er mehr als schön wäre- aber ich kriegs nicht wirklich gut hin (besser hatte ichs allerdings schon), wenn ich die Regelung so einstelle, dass er ruhiger steht, wird sie bei Störungen zu aggressiv.
Das hatte ich vorher: kleine Störungen fing er schön ab, und auch ziemlich schnell, aber wehe es gab ne grössere, dann übersteuerte er sofort dermassen, dass er sich nicht mehr abfangen konnte.
Ich hatte nämlich vorher schon versucht, nen Video da zu machen: auf dem ziemlich rutschigen Bodenbelag (irgendwas, Lineoleum oder so nen Zeugs) ging es zu wie auf Schmierseife- ging gar nicht.
Die Reifen taugen für _den_ Untergrund auch nicht so wirklich, zum einen sind sie recht hart (da "federn" eher die Felgen mit als die Reifen), und zum anderen- naja, es waren die billigsten Räder in der Grösse, die es paarweise gab beim Conrad.
Die Motorradreifen waren um Welten weicher. Aber mir halt zu klein-ich find die "Monsterräder" toll an dem Ding.

Momentan weiss ich nicht genau, woher die Pendelei wirklich rührt, das muss ich erst noch erforschen: dadurch, dass ich an der Regelung noch einiges geändert hatte, ists gut möglich, dass die umgerechneten RC-Signale nun grad nicht wirklich passen (das ist etwas umständlich, da die eingelesenen RC-Steuerungswerte passend skaliert werden), Fakt ist: die RC-Steuerung in dem Video hat in Wirklichkeit lausig funktioniert. Bei den Tests nen Tag vorher, ging das viel besser. Man muss halt genau den Bereich finden, in dem man den virtuellen Schwerpunkt recht sorglos nach vorn oder hinten schieben kann.

Ich geb auch zu: gestern hab ich nix mehr an der Software gemacht, hatte keine Lust. Mir war eher nach mechanischen Basteln, und nun hat das Ding auch noch nen Tankverschluss (da kommt die Ladebuchse dahinter), die Hupe hat ne verchromte Verkleidung und einige Gewinde der Abdeckungen, die vorher einfach M3-in-Sperrholz-leimgehärtet waren, sind nun mit Messing-Gewindeeinsätzen versehn.
Und die von aussen zugängliche USB-Buchse hat auch ne Abdeckung bekommen, da sie direkt hinter dem linken Rad sitzt- für draussen wäre das sonst nix.
Ab und zu muss ich einfach "greifbare" Dinge bauen...

- - - Aktualisiert - - -

Grade hat mir jemand vorgeschlagen, es mal mit zwei PID-Reglern zu versuchen.
Einen für kleinere Störungen, und nen zweiten, um schlimmere Fälle auszuregeln.

Im Prinzip tu ich das bereits, alleerdings läuft es auf dem selben Regler, es werden nur die Parameter Kp, Ki und Kd geändert:

Code:

---

float reglerP = 2.1;
float reglerI = 220.1;
float reglerD = 0.10;
float reglerAggP = 15.0;
float reglerAggI= 100.0;//90
float reglerAggD= 0.2;//0.4

---

Verwurstet wird das dann so:

Code:

---

double abw = abs(sollWert+genullterWinkel);
  if (abw<4)
  {
  radAchse.SetTunings(reglerP,reglerI,reglerD);
  digitalWrite(ledGelb,LOW);
  }
  else
  {
  radAchse.SetTunings(reglerAggP,reglerAggI,reglerAggD);
  digitalWrite(ledGelb,HIGH);
  }

---

Aktuell werden bei Abweichungen von vier Grad andere Parameter benutzt, die allerdings eher beruhigend wirken:

Ki ist sehr hoch (setz ichs runter, dauert es ewig, ehe das Fahrzeug ausbalanciert ist), bei grösseren Abweichungen führt das allerdings zu extremem Übersteuern. Wirklich extrem, dann kann man das Ding selbst mit der Hand kaum noch festhalten.
Deshalb ist AggI deutlich kleiner, dafür aber AggP (irgendwoher muss schliesslich die kraftvolle Ausregelung kommen) dann höher.

Durch die "aggressiven" Parameter wird dieses starke Übersteuern weitgehend unterdrückt, und die Regelung fängt sich binnen zwei, drei Pendelbewegungen wieder. Dank dann höherem P-Anteil funtioniert das auch ziemlich sicher.

Vermutlich liegt in der Gegend des Codes auch noch der Hase im Pfeffer: das ist einfach noch nicht alles optimal aufeinander abgestimmt.
Richtig schön wären Rampen, die die Werte gleitend ineinander übergehen lassen. Mal sehn, ob ich das versuche.

Hallo, Rabenauge.

Zum einen fällt mir auf, dass du zwar von einem PID-Regler sprichst, aber nie den D-Anteil diskutierst, der üblicherweise die schnelle energische Gegensteuerung gegen Soll-Ist-Differenzen ausmacht (Prinzip: "Wehret den Anfängen"). Vielleicht ist das aber bei dem Segway auch ganz anders - ich habe bisher buchstäblich keinerlei eigene praktische Erfahrungen mit Regelungen.

Zum anderen habe ich schon gestern ein wenig im Netz gesucht und eine Studienarbeit zum Inverspendel - so der wissenschaftliche Oberbegriff von Segways & Co. - gefunden: http://www.heuler.net/stud/pendel/ht...ram/node3.html . Da stehen Begriffe wie "nichtlineare Regelungstechnik", "Fuzzy-Controller" und "neuronaler Regler" drin, bloss kein PID-Regler. Das Inverspendel ist ja in sich instabil und erfordert stets ein Überkorrigieren, wenn die Fahrgeschwindigkeit nicht immer höher werden darf. Vielleicht ist das die Aufgabe für den D-Anteil?

Ich wollte das gestern noch nicht posten, um nicht nach Klugs....... zu klingen. Vielleicht liegt dort aber die Erklärung für deine Probleme. Gut möglich, dass der Segway mit PID-Regler nur in bestimmten technischen Konstellationen leidlich funktioniert, aber sehr empfindlich auf Änderungen an Systemkomponenten reagiert.

Einen Nicht-Umfaller haben ja schon einige hier erfolgreich gebaut; die Balancierer sind dann doch eher seltener. Ich wäre ja mit einem eigenen Nicht-Umfaller schon recht zufrieden.

Wie sieht's eigentlich mit der Massenverteilung bzw. Schwerpunkt bei deinem Segway aus? Auf einem 1,5t-Pkw wird man keinen Bleistift balancieren können; ein Stielbesen dagegen ist vergleichsweise leicht auf der Hand zu halten. Das Balancieren geht umso leichter, je dynamischer der Aktuator und je höher der Schwerpunkt des Pendels ist.

Hallo,

ich habe mir Gestern diese Excel-Simulation hier nach gebaut um mal zu sehen welcher Wert welche Auswirkungen hat. Ich fand`s ganz hilfreich um das ganze besser zu verstehen. Damit lässt sich auch das von RoboHolIC angesprochene "Überkorrigieren" gut darstellen.

Ich glaube bei mir liegt es zur Zeit am zu großen Spiel in den LEGO-Zahnrädern, die Drehrichtungsänderung ist einfach zu "ruppig".

Bei mir ist das aber auch so, dass das Verhalten besser wird wenn P=kleiner ist, I=größer, und D=0.

Anbei mein Arbeitsstand.

Code:

---

'*******************************************************************************
'*******************************************************************************
'**************************** BALANCE BOT V1.0 *********************************
'*******************************************************************************
'************************** 18.03.2014 by CYBORG *******************************
'*******************************************************************************
'*******************************************************************************

'****************************** Allgemein **************************************

$regfile = "m88adef.dat"
$crystal = 8000000
$hwstack = 48
$swstack = 48
$framesize = 48
$baud = 500000

'**************************** MPU-6050 GYRO ************************************

Config Scl = Portc.5      'Configure i2c SCL
Config Sda = Portc.4      'Configure i2c SDA

Declare Sub Mpu6050_write(byval Regadr As Byte , Byval Wert As Byte)
Declare Function Mpu6050_read(byval Regadr As Byte) As Byte
Declare Function Mpu6050_temp() As Single
Declare Function Mpu6050_accel(byval Mpu6050_const_h As Byte , Byval Mpu6050_const_l As Byte) As Single
Declare Function Mpu6050_gyro(byval Mpu6050_const_h As Byte , Byval Mpu6050_const_l As Byte) As Single

Dim Mpu6050_h As Byte
Dim Mpu6050_l As Byte
Dim Mpu6050_int As Integer
Dim Mpu6050_real As Single

Dim Mpu6050_chip As Byte
Dim Mpu6050_in As Byte
Dim Mpu6050_tmp(6) As Byte

Const Mpu6050_adr = &HD0      '&H68 ist 7-Bit-I2C-Adresse
Const Mpu6050_adr1 = &HD1
Const Mpu6050_who_am_i = &H75
Const Mpu6050_pwr_mgmt_1 = &H6B

Const Mpu6050_temp_h = &H41
Const Mpu6050_temp_l = &H42

Const Mpu6050_accx_h = &H3B
Const Mpu6050_accx_l = &H3C
Const Mpu6050_accy_h = &H3D
Const Mpu6050_accy_l = &H3E
Const Mpu6050_accz_h = &H3F
Const Mpu6050_accz_l = &H40

Const Mpu6050_gyrox_h = &H43
Const Mpu6050_gyrox_l = &H44
Const Mpu6050_gyroy_h = &H45
Const Mpu6050_gyroy_l = &H46
Const Mpu6050_gyroz_h = &H47
Const Mpu6050_gyroz_l = &H48

Dim Mpu6050_stemp As Single
Dim Mpu6050_accx As Single
Dim Mpu6050_accy As Single
Dim Mpu6050_accz As Single
Dim Mpu6050_gyrox As Single
Dim Mpu6050_gyroy As Single
Dim Mpu6050_gyroz As Single

'****************************** MOTOR - PWM ************************************
Config Timer1 = Pwm , Pwm = 10 , Compare_a_pwm = Clear_up , Compare_b_pwm = Clear_up , Prescale = 64

Motor_a_front Alias Portb.0      'Motor1 vorwärts
Motor_a_back Alias Portd.7      'Motor1 rückwärts
Motor_b_front Alias Portd.6      'Motor2 vorwärts
Motor_b_back Alias Portd.5      'Motor2 rückwärts


Config Motor_a_front = Output
Config Motor_a_back = Output
Config Motor_b_front = Output
Config Motor_b_back = Output


Motor_a_front = 0
Motor_a_back = 0
Motor_b_front = 0
Motor_b_back = 0

Wait 1

Dim Pwm_middle As Single
Dim Pwm_start As Single
Dim Pwm_limit As Integer

Dim Accel_middle As Single
Dim Accel_step As Single
Dim Accel_filter As Single
Dim Accel_revfilter As Single

Dim Gyro_middle As Single
Dim Gyro_step As Single
Dim Gyro_filter As Single
Dim Gyro_revfilter As Single

Dim Main_middle As Single


Pwm_middle = 0
Pwm_start = 0      '220
Pwm_limit = 1023

Accel_step = 200      '200
Accel_filter = 10      '10
Accel_revfilter = Accel_filter - 1

Gyro_step = 20      '20
Gyro_filter = 60      '60
Gyro_revfilter = Gyro_filter - 1

'****************************** PID - REGLER ***********************************
Declare Function Pid(byval Pid_ist As Single) As Single
Const P = 0.15
Const I = 0.7
Const D = 0.0


Dim Pid_soll As Single
Dim Pid_error(3) As Single
Dim Pid_ist As Single


Pid_soll = Pwm_middle

'****************************** Hauptprogramm **********************************

Mpu6050_chip = Mpu6050_read(mpu6050_who_am_i)      'Wer ist es?
If Mpu6050_chip = &H68 Then
  Print " mpu6050 gefunden... "
End If

Call Mpu6050_write(mpu6050_pwr_mgmt_1 , 0)      'aus dem sleep-modus holen
Dim S As Single
 Print " Neustart... "
Wait 1


Dim Z As Integer

Do

      'ACCEL FILTER
      Accel_middle = Accel_middle * Accel_revfilter
      Mpu6050_accx = Mpu6050_accel(mpu6050_accx_h , Mpu6050_accx_l)
      Mpu6050_accx = Mpu6050_accx * Accel_step
      Accel_middle = Accel_middle + Mpu6050_accx
      Accel_middle = Accel_middle / Accel_filter

      'GYRO FILTER
      Gyro_middle = Gyro_middle * Gyro_revfilter
      Mpu6050_gyroy = Mpu6050_gyro(mpu6050_gyroy_h , Mpu6050_gyroy_l)
      Mpu6050_gyroy = Mpu6050_gyroy * Gyro_step
      Gyro_middle = Gyro_middle + Mpu6050_gyroy
      Gyro_middle = Gyro_middle / Gyro_filter

    'ACCEL + GYRO
      Main_middle = Accel_middle - Gyro_middle

    'PID
    'Print "Ist " ; Main_middle ; " Soll " ; PID_ist
      Main_middle = Pid(main_middle)

    'PWM ermitteln
    Z = Abs(main_middle)
    Z = Z + Pwm_start

    If Z > Pwm_limit Then
          Z = 0
    End If

    'Drehrichtung festlegen
  If Main_middle < Pwm_middle Then

      Motor_a_front = 1
      Motor_a_back = 0
      Motor_b_front = 1
      Motor_b_back = 0

      Pwm1a = Z
      Pwm1b = Z


  Elseif Main_middle > Pwm_middle Then

      Motor_a_front = 0
      Motor_a_back = 1
      Motor_b_front = 0
      Motor_b_back = 1

      Pwm1a = Z
      Pwm1b = Z

  End If


Loop

'**************************** MPU-6050 Functions *******************************
'****************************** MPU-6050 WRITE *********************************
Sub Mpu6050_write(regadr As Byte , Byval Wert As Byte)
  I2cstart
  I2cwbyte Mpu6050_adr
  If Err = 0 Then
    I2cwbyte Regadr
    I2cwbyte Wert
  End If
  I2cstop
End Sub

'****************************** MPU-6050 READ **********************************
Function Mpu6050_read(regadr As Byte) As Byte
  Mpu6050_in = 0
  I2cstart
  I2cwbyte Mpu6050_adr
  If Err = 0 Then      'ACK empfangen
    I2cwbyte Regadr
    I2cstart
    I2cwbyte Mpu6050_adr1
    I2crbyte Mpu6050_in , Nack
  End If
  I2cstop
  Mpu6050_read = Mpu6050_in
End Function

'****************************** MPU-6050 TEMP **********************************
Function Mpu6050_temp() As Single
  Mpu6050_h = Mpu6050_read(mpu6050_temp_h)
  Mpu6050_l = Mpu6050_read(mpu6050_temp_l)
  Mpu6050_int = 256 * Mpu6050_h
  Mpu6050_int = Mpu6050_int + Mpu6050_l
  Mpu6050_real = Mpu6050_int * 0.294117647058823529411764705882      'vgl. S. 31 von RM_MPU-6000A.pdf
  Mpu6050_real = Round(mpu6050_real)
  Mpu6050_real = Mpu6050_real * 0.01
  Mpu6050_real = Mpu6050_real + 36.53
  Mpu6050_temp = Mpu6050_real
End Function

'***************************** MPU-6050 ACCEL **********************************
Function Mpu6050_accel(mpu6050_const_h As Byte , Mpu6050_const_l As Byte) As Single
  Mpu6050_h = Mpu6050_read(mpu6050_const_h)
  Mpu6050_l = Mpu6050_read(mpu6050_const_l)
  Mpu6050_int = 256 * Mpu6050_h
  Mpu6050_int = Mpu6050_int + Mpu6050_l

  '1 g entspricht 2^14 = 16384 bei Standard-Range 2g; also Beschl = accel_x_int*9.81/16384

  Mpu6050_accel = Mpu6050_int * 0.00059875

End Function

'***************************** MPU-6050 GYRO ***********************************
Function Mpu6050_gyro(mpu6050_const_h As Byte , Mpu6050_const_l As Byte) As Single
  Mpu6050_h = Mpu6050_read(mpu6050_const_h)
  Mpu6050_l = Mpu6050_read(mpu6050_const_l)
  Mpu6050_int = 256 * Mpu6050_h
  Mpu6050_int = Mpu6050_int + Mpu6050_l

  '1 g entspricht 2^14 = 16384 bei Standard-Range 2g; also Beschl = accel_x_int*9.81/16384

  Mpu6050_gyro = Mpu6050_int * 0.00763358778625954198473282442748

End Function

'***************************** MPU-6050 READ ***********************************
Read_gyro:

  I2cstart
  I2cwbyte Mpu6050_adr
  I2cwbyte Mpu6050_gyrox_h
  I2crepstart
  I2cwbyte Mpu6050_adr1

  I2crbyte Mpu6050_tmp(1) , Ack
  I2crbyte Mpu6050_tmp(2) , Ack

  I2crbyte Mpu6050_tmp(3) , Ack
  I2crbyte Mpu6050_tmp(4) , Ack

  I2crbyte Mpu6050_tmp(5) , Ack
  I2crbyte Mpu6050_tmp(6) , Nack

  I2cstop

Return


'******************************* PID Functions *********************************
'******************************** PID -Regler **********************************
Function Pid(pid_ist As Single ) As Single

Local P_temp As Single
Local I_temp As Single
Local D_temp As Single



'P-Anteil
P_temp = P * Pid_error(3)
P_temp = P_temp + Pid_ist

'I-Anteil
I_temp = Pid_error(3) - Pid_error(2)
I_temp = I_temp * I

'D-Anteil
D_temp = Pid_error(3) + Pid_error(2)
D_temp = D_temp + Pid_error(1)
D_temp = D_temp * D

'PID-Errors
Pid_error(1) = Pid_error(2)
Pid_error(2) = Pid_error(3)
Pid_error(3) = Pid_soll - Pid_ist
'Print "Err1" ; PID_error(1) ; " Err2 " ; PID_error(2) ; " Err3 " ; PID_error(3)


'PID-Anteil
Pid = P_temp + I_temp
Pid = Pid + D_temp
'Print "PID " ; PID ; " IST " ; PID_ist

End Function

---

mfG
Mario

@RoboHolIC: Mein Segway ist stabil.
Das Ding kann auf sagen wir nem knappen Meter, stehen, bis der Akku leer ist.
In der Zeit fällt er kein einziges Mal um.
Woran ich arbeite ist das Gewackele- das will ich weg haben und denke auch, das geht noch-zumindest beinahe.
Die Stürze im Video kamen ausnahmslos daher, dass ich zu schnell gefahren bin (ich schrieb es schon: die Regelung war auf, glaub ich nen PWM-Wert von 180 begrenzt)- wenn man dieses Tempo erreicht hat, kann die Regelung einfach nicht mehr ausgleichen, wenn da keine Reserven sind.

Auch stürzt er, genau wie die Originale, immer dann zuverlässig, wenn er gegen ne zu hohe Kante gerät.
Dagegen gibts praktisch kein Mittel: wenn der Schwerpunkt einmal vor der Achse ist, und nicht mehr nach vorn gefahren werden kann, ists aus.

Aber: beispielsweise frontal (auch rückwärts) gegen ne Wand fahren kann er noch abfangen!
Im Video sieht man das mit dem Klammerkörbchen: macht ihm absolut nix aus. Später (das war leider nicht im Bereich der Kamera) ist er auch noch gegen ne Wand gefahren. Ohne Sturz.

Den D-Anteil erwähnte ich wenig, das stimmt denn: der ist abartig klein. Ja: der kann um die Mitellage herum dämpfend wirken, aber ich hab momenten nen Kp-Wert von 2.1- da ist schon Kd >0.3 tödlich.
Ich habs mal versucht, meine Überlegung war: Kp und Kd höher, müsste in etwa was ähnliches bewirken wie der sehr hohe Ki-Wert.
Ne, das klappt nicht, ausser heftigem Übersteuern kam da nix raus.
Die Ursache ist mir inzwischen halbwegs klar: das Ding kippt nicht _schnell_. Der Schwerpunkt liegt nen Stück über den Rädern, er kippt also recht "gemächlich"- und damit ist Kd praktisch nutzlos, da der D-Anteil nur auf schnelle Änderungen heftig reagiert.
Und fürs dämpfen um die Mittellage herum bringt es auch kaum was, das hab ich mehrmals hoffnungsvoll versucht.

Das von dir erwähnte Überkorrigieren ergibt sich eigentlich von alleine. Fahrkommandos werden so gegeben, dass der Schwerpunkt verschoben wird. Beim richtigen lehnt man sich nach vorne, damit gerät das Ding aus dem Gleichgewicht und _muss_ losfahren. Dabei stellt sich aber von selber wieder ein stabiler Zustand ein, da die Regelung auch dann arbeitet.
Da mein Tom das nach vorne lehnen nicht drauf hat, mache ichs andersherum: ich verschiebe den Sollwert (den virtuellen Schwerpunkt, sozusagen) etwas nach hinten- der Effekt ist der selbe: der "Soll-Schwerpunkt" ist hinter dem tatsächlichen, das _kann_ die Regelung nur dann ausgleichen, wenn das Ding vorwärts fährt.
Da der verschobene Schwerpunkt sich nun nicht weiter ändert, erhöht sich auch die Geschwindigkeit nicht weiter- die Regelung arbeitet ja dagegen!
Das ist wirklich so einfach, wie es klingt.

Ich hatte schon "bessere" Parameter als im Video, damit war das fahren die helle Freude: schön proportional die Geschwindigkeit erhöhen, verlangsamen- gabs kein Fahrkommando mehr, rollte er gemächlich aus, und bremsen war genauso einfach: etwas "fahrt rückwärts" und das Ding stand auf dem Punkt (naja, fast).
Leider hatten diese Regelparameter aber unschöne Nebenwirkungen: bei grösseren Störungen schaukelte sich alles extrem auf...
Das hab ich momentan in Griff, indem ich bei grösseren Abweichungen andere Parameter benutze. Aktuell ist der Übergang dazwischen noch das problematischste...bin aber ja noch lang nicht fertig.
Ausserdem habe ich noch gar keine Strategie (bzw. nix dazu in der Software) um einen Überlauf zu verhindern: das Teil _muss_ von selber bremsen, bevor die Gasregler am Ende sind-damit dort noch ne Reserve fürs balancieren bleibt.
Praktisch werd ich das _erstmal_ so lösen, dass ich einfach die steuerbare Geschwindigkeit begrenze, ist nicht der optimale Weg, aber nen einfacher.
Momentan kann man im Prinzip endlos lange "Vollgas" fahren-aber dann nicht mehr anhalten, weil dazu die Regelung in Vorhalt gehen müsste. Und das kann sie nicht mehr, wenn die PWM-Werte schon auf max. sind.

@Mario: Excel und ich- das ist nen sehr unheilige Mischung. Habs mir zwar angesehn aber da waren lauter böhmische Dörfer...;)
Sorry, da hab ich echt keine Ahnung von.

Das Getriebespiel ist übrigens so tragisch nicht: mein TomWay hat auch ordentlich welches. So 3-4 Grad kann man die Räder drehen ohne dass sich die Motoren auch nur rühren. Beim LegoWay wars eher weniger- ich hatte da nur einstufige Getriebe benutzt.
Die NXT-Motoren kenn ich nicht wirklich, aber die vom RCX kommen mit ner mittleren Untersetzung schon mit so ner Fuhre gut zurecht- anfangs hatte ich die grossen Räder direkt auf die Motoren gesteckt, das ging auch, frass aber ganz schön Strom und gelegentlich fehlte dann doch etwas Kraft.

Von deinem Programm versteh ich auch nur die Hälfte (bin halt nen fauler Arduino-Programmierer geworden *zugeb), aber: mit welcher Frequenz steuierst du die Motoren an?
Ich hatte bis vor kurzem die normale Arduino PWM benutzt, die läuft nur so mit ca. 500Hz- hab inzwischen aber den Timer umgestellt und steuere die Motoren aktuell mit rund 3.5KHz an- summt kaum noch, und das Ganze läuft weicher-bild ich mir jedenfalls ein.

Wie schnell läuft dein Programm? Es macht wirklich nen grossen Unterschied- darum wird auch mein Display derzeit im Betrieb nicht aktualisiert- das dauert ewig- und bremst mir die Regelung enorm aus.
Irgendwer sagte mal, zwischen 4 und 7ms pro Durchlauf sollen wohl noch gehen- ich bin bei knapp 3.5ms.

@ Rabenauge:
Danke für deine geduldige ausführliche Erklärung. Ich wollte dein Tom-mobil nicht schlecht reden.
Was du speziell zum D-Anteil und dem langsamen Kippen geschrieben hast, ist nachvollziehbar. Was den großen "Rest" betrifft, warte ich noch auf Erkenntnisschübe.

Aber noch eine andere Sache:
Woher kann es kommen es, dass die LCD-Ausgabe den Regler ausbremst? Werden der oder die Regler denn nicht im Interrupt abgearbeitet? Oder hat das mit den Arduino-Bibliotheken zu tun?

Nein, die Regelung ist nicht interruptgesteuert. Auf die Idee bin ich noch gar nicht gekommen...:-k
Ehrlich gesagt, ist die so gut, dass ich direkt mal gucke, ob das noch geht.
Möglicherweise kommen mir da einige Bibliotheken wirklich in die Quere aber falls nicht, ists allemal ne richtig gute Idee.

Und zum schlechtreden: Das Ding ist mehr oder weniger erstmal drauf los gebaut worden. Anfangs wollte ich ganz andere Motoren benutzen, war mir aber nicht im klaren, ob die nun optimal wären, und _dann_ fiel mir ein, dass ich da noch diese Panzerantriebe übrig hab und als ich das nächste Mal hingesehn hab, hing da schon etwas Sperrholz dran und...dann passten zufällig die Motorrad-Räder einigermassen dran -naja.
Im Grunde ist er einfach aus Resten zusammengewürfelt.
Hätte man das Teil von Anfang an kompletter durchkonstruiert, wäre einiges anders gelaufen.
Aber: die Lösung funktioniert. Mit kleinen Schwierigkeiten, aber es geht.
Gekostet hats trotzdem mehr, als ursprünglich gedacht, aber das ist gewöhnlich so..liegt aber auch daran, dass ich da eben gewisse Ansprüche habe. Wollte eigentlich als Display am liebsten Mini-Nixies (wegen dem zu Tom passenden Look) verbauen, davon bin ich aber abgekommen weil die Dinger nunmal empfindlich sind, obendrein recht teuer und keiner weiss, ob man in zwei Jahren noch welche bekommt (soweit ich weiss, werden _keine_ mehr hergestellt)...dann gab mir jemand den Tipp mit diesem winzigen Oled-Display und drinne wars. Hat ja, da es grafikfähig ist, auch ganz andere Möglichkeiten als Nixies..

Würd ich den TomWay heute noch mal bauen, würd ich vermutlich die Rechenlast aufteilen: zwei MiniDuinos rein (Arduino Mini oder Nano), einen für die Motorensteuerung, bzw. fürs balancieren, den anderen für den Rest.


So- aber nun guck ich mal nach den Interrupts- keine Ahnung ob ich das noch hinkriege aber das ist allemal nen Versuch wert.