Roboterbasis mit Mecanum Wheels

[malthy]

Hi,

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.



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.



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

[Geistesblitz]

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.

[HannoHupmann]

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.

[Geistesblitz]

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?

[HannoHupmann]

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

[malthy]

Hi,

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.

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

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

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.

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

[HannoHupmann]

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.