ROS 2 ผ่าน VPN: การค้นหาไม่ใช่เส้นทางข้อมูล

โหนด ROS 2 สองโหนดที่ปลายสองข้างของ VPN สามารถแสดงรายการหัวข้อของกันและกันได้ แต่ก็ยังส่งข้อความไม่ได้แม้แต่ข้อความเดียว การค้นหาและข้อมูลผู้ใช้เป็นการแลกเปลี่ยนแยกกันโดยมีเส้นทางแยกกัน และเซิร์ฟเวอร์ค้นหาไม่ได้ส่งต่อเพย์โหลด การตรวจสอบอย่างหนึ่งแล้วสันนิษฐานอีกอย่างคือสาเหตุที่ทีมเปลี่ยนมิดเดิลแวร์ทั้งที่อุโมงค์ไม่เคยนำข้อมูลไปเลย ขั้นตอนด้านล่างแยกผลลัพธ์สองอย่างออกจากกันก่อนจะเปลี่ยนอะไร

เซิร์ฟเวอร์ค้นหาพาไปจริง ๆ อะไร

ใน 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 ซ้ำและบันทึกทิศทาง อัตราข้อความ และสภาพลิงก์ เรียกใช้การเปรียบเทียบสองครั้งเพื่อแยกการปรับปรุงจริงจากการเชื่อมต่อใหม่ที่โชคดี หากการเปลี่ยนแปลงปรับปรุงการค้นหาในขณะที่การส่งมอบยังเหมือนเดิม คุณได้ย้ายบริการแนะนำ ไม่ใช่เส้นทางข้อมูล