Tiešraides apstrāde vai ierakstīti dati: kam īsti vajadzīgs VPN?
Izlemiet, kurš robota darbs drīkst šķērsot tīklu: savlaicīgi rezultāti, novērojumu telemetrija vai ierakstīta datu kopa. Trīs nosacījumi, tad bag komandas.
Robotam, kas pārstāj būt noderīgs vienas telpas attālumā, saites vai darba apjoma problēma ir daudz agrāk nekā VPN problēma. Šifrēšana aizsargā ceļu, bet nepaplašina radio pārklājumu un nepadara attālo aprēķinu ātrāku. Lēmums jūsu priekšā ir par to, kurš darbs patiešām drīkst šķērsot tīklu, un šī atbilde parasti noņem vairāk trafika, nekā cilvēki gaida. To izšķir trīs nosacījumi, un caurlaidspēja nav viens no tiem.
Trīs izkārtojumi, viens atkarības jautājums
Tabula atdala izkārtojumus pēc tā, kas ir atkarīgs no saites, nevis pēc tā, kura programmatūra parādās diagrammā.
| 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 |
Neviena šīs tabulas rinda nav drošības arguments. Vadības un drošības funkcijām joprojām vajadzīga kvalificēta atbilde par aizkavēšanos, pakešu zudumu un pārtrauktu savienojumu, un neviens tuneļa indikators to nesniedz. Tabula parāda, kur atrodas atkarība, un tieši šo daļu tīkla projektējums var reāli mainīt.
Pirmais nosacījums: vai atbildei jābūt savlaicīgai?
Ja attālais rezultāts nonāk kontrolierī, tīkls atrodas vadības cilpas iekšpusē, un tā aizkavēšanās, džiteris un pārtraukumi kļūst par vadības īpašībām. Ja tas pats rezultāts nonāk tikai displejā, panelī vai to vērojošā cilvēkā, identiska aizkavēšanās ir tikai āriene.
Slēgtas cilpas darbs pa bezvadu saiti ir iespējams, un tieši no šejienes nāk lielākā daļa ziņojumu „VPN ir lēns“, jo tunelis ir redzamā sastāvdaļa, bet cēlonis ir radio un maršrutēšana. Mēriet īstās ziņas aprites laiku, nevis paša tuneļa ping, tad jautājiet, vai skaitlis iekļaujas cilpas budžetā. Ja neiekļaujas, pārvietojiet soli uz borta datoru, nevis risiniet pārrunas par stingrāku pakalpojuma līmeni saitei, ko telpā neviens nekontrolē. Pierakstiet izmērīto skaitli kopā ar apstākļiem, kādos tas iegūts, jo nākamais ziņojums pienāks bez tiem.
Otrais nosacījums: kādu ātrumu, virzienu un pārtraukumu jūs varat deklarēt?
Pierakstiet datus, ātrumu, virzienu un garāko pārtraukumu, ko lietojumprogramma pieļauj. Augšupvērstā kameras straume un lejupvērstais komandu kanāls sabojājas dažādi, un pārtraukums, ko pieļauj stacionāra pārbaude, izbeigs kustīgu uzdevumu.
Salīdzinot variantus, turiet fizisko pieslēgumu un tuneli atsevišķi, jo jaudīgāks radio un mazāks darba apjoms ir dažādi remonti. Liels pārsūtījums, kas beidzot pabeidzas, neko nepierāda par laikjutīga rezultāta pastāvīgu ierašanos, un veselīgs tunelis neko nepierāda par radio aiz tā.
Tad samaziniet pieprasījumu, nevis aizstāviet to. Samaziniet novērojumu straumes izšķirtspēju, sūtiet kopsavilkumus vai deltas, un neapstrādātos sensoru datus atstājiet bortā, kur glabāšana ir lēta, bet pārraide nav. Mazāks datu apjoms vājina argumentu par ātrāku saiti un bieži vien novērš vajadzību pēc tās.
Trešais nosacījums: kam tas jāredz un kas paliek lokāli
Novērošana parasti ir daudz mazāka prasība nekā apstrāde. Ja cilvēkam jāskatās kamera un pēc tam jābūt žurnālam, tā ir telemetrija plus glabāšana; ja modelim jādarbojas, vispirms jautājiet, vai tas var darboties bortā un pārsūtīt tikai savu rezultātu. Smagā soļa pārvietošana uz bortu novērš sinhrono atkarību un atstāj pārsūtījumu, ko var atkārtot.
Divi ROS dalībnieki vienā robotā paši par sevi neattaisno tuneli. Mezglu sasniedzamība, lietojumprogrammas autorizācija un vietējais atjaunošanas plāns ir atsevišķas problēmas, un VPN atbild tikai uz pirmo, un tikai par to trafiku, kuram to lūdz maršrutēt.
Datu kopas ierakstīšana ir atsevišķs projekts ar savām komandām
Versijai piesaistītam piemēram, ROS 2 Jazzy ierakstīšanas apmācība aptver atlasītu tēmu ierakstīšanu, iegūtā bag pārbaudi un tā atskaņošanu. Ierakstiet apstiprinātās novērojumu tēmas, piešķiriet palaidumam nosaukumu un turiet ziņojumu definīcijas un konfigurāciju tam blakus.
ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42
Neierakstiet visas tēmas tikai tāpēc, ka rīks to atvieglo. Krātuve piepildās, kameras un atrašanās vietas dati ir jutīgi, un bag ar neatzīmētām tēmām ir analīzes problēma tam, kas to atvērs nākamreiz. Izvietotā distribūcija nosaka arī komandas: rīki, kas rakstīti ROS 1 bag, nepāriet uz ROS 2 bag, tāpēc saskaņojiet dokumentāciju ar robotā instalēto versiju.
Atskaņojiet izolētā analīzes vai simulācijas vidē. Ierakstītu komandu tēmu atskaņošana dzīva robota izpildmehānismos ir negadījums, un profilakse ir atsevišķs ROS domēns vai vispār nekāda aparatūra cilpā.
Izlemiet, kur atkarība pieder, un pierakstiet to: VPN aizsargā apmaiņu, kurai jānotiek, apstrāde bortā novērš apmaiņu, kurai nevajadzēja būt sinhronai, un ierakstīta datu kopa aizstāj tiešu patērētāju ar vēlāku. Tad apzināti pārbaudiet atvienoto gadījumu, kamēr vietējais darbs vēl darbojas, pirms kāds nosauc projektu par pabeigtu.