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 ਟੈਸਟ ਦੁਹਰਾਓ ਅਤੇ ਦਿਸ਼ਾ, ਸੁਨੇਹਾ ਦਰ ਅਤੇ ਲਿੰਕ ਹਾਲਤਾਂ ਦਰਜ ਕਰੋ। ਅਸਲ ਸੁਧਾਰ ਨੂੰ ਕਿਸਮਤ ਵਾਲੇ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਤੋਂ ਵੱਖ ਕਰਨ ਲਈ ਤੁਲਨਾ ਦੋ ਵਾਰ ਚਲਾਓ। ਜੇਕਰ ਕੋਈ ਬਦਲਾਅ ਖੋਜ ਸੁਧਾਰਦਾ ਹੈ ਪਰ ਡਿਲੀਵਰੀ ਉਹੀ ਰਹਿੰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਜਾਣ-ਪਛਾਣ ਸੇਵਾ ਹਿਲਾਈ ਹੈ, ਡੇਟਾ ਮਾਰਗ ਨਹੀਂ।