Come posso controllare un sistema in tempo reale veloce (200Hz) con un sistema lento (30Hz)?

Attualmente stiamo progettando un robot mobile + braccio montato con più gradi di libertà e sensori controllati.

Sto considerando un'architettura in due parti:

1. Una serie di controller in tempo reale (o Raspeberry Pis che esegue un RTOS come Xenomai o microcontrollori bare metal) per controllare i motori e gli encoder del braccio. Chiamiamo queste macchine RTx, con x = 1,2,3… a seconda del numero di microcontrollori. Questo circuito di controllo funzionerà a 200Hz.

2. Una potente macchina Linux vanilla che esegue ROS per calcolare SLAM, mocap ed eseguire logiche di alto livello (decidere il compito del robot e calcolare la posizione e la velocità desiderate dei motori). Questo circuito di controllo funzionerà a 30Hz.

So che il mio framework deve essere scalabile per tenere conto di più motori, più sensori, più PC (ad es. Per mocap esterni).

Il mio problema principale è decidere come far comunicare i diversi RTx con PC1. Ho esaminato i documenti relativi all'architettura dei robot (ad esempio HRP2 ), molto spesso descrivono l'architettura di controllo di alto livello, ma devo ancora trovare informazioni su come far comunicare il livello basso con l'alto livello e in modo scalabile. Ho dimenticato qualcosa?

Per collegare le macchine RT veloci garantendo il controllo del motore con PC1, ho considerato TCP / IP, CAN e UART:

• TCP / IP: non deterministico ma facile da implementare. Il non determinismo è un vero problema (in quanto verrà utilizzato solo a bassa velocità a 30Hz)?
• CAN: lento, molto affidabile, mirato alle auto (ho visto che ci sono alcuni esempi che utilizzano CAN con i robot ma sembrava esotico)
• UART: se avessi avuto solo una macchina RT per il controllo del motore avrei considerato UART ma suppongo che questa porta non si ridimensiona bene con molti RTx TCP / IP è davvero un non andare a causa delle sue caratteristiche non deterministiche? É così facile da usare…

Al momento nessuna soluzione mi sembra davvero ovvia. E poiché non riesco a trovare alcun esempio di robot serio utilizzando una soluzione specifica affidabile e scalabile, non mi sento sicuro di fare una scelta.

Qualcuno ha una visione chiara su questo punto o sulla letteratura a cui puntare? Esistono soluzioni di comunicazione tipiche o tradizionali utilizzate sui robot?

Penso che tu abbia fatto un buon primo passo; hai diviso il problema in una piattaforma mobile (che ha incertezza di posizione e deve navigare) e il braccio (che ha una discreta certezza di posizione in tempo reale, tramite encoder).

Ho esaminato documenti relativi all'architettura dei robot [...] ma non ho ancora trovato informazioni su come far comunicare il livello basso con il livello alto e in modo scalabile. Ho dimenticato qualcosa?

Dalla tua descrizione, sembra che tu stia cercando di collegare ogni controller RTx direttamente a PC1, che esegue ROS. Quello che ti sei perso è che ROS è progettato per gestire un gruppo di applicazioni che possono produrre e consumare dati a velocità diverse.

Ciò di cui l'applicazione ha bisogno è un bridge di comunicazione : un'unica interfaccia tra il loop a 200Hz e l'ambiente ROS. In altre parole, invece di legare ogni controller RTx a PC1, legare tutti i controllori RTX e collegare che a PC1.

Ad esempio, utilizzare un bus I2C per collegare insieme i sistemi RTx e aggiungere un altro controller RTx come "Arm Master" (AM). Il compito dell'AM sarebbe quello di accettare i comandi in arrivo in un formato e protocollo compatibili con PC1 e di convertirli in messaggi I2C. Quindi scriveresti un'app ROS per inviare comandi a AM.

Un altro modo per farlo con I2C sarebbe quello di mettere un controller I2C direttamente su PC1 e scrivere tutta la logica di controllo del braccio in un'app ROS. Questo può sembrare un modo più snello per raggiungere il tuo obiettivo, ma può rendere più difficile il debug poiché stai rimuovendo la modularità del sistema: dovrai risolverlo come un unico grande sistema complesso invece di due componenti facilmente testabili.

Direi che qualsiasi applicazione in cui è richiesto un gran numero di nodi di comunicazione (sensori o attuatori) trarrebbe vantaggio dall'implementazione come bus di sistema (contrariamente ai collegamenti punto-punto come UART o Ethernet), a causa della complessità del cablaggio, del determinismo e modularità.

Qualsiasi sistema di controllo richiede un alto grado di determinismo, in cui i canali ad alta larghezza di banda (come Ethernet) sono generalmente scarsi (specialmente se utilizzati con un sistema operativo generico che introduce grandi quantità di jitter di pianificazione, vedere il link seguente per una discussione sul determinismo di pianificazione ). Anche i processori di applicazioni (come ARM11 di Raspberry Pi) sono probabilmente inadatti per i sistemi in tempo reale (a causa di effetti come la latenza di interruzione e il rivestimento delle istruzioni). Vedi la seguente discussione digikey che confronta il comportamento in tempo reale di un core di un'applicazione ARM rispetto a un microcontrollore .

È un peccato che la disponibilità del CAN integrato non sia così diffusa come UART (RS-485) o I2C (ancora), perché penso che semplifichi davvero il problema del rilevamento distribuito e dell'attuazione. E mentre i soliti 1 Mbps possono sembrare lenti, di solito è più che sufficiente dopo che sono state calcolate le frequenze di aggiornamento di tutti i membri del bus (e la velocità di trasmissione può sempre essere aumentata, a seconda della lunghezza del bus, dell'impedenza e se i ricetrasmettitori lo consentiranno). C'è anche un brillante software di simulazione disponibile, che sostanzialmente garantisce i tempi di risposta peggiori (ad esempio RealTime-at-work ha un analizzatore di bus CAN gratuito chiamato RTaW-Sim). Infine, sembrerebbe che la disponibilità dei sensori MEMS con CAN integrato sia piuttosto scarsa.

Un altro esempio in cui gli attuatori sono configurati come bus (o anello) sono le serie Dynamixels AX e MX, in cui ogni motore è collegato in cascata al successivo tramite un collegamento UART. Ciò semplifica notevolmente la progettazione del sistema se si dispone di una grande quantità di attuatori.

Ma, per tornare alla domanda reale, penso che se descrivi il tuo sistema come set point in tempo reale, anziché come comandi (ad es. Piuttosto diffondi continuamente un angolo del motore piuttosto che dare istruzioni su un comando come goto angle), semplifica l'accoppiamento tra il loop 200 Hz e 30 Hz.

Sembra che tu abbia 2 problemi separati (ma correlati) che stai cercando di risolvere contemporaneamente. Dividiamo il tuo enigma in pezzi più piccoli:

1. Come posso comunicare comandi da un sistema lento (30Hz) a un controller veloce (200Hz) e come posso comunicare i dati ricevuti a 200Hz al mio thinktank a 30Hz?
2. Come posso controllare cosa sta accadendo a 200Hz, quando posso solo dire al robot cosa fare a 30Hz?

L'articolo 1 può essere risolto nell'hardware come sembra indicare la domanda originale: è possibile mettere in coda i dati a 200Hz e inviare il pacchetto a 30Hz al sistema di livello superiore. Puoi farlo con TCP / IP o eventualmente CAN a seconda della quantità di dati che desideri inviare. Hardware diverso ha velocità dati massime diverse. Anche l'aggiunta di un livello di architettura come ROS per fungere da ponte di comunicazione / arbitro come suggerito in altri post può aiutare.

L'articolo 2 è un problema di teoria del controllo che non può essere risolto solo con l'hardware. Lo SLAM, le determinazioni di posizione e velocità e la determinazione delle attività che desideri dovranno essere più intelligenti poiché inviano e ricevono informazioni meno spesso. Probabilmente avrai bisogno di 2 loop di controllo : 1 a 200Hz e 1 a 30Hz.

Ci sono molte altre domande che coprono i loop di feed-forward, feed-back e PID, ma hai chiesto in modo specifico la scalabilità: il modo in cui la maggior parte dei sistemi giganti scala è sovrapponendo i circuiti di controllo e la logica in modo che le informazioni minime necessarie attraversino qualsiasi hardware si finisce con. Ad esempio, il tuo controller di livello superiore potrebbe assegnare solo punti di posizione dell'obiettivo e una velocità media dell'obiettivo a quello di livello inferiore, non cambiare la velocità 30 volte al secondo.