# rein aus interesse wie werden eigentlich roboterarme programmiert?



## vollmi (6 August 2008)

Der Titel sagts eigentlich schon.

Mich näme wunder wie eigentlich so Roboterarme (Kuka z.B.) programmiert werden. Ich meine die haben ja teilweise mehrere Achsen und können sich frei im Raum drehen.

Ich kann mir das schwer vorstellen wie ich sowas auf einer S7 anfangen würde. In AWL für jede Position die angefahren werden muss eine der Koordinate entsprechende Zahl in einen Regler kopieren der dann den Motor ansteuert und natürlich ohne zu überschwingen da ranfährt? Wie verwaltet man diese Koordinaten? Ich meine da braucht es doch ein unglaubliches räumliches Vorstellungsvermögen um sich da das Programm dazu auszudenken?

mfG René


----------



## gravieren (6 August 2008)

Hi

Oft im sogenanten "Teach In" verfahren.

Hierbei also "nix" mit Achs-Koordinaten


----------



## sps-concept (6 August 2008)

*Roboter*

Hallo,

wenn sowas mit einer S7 realisiert werden soll so braucht man einen "Bahnplaner" der die Einzelachsen koordiniert. Das kann zB eine FM357 sein. Wenns mehr Achsen sind kann man auch zu einer 840 greifen. Aber dann kommst du ohne Hilfe mit normalem S7-Wissen nicht mehr weiter.

André


----------



## vollmi (6 August 2008)

sps-concept schrieb:


> Hallo,
> 
> wenn sowas mit einer S7 realisiert werden soll so braucht man einen "Bahnplaner" der die Einzelachsen koordiniert. Das kann zB eine FM357 sein. Wenns mehr Achsen sind kann man auch zu einer 840 greifen. Aber dann kommst du ohne Hilfe mit normalem S7-Wissen nicht mehr weiter.



Ahso das heisst das ist dann also eine zusätzliche Software die dann die Software für die S7 generiert?

Teach-in hat mir grad wieder ein paar interessante lektüren geliefert 

Danke sehr interessantes Thema


----------



## maweri (6 August 2008)

*Roboterprogrammierung*

Tach auch,

also einen Roboter mit S7 oder irgendeinem anderen SPS-Programm zu Bewegungen zu veranlassen, ist ungefähr als ob man einen Keller mit Klappspaten und Eimerchen ausschachten will. Es geht, aber es gibt besseres (Bagger).

Jeder Roboterhersteller (KUKA, ABB, Stäubli usw.) liefert seine eigene Software zur Programmierung der Roboter.
Man 'sagt' dem Roboter wo er hinfahren soll und die Rob-Steuerung übernimmt den Rest. Er rechnet mit Punkten im Raum, die sich auf verschiedene Koordinatensysteme beziehen können (Tool, Welt, Basis usw.)

Neben dem Teachen gibt es auch noch die offline-Progammierung. Dort werden mittles eines Programms die Bahnen vorher festgelegt.

Das ist nur eine grobe Erklärung wie es funktioniert!!!

Falls Du mehr wissen willst, muß ich mal meine Kollegen fragen. Sitze schließlich mit 3 Roboterprogrammieren in einem Büro.
Na ja einer muß ja arbeiten


----------



## geduldiger (6 August 2008)

Die KUKA Sprache nennt sich z.B. KRL (KUKA Robot Language) und ist stark an Pascal angelehnt, es gibt Schleifen, If/else Anweisungen, Variablen usw. wie bei hochsprachen, dort kann man quasi Bewegungen frei programmieren (oder mit Teachverfahren über eine bedienoberfläche einfache bewegungsabläufe eingeben) und mit angabe von Koordinaten und verschiedenen Koordinatensystemen den Roboter in diesen Koordinatensystemen bewegen (die koordinatentransformationenen und berechnung der verfahrwege übernimmt die Steuerung) und dabei noch angeben wie er die punkte anfahren soll, da gibts zum beispiel die PTP (Point to Point) bewegung durch die die schnellstmögliche achsbewegung zum punkt berechnet wird was allerdings nicht die kürzeste strecke sein muss, im gegenzug dazu gibts noch die Lin(linear) bewegung bei der der kürzeste weg berechnet wird, der dann aber nicht der schnellste sein muss. Also Roboterprogrammierung ist auf jeden Fall eine Welt für sich.

Der Roboter verfügt ebenfalls über eine Art SPS mit Ein-/und Ausgängen. Man kann auch den Roboter (die Steuerung) mit einer externen SPS verbinden und über Datenverbindungen kommunizieren.


----------



## drfunfrock (6 August 2008)

Wir haben hier einen alten Sony RSX611 stehen und der hat verschiedene Modi. Erstmal ermittelt man mittels TeachIn oder per Mathematik die Positionen und dann kann man bestimmen wie und in welcher Reihenfolge diese Angefahren werden. Dabei spielt die Interpolation die Hauptrolle.


----------



## geduldiger (6 August 2008)

Gibt halt 2 Möglichkeiten,

entweder teacht (lernt) man die einzelnen Punkte ein

oder man errechnet sich die Koordinaten der Punkte die man anfahren möchte ( genauso wie man einen punkt in einem koordinatensystem identifiziert (x,y,z und die verdrehungen im Raum)


----------



## vollmi (6 August 2008)

geduldiger schrieb:


> Gibt halt 2 Möglichkeiten,
> 
> entweder teacht (lernt) man die einzelnen Punkte ein
> 
> oder man errechnet sich die Koordinaten der Punkte die man anfahren möchte ( genauso wie man einen punkt in einem koordinatensystem identifiziert (x,y,z und die *verdrehungen im Raum*)



Das gehört ja auch noch dazu. Wenn der Roboter ein Werzeug trägt muss man dem ja noch die lage zum Werkstück mitgeben und den gewünschten vorschub. Ich nehme an Roboterarme können auch Fräser tragen und damit entsprechend genau Werkstücke bearbeiten.
Da wärs natürlich unschön wen der auf dem Weg von Punkt A nach Punkt B das Werkstück durchquert.

Ich habe eben noch nie so eine Fertigungsanlage mit Roboterarmen live gesehen, geschweigedenn in ein Projekt reinspicken können.
Robotik bestand für mich bis jetzt aus XYZ Maschinen auf Linearachsen beschränkt, die habe ich auch gut auf AWL basis beschicken können. Aber so ein Arm ist dann doch ein ganz anderes Kaliber 

mfG René


----------



## geduldiger (6 August 2008)

genau, das sind dann quasi die rotationen der einzelnen (Koordinaten-)Achsen


----------



## maweri (6 August 2008)

> Ich habe eben noch nie so eine Fertigungsanlage mit Roboterarmen live gesehen, geschweigedenn in ein Projekt reinspicken können.


 
dann schau Dir mal das Video an:
http://de.youtube.com/watch?v=Vc38lDQ8WZs&feature=related

Wenn Du nach "robot", "ABB", "KUKA" usw. bei youtube sucht, gibt's ne Menge Filmchen die Roboter bei den verschiedensten Arbeiten zeigen.


----------



## godi (6 August 2008)

Hallo!

Du kannst aber auch bei großen Firmen die Roboter haben und Führungen anbieten mal eine Führung mitmachen.

Ich war vor 2 Monaten bei BMW in München und habe bei einer Führung mitgemacht.
Da siehst du dann auch genug Roboter, die Arbeiten sogar in Teams zusammen wo bis zu 12Roboter auf einem Arbeitsplatz stehen.

godi


----------



## edi (6 August 2008)

> Jeder Roboterhersteller (seine eigene Software zur Programmierung der Roboter.Man 'sagt' dem Roboter wo er hinfahren soll und die Rob-Steuerung übernimmt den Rest. Er rechnet mit Punkten im Raum, die sich auf verschiedene Koordinatensysteme beziehen können..


 
Hallo,

und wie ist das ganze *hardwaremäßig* , gibt es da Parallelen zur SPS ?
Werden Positionen über " Endschalter" erkannt ( also Eingänge wie  bei SPS  genutzt) oder wird alles " ausgerechnet " ? ...oder wie geht das ?


----------



## Pointer (6 August 2008)

vollmi schrieb:


> Der Titel sagts eigentlich schon.
> 
> Mich näme wunder wie eigentlich so Roboterarme (Kuka z.B.) programmiert werden. Ich meine die haben ja teilweise mehrere Achsen und können sich frei im Raum drehen.
> 
> ...


 
wie schon angeschnitten es gibt eigene Robotersteuerungen mit eigenen Roboter-Programmiersprachen. 

Warum? das wesentliche dabei ist: 
1) wie geht man, statisch und dynamisch, mit der Mathematik einer "Kinematik" möglichst komfortabel um.
Dafür gibts eine eigene Systemtheorie mit echt extremen Matrixberechnungen. Solche Kernroutinen programmieren in der Regel richtige Mathematiker. Stichwort "Vorwärts- und Rückwärtstransformation einer Kinematik" dazu braucht man z.B. solche Sachen: http://de.wikipedia.org/wiki/Denavit-Hartenberg-Transformation (jetzt stell dir mal vor sowas in S7 zu programmieren hihi)

2) Wie programmiert man möglichst komfortabel die Bewegung die das "Tool" (also das Teil was am Ende des Roboters montiert ist) machen soll nur aus der abstrakten Sicht des "Tools" oder des "welt-koordinatensystems" ohne sich um die einzelnen Bewegung der beteiligten Antriebe kümmern zu müssen. 

hier gibts ein roboterforum:

http://www.roboterforum.de/roboter-forum/


Aus Anwendersicht sind die Robotersprachen gar nicht so schwer wenn man sich ein paar spezifische Grundlagen draufschaft. Das ist in den Robotersprachen alles sehr schon vorbereitet damit es einfach ist dem Roboter="Multiachssystem" zu sagen was es tun soll. 
Ein bischen Pick-and place oder Werkstückbearbeitung kann jeder gute SPS-Programmierer mit einem Kurs schnell hinkriegen.

Aber es gibt natürlich hochspezielle Roboteranwendungen die einem Anfänger nicht zu empfehlen sind wie: Kopplung mit Bildverarbeitung (der Robi greift Teile die er "sieht"), convejor-tracking (greifen der Teile vom bewegten Band), 3D-Messaufgaben (eine Autokarosserie vermessen und die Abweichungen als Korekturdaten an die Schweißstraße schicken), Bewegen mit "Freiheitsgraden" (einsetzen von Teilen in Führungen)
aber dafür gibts dann die Aplikateure der Hersteller.

mfg pointer


----------



## maweri (7 August 2008)

edi schrieb:


> Hallo,
> 
> und wie ist das ganze *hardwaremäßig* , gibt es da Parallelen zur SPS ?
> Werden Positionen über " Endschalter" erkannt ( also Eingänge wie bei SPS genutzt) oder wird alles " ausgerechnet " ? ...oder wie geht das ?


 
Endschalter im eigentlichen Sinn gibt es nicht. Der Robbi muß ja zu jeder Zeit wissen, wo welche Achse gerade steht. Das ermittelt er mit Umdrehungszählern. Die Achsen werden über Servomotoren (für jede Achse ein Motor) angetrieben. Bevor man so einen Roboter nutzen kann, muß er kalibriert werden. Dazu werden die Achsen in vorgegebene Positionen gefahren. Diese sind jeweils am den Achsen markiert. Beim ABB sind die Werte der Umdrehungszähler für die Kalibrierposition auf dem Robbi angegeben. 

Die Achsbewegungen werden dann softwaremäßig begrenzt (wenn nicht die Mechanik vorher an die Grenzen stößt). 
Wenn's um die Sicherheit geht, kann man HW-Endschalter an den Achsen anbringen, die dann die Bewegung stoppen.
Heute gibt es aber auch dafür schon Software-Lösungen. Dabei muß der Roboter nach jedem Einschalten und nach einigen Stunden Betriebszeit eine voher festgelegte Position anfahren. Dort betätigt er eine Schalter oder Ini. Wenn jetzt die gespeicherten Achspositionen mit den aktuellen übereinstimmen, kann er weitermachen. Falls nicht, muß er nachjustiert werden. In der Praxis würde der Robbi aber den Schalter gar nicht erreichen, wenn die Achsdaten nicht mehr stimmen. Das Nachjustieren ist aber auch dann fällig.


----------



## drfunfrock (7 August 2008)

Pointer schrieb:


> Aber es gibt natürlich hochspezielle Roboteranwendungen die einem Anfänger nicht zu empfehlen sind wie: Kopplung mit Bildverarbeitung (der Robi greift Teile die er "sieht"), convejor-tracking (greifen der Teile vom bewegten Band),
> mfg pointer



Wobei auch das nicht so schwer ist, wenn man richtig einkauft. Die Umrechnung der Koordinaten der Bildverarbeitung in die des Roboters, ist so schwierig nicht. Selbst das Abgreifen von bewegten Teilen, wird oft schon in der Software unterstützt.


----------



## Maxl (7 August 2008)

vollmi schrieb:


> Der Titel sagts eigentlich schon.
> 
> Mich näme wunder wie eigentlich so Roboterarme (Kuka z.B.) programmiert werden. Ich meine die haben ja teilweise mehrere Achsen und können sich frei im Raum drehen.
> 
> ...


Wie Pointer schon richtig erklärte, stecken bei Knickarmrobotern entsprechend aufwändige Transformationen dahinter. Mit dem Thema kann man übrigens ein ganzes Studium füllen.
Der Knackpunkt besteht im wesentlichen immer daraus, wie man von Kartesischen Koordinaten auf Achswinkel kommt und zurück. Dann darf man natürlich nicht außer Acht lassen, dass für lineare Bewegungen eine entsprechnde Bahnplanung erforderlich ist.
Die Interpolation erfolgt dann normalerweise in Kartesischen Koordinaten - die in jedem IPO-Zyklus (z.B. bei Kuka 12ms) neu auf Achswinkel transformiert werden müssen. Speziell wenns ums Thema Genauigkeit, Dynamik und Singularitäten (mehrdeutige Konstellationen) geht, kann es schon notwendig sein, dass die Transformation mehrmals durchlaufen werden muss.

Mit den Rechenleistungen einer S7-Steuerung hat man selbstverständlich keine Chance sowas zu relisieren. Die Transformation alleine sind schon einige 1000 Zeilen C-Code. Dass man auf S7 dann auch kaum Möglichkeiten hat, Antriebe taktsynchron anzusprechen ist ein weiteres Problem.

Von den großen Roboterherstellern kocht hier jeder sein eigenes Süppchen, wobei aber jeder als Steuerung einen Industrie-PC mit einigen 100 MHz und ein Betriebssystem mit Echtzeitkern (VXWorks o.ä) nutzt. Als Bussysteme kommen Interbus, Devicnet aber auch schon Ethernet-Varianten zum Einsatz.

Zur eigentlichen Roboterprogrammierung muss man natürlich nicht soviel Hintergrundwissen mitbringen, die Programmierung erfolgt in einer Hochsprache, welche Zeile für Zeile abgearbeitet wird. Auch hier kocht jeder sein eigenes Süppchen - mit einem gewissen Grundverständinis für Nichtzyklische Programme (wie sie z.B. NC-Programme sind) kommt man aber schon recht weit.
Was Roboter natürlich auch auszeichnet, ist die ganze Geschichte mit der Definition von Werkzeugkoordinatensystemen, Basiskorrdinatensystemen, bahnbezogene Triggerfunktionen, Positionen teachen, Handverfahren im Koordinatensystem usw. usw.
Mit der Programmierweise einer S7 hat das ganze natürlich nichts zu tun!


mfg Maxl


----------



## Deltal (8 August 2008)

Eventuell passt es nicht ganz zum Thread aber wenn es allgemein um Roboter und die "Grundfunktion" geht fand ich diesen Link sehr informativ:
http://www.reisrobotics.de/Grundlagen_der_Robotik-curwidth-1046-xscal-1280-ih-665-iw-1276.html


----------

