Tiesioginis apdorojimas ar įrašyti duomenys: kam iš tikrųjų reikia VPN?
Nuspręskite, kuris roboto darbas turi kirsti tinklą: savalaikiai rezultatai, stebėjimo telemetrija ar įrašytas duomenų rinkinys. Trys sąlygos, tada bag komandos.
Robotas, kuris nustoja būti naudingas už vieno kambario, turi ryšio ar darbo krūvio problemą daug anksčiau, nei atsiranda VPN problema. Šifravimas apsaugo kelią, bet nepratęsia radijo aprėpties ir nepadaro, kad nuotolinis skaičiavimas baigtųsi greičiau. Sprendimas priešais jus yra tai, kuris darbas tikrai turi kirsti tinklą, ir šis atsakymas paprastai pašalina daugiau srauto, nei žmonės tikisi. Tai nusprendžia trys sąlygos, ir pralaidumas nėra viena iš jų.
Trys išdėstymai, vienas priklausomybės klausimas
Lentelė skiria išdėstymus pagal tai, kas priklauso nuo ryšio, o ne pagal tai, kokia programinė įranga matoma schemoje.
| Arrangement | What depends on the link | What stays onboard |
|---|---|---|
| Live remote processing | The exchange and any timely result the workstation returns | Only what the remote step does not block |
| Onboard processing, remote observation | The declared telemetry or display stream | The processing loop itself |
| Local recording, later analysis | Transfer of one selected dataset | The entire run, including raw sensors |
Nė viena šios lentelės eilutė nėra saugos argumentas. Valdymo ir saugos funkcijoms vis dar reikia kvalifikuoto atsakymo dėl vėlavimo, paketų praradimo ir nutrūkusio ryšio, o joks tunelio indikatorius jo nepateikia. Lentelė parodo, kur gyvena priklausomybė, ir būtent tą dalį tinklo projektas gali realiai pakeisti.
Pirma sąlyga: ar atsakymas turi būti savalaikis?
Jei nuotolinis rezultatas tiekiamas valdikliui, tinklas yra valdymo ciklo viduje, o jo vėlavimas, dreifas ir sutrikimai tampa valdymo savybėmis. Jei tas pats rezultatas tiekiamas tik ekranui, prietaisų skydeliui ar stebinčiam žmogui, toks pat vėlavimas yra tik vaizdas.
Uždaro ciklo darbas belaidžiu ryšiu yra įmanomas, ir būtent iš čia kyla dauguma „VPN lėtas“ pranešimų, nes tunelis yra matomas komponentas, o priežastis yra radijas ir maršrutizavimas. Matuokite tikrojo pranešimo kelionės laiką, o ne paties tunelio ping, tada paklauskite, ar skaičius telpa į ciklo biudžetą. Jei netelpa, perkelkite žingsnį į borto kompiuterį, o ne derėkitės dėl griežtesnio paslaugos lygio ryšiui, kurio kambaryje niekas nekontroliuoja. Užrašykite išmatuotą skaičių kartu su sąlygomis, kuriomis jis buvo gautas, nes kitas pranešimas atvyks be jų.
Antra sąlyga: kokį greitį, kryptį ir pertrauką galite deklaruoti?
Užrašykite duomenis, greitį, kryptį ir ilgiausią pertrauką, kurią programa toleruoja. Aukštyn krypties kameros srautas ir žemyn krypties komandų kanalas sugenda skirtingai, o pertrauka, kurią toleruoja stacionari patikra, užbaigs judančią užduotį.
Lygindami variantus laikykite fizinį prijungimą ir tunelį atskirai, nes galingesnis radijas ir mažesnis darbo krūvis yra skirtingi remontai. Didelis perdavimas, kuris galiausiai baigiasi, nieko neįrodo apie laiko atžvilgiu jautraus rezultato pastovų atėjimą, o sveikas tunelis nieko neįrodo apie radiją už jo.
Tada sumažinkite poreikį, o ne ginkite jį. Sumažinkite stebėjimo srauto tankį, siųskite suvestines arba delta reikšmes, o neapdorotus jutiklių duomenis palikite borte, kur saugojimas pigus, o perdavimas ne. Mažesnis duomenų kiekis susilpnina argumentą už greitesnį ryšį ir dažnai pašalina jo poreikį.
Trečia sąlyga: kas turi tai matyti ir kas lieka vietoje
Stebėjimas paprastai yra daug mažesnis reikalavimas nei apdorojimas. Jei žmogus turi stebėti kamerą ir vėliau turi likti žurnalas, tai telemetrija ir saugojimas; jei modelis turi veikti, pirmiausia paklauskite, ar jis gali veikti borte ir persiųsti tik savo rezultatą. Sunkaus žingsnio perkėlimas į bortą pašalina sinchroninę priklausomybę ir palieka perdavimą, kurį galima kartoti.
Du ROS dalyviai tame pačiame robote patys savaime nepateisina tunelio. Mazgų pasiekiamumas, programos autorizacija ir vietinis atkūrimo planas yra atskiros problemos, o VPN atsako tik į pirmąją ir tik už tą srautą, kurį prašoma maršrutizuoti.
Duomenų rinkinio įrašymas yra atskiras projektas su savo komandomis
Su versija susietam pavyzdžiui, ROS 2 Jazzy įrašymo pamoka apima pasirinktų temų įrašymą, gauto bag patikrinimą ir jo atkūrimą. Įrašykite patvirtintas stebėjimo temas, pavadinkite paleidimą ir laikykite pranešimų apibrėžimus bei konfigūraciją šalia jo.
ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42Neįrašykite visų temų vien todėl, kad įrankis tai palengvina. Vieta užsipildo, kameros ir vietos duomenys yra jautrūs, o bag su nepaženklintomis temomis yra analizės problema tam, kas jį atidarys kitas. Įdiegta distribucija taip pat nulemia komandas: įrankiai, parašyti ROS 1 bag, neperkeliami į ROS 2 bag, todėl dokumentaciją derinkite prie robote įdiegtos versijos.
Atkurkite izoliuotoje analizės ar modeliavimo aplinkoje. Įrašytų komandų temų atkūrimas į gyvo roboto pavaras yra avarija, o prevencija yra atskiras ROS domenas arba visiškai jokios techninės įrangos cikle.
Nuspręskite, kur priklausomybė priklauso, ir užrašykite: VPN apsaugo mainus, kurie turi įvykti, apdorojimas borte pašalina mainus, kuriems nereikėjo būti sinchroniniams, o įrašytas duomenų rinkinys pakeičia tiesioginį vartotoją vėlesniu. Tada sąmoningai išbandykite atsijungimo atvejį, kai vietinė užduotis vis dar veikia, prieš kam nors pavadinant projektą baigtu.