Жывая апрацоўка ці запісаныя даныя: што сапраўды патрабуе VPN?
Вызначце, якая праца робата павінна прайсці праз сетку: своечасовыя вынікі, тэлеметрыя назірання ці запісаны набор даных. Тры ўмовы, потым каманды bag.
Робат, які перастае быць карысным ужо праз пакой, мае праблему сувязі ці праблему нагрузкі задоўга да праблемы з VPN. Шыфраванне абараняе шлях; яно не пашырае радыёпакрыццё і не прымушае аддаленае вылічэнне скончыцца хутчэй. Рашэнне перад вамі — якая праца сапраўды павінна прайсці праз сетку, і гэты адказ звычайна прыбірае больш трафіку, чым чакаюць людзі. Гэта вырашаюць тры ўмовы, і прапускная здольнасць не адна з іх.
Тры ўладкаванні, адно пытанне пра залежнасць
Табліца раздзяляе ўладкаванні па тым, што залежыць ад сувязі, а не па тым, якое праграмнае забеспячэнне паказана на схеме.
| 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 |
Ні адзін радок у гэтай табліцы не з’яўляецца аргументам бяспекі. Функцыі кіравання і бяспекі ўсё яшчэ патрабуюць кваліфікаванага адказу наконт затрымкі, страты пакетаў і абрыву злучэння, і ні адзін індыкатар тунеля такога не дае. Табліца паказвае, дзе жыве залежнасць, а гэта якраз тое, што праект сеткі можа рэальна змяніць.
Умова першая: ці павінен адказ быць своечасовым?
Калі аддалены вынік корміць кантролер, сетка знаходзіцца ўнутры контуру кіравання, і яе затрымка, дрыжанне і перапынкі становяцца ўласцівасцямі кіравання. Калі ж той самы вынік корміць толькі дысплей, панэль або чалавека, які назірае, такая самая затрымка — чыста касметычная.
Праца з замкнёным контурам праз бясшротную сувязь магчымая, і менавіта адсюль паходзіць большасць скаргаў «VPN павольны», бо тунель — гэта бачны кампанент, а радыё і маршрутызацыя — прычына. Мерце час поўнага абароту фактычнага паведамлення, а не ўласны ping тунеля, і потым спытайце, ці ўпісваецца лік у бюджэт контуру. Калі не ўпісваецца, перанясіце крок на борт замест таго, каб вытаргоўваць больш строгі ўзровень абслугоўвання для сувязі, якую ніхто ў пакоі не кантралюе. Запішыце вымераны лік разам з умовамі, пры якіх ён атрыманы, бо наступная справаздача прыйдзе без іх.
Умова другая: якую хуткасць, кірунак і перапынак вы можаце заявіць?
Запішыце даныя, хуткасць, кірунак і найдоўгі перапынак, які вытрымлівае праграма. Паток камеры ўверх і канал каманд уніз адмаўляюць па-рознаму, і перапынак, які вытрымлівае нерухомая інспекцыя, скончыць рухомую задачу.
Трымайце фізічнае далучэнне і тунель асобна пры параўнанні варыянтаў, бо мацнейшае радыё і меншая нагрузка — гэта розныя рамонты. Вялікая перадача, якая ўрэшце завяршаецца, нічога не даказвае пра стабільнае прыходжанне выніку, адчувальнага да часу, а здаровы тунель нічога не даказвае пра радыё за ім.
Затым змяншайце попыт замест таго, каб яго абараняць. Прарэджвайце паток назірання, дасылайце зводкі або дэльты і пакідайце сырыя даныя датчыкаў на борце, дзе захоўванне таннае, а перадача — не. Меншая нагрузка аслабляе аргумент на карысць хутчэйшай сувязі і часта здымае патрэбу ў ёй.
Умова трэцяя: хто мусіць гэта бачыць, і што застаецца лакальным
Назіранне звычайна значна менш патрабавальнае, чым апрацоўка. Калі чалавек мусіць глядзець на камеру і пасля мусіць існаваць журнал, гэта тэлеметрыя плюс захоўванне; калі мусіць працаваць мадэль, спачатку спытайце, ці можа яна працаваць на борце з перадачай толькі свайго выніку. Перанос цяжкага кроку на борт здымае сінхронную залежнасць і пакідае перадачу, якую можна паўтарыць.
Два ўдзельнікі ROS на адным робаце не апраўдваюць тунель самі па сабе. Дасягальнасць вузла, аўтарызацыя праграмы і лакальны план аднаўлення — асобныя праблемы, і VPN адказвае толькі на першую, ды і то толькі для трафіку, які ён павінен маршрутызаваць.
Запіс набору даных — гэта асобны праект з уласнымі камандамі
Для прыкладу, прывязанага да версіі, падручнік па запісе ROS 2 Jazzy ахоплівае запіс выбраных тэм, праверку атрыманага bag і яго прайграванне. Запішыце зацверджаныя тэмы назірання, дайце запуску імя і трымайце вызначэнні паведамленняў і канфігурацыю побач.
ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42
Не запісвайце ўсе тэмы толькі таму, што інструмент гэта робіць лёгка. Сховішча запаўняецца, даныя камеры і месцазнаходжання нясуць адчувальнасць, а bag з непазначанымі тэмамі — гэта праблема аналізу для таго, хто адкрые яго наступным. Разгорнутая зборка таксама вызначае каманды: інструменты, напісаныя для bag ROS 1, не пераносяцца на bag ROS 2, таму ўзгадняйце дакументацыю з версіяй, усталяванай на робаце.
Прайгравайце ў ізаляваным асяроддзі аналізу або сімуляцыі. Прайграванне запісаных тэм каманд у прывады жывога робата — гэта аварыя, і прафілактыка — асобны дамен ROS або поўная адсутнасць абсталявання ў контуры.
Вызначце, дзе месца залежнасці, і запішыце гэта: VPN абараняе абмен, які мусіць адбыцца, апрацоўка на борце прыбірае абмен, якому ніколі не патрэбна была сінхроннасць, а запісаны набор даных замяняе жывога спажыўца пазнейшым. Потым свядома праверце сцэнар без сувязі, калі лакальная праца ўсё яшчэ ідзе, перш чым хтосьці назваве праект завершаным.