ROS 2 VPN-ით: აღმოჩენა მონაცემთა გზა არ არის

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

რას ატარებს აღმოჩენის სერვერი სინამდვილეში

Fast DDS-ში Discovery Server ანაწილებს ინფორმაციას ბოლო წერტილებზე: ვინ აქვეყნებს, ვინ იწერს და რომელ QoS-ს ელოდება თითოეული. მას შემდეგ რაც თანატოლები ერთმანეთს გაიცნობენ, მომხმარებლის მონაცემები პირდაპირ მათ შორის მოძრაობს და არა იმ სერვერის გავლით. სერვერამდე მისვლა ამტკიცებს, რომ გაცნობის შუამავალი პასუხობს, და მეტს არაფერს. მარშრუტიზებულ VPN-ს კვლავ სჭირდება მუშა გზა ორივე მიმართულებით იმ მისამართებს შორის, რომლებსაც თანატოლები აცხადებენ.

ეს განსხვავება ხსნის ნაწილობრივ უკმარისობებსაც, როცა არსებული თანატოლები მონაცემთა გაცვლას აგრძელებენ, ხოლო ახალი აღმოჩენა წყვეტს მუშაობას. განიხილეთ ისინი როგორც ორი ცალკეული გამოკვლევა.

წაიკითხეთ RMW, რომელსაც კვანძები რეალურად იყენებენ

ROS 2-ს შეუძლია სხვადასხვა შუამავალი პროგრამის ჩატვირთვა, და თქვენს გარსში ექსპორტირებული ცვლადი არ აღწევს სხვაგან გაშვებულ პროცესებამდე. ჰკითხეთ გაშვებულ სისტემას და არა ტერმინალის ისტორიას.

printenv RMW_IMPLEMENTATION
ros2 doctor --report | head -n 20

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

გამოსცადეთ აღმოჩენა და მონაცემები როგორც ორი შედეგი

აირჩიეთ უვნებელი თემა და გაზომეთ გაცნობა მიწოდებისგან ცალკე. ბრძანება info ჩამოთვლის ბოლო წერტილებს და QoS-ს, ხოლო echo ამტკიცებს, გადაკვეთს თუ არა ერთი შეტყობინება რეალურად კავშირს.

ros2 topic info /chatter --verbose
ros2 topic echo /chatter --once

info-ის გამოსავალში ბოლო წერტილების გამოჩენა აღმოჩენის შედეგია. შეტყობინების გამოწერილამდე მისვლა ტრანსპორტის შედეგია, და მხოლოდ მეორე ამოწმებს იმ გზას, რომელიც აპლიკაციას სჭირდება. როცა აღმოჩენა მუშაობს და echo დროში იწურება, გამოიკვლიეთ გამოცხადებული მისამართები და დაბრუნების მარშრუტი და არა აღმოჩენის სერვისი. გაუშვით ორივე ბრძანება თითოეული ჰოსტიდან, რადგან ასიმეტრიული VPN მარშრუტი ხშირად მხოლოდ ერთი მხრიდან ვლინდება.

შეცვალეთ ერთი დამოკიდებულება ყოველ ჯერზე

როცა მონაცემთა გზა ვერ მუშაობს, მოერიდეთ იმავე სესიაში შუამავალი პროგრამის, აღმოჩენის რეჟიმის და შეტყობინების ზომის შეცვლას, რადგან ამის შემდეგ ვერც ერთი შედეგი ვეღარ მიეწერება. Zenoh RMW ლეგიტიმური ალტერნატივაა, მაგრამ მისი მარშრუტიზატორი კიდევ ერთი დამოკიდებულება ხდება, რომელიც გვირაბით უნდა იყოს ხელმისაწვდომი.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

ამ RMW-ის ქვეშ მარშრუტიზატორი აღმოჩენას ატარებს Jazzy-ის ნაგულისხმევ განლაგებაში, და იქ multicast აღმოჩენა გამორთულია, ამიტომ დამოკიდებულება თქვენს შენიშვნებს ეკუთვნის და არა სხვა შუამავალი პროგრამიდან ნასესხებ ვარაუდს. შეინარჩუნეთ სამუშაო დატვირთვა უცვლელი, სანამ ერთ პარამეტრს ცვლით, შემდეგ გაიმეორეთ echo ტესტი და ჩაწერეთ მიმართულება, შეტყობინების სიხშირე და კავშირის პირობები. გაიმეორეთ შედარება ორჯერ, რათა რეალური გაუმჯობესება იღბლიანი ხელახალი დაკავშირებისგან გამოყოთ. თუ ცვლილება აუმჯობესებს აღმოჩენას, ხოლო მიწოდება იგივე რჩება, თქვენ გაცნობის სერვისი გადაიტანეთ და არა მონაცემთა გზა.