Konfiguration richtig programmieren - wie?

Neuer IRB 2400, ich bin auch neu hier.

Der Roboter soll sphärische Linsen polieren.
Das Werkzeug soll immer senkrecht zur Oberfläche stehen.
Die Bahn soll mit MoveL Befehlen gefahren werden.

Ich habe ein Programm geschrieben, das für eine vorgegebene
Bahn die Position (x,y,z) und die Orientierung (Quaternion)
berechnet. Als nächstes müßte ich die Komponente
robconf (Typ confdata) von robtarget mit sinnvollen Werten füttern.
Bei IRB 2400 werden die ersten drei Komponenten von confdata
genutzt (Achsen 1,4,6).

Ich suche nun nach einer Möglichkeit, für gegebene Zielposition
und -orientierung bei bekannten Werkzeug- und Werkstückdaten
die Positionen der einzelnen Achsen vorherzusagen. Dadurch,
daß um die zu bearbeitende Linse "herumgefahren" wird,
ändert sich die Konfiguration ja ständig.

Gibt es eine Möglichkeit, das offline zu erreichen. Telefonische
Nachfrage bei ABB ergab nur die Vorschläge
- Konfigurationsüberwachung abschalten (ConfL\Off) und robconf
überall mit Nullen zu füllen.
das funktioniert aber nicht, da Achse 4 dann schon bald in Endlage
(200 Grad) landet.
- zur Laufzeit die aktuellen Werte mit CJoinT() auszulesen
Das will mir auch nicht so recht gefallen, da man hier immer einen
zeitlichen Versatz hat.

Kann mir jemand raten, ob/wie ich die Roboterkonfiguration
vorher errechenen kann?

----------------------------------------------------------------------------

Ein anderes Problem ist die "Handgelenk-Singularität" (Achse 5 = 0 Grad)
Dann wird die Bewegung so langsam, daß man ein Loch in die
Linse polieren würde.

Kann man das im Vorfeld prüfen, ob man bei gegebener Bahn
in diese Falle laufen wird - und ggf. konstruktive Gegenmaßnahmen
(z.B. Werkzeug mit Keil befestigen) ergreifen.
Aber diese Frage ist der obigen ähnlich.

Vielen Dank im Voraus.

Zitat von robotic74

"Bei den einfachsten Linsen sind die beiden optisch aktiven Flächen sphärisch. Das heißt, sie sind Oberflächenausschnitte einer Kugel. Daher kann man diesen Flächen Krümmungsradien zuordnen."

So und warum verwendest Du dann nicht MoveC-Instruktionen. Die Positionen innerhalt einer MoveC-Instruktionen können ebenfalls noch mit Funktionen wie Offs bzw. RelTool oder beides zusammen verwendet werden.

Naja, die sphärischen Linsen (Kugeloberfläche) sind natürlich
nicht die ganze Wahrheit. Der Roboter wurde angeschafft,
um letztlich Freiformflächen (z.B. Asphären/asphärische Zylinder/
Ellipsoide/Toroide/...) bearbeiten zu können. Sphären sind nur eine
Art Zwischenschritt zum Üben.
Insofern ist der MoveL-Ansatz sicher besser zu verstehen. Ich halte
ihn im allgemeineren Fall für sinnvoll.

Zitat von robotic74

Also um Deine 4-Achse würde ich mir keine Sorgen machen. Einfach den Bereich erweitern in der MOC.cfg Der Grenzwert ist hier jeweils für die positive wie negative Richtung angegeben und wird ind Radianten angegeben. D.h. 360° sind 2*PI = 6,283185. So nun kannst du ja nach Lust und Laune den Bereich erweitern. (z.B.: die Achse 4 hat jetzt eine Wert von 4,625122 dann haben wir in der positiven Richtung 265 Grad. Ein Grad hat eine Wert in Radianten von 0,017453.)

Danke. Jetzt weiß ich also, wo die Achsenbegrenzungen abgelegt sind.
(Gradmaß/Winkelmaß kann ich umrechnen
Wenn ich sehr hohe Werte zulasse muß ich nur beachten, daß sich
irgendwelche außen angebrachten Kabel nicht verhedderen. Ist
etwas ähnliches auch 'in' den Armen zu beachten oder können die
sich beliebig oft verdrehen ohne daß da etwas reißt?

Zitat von robotic74

Thema Singularität kann ich Dir nur raten die Hardwareposition zu überdenken. Nur damit bekommst Du dieses Problem wirklich in den Griff. Du kannst ja die Station so positionieren das es günstiger wird für den Roboter. Aber das ist schließlich nur wage da ich die Vorraussetzungen so nicht kenne.

Genau das möchte ich ja, nämlich möglichst die Handgelenk-Singularität
vermeiden. Leider sieht man den Positionen/Quaternionen nicht an,
ob daraus Achse 5 nahe Null folgt. Ich suche nach einer Funktion, die mir
schon beim Erstellen des Programms sagt, so daß geeignete
Gegenmaßnahmen ergriffen werden können. Wie gesagt, CJointT
scheint mir nicht geeignet, beim Stöbern im Roboterforum bin ich aber
auf CalcJointT gestoßen. Hilft mir das weiter? Immerhin will CalcJointT
ja schon eine sinnvolle Konfiguration als Argument haben.
Ich will diese ja erst bestimmen. Komme ich da weiter?

P.S. In der Hoffnung auf einen größeren Leserkreis habe ich die
Frage auch auf roboterforum.com gestellt. Es genügt mir aber,
das ganze in Deutsch zu diskutieren.

Zitat von robotic74

Ja zum Thema CalcJointT kannst Du denn wert von Positionen rechnerisch richtig 'vergewaltigen' hast dort alle Möglichkeiten zum testen und prüfen. Du hast ja dann auch die Möglichkeit über die Fehlerbehandlung bei einer fehlerhaften Berechnung zu reagieren.

Ich frage nochmal nach, da ich es immer noch nicht ganz klar ist, wie ich vorgehen
sollte. Ich habe ein Oberfläche z=F(x,y) und eine Bahn auf dieser Oberfläche
[[x1,y1,z1],[x2,y2,z2],...] gegeben. Die Punkte legen ausreichend nahe beieinander.
Zu jedem Bahnpunkt kann ich mir das zugehörige Quaternion berechnen, so daß
das Werkzeug senkrecht auf der Oberfläche steht.
Diese Werkzeugposition/-orientierung kann der Roboter möglicherweise
durch verschiedene Konfigurationen (z.B. Achse 4/6) erreichen. Ich möchte
nun den MoveL-Befehl mit günstigen Konfigurationen füttern, so daß es möglichst
nicht von einem Bahnpunkt zum nächsten zu einer totalen Umorientierung
kommt. Mit CalcJointT kann ich von robtarget in jointtarget umrechnen, und mit
CalcRobT umgekehrt von jointtarget in robtarget.
Am Anfang habe ich also ein unvollständiges robtarget (Komponente robconf
ist möglicherweise ungünstig geraten) dann rechne ich in jointtarget um.
Dann müßte ich (zur Laufzeit) das aktuelle jointtarget mit dem vorigen vergleichen.
Wenn nun große Sprünge in den einzelnen Achsen auftreten versuche ich diese heuristisch zu korrigieren, rechne wieder in robtarget zurück und übernehme
von dem zurückgerechneten robtarget nur die Komponente robconf in mein
ursprüngliches robtarget.
Und wenn Achse 5 einen Nulldurchgang hat oder sich der Null auch nur nähert
breche ich ab/ warne den Nutzer/...
So ein richtig gefällt mir das noch nicht, das ist, als ob sich die Katze in den Schwanz beißt.

Geht das besser/eleganter?

Zitat von robotic74

Eine linieare Bewegung von P1 zu P2 ist nicht wirklich eine lineare Bewegung.
Habe dazu Test gemacht in der Vergangenheit. Die Steuerung berechnet mehrere Zwischenpunkte. Diese liegen auf der Bahn linear zwischen P1 und P2. Aber die Bewegung zwischen den einzelnen Zwischenpunkten ist nicht linear!

Die Bahn ist relativ eng abgestützt. Um eine flüssige Bewegung zu erreichen,
benutze ich Fly-by-Punkte. Die Zonengröße lege ich für jeden Bahnpunkt
einzeln fest. Dazu nehme ich den kleineren der beiden Abstände zu den benachbarten Bahnpunkten und begrenze die TCP-Zone auf ein Drittel dieses
Abstands, die erweiterte Zone auf die Hälfte.

Zitat von robotic74

Muss das Werkzeug immer zwanghaft Duch den Roboter senkrecht zum Werkstück stehen. Geht da nichts mit der Mechanik zu machen?

Da wird nicht viel zu machen sein. Senkrecht (in engen Grenzen) ist eine wesentliche Forderung.

Zitat von robotic74

Da fällt mir gerade noch etwas ein: Wenn Du eh im engeren Rahmen Deine Positionen hast kannst Du ja diese auch über ConL /OFF fahren. d.h. Die Achskonfiguration spielt für den Roboter keine rolle. Die nächstmögliche Konfiguration wird angefahren. Nun müsstet Du nur prüfen wie Achse 5 steht. Das ginge doch, oder?

ConL /OFF wird vermutlich gehen, solange man konsequent die Handgelenksingularität vermeidet. Ansonsten gibt es Ärger, weil die
Umorientierung die Bewegung stark verlangsamt. Die Bearbeitung
soll nämlich verweilzeitgesteuert ablaufen. Das würde dann einfach
zu einem 'Loch' an der Stelle führen.

Zitat von robotic74

Nun noch eine Frage: Hält der Roboter das Werkzeug oder das Werkstück?

Der Roboter hält das Werkzeug.

Ansonsten schon mal vielen Dank für die nette Diskussion.