VPN ਰਾਹੀਂ ROS 1 ਵਿਸ਼ੇ: ਘੋਸ਼ਿਤ ਅੰਤ ਬਿੰਦੂ ਦਾ ਪਾਲਣ ਕਰੋ
ROS 1 master ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਵਿਸ਼ਾ ਡੇਟਾ ਨਹੀਂ ਲੈ ਜਾਂਦੀ। ਘੋਸ਼ਿਤ ਨੋਡ URI ਪੜ੍ਹੋ, ਉਸ ਪਤੇ ਨੂੰ ਰੂਟ ਕਰਨ ਯੋਗ ਬਣਾਓ, ਫਿਰ ਪ੍ਰਕਾਸ਼ਕ ਦਾ ਪੋਰਟ ਮਨਜ਼ੂਰ ਕਰੋ।
ਤੁਹਾਡਾ ਵਰਕਸਟੇਸ਼ਨ ਸੁਰੰਗ ਰਾਹੀਂ ROS 1 master ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਵਿਸ਼ਿਆਂ ਦੀ ਸੂਚੀ ਖਾਲੀ ਦਿਖਾਉਂਦਾ ਹੈ। ਇਹ ਪੈਟਰਨ ਆਮ ਹੈ ਕਿਉਂਕਿ master ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਅਤੇ ਵਿਸ਼ਾ ਢੋਆ-ਢੁਆਈ ਦੋ ਵੱਖਰੀਆਂ ਗੱਲਬਾਤਾਂ ਹਨ, ਅਤੇ master ਰਾਹੀਂ ਸਿਰਫ਼ ਪਹਿਲੀ ਲੰਘਦੀ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀ ਜਾਂਚ-ਸੂਚੀ ਦੂਜੀ ਗੱਲਬਾਤ ਰਾਹੀਂ ਲੰਘਦੀ ਹੈ: ਪ੍ਰਕਾਸ਼ਕ ਵੱਲੋਂ ਘੋਸ਼ਿਤ ਅੰਤ ਬਿੰਦੂ, ਉਹ ਪਤਾ ਜਿੱਥੇ ਗਾਹਕ ਨੂੰ ਪਹੁੰਚਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਹ ਮਨਜ਼ੂਰੀ ਜੋ ਦੋਵਾਂ ਨੂੰ ਬੋਲਣ ਦਿੰਦੀ ਹੈ। ਇੱਥੇ ਸਭ ਕੁਝ ਸਿਰਫ਼ ਪੁਰਾਣੇ ROS 1 ਲਈ ਹੈ, ਜਿਸਦੀ Noetic ਸਹਾਇਤਾ ਮਿਆਦ ਮਈ 2025 ਵਿੱਚ ਖ਼ਤਮ ਹੋਈ।
ਕਦਮ 1: ਸਾਬਤ ਕਰੋ ਕਿ master ਕਨੈਕਸ਼ਨ ਵਿਸ਼ਾ ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਹੈ
ਕੀ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ, ਇਸਨੂੰ ਵੱਖ ਕਰਕੇ ਸ਼ੁਰੂ ਕਰੋ। ਸਫਲ rostopic list ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਸ਼ੈੱਲ 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 ਇਕਾਈ, ਕੰਟੇਨਰ ਜਾਂ ਦੂਜਾ ਟਰਮੀਨਲ ਤੁਹਾਡੀ ਜਾਂਚ ਜਿਸ ਸ਼ੈੱਲ ਵਿੱਚ ਚੱਲੀ ਸੀ ਉਸ ਤੋਂ ਵੱਖਰਾ ਮੁੱਲ ਲੈ ਸਕਦਾ ਹੈ।
echo "$ROS_IP" "$ROS_HOSTNAME"
rosnode info /talker
getent hosts robot-host
ਹੋਸਟਨਾਮ ਘੋਸ਼ਣਾ ਸਿਰਫ਼ ਤਦ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਹਰ ਪੀਅਰ ਉਸ ਨਾਂ ਨੂੰ ਲੋੜੀਂਦੇ ਪਹੁੰਚਯੋਗ ਪਤੇ ਉੱਤੇ ਹੱਲ ਕਰਦਾ ਹੈ। ਜੇ ਉਹ ਨਾਂ ਸਿਰਫ਼ ਰੋਬੋਟ ਦੇ ਆਪਣੇ ਨੈੱਟਵਰਕ ਅੰਦਰ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਸੁਰੰਗ ਦੇ ਦੂਜੇ ਪਾਸੇ ਦੇ ਵਰਕਸਟੇਸ਼ਨ ਕੋਲ ਇਸਨੂੰ ਵਰਤਣ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ, ਅਤੇ ਕੋਈ DNS ਪਿਛੇਤਰ ਨਾ ਧੱਕਣ ਵਾਲਾ VPN ਉਸ ਅਸੰਗਤੀ ਨੂੰ ਹੋਰ ਮਾੜਾ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਟੋਪੋਲੋਜੀ ਰੂਟ ਕੀਤੀ ਹੋਵੇ ਤਾਂ 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 ਇੰਟਰਫ਼ੇਸ ਰੋਬੋਟ ਦੇ Ethernet ਹਿੱਸੇ ਨੂੰ ਵਧਾਏ ਬਿਨਾਂ ਇਹ IP ਗੱਲਬਾਤਾਂ ਢੋਂਦਾ ਹੈ, ਜੋ ਆਮ ਤੌਰ ਉੱਤੇ ਦੂਰਸਥ ਆਪਰੇਟਰ ਚਾਹੁੰਦਾ ਹੈ। ਜੇ ਸਟੈਕ ਵਿੱਚ ਕੁਝ ਇਸਦੀ ਥਾਂ ਬ੍ਰਾਡਕਾਸਟ ਜਾਂ multicast ਉੱਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ ਉਹ ਲੋੜ ਵੱਖਰੇ ਤੌਰ ਉੱਤੇ ਮੁਲਾਂਕਣੀ ਚਾਹੀਦੀ ਹੈ; ਇੱਕ ਸਾਧਨ ਨੂੰ ਸੰਤੁਸ਼ਟ ਕਰਨ ਲਈ ਸੁਰੰਗ ਨੂੰ TAP ਵਿੱਚ ਬਦਲਣਾ ਹਰ ਭਾਗੀਦਾਰ ਲਈ ਨੈੱਟਵਰਕ ਚੌੜਾ ਕਰਦਾ ਹੈ।
ਜੇ ਮਾਰਗ ਜਾਂ ਵਾਪਸੀ ਮਾਰਗ ਨਹੀਂ ਹੈ ਤਾਂ ਇੱਥੇ ਰੁਕੋ। ਆਪਣੇ ਹੋਸਟ ਉੱਤੇ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਪਰ ਵਰਕਸਟੇਸ਼ਨ ਤੋਂ ਪਹੁੰਚ ਨਾ ਹੋਣ ਵਾਲਾ ਪ੍ਰਕਾਸ਼ਕ ਰੂਟਿੰਗ ਸਮੱਸਿਆ ਰੱਖਦਾ ਹੈ, ROS ਸਮੱਸਿਆ ਨਹੀਂ।
ਕਦਮ 4: ਪੀਅਰ ਗੱਲਬਾਤ ਮਨਜ਼ੂਰ ਕਰੋ ਅਤੇ ਇੱਕ ਵਿਸ਼ਾ ਵੇਖੋ
ਸਿਰਫ਼ ਉਹ ਪੋਰਟ ਖੋਲ੍ਹੋ ਜੋ ਗੱਲਬਾਤ-ਤੈਅ ਗੱਲਬਾਤ ਲਈ ਲੋੜੀਂਦੇ ਹਨ, ਅਤੇ ਹਰ ਨਿਯਮ ਨੂੰ ਘੋਸ਼ਿਤ ਭਾਗੀਦਾਰਾਂ ਤੱਕ ਸੀਮਤ ਰੱਖੋ। master ਦਾ ਸਰੋਤਾ ਵਿਸ਼ਾ ਪੇਲੋਡ ਲਈ ਰੀਲੇ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਸਿਰਫ਼ ਇਸਨੂੰ ਮਨਜ਼ੂਰ ਕਰਨ ਨਾਲ ਪ੍ਰਕਾਸ਼ਕ ਦਾ ਅੰਤ ਬਿੰਦੂ ਬੰਦ ਹੀ ਰਹਿੰਦਾ ਹੈ। ROS ਸਰੋਤਿਆਂ ਨੂੰ ਜਨਤਕ ਇੰਟਰਨੈੱਟ ਉੱਤੇ ਨੰਗਾ ਕਰਨ ਦੀ ਥਾਂ ਨਿੱਜੀ VPN ਸੀਮਾ ਉੱਤੇ ਰੱਖੋ।
rostopic hz /chatter
rostopic echo -n1 /chatter
rosnode ping /talker
ਅਸਲੀ ਪ੍ਰਕਾਸ਼ਕ ਤੋਂ ਅਸਲੀ ਗਾਹਕ ਤੱਕ ਇੱਕ ਨਿਰਦੋਸ਼ ਵਿਸ਼ਾ ਵੇਖੋ ਅਤੇ ਘੋਸ਼ਿਤ ਅੰਤ ਬਿੰਦੂ ਅਤੇ ਜਵਾਬ ਦੇ ਮਾਰਗ ਦੋਵਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਇੱਕ ਸੁਨੇਹਾ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਮਾਰਗ ਕੰਮ ਕਰਦਾ ਹੈ; ਸਥਿਰ ਦਰ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਇਹ ਖੁੱਲ੍ਹਾ ਰਹਿੰਦਾ ਹੈ। ਐਕਚੁਏਟਰ ਨਿਯੰਤਰਣ ਅਤੇ ਸੁਰੱਖਿਆ ਜਾਂਚਾਂ ਨੂੰ ਇਸ ਸਿਰਫ਼-ਨੈੱਟਵਰਕ ਜਾਂਚ ਤੋਂ ਬਾਹਰ ਰੱਖੋ, ਕਿਉਂਕਿ ਕੰਮ ਕਰਦਾ ਵਿਸ਼ਾ ਕੰਮ ਕਰਦੇ ਰੋਬੋਟ ਦਾ ਪ੍ਰਮਾਣ ਨਹੀਂ। ਤੁਸੀਂ ਵੇਖੀ ROS ਆਵਿਰਤੀ ਅਤੇ ਅੰਤ ਬਿੰਦੂਆਂ ਦੀ ਜੋੜੀ ਦਰਜ ਕਰੋ, ਤਾਂ ਜੋ ਅਗਲਾ ਵਿਅਕਤੀ ਟੋਪੋਲੋਜੀ ਬਦਲਾਅ ਨੂੰ ਰਿਗ੍ਰੈਸ਼ਨ ਤੋਂ ਵੱਖ ਪਛਾਣ ਸਕੇ।
ਜਾਂਚ-ਸੂਚੀ ਤਦ ਪੂਰੀ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਘੋਸ਼ਿਤ URI ਗਾਹਕ ਤੋਂ ਪਹੁੰਚਯੋਗ ਹੋਵੇ, ਗੱਲਬਾਤ-ਤੈਅ ਪੋਰਟ ਸਿਰਫ਼ ਉਸ ਪੀਅਰ ਲਈ ਖੁੱਲ੍ਹਾ ਹੋਵੇ, ਇੱਕ ਘੋਸ਼ਿਤ ਵਿਸ਼ਾ ਵਹਿ ਰਿਹਾ ਹੋਵੇ, ਅਤੇ ਦੋਵਾਂ ਹੋਸਟਾਂ ਲਈ ਵਾਤਾਵਰਨ ਮੁੱਲ ਦਰਜ ਹੋਣ। ਪੁਰਾਣਾ ROS 1 ਇਸ ਖੇਤਰ ਵਿੱਚ ਸੁਧਾਰ ਨਹੀਂ ਪਾਏਗਾ, ਇਸ ਲਈ ਰਿਕਾਰਡ ਹੀ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਲੋਕ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਵੀ ਕੰਮ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ।