Робот, който престава да е полезен на една стая разстояние, има проблем със свързаността или с натоварването много преди да има проблем с VPN. Шифроването защитава път; то не разширява радиопокритието и не кара отдалеченото изчисление да завърши по-рано. Решението пред вас е коя работа наистина трябва да премине през мрежата и този отговор обикновено премахва повече трафик, отколкото хората очакват. Три условия го решават и пропускната способност не е едно от тях.

Три подредби, един въпрос за зависимостта

Таблицата разделя подредбите по това какво зависи от връзката, а не по това кой софтуер се появява на диаграмата.

ArrangementWhat depends on the linkWhat stays onboard
Live remote processingThe exchange and any timely result the workstation returnsOnly what the remote step does not block
Onboard processing, remote observationThe declared telemetry or display streamThe processing loop itself
Local recording, later analysisTransfer of one selected datasetThe 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 защитава обмен, който трябва да се случи, обработката на борда премахва обмен, който никога не е трябвало да бъде синхронен, а записан набор от данни заменя живия потребител с по-късен. След това тествайте нарочно случая без връзка, докато локалната задача все още работи, преди някой да обяви дизайна за завършен.

Подобни статии