Hallo zusammen, ich würde gerne einmal folgende Idee diskutieren, um auszuschließen das ich keinen Denkfehler gemacht habe. Es geht hierbei um ein Simulationsmodell einer Roboters mit vier Räder, welche jeweils über einen DC-Motor angetrieben werden. Räder sind direkt am Ständer des Motors befestigt, somit kein Getriebe etc. Folgendes überspitztes Szenario: Im Simulationsmodell wird ein Rad durch einen Motor angetrieben. Das Drehmoment des Motors wird in die Kraft am Rad umgerechnet. Unter Berücksichtigung von Reibung (Haft-, Roll- und Gleit) wird die Beschleunigung bzw. Geschwindigkeit des Chassis durch alle vier Räder/Motoren berechnet. Keine Simulation von Schlupf. Der Roboter hat nun eine fiktive Geschwindigkeit von 4 m/s. Nun soll das Fahrzeug bremsen. Die Motoren erzeugen einen Drehmoment entgegen der aktuellen Rotation, in diesem Szenario aber so stark, dass die Räder nach einiger Zeit blockieren. Alle Räder haben nun 0 RPM, der Roboter jedoch noch eine Geschwindigkeit von 2 m/s. Der Roboter gleitet bzw. rutscht somit. Nun wird die Spannung der Motoren entfernt und die Ständer können frei drehen. Durch die Reibung müssten die Räder sich nun wieder anfangen zu drehen. Dies bildet mein Modell derzeit nicht ab und dies möchte ich abbilden. Ein ähnliches Szenario wäre ein klassischer Front- oder Heckantrieb, wo sich die anderen Räder auch anfangen zu drehen, ohne direkt angetrieben zu werden. Die einfachste Variante wäre nun die aktuelle Geschwindigkeit zu nehmen und durch den Radumfang zu teilen. Dadurch würde der Reifen aber fälschlicherweise von einem zum nächsten Simulationsschritt (50 Hz) in der Geschwindigkeit springen, was falsch ist. Besser wäre es vom aktuellen Simulationsschritt t die zurückgelegte Distanz zum letzten Schritt t-1 zu berechnen und dann auf Basis des Umfangs die Umdrehung zu berechnen. Lieber würde ich jedoch auch die Umdrehung auf Basis von Reibung und Kräften berechnen. Vor allem für den Fall, wenn die Räder wieder beginnen zu drehen und der Motor dann zeitlich bremst. Dann entstehen Kräfte die das Rad antreiben und zeitgleich stoppen möchten (z.B. Bremsen der vorderen Räder beim Heckantrieb). Hierzu fehlt mir jedoch das genaue Herangehen bzw. ich weiß gar nicht, ob es möglich ist. Folgende Gedanken habe ich mir dazu gemacht: Die max. Haftreibung bestimmt wie viel Reibung max. die Beschleunigung der Räder "fließen" kann. Da in der Simulation das Rad immer maximal haftet, bevor es gleitet, würde stets die max. Haftreibung genommen. Die Kraft würde dann das Rad beschleunigen, so lange bis die Umdrehungen des Rades der Geschwindigkeit des Chassis entsprechen. So grob skizziert wie ich mir das vorstellen würde. Leider hab ich keinen Begriff gefunden, welcher meinen Fall einheitlich beschreibt. Daher habe ich mir diese Situation mit meinem begrenzten Wissen bestmöglich hergeleitet. Ich wäre nun sehr an konstruktiver Kritik, Hinweisen oder einer Bezeichnung für meinen Fall interessiert und danke jedem für die investierte Zeit! :)
Beim Bremsen, ist der Boden doch auch nur ein masseloses Antriebsrad.
Jim B. schrieb: > Dadurch würde der Reifen aber fälschlicherweise von einem zum nächsten > Simulationsschritt (50 Hz) in der Geschwindigkeit springen, was falsch > ist. Nein. Das ist ok, da die Quantifizierung (Einteilung in Simulationsschritte) das erfordert. Das Trägheitsmoment des Rades ist meist vernachlässigbar.
Es klingt vielleicht komisch, aber es gibt keinen festen Zusammenhang zwischen Radumdrehungen und Strecke. Ausnahme: Auf dem Papier. Selbst bei einem Schienenfahrzeug gibt es Toleranzen und spätestens nach einer Kurve stimmt nichts mehr. Du hast es bestimmt schon mal "gerochen", wenn ein schwerer LKW eine enge Kurve nimmt. Vom Abrieb mal abgesehen. Willst Du bei einem Fahrzeug, das sich auf Rädern (Schienen oder Ketten) bewegt, kannst aus der Bewegung der Räder nur in etwa etwas ablesen. Spätestens wenn Du keinen "homogenen" (konstanter Reibungskoeffizient) Untergrund hast kannst Du den Ansatz vergessen. ALSO BRAUCHST DU EINE UNABHÄNGIGE WEGERFASSUNG.
A. S. schrieb: > Nein. Das ist ok, da die Quantifizierung (Einteilung in > Simulationsschritte) das erfordert. Danke für die schnelle Antwort. Hätte nicht gedacht, dass diese triviale Herangehensweise akzeptabel ist. Da es sich um einen omnidirektionaler Antrieb handelt, muss ich mir - jetzt bei genauerer Betrachtung - überlegen wie ich die Umdrehung berechne. Aufgrund der Tatsache, dass der Roboter auch seitwärts fahren kann, ist es nicht so trivial die Geschwindigkeit in Umdrehungen umzurechnen. Müsste ich aber über bekannte Kinematik erledigen können, schaue ich mir nun an. Sebastian S. schrieb: > Untergrund hast kannst Du den Ansatz vergessen. > ALSO BRAUCHST DU EINE UNABHÄNGIGE WEGERFASSUNG. Habe ich. Ist ein Motion Capture System, welches meinem Simulationsmodell die notwendigen Informationen liefern soll um die Werte näherungsweise zu bestimmen. Da es sich hierbei um einen Roboter auf nur einer Art von Untergrund handelt, sollte dies in diesem Fall ausreichend sein. Natürlich entsteht dadurch kein allgemeingültiges Modell. Das ist aber auch nicht das Ziel.
:
Bearbeitet durch User
Wir haben unseren Studenten eine (Arbeits-)Plattform mit 4 genau definierten Rädern und 4 Schrittschaltmotoren gegeben und ihnen die Aufgabe gestellt: "Fahrt 5 Meter den Flur entlang und dann genau zum Ausgangspunkt zurück". Das hat in keinem Fall geklappt. Auch nicht nach endlosen Fahr- und Bremsoptimierungen. Der Flur war etwa 20 Meter lang und enthielt keine Hindernisse. Auf dem Papier hat es immer geklappt. Selbst die endlose Berechnung von Korrekturfaktoren, anhand des beim ersten Mal zurückgelegten Weges, hat daran nichts geändert - keine Reproduktion. Nach der Montage eines Sensors (Ultraschall, LIDAR, normaler Laser, Kamera und sogar eines Tastarmes) hat es dann meistens geklappt.
Ich denke, den Schlupf wirst Du, wenn Du nicht gerade allerlangsamst beschleunigst nie richtig weg bekommen! Da reicht schon etwas mehr Feuchtigkeit wegen Temperaturänderung... Unsere Regalbediengeräte werden daher entweder über Zahnschiene angetrieben und direkt über den Motorgeber gemessen oder im Fall von Schienen und Stahlrädern über einen Lasersensor und zweites Messsystem. Bei Jog wird über den Motorgeber, im Automatikbetrieb mit Positionierung wird die Motorregelung über den Motorgeber und mit dem Laser zusätzlich die Distanz zum Ziel ausgewertet. Alles Andere wäre auf Dauer zu ungenau.
:
Bearbeitet durch User
A. S. schrieb: > Nein. Das ist ok, da die Quantifizierung (Einteilung in > Simulationsschritte) das erfordert. > > Das Trägheitsmoment des Rades ist meist vernachlässigbar. So, kurzes Feedback: Klappt soweit zufriedenstellend und kann vorerst für meinen Anwendungsfall genutzt werden. Ich speichere für jedes Rad seine Teil-Geschwindigkeit, welche es der Gesamtgeschwindig beisteuert. Wenn das Rad nicht mehr gleitet berechne ich auf Basis dieser Teil-Geschwindigkeit die Umdrehung. Das bleibt nun solang bis ich merke, dass es zu ungenau ist. Nun ist mir jedoch eine andere Situation aufgefallen, welche nicht über diese Lösung abgedeckt wird und dem Heck- und Frontantrieb-Beispiel ähnelt. Fährt der Roboter in der Realität mit nur zwei der vier Räder dann drehen sich die anderen beiden ebenfalls minimal, auch wenn dieser von den Motoren eigentlich auf 0 RPM gehalten werden sollen. Zwei Räder haben die Zielgröße 200 RPM, zwei 0 RPM. Effektiv haben die Räder jedoch zwischen 10-20 RPM, da die Regelung der Motoren wohl nicht ausreichend stark gegenarbeitet. Dies würde ich nun ebenfalls versuchen abzubilden. Hier müsste ich dann vermutlich über die Reibung gehen, welche das Rad minimal antreibt während der Motor gegenarbeitet. Sebastian S. schrieb: > Das hat in keinem Fall geklappt. Ich bin auch nicht zuversichtlich, dass meine Lösung perfekt wird. Sie muss praktisch nur einen nennenswerten Vorteil gegenüber reiner Kinematik bieten.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.