Roboterbasis mit Mecanum Wheels

Moin!

Zum Jahresende finde ich wenigstens mal die Zeit, noch so diverse halbfertige Projekte zu bearbeiten, die ich noch in der Pipeline habe ... :-) Ein bißchen weitergekommen bin ich in den letzten Tagen mit folgendem:

Neben den Allseitenrädern, mit denen ich bisher schon ein wenig experimentiert habe, gibt es ja noch die sog. Mecanum Wheels. Ich habe mir kürzlich einen Satz 100 mm Mecanum Wheels direkt vom chinesischen Hersteller nexusrobot besorgt, um auch diesen Radtyp mal praktisch kennenzulernen. Die Räder machen einen sehr guten Eindruck.

Anhang 29536 Anhang 29537

Ich habe Adapternaben zum Verbinden der Räder mit vier Getriebemotoren, die ich noch rumliegen hatte, angefertig:

Anhang 29538 Anhang 29539 Anhang 29540

Die Motoren mit den Rädern wurden ihrerseits an einer einfachen Rahmenkonstruktion aus Aluminium-Strangprofilen befestigt. Somit war auf ziemlich simple Art eine mobile Basis mit Mecanum Wheels schnell fertiggestellt:

Anhang 29541 Anhang 29542 Anhang 29543

Der nächste Schritt besteht nun darin, die Motorachsen mit Drehencodern auszustatten und geeignete Motortreiber aufzubauen, um die erforderliche Drehzahlregelung für die vier Achsen umzusetzen.

Auf meiner Homepage gibt's noch ein paar Bilder mehr.

Fortsetzung folgt ... :-)

Gruß
Malte

Mal ein kurzes Update ...

Ich habe mittlerweile die Elektronik für die Getriebemotoren fertig. Jeder Motor bekommt eine Platine mit eigenem mega168. Die AVRs werden als I2C Slaves von dem übergeordneten Master-Controller angesprochen, optional ggf. über einen PCA9600. Ein AS5048A (magnetischer Drehencoder) misst die Stellung des Motorabtriebs. Das klappt bei dem Motor sehr gut, weil der Abtrieb auf der Rückseite des Getriebekastens rausguckt. Dort befindet sich der Magnet für den Encoder, die Platine mit dem Encoder und dem Rest der Elektronik ist über Sechskantbolzen in den Befestigungslöchern der Getrieberückwand verschraubt. Dadurch ist die Platine genau ausgerichtet. Motortreiber ist ein - eventuell etwas unterdimensionierter - DRV8801. Der lokale AVR wird dann später auf dieser Grundlage eine Drehzahlregelung für das jeweilige Rad durchführen. Die Regelung zu implementieren ist jetzt der nächste Schritt. Hier ein paar Bilder:

Anhang 29821 Anhang 29822 Anhang 29823
Anhang 29824 Anhang 29825

Fortsetzung folgt!

Gruß
Malte

Mich wunderts, dass das hier keiner kommentiert.
Ich finde, du hast da eine wirklich elegante Lösung aufgebaut, schön kompakt.
Ist der Controller eigentlich nur da, um Daten durchzureichen (PWM, Sensordaten) oder direkt den Motor zu regeln, sodass man ihn nur mit Sollwerten füttern muss? Letzteres wäre ja eigentlich sinnvoller. Aus eigenen Tests mit solchen Sensoren und Getriebemotoren hab ich in Erfahrung bringen können, dass das Getriebespiel sich gerne mal negativ auf die Regelgüte auswirkt, hast du da schon ein wenig mit herumgespielt oder kommt das erst noch?

Hi,

Zitat:

---

Mich wunderts, dass das hier keiner kommentiert.

---

Naja, ich stelle ja nicht direkt irgendwelche Fragen, insofern kann ich mir schon denken dass man mal draufguckt und dann weitergeht - würde ich vielleicht auch so machen ... :-)

Zitat:

---

Ist der Controller eigentlich nur da, um Daten durchzureichen (PWM, Sensordaten) oder direkt den Motor zu regeln, sodass man ihn nur mit Sollwerten füttern muss?

---

Letzters. Es ist genau die Idee, dass die Antriebe lokal regeln, und nur "von oben" gesagt bekommen, was sie machen sollen. Für diese Anwendung will ich ja nur eine Geschwindigkeitsregelung realisieren, aber da der Encoder die Position absolut ausgibt, kann man natürlich auch noch eine Positionsregelung drüberlegen. Dann hätte man einen relativ kompakten Stellmotor, einen etwas kräftigeren Servo quasi.

Mir gefällt dieses starkt modularisierte Konzept grundsätzlich gut, auch wenn es in manchen Fällen (scheinbar) etwas overkill ist. Ist ja quasi objektorientiert in Hardware: vier "Instanzen" eines gleichen Antriebs, der dann nur spezifisch konfiguriert und angesprochen wird.

Ich habe bisher fast ausschließlich mit Schrittmotoren gearbeitet (und sie dabei auch wirklich lieb gewonnen ;-)), insofern fehlt mir die Erfahrung mit Geschwindigkeits- (oder gar Positions-) regelungen von DC Motoren. Klar ist Getriebespiel da ein Problem, ich würde aber vermuten, dass das bei Positonsregelungen noch deutlich stärker reinhaut als bei Geschw.reglungen, weil das Spiel dabei ja gerade um den Punkt herum auftritt, wo man hin will.

Gruß
Malte

Das stimmt, das Problem ist bei Drehzahlregelung eher weniger spürbar. Das Konzept mit der dezentralen Regelung finde ich auch sehr gut, so kann man alles recht übersichtlich halten. Besonders interessant finde ich ja die Integration der Elektronik mit dem Motor, ich hätte es wahrscheinlich eher so gemacht, dass die Elektronik irgendwo in der Nähe des Hauptcontrollers liegt und dann Kabel zum Motor und Sensor gehen, so hätte man aber nur Versorgungsleitung und Busleitung, die man dann wohl auch einfach hintereinander hängen könnte. Verringert den Verkabelungsaufwand schön :)
Nur müssten sich dann die Motorregler auch vernünftig addressieren lassen. Wie machst du das eigentlich genau mit der Datenkommunikation? Gerade da hatte ich irgendwie Probleme mit, weil ich da einfach nicht weiß, was da gut geeignet wäre. Sind die Regler-Controller auch über den Bus parametrierbar?

Hey,

Zitat:

---

Das Konzept mit der dezentralen Regelung finde ich auch sehr gut, so kann man alles recht übersichtlich halten. Besonders interessant finde ich ja die Integration der Elektronik mit dem Motor, ich hätte es wahrscheinlich eher so gemacht, dass die Elektronik irgendwo in der Nähe des Hauptcontrollers liegt und dann Kabel zum Motor und Sensor gehen, so hätte man aber nur Versorgungsleitung und Busleitung, die man dann wohl auch einfach hintereinander hängen könnte. Verringert den Verkabelungsaufwand schön :)

---

Die Platine direkt am Motor unterzubringen war - für meine Begriffe - in mehrerlei Hinsicht nur folgerichtig. Erstens ging es ja wie gesagt um ein modulares Konzept. Wenn alles klappt und funktioniert, habe ich eine in sich abgeschlossene Einheit, die man so wie sie ist auch an anderen Stellen einsetzen kann. Weil ich den AS5048 als Encoder verwenden wollte (interessierte mich weil ich mal den AS5045 mit SSI im Einsatz hatte, hatte außerdem noch Samples davon), war klar, dass ich eh eine Platine brauche, die sich über dem Abtrieb des Getriebes befinden muss. Und weil es natürlich auf eine präzise Ausrichtung des Sensors ankommt, war's auch irgendwie logisch, die Schraubenlöcher im Getriebekasten zur Befestigung zu verwenden, die sind nämlich sehr genau zu dem Lager der Abtriebswelle ausgerichtet. Außerdem hätte ich es nicht so schön gefunden, die recht hochfrequente und leistungsstarke PWM für die Motoren über unnötig lange Kabel zu verlegen. Ich hab quasi keine Ahnung von EMV, aber intuitiv würde ich sowas vermeiden, wenn's anders geht. Umgekehrt hätte ich auch das 2 MHz SPI über längere Strecken "frei fliegend" verlegen müssen, wenn ich nur den Sensor am Motor gehabt hätte und den Rest zentral. Auch das ist sicher machbar, einfacher ist es aber vermutlich doch, auch das lokal zu lassen. Die Verkabelung ist so eigentlich auch recht schmerzfrei: Es gibt den Stromversorgungsanschluss für den Motor als Schraubklemme und einen Flachbandkabelanschluss für die Logikversorgung und den Bus. Weil der Bus I2C ist (s.u.), kann man mehrere von den Antriebseinheiten auch als Daisy-Chain hintereinander hängen wenn man will, oder eben sternförmig vom Master - das habe ich jetzt hier geplant.

Zitat:

---

Wie machst du das eigentlich genau mit der Datenkommunikation? Gerade da hatte ich irgendwie Probleme mit, weil ich da einfach nicht weiß, was da gut geeignet wäre.

---

Tja, das ist auch so ein Thema, gerade für größere Roboter ... Wollte immer schonmal einen Thread dazu hier eröffnen, mache ich vielleicht bald mal :-). Weil es praktisch für mich gut klappt, verwende ich für solche Zwecke seit mehreren Jahren I2C. Das ist natürlich kein Feldbus, aber weil er relativ wenig overhead hat und auch low-level gut zu beherrschen ist, ist das für meine Zwecke eine gute Sache (ich brauche idR keine allzu großen Bandbreiten). Im Endeffekt ist der I2C auch erstaunlich robust - meiner unmaßgeblichen Erfahrung nach. Ich mache die Pull-Ups immer möglichst klein, dann funktioniert das sogar über längere Kabel. Meistens baue ich in das Protokoll noch eine minimale Fehlerkontrolle (CRC), damit ist es dann recht stabil. Diesmal habe ich auf der Platine noch einen PCA9600 vorgesehen, der macht aus dem I2C einen differentiellen Bus, den man quasi als Feldbus einsetzen kann. Ich habe noch keine Erfahrung damit, und mich bisher ehrlich gesagt auch nur oberflächlich eingelesen. Dieses Projekt war mal eine Möglichkeit ein wenig praktische Erfahrung mit dem Baustein und dem Konzept zu sammeln ...

Zitat:

---

Sind die Regler-Controller auch über den Bus parametrierbar?

---

Das ist ja nur eine Frage der Firmware :-)

Also über die Frage eines geeigneten Busses für (größere) Roboter würde ich durchaus gerne - ggf an anderer Stelle - nochmal diskutieren, auch wenn für dieses Projekt die Wahl auf I2C gefallen ist.

Gruß
Malte

Sehr schönes Konzept und ich finde eine Modulare Lösung auch immer schöner, da es einfach weniger Kabel sind und man oft gleiche Komponenten verwenden kann. In Bezug auf Daisy-Chain würde ich dir empfehlen pro Platine zwei Datenstecker vorzusehen, dann kann man einen Stecker als Eingang und einen als Ausgang verwenden. Ist ein wenig angenehmer beim verkabeln.

I2C sollte eigentlich für alle Hobby Roboter ausreichen, auch wenn es ein Protokoll für Platinenbus ist.

Hi,

Zitat:

---

In Bezug auf Daisy-Chain würde ich dir empfehlen pro Platine zwei Datenstecker vorzusehen, dann kann man einen Stecker als Eingang und einen als Ausgang verwenden. Ist ein wenig angenehmer beim verkabeln.

---

Ich habe ja einen Stecker für Flachbandkabel-Quetschverbinder vorgesehen. Ein Flachbandkabel mit mehreren Buchsen schleift die Signale ja quasi auch einfach nur durch. Insofern braucht man für Daisy Chain nichtmal mehr als eine Buchse pro Slave.

Ich habe mir mittlerweile mal ein paar Sprungantworten des Antriebs angeguckt. Ich habe dazu die PWM in Schritten von 16 von 15 bis 255 (8 bit PWM) erhöht und rückwärts wieder erniedrigt. Währenddessen habe ich die Drehzahl in einem Intervall von 2.048 ms aufgezeichnet. Die Treppe habe ich viele Male wiederholt und dann samplegenau gemittelt. Das Video nur zur Anschauung, hat ansonsten keinen Erklärungswert.

http://youtu.be/izpkCuhH2BE

Abgesehen von einer Schwelle am unteren Ende des Drehzahlbereiches verhält sich das Ding recht linear - besser als ich erwartet habe. Ich habe die Ausgleichsvorgänge nach einem Sprung mal als PT₁-Glied gefittet (f(t) = k*(1-e^-t/τ)), auch das kommt sehr gut hin. Schaut man sich die Zeitkonstanten über sämtliche Sprünge an, sind sie einigermaßen im selben Bereich, wiederum abgesehen vom ersten Schritt nach der Schwelle, aber das ist ja auch nicht weiter überraschend. Folgend mal als Bild (die x-Achse ist etwas wild, aber man sieht wohl was es bedeutet). Die mit höherer Auflösung gezeigten Sprungantworten sind beliebige Beispiele.

Anhang 29857

Jetzt muss ich mal überlegen wie ich weitermache. Ein wenig (wirklich nur ein wenig) mehr Erfahrung habe ich mit Temperaturregelungen, die Regelstrecken mit denen ich da bisher zu tun hatte, konnte man enigermaßen als PT₂ modellieren, was eine Parametrisierung über die klassischen Einstellregeln erlaubt hat (wobei ich dann immer auch noch per Hand nachgetuned habe). Da das PT₁ natürlich keine Verzugszeit hat, die bei den Einstellregeln (ich kenne nur Chien/Hrones/Reswick und Ziegler/Nichols wie hier beschrieben) aber immer im Nenner steht, kann man diese nicht sinnvoll verwenden. Vielleicht ist das mal ein Anlass, ein ordentliches Modell in Matlab zu basteln.

Gruß
Malte

Ah, es geht weider :)
Eigentlich 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. 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. Ich hab auch schon versucht, von meinem Motor ein möglichst komplettes Modell in Simulink aufzubauen, mit dem Versatz in der PWM, mit Spannungsbegrenzung und mit Getriebespiel. Was da herauskommt sieht allerdings immernoch anders aus als das, was ich messe. Kommt vielleicht auch ein wenig daher, dass der fertige Block für Getriebespiel (Backlash) nur anhand der Geschwindigkeit umschaltet und nicht anhand der wirkenden Kraft. Es können aber auch noch andere Unstimmigkeiten vorhanden sein.

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.

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?

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,

Zitat:

---

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

---

So tief stecke ich da bisher nicht drin :-). Allerdings hab ich mich im Netz ein wenig umgesehen, einen Motor für eine Drehzahlregelung als PT₁ Strecke zu modellieren scheint nicht so unüblich zu sein.

Zitat:

---

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.

---

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

Zitat:

---

Ich hab auch schon versucht, von meinem Motor ein möglichst komplettes Modell in Simulink aufzubauen [...]

---

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

Zitat:

---

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.

---

Ja, da hast Du schon recht. Ist für mich aber okay, Daisy Chain ist jetzt sowieso nicht geplant.

Zitat:

---

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?

---

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ündet :-). Bei der Steckerbelegung für das Flachbandkabel habe ich es jetzt zumindest so gemacht, dass sich jede Datenleitung mit einer Masseleitung abwechselt. Das wird sich aber wohl primär auf das Übersprechen zwischen den Datenleitungen auswirken (bei längeren I2C Leitungen ja durchaus ein Punkt). Ansonsten wäre Twisted Pair wohl noch eine Variante, ist aber natürlich etwas unbequemer als Flachband.

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!

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')

---

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:

Anhang 29864 Anhang 29865

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.

Zitat:

---

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 hatte :-)). Mir geht's ja auch nur um's Prinzip, dass das Ding dann etwas gemächlich sein wird, ist schon okay ...

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?

Hi,

Zitat:

---

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.

---

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.

Zitat:

---

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?

---

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.

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 :)

Anhang 29867 Anhang 29868

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')

---

Hey,

Zitat:

---

Mir ist auch aufgefallen, warum du keinen D-Anteil brauchst: du hast deinen Regler auf Drehzahlebene aufgebaut, ich hingegen auf Positionsebene.

---

Achso, sorry, haben wir da die ganze Zeit aneinander vorbeigeredet? Mir geht es erstmal nur um eine Drehzahlregelung, ist ja nur als Antrieb für die Räder gedacht. Eine Positionsregelung könnte man draufsetzen, ich würde die aber auf einer Drehzahlregelung aufbauen.

Gruß
Malte

Erstmal: Sehr cooles Projekt.

Mit welcher Regelfrequenz möchtest du denn arbeiten?
Bin gerade nämlich auf der Suche nach Sensoren für mein Projekt. Ich will einen ähnlichen Bot als Studienarbeit bauen, allerdings möglichst viel mit dem 3D Drucker arbeiten. Also werden die Räder gedruckt und mit Kugellager gelagert. Da das ganze Gebilde möglichst günstig und schnell reproduzierbar sein soll, werde ich beim Antrieb auf RC-Motor setzen und ihn untersetzen (muss erstmal evaluieren, ob mein 3D Drucker auch hinreichend genau und steif drucken kann). Deine Idee mit der separaten Regelelektronik für jedes Rad klingt sehr verlockend, habe mir das auch überlegt, allerdings will ich nicht nur die Drehzahl regeln, sondern auch die Drehung ( mittels Gyro ) um den Schlupf zu kompensieren.


MfG,
C_M

Hi!

Zitat:

---

Erstmal: Sehr cooles Projekt.

---

Danke sehr! :-)

Zitat:

---

Mit welcher Regelfrequenz möchtest du denn arbeiten?

---

Die ISR mit dem Regler wird alle 2.048 ms aufgerufen (ergibt sich aus dem 8 MHz Takt mit 64er Teiler für den 8 Bit Timer Overflow). Das sind also etwa 488 Hz Zyklusfrequenz. Ich filtere das Signal von dem Drehgeber aber nochmal deutlich, der Regler könnte durchaus auch langsamer laufen.

Zitat:

---

[...] allerdings will ich nicht nur die Drehzahl regeln, sondern auch die Drehung ( mittels Gyro ) um den Schlupf zu kompensieren.

---

Ich habe auf der Hauptplatine - die layoutet ist, die ich aber noch nicht habe herstellen lassen - ein MPU6050 Modul als IMU vorgesehen, damit könnte man evnt "Widersprüche" zwischen der Ansteuerung der Räder und der tatsächlichen Bewegung des Vehikels ermitteln, ob das praktisch funktionieren wird (und mit welcher Genauigkeit) weiß ich nicht.

Ich kann hier bald nochmal ein paar Infos nachlegen, die Drehzahlregelung läuft jetzt einigermaßen, ich bin gerade dabei, die Platinen für die anderen Antriebe zu bestücken.

Gruß
Malte

Eine Frage, da ich selber plane einen Roboter auf Mecanum Rädern zu bauen: Wie laut sind dieser Räder auf Laminat?
Auf den Videos die ich bisher gesehen habe, waren die hartplastik Räder systembedingt sehr laut. Gibt es diese auch mit einer Gummierung?

Hi Hanno,

Sehr hart sind diese Rollen auf jeden Fall nicht. Sie sind ein klein wenig weicher als zB typisches hart-PVC, aber auch nicht wie aus Gummi. Der Hersteller sagt die Rollen seien aus "PP+PE", also Polypropylen und Polyethylen. Wenn ich das richtig sehe haben die Rollen einen härteren Kern, vermutlich aus PE und dann eine Außenkörper, vermutlich aus PP. Wie laut die Dinger wirklich sind, kann ich erst sagen, wenn ich alle vier Räder motorisiert habe. Ich hatte aber auch immer ein wenig den Eindruck, dass die Laufgeräusche von manchen Omniwheels (gilt für Mecanum dann vermutlich ähnlich) nicht nur vom Aufsetzen der Laufrollen herrühren, sondern auch vom Lagerspiel in den Aufhängungen der Rollen. Die Lagerung der Rollen bei diesen Mecanum Rädern ist sehr gut, jede Rolle läuft auf zwei Kugellagern.

Gruß
Malte

Moin!

Ich bin ein bißchen weiter gekommen. Die Drehzahlregelung für die Antriebsmodule läuft mittlerweile ganz ordentlich. Der Regler ist jetzt ein reiner PI, der D Anteil hat letztlich nicht mehr so viel Verbesserung der Regelgüte gebracht. Ich habe noch einen minimalen Ist-Wert-Overshoot bei einer Sollwertänderung, aber das ist im Rahmen. Noch habe ich nichts vorzeigbar geplpottet, ggf mach in noch ein paar Diagramme von Antworten auf Sprünge und Rampen, dann kann man sich ein Bild von der Regelqualität machen. Auch wenn ein wenig Feintuning durchaus noch angebracht ist, habe ich erstmal weiter gemacht, ich war neugierig wie der Antrieb als Ganzer läuft.

Bei Zeiten wird es einen zentralen Master geben, der die Antriebe als Slaves kontrolliert. Die Platine dafür ist schon in Auftrag gegeben. Einstweilen habe ich einfach eines der Antriebsmodule als Master verwendet, der mit den anderen Antrieben per I2C redet. Das funktioniert so weit ganz gut. Die inverse Kinematik steht auch, die rechnet der Master.

Hier ein Video von der Jungfernfahrt (sorry für die schrottige Qualität). Die Bewegungen sind einfach hard gecoded, das Vehikel fährt in 45° Schritten einige Geschwindigkeitsrampen ab und dreht sich dann auf der Stelle. Die Stromversorgung kommt noch von außen.

http://youtu.be/sRkIqhVpVsY

Gruß
Malte

Hi!

Noch ein kleiner "Nachtrag" zu dem Video oben. Im folgenden Video macht die Plattform (fast) die gleichen Bewegungen wie oben, jede Fahrt in eine Richtung wird also durch eine (abgesehen von der Richtung) gleiche Fahrt in Gegenrichtung kompensiert. Wenn man ein paar von diesen Bewegungen aneinanderhängt und dann Start- und Endpunkt vergleicht, bekommt man also einen qualitativen Eindruck von der Spurtreue des Vehikels. Im Ergebnis sieht man durchaus eine deutliche Abweichung, katastrophal ist es aber nicht.

@Hanno: weil Du oben fragtest: hier hörst Du die Laufgeräusche der Räder auf Parkett. Ich finde die halten sich sehr in Grenzen, die Motoren, insb. die Getriebe sind deutlich lauter ...

http://youtu.be/Ne09Y72zW_Y

Die oben angedeuteten Masterplatinen haben sich heute auf den Weg zu mir aus China gemacht, in ca. 3 Wochen kann's also damit weitergehen. Ich habe zwischenzeitlich angefangen einen Arm für die Plattform aufzubauen. Ich verwende dafür die gleichen Getriebemotoren wie für den Antrieb. Das Ganze läuft natürlich wiedermal relativ planlos, insofern wird sich zeigen, wie gut das gehen wird. Insgesamt ähnelt das Konzept dann ein wenig dem youBot (ehemals?) von KuKa. Es gibt hier im RN ja schon den schönen Ansatz von Staind, ich selbst werde allerdings keinen Wert darauf legen, dass mein Aufbau dem youBot optisch ähnlich wird. Bei Zeiten mehr dazu ...

Gruß
Malte

hallo malthy, ja das geht, aber ein wenig klappert es schon. Liegt halt in der Natur der Sache, ich habs aber auch schon schlimmer erlebt. Ich bin in Gedanken dabei eine Transportplattform zu bauen für die Wohnung. Wird allerdings erst mal kein Roboter sondern soll ferngesteuert - möglichst über ein Web-Interface - sein.

Moin!

Weiter oben hatte ich ja schonmal angedeutet einen Arm für die Mecanum Wheel Plattform aufbauen zu wollen, sodass dann ein ähnliches System entsteht wie der Kuka youBot. Die Idee ergab sich auch daraus, dass sich die Antriebsmodule, die ich aufgebaut habe, auch ganz gut als Stellmotoren verwenden ließen. Ich hatte eine Positionsregelung nur mal auf die Schnelle "zusammengehauen", die eigentlich direkt ganz gut lief.

Die ersten drei Freiheitsgrade des Arms habe ich jetzt zumindest mechanisch mal aufgabaut. Es soll im Endeffekt ein 5-Achs Arm werden, für die zwei noch verbleibenden Achsen werde ich kleinere Getriebemotoren verwenden. Die ersten beiden Achsen werden direkt von den Getriebemotoren gebildet bzw angetrieben. Das wäre für die dritte Achse nicht so günstig gewesen, weil der relativ schwere Motor dann über den Hebelarm die zweite Achse deutlich belastet hätte. Deswegen verwende ich einen Zahnriemen, um Antrieb und Drehachse zu trennen. Um die zweite Achse zu entlasten, wurde der Getriebemotor außerdem so angeordnet, dass er als Gegengewicht dient: der eigentliche Motor für die dritte Achse liegt hinter dem Lagerpunkt der zweiten Achse.

Der Unterarm ist erstmal nur eine Art Platzhalter, aber an dem Bauprinzip werden ich festhalten. Was nicht so bleiben kann wie es jetzt ist, ist die Verbindung des Unterarms mit seiner Welle. Das ist aktuell eine einfache Verschraubung ohne jeden Verdrehungsschutz. Bei Belastung löst sich je nach Richtung - erwartungsgemäß - eine der Schrauben. Ich werde zunächst mal versuchen, ob ich mit einer großen Unterlegscheibe und einer gekonterten Verschraubung an diese Stelle die nötige Verbindungsstabilität erreichen kann.

Hier ein paar Bilder vom aktuellen Stand:

Anhang 30044 Anhang 30046 Anhang 30050
Anhang 30047 Anhang 30049 Anhang 30048

Gruß
Malte

schöne arbeit

Hallo,

vorab: Tolles Projekt, bin beeindruckt!
Ich habe jetzt auch 100mm Mecanum Räder bestellt bei Nexusrobots, allerdings die "basic" Variante ohne Kugellager (20€ je Rad mit Versand bei AliExpress).
Mal sehen ob die gut genug sind... Herauskommen soll bei mir eine omnidirektionale Plattform für eine Videokamera.

Bei den Motoren verwende ich welche mit eingebauten Encodern. Steuern möchte ich das alles mit einem Arduino - prinzipiell würde wohl ein Arduino Uno reichen (mit Motor Shield), allerdings möchte ich auch noch ein Bluetooth-Modul anschließen, und dafür reichen die Pins dann nicht mehr. Also habe ich einen Arduino Mega geordert.

Spricht etwas dagegen das so zu lösen? Den Ansatz mit eigenen kleinen Platinen je Motor finde ich ganz cool, allerdings erscheint mir der Aufwand höher im Vergleich zu einer Steuerung für 4 Motoren.

Kleines Update von mir: Funktioniert alles soweit, das Teil fährt!
Ich habe noch etwas Probleme mit dem Motor-Treiber, der 2 L293D benutzt hat. Die sind für meine Motoren unterdimensioniert.

Bei den Encodern benutze ich nur 1 von 2 Pins, das gibt zwar nur halbe Genauigkeit und keine Richtungsangabe, aber damit kann ich leben. Und dann klappts auch noch mit dem ATmega328P.

Eine Frage zur Ansteuerung der Mecanum-Räder - hat mal jemand das ausgerechnet/ausprobiert wie man in beliebige Richtungen fährt, also nicht nur 45° Winkel?
Ich bin auch an Lösungen interessiert um eine unbeabsichtigte Drehung (z.B. durch unterschiedlichen Grip der Räder) zu Erkennen und zu kompensieren.

Ich denk mal, dass sich die Bewegungen allein schon durch die geometrischen Zusammenhänge berechnen lassen. Beispielsweise drehen sich ja bei Vorwärtsfahrt alle Räder vorwärts, während beim Querfahren ja zwei Räder entgegengesetzt zu den anderen zweien drehen würden. Um schräg zu fahren, müsste man beides kombinieren, also müssten sich zwei Räder mit doppelter Geschwindigkeit vorwärts drehen, während die anderen still bleiben. Wäre quasi einfache Addition, wäre einmal v+v=2v und einmal v+(-v)=0. Zum Drehen müsste man dann nochmal die Räder anders antreiben, aber auch das ließe sich berücksichtigen. Letztendlich kann man Geschwindigkeit in x- und y-Richtung sowie eine Winkelgeschwindigkeit angeben (im roboterfesten Koordinatensystem) und daraus dann die Geschwindigkeiten der Räder durch Überlagerung der Einzelbewegungen berechnen. Zum Messen könnte man ja versuchen, mehrere Maussensoren unter den Roboter zu setzen und damit dann die absolute Bewegung aufzeichnen (mindestens zwei wegen Drehung, oder?).

Kann gut sein, dass es so einfach ist. Kann aber auch sein dass es nicht linear ist und/oder sich eine Drehung des Fahrzeugs einstellt. Ich denke ich probiere es aus.

Mache mir hier mal Notizen:
Die Räder sehen von oben so aus:
\ /

/ \

dementsprechend berühren die Laufrollen den Boden so:
/ \

\ /


Grad VL VR HL HR
__0 _v_ v_ v_ v
_45 _v_ 0_ 0_ v
_90 _v_ r_ r_ v
135 _0_ r_ r_ 0

der Rest entsprechend gespiegelt.

Als ASCII Art:

/+ \+ . /+ \o . /+ \- . /o \-
↑↑↑↑↑ . ↗↗↗ . →→→→→ . ↘↘↘
\+ /+ . \o /+ . \- /+ . \- /o

(Interessant, die diagonalen Pfeile sind breiter trotz Nicht-Proportional-Schriftart Courier New).

Die Idee mit den Maussensoren ist für meinen Anwendungsfall nicht so ideal, ich habe lieber etwas Bodenfreiheit.

Hey,

hab gerade wenig Zeit, deswegen nur in aller Kürze. Es ist tatsächlich relativ simpel und total linear :-). Wenn V_LF die Geschwindigkeit des Rades links vorne ist, V_LB die des Rades links hinten, V_RF die des Rades rechts vorne und V_RB die Geschwindigkeit des Rades rechts hinten, dann sind die Räder folgendermaßen anzusteuern, wenn x und y die Komponenten des Geschwindigkeitsvektors sind und r die Rotation der Plattform bezeichnet:

V_LF = y + x + r
V_LB = y - x + r
V_RF = y - x - r
V_RB = y + x - r

Um die Skalierung muss man sich dann noch kümmern, je nachdem wie man die Ansteuerung gebaut hat. Ich bin jetzt zu faul das nochmal "in Sprache" zu erläutern, aber wenn man sich hinsetzt und drüber nachdenkt wie Geistesblitz das schon angefangen hat, kommt man zu einem intuitiven Verständnis. Viel Spass damit!

Gruß
Malte

Wunderbar! Mit diesen Formeln kann man auch Kreise fahren usw.

Wer ein Mecanum-Gefährt mit 3 (gleichen) Rädern ansteuern möchte der findet übrigens in der Abhandlung "Maschinenbau im RoboCup - Spielfreies Mecanum-Wheel" die entsprechenden Formeln (Seite 10f).

Edit: Habs auch mal angehängt: Anhang 30625

Klar, so kann man es auch definieren, allerdings hast du dann nur 8 Richtungen zur Verfügung.

Ich hab gerade noch ein bisschen genauer überlegt, haben die Rollen an den Rädern eigentlich immer einen Winkel von 45° zur Radachse? Könnte der sich vielleicht sogar je nach Drehwinkel des Rads leicht ändern?
Müsste jedenfalls berücksichtigt werden, sonst ist die Geschwindigkeit und der zurückgelegte Weg inkonsistent.
Bei Drehung kommt es dann auch noch drauf an, wie weit die jeweiligen Räder vom geplanten Drehpunkt entfernt sind. Vielleicht könnte man sogar jede Bewegung als Drehung um einen beliebigen Punkt definieren (bei gerader Fahrt liegt der Punkt eben im Unendlichen).

Edit: zu langsam, der erste Satz bezieht sich auf den Beitrag mit den Richtungen in 45°-Abstufungen. Der Rest passt gerade aber trotzdem gut in die Diskussion.

Ja, die Walzen auf den Rädern sind genau im Winkel von 45° angeordnet. Wenn sich das ändern würde, dann würde das Mecanum-Rad nicht mehr so rund laufen (die Walzen sind ja entsprechend geformt das sie beim Abrollen genau einen Kreis ergeben).

Eine Drehung wird in der Praxis vermutlich nie ganz exakt sein, da z.B. der Schwerpunkt nicht genau in der Mitte liegt und kleine Unterschiede bei der Reibung wahrscheinlich sind.