Procesare live sau date înregistrate: de ce are într-adevăr nevoie un VPN?

Un robot care încetează să mai fie util la o cameră distanță are o problemă de legătură sau de volum de lucru cu mult înainte de a avea o problemă de VPN. Criptarea protejează o cale, dar nu extinde acoperirea radio și nu face un calcul la distanță să se termine mai repede. Decizia din fața dumneavoastră este ce lucru trebuie să traverseze cu adevărat rețeaua, iar acel răspuns elimină de obicei mai mult trafic decât se așteaptă oamenii. Trei condiții o stabilesc, iar debitul nu este una dintre ele.

Trei aranjamente, o singură întrebare de dependență

Tabelul separă aranjamentele după ce depinde de legătură, nu după ce software apare în diagramă.

Niciun rând din acel tabel nu este un argument de siguranță. Funcțiile de control și de siguranță au în continuare nevoie de un răspuns calificat pentru întârziere, pierderea pachetelor și o conexiune căzută, iar niciun indicator de tunel nu îl oferă. Tabelul arată unde se află dependența, iar aceea este partea pe care un proiect de rețea o poate schimba cu adevărat.

Prima condiție: răspunsul trebuie să fie la timp?

Dacă un rezultat de la distanță alimentează un controller, rețeaua stă în interiorul buclei de reglare, iar întârzierea, jitterul și căderile ei devin proprietăți ale reglării. Dacă același rezultat alimentează doar un ecran, un panou sau o persoană care privește, întârzierea identică este doar cosmetică.

Lucrul în buclă închisă printr-o legătură fără fir este posibil, și tot de acolo provin majoritatea rapoartelor „VPN-ul este lent”, pentru că tunelul este componenta vizibilă, în timp ce radioul și rutarea sunt cauza. Măsurați timpul dus-întors al mesajului real, nu pingul tunelului însuși, apoi întrebați dacă numărul se încadrează în bugetul buclei. Dacă nu se încadrează, mutați pasul la bord în loc să negociați un nivel de serviciu mai strict pentru o legătură pe care nimeni din încăpere nu o controlează. Notați numărul măsurat împreună cu condițiile în care a fost luat, pentru că următorul raport va veni fără ele.

A doua condiție: ce ritm, direcție și întrerupere puteți declara?

Notați datele, ritmul, direcția și cea mai lungă întrerupere pe care aplicația o tolerează. Un flux de cameră spre amonte și un canal de comenzi spre aval eșuează în moduri diferite, iar o întrerupere tolerată de o inspecție staționară va încheia o sarcină în mișcare.

Țineți legătura fizică și tunelul separat când comparați opțiunile, pentru că un radio mai puternic și un volum de lucru mai mic sunt reparații diferite. Un transfer mare care se termină în cele din urmă nu dovedește nimic despre un rezultat sensibil la timp care sosește constant, iar un tunel sănătos nu dovedește nimic despre radioul din spatele lui.

Apoi reduceți cererea în loc să o apărați. Reduceți eșantionarea fluxului de observare, trimiteți rezumate sau delta, și lăsați datele brute ale senzorilor la bord, unde stocarea este ieftină, iar transmisia nu. Un payload mai mic slăbește argumentul pentru o legătură mai rapidă și de multe ori elimină nevoia de ea.

A treia condiție: cine trebuie să vadă și ce rămâne local

Observarea este de obicei o cerință mult mai mică decât procesarea. Dacă o persoană trebuie să privească camera și trebuie să existe un jurnal după aceea, aceasta este telemetrie plus stocare; dacă un model trebuie să ruleze, întrebați mai întâi dacă poate rula la bord cu doar rezultatul trimis mai departe. Mutarea pasului greu la bord elimină dependența sincronă și lasă un transfer care poate fi reîncercat.

Doi participanți ROS pe același robot nu justifică un tunel prin ei înșiși. Accesibilitatea nodurilor, autorizarea aplicației și un plan local de recuperare sunt probleme separate, iar un VPN răspunde doar primei, și doar pentru traficul pe care i se cere să îl ruteze.

Înregistrarea unui set de date este un proiect propriu, cu propriile comenzi

Pentru un exemplu legat de o versiune, tutorialul de înregistrare ROS 2 Jazzy acoperă înregistrarea subiectelor selectate, inspectarea bag-ului rezultat și redarea lui. Înregistrați subiectele de observare aprobate, dați un nume rulării și păstrați definițiile mesajelor și configurația alături.

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

Nu înregistrați fiecare subiect doar pentru că instrumentul face asta ușor. Spațiul de stocare se umple, datele de cameră și de locație sunt sensibile, iar un bag cu subiecte neetichetate este o problemă de analiză pentru cine îl deschide următorul. Distribuția instalată decide și comenzile: uneltele scrise pentru bag-uri ROS 1 nu se transferă la bag-uri ROS 2, așa că potriviți documentația cu versiunea instalată pe robot.

Redați într-un mediu izolat de analiză sau simulare. Redarea subiectelor de comandă înregistrate în actuatoarele unui robot viu este un accident, iar prevenirea este un domeniu ROS separat sau deloc hardware în buclă.

Decideți unde îi este locul dependenței și notați: un VPN protejează un schimb care trebuie să aibă loc, procesarea la bord elimină un schimb care nu a avut niciodată nevoie să fie sincron, iar un set de date înregistrat înlocuiește un consumator live cu unul ulterior. Apoi testați intenționat cazul deconectat, cu sarcina locală încă în funcțiune, înainte ca cineva să declare proiectul terminat.