Dit artikel vergelijkt de besturingssysteemoplossingen van twee industriële robots, de manipulator en de mobiele robot, en introduceert hun kenmerken.
De bovenstaande classificatie is gebaseerd op het applicatieobject. Daarnaast zijn er meer algemene bewegingscontrollers op de markt, dat wil zeggen degenen die niet-standaardapparatuur aansturen.
1 Controller op het laagste niveau 1.1 Manipulatortype De controller van het manipulatortype is eerder ontwikkeld en is relatief volwassen. Laten we eens kijken naar de bestaande oplossing op het onderste niveau van het besturingssysteem. 1.2 Type mobiele robot De besturing van de mobiele robot behoort tot een relatief nieuwe richting. Industriële mobiele robots hebben de vorm van AGV, onbemande technische machines, enz. De oplossing op het laagste niveau van het besturingssysteem is als volgt:
1.3 Vergelijking
De manipulator stelt hoge eisen aan nauwkeurigheid en bewegingsstabiliteit, waardoor het rekenbedrag groot is en de cyclus kort is, wat doorgaans 1 tot 2 ordes van grootte hoger ligt dan die van mobiele robots. Mobiele robots stellen over het algemeen geen hoge eisen aan de synchronisatienauwkeurigheid en hun configuratie is relatief laag.
De manipulator werkt over het algemeen in een vaste ruimte en de controller wordt meestal in het chassis geplaatst, dus het beschermingsniveau is niet hoog, doorgaans IP20. Mobiele robots moeten water- en stofdicht zijn omdat ze vaak moeten bewegen, vooral buitenmachines, en daarom moeten ze rekening houden met water- en stofdichtheid. Hun beschermingsniveau is hoger, doorgaans IP67.
2 Inleiding tot CoDeSys 2.1 Samenstelling van CoDeSys
U zult merken dat veel robotbesturingssoftware wordt geïmplementeerd met behulp van CoDeSys, dus wat is CoDeSys?
CoDeSys is een betaalde software voor zachte PLC-ontwikkeling. Simpel gezegd bestaat het uit twee delen: Development System en Runtime System. Ontwikkelsysteem is de software-interface die wordt gebruikt voor het programmeren (net als Visual Studio, Eclipse en andere software, die ook IDE kan worden genoemd). Het ontwerpen, debuggen en compileren van PLC-programma's worden allemaal uitgevoerd in IDE, het onderdeel waar gebruikers vaak mee te maken hebben;
Nadat het PLC-programma is geschreven, moet het voor gebruik naar het hardwareapparaat worden overgebracht. Het gegenereerde PLC-programma kan op dit moment echter niet zelfstandig draaien. Het moet in een bepaalde softwareomgeving werken. Deze omgeving is het Runtime Systeem, dat onzichtbaar is voor gebruikers.
De installatielocaties van de twee zijn meestal verschillend. IDE wordt doorgaans op de ontwikkelingscomputer geïnstalleerd en Runtime System bevindt zich op het hardwareapparaat dat een controlerol speelt. De twee zijn doorgaans met elkaar verbonden via netwerkkabels en het programma wordt via de netwerkkabel naar Runtime gedownload voor gebruik.
CoDeSys is niet zo bekend in China, maar heeft in Europa al lang een reputatie, vooral op het gebied van industriële besturing. Veel robotbedrijven die we hierboven noemden, gebruiken zijn producten, zoals KEBA, Beckhoff, Googol en bijna alle fabrikanten van mobiele robotcontrollers.
3S, het bedrijf dat CoDeSys heeft ontworpen, verkoopt alleen software, geen hardware. Het hardwarecircuit moet door de gebruiker worden ontworpen en 3S is verantwoordelijk voor het overbrengen van het Runtime-systeem naar de hardware van de klant. Het Runtime-systeem kan naakt op de hardware draaien, maar meestal draait het op het besturingssysteem, en het configureren van het besturingssysteem is ook de taak van de klant.
Als de klant dit wenst, kan de IDE van CoDeSys worden aangepast om het logo en het uiterlijk van de klant te veranderen. Daarom zult u merken dat de ontwikkelingsplatforms van verschillende fabrikanten er verschillend uitzien, maar dat de stijlen relatief vergelijkbaar zijn.
Uiteraard kunnen gebruikers ook andere IDE's gebruiken. Beckhoff gebruikt bijvoorbeeld Visual Studio van Microsoft, terwijl de kernel- en functiebibliotheek achter de compiler nog steeds de oplossing van CoDeSys gebruiken.
De Runtime van CoDeSys heeft een sterk aanpassingsvermogen en ondersteunt de meeste besturingssystemen en hardwarechiparchitecturen.
2.2 CoDeSys Runtime-principe
Het IDE-gedeelte van CoDeSys is gratis en je kunt het downloaden van de officiële website om het te ervaren. De echte lading is het runtime-systeem Runtime System.
Aan het begin van het ontwerp verdeelde CoDeSys de functies in verschillende componentmodules, zoals busprotocolstack, visuele interface, bewegingsbesturing, veiligheidsbesturing, enz. Gebruikers kunnen de benodigde modules kiezen om hun eigen systeem als bouwstenen te bouwen, en ten slotte vormen een op maat gemaakt besturingssoftwareplatform.
Sommige gebruikers die nieuw zijn met zachte PLC zijn misschien niet vertrouwd met dit onderdeel, maar in feite is deze ontwerpmethode heel gebruikelijk. Zo werkt bijvoorbeeld de real-time toolbox (Real-Time) van MATLAB Simulink. Gebruikers ontwerpen besturingsprogramma's door ze in de grafische interface van Simulink te slepen en neer te zetten en ze vervolgens naar de echte hardware te downloaden om ze uit te voeren. Je kunt er hier meer over leren.
Er is ook zo'n manier van gebruik zoals Beckhoff. Gebruikers programmeren in TwinCAT IDE en downloaden deze vervolgens naar de controller van Beckhoff. In feite is er vooraf een runtime in de controller geïnstalleerd. Siemens STEP7 is ook een IDE en de PLC heeft ook een bijpassende runtime.
Het door de gebruiker geschreven PLC-programma lijkt op de applicatie op onze computer. Het draait op het runtime-systeem en het runtime-systeem draait op het besturingssysteem.
Het runtimesysteem bevindt zich tussen de applicatie en het besturingssysteem. Het kan dus middleware worden genoemd. In robotsoftware bevinden ROS, OROCOS (Real-Time Toolkit), enz. zich in dezelfde positie.
Robotbesturing vereist, net als CNC-bewerkingsmachines, realtime prestaties, dus het besturingssysteem dat we kiezen is bij voorkeur een realtime besturingssysteem (RTOS). Helaas zijn de besturingssystemen die wij vaak gebruiken niet real-time, zoals Windows en Linux. Maar gelukkig heeft iemand ze aangepast, dat wil zeggen realtime patches toegevoegd.
Veelgebruikte real-time besturingssystemen zijn onder meer: VxWorks, QNX, Windows RTX, Xenomai, RT Linux, Linux RTAI, WinCE, μC/OS, SylixOs, enz. Gezien het feit dat er veel gebruikers zijn van Windows- en Linux-besturingssystemen, heeft CoDeSys gelanceerd een overeenkomstige real-time patch (RTE) om gebruikers de moeite van wijzigingen te besparen.
Voor meer informatie over CoDeSys Runtime kunt u het officiële document [Math Processing Error] [1][2][1][2] lezen.
2.3 Nadelen van CoDeSys
CoDeSys zorgt voor gemak bij de ontwikkeling van onze controllers en bespaart ons de moeite om helemaal opnieuw te beginnen. Er kleven echter ook veel nadelen aan het ontwikkelen van eigen controllerproducten op basis van commerciële software zoals CoDeSys:
(1) Het onderliggende algoritme is niet open
De motion control-componenten en busprotocolstacks die door CoDeSys zijn geïntegreerd, zijn allemaal ingekapseld. Gebruikers kunnen hun interne gegevens niet begrijpen en kunnen deze ook niet aanpassen en optimaliseren volgens hun specifieke behoeften. Ze kunnen ze alleen maar eenvoudig bellen. Gebruikers kunnen alleen vertrouwen op het CoDeSys-platform en vinden het moeilijk om hun eigen kerntechnologie te vormen.
(2) Beperkte functies en moeilijk uit te breiden
Nieuwe technologieën, vertegenwoordigd door machine vision, kunstmatige intelligentie en autonoom rijden, gaan nu met grote sprongen vooruit, terwijl veel technologieën op het gebied van industriële controle nog steeds twintig jaar oud zijn. Als we de navigatiescène in een mobiele robot als voorbeeld nemen, moet de navigatiemethode op basis van vision of laser een grote hoeveelheid gegevens verzamelen en verwerken, wat veel matrixberekeningen met zich meebrengt.
Nu kan PLC alleen achterwaartse eendimensionale digitale berekeningen uitvoeren, waardoor het moeilijk wordt om complexe algoritmen te implementeren. In tegenstelling tot de open source-stijl van de kunstmatige-intelligentiegemeenschap, is de industriële controlegemeenschap gesloten voor elkaar. Niemand is bereid zijn eigen functiebibliotheken te openen. Er zijn zeer weinig open source functiebibliotheken (OSCAT). Zelfs de meest elementaire filteralgoritmen en matrixberekeningen moeten helemaal opnieuw worden geschreven. Bovendien zijn de basisfuncties die door internationale standaarden worden geboden te beperkt en kunnen ze zich helemaal niet aanpassen aan nieuwe scenario's. Ze hebben dringend behoefte aan uitbreiding.
(3) Moeilijk te updaten
Vanwege de volledige afhankelijkheid van CoDeSys moet de upgrade van de eigen producthardware van de klant worden aangepast en getransplanteerd, wat resulteert in hogere kosten.
3 Open source-oplossingen
Momenteel zijn er enkele open source besturingssysteemoplossingen, zoals Beremiz, Orocos, OpenPLC, OpenRTM en ORCA.
Het ontwikkelen van robotcontrollers is een zware opgave. Een reeks prestatie-eisen moet worden verduidelijkt, waarvan de eerste de real-time prestatie is.
Realtime prestaties zijn over het algemeen noodzakelijk voor industriële robots, maar niet noodzakelijkerwijs voor service- of entertainmentrobots. Het is voor gewone mensen gemakkelijk om ‘real-time prestaties’ te verwarren met snelle verwerkings- of reactiesnelheid, maar in feite betekent ‘real-time prestaties’ ‘determinisme’ in de tijd. De vertragingstijd van de interruptrespons of processchakeling in het realtime besturingssysteem (RTOS) moet bijvoorbeeld binnen een tijdsbereik liggen.
De besturingssystemen die we vaak gebruiken (Windows, Linux) zijn geen realtime besturingssystemen, omdat ze zijn ontworpen voor doorvoer en niet kunnen garanderen dat elke gebeurtenis binnen een bepaald bereik wordt verwerkt. De transmissiesnelheid van standaard Ethernet is bijvoorbeeld veel sneller dan die van real-time industrieel Ethernet, maar het is ook niet realtime, omdat het ook niet kan garanderen dat gegevens binnen een bepaalde tijd worden verzonden.
Het is niet moeilijk om realtime te begrijpen, maar welke taken van de robot moeten in realtime worden uitgevoerd? Hoe bepaal ik het tijdsinterval voor het uitvoeren van een programma volgens de prestatie-eisen van de robot (1 ms of 10 ms)? Is real-time afhankelijk van hardware of software?
Hoe kies je specifieke hardware en software op basis van realtime (ARM of X86, Linux RTAI of VxWorks)? Er is een gebrek aan diepgaande discussies over dit aspect op internet, en grote robotfabrikanten willen hun test- en experimentele resultaten niet openbaar maken. Het lijkt erop dat dit aspect vooral afhankelijk is van ervaring en vallen en opstaan.
Hier kan ik slechts enkele indicatoren geven. Momenteel bedraagt de besturingscyclus van industriële robotarmen ongeveer 1 ms, en de besturingscyclus van de positielus van een krachtige servoaandrijving kan 125 [Math Processing Error] mu sμs bereiken. PLCopen definieert enkele standaarden voor servo- en bewegingsbesturing, waaronder programmeertaal, basisfunctieblokken voor bewegingsbesturing, parameters van invoer- en uitvoerinterfaces, enz. [Math Processing Error] ^{[3]}
[3] De specifieke details van de implementatiecode worden door verschillende fabrikanten verstrekt.
