Live na Pagproseso o Naitalang Data: Ano Talaga ang Kailangan ng VPN?

Ang robot na hindi na kapaki-pakinabang isang kwarto ang layo ay may problema sa link o sa dami ng trabaho matagal bago ito magkaroon ng problema sa VPN. Pinoprotektahan ng encryption ang isang landas, ngunit hindi nito pinapalawak ang saklaw ng radyo at hindi nito pinapabilis ang pagtatapos ng malayong komputasyon. Ang desisyon sa harap mo ay kung aling trabaho ang tunay na kailangang tumawid sa network, at ang sagot na iyon ay karaniwang nag-aalis ng mas maraming trapiko kaysa inaasahan ng mga tao. Tatlong kondisyon ang nagpapasya nito, at ang throughput ay hindi isa sa mga iyon.

Tatlong kaayusan, isang tanong ng dependency

Hinihiwalay ng talahanayan ang mga kaayusan ayon sa nakadepende sa link, hindi ayon sa kung anong software ang nakikita sa diagram.

Walang hilera sa talahanayang iyon ang isang argumento sa kaligtasan. Ang mga tungkulin sa kontrol at kaligtasan ay nangangailangan pa rin ng kwalipikadong sagot para sa pagkaantala, pagkawala ng packet at naputol na koneksyon, at walang indicator ng tunnel ang nagbibigay niyon. Sinasabi ng talahanayan kung saan nakatira ang dependency, at iyon ang bahaging tunay na maaaring baguhin ng disenyo ng network.

Unang kondisyon: kailangan bang napapanahon ang sagot?

Kung ang malayong resulta ay nagpapakain sa isang controller, ang network ay nasa loob ng control loop, at ang pagkaantala, jitter at pagpalya nito ay nagiging katangian ng kontrol. Kung ang parehong resulta ay nagpapakain lamang sa isang display, dashboard o taong nanonood, ang parehong pagkaantala ay panggayak lamang.

Ang trabahong closed-loop sa isang wireless na link ay posible, at doon din nagmumula ang karamihan ng ulat na "mabagal ang VPN", dahil ang tunnel ang nakikitang bahagi habang ang radyo at routing ang dahilan. Sukatin ang round trip ng aktwal na mensahe at hindi ang ping ng tunnel mismo, pagkatapos itanong kung kasya ang bilang sa badyet ng loop. Kung hindi kasya, ilipat ang hakbang onboard sa halip na makipagnegosyo ng mas mahigpit na antas ng serbisyo para sa isang link na walang tao sa silid ang kumokontrol. Itala ang sinukat na bilang kasama ang mga kondisyon kung kailan ito kinuha, dahil darating ang susunod na ulat na wala ang mga iyon.

Ikalawang kondisyon: anong rate, direksyon at pagkaantala ang maaari mong ideklara?

Isulat ang data, ang rate, ang direksyon at ang pinakamahabang pagkaantala na kinakaya ng aplikasyon. Ang upstream na stream ng camera at ang downstream na channel ng utos ay nabibigo sa magkaibang paraan, at ang pagkaantala na kinakaya ng isang nakatigil na inspeksyon ay tatapos sa isang gumagalaw na gawain.

Panatilihing hiwalay ang pisikal na koneksyon at ang tunnel kapag naghahambing ng mga opsyon, dahil ang mas malakas na radyo at mas maliit na dami ng trabaho ay magkaibang pagkukumpuni. Ang malaking paglilipat na sa huli ay natatapos ay walang pinapatunayan tungkol sa resulta na sensitibo sa oras na dumarating nang tuloy-tuloy, at ang malusog na tunnel ay walang pinapatunayan tungkol sa radyong nasa likod nito.

Pagkatapos, bawasan ang pangangailangan sa halip na ipagtanggol ito. Bawasan ang sampling ng stream ng pagmamasid, magpadala ng buod o delta, at iwanan ang hilaw na data ng sensor onboard kung saan mura ang imbakan at hindi ang transmisyon. Ang mas maliit na payload ay nagpapahina sa argumento para sa mas mabilis na link at kadalasan ay nag-aalis ng pangangailangan para dito.

Ikatlong kondisyon: sino ang dapat makakita, at ano ang nananatiling lokal

Ang pagmamasid ay karaniwang mas maliit na pangangailangan kaysa sa pagproseso. Kung ang isang tao ay dapat manood ng camera at dapat may talaan pagkatapos, iyon ay telemetry at imbakan; kung ang isang modelo ay dapat tumakbo, itanong muna kung maaari itong tumakbo onboard na ang resulta lamang ang ipinapasa. Ang paglipat ng mabigat na hakbang onboard ay nag-aalis ng synchronous na dependency at nag-iiwan ng paglilipat na maaaring ulitin.

Ang pagkakaroon ng dalawang kalahok ng ROS sa isang robot ay hindi nagbibigay-katwiran sa isang tunnel nang mag-isa. Ang maabot ng node, awtorisasyon ng aplikasyon at lokal na plano sa pagbawi ay magkakaibang problema, at sinasagot ng VPN ang una lamang, at para lamang sa trapikong hinihiling na i-route nito.

Ang pagtatala ng dataset ay sarili nitong disenyo, may sariling mga utos

Para sa halimbawang nakatali sa bersyon, ang tutorial sa pagtatala ng ROS 2 Jazzy ay sumasaklaw sa pagtatala ng mga piling topic, pagsusuri ng nagawang bag at pag-play muli nito. Itala ang mga aprubadong topic ng pagmamasid, bigyan ng pangalan ang pagtakbo, at itago ang mga depinisyon ng mensahe at konfigurasyon sa tabi nito.

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

Huwag itala ang bawat topic dahil lang pinapadali ito ng tool. Napupuno ang imbakan, may sensitivity ang data ng camera at lokasyon, at ang bag ng mga topic na walang label ay problema sa pagsusuri para sa sinumang magbubukas nito sa susunod. Ang naka-install na distribusyon ang nagtatakda din ng mga utos: ang mga tool na isinulat para sa bag ng ROS 1 ay hindi lumilipat sa bag ng ROS 2, kaya itugma ang dokumentasyon sa bersyong naka-install sa robot.

I-play muli sa isang hiwalay na kapaligiran ng pagsusuri o simulation. Ang pag-play muli ng naitalang mga topic ng utos sa mga actuator ng buhay na robot ay aksidente, at ang pag-iwas ay isang hiwalay na ROS domain o walang hardware sa loop.

Magpasya kung saan nararapat ang dependency at isulat ito: pinoprotektahan ng VPN ang palitan na dapat mangyari, inaalis ng pagproseso onboard ang palitan na hindi kailanman kailangang maging synchronous, at pinapalitan ng naitalang dataset ang live na konsyumer ng mas huling konsyumer. Pagkatapos, sinasadya mong subukan ang naka-disconnect na kaso, habang tumatakbo pa ang lokal na trabaho, bago sabihin ng kahit sino na tapos na ang disenyo.