લાઇવ પ્રોસેસિંગ કે રેકોર્ડ કરેલો ડેટા: ખરેખર શેને 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 ધીમું છે” અહેવાલો પણ ત્યાંથી જ ઉદ્ભવે છે, કારણ કે ટનલ દેખાતો ઘટક છે જ્યારે રેડિયો અને રાઉટિંગ કારણ છે. ટનલની પોતાની ping નહીં, પણ વાસ્તવિક સંદેશનો રાઉન્ડ ટ્રિપ માપો, પછી પૂછો કે સંખ્યા લૂપના બજેટમાં બેસે છે કે નહીં. ન બેસે તો પગલું ઓનબોર્ડ ખસેડો, ઓરડામાં કોઈ નિયંત્રણ ન કરતી લિંક માટે વધુ કડક સેવા સ્તરની વાટાઘાટ કરવાને બદલે. માપેલી સંખ્યા જે પરિસ્થિતિમાં લેવાઈ તેની સાથે નોંધો, કારણ કે આગલો અહેવાલ તેના વિના આવશે.
શરત બે: કઈ દર, દિશા અને વિક્ષેપ તમે જાહેર કરી શકો છો?
ડેટા, દર, દિશા અને એપ્લિકેશન જે સૌથી લાંબો વિક્ષેપ સહન કરે છે તે લખો. ઉપર તરફનો કેમેરા સ્ટ્રીમ અને નીચે તરફનો કમાન્ડ ચેનલ જુદી જુદી રીતે નિષ્ફળ જાય છે, અને સ્થિર નિરીક્ષણ સહન કરે તેવો વિક્ષેપ ચાલતા કાર્યને પૂરું કરી નાખશે.
વિકલ્પોની સરખામણી કરતી વખતે ભૌતિક જોડાણ અને ટનલને અલગ રાખો, કારણ કે વધુ મજબૂત રેડિયો અને નાનું વર્કલોડ જુદા જુદા સમારકામ છે. છેવટે પૂર્ણ થતું મોટું ટ્રાન્સફર સમય-સંવેદનશીલ પરિણામ સતત આવવા વિશે કંઈ સાબિત કરતું નથી, અને સ્વસ્થ ટનલ તેની પાછળના રેડિયો વિશે કંઈ સાબિત કરતું નથી.
પછી માંગનો બચાવ કરવાને બદલે તેને ઘટાડો. અવલોકન સ્ટ્રીમનું સેમ્પલિંગ ઘટાડો, સારાંશ કે ડેલ્ટા મોકલો, અને કાચા સેન્સર ડેટાને ઓનબોર્ડ રાખો જ્યાં સંગ્રહ સસ્તો છે અને પ્રસારણ નથી. નાનું પેલોડ ઝડપી લિંકની તરફેણની દલીલ નબળી કરે છે, અને ઘણી વાર તેની જરૂરિયાત જ દૂર કરે છે.
શરત ત્રણ: કોને તે જોવું જોઈએ, અને શું સ્થાનિક રહે છે
અવલોકન સામાન્ય રીતે પ્રોસેસિંગ કરતાં ઘણું નાનું જરૂરિયાત છે. જો વ્યક્તિએ કેમેરા જોવો પડે અને પછી લોગ હોવો જોઈએ, તો તે ટેલિમેટ્રી ઉપરાંત સંગ્રહ છે; જો મોડેલ ચલાવવું પડે, તો પહેલાં પૂછો કે તે ઓનબોર્ડ ચાલી શકે છે અને ફક્ત તેનું પરિણામ મોકલાય છે. ભારે પગલું ઓનબોર્ડ ખસેડવાથી સિંક્રોનસ અવલંબન દૂર થાય છે અને ફરી પ્રયાસ કરી શકાય તેવું ટ્રાન્સફર રહે છે.
એક જ રોબોટ પર બે 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 એવી આપલેનું રક્ષણ કરે છે જે થવી જ જોઈએ, ઓનબોર્ડ પ્રોસેસિંગ એ આપલે દૂર કરે છે જેને ક્યારેય સિંક્રોનસ હોવાની જરૂર નહોતી, અને રેકોર્ડ કરેલો ડેટાસેટ જીવંત ગ્રાહકને પછીના ગ્રાહકથી બદલે છે. પછી કોઈ ડિઝાઇનને પૂર્ણ કહે તે પહેલાં, સ્થાનિક કામ હજી ચાલુ હોય તેમ, ડિસ્કનેક્ટેડ કેસનું ઇરાદાપૂર્વક પરીક્ષણ કરો.