Industrie Roboter / 3D-Kameras Funktionsweise

[KarlMeier]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,
die Frage mag vielleicht ein wenig unverständlich erscheinen, aber ich hatte bisher nur "Sichtkontakt" mit Industrierobotern und finde das ziemlich interessant. Mir würden auch einige Anwendungen dafür einfallen. Leider konnte ich noch nicht so wirklich herausfinden wie die ganze Programmierung eigentlich abläuft. Vielleicht kann mir das jemand einfach mal kurz und bündig, aber trotzdem ausführlich genug, um es zu verstehen, erklären.

Wie läuft die Programmierung der Fahrwege und der Bewegungsabläufe ab? Programmiere ich das direkt in der Automatisierungs-Software, also TiaPortal, AS, TwinCAT etc.? Für TiaPortal scheint es ja extra eine Erweiterung namens "Simatic Robot Integrator" zu geben. Laut Beschreibung kann man damit mit vielen verschiedenen Industrierobotern kommunizieren. Leider finde ich dann keine weiteren Details wie das Ganze funktioniert.
Programmiere ich die ganzen Bewegungen dann mit verschiedenen Funktionsbausteinen oder rufe ich über die Schnittstelle nur Bewegungsabläufe ab, welche ich mit einer externen Software (wahrscheinlich eine Software des Roboterherstellers) programmiere?

Selbiges gilt für die Kameratechnik. Soweit ich es bisher verstanden hab ist so eine 3D-Kamera an einem PC angeschlossen. Auf diesem PC läuft eine spezielle Software. Die Kamerabilder werden eingelesen, analysiert und je nach Vorgaben, programmierten Merkmalen und Details kommt am Ende ein Ergebnis, um welches Teil es sich handelt. Ich hab zB. 10 verschieden Kisten. Alle sind von den Maßen etwas anders. Die Kamera kann die Unterschiede erkennen, wenn ich es vorab entsprechend eingelernt hab. Die Ausgabe sagt also um welches Teil es sich handelt. Wie kommt diese Information dann in mein SPS-Programm?
Spezieller wird es dann in Verbindung mit einem Roboterarm, wenn ich ihm anhand der Kameradaten sagen will wo genau an welcher Position der Arm zugreifen muss. Dann müsste ich ja im Kameraprogramm erkennen wo genau die gesuchte Position ist und muss dies dann dem SPS-Programm mitteilen und dieses würde wiederum dem Roboter sagen wo genau an welche Position sich dieser hinbewegen und zugreifen muss.

Ich hoffe dass dies halbwegs verständlich und überschaubar beantwortet werden kann, ohne den Rahmen komplett zu sprengen. Mir geht es da auch gar nicht um Detailfragen und dass alles 100%ig (technisch) richtig beschrieben wird. Mir geht es um das grundsätzliche Verständnis.

 

[KarlMeier]

Vielleicht ist es auch leichter zu beantworten, wenn ich zusammenfasse was ich schon weiß, bzw. was ich denken zu wissen.

Die Roboter bestehen aus einem Roboterarm und einem Steuerungsteil. Auf diesem Steuerungsteil sind verschiedene Abläufe in Form von verschiedenen Programmen gespeichert, welche vorher entsprechend programmiert wurden. Dieser Steuerungsteil verfügt über verschiedene Schnittstellen. Digitale und/oder analoge Eingänge. Im besten Fall kann man den Steuerungsteil direkt via Profinet, Ethercat, Profilink oder Profibus in eine SPS einbinden. Mit der SPS rufe ich dann die verschiedenen Programme in der Roboter-Steuerung auf und der Roboter führt die Bewegung aus. So könnte ich es mir anhand von dem was ich bisher weiß vorstellen.

Aber wie funktioniert es, wenn ich wie oben erwähnt immer andere Positionen anfahren muss? Angenommen ich habe eine Kiste voll mit verschiedenfarbigen Bällen und möchte diese aus der Kiste heraus nach Farben trennen. Dann brauch ich eine Kamera welche die unterschiedlichen Farben erkennt und der Steuerung sagt wo der Arm hinfahren muss.
Und wenn ich das alles in meinen Prozess einbinden muss, dann muss es auch von der SPS irgendwelche Befehle geben. Wie läuft sowas ab? Welche Rolle spielt in solchen Szenarien die SPS? Ist die weitestgehend „Zuschauer“ und kümmert sich nur um Zuführung, Sicherheit usw. oder hat die in dem ganzen auch einen aktiven Auftrag?

 

[roboticBeet]

Zuviel Werbung?
-> Hier kostenlos registrieren

Klassischer Weise werden Industrieroboter direkt auf der Robotersteuerung mit einem Teach-Panel programmiert. Um es auf das Wesentliche zu reduzieren, besteht dann eine Programmzeile aus folgenden Elementen:

• Bewegungsart (PTP (J), LIN (L), CIRC (C), SPLINE, ...),
• der Zielpose,
• der zu verwendenden Geschwindigkeit sowie
• ggf. Zusatzinformationen für die kinematische Berechnung (Überschleifen etc.)

Praktisch alle Roboterhersteller haben auch eine entsprechende Software für eine vorherige Offline-Programmierung, mit welcher man die Roboterprogramme am PC erstellen kann. Diese sind jedoch häufig teuer und erfordern, um sinnvoll genutzt werden zu können, ein 3D Modell der Anlage. In der Praxis sieht man stattdessen durchaus eine Programmvorbereitung in einem einfachen Text-/Programmiereditor (bspw. VS Code). Die relevanten Positionen des Roboters werden dann später erst an der realen Maschine eingeteacht.
Die entsprechenden Roboterprogramme werden über eine Schnittstelle des Roboters, in der Regel Feldbus / IE (Profinet, EtherCAT, ...), von der Steuerung angewählt und von der Robotersteuerung ausgeführt. Wie gesagt, das Programm liegt auf der Robotersteuerung.

Die Steuerung von Robotern über die SPS mittels der SRCI Schnittstelle ist noch recht neu. Mittlerweile haben da aber alle großen Steuerungshersteller was in Vorbereitung. Am Ende funktioniert dies ähnlich wie mit den PLCopen Motion Control Bausteinen. Man hat eine herstellerabstrahierte Form der Programmierung und die entsprechenden Bewegungsbefehle werden so direkt an die Robotersteuerung geschickt.
In der Praxis, abgesehen von Messedemonstratoren, habe ich das noch nicht gesehen.

Die Kommunikation zwischen Bildverarbeitungssystem und SPS erfolgt auch mittels Feldbus / IE Schnittstelle. Die Hersteller von Bildverarbeitungssystemen haben hier bereits Profinet, EtherCAT Schnittstellen mit an Bord. Wenn nichts vorhanden ist, kann man zur Not in der Regel per TCP/IP oder UDP kommunizieren. Für eine Positionskorrektur des Roboters durch ein Kamerasystem kommuniziert das Kamerasystem jedoch häufig auch direkt mit dem Roboter. Einer der "üblichen Verdächtigen" Hersteller von Bildverarbeitungssystemen hat da ein ziemlich komfortables Feature im Portfolio. Aber auch ohne dieses Feature muss für eine Positionskorrektur des Roboters, das Bildkoordinatensystem der Kamera mit dem Koordinatensystem des Roboters zusammengeführt werden. Dafür muss bspw. der Roboter wissen, an welcher Stelle im Raum exakt die Kamera sitzt und welchen Raumbereich die Kamera abbildet. Zusätzlich müssen die Pixel-Bildkoordinaten des Kamerasystems in physikalische Einheiten überführt werden. Dafür muss das Kamerabild entsprechend kalibriert werden. Dies macht man häufig in der Form, dass man ein Schachbrettmuster mit definierten Kantenlängen im Bild abbildet. Dadurch kann die Kamera dann zwischen Pixel und der tatsächlichen Längeneinheit umrechnen.

 

[KarlMeier]

Vielen Dank für die ausführliche Antwort!
Das hat einige Verständnislücken geschlossen und anderes bestätigt. Mit diesen Informationen kann ich jetzt weiter planen bzw. mich weiter und präziser informieren. Bei der SPS 2024 wird es diesbezüglich sicherlich auch sehr vieles zu sehen geben.

 

[roboticBeet]

Für Robotik (und auch der damit zusammenhängenden Bildverarbeitung) ist insbesondere die Automatica empfehlenswert, nächstes Jahr im Sommer in München. Dort stellen alle relevanten Roboterhersteller aus und die großen Bildverarbeiter sind auch da. Auf anderen Messen SPS, Hannover Messe, ... sind Roboterhersteller imho nicht mehr / kaum vertreten.

 

[KarlMeier]

Zuviel Werbung?
-> Hier kostenlos registrieren

Für Robotik (und auch der damit zusammenhängenden Bildverarbeitung) ist insbesondere die Automatica empfehlenswert, nächstes Jahr im Sommer in München. Dort stellen alle relevanten Roboterhersteller aus und die großen Bildverarbeiter sind auch da. Auf anderen Messen SPS, Hannover Messe, ... sind Roboterhersteller imho nicht mehr / kaum vertreten.

Danke für den Tipp!
Hab mir den Termin gleich mal eingetragen.

 

[itsdarkdownhere]

Zur Offline Programmierung gibt es verschiedene Software in unterschiedlichsten Preisklassen. Beispiele sind hier RoboDK oder VisualComponents (vorher Delfoi). Mit dem richtigen Postprozessor lässt sich nahezu herstellerunabhängig programmieren.

Im Grunde ist die Roboterprogrammierung aus Grundbewegeungen (PTP, LIN, CIRC...) aufgebaut. Beim TeachIn mit dem Panel fügst du zeilenweise deine Zielpunkte hinzu, gibst Geschwindigkeiten etc. an. Die genauen Bahnbewegungen zu deinem Zielpunkt werden automatisch berechnet, weshalb man meistens noch Bahnoptimierungen vornehmen muss, bspw. um Singularitäten zu vermeiden.

Der Roboter arbeitet zudem mit verschiedenen Koordinatensystemen, wie Basis-, Werkstück-, Werkzeug oder Flanschkoordinatensystem. Diese verschiedenen Systeme sind nötig, um die genauen Zielpunkte in den gewünschten Positionen/Orientierungen zu realisieren.

Die Offline Programmierung macht das ganze deutlich komfortabler, da hier auch mit dem 3D-Modell direkt Kollisionserkennungen getestet werden.

 

[DCDCDC]

Wir verwenden auch visual components zur Darstellung/digitaler Zwilling/-Schatten und auch zur Machbarkeitsanalyse für Aufgaben von Robotern. Ansonsten gibts dafür auch noch ein Tool von Artiminds, damit lassen sich zB auch Abläufe erstellen und direkt an die Steuerung des Roboters übertragen und starten.. ist aber mehr was fürs Labor.. könntest du dir aber auch mal vorführen lassen.