ਲਾਈਵ ਪ੍ਰੋਸੈਸਿੰਗ ਜਾਂ ਰਿਕਾਰਡ ਕੀਤਾ ਡੇਟਾ: VPN ਅਸਲ ਵਿੱਚ ਕਿਸ ਲਈ ਲੋੜੀਂਦਾ ਹੈ?
ਤੈਅ ਕਰੋ ਕਿ ਕਿਹੜਾ ਰੋਬੋਟ ਕੰਮ ਨੈੱਟਵਰਕ ਪਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਸਮੇਂ ਸਿਰ ਨਤੀਜੇ, ਨਿਰੀਖਣ ਟੈਲੀਮੈਟਰੀ ਜਾਂ ਰਿਕਾਰਡ ਕੀਤਾ ਡੇਟਾਸੈਟ। ਤਿੰਨ ਸ਼ਰਤਾਂ, ਫਿਰ bag ਕਮਾਂਡਾਂ।
ਇੱਕ ਕਮਰੇ ਦੀ ਦੂਰੀ 'ਤੇ ਬੇਕਾਰ ਹੋ ਜਾਣ ਵਾਲੇ ਰੋਬੋਟ ਨੂੰ VPN ਦੀ ਸਮੱਸਿਆ ਆਉਣ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ ਲਿੰਕ ਜਾਂ ਕੰਮ ਦੇ ਭਾਰ ਦੀ ਸਮੱਸਿਆ ਹੁੰਦੀ ਹੈ। ਐਨਕ੍ਰਿਪਸ਼ਨ ਇੱਕ ਰਾਹ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਰੇਡੀਓ ਦੀ ਪਹੁੰਚ ਨਹੀਂ ਵਧਾਉਂਦਾ ਅਤੇ ਦੂਰਲੇ ਗਣਨ ਨੂੰ ਛੇਤੀ ਖ਼ਤਮ ਨਹੀਂ ਕਰਦਾ। ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਫੈਸਲਾ ਇਹ ਹੈ ਕਿ ਕਿਹੜਾ ਕੰਮ ਸੱਚਮੁੱਚ ਨੈੱਟਵਰਕ ਪਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਹ ਜਵਾਬ ਆਮ ਤੌਰ 'ਤੇ ਲੋਕਾਂ ਦੀ ਉਮੀਦ ਤੋਂ ਵੱਧ ਟਰੈਫਿਕ ਹਟਾਉਂਦਾ ਹੈ। ਇਸਨੂੰ ਤਿੰਨ ਸ਼ਰਤਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਥ੍ਰੂਪੁਟ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਹੀਂ।
ਤਿੰਨ ਪ੍ਰਬੰਧ, ਇੱਕ ਨਿਰਭਰਤਾ ਸਵਾਲ
ਸਾਰਣੀ ਪ੍ਰਬੰਧਾਂ ਨੂੰ ਡਾਇਗ੍ਰਾਮ ਵਿੱਚ ਕਿਹੜਾ ਸੌਫਟਵੇਅਰ ਦਿਸਦਾ ਹੈ ਨਾਲ ਨਹੀਂ, ਸਗੋਂ ਲਿੰਕ 'ਤੇ ਕੀ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਨਾਲ ਵੱਖ ਕਰਦੀ ਹੈ।
| Arrangement | What depends on the link | What stays onboard |
|---|---|---|
| Live remote processing | The exchange and any timely result the workstation returns | Only what the remote step does not block |
| Onboard processing, remote observation | The declared telemetry or display stream | The processing loop itself |
| Local recording, later analysis | Transfer of one selected dataset | The entire run, including raw sensors |
ਉਸ ਸਾਰਣੀ ਦੀ ਕੋਈ ਵੀ ਕਤਾਰ ਸੁਰੱਖਿਆ ਦਲੀਲ ਨਹੀਂ ਹੈ। ਕੰਟਰੋਲ ਅਤੇ ਸੁਰੱਖਿਆ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਦੇਰੀ, ਪੈਕੇਟ ਦੇ ਨਸ਼ਟ ਹੋਣ ਅਤੇ ਟੁੱਟੇ ਕਨੈਕਸ਼ਨ ਲਈ ਯੋਗ ਜਵਾਬ ਅਜੇ ਵੀ ਲੋੜੀਂਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਟਨਲ ਸੂਚਕ ਇਹ ਨਹੀਂ ਦਿੰਦਾ। ਸਾਰਣੀ ਦੱਸਦੀ ਹੈ ਕਿ ਨਿਰਭਰਤਾ ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਨੈੱਟਵਰਕ ਡਿਜ਼ਾਈਨ ਸੱਚਮੁੱਚ ਜੋ ਹਿੱਸਾ ਬਦਲ ਸਕਦਾ ਹੈ, ਉਹੀ ਹੈ।
ਪਹਿਲੀ ਸ਼ਰਤ: ਕੀ ਜਵਾਬ ਸਮੇਂ ਸਿਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ?
ਜੇ ਦੂਰਲਾ ਨਤੀਜਾ ਕੰਟਰੋਲਰ ਵਿੱਚ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਨੈੱਟਵਰਕ ਕੰਟਰੋਲ ਲੂਪ ਦੇ ਅੰਦਰ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਸ ਦੀ ਦੇਰੀ, ਜਿਟਰ ਅਤੇ ਰੁਕਾਵਟਾਂ ਕੰਟਰੋਲ ਦੇ ਗੁਣ ਬਣ ਜਾਂਦੀਆਂ ਹਨ। ਜੇ ਉਹੀ ਨਤੀਜਾ ਸਿਰਫ਼ ਡਿਸਪਲੇ, ਡੈਸ਼ਬੋਰਡ ਜਾਂ ਦੇਖ ਰਹੇ ਵਿਅਕਤੀ ਤੱਕ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਉਹੀ ਦੇਰੀ ਸਿਰਫ਼ ਦਿੱਖ ਹੈ।
ਵਾਇਰਲੈੱਸ ਲਿੰਕ 'ਤੇ ਬੰਦ ਲੂਪ ਦਾ ਕੰਮ ਸੰਭਵ ਹੈ, ਅਤੇ "VPN ਹੌਲੀ ਹੈ" ਵਾਲੀਆਂ ਬਹੁਤੀਆਂ ਸ਼ਿਕਾਇਤਾਂ ਇੱਥੋਂ ਹੀ ਆਉਂਦੀਆਂ ਹਨ, ਕਿਉਂਕਿ ਟਨਲ ਦਿਸਣ ਵਾਲਾ ਹਿੱਸਾ ਹੈ ਜਦੋਂ ਕਿ ਕਾਰਨ ਰੇਡੀਓ ਅਤੇ ਰੂਟਿੰਗ ਹੈ। ਟਨਲ ਦੇ ਆਪਣੇ ਪਿੰਗ ਦੀ ਥਾਂ ਅਸਲ ਸੁਨੇਹੇ ਦਾ ਆਵਾਜਾਈ ਸਮਾਂ ਮਾਪੋ, ਫਿਰ ਪੁੱਛੋ ਕਿ ਕੀ ਇਹ ਅੰਕੜਾ ਲੂਪ ਦੇ ਬਜਟ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦਾ ਹੈ। ਜੇ ਨਹੀਂ, ਤਾਂ ਕਮਰੇ ਵਿੱਚ ਕਿਸੇ ਦੇ ਵੀ ਕੰਟਰੋਲ ਵਿੱਚ ਨਾ ਹੋਣ ਵਾਲੇ ਲਿੰਕ ਲਈ ਸਖ਼ਤ ਸੇਵਾ ਪੱਧਰ ਦੀ ਗੱਲਬਾਤ ਕਰਨ ਦੀ ਥਾਂ ਕਦਮ ਨੂੰ ਆਨਬੋਰਡ ਲੈ ਜਾਓ। ਮਾਪਿਆ ਅੰਕੜਾ ਉਨ੍ਹਾਂ ਹਾਲਾਤਾਂ ਸਮੇਤ ਲਿਖੋ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਇਹ ਲਿਆ ਗਿਆ, ਕਿਉਂਕਿ ਅਗਲੀ ਰਿਪੋਰਟ ਉਹਨਾਂ ਹਾਲਾਤਾਂ ਤੋਂ ਬਿਨਾਂ ਆਵੇਗੀ।
ਦੂਜੀ ਸ਼ਰਤ: ਤੁਸੀਂ ਕਿਹੜੀ ਦਰ, ਦਿਸ਼ਾ ਅਤੇ ਰੁਕਾਵਟ ਦਾ ਐਲਾਨ ਕਰ ਸਕਦੇ ਹੋ?
ਡੇਟਾ, ਦਰ, ਦਿਸ਼ਾ ਅਤੇ ਉਹ ਸਭ ਤੋਂ ਲੰਮੀ ਰੁਕਾਵਟ ਲਿਖੋ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਸਹਿੰਦੀ ਹੈ। ਉੱਪਰ ਵੱਲ ਕੈਮਰਾ ਸਟ੍ਰੀਮ ਅਤੇ ਹੇਠਾਂ ਵੱਲ ਕਮਾਂਡ ਚੈਨਲ ਵੱਖਰੇ ਤਰੀਕਿਆਂ ਨਾਲ ਫੇਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਸਥਿਰ ਜਾਂਚ ਵੱਲੋਂ ਸਹੀ ਗਈ ਰੁਕਾਵਟ ਚੱਲ ਰਹੇ ਕੰਮ ਨੂੰ ਖ਼ਤਮ ਕਰ ਦੇਵੇਗੀ।
ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦਿਆਂ ਭੌਤਿਕ ਜੁੜਾਅ ਅਤੇ ਟਨਲ ਨੂੰ ਵੱਖਰਾ ਰੱਖੋ, ਕਿਉਂਕਿ ਵਧੀਆ ਰੇਡੀਓ ਅਤੇ ਘੱਟ ਕੰਮ ਦਾ ਭਾਰ ਵੱਖਰੀਆਂ ਮੁਰੰਮਤਾਂ ਹਨ। ਅੰਤ ਵਿੱਚ ਪੂਰਾ ਹੋਣ ਵਾਲਾ ਵੱਡਾ ਤਬਾਦਲਾ ਸਮੇਂ ਪ੍ਰਤੀ ਸੰਵੇਦਨਸ਼ੀਲ ਨਤੀਜੇ ਦੇ ਲਗਾਤਾਰ ਆਉਣ ਬਾਰੇ ਕੁਝ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਸਿਹਤਮੰਦ ਟਨਲ ਉਸ ਦੇ ਪਿੱਛੇ ਦੇ ਰੇਡੀਓ ਬਾਰੇ ਕੁਝ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।
ਫਿਰ ਮੰਗ ਦਾ ਬਚਾਅ ਕਰਨ ਦੀ ਥਾਂ ਇਸਨੂੰ ਘਟਾਓ। ਨਿਰੀਖਣ ਸਟ੍ਰੀਮ ਦਾ ਸੈਂਪਲਿੰਗ ਘਟਾਓ, ਸਾਰਾਂਸ਼ ਜਾਂ ਡੈਲਟਾ ਭੇਜੋ, ਅਤੇ ਕੱਚਾ ਸੈਂਸਰ ਡੇਟਾ ਉੱਥੇ ਆਨਬੋਰਡ ਛੱਡੋ ਜਿੱਥੇ ਸਟੋਰੇਜ ਸਸਤੀ ਹੈ ਅਤੇ ਭੇਜਣਾ ਨਹੀਂ। ਛੋਟਾ ਪੇਲੋਡ ਤੇਜ਼ ਲਿੰਕ ਦੀ ਦਲੀਲ ਨੂੰ ਕਮਜ਼ੋਰ ਕਰਦਾ ਹੈ ਅਤੇ ਅਕਸਰ ਇਸਦੀ ਲੋੜ ਹੀ ਖ਼ਤਮ ਕਰ ਦਿੰਦਾ ਹੈ।
ਤੀਜੀ ਸ਼ਰਤ: ਇਹ ਕਿਸਨੂੰ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕੀ ਸਥਾਨਕ ਰਹਿੰਦਾ ਹੈ
ਨਿਰੀਖਣ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰੋਸੈਸਿੰਗ ਨਾਲੋਂ ਬਹੁਤ ਛੋਟੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇ ਵਿਅਕਤੀ ਨੂੰ ਕੈਮਰਾ ਦੇਖਣਾ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਲੌਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਉਹ ਟੈਲੀਮੈਟਰੀ ਅਤੇ ਸਟੋਰੇਜ ਹੈ; ਜੇ ਮਾਡਲ ਚੱਲਣਾ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਪੁੱਛੋ ਕਿ ਕੀ ਇਹ ਆਨਬੋਰਡ ਚੱਲ ਕੇ ਸਿਰਫ਼ ਆਪਣਾ ਨਤੀਜਾ ਅੱਗੇ ਭੇਜ ਸਕਦਾ ਹੈ। ਭਾਰੀ ਕਦਮ ਨੂੰ ਆਨਬੋਰਡ ਲੈ ਜਾਣ ਨਾਲ ਸਿੰਕ੍ਰੋਨਸ ਨਿਰਭਰਤਾ ਹਟਦੀ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਯੋਗ ਤਬਾਦਲਾ ਬਚਦਾ ਹੈ।
ਇੱਕੋ ਰੋਬੋਟ 'ਤੇ ਦੋ ROS ਭਾਗੀਦਾਰ ਹੋਣਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਟਨਲ ਦਾ ਜਾਇਜ਼ ਨਹੀਂ ਹੈ। ਨੋਡ ਦੀ ਪਹੁੰਚ, ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਮਨਜ਼ੂਰੀ ਅਤੇ ਸਥਾਨਕ ਰਿਕਵਰੀ ਯੋਜਨਾ ਵੱਖਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ, ਅਤੇ VPN ਸਿਰਫ਼ ਪਹਿਲੀ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਉਹ ਵੀ ਉਸ ਟਰੈਫਿਕ ਲਈ ਜਿਸਨੂੰ ਰੂਟ ਕਰਨ ਲਈ ਕਿਹਾ ਜਾਂਦਾ ਹੈ।
ਡੇਟਾਸੈਟ ਰਿਕਾਰਡ ਕਰਨਾ ਆਪਣੀਆਂ ਕਮਾਂਡਾਂ ਵਾਲਾ ਆਪਣਾ ਡਿਜ਼ਾਈਨ ਹੈ
ਵਰਜਨ ਨਾਲ ਜੁੜੇ ਉਦਾਹਰਨ ਲਈ, ROS 2 Jazzy ਰਿਕਾਰਡਿੰਗ ਟਿਊਟੋਰਿਅਲ ਚੁਣੇ ਵਿਸ਼ਿਆਂ ਦੀ ਰਿਕਾਰਡਿੰਗ, ਬਣੇ bag ਦੀ ਜਾਂਚ ਅਤੇ ਇਸਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਣ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ। ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਨਿਰੀਖਣ ਵਿਸ਼ੇ ਰਿਕਾਰਡ ਕਰੋ, ਦੌੜ ਨੂੰ ਨਾਮ ਦਿਓ, ਅਤੇ ਸੁਨੇਹਾ ਪਰਿਭਾਸ਼ਾਵਾਂ ਤੇ ਕਨਫਿਗਰੇਸ਼ਨ ਇਸਦੇ ਕੋਲ ਰੱਖੋ।
ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42ਟੂਲ ਸੌਖਾ ਹੈ ਇਸ ਲਈ ਹਰ ਵਿਸ਼ਾ ਰਿਕਾਰਡ ਨਾ ਕਰੋ। ਸਟੋਰੇਜ ਭਰਦੀ ਹੈ, ਕੈਮਰਾ ਤੇ ਟਿਕਾਣਾ ਡੇਟਾ ਸੰਵੇਦਨਸ਼ੀਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਬਿਨਾਂ ਲੇਬਲ ਵਾਲੇ ਵਿਸ਼ਿਆਂ ਦਾ bag ਅੱਗੇ ਇਸਨੂੰ ਖੋਲ੍ਹਣ ਵਾਲੇ ਲਈ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਸਮੱਸਿਆ ਬਣਦਾ ਹੈ। ਤੈਨਾਤ ਕੀਤਾ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਕਮਾਂਡਾਂ ਵੀ ਤੈਅ ਕਰਦਾ ਹੈ: ROS 1 bag ਲਈ ਲਿਖੇ ਟੂਲ ROS 2 bag 'ਤੇ ਨਹੀਂ ਜਾਂਦੇ, ਇਸ ਲਈ ਦਸਤਾਵੇਜ਼ ਰੋਬੋਟ 'ਤੇ ਲੱਗੇ ਵਰਜਨ ਨਾਲ ਮਿਲਾਓ।
ਅਲੱਗ ਥਲੱਗ ਵਿਸ਼ਲੇਸ਼ਣ ਜਾਂ ਸਿਮੂਲੇਸ਼ਨ ਵਾਤਾਵਰਨ ਵਿੱਚ ਦੁਬਾਰਾ ਚਲਾਓ। ਰਿਕਾਰਡ ਕੀਤੇ ਕਮਾਂਡ ਵਿਸ਼ਿਆਂ ਨੂੰ ਚੱਲ ਰਹੇ ਰੋਬੋਟ ਦੇ ਐਕਚੁਏਟਰਾਂ ਵਿੱਚ ਦੁਬਾਰਾ ਚਲਾਉਣਾ ਹਾਦਸਾ ਹੈ, ਅਤੇ ਰੋਕਥਾਮ ਵੱਖਰਾ ROS ਡੋਮੇਨ ਜਾਂ ਲੂਪ ਵਿੱਚ ਕੋਈ ਵੀ ਹਾਰਡਵੇਅਰ ਨਾ ਹੋਣਾ ਹੈ।
ਨਿਰਭਰਤਾ ਕਿੱਥੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਤੈਅ ਕਰਕੇ ਲਿਖੋ: VPN ਉਸ ਅਦਲਾ-ਬਦਲੀ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ ਜੋ ਹੋਣੀ ਹੀ ਚਾਹੀਦੀ ਹੈ, ਆਨਬੋਰਡ ਪ੍ਰੋਸੈਸਿੰਗ ਉਸ ਅਦਲਾ-ਬਦਲੀ ਨੂੰ ਹਟਾਉਂਦੀ ਹੈ ਜਿਸਨੂੰ ਕਦੇ ਸਿੰਕ੍ਰੋਨਸ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ, ਅਤੇ ਰਿਕਾਰਡ ਕੀਤਾ ਡੇਟਾਸੈਟ ਲਾਈਵ ਖਪਤਕਾਰ ਦੀ ਥਾਂ ਬਾਅਦ ਵਾਲੇ ਖਪਤਕਾਰ ਨੂੰ ਲੈ ਆਉਂਦਾ ਹੈ। ਫਿਰ ਡਿਜ਼ਾਈਨ ਨੂੰ ਮੁਕੰਮਲ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਸਥਾਨਕ ਕੰਮ ਦੇ ਚੱਲਦਿਆਂ ਹੀ ਡਿਸਕਨੈਕਟ ਹੋਣ ਵਾਲੀ ਸਥਿਤੀ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਪਰਖੋ।