ROS 1-ის თემები VPN-ის გავლით: მიჰყევით გამოცხადებულ საბოლოო წერტილს

თქვენი სამუშაო სადგური გვირაბის გავლით აღწევს ROS 1-ის master-ს და მაინც აჩვენებს თემების ცარიელ სიას. ეს ნიმუში გავრცელებულია, რადგან master-ში რეგისტრაცია და თემების გადაცემა ორი განსხვავებული საუბარია, და master-ის გავლით მხოლოდ პირველი გადის. ქვემოთ მოცემული სია გადის მეორე საუბარს: საბოლოო წერტილი, რომელსაც გამომქვეყნებელი აცხადებს, მისამართი, რომელზეც გამომწერი უნდა მივიდეს, და ნებართვა, რომელიც წყვილს საუბრის საშუალებას აძლევს. აქ ყველაფერი ეხება მხოლოდ ძველ ROS 1-ს, რომლის Noetic-ის მხარდაჭერის ფანჯარა 2025 წლის მაისში დასრულდა.

ნაბიჯი 1: დაამტკიცეთ, რომ master-ის კავშირი თემის კავშირი არ არის

დაიწყეთ იმის გამოყოფით, რაც მუშაობს, იმისგან, რაც არ მუშაობს. წარმატებული rostopic list ამტკიცებს, რომ თქვენი shell აღწევს master-ის XMLRPC პორტს და რომ master-მა იცის თემები; ის არაფერს ამბობს იმაზე, შეუძლია თუ არა გამომწერს გამომქვეყნებლამდე მისვლა. ქვემოთ მოცემული სამი ბრძანება ამ სხვაობას თვალსაჩინოს ხდის, და ყველა მხოლოდ წაკითხვისთვისაა.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

rostopic info-ის გამომავალი ასახელებს გამომქვეყნებლის კვანძის URI-ს, რომელიც XMLRPC მისამართია გამომქვეყნებლის ჰოსტზე. ეს მისამართია ის, რასაც თქვენი გამომწერი შემდეგ გამოიძახებს, ამიტომ ის უნდა იყოს მისაწვდომი ყველგან, სადაც გამომწერი მუშაობს. თუ ის მიუთითებს ინტერფეისზე, რომელიც მხოლოდ თავად რობოტის LAN-ში არსებობს, master-ის ძებნა წარმატებით სრულდება და მონაცემები არასდროს ჩამოდის.

ნაბიჯი 2: წაიკითხეთ გამოცხადებული საბოლოო წერტილი თავად კვანძიდან

ROS 1 თავის გამოცხადებულ ჰოსტის იდენტობას ირჩევს ROS_IP-იდან ან ROS_HOSTNAME-იდან, როცა ერთ-ერთი მათგანი დაყენებულია, ხოლო სხვა შემთხვევაში უბრუნდება თავად ჰოსტის სახელის გარჩევას. შეამოწმეთ რეალურად გაშვებული პროცესის გარემო, რადგან systemd ერთეულს, კონტეინერს ან მეორე ტერმინალს შეიძლება ჰქონდეს განსხვავებული მნიშვნელობა, ვიდრე იმ shell-ს, სადაც თქვენი ტესტი მუშაობდა.

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

ჰოსტის სახელის გამოცხადება მუშაობს მხოლოდ მაშინ, როცა ყველა პარტნიორი ამ სახელს გადააქცევს განზრახ მისაწვდომ მისამართად. თუ ეს სახელი მხოლოდ რობოტის საკუთარი ქსელის შიგნით გარჩევადია, გვირაბის მეორე მხარეს მდგარ სამუშაო სადგურს მისი გამოყენების არავითარი გზა არ აქვს, და VPN, რომელიც არავითარ DNS სუფიქსს არ უბიძგებს, შეუსაბამობას კიდევ უფრო აუარესებს. როცა ტოპოლოგია მარშრუტიზებულია, ROS_IP-ის გვირაბის მისამართზე დაყენება უფრო მცირე ცვლილებაა. რასაც არ უნდა აირჩიოთ, ჩაწერეთ ის ორივე ბოლოსთვის, რადგან იდენტობაზე შეუთანხმებელი გამომქვეყნებელი და გამომწერი მოლაპარაკებას აწარმოებს და შემდეგ ვერ დაუკავშირდება.

აქ გაჩერდით, თუ გამოცხადებული URI იყენებს მისამართს, რომელზეც ვერც ერთი პარტნიორი ვერ გაატარებს მარშრუტს. firewall-ის არც არავითარი მუშაობა არ გამოასწორებს სახელს, რომელიც არასწორ ინტერფეისზე გარჩევადია.

ნაბიჯი 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 ამ სფეროში შესწორებებს აღარ მიიღებს, ამიტომ ჩანაწერი ის ნაწილია, რომელიც ხალხის შეცვლის შემდეგაც აგრძელებს მუშაობას.