Questo articolo mette a confronto le soluzioni del sistema di controllo di due robot industriali, il manipolatore e il robot mobile, e ne presenta le caratteristiche.
La classificazione di cui sopra si basa sull'oggetto dell'applicazione. Inoltre, sul mercato sono disponibili controller di movimento più generali, ovvero quelli che controllano apparecchiature non standard.
1 Soluzione di livello inferiore del controller 1.1 Tipo di manipolatore Il controller del tipo manipolatore è stato sviluppato in precedenza ed è relativamente maturo. Diamo un'occhiata alla soluzione di livello inferiore del sistema di controllo esistente. 1.2 Tipo di robot mobile Il controllore del robot mobile appartiene ad una direzione relativamente nuova. I robot mobili industriali sono sotto forma di AGV, macchinari di ingegneria senza pilota, ecc. La soluzione di livello inferiore del sistema di controllo è la seguente:
1.3 Confronto
Il manipolatore ha requisiti elevati di precisione e stabilità del movimento, quindi la quantità di calcoli è elevata e il ciclo è breve, che generalmente è da 1 a 2 ordini di grandezza superiore a quello dei robot mobili. I robot mobili generalmente non hanno requisiti elevati in termini di precisione della sincronizzazione e la loro configurazione è relativamente bassa.
Il manipolatore generalmente lavora in un'area fissa e il suo controllore è solitamente posizionato nel telaio, quindi il livello di protezione non è elevato, generalmente IP20. I robot mobili devono essere impermeabili e resistenti alla polvere perché devono spostarsi frequentemente, in particolare i macchinari di ingegneria per esterni, quindi devono considerare l’impermeabilità e la protezione dalla polvere. Il loro livello di protezione è più elevato, generalmente IP67.
2 Introduzione a CoDeSys 2.1 Composizione di CoDeSys
Scoprirai che molti software di controllo robot sono implementati con l'aiuto di CoDeSys, quindi cos'è CoDeSys?
CoDeSys è un software di sviluppo soft PLC a pagamento. In poche parole, è composto da due parti: sistema di sviluppo e sistema runtime. Il sistema di sviluppo è l'interfaccia software utilizzata per la programmazione (proprio come Visual Studio, Eclipse e altri software, che possono anche essere chiamati IDE). La progettazione, il debug e la compilazione dei programmi PLC vengono tutti eseguiti in IDE, che è la parte di cui spesso si occupano gli utenti;
Dopo che il programma PLC è stato scritto, deve essere trasferito sul dispositivo hardware per il funzionamento. Tuttavia, al momento il programma PLC generato non può essere eseguito da solo. Deve funzionare in un determinato ambiente software. Questo ambiente è il Runtime System, che è invisibile agli utenti.
Le posizioni di installazione dei due sono generalmente diverse. L'IDE è generalmente installato sul computer di sviluppo e il sistema runtime si trova sul dispositivo hardware che svolge un ruolo di controllo. I due sono generalmente collegati tramite cavi di rete e il programma viene scaricato in Runtime tramite il cavo di rete per il funzionamento.
CoDeSys non è molto conosciuto in Cina, ma gode di una reputazione di lunga data in Europa, soprattutto nel campo del controllo industriale. Molte aziende di robot menzionate sopra utilizzano i suoi prodotti, come KEBA, Beckhoff, Googol e quasi tutti i produttori di controller per robot mobili.
3S, la società che ha progettato CoDeSys, vende solo software, non hardware. Il circuito hardware deve essere progettato dall'utente e 3S è responsabile del porting del sistema runtime sull'hardware del cliente. Il sistema runtime può funzionare nudo sull'hardware, ma di solito funziona sul sistema operativo e anche la configurazione del sistema operativo è compito del cliente.
Se il cliente lo richiede, l'IDE di CoDeSys può essere personalizzato per modificare il logo e l'aspetto del cliente, motivo per cui scoprirai che le piattaforme di sviluppo di diversi produttori sembrano diverse, ma gli stili sono relativamente simili.
Naturalmente gli utenti possono utilizzare anche altri IDE. Beckhoff utilizza ad esempio Visual Studio di Microsoft, mentre il kernel e la libreria di funzioni dietro il compilatore utilizzano ancora la soluzione di CoDeSys.
Il runtime di CoDeSys ha una forte adattabilità e supporta la maggior parte dei sistemi operativi e delle architetture di chip hardware.
2.2 Principio di esecuzione di CoDeSys
La parte IDE di CoDeSys è gratuita e puoi scaricarla dal suo sito Web ufficiale per provarla. La vera carica è il sistema runtime Runtime System.
All'inizio della sua progettazione, CoDeSys ha suddiviso le funzioni in diversi moduli componenti, come stack di protocolli bus, interfaccia visiva, controllo del movimento, controllo di sicurezza, ecc. Gli utenti possono scegliere i moduli necessari per costruire il proprio sistema come elementi costitutivi e infine formare una piattaforma software di controllo personalizzata.
Alcuni utenti che non conoscono il soft PLC potrebbero non avere familiarità con questa parte, ma in realtà questo metodo di progettazione è molto comune. Ad esempio, il toolbox real-time (Real-Time) di MATLAB Simulink funziona in questo modo. Gli utenti progettano programmi di controllo trascinandoli nell'interfaccia grafica di Simulink, quindi scaricandoli sull'hardware reale per l'esecuzione. Puoi scoprirlo qui.
Esiste anche un modo di utilizzo come Beckhoff. Gli utenti programmano in TwinCAT IDE e poi li scaricano sul controller di Beckhoff. Nel controller infatti è preinstallato un runtime. Anche Siemens STEP7 è un IDE e anche il suo PLC ha un runtime corrispondente.
Il programma PLC scritto dall'utente è come l'applicazione nel nostro computer. Funziona sul sistema runtime e il sistema runtime funziona sul sistema operativo.
Il sistema runtime si trova tra l'applicazione e il sistema operativo. Quindi può essere chiamato middleware. Nel software del robot, ROS, OROCOS (Real-Time Toolkit), ecc. si trovano nella stessa posizione.
Il controllo dei robot, come le macchine utensili CNC, richiede prestazioni in tempo reale, quindi il sistema operativo che scegliamo è preferibilmente un sistema operativo in tempo reale (RTOS). Sfortunatamente, i sistemi operativi che utilizziamo spesso non sono in tempo reale, come Windows e Linux. Ma per fortuna qualcuno li ha modificati, cioè ha aggiunto patch in tempo reale.
I sistemi operativi real-time comunemente utilizzati includono: VxWorks, QNX, Windows RTX, Xenomai, RT Linux, Linux RTAI, WinCE, μC/OS, SylixOs, ecc. Considerando che ci sono molti utenti dei sistemi operativi Windows e Linux, CoDeSys ha lanciato una corrispondente patch in tempo reale (RTE) per salvare gli utenti dal problema della modifica.
Per ulteriori informazioni su CoDeSys Runtime, è possibile leggere il documento ufficiale [Math Processing Error] [1][2][1][2].
2.3 Svantaggi di CoDeSys
CoDeSys offre comodità allo sviluppo del nostro controller e ci risparmia la fatica di iniziare da zero. Tuttavia, ci sono anche molti svantaggi nello sviluppare i nostri prodotti di controllo basati su software commerciale come CoDeSys:
(1) L'algoritmo sottostante non è aperto
I componenti di controllo del movimento e gli stack di protocolli bus integrati da CoDeSys sono tutti incapsulati. Gli utenti non possono comprendere i loro dettagli interni, né possono personalizzarli e ottimizzarli in base alle loro esigenze specifiche. Possono solo chiamarli semplicemente. Gli utenti possono fare affidamento solo sulla piattaforma CoDeSys e hanno difficoltà a creare la propria tecnologia di base.
(2) Funzioni limitate e difficili da espandere
Le nuove tecnologie rappresentate dalla visione artificiale, dall’intelligenza artificiale e dalla guida autonoma stanno facendo passi da gigante, mentre molte tecnologie nel controllo industriale hanno ancora 20 anni. Prendendo come esempio la scena di navigazione in un robot mobile, il metodo di navigazione basato sulla visione o sul laser deve raccogliere una grande quantità di dati ed elaborarli, il che comporta molti calcoli a matrice.
Ora il PLC può eseguire solo calcoli digitali unidimensionali all'indietro, rendendo difficile l'implementazione di algoritmi complessi. In contrasto con lo stile open source della comunità dell’intelligenza artificiale, la comunità del controllo industriale è chiusa l’una verso l’altra. Nessuno è disposto ad aprire le proprie librerie di funzioni. Esistono pochissime librerie di funzioni open source (OSCAT). Anche gli algoritmi di filtraggio e i calcoli matriciali più basilari devono essere scritti da zero. Inoltre, le funzioni di base previste dagli standard internazionali sono troppo limitate e non possono assolutamente adattarsi ai nuovi scenari. Hanno urgente bisogno di espansione.
(3) Difficile da aggiornare
A causa della completa dipendenza da CoDeSys, l'aggiornamento dell'hardware dei prodotti dei clienti deve essere personalizzato e trapiantato, con conseguente aumento dei costi.
3 Soluzioni open source
Attualmente esistono alcune soluzioni di sistemi di controllo open source, come Beremiz, Orocos, OpenPLC, OpenRTM e ORCA.
Lo sviluppo di controller per robot è un compito arduo. Occorre chiarire una serie di requisiti prestazionali, il primo dei quali è quello delle prestazioni in tempo reale.
Le prestazioni in tempo reale sono generalmente necessarie per i robot industriali, ma non necessariamente per i robot di servizio o di intrattenimento. È facile per la gente comune confondere le "prestazioni in tempo reale" con un'elaborazione veloce o una velocità di risposta, ma in realtà "prestazioni in tempo reale" significa "determinismo" nel tempo. Ad esempio, il tempo di ritardo della reazione all'allarme o della commutazione del processo nel sistema operativo in tempo reale (RTOS) deve rientrare in un intervallo di tempo.
I sistemi operativi che utilizziamo comunemente (Windows, Linux) non sono sistemi operativi in tempo reale, perché sono progettati per il throughput e non possono garantire che ogni evento venga elaborato entro un certo intervallo. Ad esempio, la velocità di trasmissione dell'Ethernet standard è molto più veloce di quella dell'Ethernet industriale in tempo reale, ma non è nemmeno in tempo reale, perché non può garantire che i dati vengano trasmessi entro un determinato tempo.
Non è difficile capire il tempo reale, ma quali attività del robot devono essere eseguite in tempo reale? Come determinare l'intervallo di tempo per l'esecuzione del programma in base ai requisiti prestazionali del robot (1 ms o 10 ms)? Il tempo reale dipende dall'hardware o dal software?
Come scegliere hardware e software specifici basati sul tempo reale (ARM o X86, Linux RTAI o VxWorks)? Su Internet mancano discussioni approfondite su questo aspetto e i principali produttori di robot non rendono pubblici i risultati dei loro test e sperimentali. Sembra che questo aspetto si basi principalmente sull'esperienza, su tentativi ed errori.
Qui posso fornire solo alcuni indicatori. Attualmente, il ciclo di controllo dei bracci robotici industriali è di circa 1 ms e il ciclo di controllo dell'anello di posizione di un servoazionamento ad alte prestazioni può raggiungere 125[Errore elaborazione matematica] mu sμs. PLCopen definisce alcuni standard per il servocontrollo e il controllo del movimento, inclusi il linguaggio di programmazione, i blocchi funzione di base del controllo del movimento, i parametri delle interfacce di ingresso e uscita, ecc. [Errore di elaborazione matematica] ^{[3]}
[3] I dettagli specifici del codice di implementazione sono forniti da vari produttori.
