Quanto è matura la programmazione in tempo reale in robotica? [chiuso]

Modifica: non so perché, ma questa domanda sembra confondere molte persone. Sono consapevole di quando / dove / perché / come utilizzare in tempo reale. Sono interessato a sapere se le persone che hanno un compito in tempo reale si preoccuperebbero abbastanza per implementarlo in tempo reale o meno.

Non è necessario menzionare perché le operazioni in tempo reale sono importanti per un robot. La mia domanda è tuttavia: quanto viene effettivamente utilizzato in robotica?

Prendi questa domanda per esempio. Solo una risposta menziona qualsiasi piattaforma con funzionalità in tempo reale ed è anche lontana dalla cima. Apparentemente ROS, essendo una piattaforma molto popolare che non è in tempo reale.

Nel mondo in tempo reale, tuttavia, RTAI ¹ sembra essere l'unica piattaforma di utilizzo in tempo reale gratuita realizzabile . È tuttavia limitato a Linux (nessun problema), mal documentato e sviluppato lentamente.

Quindi, quanto viene ricercato il comportamento in tempo reale tra gli sviluppatori di robotica?La domanda è: quanto sono propensi gli sviluppatori a scrivere applicazioni in tempo reale quando è effettivamente necessario un comportamento in tempo reale? Se non molto, perché?

Ad esempio, il comportamento riflessivo basato su dati tattili, non può passare attraverso ROS perché perderebbe la sua proprietà in tempo reale. Ma le persone escogitano davvero una soluzione in tempo reale o usano comunque ROS, ignorando la proprietà in tempo reale?

¹ o similmente Xenomai

Ricorda che c'è tempo reale e tempo reale .

Hard Real Time è difficile da ottenere senza supporto hardware o supporto software di basso livello, ma spesso non è necessario tutto per essere in grado di realizzare Hard Real Time . La risposta in tempo reale di Soft & Firm è molto più facile da ottenere ed è spesso più che adeguata per molte applicazioni.

Inoltre, diverse parti di un sistema possono avere requisiti in tempo reale molto diversi . Se stai eseguendo loop PID software, dovrebbero davvero avere una risposta in tempo reale difficile (non devi davvero scegliere tra soft tuning i tuoi PID o messa a punto duramente e farli diventare occasionalmente instabili, per esempio). Un sistema di visione potrebbe avere fermi requisiti di risposta in tempo reale , le prestazioni diminuiranno se non è possibile elaborare l'immagine in tempo per la decisione successiva, ma non è necessario impedire il funzionamento del sistema, in questo caso se non è possibile elaborarla in tempo è meglio buttare via i risultati parziali e non perdere tempo a iniziare l'analisi sul frame successivo. Finalmente la tua pianificazione e coordinamento generale (probabilmente il più complessoparte del tuo sistema robotico) può spesso rimanere saldamente nel dominio del soft real time .

Anche nel regno dei PC Windows puoi ottenere prestazioni in tempo reale difficili , hai solo bisogno del software giusto con i giusti hook nel kernel. Il soft PLC TwinCat di Beckhoff ha eseguito abbastanza felicemente un PLC ad alta velocità di scansione tagliando metà dei cicli di una macchina Pentium, dando l'altra metà a Windows NT, e questo è successo più di un decennio fa. Anche i moderni sistemi di controllo come alcune opzioni nella gamma A3200 di Aerotech svolgono il lavoro grugnito sul PC host, con il kernel di basso livello che occupa tutto il tempo CPU necessario per i requisiti di tempo reale e lasciando il resto dei cicli CPU per Windows 7 usare!

Un sistema in tempo reale non è realmente richiesto per molti (la maggior parte?) Sistemi di controllo robotico. Finché hai un loop di controllo che corre abbastanza veloce, con jitter abbastanza basso e non perde troppi cicli, questo è abbastanza adeguato per il controllo robotico e il servoing.

A riprova di ciò, lasciatemi presentare la PR2 e la Shadow Robot Hand:

Questo robot ha circa 20 gradi di libertà, tutti serviti attraverso il circuito principale di ROS. O che ne dici della Shadow Robot Hand, che ha anche 20 DOF, oltre a una serie di sensori tattili e di altro tipo, ed è anche servita attraverso il circuito principale di ROS.

Il circuito principale ROS soffre di un piccolo jitter, a volte fino a 100us, e talvolta a volte manca del tutto i cicli. Ma non importa se il 99,9% dei cicli viene eseguito correttamente.

L'uso di molti core nei PC host significa che un intero core è dedicato all'esecuzione del ciclo principale, e quindi è molto raramente ritardato da altre attività.

Il motivo principale per l'utilizzo di un sistema operativo in tempo reale per un sistema robotico è la sicurezza. Se il robot lavora in una situazione critica di sicurezza, è responsabilità dell'utente garantire il 100% di up-time di controllo, e in parte ciò garantisce la sua natura in tempo reale.

Indipendentemente dal fatto che tu usi un sistema operativo in tempo reale o meno, i tuoi servi dovrebbero fare qualcosa di sicuro nel caso in cui il circuito di controllo si interrompa completamente. Questo sistema di sicurezza sarebbe anche utile nelle rare occasioni in cui il tuo sistema operativo non in tempo reale salta più di un ciclo. Ad esempio, sulla Shadow Shadow, i motori vengono arrestati se il circuito di controllo manca più di 20 cicli (20ms). Non l'ho mai visto accadere però.

aggiunto

Un altro modo di pensarci è questo: di quale frequenza di aggiornamento ha effettivamente bisogno il tuo servosistema? Se è un braccio largo e non necessita di prestazioni super elevate, posizionamento ad alta velocità, allora 500Hz potrebbero essere sufficienti. Per andare in giro, 200Hz è probabilmente sufficiente. In entrambi questi casi, se il tuo loop è effettivamente in esecuzione a 1000Hz, un ciclo in ritardo o mancante non è affatto un problema, a condizione che l'algoritmo di controllo tenga conto del tempo reale trascorso tra i loop.

Lo scopo del software determina se deve essere rigorosamente in tempo reale.

Laddove lo scopo è la pianificazione o la localizzazione del percorso, spesso è sufficiente una bassa frequenza, ad esempio 10Hz. In questi casi, una configurazione giocatore / palco in esecuzione su Linux va bene. Possiamo vedere che ci sono pochi problemi se un passaggio temporale è un po 'più lungo o più corto.

Se la dinamica del robot è veloce, è necessario un comportamento rigorosamente in tempo reale. Ad esempio, spostando un braccio robotizzato per tracciare una posizione o per maneggiare / afferrare oggetti e spostarli. Se manca un passaggio temporale, la posizione potrebbe essere superata in modo indesiderato e potremmo desiderare comportamenti più prevedibili. In questo caso, potremmo avere una frequenza fino a 1kHz o più. Se viene utilizzato un sistema operativo, vogliamo un sistema operativo in tempo reale.

Il comportamento in tempo reale può essere realizzato in applicazioni integrate, utilizzando timer e interrupt (codice C compilato su un microcontrollore). In questo caso, dobbiamo garantire che il carico di elaborazione non sia troppo elevato in modo da poter mantenere una frequenza di campionamento regolare.

I robot che utilizzano computer / microprocessori (poiché è necessaria una maggiore potenza di elaborazione), dovranno utilizzare un sistema operativo in tempo reale per garantire elevate frequenze di campionamento.

Pertanto, se è richiesto un comportamento in tempo reale dipende da cosa lo sviluppatore intende utilizzarlo.

La nostra azienda costruisce robot utilizzando FreeRTOS in esecuzione su microcontrollori PIC. Per noi, i motivi principali per utilizzare FreeRTOS sono la facilità di riordinare le priorità sulle attività, la gestione simultanea di più linee di comunicazione e la comunicazione semplice tra gestori di interruzioni e attività principali. I microcontrollori sono molto più economici rispetto al mettere una macchina linux completa in ogni robot che produciamo.

Se hai effettivamente bisogno in tempo reale, allora usi un sistema operativo in tempo reale. I circuiti di monitoraggio della sicurezza, acquisizione dati e controllo costante della frequenza di campionamento sono sottosistemi comuni che utilizzano la pianificazione in tempo reale.

La parte in tempo reale della programmazione è generalmente la più piccola possibile, perché è più difficile eseguire il debug e meno codice è più facile da verificare per la correttezza. La documentazione sui sistemi operativi in ​​tempo reale è generalmente piuttosto buona (incluso RTAI / Xenomai).

Ho usato QNX e RTAI-> Xenomai in diversi progetti di robotica reale . Ho preferito QNX ma Xenomai è stato altrettanto efficace.

Orocos è un framework software maturo di controllo della robotica in tempo reale. L'ho visto usato per controllare con successo manipolatori robot ad alta velocità con requisiti in tempo reale difficili. Ha molti degli stessi componenti a livello di framework di ROS, comunicazioni, configurazione, serializzazione e packaging basato su componenti.

Inizia a pensare al tuo robot in termini di CPU multiple e turni di domande in tempo reale. Se si dispone di un algoritmo che necessita di feedback affidabili ad alta velocità come un bilanciatore a due ruote o uno stabilizzatore quad-elicottero o un servo impulso, il tempo reale è estremamente importante, ma l'attività è anche molto limitata.

È possibile scaricare un loop di controllo come questo su una CPU in tempo reale dedicata come l'AVR economico a 8 bit o ARM di fascia bassa a 32 bit trovati nella classe di dispositivi Arduino. Non c'è nulla che ti impedisca di aggiungere molte dozzine di questi piccoli MCU che eseguono circuiti di controllo dedicati, l'enumerazione dei dispositivi USB rende anche questo facile.

Ora che hai i circuiti di controllo sensibili ai tempi gestiti da una CPU dedicata, puoi rilassare le esigenze in tempo reale del "cervello" del robot che può eseguire la logica di fascia più alta usando componenti come ROS su Linux o Kinect per Windows.

In risposta a "quando / nel qual caso" vengono utilizzati i sistemi in tempo reale:

Nella mia esperienza, il motion control è l'applicazione principale per i sistemi in tempo reale. Per il controllo dei motori sono importanti un'alta frequenza (100 Hz, 1000 Hz e oltre) e un basso jitter (variazioni di tempo). La sicurezza è un punto importante qui. Prendi in considerazione un robot tra gli esseri umani: ad esempio, vuoi / devi assicurarti che il robot (braccio) si fermi in un determinato intervallo di tempo / distanza.

Per altre attività come la pianificazione del percorso, l'elaborazione della visione e il ragionamento del sistema in tempo reale non sono così importanti e spesso evitati a causa del sovraccarico nei tempi di sviluppo e dei costi hardware.

Oggi grandi robot come il PR2 combinano entrambi i mondi. Nel contesto in tempo reale del sistema operativo abilitato per RT (ad es. Linux + Xenomai) sta avvenendo il controllo del movimento e nella parte non in tempo reale (terra dell'utente), l'elaborazione e la pianificazione della visione sono incorporate in sistemi come ROS. Entrambi possono essere eseguiti sullo stesso computer.

Sono felice di modificare questa risposta, una volta che la domanda è stata chiarita. :-)

Sì, supponendo che le risorse hardware possano soddisfare i requisiti di temporizzazione (sufficiente potenza di elaborazione, bassa latenza sufficiente), quando lo scheduler non può sequenziare processi e thread in modo appropriato, quindi si utilizza uno scheduler in tempo reale, solitamente collegato a un kernel specificamente ottimizzato per il sfide di questo. I driver hardware possono anche essere ottimizzati per condizioni in tempo reale.

Sì, se non è possibile garantire che un software esegua il proprio lavoro nei limiti di tempo richiesti, si utilizzano approcci in tempo reale.

Una buona soluzione è fare ENTRAMBE. Un design che uso colloca funzioni "difficili" in tempo reale su un piccolo microcontrollore, circuiti di servocomando stretti e simili. Poi c'è un'altra CPU più grande, con Linux e ROS. Lascio che ROS gestisca le attività di livello più alto e l'uP gestisca cose come il controllo di un motore passo-passo o l'esecuzione di un circuito PID.

Come detto sopra da altri, PUOI consentire a un sistema operativo non in tempo reale di eseguire loop di controllo a 1 KHz, ma affinché ciò funzioni è necessario un computer di dimensioni massime di over-kill che trascorre la maggior parte del tempo in un ciclo inattivo. Se si esegue il computer Linux / ROS con un utilizzo della CPU vicino al 100%, le prestazioni in tempo reale sono scadenti. L'utilizzo di un design a due livelli ti consente di ottenere sempre ottime prestazioni RT e anche di utilizzare un computer più piccolo e con meno energia (probabilmente attività di livello superiore Pi2). Il mio uP attualmente non esegue alcun sistema operativo ma mi sto spostando su FreeRTOS