Обработка на живо или записани данни: какво наистина се нуждае от 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 защитава обмен, който трябва да се случи, обработката на борда премахва обмен, който никога не е трябвало да бъде синхронен, а записан набор от данни заменя живия потребител с по-късен. След това тествайте нарочно случая без връзка, докато локалната задача все още работи, преди някой да обяви дизайна за завършен.