Robotikautomatisierung mit ROS 2 und KI für Ihren Betrieb

Bei welchen Aufgaben können KI und Robotik gemeinsam betrachtet werden?

In einer Anwendung kann eine Kamera Klasse oder Position eines Teils bestimmen; Teileidentität und Entscheidungsergebnis können über ROS 2 an die Aufgabenverwaltung übertragen werden. Robotersteuerung oder SPS prüfen die Gültigkeit dieser Information und führen den definierten Ablauf aus. Im physischen Pilotversuch wird neben dem Nachrichtenempfang auch verifiziert, dass das Teil an den richtigen Ort gelangt. Für unklare Bild- oder Sensorergebnisse werden Bedienerprüfung und Verhalten der lokalen Steuerung gesondert definiert.

Nicht jede Aufgabe erfordert ein lernendes Modell. Erfüllen feste Regeln oder das vorhandene Messverfahren den Bedarf, bewerten wir dies als Ausgangslösung. Wird KI eingesetzt, werden die Produktvarianten und Betriebsbedingungen angegeben, für die sie abgenommen werden soll. Falsche Annahmen, falsche Ablehnungen und Fälle ohne Ergebnis werden getrennt verfolgt; ein einzelner Erfolgsprozentsatz ersetzt nicht sämtliche betrieblichen Erwartungen.

• Interpretation von Sensordaten in Fertigungs- und Roboterzellen
• Zuordnung der Modellentscheidung zu Auftrag und Teileidentität
• Prüfablauf durch Bediener bei unklarem Ergebnis

Daten- und Aufgabenfluss in Roboterautomatisierungssystemen mit ROS 2

ROS 2 ist eine Entwicklungsinfrastruktur, die Softwarekomponenten in der Robotik beim Austausch von Daten und Aufgaben unterstützt. Sensorerfassung, Modellausführung und Aufgabenverwaltung können als getrennte Knoten organisiert werden. Kontinuierliche Daten werden über Topics veröffentlicht; kurze Anfragen können über Services und Aufgaben mit Fortschritts- und Ergebnisverfolgung über Actions abgewickelt werden. Zeitstempel, Gerätekennung und Fehlerstatus in den Schnittstellen definieren, für welchen Vorgang die Daten gültig sind.

Je nach Bedarf können Linux-basierte Industriecomputer, Einplatinencomputer und unterstützte Mikrocontroller gemeinsam eingesetzt werden. micro-ROS bietet die Möglichkeit, geeignete Embedded-Plattformen über eine Client-Agent-Architektur an ein ROS-2-System anzubinden. Die Aufgabenverteilung zwischen Zentralrechner und verteilten Geräten wird unter Berücksichtigung von Verbindungsverlust, Neustart und Wartungserwartungen ausgelegt. ROS 2 bedeutet nicht, dass jede Platine oder jeder Roboter direkt kompatibel ist; Treiber und Herstellerschnittstellen werden geprüft.

• ROS-2-Knoten und definierte Datenschnittstellen
• Zentrale oder verteilte Softwareanordnung
• Anbindungen individueller Sensorplatinen, Embedded-Geräte und Server

Leitfaden zur ROS-2- und industriellen KI-Architektur →

Wie wird entschieden, ob CPU oder GPU eingesetzt wird?

Modelltraining und die Erzeugung von Ergebnissen aus einem trainierten Modell, also Inferenz, sind unterschiedliche Rechenaufgaben. Ein auf einem Server trainiertes Modell kann im Feld auf einer CPU laufen. Bei rechenintensiveren Modellen kann eine GPU erwogen werden; für kleine Modelle, niedrige Datenraten oder ein begrenztes Energiebudget kann dagegen eine CPU geeignet sein. Wir entscheiden nicht nach Modellnamen oder Werbewert der Hardware.

Modellkandidaten werden mit realen Daten auf dem Zielgerät verglichen. Gesamtzeit vom Sensor bis zum Ergebnis, Schwankungen der Latenz, Speicherbedarf, Temperatur nach längerem Betrieb und Leistungsaufnahme werden gemeinsam untersucht. Bei GPU-Nutzung können Datenübertragung und auf der CPU verbleibende nicht unterstützte Operationen den Vorteil verringern. Werden Modelle verkleinert oder numerische Genauigkeiten geändert, wird die Ergebnisqualität erneut verifiziert. Geeignete Hardware erfüllt sowohl die akzeptierte Genauigkeit als auch die Betriebsbedingungen.

• Trainings- und Inferenzumgebungen im Feld getrennt planen
• Vergleichsmessung mit realen Daten und Zielgerät
• Leistung, thermisches Verhalten und Wartungskosten gemeinsam bewerten

Wie wird das Lernen in einem geschlossenen Modellentwicklungszyklus gesteuert?

Neue oder fehlerhafte Beispiele aus dem Betrieb können kontrollierte Rückmeldungen für die Modellentwicklung liefern. Datenerfassung, Prüfung durch befugte Personen, Korrektur von Kennzeichnungen, erneutes Training und unabhängige Verifizierung werden definiert. Datensatz, Modell, Vorverarbeitung und Entscheidungsschwellen werden versioniert. Anhand früherer Abnahmebeispiele wird auch geprüft, ob eine neue Version zwar alte Fehler behebt, aber bei anderen Produkten Rückschritte verursacht.

Dieser Zyklus bedeutet nicht, dass das Modell im Feld seine eigenen Entscheidungen für richtig hält und sich unkontrolliert verändert. Ein neues Modell wird nach befugter Freigabe in einem begrenzten Pilotversuch erprobt und bei erfolgreicher Abnahme in Betrieb genommen. Der Rückweg zur vorherigen Version bleibt erhalten. Änderungen der Datenverteilung, unklare Ergebnisse und zur menschlichen Prüfung weitergeleitete Beispiele können verfolgt werden. Soll ohne Ausleitung betrieblicher Daten gearbeitet werden, wird die Infrastruktur für Erfassung, Training und Verteilung entsprechend festgelegt.

• Betriebsinterne Daten und geprüfte Kennzeichnungen
• Nachvollziehbare Versionen von Daten, Modell und Einstellungen
• Menschlich freigegebenes Update und Rückkehr zur vorherigen Version

Wie werden Grenzen zu vorhandener SPS und Maschinensteuerung festgelegt?

Bestehende Aufgaben der SPS oder Robotersteuerung, verfügbare Kommunikationsschnittstellen und Herstellervorgaben werden geprüft. Es wird festgelegt, unter welchen Bedingungen Vorschläge oder Aufgabenanfragen aus ROS 2 angenommen werden. Das Verhalten bei veralteten Ergebnissen, wiederholten Befehlen, Verbindungsabbruch und Zeitüberschreitung wird ausdrücklich beschrieben. Kritische Maschinenzyklen und Sicherheitsfunktionen verbleiben in der dafür erforderlichen Steuerungs- und Sicherheitsarchitektur.

Bei DDS-basierter Kommunikation werden QoS-Einstellungen nach Datenfluss gewählt; nicht alle Nachrichten erhalten dieselbe Einstellung. ROS_DOMAIN_ID dient der Trennung logischer Kommunikationsgruppen und ersetzt keine Zugriffssicherheit. Netzwerksegmentierung, Berechtigungen, geeignete ROS-2-Sicherheitskonfiguration und Fernzugriffsrichtlinien werden gesondert geplant. Das Hinzufügen von KI oder ROS 2 verleiht einem System nicht automatisch eine Sicherheitszertifizierung.

• Aufgabentrennung zwischen SPS, Robotersteuerung und KI-Ebene
• Befehlsgültigkeit, Zeitüberschreitungen und Fehlerszenarien
• Sicherheitskonfiguration für Netzwerkzugriff und Datenkommunikation

Integration individueller Elektronik und Software in das vorhandene Steuerungssystem →

Wie wird der Übergang in den laufenden Betrieb gestaffelt?

Zunächst werden vorhandene Geräte, Datenquellen und Produktionsabläufe erfasst. Mit Ausgangsdaten erfolgen Offlineversuche; in geeigneten Projekten unterstützen Simulation oder digitaler Zwilling die Untersuchung definierter Szenarien. Diese Modelle werden nicht als vollständige Abbildung realer Feldbedingungen betrachtet. In der ersten Livephase können Systemergebnisse ohne Befehlsausgabe mit dem bestehenden Prozess verglichen werden. Dieser sogenannte Schattenbetrieb ermöglicht eine Bewertung, bevor falsche Vorschläge Auswirkungen verursachen.

Der Umfang der Pilotstation wird gemeinsam mit dem Produktionsplan festgelegt. Neben dem Normalbetrieb werden Situationen wie Sensorausfall, Softwareneustart, Netzwerkunterbrechung und falsche Modellversion erprobt. Welche Messungen und Beispiele für die Abnahme vor Ort verwendet werden, wird vorab dokumentiert. Sind Berechtigungen, Überwachung und Rückkehrschritte geklärt, erfolgt die kontrollierte Inbetriebnahme; die Ausweitungsentscheidung basiert auf Pilotprotokollen.

• Bestandsaufnahme und Offlinebewertung der Daten
• Schattenbetrieb, begrenzter Pilot und Abnahme vor Ort
• Plan für Inbetriebnahme, Überwachung und Rückkehr

Welche technischen Ergebnisse werden zum Entwicklungsabschluss übergeben?

Projektspezifische Anwendungsquellcodes, ROS-2-Pakete, Schnittstellendefinitionen, Konfigurationen und technische Dokumente gehören zum Übergabeumfang. Wurde ein Modell entwickelt, werden Modelldateien, Versionsinformationen, Trainings- und Ausführungsschritte sowie Verifizierungsprotokolle aufbereitet. Bedingungen für Speicherung und Übertragung von Kundendaten werden angegeben; Lizenzen quelloffener oder kommerzieller Komponenten Dritter werden gesondert erläutert.

Bei Projekten mit individueller Elektronik- und Mechanikentwicklung werden zum Abschluss auch projektspezifische PCB-Designquellen, CAD-Dateien und zugehörige Fertigungsdokumente übergeben. Informationen für erneute Installation, Gerätetausch und Updates werden vorbereitet. PCB-Schnellfertigung und Bestückungsunterstützung bieten wir im Rahmen der von uns entwickelten Kundenprojekte an. Für ein Angebot können Sie vorhandene Geräte, die zu lösende Aufgabe, die Datenlage und das erwartete Projektergebnis mitteilen.

• Quellcode, Modellversionen und Konfigurationen
• PCB-/CAD-Quellen und technische Dokumente im vereinbarten Umfang
• Übergabeunterlagen für Installation, Verifizierung und Wartung