In diesem Artikel werden die Steuerungssystemlösungen zweier Industrieroboter, des Manipulators und des mobilen Roboters, verglichen und deren Eigenschaften vorgestellt.
Die obige Klassifizierung basiert auf dem Anwendungsobjekt. Darüber hinaus gibt es auf dem Markt allgemeinere Motion Controller, also solche, die nicht standardmäßige Geräte steuern.
1 Controller-Lösung auf unterster Ebene 1.1 Manipulatortyp Der Controller des Manipulatortyps wurde früher entwickelt und ist relativ ausgereift. Werfen wir einen Blick auf die Lösung des bestehenden Steuerungssystems auf der unteren Ebene. 1.2 Typ des mobilen Roboters Die Steuerung des mobilen Roboters gehört einer relativ neuen Richtung an. Industrielle mobile Roboter gibt es in Form von AGV, unbemannten technischen Maschinen usw. Die unterste Lösung des Steuerungssystems ist wie folgt:
1.3 Vergleich
Der Manipulator stellt hohe Anforderungen an Genauigkeit und Bewegungsstabilität, daher ist der Rechenaufwand groß und der Zyklus kurz, was im Allgemeinen 1 bis 2 Größenordnungen höher ist als bei mobilen Robotern. Mobile Roboter stellen im Allgemeinen keine hohen Anforderungen an die Synchronisationsgenauigkeit und ihre Konfiguration ist relativ gering.
Der Manipulator arbeitet im Allgemeinen in einem festen Bereich und seine Steuerung ist normalerweise im Gehäuse untergebracht, sodass die Schutzstufe nicht hoch ist, im Allgemeinen IP20. Mobile Roboter müssen wasser- und staubdicht sein, da sie sich häufig bewegen müssen, insbesondere technische Maschinen im Freien, daher müssen sie Wasser- und Staubdichtigkeit berücksichtigen. Ihr Schutzniveau ist höher, im Allgemeinen IP67.
2 Einführung in CoDeSys 2.1 Aufbau von CoDeSys
Sie werden feststellen, dass viele Robotersteuerungssoftware mithilfe von CoDeSys implementiert wird. Was ist also CoDeSys?
CoDeSys ist eine kostenpflichtige Soft-SPS-Entwicklungssoftware. Vereinfacht ausgedrückt besteht es aus zwei Teilen: dem Entwicklungssystem und dem Laufzeitsystem. Das Entwicklungssystem ist die Softwareschnittstelle, die zum Programmieren verwendet wird (genau wie Visual Studio, Eclipse und andere Software, die auch als IDE bezeichnet werden kann). Design, Debugging und Kompilierung von SPS-Programmen werden alle in der IDE ausgeführt, was der Teil ist, mit dem Benutzer häufig zu tun haben;
Nachdem das SPS-Programm geschrieben wurde, muss es zur Ausführung auf das Hardwaregerät übertragen werden. Allerdings kann das generierte SPS-Programm zu diesem Zeitpunkt nicht selbstständig laufen. Es muss in einer bestimmten Softwareumgebung funktionieren. Diese Umgebung ist das Laufzeitsystem, das für Benutzer unsichtbar ist.
Die Installationsorte der beiden sind normalerweise unterschiedlich. Die IDE wird im Allgemeinen auf dem Entwicklungscomputer installiert, und das Laufzeitsystem befindet sich auf dem Hardwaregerät, das eine Steuerungsrolle spielt. Die beiden sind im Allgemeinen über Netzwerkkabel verbunden, und das Programm wird zur Ausführung über das Netzwerkkabel in Runtime heruntergeladen.
CoDeSys ist in China nicht sehr bekannt, genießt in Europa jedoch einen langjährigen Ruf, insbesondere im Bereich der industriellen Steuerung. Viele oben erwähnte Roboterunternehmen verwenden seine Produkte, wie KEBA, Beckhoff, Googol und fast alle Hersteller mobiler Robotersteuerungen.
3S, das Unternehmen, das CoDeSys entwickelt hat, verkauft nur Software, keine Hardware. Der Hardware-Schaltkreis muss vom Benutzer entworfen werden und 3S ist für die Portierung des Laufzeitsystems auf die Hardware des Kunden verantwortlich. Das Laufzeitsystem kann nackt auf der Hardware laufen, in der Regel läuft es aber auf dem Betriebssystem und die Konfiguration des Betriebssystems ist ebenfalls Sache des Kunden.
Wenn der Kunde es wünscht, kann die IDE von CoDeSys angepasst werden, um das Logo und das Erscheinungsbild des Kunden zu ändern, weshalb Sie feststellen werden, dass die Entwicklungsplattformen verschiedener Hersteller unterschiedlich aussehen, die Stile jedoch relativ ähnlich sind.
Natürlich können Benutzer auch andere IDEs verwenden. Beckhoff verwendet beispielsweise das Visual Studio von Microsoft, während der Kernel und die Funktionsbibliothek hinter dem Compiler weiterhin die Lösung von CoDeSys verwenden.
Die Runtime von CoDeSys ist sehr anpassungsfähig und unterstützt die meisten Betriebssysteme und Hardware-Chip-Architekturen.
2.2 CoDeSys-Laufzeitprinzip
Der IDE-Teil von CoDeSys ist kostenlos und Sie können ihn von der offiziellen Website herunterladen, um ihn auszuprobieren. Die eigentliche Gebühr ist das Laufzeitsystem Runtime System.
Zu Beginn seines Entwurfs hat CoDeSys die Funktionen in mehrere Komponentenmodule unterteilt, z. B. Busprotokollstapel, visuelle Schnittstelle, Bewegungssteuerung, Sicherheitssteuerung usw. Benutzer können die erforderlichen Module auswählen, um ihr eigenes System wie Bausteine aufzubauen, und schließlich bilden eine maßgeschneiderte Steuerungssoftwareplattform.
Einige Benutzer, die mit Soft-SPS noch nicht vertraut sind, fühlen sich möglicherweise mit diesem Teil nicht vertraut, aber tatsächlich ist diese Entwurfsmethode sehr verbreitet. Auf diese Weise funktioniert beispielsweise die Echtzeit-Toolbox (Real-Time) von MATLAB Simulink. Benutzer entwerfen Steuerungsprogramme per Drag-and-Drop in der grafischen Oberfläche von Simulink und laden sie dann zur Ausführung auf die echte Hardware herunter. Hier können Sie mehr darüber erfahren.
Es gibt auch eine solche Verwendungsweise wie Beckhoff. Anwender programmieren in der TwinCAT IDE und laden sie dann auf die Steuerung von Beckhoff herunter. Tatsächlich ist eine Runtime im Controller vorinstalliert. Siemens STEP7 ist ebenfalls eine IDE, und seine SPS verfügt auch über eine passende Laufzeit.
Das vom Benutzer geschriebene SPS-Programm ist wie die Anwendung auf unserem Computer. Es läuft auf dem Laufzeitsystem und das Laufzeitsystem läuft auf dem Betriebssystem.
Das Laufzeitsystem befindet sich zwischen der Anwendung und dem Betriebssystem. Es kann also als Middleware bezeichnet werden. In der Robotersoftware befinden sich ROS, OROCOS (Real-Time Toolkit) usw. in derselben Position.
Die Robotersteuerung erfordert wie CNC-Werkzeugmaschinen Echtzeitleistung, daher ist das von uns gewählte Betriebssystem vorzugsweise ein Echtzeitbetriebssystem (RTOS). Leider sind die von uns häufig verwendeten Betriebssysteme wie Windows und Linux nicht echtzeitfähig. Aber zum Glück hat jemand sie modifiziert, also Echtzeit-Patches hinzugefügt.
Zu den häufig verwendeten Echtzeitbetriebssystemen gehören: VxWorks, QNX, Windows RTX, Xenomai, RT Linux, Linux RTAI, WinCE, μC/OS, SylixOs usw. Da es viele Benutzer von Windows- und Linux-Betriebssystemen gibt, wurde CoDeSys gestartet ein entsprechender Echtzeit-Patch (RTE), um Benutzern die Mühe der Änderung zu ersparen.
Weitere Informationen zu CoDeSys Runtime finden Sie im offiziellen Dokument [Math Processing Error] [1][2][1][2].
2.3 Nachteile von CoDeSys
CoDeSys erleichtert unsere Controller-Entwicklung und erspart uns die Mühe, bei Null anzufangen. Allerdings gibt es auch viele Nachteile bei der Entwicklung eigener Controller-Produkte auf Basis kommerzieller Software wie CoDeSys:
(1) Der zugrunde liegende Algorithmus ist nicht offen
Die von CoDeSys integrierten Motion-Control-Komponenten und Busprotokoll-Stacks sind alle gekapselt. Benutzer können ihre internen Details weder verstehen noch an ihre spezifischen Bedürfnisse anpassen und optimieren. Sie können sie nur einfach nennen. Benutzer können sich nur auf die CoDeSys-Plattform verlassen und finden es schwierig, ihre eigene Kerntechnologie zu entwickeln.
(2) Begrenzte Funktionen und schwierig zu erweitern
Neue Technologien wie maschinelles Sehen, künstliche Intelligenz und autonomes Fahren machen mittlerweile rasante Fortschritte, während viele Technologien in der industriellen Steuerung noch 20 Jahre alt sind. Am Beispiel der Navigationsszene in einem mobilen Roboter muss die auf Vision oder Laser basierende Navigationsmethode eine große Datenmenge sammeln und verarbeiten, was viele Matrixberechnungen erfordert.
Jetzt kann die SPS nur noch eindimensionale digitale Rückwärtsberechnungen durchführen, was die Implementierung komplexer Algorithmen erschwert. Im Gegensatz zum Open-Source-Stil der Community für künstliche Intelligenz ist die Community für industrielle Steuerung untereinander geschlossen. Niemand ist bereit, eigene Funktionsbibliotheken zu öffnen. Es gibt nur sehr wenige Open-Source-Funktionsbibliotheken (OSCAT). Selbst die grundlegendsten Filteralgorithmen und Matrixberechnungen müssen von Grund auf neu geschrieben werden. Darüber hinaus sind die von internationalen Standards bereitgestellten Grundfunktionen zu begrenzt und können sich überhaupt nicht an neue Szenarien anpassen. Sie bedürfen dringend einer Erweiterung.
(3) Schwierig zu aktualisieren
Aufgrund der vollständigen Abhängigkeit von CoDeSys muss die Aktualisierung der eigenen Produkthardware des Kunden angepasst und übertragen werden, was zu erhöhten Kosten führt.
3 Open-Source-Lösungen
Derzeit gibt es einige Open-Source-Steuerungssystemlösungen wie Beremiz, Orocos, OpenPLC, OpenRTM und ORCA.
Die Entwicklung von Robotersteuerungen ist eine schwere Aufgabe. Es müssen eine Reihe von Leistungsanforderungen geklärt werden, wobei die erste davon die Echtzeitleistung ist.
Für Industrieroboter ist im Allgemeinen Echtzeitleistung erforderlich, für Service- oder Unterhaltungsroboter jedoch nicht unbedingt. Für normale Menschen ist es leicht, „Echtzeitleistung“ mit schneller Verarbeitung oder Reaktionsgeschwindigkeit zu verwechseln, aber tatsächlich bedeutet „Echtzeitleistung“ „Determinismus“ in der Zeit. Beispielsweise muss die Verzögerungszeit der Interrupt-Reaktion oder des Prozesswechsels im Echtzeitbetriebssystem (RTOS) innerhalb eines Zeitbereichs liegen.
Die von uns üblicherweise verwendeten Betriebssysteme (Windows, Linux) sind keine Echtzeitbetriebssysteme, da sie auf Durchsatz ausgelegt sind und nicht garantieren können, dass jedes Ereignis innerhalb eines bestimmten Bereichs verarbeitet wird. Beispielsweise ist die Übertragungsgeschwindigkeit von Standard-Ethernet viel schneller als die von Echtzeit-Industrial-Ethernet, es handelt sich aber auch nicht um Echtzeit, da es auch nicht garantieren kann, dass die Daten innerhalb einer bestimmten Zeit übertragen werden.
Es ist nicht schwer, Echtzeit zu verstehen, aber welche Aufgaben des Roboters müssen in Echtzeit ausgeführt werden? Wie kann das Zeitintervall für die Programmausführung entsprechend den Leistungsanforderungen des Roboters bestimmt werden (1 ms oder 10 ms)? Hängt Echtzeit von Hardware oder Software ab?
Wie wählt man spezifische Hardware und Software basierend auf Echtzeit aus (ARM oder X86, Linux RTAI oder VxWorks)? Im Internet mangelt es an einer ausführlichen Diskussion zu diesem Aspekt und große Roboterhersteller geben ihre Test- und Versuchsergebnisse nicht bekannt. Es scheint, dass dieser Aspekt hauptsächlich auf Erfahrung und Versuch und Irrtum beruht.
Hier kann ich nur einige Anhaltspunkte nennen. Derzeit beträgt der Steuerzyklus von Industrieroboterarmen etwa 1 ms, und der Steuerzyklus des Positionsregelkreises eines Hochleistungsservoantriebs kann 125 [Math Processing Error] mu sμs erreichen. PLCopen definiert einige Standards für Servo- und Bewegungssteuerung, einschließlich Programmiersprache, grundlegende Bewegungssteuerungsfunktionsblöcke, Parameter von Eingabe- und Ausgabeschnittstellen usw. [Fehler bei der mathematischen Verarbeitung] ^{[3]}
[3] Die spezifischen Implementierungscodedetails werden von verschiedenen Herstellern bereitgestellt.
