Offlineberechnung einer Linearbewegung

fals a=constant

s=0,5 * a*t^2 + v0 * t + s0

ich nehme an, Du orientierst nicht um ?

...die beschleunigungskurve...
wird die überhaupt berechnet?
...oder ist sie durch die eingestellten motorströme, maximalen achsbeschleunigungen etc. nur begrenzt und daher gar nicht berechnet?

Hallo,

Zitat

Selbst wenn sie nicht berechnet wird und durch Anderes als eine Variable begrenzt wird, muss es möglich sein, mit 2,3 m/s² zu beschleunigen wenn 2,3m/s² vorgegeben sind.
Oder irre ich mich hier?

Leider ist die Realität nie so einfach wie sie in akademischen Uni-Beispielen vorgegaukelt wird:

Du vergisst z.B. den Filter. Ohne den Filter würdest du Knicke im Geschwindigkeitsprofil haben, was eine reale Mechanik nicht verträgt (unendlicher Beschleunigungssprung beim Übergang aus konstanter Beschleunigung in konstante Geschwindigkeit oder konstante Verzögerung, fehlende Ruckbegrenzung). Du hast aufgrund der Trapezprofilplanung über s=0.5*a*t^2 ja nur ein einmal stetig differenzierbares Geschwindigkeitsprofil. Man muss aber mindestens C2 sein. Daher werden bei KUKA die Sollachspositionen noch bevor sie an die Antriebe kommandiert werden durch einen Mittelwertfilter der Länge $Filter modifiziert. So ein Filter wirkt quadratisch auf die Beschleunigung. Also vor Filterung hat die Steuerung tatsächlich ein Trapezprofil, dass über s=0.5*a*t^2 definiert ist, geplant. Nach Filter kommt aber ein Profil mit weniger Beschleunigung raus.

Ferner müssen die Profile für kartesische Geschwindigkeit und Orientierung noch synchronisiert werden. Hier gilt es zwei Arten zu Unterscheiden:

1) zeitsynchron: alle Komponenten starten gleichzeitig und Beenden ihre Bewegung auch wieder gleichzeitig
2) phasensynchron: alle Beschleunigungs- und Verzögerungsphasen über alle Komponenten starten zu den gleichen Zeitpunkten

Erst wenn diese beiden Arten der Synchronität für ein Geschwindigkeitsprofil erfüllt sind, wird die gefahrenen Bahn unabhängig von den programmierten Profildaten.

Ferner hat die KUKA-Steuerung noch Mechanismen die z.B. Anregungen von Schwingungen des Roboters in dessen Eigenfrequeenzbereich verhindern sollen. Hier werden die Vorschübe an die Antriebstechnik noch nachträglich in Abhängigkeit von Lastdaten über das Dynamikmodell modifiziert.

Ferner: Ist man in der Nähe von Singularitäten würde auch langsamere Beschleunigungen rauskommen, da die Steuerung dann zusätzlich auf maximale Achsgeschwindigkeiten begrenzen muss um ein Durchfahren von Singularitäten zu ermögliche (siehe $CP_VEL_TYPE)

....

ICh könnte jetzt hier noch viele andere Fälle aufzählen die Einfluss haben auf das beobachtete Ergebnis, aber ich glaube es wird klar, dass die Welt manchmal nicht so einfach ist.

Als Einführungsbuch in alle diese Thematiken könnte ich John J.Craigs: Introduction to Robotics: Mechanics and Control (3rd Edition) empfehlen. Es gibt aber sicher noch viele anderer Einsteigerbücher.

Fubini

Hallo,

wir sollten hier ein Rampenprofil (genauer ein 3 phasiges-trapezförmiges: konstant Beschleunigen, konstante Geschwindigkeit, konstant Verzögern) haben. Trägt man die Geschwindigkeit über den Weg an entsteht so ein Trapez:
_______________
/ \
/ \
/ \

Fubini

Hallo Komkonza,
du beschleunigst mit 2.3 m/s*s auf eine Endgeschwindigkeit von 0.25 m/s. Theoretisch dauert der Beschleunigungsvorgang 108.7 ms, das sind also 'nur' 9 Ipo-Takte. Hier dürfte der von fubini erwähnte $FILTER das Ergebnis stark beeinflussen, zumal die Datenaufnahme im Submit-Interpreter bei dessen Taktung (mal 12ms, dann auch mal 24ms) zusätzlich die Messgenauigkeit verschlechtert.
Warum wählst du nicht stattdessen eine Endgeschwindigkeit von z.B. 1.2 m/s. Dann würde dein Beschleunigungsvorgang 521 ms bzw. etwa 44 Ipo-Takte dauern und theoretisch sollte der TCP in der Zeit ca. 310 mm zurücklegen. Bei deiner Gesamtfahrstrecke von 960 mm bedeutet das, dass sich in etwa eine Streckenaufteilung von 1/3 Beschleunigung, 1/3 Konstantfahrphase und 1/3 Verzögerung ergeben sollte. Ich bin mir ziemlich sicher, dass dabei dann die gemessene Beschleunigung dem Grenzwert von 2.3 m/s*s deutlich näher kommen dürfte.

Hallo,

danke für den Hinweis, dass unsere Steuerung hochentwickelt ist, aber ich bin mir sicher, dass es nicht Sinoid ist, da ein Sinus ja unendlich oft stetig differenzierbar wäre und man sich dann, dass ganze gefiltere ja sparen könnte. Die Ruckbegrenzung wird ja gerade durch die Filterung auf Achsebene erreicht.

Selbst wenn man das mit heutigen Techniken und mehr Rechenpower auch besser kann (Hier ist übrigens ein Unterschied zum Spline, der nichtmehr so "veraltet" mit Trapezprofilen arbeitet) darf man leider so etwas im Nachinein leider nie wieder ändern, da uns sonst die BMWs, VWs und Daimlers dieser Welt immer lynchen, dass wir uns jetzt anders verhalten als früher. Was übrigens gerade immer wieder beim Spline passiert: Aus der Beobachtung, dass Splinebewegungen sich anders verhalten als der alte Bereich wird immer daraus geschlossen, dass der Spline sich falsch verhält und nicht, dass manche Lösungen von früher äusserst suboptimal waren. Man gewöhnt sich halt schnell an Sachen die eigentlich Mist waren und will die dann bis in alle Ewigkeit so beibehalten.

Gruß
Fubini

Hallo Komkonza,

ich, und wahrscheinlich viele andere, würden ebenfalls gerne hinter die (komplexe) Offline-Berechnung einer Linearbewegung kommen. Du hattest erwähnt, daß du dir Bücher zum Thema Bahnplanung besorgt hast, kannst du eines empfehlen (möglichst deutschsprachig)?
Hättest du die eventuell die Möglichkeit / Lust deine gefundenen Formeln + Ergebnisse hier im Forum zu posten?

Viele Grüße,

maeher