Pendelbewegung

und wie lautet die Frage ?

Zitat von IrrerPolterer

ähhhh...wie kriegt man das programmtechnisch hin?
Also...ich meine. wie programmiere ich diese Bewegung?

Also praktisch so eine Art gleichmäßige Entgratung!

also die Bilder darfste gerne drinlassen, is doch schön, wenns so schön bunt ist hier.

Ja und Dein Problem kann ich leider immer noch nicht genau einordnen.
Hört sich aber nach einem mathematischen Problem an, oder ?

Ich würd den TCP jeweils um die Bohrkrone verschieben, je nachdem, wos passiert.

Base brauchste nur im Lochmittelpunkt.

Der Rest sollte lösbare Rechenarbeit sein.

...nochmal zum Verständnis:

also wie ich das sehe, muß
1. der TCP zentrisch über dem Loch positioniert werden

2. während der "Bohr/Entgratbewegung" wird der TCP zum Loch hin abgesenkt (Z), verändert aber bzgl. der Lochmitte seine Position nicht

3. das Werkzeug wird kreisförmig um den TCP herumgeführt (wobei sich also lediglich die Werkzeug-Orientierung ändert, nicht die TCP-Position!)

4. der Bewegungsablauf des Werkzeuges beschreibt dabei den Mantel eines, mit der Spitze nach unten zeigenden Kegels, mit dem TCP als Kegelspitze

5. ich würde das eher als "Rühren" statt "Pendeln" bezeichnen

Wenn das soweit alles richtig ist, dann kann ich dir leider keine konkreten Programmieranweisungen geben, da ich von KUKA überhaupt keine Ahnung habe aber wie wäre denn folgender Ansatz:

- erste Position/Orientierung teachen mit 1° "Schräge" nach einer Seite
- TCP beibehalten (!) und zur gegenüberliegenden Seite mit 1° abkippen (= 2° Rotation im Werkzeug-Koord.-System)
- zweite Position/Orientierung teachen
- mit Kreisinterpolation (müsste es ja wohl bei KUKA geben ) zwischen den beiden Orientierungen wechselseitig verfahren

Weiß zwar nicht ob's geht, aber ich denke bei ABB würde ich das schon so (oder ähnlich) hinbekommen....

Gruß
Rainer

mmmh,

2 geteachte Halbkeise (CIRC-Bewegung) ..?
z-Koordinate programmtechnisch absenken, falls Rainer recht hat unter Punkt 2 .??
das ganze inner Schleife ???

Was hast Du denn schon alles probiert?

Hallole,
meiner Meinung nach ist der TCP falsch gewählt.
Denn das Problem der ganzen Lösungsvorschläge ist, dass da der
TCP quasi immer auf ein und der selben Stelle 'steht'.
Da kommt man weder mit Linear- noch mit Kreisbewegungen weiter.
Denn der TCP steht ja. Wo soll da eine Kreisbewegung herkommen?

Also meine Gedanken (ohne Anspruch auf Funktionsfähigkeit):
TCP auf den Rand der Borhkrone setzen, und dann
kann man das nochmal mit ganz normalen LIN- Bewegungssaetzen probieren.

Oder den TCP in der Mitte der Antriebswelle der Bohrkrone aber viel weiter
oben setzen und mit Kreisbewegungen probieren.

Tschau, schönen Sonntag noch.
Hermann

Zitat von Hermann

[...]Denn das Problem der ganzen Lösungsvorschläge ist, dass da der
TCP quasi immer auf ein und der selben Stelle 'steht'.
Da kommt man weder mit Linear- noch mit Kreisbewegungen weiter.
Denn der TCP steht ja. Wo soll da eine Kreisbewegung herkommen?[...]

Die Bewegung kommt halt dadurch, dass sich die Orientierung ändert, nicht notwendigerweise der TCP:
Stell dir mal vor du sitzt mit deiner vierköpfigen Familie am Sonntagmorgen an eurem kreisrunden Frühstückstisch. Weil ihr ganz sparsame Schwaben seid, teilt ihr euch ein Frühstücksei welches in der Mitte des Tisches steht. Gegessen wird mit einem Löffel, der immer reihum von einer Person zur Nächsten weitergegeben wird. Dabei bleibt die Position des Eis (oder heißt das dann Eies ?) immer an der gleichen Stelle, nur die Orientierung des Löffels ändert sich und der Löffelstiel beschreibt dabei eine Kreisbahn um das Ei.

Gruß
Rainer

Hallole,
ja, schon klar, dass die Bohrkrone eine Bewegung macht, aber
der TCP selber bewegt sich eben nicht.
Bei sämtlichen Robotern, die ich kenne, wird die Bahn und die
Bahngeschwindigkeit aber auf den TCP bezogen, alles andere
wäre auch sinnlos.
Wenn jetzt der TCP auf einer Stelle steht, und sich nur die
Orientierung ändert, dann gibt das ein physikalisches Problem,
das sich nicht ohne weiteres sauber lösen lässt:

Ich gebe zwei Punkte an, die sich nur in der Orientierung
unterscheiden, der TCP steht also an einer Stelle und ich
gebe eine Bahngeschwindigkeit des TCP's auf der Bahn an.

Jetzt hat der TCP eigentlich einen Weg von 0 mm zu fahren,
das mit einer Geschwindigkeit von sagen wir mal 100mm/s
daraus kann ich dann ausrechnen, dass der Endpunkt in
0 Sekunden erreicht wird. Aber die Orientierung ist ja
unterschiedlich, daher müsste der Roboter die Orientierung
innerhalb von 0 Sekunden auf den Zielpunkt ändern.
Das kann er nicht. Also machen das manche Roboter so,
dass sie mit zu grossen Achsgeschwindigkeiten aussteigen
andere begrenzen die Geschwindigkeiten so, dass sie nicht
aussteigen. Aber die Geschwindigkeit ist eigentlich nicht mehr
programmtechnisch sauber kontrollierbar.

Nächstes Problem: Wie bekomme ich da eine Kreisbahn
(wohlgemerkt mit dem Roboter geteacht) hin?
Normalerweise wird ein Kreisbahn durch drei Punkte definiert:
der Startpunkt, ein Zwischenpunkt und der Endpunkt. Wenn
jetzt der TCP auf einer Stelle steht, dann liegen alle drei
Punkte auf den selben Koordinaten. Da kann beim besten
Willen keine Kreisbahn berechnet werden. Normalerweise
erntet man da eine Fehlermeldung wie:
Punkte liegen zu nahe beieinander oder so ähnlich.
Ein ähnliches Problem gibt es, wenn ich es schaffe alle
drei Punkte exakt auf eine Gerade zu legen, auch da
kann kein Kreis berechnet werden.

Tschau, Hermann

Zitat von Hermann

[...]Also machen das manche Roboter so,
dass sie mit zu grossen Achsgeschwindigkeiten aussteigen
andere begrenzen die Geschwindigkeiten so, dass sie nicht
aussteigen. Aber die Geschwindigkeit ist eigentlich nicht mehr
programmtechnisch sauber kontrollierbar.[...]

Gut, das mag ja alles so sein, hängt aber von der jeweiligen Möglichkeiten/Implementierung der Steuerung ab. Wie schon gesagt, von KUKA habe ich leider keine Ahnung.
Hierzu aber mal ein kurzer Auszug aus der ABB-Doku zu diesem Thema:

Zitat

[...]The orientation of the tool remains constant during the entire movement unless a
reorientation has been programmed. If the tool is reorientated, it is rotated at constant
velocity. A maximum rotational velocity (in degrees per second) can be specified when rotating
the tool. If this is set to a low value, reorientation will be smooth, irrespective of the
velocity defined for the tool centre point.[...]

Zitat von Hermann

[...]Wenn jetzt der TCP auf einer Stelle steht, dann liegen alle drei
Punkte auf den selben Koordinaten. Da kann beim besten
Willen keine Kreisbahn berechnet werden.[...]

Jo, da gebe ich dir Recht, das wird so nicht funzen

Wie wäre es denn ein Werkobjekt in der Mitte des Loches zu definieren, per Programm das gesamte Werkobjekt um Z rotieren und dabei mit dem Werkzeug zu folgen ?
Wenn ich ein bisschen Zeit hab, dann probier ich das mal in der ABB-Simulation....

Gruß
Rainer

Eigentlich klingt das recht einfach:
Base in der Mitte des Lochs
TCP bis z= ein bisschen was ans Loch ran fahren
TCP so weit um B (um Y-Achse) kippen, bis er den Rand berührt (Lässt sich mit dem Sinussatz berechnen)
Dann zwei LIN Bewegungen:
LIN_REL {A 180}
LIN_REL {A 180}
Vielleicht reicht ja sogar
LIN_REL {A 360}
Um den TCP zu drehen. Vielleicht geht ja auch so was:
LIN_REL {z 1, a 1080}
Um den TCP während er sich drei mal um sich selber dreht um einen Millimeter näher ran zu fahren.
Ich meine CP_ORI kann in irgendeiner Form benutzt werden um die Winkelgeschwindigkeit einzustellen, wie habe ich allerdings nicht verstanden, da dabei zwischen Dreh- und Schwenk-Bewegungen unterschieden wird und ich nirgendwo finden konnte, wo da der Unterschied liegt.

Zitat von kai_n

Ich meine CP_ORI kann in irgendeiner Form benutzt werden um die Winkelgeschwindigkeit einzustellen, wie habe ich allerdings nicht verstanden, da dabei zwischen Dreh- und Schwenk-Bewegungen unterschieden wird und ich nirgendwo finden konnte, wo da der Unterschied liegt.

@ kai_n Das könnte funzen!
Mit dem herabsetzten von $ORI_VEL kannst du z.B. verhindern, dass dir Achse 4 mit Sollgeschwindigkeit aussteigt, wenn du bei einer PTP-Bewegung ungünstig über die Kanonenstellung fährst!

Man kann Schwenkbewegungen auf Grad/Sekunde statt mm/sec begrenzen.
Somit könnten auch 2 Linearpunkte, die auf der gleichen Koordinate mit unterschiedlicher Orientierung liegen, anfahren.

Ansonsten bin ich mit Kais Lösung am ehesten einverstanden.

Obwohl ich die Aufgabe ehrlich gesagt immer noch net ganz kapiert hab.

Ich glaub es geht um ne Art Entgraten oder Abschrägen oder so.

Ich hatte gestern nen Denkfehler: Wenn der TCP um B gedreht wird und anschliessend um A rotiert, dann rotiert der um die um B gekippte Z-Achse.
Aber so gehts: Das Tool, das dieses Werkzeug beschreibt, muss um B gekippt werden. Dann mit diesem Tool den Punkt
Z=ein bisschen
Im Base anfahren und wie gestern beschrieben um A rotieren. Dann dreht der um die Z-Achse des Tool, die nach wie vor in der Z-Achse des BASE liegt. Dann müsste es gehen.

Noch eine Idee, die vielleicht hübscher aussieht: Das $TOOL nicht kippen.
WINKEL ist der Winkel, um den gekippt werden muss, um den Rand zu berühren.

LIN {z 10, b winkel}

FOR i=1 to Anz_umdrehungen
LIN_REL {b 0, c winkel}
LIN_REL [b -winkel, c 0}
LIN_REL {b 0, c -winkel}
LIN_REL {b winkel, c 0}
ENDFOR

Um nebenher z näher ran zu fahren fehlt mir noch ne Idee.