VPN ಮೂಲಕ ROS 2: ಶೋಧನೆ ಡೇಟಾ ಮಾರ್ಗವಲ್ಲ

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 ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಶೋಧನೆಯನ್ನು ಸಾಗಿಸುತ್ತದೆ, ಮತ್ತು ಅಲ್ಲಿ ಮಲ್ಟಿಕಾಸ್ಟ್ ಶೋಧನೆ ನಿಷ್ಕ್ರಿಯವಾಗಿದೆ, ಆದ್ದರಿಂದ ಅವಲಂಬನೆ ಬೇರೆ ಮಿಡಲ್ವೇರ್ನಿಂದ ಎರವಲು ಪಡೆದ ಊಹೆಯಲ್ಲ, ನಿಮ್ಮ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿರಬೇಕು. ಒಂದು ಸೆಟ್ಟಿಂಗ್ ಬದಲಿಸುವಾಗ ವರ್ಕ್ಲೋಡ್ ಸ್ಥಿರವಾಗಿರಿಸಿ, ನಂತರ echo ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ ದಿಕ್ಕು, ಸಂದೇಶ ದರ ಮತ್ತು ಲಿಂಕ್ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ದಾಖಲಿಸಿ. ನಿಜವಾದ ಸುಧಾರಣೆಯನ್ನು ಅದೃಷ್ಟದ ಮರುಸಂಪರ್ಕದಿಂದ ಪ್ರತ್ಯೇಕಿಸಲು ಹೋಲಿಕೆಯನ್ನು ಎರಡು ಬಾರಿ ಚಲಾಯಿಸಿ. ಬದಲಾವಣೆಯು ಶೋಧನೆಯನ್ನು ಸುಧಾರಿಸಿ ವಿತರಣೆ ಹಾಗೆಯೇ ಉಳಿದರೆ, ನೀವು ಪರಿಚಯ ಸೇವೆಯನ್ನು ಸರಿಸಿದ್ದೀರಿ, ಡೇಟಾ ಮಾರ್ಗವನ್ನಲ್ಲ.