VPN വഴിയുള്ള ROS 1 വിഷയങ്ങൾ: പ്രഖ്യാപിച്ച അന്തിമ പോയിന്റ് പിന്തുടരുക

നിങ്ങളുടെ വർക്ക്സ്റ്റേഷൻ ടണലിലൂടെ ROS 1 master-ൽ എത്തുന്നു, എന്നിട്ടും വിഷയങ്ങളുടെ പട്ടിക ശൂന്യമായി കാണുന്നു. ഈ മാതൃക സാധാരണമാണ്, കാരണം master രജിസ്ട്രേഷനും വിഷയ കൈമാറ്റവും രണ്ട് വ്യത്യസ്ത സംഭാഷണങ്ങളാണ്, master വഴി പോകുന്നത് ആദ്യത്തേത് മാത്രം. താഴെയുള്ള പരിശോധനാ പട്ടിക രണ്ടാമത്തെ സംഭാഷണം നടത്തുന്നു: പ്രസാധകൻ പ്രഖ്യാപിക്കുന്ന അന്തിമ പോയിന്റ്, സബ്സ്ക്രൈബർ എത്തേണ്ട വിലാസം, ഇരുവർക്കും സംസാരിക്കാൻ അനുവദിക്കുന്ന അനുമതി. ഇവിടെയുള്ളതെല്ലാം Noetic പിന്തുണാ കാലയളവ് 2025 മേയിൽ അവസാനിച്ച പഴയ ROS 1-ന് മാത്രം ബാധകമാണ്.

ഘട്ടം 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 ഈ മേഖലയിൽ തിരുത്തലുകൾ സ്വീകരിക്കില്ല, അതിനാൽ ആളുകൾ മാറിയതിന് ശേഷവും തുടർന്ന് പ്രവർത്തിക്കുന്ന ഭാഗം രേഖയാണ്.