Вашата работна станица стигнува до master на ROS 1 преку тунелот, а сепак прикажува празна листа со теми. Овој образец е чест бидејќи регистрацијата во master и преносот на теми се два различни разговора, и само првиот поминува низ master. Контролната листа подолу го поминува вториот разговор: крајната точка што ја објавува издавачот, адресата до која претплатникот мора да стигне и дозволата што им овозможува на двајцата да разговараат. Сѐ овде се однесува само на стариот ROS 1, чијшто прозорец за поддршка на Noetic заврши во мај 2025.

Чекор 1: докажете дека врската со master не е врската со темата

Започнете со одвојување на тоа што работи од тоа што не работи. Успешен rostopic list докажува дека вашата школка стигнува до портот XMLRPC на master и дека master знае за темите; тоа не кажува ништо за тоа дали претплатникот може да стигне до издавачот. Трите команди подолу ја прават таа разлика видлива, и сите се само за читање.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

Излезот од rostopic info го именува URI на јазолот на издавачот, што е XMLRPC адреса на домаќинот на издавачот. Таа адреса е онаа што вашиот претплатник ќе ја повика следно, па мора да биде достапна од каде и да работи претплатникот. Ако покажува на интерфејс што постои само на LAN мрежата на самиот робот, пребарувањето во master успева, а податоците никогаш не пристигнуваат.

Чекор 2: прочитајте ја објавената крајна точка од самиот јазол

ROS 1 го избира својот објавен идентитет на домаќин од ROS_IP или ROS_HOSTNAME кога еден од нив е поставен, а инаку се враќа на сопственото разрешување на имиња на домаќинот. Прегледајте ја околината на процесот што навистина е стартуван, бидејќи systemd единица, контејнер или втор терминал можат да носат различна вредност од школката во која вашиот тест работеше.

echo "$ROS_IP" "$ROS_HOSTNAME"
rosnode info /talker
getent hosts robot-host

Објавувањето на име на домаќин работи само ако секој партнер го разреши тоа име на предвидената достапна адреса. Ако тоа име се разрешува само во сопствената мрежа на роботот, работната станица од другата страна на тунелот нема никаков начин да го искористи, а VPN што не турка никаков DNS суфикс ја прави неусогласеноста уште полоша. Кога топологијата е рутирана, поставувањето на ROS_IP на адресата на тунелот е помала промена. Што и да изберете, запишете го за двата краја, бидејќи издавач и претплатник што не се согласуваат за идентитетот ќе преговараат и потоа нема да можат да се поврзат.

Запрете тука ако објавениот URI користи адреса до која ниту еден партнер не може да рутира. Никаква работа на огнениот ѕид нема да поправи име што се разрешува на погрешниот интерфејс.

Чекор 3: направете ја објавената адреса разложна и рутирана

Со URI во рака, тестирајте достапност од домаќинот на претплатникот, а не од роботот. Портот TCPROS се избира за време на преговорите, па корисниот ран тест е портот XMLRPC, а корисниот подоцнежен тест е воспоставениот сокет. Рута што постои само во една насока е честа дефект на рутирани VPN, и повратниот пат е исто толку важен како патот напред.

ip route get 10.70.0.2
nc -vz 10.70.0.2 33911
ss -tnp dst 10.70.0.2

Рутираниот TUN интерфејс ги пренесува овие IP разговори без да го прошири Ethernet сегментот на роботот, што обично е она што го сака далечински оператор. Ако нешто во стекот зависи наместо тоа од broadcast или multicast, тој услов мора да се оцени одделно; претворањето на тунелот во TAP за да се задоволи една алатка го проширува мрежата за секој учесник.

Запрете тука ако рутата или повратниот пат недостасува. Издавач што одговара на сопствениот домаќин, но не е достапен од работната станица, има проблем со рутирање, а не проблем со ROS.

Чекор 4: дозволете разговорот меѓу партнерите и набљудувајте една тема

Отворете ги само портовите што му се потребни на договорениот разговор, и ограничете го секое правило на објавените учесници. Слушачот на master не е реле за товарот на темите, па дозволата само за него го остава крајот на издавачот затворен. Држете ги слушачите на ROS на границата на приватниот VPN наместо да ги изложувате на јавниот интернет.

rostopic hz /chatter
rostopic echo -n1 /chatter
rosnode ping /talker

Набљудувајте една безопасна тема од вистинскиот издавач до вистинскиот претплатник и потврдете ја и објавената крајна точка и патот на одговорот. Една порака докажува дека патот работи; стабилна честота докажува дека тој останува отворен. Држете го управувањето со извршните уреди и безбедносните проверки надвор од овој тест што се однесува само на мрежата, бидејќи работна тема не сертифицира работен робот. Запишете ја верзијата на ROS и парот крајни точки што ги набљудувавте, за да може следната личност да разликува промена на топологијата од регресија.

Контролната листа е завршена кога објавениот URI е достапен од претплатникот, договорениот порт е отворен само за тој партнер, една објавена тема тече и вредностите на околината се запишани за двата домаќини. Стариот ROS 1 нема да добива исправки во оваа област, па записот е делот што продолжува да работи откако луѓето ќе се сменат.

Поврзани статии