VPN வழியாக ROS 1 தலைப்புகள்: அறிவிக்கப்பட்ட இறுதிப் புள்ளியைப் பின்பற்றுங்கள்
ROS 1 master பதிவு தலைப்புத் தரவை எடுத்துச் செல்லாது. அறிவிக்கப்பட்ட முனை URI-ஐப் படியுங்கள், அந்த முகவரியை வழியமைக்கக்கூடியதாக்குங்கள், பின்னர் வெளியீட்டாளரின் துறையை அனுமதியுங்கள்.
உங்கள் பணிநிலையம் சுரங்கப்பாதை வழியாக ROS 1 master-ஐ அடைகிறது, இருப்பினும் தலைப்புகளின் பட்டியல் காலியாகவே காட்டப்படுகிறது. இந்த முறை பொதுவானது, ஏனெனில் master பதிவும் தலைப்பு இடமாற்றமும் இரண்டு வெவ்வேறு உரையாடல்கள், master வழியாக முதல் ஒன்று மட்டுமே செல்கிறது. கீழே உள்ள சரிபார்ப்புப் பட்டியல் இரண்டாவது உரையாடலைக் கடக்கிறது: வெளியீட்டாளர் அறிவிக்கும் இறுதிப் புள்ளி, சந்தாதாரர் அடைய வேண்டிய முகவரி, மற்றும் இருவரும் பேச அனுமதிக்கும் அனுமதி. இங்குள்ள அனைத்தும் 2025 மே மாதத்தில் Noetic ஆதரவுக் காலம் முடிவடைந்த பழைய 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 உரையாடல்களைக் கொண்டு செல்கிறது, இது வழக்கமாக தொலை இயக்குபவர் விரும்புவது. அடுக்கில் ஏதேனும் broadcast அல்லது multicast-ஐச் சார்ந்திருந்தால், அந்தத் தேவை தனித்தனியாக மதிப்பிடப்பட வேண்டும்; ஒரு கருவியைத் திருப்திப்படுத்த சுரங்கப்பாதையை TAP ஆக மாற்றுவது ஒவ்வொரு பங்கேற்பாளருக்கும் வலையை விரிவாக்குகிறது.
வழி அல்லது திரும்பும் வழி இல்லாவிட்டால் இங்கே நிறுத்துங்கள். தன் சொந்தப் புரவலனில் பதிலளிக்கும் ஆனால் பணிநிலையத்திலிருந்து அடைய முடியாத வெளியீட்டாளருக்கு வழியமைப்புப் பிரச்சினை உள்ளது, ROS பிரச்சினை அல்ல.
படி 4: சக உரையாடலை அனுமதித்து ஒரு தலைப்பைக் கவனியுங்கள்
பேச்சுவார்த்தை செய்யப்பட்ட உரையாடலுக்குத் தேவையான துறைகளை மட்டும் திறங்கள், ஒவ்வொரு விதியையும் அறிவிக்கப்பட்ட பங்கேற்பாளர்களுக்கு மட்டுப்படுத்துங்கள். master-இன் கேட்பவர் தலைப்பு பேலோட்டுக்கான ரிலே அல்ல, எனவே அதற்கு மட்டும் அனுமதி அளித்தால் வெளியீட்டாளரின் இறுதிப் புள்ளி மூடியே இருக்கும். ROS கேட்பவர்களைப் பொது இணையத்திற்கு வெளிப்படுத்தாமல் தனியார் VPN எல்லையில் வைத்திருங்கள்.
rostopic hz /chatter
rostopic echo -n1 /chatter
rosnode ping /talker
உண்மையான வெளியீட்டாளரிடமிருந்து உண்மையான சந்தாதாரருக்கு ஒரு பாதிப்பில்லாத தலைப்பைக் கவனித்து, அறிவிக்கப்பட்ட இறுதிப் புள்ளியையும் பதிலின் வழியையும் உறுதிப்படுத்துங்கள். ஒரு செய்தி வழி வேலை செய்கிறது என்பதை நிரூபிக்கிறது; நிலையான விகிதம் அது திறந்தே இருப்பதை நிரூபிக்கிறது. இயக்கிக் கட்டுப்பாடு மற்றும் பாதுகாப்புச் சோதனைகளை இந்த வலையமைப்பு மட்டும் சோதனைக்கு வெளியே வைத்திருங்கள், ஏனெனில் வேலை செய்யும் தலைப்பு வேலை செய்யும் ரோபோவுக்குச் சான்று அல்ல. நீங்கள் கவனித்த ROS பதிப்பையும் இறுதிப் புள்ளிகளின் இணையையும் பதிவு செய்யுங்கள், அடுத்த நபர் இடவியல் மாற்றத்தைப் பின்னடைவிலிருந்து வேறுபடுத்திக்கொள்ள முடியும்.
அறிவிக்கப்பட்ட URI சந்தாதாரரிடமிருந்து அடையக்கூடியதாக இருக்கும்போது, பேச்சுவார்த்தை செய்யப்பட்ட துறை அந்தச் சகாவுக்கு மட்டும் திறந்திருக்கும்போது, ஒரு அறிவிக்கப்பட்ட தலைப்பு பாயும்போது, இரு புரவலன்களுக்கும் சூழல் மதிப்புகள் பதிவு செய்யப்பட்டிருக்கும்போது சரிபார்ப்புப் பட்டியல் நிறைவடைகிறது. பழைய ROS 1 இந்தப் பகுதியில் திருத்தங்களைப் பெறாது, எனவே மக்கள் மாறிய பிறகும் தொடர்ந்து வேலை செய்யும் பகுதி பதிவே.