ಲೈವ್ ಪ್ರೊಸೆಸಿಂಗ್ ಅಥವಾ ದಾಖಲಾದ ಡೇಟಾ: ನಿಜವಾಗಿ 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 ನಡೆಯಲೇಬೇಕಾದ ವಿನಿಮಯವನ್ನು ರಕ್ಷಿಸುತ್ತದೆ, ಆನ್‌ಬೋರ್ಡ್ ಪ್ರೊಸೆಸಿಂಗ್ ಸಿಂಕ್ರೊನಸ್ ಆಗಿರಬೇಕಾಗಿಲ್ಲದ ವಿನಿಮಯವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಮತ್ತು ದಾಖಲಾದ ಡೇಟಾಸೆಟ್ ಜೀವಂತ ಗ್ರಾಹಕನನ್ನು ನಂತರದ ಗ್ರಾಹಕನಿಂದ ಬದಲಾಯಿಸುತ್ತದೆ. ನಂತರ ಸಂಪರ್ಕ ಕಡಿತದ ಸಂದರ್ಭವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ, ಸ್ಥಳೀಯ ಕೆಲಸ ಇನ್ನೂ ನಡೆಯುತ್ತಿರುವಾಗಲೇ ಪರೀಕ್ಷಿಸಿ, ವಿನ್ಯಾಸ ಮುಗಿಯಿತು ಎಂದು ಯಾರಾದರೂ ಹೇಳುವ ಮೊದಲು.