Ĉu viva prilaborado aŭ registritaj datumoj: kion fakte bezonas VPN?
Decidu, kiu robota laboro devas transiri la reton: ĝustatempe rezultoj, observa telemetrio aŭ registrita datumaro. Tri kondiĉoj, poste la bag-komandoj.
Roboto, kiu ĉesas utili unu ĉambron for, havas problemon pri ligo aŭ pri laborŝarĝo longe antaŭ ol ĝi havas problemon pri VPN. Ĉifrado protektas vojon; ĝi ne etendas la radio-kovradon kaj ne igas malproksiman komputadon finiĝi pli frue. La decido antaŭ vi estas, kiu laboro vere devas transiri la reton, kaj tiu respondo kutime forigas pli da trafiko ol homoj atendas. Tri kondiĉoj decidas tion, kaj trafluo ne estas unu el ili.
Tri aranĝoj, unu demando pri dependeco
La tabelo apartigas la aranĝojn laŭ tio, kio dependas de la ligo, ne laŭ tio, kiu programaro aperas en la diagramo.
| 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 |
Neniu vico en tiu tabelo estas sekureca argumento. Regado kaj sekurecaj funkcioj ankoraŭ bezonas kvalifikitan respondon pri prokrasto, paketa perdo kaj interrompita konekto, kaj neniu tunela indikilo provizas ĝin. La tabelo diras, kie loĝas la dependeco, kaj tio estas la parto, kiun reta dezajno povas vere ŝanĝi.
Kondiĉo unua: ĉu la respondo devas esti ĝustatempa?
Se malproksima rezulto nutras regilon, la reto sidas ene de la regobuklo, kaj ĝia prokrasto, ĵitermovo kaj interrompoj fariĝas regaj ecoj. Se la sama rezulto nutras nur ekranon, panelon aŭ homon, kiu rigardas, la identa prokrasto estas kosmetika.
Fermitbukla laboro super sendrata ligo estas ebla, kaj ĝuste de tie venas la plej multaj raportoj «la VPN estas malrapida», ĉar la tunelo estas la videbla komponanto dum la radio kaj la enkursigado estas la kaŭzo. Mezuru la rondvojaĝon de la reala mesaĝo anstataŭ la pingon de la tunelo mem, kaj poste demandu, ĉu la nombro taŭgas por la buĝeto de la buklo. Kiam ĝi ne taŭgas, movu la paŝon sur la veturilon anstataŭ negoci pli striktan servan nivelon por ligo, kiun neniu en la ĉambro kontrolas. Registru la mezuritan nombron kun la kondiĉoj, sub kiuj ĝi estis prenita, ĉar la sekva raporto alvenos sen ili.
Kondiĉo dua: kiun rapidon, direkton kaj interrompon vi povas deklari?
Skribu la datumojn, la rapidon, la direkton kaj la plej longan interrompon, kiun la aplikaĵo toleras. Supreniranta kameraa fluo kaj malsupreniranta komanda kanalo malsukcesas diversmaniere, kaj interrompo, kiun senmova inspektado toleras, finigos moviĝantan taskon.
Tenu la fizikan konekton kaj la tunelon aparte, kiam vi komparas opciojn, ĉar pli forta radio kaj pli malgranda ŝarĝo estas malsamaj riparoj. Granda transigo, kiu finfine kompletiĝas, pruvas nenion pri ĝustatempa rezulto alvenanta konstante, kaj sana tunelo pruvas nenion pri la radio malantaŭ ĝi.
Poste reduktu la postulon anstataŭ defendi ĝin. Maldensigu la observan fluon, sendu resumojn aŭ deltojn, kaj lasu krudajn sensilajn datumojn sur la veturilo, kie stokado estas malmultekosta kaj transigo ne estas. Pli malgranda ŝarĝo malfortigas la argumenton por pli rapida ligo kaj ofte forigas la bezonon de ĝi.
Kondiĉo tria: kiu devas vidi ĝin, kaj kio restas loka
Observado estas kutime multe pli malgranda postulo ol prilaborado. Se homo devas rigardi la kameraon kaj registro devas ekzisti poste, tio estas telemetrio plus stokado; se modelo devas funkcii, unue demandu, ĉu ĝi povas funkcii sur la veturilo kun nur sia rezulto plusendata. Movi la pezan paŝon sur la veturilon forigas la sinkronan dependecon kaj lasas transigon, kiun oni povas ripeti.
Du ROS-partoprenantoj sur la sama roboto ne pravigas tunelon per si mem. Atingebleco de nodoj, permeso de aplikaĵo kaj loka riparplano estas apartaj problemoj, kaj VPN respondas nur al la unua, kaj nur por la trafiko, kiun oni petas ĝin enkursigi.
Registri datumaron estas propra dezajno, kun propraj komandoj
Por versie ligita ekzemplo, la lernilo pri registrado en ROS 2 Jazzy kovras registradon de elektitaj temoj, inspekton de la rezulta bag kaj ĝian reludon. Registru la aprobitajn observajn temojn, nomu la ruladon, kaj tenu la mesaĝdifinojn kaj la agordon apude.
ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42
Ne registru ĉiun temon nur ĉar la ilo faciligas tion. Stokado pleniĝas, kameraaj kaj lokaj datumoj portas senteblecon, kaj bag kun neetikeditaj temoj estas analiza problemo por tiu, kiu malfermos ĝin venontfoje. La disfaldita distribuo ankaŭ decidas la komandojn: iloj skribitaj por ROS 1-bag ne transiĝas al ROS 2-bag, do kongruigu la dokumentaron kun la versio instalita sur la roboto.
Reludu en izolita analiza aŭ simula medio. Reludi registritajn komandajn temojn en la aktuariojn de viva roboto estas akcidento, kaj la prevento estas aparta ROS-domajno aŭ tute neniu aparataro en la buklo.
Decidu, kie la dependeco apartenas, kaj skribu ĝin: VPN protektas interŝanĝon, kiu devas okazi, prilaborado sur la veturilo forigas interŝanĝon, kiu neniam bezonis esti sinkrona, kaj registrita datumaro anstataŭigas vivan konsumanton per posta. Poste testu la malkonektan kazon intence, dum la loka laboro ankoraŭ funkcias, antaŭ ol iu nomas la dezajnon finita.