Elaborazione in diretta o dati registrati: cosa richiede davvero una VPN?

Un robot che smette di essere utile già una stanza più in là ha un problema di collegamento o di carico di lavoro molto prima di avere un problema di VPN. La cifratura protegge un percorso; non estende la copertura radio e non fa terminare prima un calcolo remoto. La decisione davanti a te è quale lavoro deve davvero attraversare la rete, e quella risposta di solito elimina più traffico di quanto le persone si aspettino. Tre condizioni la risolvono, e la velocità di trasferimento non è una di queste.

Tre assetti, una sola domanda sulla dipendenza

La tabella separa gli assetti in base a ciò che dipende dal collegamento, non in base al software che compare nello schema.

Nessuna riga di quella tabella è un argomento di sicurezza. Le funzioni di controllo e di sicurezza richiedono comunque una risposta qualificata per ritardo, perdita di pacchetti e connessione caduta, e nessun indicatore del tunnel la fornisce. La tabella dice dove vive la dipendenza, che è la parte che un progetto di rete può davvero cambiare.

Prima condizione: la risposta deve essere tempestiva?

Se un risultato remoto alimenta un controllore, la rete sta dentro l'anello di controllo, e il suo ritardo, il jitter e le interruzioni diventano proprietà del controllo. Se lo stesso risultato alimenta solo un display, un cruscotto o una persona che guarda, lo stesso identico ritardo è solo estetico.

Il lavoro in anello chiuso su un collegamento wireless è possibile, ed è anche l'origine della maggior parte delle segnalazioni «la VPN è lenta», perché il tunnel è il componente visibile mentre la radio e l'instradamento sono la causa. Misura il tempo di andata e ritorno del messaggio reale invece del ping del tunnel, poi chiediti se quel numero rientra nel budget dell'anello. Quando non ci rientra, sposta il passaggio a bordo invece di negoziare un livello di servizio più severo per un collegamento che nessuno nella stanza controlla. Registra il numero misurato insieme alle condizioni in cui è stato rilevato, perché la prossima segnalazione arriverà senza di esse.

Seconda condizione: quale velocità, direzione e interruzione puoi dichiarare?

Scrivi i dati, la velocità, la direzione e l'interruzione più lunga che l'applicazione tollera. Un flusso video in salita e un canale di comandi in discesa falliscono in modi diversi, e un'interruzione che un'ispezione stazionaria tollera porrà fine a un compito in movimento.

Tieni separati il collegamento fisico e il tunnel quando confronti le opzioni, perché una radio più potente e un carico di lavoro minore sono riparazioni diverse. Un trasferimento grande che alla fine si completa non dimostra nulla su un risultato sensibile al tempo che arriva con costanza, e un tunnel sano non dimostra nulla sulla radio che sta dietro.

Poi riduci la domanda invece di difenderla. Riduci il campionamento del flusso di osservazione, invia riassunti o delta e lascia a bordo i dati grezzi dei sensori, dove lo spazio costa poco e la trasmissione no. Un payload più piccolo indebolisce l'argomento a favore di un collegamento più veloce e spesso elimina la necessità di averne uno.

Terza condizione: chi deve vederlo e cosa resta locale

L'osservazione è di solito un requisito molto più piccolo dell'elaborazione. Se una persona deve guardare la telecamera e un registro deve esistere dopo, si tratta di telemetria più archiviazione; se un modello deve girare, chiediti prima se può girare a bordo con solo il risultato inoltrato. Spostare a bordo il passaggio pesante elimina la dipendenza sincrona e lascia un trasferimento che può essere ritentato.

Due partecipanti ROS presenti sullo stesso robot non giustificano da soli un tunnel. Raggiungibilità dei nodi, autorizzazione delle applicazioni e un piano di ripristino locale sono problemi distinti, e una VPN risponde solo al primo, e solo per il traffico che le viene chiesto di instradare.

Registrare un set di dati è un progetto a sé, con i propri comandi

Per un esempio legato a una versione, il tutorial di registrazione di ROS 2 Jazzy copre la registrazione di argomenti selezionati, l'ispezione del bag risultante e la sua riproduzione. Registra gli argomenti di osservazione approvati, dai un nome alla sessione e tieni le definizioni dei messaggi e la configurazione accanto ad essa.

ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42

Non registrare ogni argomento solo perché lo strumento lo rende facile. Lo spazio si riempie, i dati della telecamera e della posizione sono sensibili, e un bag di argomenti senza etichetta è un problema di analisi per chi lo aprirà dopo. Anche la distribuzione installata decide i comandi: gli strumenti scritti per i bag di ROS 1 non si trasferiscono ai bag di ROS 2, quindi allinea la documentazione alla versione installata sul robot.

Riproduci in un ambiente di analisi o simulazione isolato. Argomenti di comando registrati riprodotti negli attuatori di un robot in funzione sono un incidente, e la prevenzione è un dominio ROS separato o nessun hardware nel loop.

Decidi dove deve stare la dipendenza e scrivilo: una VPN protegge uno scambio che deve avvenire, l'elaborazione a bordo elimina uno scambio che non aveva mai bisogno di essere sincrono, e un set di dati registrato sostituisce un consumatore dal vivo con uno successivo. Poi prova di proposito il caso disconnesso, con il lavoro locale ancora in esecuzione, prima che qualcuno dichiari concluso il progetto.