ZitierenIch würde die Störquelle abschirmen, da es weniger Aufwand im Roboter bedeutet.
Aber hier ein paar Infos dazu: http://www.schirmungstechnik.de/site...r_20120605.pdf
Wäre es bei den Kabeln eigentlich sinnvoll zu schirmen? Was würde man dann eigentlich eher schirmen, die Kabel für die Motoren oder die Datenleitungen?
AI - Artificial Idiocy
Ich würde die Störquelle abschirmen, da es weniger Aufwand im Roboter bedeutet.
Aber hier ein paar Infos dazu: http://www.schirmungstechnik.de/site...r_20120605.pdf
Hi,
So tief stecke ich da bisher nicht drinEigentlich sollte so ein Motor auch PT2-Verhalten haben, da man als verzögernde Elemente sowohl Massenträgheit als auch Induktivität hat. Die elektrische Zeitkonstante ist allerdings meist viel kleiner als die Mechanische, daher ist davon nicht viel zu merken.. Allerdings hab ich mich im Netz ein wenig umgesehen, einen Motor für eine Drehzahlregelung als PT1 Strecke zu modellieren scheint nicht so unüblich zu sein.
Im Endeffekt habe ich das bisher auch so gemacht - außer bei den kurz angesprochenen Temperaturregelungen. Ich habe mal quasi im Blindflug eine Drehzahlregelung für einen gehackten Servo gemacht, das hat im Endeffekt auch einigermaßen geklappt. Fände es einfach interessant, es mal "besser" zu machen. Ich vermute mal dass man in dem Moment wo so eine Regelstrecke wirklich "nasty" wird, auch nicht viel andere Chancen hat (es sei denn man hat riiiiiesige Erfahrung).Ich hab meinen Regler jedenfalls größtenteils durch Variation der Reglerparameter eingestellt, also viel herumspielen, bis das Verhalten passt. Ist sicher nicht die effektivste Methode, aber so bekommt man schonmal ein wenig ein Gefühl dafür, welcher Regleranteil was bewirkt.
In Matlab bin ich eigentlich ganz fit, mit Simulink habe ich aber noch nie richtig was gemacht. Ist schon ganz nett was offenbar mit Simulink Control Design mit ein paar Clicks zu machen ist (okay, ist nur Werbung ...).Ich hab auch schon versucht, von meinem Motor ein möglichst komplettes Modell in Simulink aufzubauen [...]
Ja, da hast Du schon recht. Ist für mich aber okay, Daisy Chain ist jetzt sowieso nicht geplant.Dachte mir schon, dass du es so gelöst hast, finde ich persönlich aber nicht so gut. Der Grund ist schlicht, dass man dann ein Flachbandkabel hat und die Positionen der Buchsen sehr genau vermessen muss, damit es später ordentlich aussieht. Abgesehen davon kann man den Aufbau nicht so leicht modifizieren ohne gleich ein komplett neues Kabel zu fertigen. Es scheint jetzt auch nicht als hättest du ein Platzproblem auf der Platine.
Hm, also ich würde eher so rangehen, Datenleitungen zu schirmen und Versorgungsleitungen zum Motor - erst recht mit PWM - so kurz wie möglich zu halten, d.h. Leistungselektronik für den Motor so nah an den Motor wie möglich. Also diesen Punkt von vornherein beim Designprozess berücksichtigen. Der Ansatz ist aber eher intuitiv als begründetWäre es bei den Kabeln eigentlich sinnvoll zu schirmen? Was würde man dann eigentlich eher schirmen, die Kabel für die Motoren oder die Datenleitungen?
Das ist halt genau das Problem, eigentlich müsste man einen ordentlichen Feldbus verwenden. Jetzt mal den PCA9600 fürs I2C zu verwenden war ein Schritt in die Richtung. Vermutlich sollte man sich aber einfach mal CAN oder RS485 angewöhnen ...
Gruß
Malte
Soweit ich mich erinnere an meine Praktikumszeit beim DLR galt es immer für Elektronik: "Hast du einen Tiger, sperr ihn in den Käfig" Der Tiger ist in dem Fall der Motor mit dem PWM und den sperrt man so gut wie möglich von allen anderen Komponenten weg. Daher hilft der Tipp von Malthy um den Käfig klein zu halten, aber die Schirmung sollte trotzdem um den Motor sein. I2C ist so schlecht nicht, ich weiß natürlich nicht wie lange eure Datenleitungen werden aber so groß wird der Roboter wohl auch nicht, dass sowas gleich ins Gewicht fällt. Ich hatte bisher keine Probleme bei I2C mit Datenverlusten oder ähnlichem. Der PCA9600 ermöglicht Datenleitungen bis zu 20m - ich ähm glaube nicht, dass ihr so lange Leitungen in euren Robotern verlegen könnt.
Hi,
ich habe den Regelkreis jetzt doch mal als ganz simples Modell in Matlab nachgebaut. Falls jemand Interesse hat, hier der Code. Das ist ausdrücklich kein guter Matlab-Code!
Die Abhängigkeit der Drehzahl von der PWM wurde wie oben gesagt als PT1 angenommen, für Zeitkonstante und Streckenverstärkung wurden die empirisch ermittelten Werte verwendet. Um die Nichtlinearität durch die Schwelle wegzubekommen habe ich den PWM Wert einfach verschoben, die tatsächliche Aktivierung von 47 bis 255 sieht der Regler als 0 bis 208. Ich habe dann per Hand mit den Parametern gespielt, bis das Regelverhalten gut aussah. Es stellte sich schnell heraus, dass der D-Anteil keine wesentliche Verbesserung des Regelverhaltens bringt, ich habe ihn dann rausgeschmissen. Es war wohl nicht anders zu erwarten als dass der PID sehr gut mit einer perfekt linearen Regelstrecke funktioniert, die Frage ist also, wie gut das Ganze dann noch am realen Objekt funktioniert. Auch den Vergleich mit dem Modell finde ich dann nochmal spannend. Hier mal zwei Bilder des Regelverhaltens, einmal Sollwertsprünge, einmal Rampen:Code:clear if 1 % sprünge soll = [zeros(1, 100) ... ones(1, 200)*20 ... zeros(1, 100) ... ones(1, 200)*-40 ... zeros(1, 100) ... ones(1, 200)*60 ... zeros(1, 100) ... ones(1, 200)*80 ... zeros(1, 100)]; else % rampen soll = [-80:2:80 ... -80:1:80 ... -80:0.5:80 ... -80:0.25:80]; end % streckeneigenschaften v = 0.38; T1 = 13; % PID parameter Kp = 6; Ki = 0.35; Kd = 0; Ta = 1; % entspr. 2.048 ms % init y = 0; eSum = 0; eOld = 0; yOld = 0; for i = 1:length(soll) w = soll(i); %% PID e = w - y; eSum = eSum + e; P = Kp*e; I = Ki * Ta * eSum; D = Kd/Ta*(e - eOld); u = P+I+D; eOld = e; u(u>208) = 208; % max. stellwert u(u<-208) = -208; %% PT1 strecke y = yOld + 1/T1 * (v * u - yOld); yOld = y; %% doku y_(i) = y; u_(i) = u; w_(i) = w; e_(i) = e; P_(i) = P; I_(i) = I; D_(i) = D; end % darstellung disp(['Summenfehler: ' num2str(eSum)]) subplot(2, 1, 1) plot(soll, 'LineWidth', 2) hold on plot(y_, 'r', 'LineWidth', 2) set(gca, 'XLim', [0 length(y_)]) xlabel('Zeit [Ticks]') ylabel('Drehzahl') legend('soll', 'ist') subplot(2, 1, 2) plot(P_, 'LineWidth', 2) hold on plot(I_, 'g', 'LineWidth', 2) plot(u_, 'r', 'LineWidth', 2) set(gca, 'XLim', [0 length(y_)]) xlabel('Zeit [Ticks]') ylabel('Wert') legend('P', 'I', 'Stellwert')
Fortsetzung folgt ...
Gruß
Malte
War das auf dem Video eigentlich die maximale Geschwindigkeit? Wirkt für mich fast ein wenig langsam, wenn man berücksichtig, dass bei diesen Rädern nicht die volle Umdrehung in Vortrieb umgesetzt wird.
Ja, das ist das Maximum bei Nennspannung des Motors. Ich kann den Motor noch etwas treten, das sollte kein Problem sein, aber doppelt so schnell wird er nicht mehr. Ich gebe Dir Recht, er ist etwas lahm. Aber die Vorteile dieses Motors haben den kleinen Nachteil mit der geringen Geschwindigkeit überwogen (dessen erster war, dass ich die Motoren noch rumliegen hatteWar das auf dem Video eigentlich die maximale Geschwindigkeit? Wirkt für mich fast ein wenig langsam, wenn man berücksichtig, dass bei diesen Rädern nicht die volle Umdrehung in Vortrieb umgesetzt wird.
Gruß
Malte
Das ist jetzt erstmal alles nur simuliert?
Also ich hab auf jeden Fall einen ordentlichen D-Anteil drin, da dieser die Schwingneigung gut unterdrückt. Wenn man den P- und I-Anteil hochschraubt, neigt der Regler nämlich stärker zum Schwingen, der D-Anteil dämpft das dann wieder etwas, daher finde ich den eigentlich ganz sinnvoll.
Womit sendest du eigentlich deine Sollwerte an den Regler, kannst du das auch über Matlab machen oder lädst du da dann nachher nur die Messwerte rein zum rechnen und darstellen?
AI - Artificial Idiocy
Hi,
Genau, das ist eine reine Simulation. Und da war der Vorteil, den der D-Anteil für die Regelgüte dann noch gebracht hat, wirklich minimal (beurteilt nach dem Summenfehler über alles). Falls Du Matlab hast, kannst Du mit dem Code auch rumspielen, dann siehst Du es. Kann auch vielleicht noch ein Bild dazu nachliefern. Wie groß der Unterschied zur Realität dann ist, weiß ich natürlich nicht. Das finde ich aber sehr spannend und freue mich insofern darauf, das jetzt auch auf der Motorelektronik zu implementieren. Ich habe leider gerade wenig Zeit, ich hoffe dass ich zwischendurch mal dazu komme. Ich habe auch noch das Problem, dass mein Sensorsignal ziemlich stark rauscht, ich muss da also noch auf eine gute Art filtern, ohne das System insgesamt deutlich träger zu machen.Das ist jetzt erstmal alles nur simuliert?
Also ich hab auf jeden Fall einen ordentlichen D-Anteil drin, da dieser die Schwingneigung gut unterdrückt. Wenn man den P- und I-Anteil hochschraubt, neigt der Regler nämlich stärker zum Schwingen, der D-Anteil dämpft das dann wieder etwas, daher finde ich den eigentlich ganz sinnvoll.
Im Moment ist das noch ganz stumpf gemacht, für die Kennlinien hab ich die Sollwerte hart in den Programmcode geschrieben. Es spricht ja aber grundsätzlich nichts dagegen, die über RS232 zu senden. Später möchte ich da ja I2C verwenden.Womit sendest du eigentlich deine Sollwerte an den Regler, kannst du das auch über Matlab machen oder lädst du da dann nachher nur die Messwerte rein zum rechnen und darstellen?
Gruß
Malte
Hab da wirklich gerade nochmal ein wenig mit herumgespielt und an den Reglerparametern gedreht. Hab auch mal einen Anti-Windup für den Integratoranteil wie bei mir eingebaut. Mir ist auch aufgefallen, warum du keinen D-Anteil brauchst: du hast deinen Regler auf Drehzahlebene aufgebaut, ich hingegen auf Positionsebene. Jedenfalls hab ich jetzt folgende Parameter verwendet:
Kp=50
Ki=3
Kd=1
Der Regler funktioniert jetzt schön zackig und ohne Überschwinger
Hier nochmal der ganze Code:
Code:clear all; close all; clc; if 0 % sprünge soll = [zeros(1, 100) ... ones(1, 200)*20 ... zeros(1, 100) ... ones(1, 200)*-40 ... zeros(1, 100) ... ones(1, 200)*60 ... zeros(1, 100) ... ones(1, 200)*80 ... zeros(1, 100)]; else % rampen soll = [-80:2:80 ... -80:1:80 ... -80:0.5:80 ... -80:0.25:80]; end % streckeneigenschaften v = 0.38; T1 = 13; % PID parameter Kp = 50; Ki = 3; Kd = 1; Ta = 1; % entspr. 2.048 ms % init u=0; y = 0; eSum = 0; eOld = 0; yOld = 0; for i = 1:length(soll) w = soll(i); %% PID e = w - y; if abs(u)<208 %Anti-Windup, Integrator abschalten wenn Ausgang in Begrenzung eSum = eSum + e; end P = Kp*e; I = Ki * Ta * eSum; D = Kd/Ta*(e - eOld); u = P+I+D; eOld = e; u(u>208) = 208; % max. stellwert u(u<-208) = -208; %% PT1 strecke y = yOld + 1/T1 * (v * u - yOld); yOld = y; %% doku y_(i) = y; u_(i) = u; w_(i) = w; e_(i) = e; P_(i) = P; I_(i) = I; D_(i) = D; end % darstellung disp(['Summenfehler: ' num2str(eSum)]) subplot(2, 1, 1) plot(soll, 'LineWidth', 2) hold on plot(y_, 'r', 'LineWidth', 2) set(gca, 'XLim', [0 length(y_)]) xlabel('Zeit [Ticks]') ylabel('Drehzahl') legend('soll', 'ist') subplot(2, 1, 2) plot(P_, 'LineWidth', 2) hold on plot(I_, 'g', 'LineWidth', 2) plot(u_, 'r', 'LineWidth', 2) set(gca, 'XLim', [0 length(y_)]) xlabel('Zeit [Ticks]') ylabel('Wert') legend('P', 'I', 'Stellwert')
AI - Artificial Idiocy
Berechtigungen
Lesezeichen