Denne artikel sammenligner kontrolsystemløsningerne for to industrirobotter, manipulatoren og den mobile robot, og introducerer deres egenskaber.
Ovenstående klassificering er baseret på applikationsobjektet. Derudover er der mere generelle motion controllere på markedet, det vil sige dem, der styrer ikke-standardudstyr.
1 Controller på bundniveau 1.1 Manipulatortype Regulatoren af manipulatortypen er udviklet tidligere og er relativt moden. Lad os tage et kig på det eksisterende kontrolsystem på bundniveau. 1.2 Mobil robottype Styringen af den mobile robot tilhører en relativt ny retning. Industrielle mobile robotter er i form af AGV, ubemandet ingeniørmaskineri osv. Bundniveauløsningen af styresystemet er som følger:
1.3 Sammenligning
Manipulatoren har høje krav til nøjagtighed og bevægelsesstabilitet, så beregningsmængden er stor, og cyklussen er kort, hvilket generelt er 1 til 2 størrelsesordener højere end for mobile robotter. Mobile robotter har generelt ikke høje krav til synkroniseringsnøjagtighed, og deres konfiguration er relativt lav.
Manipulatoren arbejder generelt i et fast område, og dens controller er normalt placeret i chassiset, så beskyttelsesniveauet er ikke højt, generelt IP20. Mobile robotter skal være vandtætte og støvtætte, fordi de skal bevæge sig ofte, især udendørs ingeniørmaskiner, så de skal overveje vandtætning og støvtætning. Deres beskyttelsesniveau er højere, generelt IP67.
2 Introduktion til CoDeSys 2.1 Sammensætning af CoDeSys
Du vil opdage, at mange robotstyringssoftware er implementeret ved hjælp af CoDeSys, så hvad er CoDeSys?
CoDeSys er en betalt blød PLC-udviklingssoftware. Kort sagt består det af to dele: Udviklingssystem og Runtime System. Development System er softwaregrænsefladen, der bruges til programmering (ligesom Visual Studio, Eclipse og anden software, som også kan kaldes IDE). Design, debugging og kompilering af PLC-programmer udføres alle i IDE, som er den del, som brugere ofte beskæftiger sig med;
Efter at PLC-programmet er skrevet, skal det overføres til hardwareenheden for drift. Det genererede PLC-program kan dog ikke køre af sig selv på nuværende tidspunkt. Det skal fungere i et bestemt softwaremiljø. Dette miljø er Runtime System, som er usynligt for brugerne.
Installationsstederne for de to er normalt forskellige. IDE er generelt installeret på udviklingscomputeren, og Runtime System er placeret på den hardwareenhed, der spiller en kontrolrolle. De to er generelt forbundet med netværkskabler, og programmet downloades til Runtime gennem netværkskablet til drift.
CoDeSys er ikke kendt i Kina, men det har et mangeårigt ry i Europa, især inden for industriel kontrol. Mange robotvirksomheder, vi nævnte ovenfor, bruger deres produkter, såsom KEBA, Beckhoff, Googol og næsten alle producenter af mobile robotcontrollere.
3S, virksomheden, der har designet CoDeSys, sælger kun software, ikke hardware. Hardwarekredsløbet skal designes af brugeren, og 3S er ansvarlig for at portere Runtime Systemet til kundens hardware. Runtime Systemet kan køre nøgen på hardwaren, men det kører normalt på operativsystemet, og konfigurering af operativsystemet er også kundens opgave.
Hvis kunden ønsker det, kan CoDeSys's IDE tilpasses til at ændre kundens logo og udseende, hvorfor du vil opleve, at forskellige producenters udviklingsplatforme ser forskellige ud, men stilene er relativt ens.
Selvfølgelig kan brugere også bruge andre IDE'er. Beckhoff bruger eksempelvis Microsofts Visual Studio, mens kerne- og funktionsbiblioteket bag compileren stadig bruger CoDeSys's løsning.
Runtime of CoDeSys har stærk tilpasningsevne og understøtter de fleste operativsystemer og hardwarechiparkitekturer.
2.2 CoDeSys Runtime Princip
IDE-delen af CoDeSys er gratis, og du kan downloade den fra dens officielle hjemmeside for at opleve den. Den reelle afgift er runtime-systemet Runtime System.
I begyndelsen af sit design opdelte CoDeSys funktionerne i flere komponentmoduler, såsom busprotokolstak, visuel grænseflade, motion control, sikkerhedskontrol osv. Brugere kan vælge de nødvendige moduler til at bygge deres eget system som byggeklodser, og til sidst danne en skræddersyet kontrolsoftwareplatform.
Nogle brugere, der er nye til blød PLC, føler sig måske ikke bekendt med denne del, men faktisk er denne designmetode meget almindelig. For eksempel fungerer realtidsværktøjskassen (Real-Time) i MATLAB Simulink på denne måde. Brugere designer kontrolprogrammer ved at trække og slippe i Simulinks grafiske grænseflade og derefter downloade dem til den rigtige hardware for at køre. Du kan lære om det her.
Der er også sådan en brugsmåde som Beckhoff. Brugere programmerer i TwinCAT IDE og downloader dem derefter til Beckhoffs controller. Faktisk er en runtime forudinstalleret i controlleren. Siemens STEP7 er også en IDE, og dens PLC har også en matchende runtime.
PLC-programmet skrevet af brugeren er ligesom applikationen på vores computer. Det kører på runtime-systemet, og runtime-systemet kører på operativsystemet.
Runtime-systemet er placeret mellem applikationen og operativsystemet. Så det kan kaldes middleware. I robotsoftware er ROS, OROCOS (Real-Time Toolkit) osv. i samme position.
Robotstyring kræver, ligesom CNC-værktøjsmaskiner, realtidsydelse, så det operativsystem, vi vælger, er fortrinsvis et realtidsoperativsystem (RTOS). Desværre er de operativsystemer, vi ofte bruger, ikke i realtid, såsom Windows og Linux. Men heldigvis har nogen modificeret dem, det vil sige tilføjet real-time patches.
Almindelig brugte realtidsoperativsystemer omfatter: VxWorks, QNX, Windows RTX, Xenomai, RT Linux, Linux RTAI, WinCE, μC/OS, SylixOs osv. I betragtning af at der er mange brugere af Windows og Linux operativsystemer, har CoDeSys lanceret en tilsvarende real-time patch (RTE) for at spare brugere for besværet med ændringer.
For mere information om CoDeSys Runtime kan du læse det officielle dokument [Math Processing Error] [1][2][1][2].
2.3 Ulemper ved CoDeSys
CoDeSys bringer bekvemmelighed til vores controllerudvikling og sparer os for besværet med at starte fra bunden. Der er dog også mange ulemper ved at udvikle vores egne controllerprodukter baseret på kommerciel software såsom CoDeSys:
(1) Den underliggende algoritme er ikke åben
Bevægelseskontrolkomponenterne og busprotokolstakkene integreret af CoDeSys er alle indkapslet. Brugere kan ikke forstå deres interne detaljer, og de kan heller ikke tilpasse og optimere dem efter deres specifikke behov. De kan kun ringe til dem. Brugere kan kun stole på CoDeSys-platformen og har svært ved at danne deres egen kerneteknologi.
(2) Begrænsede funktioner og vanskelige at udvide
Nye teknologier repræsenteret ved maskinsyn, kunstig intelligens og autonom kørsel er nu fremme med stormskridt, mens mange teknologier inden for industriel kontrol stadig er 20 år gamle. Tager man navigationsscenen i en mobil robot som eksempel, skal navigationsmetoden baseret på syn eller laser indsamle en stor mængde data og behandle dem, hvilket involverer en masse matrixberegninger.
Nu kan PLC kun udføre baglæns endimensionelle digitale beregninger, hvilket gør det vanskeligt at implementere komplekse algoritmer. I modsætning til open source-stilen i det kunstige intelligenssamfund er det industrielle kontrolfællesskab lukket for hinanden. Ingen er villige til at åbne deres egne funktionsbiblioteker. Der er meget få open source-funktionsbiblioteker (OSCAT). Selv de mest basale filtreringsalgoritmer og matrixberegninger skal skrives fra bunden. Desuden er de grundlæggende funktioner i internationale standarder for begrænsede og kan slet ikke tilpasse sig nye scenarier. De har et akut behov for udvidelse.
(3) Svært at opdatere
På grund af den fuldstændige afhængighed af CoDeSys skal opgraderingen af kundernes egen produkthardware tilpasses og transplanteres, hvilket resulterer i øgede omkostninger.
3 Open source-løsninger
I øjeblikket er der nogle open source kontrolsystemløsninger, såsom Beremiz, Orocos, OpenPLC, OpenRTM og ORCA.
Det er en tung opgave at udvikle robotcontrollere. En række præstationskrav skal afklares, hvoraf det første er realtidsydelse.
Realtidsydelse er generelt nødvendig for industrirobotter, men ikke nødvendigvis for service- eller underholdningsrobotter. Det er let for almindelige mennesker at forveksle "realtidsydelse" som hurtig behandling eller responshastighed, men faktisk betyder "realtidsydelse" "determinisme" i tid. For eksempel skal forsinkelsestiden for afbrydelsessvar eller processkift i realtidsoperativsystemet (RTOS) være inden for et tidsinterval.
De operativsystemer, vi almindeligvis bruger (Windows, Linux), er ikke realtidsoperativsystemer, fordi de er designet til gennemstrømning og kan ikke garantere, at hver hændelse behandles inden for et bestemt område. For eksempel er transmissionshastigheden for standard Ethernet meget hurtigere end for real-time industriel Ethernet, men den er heller ikke real-time, fordi den heller ikke kan garantere, at data transmitteres inden for en given tid.
Det er ikke svært at forstå realtid, men hvilke opgaver i robotten skal køre i realtid? Hvordan bestemmes tidsintervallet for program, der kører i henhold til robottens ydeevnekrav (1ms eller 10ms)? Afhænger realtid af hardware eller software?
Hvordan vælger man specifik hardware og software baseret på realtid (ARM eller X86, Linux RTAI eller VxWorks)? Der mangler en dybdegående diskussion om dette aspekt på internettet, og store robotproducenter vil ikke offentliggøre deres test- og eksperimentelle resultater. Det ser ud til, at dette aspekt hovedsageligt bygger på erfaring og forsøg og fejl.
Her kan jeg kun give nogle få indikatorer. På nuværende tidspunkt er kontrolcyklussen for industrirobotarme omkring 1 ms, og kontrolcyklussen for positionsløkken for et højtydende servodrev kan nå 125 [Math Processing Error] mu sμs. PLCopen definerer nogle standarder for servo- og bevægelsesstyring, herunder programmeringssprog, grundlæggende bevægelseskontrolfunktionsblokke, parametre for input- og outputgrænseflader osv. [Matematikbehandlingsfejl] ^{[3]}
[3] De specifikke implementeringskodedetaljer leveres af forskellige producenter.
