Risposta molto breve: 2
sensori
Per quanto riguarda la lettura da sensori tutti in un nodo o ciascuno separatamente, è necessario porsi questa domanda:
I sensori sono privi di significato senza l'altro?
Questa domanda pone se i sensori sono strettamente accoppiati o meno. Ad esempio, supponiamo di avere un sensore sensibile alla temperatura (e che è necessario compensarlo). Aggiungete un sensore di temperatura principalmente per fissare il valore dell'altro sensore. In questo scenario, ha senso leggere entrambi i valori contemporaneamente, poiché sono strettamente accoppiati. Infatti, senza le letture del sensore di temperatura, le letture del sensore originale sono inutili.
D'altra parte, se i sensori sono individualmente utili, sicuramente tenerli in nodi separati. Questo ha molti vantaggi:
- I nodi possono essere eseguiti su processori separati
- I nodi possono essere riutilizzati nei robot futuri
- L'errore nella comunicazione con un nodo non interrompe l'intero sistema
- Il riavvio dell'acquisizione da una scheda sensore difettosa può essere effettuato separatamente dagli altri
In effetti, se hai bisogno di uno dei vantaggi di cui sopra, dovresti andare con nodi separati, anche se i sensori sono strettamente accoppiati, ma di solito ciò non accade.
attuatori
Questo è analogo.
Gli attuatori sono privi di significato senza l'altro?
Ad esempio, se si sta progettando un polso con tendini robotici in cui per ciascun tendine (per qualsiasi motivo) due motori sono responsabili di lavorare simultaneamente per spostare un giunto in una o nell'altra direzione, quindi averli serviti nello stesso nodo rende molto di più senso che separato.
D'altra parte, dove gli attuatori sono indipendenti (caso comune), ha senso avere un nodo per ciascun attuatore. In tal caso, ognuno potrebbe essere inserito in un nodo diverso. Oltre agli stessi esatti vantaggi dei sensori, c'è questo ulteriore vantaggio:
- Se un attuatore è bloccato (per qualsiasi motivo), gli altri attuatori continuano a funzionare. Se ci sono gradi di libertà ridondanti, potrebbero persino compensarli completamente.
Questo ha un'implicazione. Se è necessario che gli attuatori funzionino in armonia, inserirli nello stesso nodo. Questo non è solo a causa di un errore nella comunicazione, ma perché nodi diversi significano ritardi diversi; su un sistema distribuito ogni nodo si trova su una parte diversa della rete e quindi la differenza nei ritardi, su un sistema centralizzato si verificano diversi ritardi su elevati carichi della CPU a causa della fortuna di ogni processo nella pianificazione.
Dovrebbe esserci un gestore?
Anche se la risposta è "dipende", esiste un approccio comune con molti vantaggi. Cambiamo il nome e chiamiamolo "controller". L'approccio è "sì, dovrebbe esserci un controller".
I vantaggi di avere un controller sono (tra i tanti):
- Elaborazione disaccoppiata: ogni nodo è responsabile di una cosa che significa:
- Semplicità: il che implica
- Sviluppo più semplice
- Debug più semplice
- Meno errori
- Meno possibilità di fallimento
- Riusabilità: perché lo stesso controller può essere utilizzato con nodi di sensori diversi se hanno le stesse funzionalità (ovvero formati di messaggi e servizi).
- Esecuzione su hardware separato: ogni nodo può essere spostato nella rete. Ad esempio, i nodi del sensore e dell'attuatore possono essere spostati su un microcontrollore dedicato ( Arduino ad esempio (non che io raccomando)) e sul controller su un PC.
- Evita la bruttezza estrema: se i sensori volessero influenzare direttamente gli attuatori, il risultato sarebbe semplicemente un casino. Supponendo che nessun controller, diamo un'occhiata a ciascun caso:
- Un nodo sensore: fondamentalmente ciò significa che il nodo sensore e il controller sono riuniti nello stesso nodo. Non troppo male, ma molto inutile.
- Molti nodi di sensori: questo è il casino. Ciò significa che il controller è distribuito tra i nodi del sensore. Pertanto, tutti i nodi del sensore devono dialogare tra loro affinché ciascuno sappia come controllare i suoi attuatori associati. Immagina un fallimento nella comunicazione o vari tipi di ritardi e vedrai quanto diventa difficile. Dato che questo è assolutamente inutile, non c'è motivo di farlo!
Detto questo, ci sono anche degli svantaggi. Avere più nodi (qualsiasi nodo, non solo il controller) significa:
- Comunicazione più sprecata: i dati devono spostarsi in formati standard (quindi serializzati e deserializzati) attraverso la rete o la memoria condivisa, il core ROS deve guardarli e decidere a chi consegnarli, ecc. In breve, alcune risorse di sistema vengono sprecate nella comunicazione. Se tutti i nodi fossero in uno, quel costo avrebbe potuto essere zero.
- Maggiori possibilità di errore: se per qualsiasi motivo un collegamento di rete si interrompe o un nodo muore, si verifica un errore nel sistema. Se non sei preparato per questo, può abbattere l'intero sistema. Ora, questa è in realtà una buona cosa in generale essere in grado di perdere parte del sistema ma non tutto ( degrado aggraziato ), ma esistono anche applicazioni in cui questo dovrebbe essere evitato il più possibile. Tagliare la comunicazione e mettere tutto il codice in un nodo aiuta effettivamente con la stabilità del sistema. Il lato negativo è ovviamente, il sistema funziona bene o improvvisamente muore completamente.
- Tempi caotici: ogni nodo funziona da solo. Il tempo necessario affinché i suoi messaggi arrivino agli altri non è deterministico e varia a seconda della corsa. A meno che i tuoi nodi non timestamp ogni messaggio (come una nota a margine: devi avere orologi sincronizzati in buona misura, cosa che ROS non fa) e a meno che ogni nodo ricevente possa prendere in considerazione il ritardo e controllare di conseguenza (che è un compito molto difficile da solo) quindi avere più nodi significa elevata incertezza sull'età dei dati. Questo è in realtà uno dei motivi (tra i tanti) che la maggior parte dei robot si muove così lentamente; il loro circuito di controllo deve essere abbastanza lento da assicurarsi che tutti i dati corrispondano al periodo corrente. Maggiore è il ritardo, più lento è il circuito di controllo.
In tutti gli svantaggi di cui sopra, la soluzione è ridurre il numero di nodi, preferibilmente a un singolo nodo. Aspetta un attimo, non sta più usando ROS! Esattamente.
Riassumere:
- Utilizzare ROS per sistemi non in tempo reale in cui i ritardi potrebbero sporadicamente aumentare. In tal caso, sentiti libero di avere tutti i nodi ROS che desideri. In effetti, è una buona pratica fare in modo che ciascun nodo ROS faccia una e una sola cosa. In questo modo, diventano molto semplici e diventano altamente riutilizzabili.
- D'altra parte, per i sistemi in tempo reale, evitare assolutamente i ROS. Per questo ci sono orocos e tecnologie come EtherCAT e il più delle volte soluzioni ad hoc.
Come ultima parola, in pratica ROS va bene. Non eccezionale, ma va bene. Molto spesso il sistema non è critico e la possibilità di guasti è così piccola che di tanto in tanto un riavvio non è un grosso problema. Questo è l' algoritmo di struzzo !
