Denne artikkelen sammenligner kontrollsystemløsningene til to industriroboter, manipulatoren og den mobile roboten, og introduserer deres egenskaper.
Ovennevnte klassifisering er basert på applikasjonsobjektet. I tillegg finnes det mer generelle bevegelseskontrollere på markedet, det vil si de som styrer ikke-standardutstyr.
1 Regulator på bunnnivå 1.1 Manipulatortype Regulatoren av manipulatortypen utviklet tidligere og er relativt moden. La oss ta en titt på den eksisterende løsningen på bunnnivået for kontrollsystemet. 1.2 Mobil robottype Kontrolleren til den mobile roboten tilhører en relativt ny retning. Industrielle mobile roboter er i form av AGV, ubemannet ingeniørmaskineri osv. Bunnnivåløsningen til kontrollsystemet er som følger:
1.3 Sammenligning
Manipulatoren har høye krav til nøyaktighet og bevegelsesstabilitet, så beregningsmengden er stor og syklusen er kort, som vanligvis er 1 til 2 størrelsesordener høyere enn for mobile roboter. Mobile roboter har generelt ikke høye krav til synkroniseringsnøyaktighet, og deres konfigurasjon er relativt lav.
Manipulatoren fungerer vanligvis i et fast område, og kontrolleren er vanligvis plassert i chassiset, så beskyttelsesnivået er ikke høyt, vanligvis IP20. Mobile roboter må være vanntette og støvtette fordi de må bevege seg ofte, spesielt utendørs ingeniørmaskiner, så de må vurdere vanntetting og støvtetting. Beskyttelsesnivået deres er høyere, vanligvis IP67.
2 Introduksjon til CoDeSys 2.1 Sammensetning av CoDeSys
Du vil finne at mange robotkontrollprogramvare er implementert ved hjelp av CoDeSys, så hva er CoDeSys?
CoDeSys er en betalt myk PLS-utviklingsprogramvare. Enkelt sagt består den av to deler: Utviklingssystem og Runtime System. Development System er programvaregrensesnittet som brukes til programmering (akkurat som Visual Studio, Eclipse og annen programvare, som også kan kalles IDE). Design, feilsøking og kompilering av PLS-programmer utføres i IDE, som er den delen brukere ofte arbeider med;
Etter at PLS-programmet er skrevet, må det overføres til maskinvareenheten for drift. Det genererte PLS-programmet kan imidlertid ikke kjøre av seg selv på dette tidspunktet. Det må fungere i et bestemt programvaremiljø. Dette miljøet er Runtime System, som er usynlig for brukere.
Installasjonsstedene til de to er vanligvis forskjellige. IDE er vanligvis installert på utviklingsdatamaskinen, og Runtime System er plassert på maskinvareenheten som spiller en kontrollrolle. De to er vanligvis koblet sammen med nettverkskabler, og programmet lastes ned til Runtime gjennom nettverkskabelen for drift.
CoDeSys er ikke kjent i Kina, men har et langvarig rykte i Europa, spesielt innen industriell kontroll. Mange robotbedrifter vi nevnte ovenfor bruker produktene deres, som KEBA, Beckhoff, Googol og nesten alle produsenter av mobile robotkontroller.
3S, selskapet som designet CoDeSys, selger kun programvare, ikke maskinvare. Maskinvarekretsen må designes av brukeren, og 3S er ansvarlig for å portere Runtime System til kundens maskinvare. Runtime System kan kjøres nakent på maskinvaren, men det kjører vanligvis på operativsystemet, og konfigurering av operativsystemet er også kundens jobb.
Hvis kunden krever det, kan CoDeSys sin IDE tilpasses for å endre kundens logo og utseende, derfor vil du oppleve at utviklingsplattformene til ulike produsenter ser forskjellige ut, men stilene er relativt like.
Selvfølgelig kan brukere også bruke andre IDEer. Beckhoff bruker for eksempel Microsofts Visual Studio, mens kjerne- og funksjonsbiblioteket bak kompilatoren fortsatt bruker CoDeSys sin løsning.
Runtime of CoDeSys har sterk tilpasningsevne og støtter de fleste operativsystemer og maskinvarebrikkearkitekturer.
2.2 CoDeSys kjøretidsprinsipp
IDE-delen av CoDeSys er gratis, og du kan laste den ned fra den offisielle nettsiden for å oppleve den. Den virkelige kostnaden er runtime-systemet Runtime System.
I begynnelsen av designet delte CoDeSys funksjonene inn i flere komponentmoduler, som bussprotokollstabel, visuelt grensesnitt, bevegelseskontroll, sikkerhetskontroll osv. Brukere kan velge de nødvendige modulene for å bygge sitt eget system som byggeklosser, og til slutt danne en tilpasset kontrollprogramvareplattform.
Noen brukere som er nye til myk PLS kan føle seg ukjent med denne delen, men faktisk er denne designmetoden veldig vanlig. For eksempel fungerer sanntidsverktøykassen (Real-Time) til MATLAB Simulink på denne måten. Brukere designer kontrollprogrammer ved å dra og slippe i det grafiske grensesnittet til Simulink, og deretter laste dem ned til den virkelige maskinvaren for å kjøre. Du kan lære om det her.
Det finnes også en slik bruksmåte som Beckhoff. Brukere programmerer i TwinCAT IDE og laster dem deretter ned til kontrolleren til Beckhoff. Faktisk er en kjøretid forhåndsinstallert i kontrolleren. Siemens STEP7 er også en IDE, og dens PLS har også en matchende kjøretid.
PLS-programmet skrevet av brukeren er som applikasjonen på datamaskinen vår. Det kjører på kjøretidssystemet, og kjøretidssystemet kjører på operativsystemet.
Kjøretidssystemet er plassert mellom applikasjonen og operativsystemet. Så det kan kalles mellomvare. I robotprogramvare er ROS, OROCOS (Real-Time Toolkit) osv. i samme posisjon.
Robotstyring, som CNC-maskinverktøy, krever sanntidsytelse, så operativsystemet vi velger er fortrinnsvis et sanntidsoperativsystem (RTOS). Dessverre er operativsystemene vi ofte bruker ikke sanntid, slik som Windows og Linux. Men heldigvis har noen modifisert dem, det vil si lagt til sanntidsoppdateringer.
Vanlige sanntidsoperativsystemer inkluderer: VxWorks, QNX, Windows RTX, Xenomai, RT Linux, Linux RTAI, WinCE, μC/OS, SylixOs osv. Med tanke på at det er mange brukere av Windows og Linux operativsystemer, har CoDeSys lansert en tilsvarende sanntidsoppdatering (RTE) for å spare brukere for bryet med endring.
For mer informasjon om CoDeSys Runtime, kan du lese det offisielle dokumentet [Math Processing Error] [1][2][1][2].
2.3 Ulemper med CoDeSys
CoDeSys bringer bekvemmeligheten til kontrollutviklingen vår og sparer oss for bryet med å starte fra bunnen av. Det er imidlertid også mange ulemper ved å utvikle våre egne kontrollerprodukter basert på kommersiell programvare som CoDeSys:
(1) Den underliggende algoritmen er ikke åpen
Bevegelseskontrollkomponentene og bussprotokollstablene integrert av CoDeSys er alle innkapslet. Brukere kan ikke forstå sine interne detaljer, og de kan heller ikke tilpasse og optimalisere dem i henhold til deres spesifikke behov. De kan bare ringe dem enkelt. Brukere kan kun stole på CoDeSys-plattformen og synes det er vanskelig å danne sin egen kjerneteknologi.
(2) Begrensede funksjoner og vanskelig å utvide
Nye teknologier representert av maskinsyn, kunstig intelligens og autonom kjøring går nå frem med stormskritt, mens mange teknologier innen industriell kontroll fortsatt er 20 år gamle. For å ta navigasjonsscenen i en mobil robot som et eksempel, må navigasjonsmetoden basert på syn eller laser samle inn en stor mengde data og behandle den, noe som innebærer mange matriseberegninger.
Nå kan PLS bare utføre bakover, endimensjonale digitale beregninger, noe som gjør det vanskelig å implementere komplekse algoritmer. I motsetning til åpen kildekode-stilen til kunstig intelligenssamfunnet, er det industrielle kontrollsamfunnet lukket for hverandre. Ingen er villige til å åpne sine egne funksjonsbiblioteker. Det er svært få funksjonsbiblioteker med åpen kildekode (OSCAT). Selv de mest grunnleggende filtreringsalgoritmene og matriseberegningene må skrives fra bunnen av. Dessuten er de grunnleggende funksjonene som tilbys av internasjonale standarder for begrensede og kan ikke tilpasses nye scenarier i det hele tatt. De har et akutt behov for utvidelse.
(3) Vanskelig å oppdatere
På grunn av den fullstendige avhengigheten av CoDeSys, må oppgraderingen av kundenes egen produktmaskinvare tilpasses og transplanteres, noe som resulterer i økte kostnader.
3 Åpen kildekode-løsninger
For øyeblikket er det noen åpen kildekode-kontrollsystemløsninger, som Beremiz, Orocos, OpenPLC, OpenRTM og ORCA.
Å utvikle robotkontrollere er en tung oppgave. En rekke ytelseskrav må avklares, hvorav det første er sanntidsytelse.
Sanntidsytelse er generelt nødvendig for industriroboter, men ikke nødvendigvis for service- eller underholdningsroboter. Det er lett for vanlige mennesker å ta feil av «sanntidsytelse» som rask prosessering eller responshastighet, men faktisk betyr «sanntidsytelse» «determinisme» i tid. For eksempel må forsinkelsestiden for avbruddsrespons eller prosessveksling i sanntidsoperativsystemet (RTOS) være innenfor et tidsrom.
Operativsystemene vi vanligvis bruker (Windows, Linux) er ikke sanntidsoperativsystemer, fordi de er designet for gjennomstrømning og kan ikke garantere at hver hendelse behandles innenfor et visst område. For eksempel er overføringshastigheten til standard Ethernet mye raskere enn for sanntids industriell Ethernet, men den er heller ikke sanntid, fordi den heller ikke kan garantere at data overføres innen en gitt tid.
Det er ikke vanskelig å forstå sanntid, men hvilke oppgaver må roboten kjøre i sanntid? Hvordan bestemme tidsintervallet for program som kjører i henhold til ytelseskravene til roboten (1ms eller 10ms)? Er sanntid avhengig av maskinvare eller programvare?
Hvordan velge spesifikk maskinvare og programvare basert på sanntid (ARM eller X86, Linux RTAI eller VxWorks)? Det mangler en grundig diskusjon om dette aspektet på Internett, og store robotprodusenter vil ikke avsløre sine test- og eksperimentelle resultater. Det ser ut til at dette aspektet hovedsakelig er avhengig av erfaring og prøving og feiling.
Her kan jeg bare gi noen få indikatorer. For tiden er kontrollsyklusen til industrielle robotarmer omtrent 1 ms, og kontrollsyklusen til posisjonssløyfen til en høyytelses servodrift kan nå 125 [Math Processing Error] mu sμs. PLCopen definerer noen standarder for servo- og bevegelseskontroll, inkludert programmeringsspråk, grunnleggende funksjonsblokker for bevegelseskontroll, parametere for inngangs- og utgangsgrensesnitt osv. [Math Processing Error] ^{[3]}
[3] De spesifikke implementeringskodedetaljene er gitt av ulike produsenter.
