Lineare Bewegung

Hallo,

ich schreibe gerade ein Konzept, wie ich mit einem 6-Rotationsachsen Roboter Bewegungen realisiere.

Es gibt ja die Punkt-zu-Punkt(PTP) Bewegung, bei der ein Punkt mit einer unvorhersehbaren Bahn schnellstmöglich erreicht wird.
Bei einer Linearen Bewegung benutzt man die Interpolation. Man berechnet Zwischenpunkte(Interpolationspunkte) auf der zu fahrenden,
linearen Strecke. Je dichter die sind, desto kleiner die Abweichung zur Bahn.

Nach meinem Verständnis ist also die Bewegung zwischen den Interpolationspunkte also auch eine PTP-Bewegung.

Meiner Meinung nach müsste es doch möglich seine durch die Bewegung der 6 Gelenke exakte lineare Bahn zu fahren, ohne unnötig viele Interpolationspunkte zu bestimmen?
Ich finde dazu leider nicht im Netz. Irre ich mich da in der Möglichkeit, oder gibt es Ansätze zur Berechnung der Gelenkbewegungen um so eine Lineare Bahn zu fahren?

Danke!
Micha

Zitat:

Zitat von raze92

Nach meinem Verständnis ist also die Bewegung zwischen den Interpolationspunkte also auch eine PTP-Bewegung.

Da man eine Positions- und Geschwindigkeitsregelung nutzt, theoretisch ja praktisch ist es eine Bahnregleung, da bei einer Graden das Verhältniss der Bewegungsanteile zueinander immer gleich ist und es somit genau 0 Zwichenpunkte gibt.
Eine Steuerung kann mit absoluten Zwichenpunkten arbeiten um zu prüfen ob eine Achse vor oder nachläuft, oder einfach ständig das integral unter einem inkrementellen Delta berechnen und darüber die Regleabweichung klein halten.

Zitat:

Zitat von raze92

gibt es Ansätze zur Berechnung der Gelenkbewegungen um so eine Lineare Bahn zu fahren?

Inverse Kinematik / Direkte Kinematik
https://de.wikipedia.org/wiki/Inverse_Kinematik

Danke für die Antwort!
So ganz hab ich das nicht verstanden. Dass man die Gelenkstellungen über Inverse Kinematik ermittelt weißt ich schon.

Wenn die Bahn eine gerade Linie sein soll, dann führt man Zwischenpunkte ein um die Abweichung gering zu halten. Wie aber kann ich sicher gehen, dass zwischen den Punkten es auch eine gerade Linie ist? Klar kann man viele solche Zwischenpunkte nutzen und bei Abweichungen jedes mal nachregeln.

Ich hatte halt die Idee, dass man die Geschwindigkeit aller Gelenke so berechnet, dass die Bahn genau eine Linie ist, ohne unnötig viele Zwischenpunkte zu bestimmten. Aber wie man das genau macht weiß noch nicht. Das bisherige Konzept war, dass man viele Zwischenpunkte wählt und jedes mal kurz vor dem erreichen des Zwischenpunktes den neuen Zwischenpunkt der Steuerung übergibt und Der Roboter dann zum nächsten Fährt. Wie man aber berechnet, dass zwischen den Zwischenpunkten die Bahn nicht PTP sein soll sondern Linear(so war die Idee um zu viele Zwischenpunkte zu vermeiden) versuche ich herauszufinden.

Wahrscheinlich sind meine Gehirnzellen auch nur verknotet.

Hallo Micha,

willkommen im Forum.

Zitat:

.. mit einem 6-Rotationsachsen Roboter Bewegungen ..

Zitat:

.. Wie aber kann ich sicher gehen, dass zwischen den Punkten es auch eine gerade Linie ist? ..

Garnicht - im Prinzip. Real und recht theoretisch geht das in ganz wenigen Fällen - genau dann, wenn die Abweichungen der einen Achse (des einen Gelenkarms) die Abweichungen des anderen Gelenkarmes gerade noch im Bereich der Messgenauigkeit kompensieren bzw. wenn die Abweichungen aller Gelenkarme sich gegenseitig kompensieren.

Schau Dir doch mal den "Gelenkarm" Deines eigenen Körpers an. Nehmen wir an, die Faust sei Dein "TCP" (und fixiert gegen den Unterarm), die Elle-Speiche-Konstruktion sei starr = nicht verdrehbar.
Wenn Du nun den Oberarm schwenkst (oBdA OArm und Bewegung des Ellenbogens in einer waagrechten Ebene) dann wird Dein TCP eine Schwenkbewegung (=Kreisbahn) durchführen.
Wenn Du nur den Unterarm schwenkst (oBdA OArm starr und Bewegung des Unterarms in einer Ebene) dann wird der TCP ebenfalls eine Schwenkbewegung durchführen.
Genaugenommen sind alle diese Einzelbewegungen stets Kreisabschnitte bezogen auf ihr TCP-seitiges Gelenkarmende mit dem Mittelpunkt des gegenüberliegenden Gelenks.

Die gerade Bahn des TCP ist also zwischen zwei Einzelpunkten der vorgerechneten Bahn - theoretisch und absolut gesehen - nie völlig gerade. Der Trick liegt darin die Gelenkauflösung (messtechnisch und antriebstechnisch) so hoch zu halten, dass die resultierenden Schwankungen innerhalb der tolerierbaren Grenze liegen und die Einzelpunkte der vorgerechneten Bahn möglichst dicht zu setzen; abhängig von Rechnerleistung der Steuerung, Messgenauigkeit der Gelenke etc.

War das verständlich?

Das war sehr verständlich. Danke!

Wie Realisiert man das denn programmtechnisch am sinnvollsten? Misst man die Abweichung der Gerade und wenn sie einen festgelegten Wert überschreitet regelt man nach und berechnet somit weniger Zwischenpunkte bei der Bahnberechnung? Oder Berechnet man mehr lieber mehr Zwischenpunkte um zur Laufzeit nicht nachregeln zu müssen? Oder ist eine Kombination von beiden das A und O?

Bei einer Graden ist die Bewegung für alle beteiligten Raumachsen linear und proportional zueinander (anders als bei einer Kreisbahn).
Wenn man für alle Raumachsen die Steigung hat, benötigt man keine Zwischenpunkte die erreichnet eine Steuerung sich zur Laufzeit dynamisch anhand einer definierten kleinsten Schrittweite, iterativ, bis die Istposition mit der Sollposition (Endpunkt) übereinstimmt.
Beispiel: wenn sich die Steigungen 1 zu 2 zu 3 verhalten, kann die Steuerung bei einer Startposition 100, 30, 50. zur laufzeit die Positionen 101, 32, 53; 102, 34, 56;..... berechnen.
Je nach Auflösung der Meßsysteme und Antriebe wird das dann entsprechend genau angefahren.
Bei Industriesystemen hat dann auch ein Drehgeber mal 5000 Digit auf 360°. Und mit einem Signal multiplizierer (Interpolations und Digitalisierungselektronik) wird das dann bis zu 100 Fach verfeinert.
Bei dann 50000 Digit auf 360° sind das Auflösungen von einer halben Bogenminute. Das ist dann ein PTP Inkrement das zwar mathematisch noch als solsches gesehen werden kann, aber praktisch ist das Delta so klein, das es ein Bahnsteuerung bleibt.
Und das Berechnen der Positionen erfolgt bei Industriesteuerungen meist mit 20-100 kHz. Also alle 50 bis 10 Nanosekunden.

Beim Selbstbau eines 6-Achs Verikal Knickarm Roboters werden die Encoder vermutlich alleine schon wegen den Kosten weniger Auflösung haben und die Signalvervielfachung entfällt meist auch mangels entsprechender Elektronik Kenntnisse.
Mit zwei handelsüblichen Fensterdiskriminatoren ließe sich der Sinus am A und B Kanal eines Drehgebers in je drei Spannungspegel teilen, und man erhält so eine Verdopplung der Auflösung gegenüber dem reinen Geber mit nachgeschalteten Schmitt Trigger.
Hat jetzt zwar nicht mit der mathematischen Lösung zu tun aber mit der praktischen Verbesserung der für die Lösung notwendigen Daten.

Zitat:

Zitat von i_make_it

Bei einer Graden ist die Bewegung für alle beteiligten Raumachsen linear und proportional zueinander (anders als bei einer Kreisbahn).
Wenn man für alle Raumachsen die Steigung hat, benötigt man keine Zwischenpunkte die erreichnet eine Steuerung sich zur Laufzeit dynamisch anhand einer definierten kleinsten Schrittweite, iterativ, bis die Istposition mit der Sollposition (Endpunkt) übereinstimmt.

Das ergibt Sinn. Was ist mit der Orientierung?
Trotzdem muss doch für jeden Schritt eine Rücktransformation erfolgen. Ist das nicht ein ziemlich großer Rechenaufwand? Ist es da nicht schlauer die Gelenkstellungen schon vorher zu berechnen?

Zitat:

Zitat von i_make_it

Je nach Auflösung der Messsysteme und Antriebe wird das dann entsprechend genau angefahren.

Der verbaute Encoder pro Achse hat eine Auflösung von 14-Bit also ca. 0,02° Genauigkeit. Ich hab leider noch keine praktischen Erfahrung bei der Berechnung der Inverse Kinematik. Die Idee war zur Steuerung ein Minirechner wie Arduino, Raspberry Pi etc. zu verwenden. Schaffen es solche Rechner die mögliche Genauigkeit auszunutzen?

Wenn man sich entscheidet, die Schrittweite zu vergrößern, ist es möglich die maximal mögliche Abweichung zur Bahn zu bestimmen?

Zitat:

Zitat von raze92

Was ist mit der Orientierung?

Die Orientierung und den Offset zwichen dem roboterbezogenen Weltkoordinatensystem und dem roboterbezogenem Polaren Weltkoordinatensystem bestimmst Du in den Systemparamtern des Roboters.
Willst Du nur in einem Raumquadranten mit positiven Werten für X, Y und Z arbeiten, dann verschiebst Du den Nullpunkt des polaren Koordinatensystems in allen Achsen jeweils soweit ins Plus, bis niemals ein negativer Wert erreicht werden kann.
Falls Du mit Orientierung A, B und C Ausrichtung des TCP meinst, die ist neben den X, Y und Z Koordinaten des TCP natürlich auch immer mit anzugeben.
Üblicherweise erfolgt das heutzutage in einer 4Kreuz4 Matrix. Da man damit auch direkt die Transformationen durchführen kann.
https://prof.beuth-hochschule.de/fil...ng_Teil_03.pdf

Zitat:

Zitat von raze92

Trotzdem muss doch für jeden Schritt eine Rücktransformation erfolgen.

JA per Inverser Kinematik

Zitat:

Zitat von raze92

Ist das nicht ein ziemlich großer Rechenaufwand?

JA.

Zitat:

Zitat von raze92

Ist es da nicht schlauer die Gelenkstellungen schon vorher zu berechnen?

Hat man früher so gemacht, als die Rechner noch langsam und groß waren.
Als ich 1984 in der ausbildung das erste mal mit Industirerobotern zu tun hatte, waren einige (altere) davon noch so das man entweder hunderte Punkte geteacht hat um mit Synchonen PTP eine Bahnsteuernug zu simmulieren oder das für diese Roboter tatsächlich die Posen entlang der Bahn vorberechnet wurden und dementsprechend viele Datensätze einafach Sequentiel durchfahren wurden.
Beim synchonen PTP fahren nicht mehr alle Achsen full speed sondern proprtional zueinander. wenn also eine Achse zwichen zwei Posen 500 digit fahren muß und eine andere nur 50 Digit, dann fährt die erste 100% und die zweite nur 10% speed.
Nur so ist es bei PTP möglich das Verhalten von Bahnsteuerungen zu simulieren und zwichenpunkte zu verschleifen ohne jedesmal auf null zu bremsen und wartezeiten für die langsamste Achse einzufügen.

Zitat:

Zitat von raze92

Der verbaute Encoder pro Achse hat eine Auflösung von 14-Bit also ca. 0,02° Genauigkeit.

Dabei dürfte es sich um die Auflösung eines ADC handeln da Encoder entweder pro Kanal seriell einfach nur ein Rechtecksignal mit geschwindigkeitsabhängiger Frequenz liefern oder pro Kanal einen Sinus.
Wobei die Kanäle um 90° (beim Sinus) oder um Lambda/4 (ein Viertel der Frequenz) bei digitalen Encodern, zueinander verschoben sind.
Bei einem ADC mit 14 Bit kann es sein das du die beiden letzten Bit im Signalrauschen verlierst. Das müsstest Du dann erst mal testen.

Zitat:

Zitat von raze92

Die Idee war zur Steuerung ein Minirechner wie Arduino, Raspberry Pi etc. zu verwenden. Schaffen es solche Rechner die mögliche Genauigkeit auszunutzen?

Minirechner mit eigenem OS, haben als Haupthandycap die mangelnde Echtzeitfähigkeit.
Du hast Tasks vom Kernel, von den Hardwaretreibern, Daemons, etc. und dann mal den oder die Tasks von der Steuersoftware.
Vom Prinzip her funktioniert das und mit CNC Software wie z.B. Mach3 sieht man auch das es bis zu einer gewissen Geschwindigkeit auch mit der notwendigen Präzission und Wiederholgenauigkeit funktioniert.
Darüber hinaus werden dann spezielle G-Code Steuerkarten angeboten.

Zum Einsteigen kann man durchaus damit anfangen. wenn man aber hohe Positioniergenauigkeit, hohe Wiederholgenauigkeit und hohe Geschwindigkeit (kurze Zykluszeiten der Positions- und Geschwindikeitsregelung) haben will, kann man sich darauf einstellen auf eine Lösung mit besserer Echtzeitfähigkeit umsteigen zu müssen.
Da kommen dann Microkontroller oder proprietäre Singletask Betriebssysteme ins Spiel. (nicht umsonst kostet oft eine Driveunit mit Lizenz mehr als der dazugehörige Arm).

Zitat:

Zitat von raze92

Wenn man sich entscheidet, die Schrittweite zu vergrößern, ist es möglich die maximal mögliche Abweichung zur Bahn zu bestimmen?

Ja kann man berechnen.
Ist genau der Selbe Aufwand der zur Regelung des eigenlichen Arms notwendig ist, da man bei der Berechnung eigentlich nur das verhalten simuliert.

Wobei halt nicht nur Entfernung sondern auch Geschwindigkeit maßgeblich sind.

(das Beispiel nicht real nachmachen)
Mann fährt mit 50 eine langestreckte Kurve und macht einfach mal für 1 Sekunde die Augen zu.
Dann das selbe mit Tempo 100. Die gefahrene Strecke und wie weit man aus der Spur getragen wurde unterscheiden sich.
Jetzt hat man eine Beifahrer, der alle 100 Meter ein Signal gibt. und man macht das selbe nochmal mit 50 und mit 100 Sachen.
Die Streke die man mit geschlossenen Augen fährt ist also immer gleich. aber wegen der unterschiedlichen Geschwindigkeit unterscheidet sich immer noch die Dynamik und damit die Größe der Abweichung.
Macht man das ein drittes mal, aber diesmal mit 50 Metern dann wird auch die Abweichung kleiner.
Das Delta kann man dann soweit verkleinenr bis man an die Grenzen der Sensorauflösung kommt, Sprich Du kannst nicht mehr sagen ob Du aus der Spur getragen wurdest oder nicht, weil beide Durchläufe für Dich gleich aussehen.

Vielen Dank! Soweit hat sich einiges geklärt.

Ich will eine gerade Bahn fahren. Der Steuerung übergebe ich also Zielpunkt und Zielorientierung und zur Laufzeit wird nun iterativ die zu fahrenden Positionen berechnet. Wie bestimme ich aber die Geschwindigkeit/Beschleunigung? Es kommt ja vor, dass ein Gelenk mal seine Richtung änder muss, dann muss ich doch schon vorher wissen, an welcher stelle das passiert, um so Beschleunigen/Bremsen zu können. Rechne ich schon so weit vor, um entsprechend Anpassung an die Geschwindigkeit machen zu können?

Sehr oft definiert man die maximal nutzbare Geschwindigkeit bei geregelter Bahnsteuerung als Bruchteil des Produkts der tatsächlich möglichen Geschwindigkeit und der maximalen Beschleunigung.
Damit ist dann sichergestellt, das jede Achse in Extremsituationen (z.B. Drehrichtungsumkehr) die Geschwindigkeit zur Einhaltung der Bahn erreichen kann.

Grade bei Aufgaben wie Lackieren, wo das Einhalten der Geschwindigkeit proportional zur Farbmenge das wichtigste ist, darf es nicht zu Geschwindigkeitsschwankungen kommen. entweder wird die Schichtdicke zu dünn (zu schnell Verfahren)
oder zu Tropfnasen (extrem zu langsam).
Das eine ist aufwendige manuelle Nacharbeit das andere ist Ausschuß oder muß komplett entlackt werden um dann noch mal neu bearbeitet zu werden.
Auch bei der Materialbearbeitung ist so was tödlich fürs Werkstück.
Beim Entgraten einer Kontour mal wegen Schleppfehler einer Achse ins Werkstück reingefahren und man hat Ausschuß, Bis hin zum zerstörten Werkzeug mit entsprechenden Reparaturzeiten.

Der Steuerung übergibst Du nur Deine Bahn und die Parameter für Geschwindigkeit und Beschleunigungsrampen/-Kurven am Anfang und Ende.
den Rest muß die Regelung mit den transformierten Daten rausholen.
Über die vorher definierten Rampen/Kurven ist ja vorab schnell zu berechnen wo auf der Graden welche Geschwindigkeit zu fahren ist.
Das Reale System muß halt diesem virtuellen Modell folgen können damit das Ergebniss stimmt.

Genau das selbe macht auch eine karthesisch aufgebaute Fräsmaschine wenn man der entsprechende im Raum liegende Kurven gibt.
Bei einem 6-Achs Vertikal Knickarm wird das allerdings noch eine Ecke schwieriger.
In dem Link aus meinem letzten Post steht ja auch irgendwo das es keine allgemeingültige Lösung gibt.

###

Bei Beschleunigungsrampen, hast Du in gewisser Weise 2 Zwischenpunkte die bei der Bahnplanung vorab zu berechnen sind. Denn dort ändert sich ja die Beschleunigung.
Am Startpunkt beginnt man, von 0 aus, mit einer monoton steigenden Geschwindigkeit, bis man den Punkt erreicht an dem man die eigentliche Verfahrgeschwindigkeit erreicht hat dann fährt man mit gleichbleibender Geschwindigkeit bis zu dem Punkt ab dem man mit der monoton fallenden Geschwindigkeit beginnen muß um am Endpunkt eine Geschwindigkeit von 0 zu haben.

Erst wenn man mit Beschleunigungskurven arbeitet, also alle Geschwindigkeiten tangential, knickfrei ineinander übergehen sollen, dann kommen mehr Zwichenpunkte ins Spiel die zu berechnen sind. Dazu muß man dann aber auch für jeden Abschnitt der Spline das Polynom ermitteln mit dem dieser Abschnitt beschrieben wird. Denn nur so kann zur Laufzeit jeder Punkt iterativ berechent werden.

Je mehr Du Dich mit dem Thema befasst um so mehr wirst Du feststellen, das der mechanische Aufbau, die Antriebe und die Elektronik das kleinste Problem sind. Die Mathematik und diese dann clever in Software zu packen sind der haarige Teil.

Wenn man schneller zu positiven Ergebnissen kommen will, baut man zum einen erst mal einen Arm den man nur über Achspositionen steuert (der beherscht dann halt keine Graden- und Kreisinterpolation) und zum anderen, parallel einen karthesischen Aufbau (wie eine Fräsmaschine) und fängt dort dann mit Graden- und Kreisinterpolation an. Als Ergebniss kann mam da dann einen 3D-Drucker oder eine kleine Fräse schaffen. Mit den Erkenntnissen aus beiden Projekten kann man dann stückweise das Systemprogramm des Arms erweitern/umbauen.

Zitat:

Zitat von i_make_it

Bei Beschleunigungsrampen, hast Du in gewisser Weise 2 Zwischenpunkte die bei der Bahnplanung vorab zu berechnen sind. Denn dort ändert sich ja die Beschleunigung.
Am Startpunkt beginnt man, von 0 aus, mit einer monoton steigenden Geschwindigkeit, bis man den Punkt erreicht an dem man die eigentliche Verfahrgeschwindigkeit erreicht hat dann fährt man mit gleichbleibender Geschwindigkeit bis zu dem Punkt ab dem man mit der monoton fallenden Geschwindigkeit beginnen muß um am Endpunkt eine Geschwindigkeit von 0 zu haben.

Das heißt bei der Bahnplanung muss ich schon vorher die 2 Zwischenpunkte der Beschleunigungsphase jedes Gelenks einzeln bestimmen? Dann muss ich schon vorher die Bahn bestimmen um zu wissen wo Richtungsänderungen eines Gelenks auftauchen um dort die Zwischenpunkte der Beschleunigung zu bestimmen?

Ich Danke vielmals für die Hilfe bis jetzt. Das hat mir sehr geholfen.

Hi Micha,

für nen Fünfachser (klick) hatte ich mal ne Bahnplanung mit sehr minimaler Mathematik geschreiben:

......Bild hier

Wenige Stützpunkte zur Bahndefinition, Verbindung durch gerade Linien, Verschleifung der Punktumgebung und Synchronisation der verschiedenen Gelenke um eine möglichst glatte Bewegung zu gewährleisten (lief etliche Jahre in industrieller Umgebung), Parameteriesierung der Bahnkurve und funktionstechnische Doppeldeutigkeiten zu vermeiden.

Zitat:

.. bei der Bahnplanung muss ich schon vorher die 2 Zwischenpunkte der Beschleunigungsphase jedes Gelenks einzeln bestimmen? Dann muss ich schon vorher die Bahn bestimmen um zu wissen wo Richtungsänderungen eines Gelenks auftauchen um dort die Zwischenpunkte der Beschleunigung zu bestimmen ..

Mal etwas ausführlicher (trotzdem viel zu kurz) zu einem möglichen Prinzip: Auf den TCP bezogen kann ein Ausschnitt der Bewegung etwa so aussehen wie hier. Diese Darstellung kannst Du als (parameterisierte) Raumkurve interpretieren oder als Bewegung in einer (Kooridnaten-) Ebene usf. Diesen Ausschnitt hatte ich als planerischen Horizont benutzt. Sobald der TCP beim Punkt L vorbei war, wurde der Horizont geshiftet - L wurde K, M wurde L usf, bis am Ende des neuen Horizontes ein neuer Zielpunkt aus einer Liste eingefügt wurde. Wird das Bild als Darstellung der Bahn auf einer Koordinatenebene benutzt, so kannst Du Dir vorstellen dass Du nun einzelne Vorbeifahrten an Stützpunkten prüfen kannst auf die Geschwindigkeit in dieser Ebene - und die zu einer wahren Geschwindigkeit (insbes linear) im Raum zusammensetzen und mit diesen Werten die erforderlichen Gelenkgeschwindigkeiten (max. Drehzahl der Motoren!). Bei zu hohen Geschwindigkeit wird dann aus dem zulässigen Maximum zurückgerechnet und die Planung korrigiert - Horizontänderung und neue Planung der Kurve um den (neuen) Punkt L bei Laufbo=1. Dann wird die vorberechnete Bahn in zeitlich! gleich lange Abschnitte unterteilt werden die vom Roboter gefahren werden. OHNE Übergeschwindigkeit in den Gelenken, ohne zu hohe Beschleunigungen etc. Hier etwas mehr Text dazu.

Genaueres - und ausführlich(er) - zur Bahnplanung dieses hier.

Natürlich soll/muss immer überlegt werden, FMEA, ob Fehler, z.B. durch Doppeldeutigkeit, Nulldurchgänge, interne Gelenkanschläge etc möglich sind und wie die verhindert werden können. (Hilft Dir das zur klaren Vorstellung oder ist es schon zu aufwendig-kompliziert-etc ? )

Nein.
Die Punkte beziehen sich auf die lineare (virtuelle) Bahn.
Deine Gelenke werden dann rein durch die Sollwerte der Achsregelungen gesteuert, die sich durch die inverse Kinematik aus den X,Y,Z,A,B,C Koordinaten des jeweils zur Laufzeit berechneten nächsten Punktes ergibt.

Du errechnest bei der Bahnplanung ausgehend von Startkoordinate Xstart,Ystart,Zstart,Astart,Bstart,Cstart, der Zielkoordinate Xziel,Yziel,Zziel,Aziel,Bziel,Cziel, der Geschwindigkeit Vsoll, der Startbeschleunigung astart und der Bremsbeschleunigung aziel die koordinaten für die beiden Punkte wo die beschleunigte Bewegung in die gleichförmigen Bewegung übergeht und wo die gleichförmige Bewegung in die verzögerte Bewegung übergeht.
Jetzt hast Du drei Streckenabschnitte. Abschnitt 1 wo ausgehend von der Geschwindigkeit 0 für jedes Delta der Position ein Delta bei der Vergrößerung der Geschwindigkeit gilt. Im Abschnitt 2 gilt für jedes Delta der Position das die Geschwindigkeit gleich bleibt und im Abschnitt 3 gilt entsprechend eine Verkleinerung der Geschwindigkeit.
Macht man das nicht, dann kann es die Getriebe, Motoren oder Regler zerreißen, wenn die Antriebe versuchen mit einer (theoretisch) unendlichen Beschleunigung auf die Sollgeschwindigkeit zu kommen.

Wenn Deine Regleung nun z.B.: mit 1kHz läuft, berechnest Du alle 1ms die nächste X,Y,Z,A,B,C Position und per inverser Kinematik daraus die nächsten Achspositionen A1,A2,A3,A4,A5,A6 für jede Achse gibt es einen momentanen Positions Istwert. Und Du lieferst jetzt den Sollwert. Die Positionsregelung jeder Achse gibt dann per Soll-Istwert Vergleich eine Steuergröße an den jeweiligen Motortreiber. Ändert sich dabei die Drehrichtung einer Achse, dann ist das nur für die Achsregelung interessant und für Dich ob das Delta zwichen Istwert und Sollwert kleiner ist als die Grenzwerte des Antriebs. Deshalb hat man üblicherweise bei einer NC Achse eine Positionsregelung, eine nachgeschaltete Geschwindigkeitsregelung und eine nachgeschaltete Stromregleung. alle drei Regelungen haben dabei noch Überwachungen ob Grenzwerte überschritten werden und können so entweder einen Notstop auslösen oder eine Runterskalierung der Sollwerte der anderen Achsen durchführen, so das alle Achsen innerhalb der Betriebsgrenzwerte bleiben und die Bah nnicht verlassen wird.
Bei der Positionsregelung wird meist gestoppt, wenn eine Bahn eine Schutzzone verletzt.
Das dabei trotzdem was schiefgehen kann, merkt man, wenn zwar der TCP (dessen Position man so überwacht) immer im grünen Bereich ist, aber z.B.: der Ellenbogen hinten einmal alles abräumt. (selbst einmal erlebt, wie aus einer vollverkleideten Schleifmaschine ein Cabrio wurde).

Aus dem Grund werden komplette Roboterzellen trotzdem virtuell einmal vorher simuliert und alle Kollisionen der Volumenkörper zeigen dann, das man die Zelle umbauen muß oder die Bahn anders Planen muß.
Nich um sonst sieht man oft Roboter schöne Pirouetten mit einem Teil durchführen. Da get es oft darum, das Kabel oder Schläuche nicht abgerissen werden, oder das Teil nur durch das Drehen kollisionsfrei durch die umgebenden Objekte manövriert werden kann.

Jetzt hab ich es, Danke!

Die Kommunikation der Gelenke folgt über ein CAN-Bus. Somit ist eine gleichzeitige Ansteuerung der Achsen nicht möglich. Wie geht man damit um?
Meine Ideen waren:
1. Verzögerung vernachlässigen, aber die Gelenke immer in der selben Reihenfolge steuern oder
2. eine geplante Versetzung der Steuerung und diese Verzögerung in der Steuerung mit berücksichtigen.

CAN Bus ist von hause aus nicht echtzeitfähig, zwar kann man durch entsprechende Identifier eine Nachricht priorisieren, aber schon bei der Rückantwort (z.B.: bei Regelkreisen) kann nicht sichergestellt werden innerhalb welcher Zeitspanne die antworten.
Kommt es jetzt noch zu Störungen und Nachrichten schaffen den Annahmetest beim Empfänger nicht, hat man das selbe Problem wie bei Ethernet mit CSMA/CD.
Irgendwann kommt das Paket mal an. aber Echtzeitfähigkeit und somit Regelung ist damit nicht möglich.
Das ginge nur wenn man für jede Achse einen eigenen CAN Bus mit genau 2 Knoten betreibt (Achse und Controller).
Wenn man entsprechend langsam fährt, kann man mit Varinate 1 arbeiten, aber sicher ist man nie wirklich.
Variante 1 ist der zeitgesteuerte Buszugriff (Token passing)
CAN Bus funktioniert aber Bedarfsorientiert.
Also muß man über Prioritäten versuchen das hinzubekommen. Da gibts dann halt die Probleme mit den Antworten wenn man nur einem Knoten erlaubt Nachrichten mit den höchsten Prioritäten zu versenden.
Erlaubt man es allen kann alles durcheinander kommen.
mehr wie PTP wird man da niemals sicher hinbekommen.
Im Idealfall kappt es aber es gibt keine Vorhersagbarkeit für das Timingverhalten und somit keine verlässliche, robuste Regelung über mehr als eine Achse.

Vom Prinzip her kann man übrigens im CAN Bus alle Achsen auf einmal ansprechen. Man benötigt nur eine Nachricht in der die Daten für alle Achsen stehen. Dann müssen alle Achsen sich auch als Empfänger dieser Nachricht fühlen und dann muß jede Achse aus der Nachricht ausschließlich die Daten verarbeiten die für sie bestimmt sind und den Rest ignorieren.

Die Hauptaufgabe des Roboters wird es sein, Gegenstände an eine Bestimmte Position zu fahren und dort zu halten, so wie das auch ein Mensch Kann und in der ähnlichen Präzision. Aufgaben wie Abarbeitung von Materialien wo eine hohe Präzision gefordert wird, wird der Roboter nicht erfüllen müssen.

Wie sieht es bei einer PTP Bewegung aus, wird da auch vorher in die 3 Phasen unterteilt oder Regelt die Beschleunigung jede Achse für sich selbst?

Zitat:

Zitat von raze92

Wie sieht es bei einer PTP Bewegung aus, wird da auch vorher in die 3 Phasen unterteilt oder Regelt die Beschleunigung jede Achse für sich selbst?

Mit etwas Nachdenken kannst Du Dir das selbst beantworten. (unendlich große Beschleunigung)
Beim Beschleunigen kommt man ja noch damit hin solange Gas zu geben bis man die gewünschte Geschwindigkeit hat.
Renn einfach mal auf eine massive Wand zu und wenn Du dort bist und nicht mit voller Geschwindigkeit dagegen gerannt bist, dann überlegmal was Du gemacht hast.
Du hast entschieden an welchem Punkt du damit anfangen musst zu bremsen, damit du Dir nicht weh tust. Du hast also dein Bahn geplant und beim Abbremsen hast Du geregelt damit deine Verzögerung so passt, das Du genau vor der Wand zum Stillstand kommst. Und weder viel zu weit davor oder zu spät, so das Du Dir weh tust.
Jetzt überleg noch mal was man mit Bahnplanung und was man mit Regelung hinbekommen kann.

Oberallgeier hat Dir eigentlich schon ein elementares Hilfsmittel genannt.

Zitat:

Zitat von oberallgeier

Schau Dir doch mal den "Gelenkarm" Deines eigenen Körpers an. Nehmen wir an, die Faust sei Dein "TCP"

Beobachte mal dich selbst und versuche Dir klar zu werden was Dein Körper so schön automatisch macht.
Setze Dich an einen zu flachen Tisch und male mal ein Quadrat, Dreieck,Kreis ohne das Dein Arm irgendwo aufliegt, also Du freihand alle Gelenke koordinieren musst. Wenn Du ein Rechteck hinbekommst, dann wiederhole das mit geschlossenen Augen und versuche nur über das Körpergefühl die Bewegung nachzuvollziehen.
Dieser Selbstversuch kann sehr lehrreich sein um Regelung und Koordination zu verstehen. Denn Dein visueller Sensor (Augen) ist ja beim zweiten Teil ausgeschaltet. Ein direktes Bahn planen/Bahn regeln "in Process" ist damit nicht mehr möglich.

Dass eine Beschleunigung- und Bremsphase geben muss war mir ja klar, ich hatte mich nur gefragt, von wem das berücksichtigen werden soll.

Habe das jetzt so gedacht:
1. Die Gelenkstellungen vom Ziel berechnen,
2. die Gelenke miteinander Synchronisieren, dass sie alle gleich lange brauchen, wie das langsamste Gelenk,
3. und dann jeder Achse mit einem Beschleunigungsprofil versehe. Die Dauer der Beschleunigungs- und Bremsphase halte ich dann auch Synchron zu jeder Achse.

Zitat:

Zitat von raze92

1. Die Gelenkstellungen vom Ziel berechnen,

Funktioniert nur, wenn sich die Bewegungsrichtung einer Achse während der Bewegung nicht umkehrt.
Im Extremfall, kann ein Gelenk am Start und am Ende die selbe Position haben muß sich aber bewegen, damit die Ausrichtung des Teils während der Bewegung definiert ist (z.B. Glas Wasser).
So wirst Du auf jede Fall in bestimmten Situationen Probleme bekommen mit A,B,C also der Ausrichtung des Teils das Du handhaben willst.

So langsam komme ich zu dem Schluß, das Dir noch etwas Verständnis bei dem Thema fehlt.
Eventuell hilft es Dir ja wenn Du das visualisieren kannst.

Eine Möglichkeit, wäre wenn Du Dir mal ein paar Potis besorgst.
Bsp.: https://www.amazon.de/20K-Ohm-Pot-Po...words=20k+poti
Und mit etwas Bastelsperrholz einfach mal einen Arm mit den Potis als Achsen (Wellen) baust.
Dann kannst Du z.B. mit einem Arduino Nano
Bsp.: https://www.amazon.de/s/ref=nb_sb_no...s=Arduino+nano
für unter 10€ und der IDE aus dem Web einfach mal jedes Poti als Spannungsteiler aufbauen und die Schleifer an die Analogeingänge hängen. So kannst Du Dir bei verschiedenen Bewegungsabläufen einfach mal die Veränderung der Gelenkstellungen ansehen (z.B. mit dem seriellen Plotter).
Eventuell hilft Dir das die Zusammenhänge und die Konsequenzen verschiedener Herangehensweisen besser zu verstehen.

So wie ich es verstanden bestimmt man bei PTP nur die Gelenktstellungen des Ziel uns alle Gelenkte fahren dann auf dem kürzesten Weg(wenn keine Kollision entsteht) zu ihren Sollstellungen.

Seite 20, Kapitel 3.2
https://homepages.thm.de/~hg6458/Robotik/Robotik.pdf

die Abb. 3.2 und 3.3 zu PTP
(asynchron und synchron, mit dem nicht zu vernachlässigenden Hinweis "Damit ist die PTP-Steuerung für alle Bewegungen ungeeignet, bei denen es auf eine genaue Bahnführung ankommt. Beispiele dafür sind Schweißen, Montage, Kleben, Falzen, Entgraten usw.")
und die Abb 3.4 zu CP
mit den entsprechenden Erklärungen machen doch eigentlich die Sache sehr klar, oder habe ich deine Frage vlt nicht recht verstanden?

- - - Aktualisiert - - -
(edit, OP-post wurde zwischenzeitlich gelöscht)

zunächst ist das ganze in deinem pdf nur ein Modell zur Erklärung, nicht zur praktischen Implementierung.

Praktisch wird man Geschwindigkeiten und Streckenpunkte idealerweise durch unabhängige Setpoints per PID-Steuerung implementieren, mit Rampup- und Rampdown-Funktionen für Anfang und Ende und konstanten Geschwindigkeits-Setpoints für die Strecke dazwischen.

Wie man das richtig programmiert, ist eine ziemliche Herausforderung, schon alleine die korrekte Zielansteuerung ohne Geschwindigkeitssteuerung "in der Mitte" ist in C einigermaßen unübersichtlich, wenn man Oszillationen und Überschwingen und Verrecken unter Last kurz vor dem Ziel vermeiden will:

Code:

//*************************************************************//************************************************************* // motor API // motor API //*************************************************************//************************************************************* #define MAXMOTORS 10 // maximum number of motors #define MAXMOTORSLOCAL 2 // maximum number of local motors #define MAXPWMRANGE 255 // maximum software-pwm range (0-255) // motor control structure typedef struct { // electrical motor pins uint8_t pind1, pind2, pinpwm; // dir + pwm L293 H-Bridge type uint8_t pinQa, pinQb; // rotary enc pins Qa,Qb // pwm and encoder values int16_t dirpwm; int32_t motenc, oldenc; // rotary encoder values // PID pthread_t tid; // PID custom target values int32_t target; // set target int16_t tarpwm; // motor target speed // PID custom regulation parameters double P; // P: basic propotional to error double I; // I: integral: avoid perish double D; // D: derivative: avoid oscillating double precis; // error precision to target int32_t regtime; // PID loop time double damp; // damp the integral memory int8_t cont; // target: continue or hit once // internal control variables int16_t runstate; // monitors runstate int16_t outp; // PID control output value int16_t maxout; // max output (max motor pwr) int32_t read; // current sensor reading double err; // current error double integr; // integral of errors double speed; // current speed int8_t stopPIDcontrol; // flag for external termination } tEncMotor; tEncMotor motor[MAXMOTORS]; #define motorLeft motor[0] #define motorRight motor[1] // motor runstates: #define OUT_REGSTATE_NULL 0 #define OUT_REGSTATE_COAST 2 #define OUT_REGSTATE_BRAKE 3 #define OUT_REGSTATE_EMERG_STOP 5 #define OUT_REGSTATE_ON 8 #define OUT_REGSTATE_RAMPUP 9 #define OUT_REGSTATE_RAMPDOWN 10 #define OUT_REGSTATE_PIDIDLE 15 #define OUT_REGSTATE_ACTIVE 16 #define OUT_REGSTATE_PIDSTART 17 #define OUT_REGSTATE_PIDEND 18 #define OUT_REGSTATE_PIDHOLD 19 #define OUT_REGSTATE_PIDHOLDCLOSE 20 //************************************************************* #define motorCoast(nr) motorOn(nr, 0) // alias for motor coast //************************************************************* inline void motorBrake(uint nr, int dirpwm) { // brake by pwm power int pwm; pwm = abs(dirpwm); digitalWrite(motor[nr].pind1, HIGH); digitalWrite(motor[nr].pind2, HIGH); motor[nr].dirpwm = pwm; softPwmWrite(motor[nr].pinpwm, pwm); // brake power always > 0 } //************************************************************* inline void motorOn(uint nr, int dirpwm) { // motor On (nr, dir_pwm) int dir, pwm; // signed pwm: if(dirpwm > 0) dir = +1; // pwm > 0: forward else if(dirpwm < 0) dir = -1; // pwm < 0: reverse else dir = 0; // pwm = 0: coast if(! _REMOTE_OK_) dirpwm=0; pwm = abs(dirpwm); if(dir> 0) { digitalWrite( motor[nr].pind1, HIGH); digitalWrite( motor[nr].pind2, LOW); } else if(dir==0) { digitalWrite( motor[nr].pind1, LOW); digitalWrite( motor[nr].pind2, LOW); } else { digitalWrite( motor[nr].pind1, LOW); digitalWrite( motor[nr].pind2, HIGH); } motor[nr].dirpwm = dirpwm; softPwmWrite( motor[nr].pinpwm, pwm); } //*************************************************************//************************************************************* // PID control // PID control //*************************************************************//************************************************************* // forward: motor API functions inline void RotatePIDtoTarget (uint nr, int32_t Target, double RotatSpeed); // approach absolute target once inline void RotatePIDdegrees (uint nr, int32_t Target, double RotatSpeed); // turn relative degrees inline void RotatePIDcontinue (uint nr, int32_t Target, double RotatSpeed); // approach target continuously inline void StopPIDcontrol (uint nr); inline void PIDinit(); // P=0.4, I=0.4, D=10.0 // simple customized PID setting: inline void SetPIDparam(uint nr, double P,double I,double D); // extended customized parameter setting: inline void SetPIDparamEx(uint nr, double P, double I, double D, double prec, int16_t regtime, double damp); //************************************************************* inline void PIDcleanup(uint nr) { motorCoast(nr); motor[nr].runstate = OUT_REGSTATE_NULL; motor[nr].speed = 0; motor[nr].outp = 0; motor[nr].cont = 0; } //************************************************************* void * PID_calc(void *arg) { double aspeed, damp, PWMpwr, readold, errorold, tprop; int32_t readstart, cmax, cmin; // for monitoring int32_t starttime, runtime, clock, dtime; // timer int regloop; // arg nach index casten unsigned nr = (unsigned)arg; motor[nr].runstate = OUT_REGSTATE_PIDSTART ; // reg state: RAMPUP motor[nr].read = motor[nr].motenc; // get current encoder reading motor[nr].err = motor[nr].target - motor[nr].read; // error to target readstart = motor[nr].read; regloop = 1; damp=0; // damp the integral memory starttime= millis(); // appoach target _Astart: motor[nr].runstate = OUT_REGSTATE_ACTIVE; // run state: RUNNING do { pthread_testcancel(); if (motor[nr].stopPIDcontrol) { PIDcleanup(nr); return NULL; } dtime = millis() - clock; clock = millis(); runtime = clock - starttime; tprop = dtime/20.0; if ((motor[nr].err==errorold)&& (abs(motor[nr].err)>motor[nr].precis)) damp=1; // stalling else damp=motor[nr].damp; motor[nr].integr = (damp * motor[nr].integr) + motor[nr].err; if((motor[nr].integr) > 3*motor[nr].maxout) motor[nr].integr = 3*motor[nr].maxout; // cut away else if((motor[nr].integr) <-3*motor[nr].maxout) motor[nr].integr =-3*motor[nr].maxout; PWMpwr= (motor[nr].P*motor[nr].err) + (motor[nr].I*motor[nr].integr)*tprop + (motor[nr].D*(motor[nr].err-errorold))/tprop; if(PWMpwr > motor[nr].maxout) PWMpwr= motor[nr].maxout; // forward maxout else if(PWMpwr < -motor[nr].maxout) PWMpwr= -motor[nr].maxout; // reverse maxout motor[nr].speed= (motor[nr].read-readold)*100/dtime; // rotat speed [degrees/100ms] aspeed = abs(motor[nr].speed) ; if (abs(PWMpwr) > motor[nr].tarpwm ) { PWMpwr = sign(PWMpwr) * motor[nr].tarpwm ; } motor[nr].outp = round(PWMpwr); //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ // PID regulation ! motorOn(nr, motor[nr].outp); // action ! delay(motor[nr].regtime); // wait regulation time //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ readold = motor[nr].read; // save old sensor errorold = motor[nr].err; // save old error motor[nr].read = motor[nr].motenc; // get new encoder value motor[nr].err = motor[nr].target-motor[nr].read; // new error to target if (motor[nr].read>cmax) cmax=motor[nr].read; // monitor overshooting else if (motor[nr].read<cmin) cmin=motor[nr].read; // monitor overshooting if ((motor[nr].cont)&& (abs(motor[nr].err)<=motor[nr].precis)) motor[nr].runstate = OUT_REGSTATE_PIDSTART ; else motor[nr].runstate = OUT_REGSTATE_ACTIVE; if (motor[nr].cont) continue; if (abs(motor[nr].err)<=motor[nr].precis) { regloop +=1 ; motor[nr].runstate = OUT_REGSTATE_PIDEND ; } if (motor[nr].stopPIDcontrol) { PIDcleanup(nr); return NULL; } } while ((abs(motor[nr].err)>=motor[nr].precis) && (regloop<=5)); // target reached motorCoast(nr); // finished - stop motor motor[nr].runstate = OUT_REGSTATE_PIDEND; // run state: RAMPDOWN motor[nr].outp=0; delay(50); motor[nr].read = motor[nr].motenc; regloop=1; if (motor[nr].read>cmax) cmax=motor[nr].read; // detect overshooting if (motor[nr].read<cmin) cmin=motor[nr].read; // detect overshooting motor[nr].err = motor[nr].target-motor[nr].read; if (motor[nr].stopPIDcontrol) { PIDcleanup(nr); return NULL; } if ((abs(motor[nr].err)>motor[nr].precis)) {goto _Astart;} motor[nr].runstate=0; delay(1); //runstate = IDLE return (NULL); } //************************************************************* inline void RotatePID(uint nr, int32_t Target, double RotatSpeed, int8_t cont) { if( !motor[nr].tid && motor[nr].runstate) { motor[nr].runstate=0; // repair delay(1); } if( ( motor[nr].runstate ) || ( motor[nr].tid ) ) { motor[nr].stopPIDcontrol = 1; delay(1); while( motor[nr].runstate || motor[nr].tid ); // wait for PID task to terminate delay(1); PIDcleanup(nr); } // init new PID structure motor[nr].runstate = 1; // set runstate: PID active // custom init PID [nr] motor[nr].target = Target; // assign target motor[nr].tarpwm = abs(RotatSpeed); // assign max rotation speed motor[nr].cont=cont; // cont vs. hit once // Reset PID control defaults motor[nr].outp = 0; // PID control output value motor[nr].maxout = MAXPWMRANGE; // absolute max possible output (max pwr) motor[nr].read = 0; // current reading motor[nr].err = 0; // current error motor[nr].integr = 0; // integral of errors motor[nr].speed = 0; // current speed motor[nr].stopPIDcontrol = 0; // flag for external termination // start PID control task pthread_create( & motor[nr].tid, // id speichern in dem dazugehörigen Array-Element 0, // Default Attribute (threads cancelbar) PID_calc, // Name der PID-Kalkulationsroutinge (void *) nr); // der Index des Array-Elements für eine PID Struktur, // die mit dem Motorindex gleich ist. // run pthread task in detached mode, auto-cleanup pthread_detach(motor[nr].tid); } //************************************************************* inline void StopPIDcontrol (uint nr) { if (motor[nr].tid) { // stop PID task if already running motor[nr].stopPIDcontrol = 1; } } //************************************************************* // custom PID parameters Extended inline void SetPIDparamEx(uint nr, double P, double I, double D, double prec, int16_t regtime, double damp) { motor[nr].P = P; // P: propotional to error motor[nr].I = I; // I: avoid perish motor[nr].D = D; // D: derivative: avoid oscillating motor[nr].precis = prec; // error precision to target motor[nr].regtime = regtime; // PID regulation time motor[nr].damp = damp; // damp error integral } //************************************************************* // custom PID parameters inline void SetPIDparam(uint nr, double P, double I, double D) { motor[nr].P = P; // P: propotional to error motor[nr].I = I; // I: integral: avoid perish motor[nr].D = D; // D: derivative: avoid oscillating } //************************************************************* inline void PIDinit() { for (uint nr=0; nr < MAXMOTORS; ++nr) { SetPIDparamEx(nr, 0.40, 0.40, 10.0, 1.0, 5, 0.75); // p,i,d, precis, reg_time, damp delay(1); } } //************************************************************* inline void RotatePIDtoTarget(uint nr, int32_t Target, double RotatSpeed) { RotatePID(nr, Target, RotatSpeed, false); delay(1); } //************************************************************* inline void RotatePIDcont(uint nr, int32_t Target, double RotatSpeed) { RotatePID(nr, Target, RotatSpeed, true); delay(1); } //************************************************************* inline void RotatePIDdegrees(uint nr, int32_t Target, double RotatSpeed) { RotatePID(nr, Target+motor[nr].motenc, RotatSpeed, false); delay(1); } //************************************************************* // ^^^^^^^^^^^^^^ PID end ^^^^^^^^^^^^^ //*************************************************************

Ich habe PTP und LIN seperat betrachtet. Für beide Bewegungen erzeuge ich eine Tabelle die die Gelenkstellungen beinhaltet für die zu fahrende Bahn.

Ich übergebe der Gelenksteuerung die Tabelle mit den Gelenkstellungen mit zusätzlich den Geschwindigkeiten jedes Gelenks an jedem Zwischenpunkt. Die Gelenke sollen dann mit der Geschwindigkeit fahren, bis die Soll-Gelenkstellung erreicht wurde. Dann wird die nächste Geschwindigkeit an die Gelenke gesendet usw.
Da kam ich aber jetzt auf den Schluss, dass mit diesem vorgehen eine Bahn schnell abweichen kann und nicht mehr in die Bahn zurück kommt.

Wenn ich jetzt stattdessen eine Interpolation durchführe der Linearen Bahn und mit den 3 Phasen das Geschwindigkeitsprofil der Bahn bestimme und jeden Interpolationspunkt nun über eine synchrone PTP-Steuerung übergebe:
Wie Regel ich die Geschwindigkeit in der PTP-Steuerung des TCP?

das habe ich doch gerade erklärt: über eine PID-Steuerung.
Ich habe den Eindruck, du hast überhaupt keine praktische Erfahrung, und aus einem rein theoretischen Ansatz heraus wirst du hier nicht weiterkommen, fürchte ich.

Hast du überhaupt jemals praktisch einen Roboterarm programmiert?
Wenn ja, welchen (Hardware) und mit welcher Programmiersprache (Software)?

Wenn du tatsächlich noch keine praktische Erfahrung hast: Kauf dir mal einen Arduino Mega und einen Arduino Braccio Roboterarm, und dann fang einfach mal an.

Deine Antwort hab ich erst danach gelesen

Zitat:

Zitat von HaWe

das habe ich doch gerade erklärt: über eine PID-Steuerung.
Ich habe den Eindruck, du hast überhaupt keine praktische Erfahrung, und aus einem rein theoretsichen Ansatz heraus wirst du hier nicht weiterkommen, fürchte ich.

Hast du überhaupt jemals praktisch einen Roboterarm programmiert?
Wenn ja, welchen (Hardware) und mit welcher Programmiersprache (Software)?

Nein hab ich leider noch nicht. Das Projekt ist eine Aufgabe in der Firma wo ich momentan tätig bin, dort soll ich erstmal alles Theoretisch erarbeiten.

Zitat:

Zitat von raze92

Wie Regel ich die Geschwindigkeit in der PTP-Steuerung des TCP?

Hatten wir schon mal.
Motorregler für NC-Achsen haben Positionsregler, nachgeschaltete Geschwindigkeitsregler und nachgeschaltete Stromregler.

Dein Positionsregler hat eine Zykluszeit z.B. regelt er alle 1ms.
Dann hast du einen Istzustand (Istposition) und den Sollzustand (Sollposition) der innerhalb der Zykluszeit erreicht werden soll.
Wir haben also eine Zeit (Zykluszeit 1ms) und eine Strecke (sollposition minus Istposition)
Geschwindigkeit ist Weg pro Zeiteinheit.
Sprich dein Positionsregler liefert Dir den Sollwert für Deinen Geschwindigkeitsregler und dein Meßsystem (Tachogenerator, Resolver, Drehgeber) liefert Dir den Istwert.
Der Stromregler sorgt dann dafür das auch das notwendige Drehmoment da ist.

Zitat:

Zitat von HaWe

wenn man Oszillationen und Überschwingen und Verrecken unter Last kurz vor dem Ziel vermeiden will:

Um das zu vermeiden.

Zitat:

Zitat von HaWe

PID-Steuerung

Ist meiner Meinung Nach eine unglückliche Wortwahl, da es nicht um eine Steuerung (Steuerstrecke ohne Feedback) geht sondern um eine Regelung (Regelkreis mit Soll-Ist vergleich und entsprechnder Nachführung) geht.
Eine Steuerhardware oder eine Steuersoftware die PID Regelung enthält, wird in Marketingsprache allerdings mittlerweile gerne als PID-Steuerung angepriesen.

Interessant wäre jetzt zu erfahren wie Dein Wissensstand bei Steuer- und Regelungstechnik ist.
Ein Fachbuch zum Thema wäre z.B. "Elementare Regelungstechnik".
Ein Buch mit dem man direkt in die Softwareimplementierung von Reglern starten kann, wäre "Praxisbuch Regelungstechnik" (von dem es allerdings anscheinend keine Neuaflage gibt)

Ich habe beschlossen für unsere Anwendung die Gelenkstellungen vorher zu berechnen und nicht zur laufzeit.

Zitat:

Zitat von i_make_it

Dein Positionsregler hat eine Zykluszeit z.B. regelt er alle 1ms.
Dann hast du einen Istzustand (Istposition) und den Sollzustand (Sollposition) der innerhalb der Zykluszeit erreicht werden soll.
Wir haben also eine Zeit (Zykluszeit 1ms) und eine Strecke (sollposition minus Istposition)
Geschwindigkeit ist Weg pro Zeiteinheit.
Sprich dein Positionsregler liefert Dir den Sollwert für Deinen Geschwindigkeitsregler und dein Meßsystem (Tachogenerator, Resolver, Drehgeber) liefert Dir den Istwert.
Der Stromregler sorgt dann dafür das auch das notwendige Drehmoment da ist.

Wenn ich es dann über die Zykluszeit berechne, dann muss ja gegeben sein, dass die Interpolationspunkte den selben Abstand haben. Gedacht war, dass in der Beschleunigungsphase und Bremsphase die Interpolationsdichte größer ist.
Ich möchte die Regelung Softwaretechnisch lösen. Bestimme ich dann die Zykluszeit bei der Interpolation und übergebe diese zusammen mit den Rücktransformierten Gelenkstellungen? Dann könnte ich die nötige Geschwindigkeit berechnen und Fahren. Und um das Phasenproblem zu lösen übergebe ich 3, bzw 2, Zykluszeiten für die Phasen.

Kenntnisse zu Regelungstechnik sind vorhanden.

Zitat:

Zitat von raze92

Wenn ich es dann über die Zykluszeit berechne, dann muss ja gegeben sein, dass die Interpolationspunkte den selben Abstand haben.

Hä?????????????????
Bei gleich großem zeitlichem Delta, (z.B. 1ms) kann der Abstand der Interpolationspunkte gar nicht immer gleich sein.
Bei einer Geschwindigkeit von 0mm/s ist der Abstand z.B. 0mm.
Bei 500mm/s ist der Abstand 0,5mm.
Bei gleicher Zeit ist der Abstand immer Proportional zur Geschwindigkeit.

Sorry wenn ich bei anscheinend so grundlegenden Verständnissproblemen der physikalischen Zusammenhänge, den Kenntniss Stand (oder besser den Verständniss Stand) zur Regelungstechnik als nicht besonders hoch einschätze.

Ich kann Deinen Wissensstand halt nur anhand dessen einschätzen was ich hier von Dir lese. Und das wirkt halt grade nicht so.

Ich denke am besten wäre wenn Du erst einmal anhand des Vorlesungsscripts das Du gepostet hast Deine Eingangsfragestellung betrachtest und Dann noch mal neu formulierts wo du ein Verständnissproblem hast.

Ach jaaa :Haue.

Zitat:

Zitat von i_make_it

Sorry wenn ich bei anscheinend so grundlegenden Verständnissproblemen der physikalischen Zusammenhänge, den Kenntniss Stand (oder besser den Verständniss Stand) zur Regelungstechnik als nicht besonders hoch einschätze.

Ich kann Deinen Wissensstand halt nur anhand dessen einschätzen was ich hier von Dir lese. Und das wirkt halt grade nicht so.

Kein problem. Brauche auch langsam eine Pause von der Theorie.

Dann so:
Ich lege eine Zykluszeit fest. Anhand dieser setze ich die Interpolationspunkte. Ja das hatten wir schon.

Ich bedanke mich vielmals für die Mühe, mir die ganzen Fragen zu beantworten.

Wenn Du Dich mit der ganzen Theorie grade anfängst im Kreis zu drehen und vor lauter Bäumen keinen Wald mehr siehst, dann gehe hin und bastel Dir Zur Not aus Pappe ein kleines Model mit Winkelskalen und als Hilfsmittel mal ein Lineal oder ein Stück von einer Pringlesdose (oder was anderes) dann kannst Du ganz praktisch Graden und Kreisinterpolation und deren Auswirkungen auf die Gelenkstellungen durchspielen und ggf. auch mit konkreten Zahlenwerten durcharbeiten.

Es hilft oft simplifizierte, praktische Versuche zu machen um ein Verständniss zu entwickeln oder sich aus einer selbst gegrabenen gedanklichen Grube wieder zu befreien.

Bei so einem Modellarm kann man auch mit etwas Schnur und einem Pappstück das man festklemmt, schnell Anschläge für die Gelenk Start- und Endstellungen herstellen und sich dann einfach mal ansehen, wie sich die PTP-Bewegung von der Bahnbewegung, für die selben gegebenen Start- und Endpositionen unterscheidet.

Oder man macht das mit einem Zollstock.

Wie kann man aus den maximalen Gelenkbeschleunigungen die maximale Beschleunigung einer Bahn berechnen?

Kommt auf die Bahn an.

Bei einer Kreisbahn, deren Mittelpunkt das Gelenk ist, ist die Umfangsgeschwindigkeit direkt abhängig vom Radius und der Winkelgeschwindigkeit des Drehgelenks.
Damit ist auch die Beschleunigung über den Radius proportional zur Beschleunigung am Drehgelenk.
Für jede andere Bahn, ist ja mehr als ein Gelenk beteiligt. Da kann man es dann nicht mehr einfach berechnen.
Da benötigt mann dann die Rechenschritte der direkten Kinematik bzw. der inversen Kinematik (je nach dem von was man auf was schließen will), da man ja damit jede TCP Position ermitteln kann und über das zeitliche Delta die Geschwindigkeit die zwichen zwei Posen erreicht wird.
Bei (mindestens) drei Posen, erhält man bei einer Beschleunigung zwei verschiedene Geschwindigkeiten für beide Strecken, und kann so über den Geschwindigkeitsunterschied die Beschleunigung ermitteln.
Nimmt man keine Beschleunigungsrampen, sondern Beschleunigungskurven, die tangential ineinander übergehen, dann ändert sich logischerweise auch ständig die Beschleunigung.
Das ganze erfolgt also iterativ.
Weshalb eine NC-Achsen Regelung auch immer eine Positionsregleung mit nachgeschalteter Geschwindigkeitsregelung hat.
Dementsprechend wird bei der Robotersimulation auch über die, in einem festen Zeitraster erfolgende Positionsbestimmung auch eine nachgeschaltete Geschwindigkeitsbestimmung für die Strecke zwichen den einzelnen Posen vorgenommen.
Aus dem Delta der Geschwindigkeiten zwichen diesen verschiedenen Posen erhält man dann die Beschleunigungen.
Will man nicht vorab Simulieren, setzt man eine Maximalgeschwindigkeit und Maximalbeschleunigung fest, die den einzelnen Achsen genug Reserve nach oben lässt dies auch zu erfüllen.
Das ganze macht man unter Annahme der maximal zu handhabenden Last.
Damit wird dann sichergestellt, das der Arm die als Maximum angegebene Last auch mit der als Maximum angegebenen Geschwindigkeit und Beschleunigung bewegen kann.
Sprich jeder Roboterarm kann sich, ohne Last und unter Umgehung der per Parameter festgelegten Obergrenzen, eigentlich viel schneller bewegen.