Përpunim i drejtpërdrejtë apo të dhëna të regjistruara: për çfarë duhet vërtet VPN?
Vendosni cila punë e robotit duhet të kalojë rrjetin: rezultate në kohë, telemetri vëzhgimi apo një grup të dhënash i regjistruar. Tri kushte, pastaj komandat bag.
Një robot që pushon së qeni i dobishëm një dhomë larg ka një problem lidhjeje ose ngarkese pune shumë përpara se të ketë një problem VPN. Kriptimi mbron një rrugë, por nuk e zgjeron mbulimin radio dhe nuk e bën një llogaritje të largët të përfundojë më shpejt. Vendimi para jush është cila punë duhet vërtet të kalojë rrjetin, dhe ai përgjigje zakonisht heq më shumë trafik nga sa njerëzit presin. Këtë e vendosin tri kushte, dhe kapaciteti i transmetimit nuk është një prej tyre.
Tre rregullime, një pyetje varësie
Tabela i ndan rregullimet sipas asaj që varet nga lidhja, jo sipas asaj se cili software shfaqet në diagram.
| 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 |
Asnjë rresht në atë tabelë nuk është argument sigurie. Funksionet e kontrollit dhe të sigurisë ende kërkojnë një përgjigje të kualifikuar për vonesën, humbjen e paketave dhe një lidhje të ndërprerë, dhe asnjë tregues tuneli nuk e jep atë. Tabela tregon ku banon varësia, dhe pikërisht ajo është pjesa që një projekt rrjeti mund të ndryshojë vërtet.
Kushti i parë: a duhet përgjigja të jetë në kohë?
Nëse një rezultat i largët ushqen një kontrollues, rrjeti qëndron brenda ciklit të kontrollit, dhe vonesa, jitter-i dhe ndërprerjet e tij bëhen veti të kontrollit. Nëse i njëjti rezultat ushqen vetëm një ekran, një panel ose një person që shikon, vonesa identike është thjesht pamje.
Puna në cikël të mbyllur përmes një lidhjeje pa tela është e mundur, dhe pikërisht prej andej vijnë shumica e raportimeve "VPN-ja është e ngadaltë", sepse tuneli është komponenti i dukshëm, ndërsa radioja dhe rrugëtimi janë shkaku. Matni kohën e vajtjes e kthimit të mesazhit real, jo ping-un e vetë tunelit, pastaj pyesni nëse numri përshtatet në buxhetin e ciklit. Nëse nuk përshtatet, zhvendoseni hapin në bordin e vetë pajisjes në vend që të negocioni një nivel shërbimi më të rreptë për një lidhje që askush në dhomë nuk e kontrollon. Shënoni numrin e matur bashkë me kushtet në të cilat u mor, sepse raporti i radhës do të vijë pa ato.
Kushti i dytë: çfarë ritmi, drejtimi dhe ndërprerjeje mund të deklaroni?
Shkruani të dhënat, ritmin, drejtimin dhe ndërprerjen më të gjatë që aplikacioni toleron. Një rrjedhë kamere lart dhe një kanal komandash poshtë dështojnë në mënyra të ndryshme, dhe një ndërprerje që toleron një inspektim i palëvizshëm do të përfundojë një detyrë në lëvizje.
Kur krahasoni opsionet, mbani të ndara lidhjen fizike dhe tunelin, sepse një radio më e fortë dhe një ngarkesë pune më e vogël janë riparime të ndryshme. Një transferim i madh që përfundon më në fund nuk provon asgjë për një rezultat të ndjeshëm ndaj kohës që vjen vazhdimisht, dhe një tunel i shëndoshë nuk provon asgjë për radion pas tij.
Pastaj ulni kërkesën në vend që ta mbroni. Ulini kampionimin e rrjedhës së vëzhgimit, dërgoni përmbledhje ose delta, dhe lërini të dhënat e papërpunuara të sensorëve në bordin e pajisjes atje ku ruajtja është e lirë dhe transmetimi nuk është. Një ngarkesë më e vogël e dobëson argumentin për një lidhje më të shpejtë dhe shpesh e heq nevojën për të.
Kushti i tretë: kush duhet ta shohë dhe çfarë mbetet lokale
Vëzhgimi është zakonisht një kërkesë shumë më e vogël se përpunimi. Nëse një person duhet të shohë kamerën dhe më pas duhet të ekzistojë një regjistër, kjo është telemetri plus ruajtje; nëse një model duhet të ekzekutohet, pyesni së pari nëse mund të ekzekutohet në bordin e pajisjes me vetëm rezultatin e përcjellë. Zhvendosja e hapit të rëndë në bord heq varësinë sinkrone dhe lë një transferim që mund të përsëritet.
Dy pjesëmarrës ROS në të njëjtin robot nuk e justifikojnë një tunel në vetvete. Arritshmëria e nyjeve, autorizimi i aplikacionit dhe një plan rikuperimi lokal janë probleme të ndara, dhe një VPN i përgjigjet vetëm të parës, dhe vetëm për trafikun që i kërkohet të rrugëtojë.
Regjistrimi i një grupi të dhënash është projekt më vete, me komandat e veta
Për një shembull të lidhur me versionin, tutoriali i regjistrimit ROS 2 Jazzy mbulon regjistrimin e temave të zgjedhura, inspektimin e bag-ut që rezulton dhe riprodhimin e tij. Regjistroni temat e vëzhgimit të miratuara, jepini një emër ekzekutimit dhe mbani përkufizimet e mesazheve dhe konfigurimin pranë tij.
ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42
Mos regjistroni çdo temë vetëm sepse mjeti e bën të lehtë. Ruajtja mbushet, të dhënat e kamerës dhe të vendndodhjes mbartin ndjeshmëri, dhe një bag me tema pa etiketa është problem analize për këdo që e hap më pas. Distribucioni i instaluar vendos edhe komandat: mjetet e shkruara për bag të ROS 1 nuk transferohen në bag të ROS 2, prandaj përputhni dokumentacionin me versionin e instaluar në robot.
Riprodhoni në një mjedis të izoluar analize ose simulimi. Riprodhimi i temave të komandave të regjistruara në aktuatorët e një roboti të gjallë është aksident, dhe parandalimi është një domen ROS i veçantë ose aspak harduer në cikël.
Vendosni ku i takon varësisë dhe shkruajeni: një VPN mbron një shkëmbim që duhet të ndodhë, përpunimi në bord heq një shkëmbim që nuk duhej të ishte kurrë sinkron, dhe një grup të dhënash i regjistruar zëvendëson një konsumator të gjallë me një më të vonë. Pastaj provoni me qëllim rastin e shkëputur, ndërsa puna lokale vazhdon, përpara se dikush ta shpallë projektin të përfunduar.