[gelöst:] PID library - funktioniert [-nicht-]

[Rabenauge]

Ja, muss er.
Möglicherweise hast du Kp,Ki,Kd nicht korrekt justiert?
DAS sind die Parameter, die die Regelung beeinflussen.
Den Wert für Kd z.B. halte ich für seeeehr aggressiv-aber es kommt natürlich immer auf die konkrete Aufgabe (bzw. den Aufbau) an.
Kennst du dich mit PID-Reglern denn aus?

[HaWe]

ja, kenne mich schon aus damit.
Habe selber einen *SEEHR* guten asynchronen für >= 3 Motoren programmiert (für den NXT).

Wenn die PID-Werte nicht stimmen, macht er sowas wie in 1):
und wenn es stimmt, so was wie in 2):

aber immerhin: in jedem Fall erreicht er den Zielwert, unabhängig vom Tuning oder Finetuning, ob mit oder ohne Overshooting!

So wie hier beim NXT muss es doch nun auch mit dem Arduino-PIDregler funktionieren, tut es aber nicht, er überschießt endlos und regelt ÜBERHAUPT NICHT wieder auf den Sollwert zurück!

[Rabenauge]

Dat macht der Arduino-PID auch, wenn alles richtig ist. Sonst läge mein Segway dauernd auf der Nase (ab und zu allerdings tut ers noch, liegt aber nich an der Regelung).

Leider hab ich nicht die Zeit, dein Programm mal genauer zu analysieren, ich tu mich bei fremden Programmen immer bissel schwer und spiel grad mitm Monstertruck, der erfordert auch grade einiges an Hirnschmalz.
Wichtig ist z.B. dass zwischen Sensor und Regler _nichts_ kommt.
Wenn der Sensorwert verzögert geliefert wird (weil _irgendwas_ dazwischen noch Zeit braucht), kommt Murks raus.
Da du mit Interupts arbeitest, die Regler aber wiederum auch zeitgesteuert laufen (Samplingtime), könnte sich da ggf. was in die Quere kommen.
Die Samplintime legt _nur_ fest, wie oft die Regelung mit neuen Sensordaten (oder den alten, wenns keine neuen gibt) neu durchkalkuliert wird-regeln tut sie in der Zwischenzeit auch.

[HaWe]

Im Augenblick ist kaum was dazwischen außer meine Motor-Routine, das soll auch so bleiben.
Das kann nicht der Grund sein, dass er überschießt und nicht mehr zurückrudert.

Es kommt später aber tatsächlich mit absoluter Sicherheit noch jede Menge mehr dazwischen,
zum Einen noch mehr Motoren (insg. 6 mit Mega), deren Werte an die PID-Controller übergeben und gestellt werden müssen,
und dann noch eine i2c-Read/Write-Funktion, die Werte und Befehle vom Master (NXT) in Empfang nimmt und Sensorwerte regelmäßig wieder zurückschickt. Diese haben ein delay jew. von 10-20ms, plus Codierung/Decodierung der i2c-msg-arrays.
Anders geht es nicht.

Ein guter PID-Controller vergleicht aber die echten, gestoppten loop-Zeiten und bringt sie in den I- und D- Summanden mit ein, damit die echte delta-Zeit zur Steuerung zu grunde gelegt wird. Da macht dann eine Verzögerung nichts aus.
reg = P + I*dt + D/dt

Ansonsten: Zeitscheiben-Multitasking, jeder Motor-Thread und jeder i2c-Thread in eine extra Zeitscheibe. So mache ich es beim NXT, das geht sogar mit einer VM, die alles um den Faktor 10 verlangsamt, in Echtzeit.

Da wäre also noch was deutlich ausbaufähig, beim Mega.

[Serenifly]

Der Arduino Due hat einen Prozessor der in etwa dem NXT entspricht. ARM Cortex mit 84MHz. Das wäre vielleicht eher etwas für dich. Musst halt mit den 3,3V aufpassen.

Da funktioniert aber die Timer Geschichte nicht mehr so wie du es im Moment machst. Da gibt es aber Libs dafür:
https://github.com/ivanseidel/DueTimer

[HaWe]

[OT]
Als NXT-Ersatz muss er nicht taugen, außerdem fehlt mir ja schon beim NXT als "Hauptrechner" oder i2c-Master ausreichend RAM (er hat nur 64 kB) - 512kB RAM aufwärts könnte ich gebrauchen.

Wenn aber der neue dann unter Linux läuft, dann kann man sicher gpp Toolchains mit POSIX libs verwenden, die pthread unterstützen (wie EV3).

Aber schon als i2c-Slave, als Motor- und Sensor-Multiplexer, wäre MT sinnvoll .
Denn das Betriebssystem an sich muss ja gar nicht MT-fähig sein, wie die Beispiele RCX (Renessas H8/300), NXT (ARM 8 ), und Robo TX (ARM9)  zeigen, man braucht nur eine VM, die das für einen erledigt .

So eine VM müsste sicherlich auch  auf dem Mega einzurichten sein.
Timer-Interrupts wären dann überflüssig und man hätte mit einem  Zeitscheiben-Multithreading ein absolut ausreichendes Echtzeitverhalten (ein Dutzend oder mehr parallel-laufende, unabhängige loop-Tasks). Der Mega ist dazu vom cpu-Takt und Speicher leistungsfähig  genug.
[/OT]

Trotzdem würde mich interessieren, warum der PID "Regler" das Überschießen des Motors nicht gegenreguliert. Nach meiner Meinung müsste mein Code mit den Encodern und den Motor-pwm- und Richtungspins doch richtig funktionieren! (direkt aufgerufen funktionieren sie ja auch korrekt nach Stärke und Richtung!)

[Rabenauge]

Wie gesagt- an der PID-Lib. wird es nicht liegen, die Regler funktionieren ja nicht nur bei mir.

Was da nun genau los ist....

Zum anderen Thema: kennst den? http://www.roboternetz.de/community/threads/59698-HaikuVM-A-Java-VM-for-ARDUINO-and-other-micros-using-the-leJOS-runtime

Für mich persönlich ist Java zwar irgendwas zwischen Pest und Ebola aber wers mag....

[Serenifly]

Also zumindest auf dem NXT ist leJOS super. Und von daher kommt das. Als ich da damit was gemacht habe, habe ich erst ein C++ RTOS ausprobiert, aber der Prozessor ist so leistungsstark, dass die VM problemlos läuft und noch massig Leistung da ist. Vor allem ist die API wirklich gut und es schon zig Zeug dabei das man bei anderen Firmwares erst per Hand implementieren müsste.

[HaWe]

Pest und Cholera - oder Ebola - das ist Java/Lejos auch für mich.
C# genauso, alles mit OOP eben
wenn ich scho new-implements-extends höre, kann ich kotzen.

Natürlich habe ich es schon benutzt, auf dem RCX genau wie auf dem NXT, aber ich hätte die Teile danach fast an die Wand gedonnert. C# auf dem EV3 genauso, wenn nicht NOCH schlimmer.
Aber schnell ist der Java JIT compiler, das muss man ihm lassen.
Trotzdem, kommt nicht in Frage. Genausowenig wie Ebola und Pest.

Aber ich will mit dem PID controller noch nicht aufgeben- ob mein Programm mal wer mit L293D und Encodermotoren bei sich nachbauen und ausprobieren kann?


ps,
Github ist auch so ein rotes Tuch für mich.
Wer hat DIESES User-Interface erfunden? den sollte man im Hindukush steinigen!

Code: [Select]


examples Typo fix. a year ago
.gitignore Ignore file modified a year ago
DueTimer.cpp Fix for servo Library. Enable USING_SERVO_LIB in DueTimer.h 3 months ago
DueTimer.h Fix for servo Library. Enable USING_SERVO_LIB in DueTimer.h 3 months ago
README.md Explanation improvement 3 months ago
TimerCounter.md Adding documentation about the hardware of the Timer Counter a year ago



pps
das RTOS auf dem NXT ist Granate! Du meinst sicher nxtOSEK? Allerdings braucht man für die Installation schon nen Monat und ein weiteres halbes Jahr um das erste Demo-Programm zum Laufen zu kriegen.

[Serenifly]

Du machst dir ständig selbst Probleme

Rechte Leiste -> runter -> Download ZIP

Wobei es sehr schön ist, dass man sich da die Dateien anschauen kann ohne alles runterzuladen. Manchmal will man eben nur nachschauen wie etwas implementiert ist

Du meinst sicher nxtOSEK?

Ja, wobei das wie ich es ausprobiert habe sowas wie pre-Alpha war. Geschwindigkeit ohne Ende, ja, aber am Ende lief irgendwie gar nichts mehr. Nicht mal die einfachsten Programme. Am Anfang ging alles, aber dann hat es gestreikt. Keine Ahnung wieso.
Und dann wie gesagt eine spärliche API. Da hat mir dann leJOS viel Arbeit angenommen. Und für meine Anwendung brauchte ich sowieso nicht die maximale Geschwindigkeit, da hat das perfekt gepasst.

Wenn ich mir die version history anschaue hat sich da inzwischen aber was getan

[HaWe]

mein Denken ist einfach anders strukturiert
aber im Moment tu ich mir den Due Code nicht an, ich hab ja keinen.
Mir sind Code-Listings untereinander, ungezipped, mit Beschreibung, alles im Klartext,  allerdings trotzdem lieber.
Aber alles zu seiner Zeit.

Jetzt erst noch mal zurück zum nicht funktinierenden aber immerhin laufenden sog. PID-"Regler"... 8-)

ps
zu nxtOSEK guck jetzt mal hier:
http://www.mindstormsforum.de/viewtopic.php?f=25&t=8102

[HaWe]

da stelle ich gerade fest:
im Original-PID-Basis-Programm wird ja als Output nur eine pwm geschrieben (analogWrite(pin,Output) ):

Code: [Select]


void loop()
{
 Input = analogRead(0);
 myPID.Compute();
 analogWrite(3,Output);
}


Da ist eine Richtungssteuerung doch überhaupt nicht möglich, denn pwm-Output ist doch immer positiv!?!
Wo werden hier die Richtungspins gesetzt

Das kann doch gar nicht funktionieren, wenn der Zielwert kleiner ist als der Ist-Wert (also z.B. nach Überschießen)!!

[Rabenauge]

Ne PWM wird da nicht geschrieben, man kann es aber als PWM benutzen.
Der Regler berechnet einfach nur _irgendeine_ Grösse-was damit dann angestellt wird, interessiert ihn nicht.
Das muss man sich dann schon passend aufdröseln, z.B. indem man, wenn man die Dino-PWM benutzen will, die OutputLimits auf -255, 255 setzt, das Vorzeichen als Richtungsinformation weiter benutzt und den PWM-Wert als abs(Wert) auf die PWM-Leitung gibt, oder eben je nach konkretem Aufbau.

Diese Lösung ist viel flexibler, weil mans eben an seine konkrete Anwendung anpassen kann, wie man es braucht (du z.B. steuerst deine Motoren ja ganz anders an als ich meine- es geht aber bei beiden).
Gibt ja auch Anwendungsfälle für solche Regler, bei denen gar keine Motoren bedient werden.

[HaWe]

ach so ist das...

was für Outputs werden denn von dem Controller erzeugt, für
a) Input < Setpoint
b) Input == Setpoint
c) Input > Setpoint

bzw wo kann man die definieren?
es wäre ja sinnvoll für

a) Input < Setpoint => Output = 1...255
b) Input == Setpoint => Output = 0
c) Input > Setpoint => Output = -1...-255

ausgeben zu lassen, und dafür habe ich ja auch schon eine Steuer-Lösung in meinen Motorfunktionen.

[Rabenauge]

http://playground.arduino.cc/Code/PIDLibrary

Lies mal ganz unten die Links zu den "Funktionen". Da steht das alles recht gut beschrieben.
Auch zu SetOutputLimits(), das ist das,w as dich grad interessiert.
Wenn du genau wissen willst, was bei einem gegebenen Input passiert-einfach mal die serielle Konsole benutzen, grad bei solchen Geschichten, die immer abgestimmt werden müssen, eine grosse Hilfe.