Mavros: NED और ENU के बीच फ्रेम रूपांतरणों को दोहराएं

शायद कोई वर्तमान स्थिति पर टिप्पणी कर सकता है? मेरे पास वर्तमान में कोड को छानने का समय नहीं है, लेकिन मुझे परिवर्तनों की समीक्षा करने में खुशी होगी।

@LorenzMeier पीआर # 208 देखें।

@LorenzMeier वास्तव में, यह वर्तमान सम्मेलन है जिसका हम उपयोग करते हैं:

बॉडी-फिक्स्ड NED → ROS ENU: (xyz)→(x -y -z) या (wxyz)→(x -y -zw)
स्थानीय NED → ROS ENU: (xyz)→(yx -z) या (wxyz)→(yx -zw)

मैं इस आरेख की शुद्धता को सत्यापित नहीं कर सकता, लेकिन मुझे लगता है कि हम अभी यही कर रहे हैं।

हाँ यह मेरी योजना है। मैं इसकी पुष्टि कर सकता हूं, और मैंने इसे अपनी थीसिस पर इस्तेमाल किया और समझाया।

नोट: इस रूपांतरण पर कुछ महीने पहले हम सहमत हुए थे और मैं रविज़ पर इसकी पुष्टि करने में सक्षम था।

मुद्दा वास्तविक रूपांतरण नहीं है, बल्कि जब एक निश्चित रूपांतरण का उपयोग किया जाता है।

मैं इसे देख रहा हूँ:
http://wiki.ros.org/geometry/CoordinateFrameConventions and
http://www.ros.org/reps/rep-0103.html

ग्राफिक के साथ कई मुद्दे हैं (और यदि यह अभिविन्यास, कोड का प्रतिनिधित्व करता है):

• ROS हमेशा दाहिने हाथ का होता है। ENU ग्राफिक (नीचे की पंक्ति) बाएं हाथ का है, जो सही नहीं है।
• ROS ENU का उपयोग कर रहा है। ENU का अर्थ है पूर्व-उत्तर-ऊपर, इसलिए X अक्ष पूर्व की ओर इशारा कर

नतीजतन, शून्य रोटेशन पर शरीर के फ्रेम और विश्व फ्रेम के बीच कोई अंतर नहीं है, और एनईडी और ईएनयू के बीच रूपांतरण क्रमशः वैश्विक/स्थानीय संदर्भ का उपयोग करते हुए दोनों फ़्रेमों के लिए समान है।

मैं ज्यादातर @LorenzMeier ने जो कहा है

इसके अलावा मैं इस बात से सहमत हूं कि ईएनयू को एनईडी में परिवर्तित करना वही है चाहे वह ग्राउंड फ्रेम या बॉडी फ्रेम के लिए हो। बॉडी फ्रेम पर ENU या NED नाम का ज्यादा मतलब नहीं है, लेकिन फिर भी ROS में इस्तेमाल होने वाले कोऑर्डिनेट फ्रेम से FCU में कनवर्ट करना हमेशा वैसा ही होना चाहिए जैसा मुझे लगता है।

मैंने अभी तक उस रूपांतरण की विधि की जाँच नहीं की है जिसे @mhkabir ने ऊपर पोस्ट किया है। सोचें कि हमें गणित करने से पहले सही ग्राफिक प्राप्त करने की आवश्यकता है

@thedinuka क्या आपको जो सही लगता है, उसके अनुसार आप पेंट या कुछ और में एक नया चाबुक

मेरे पास मूल फ़ाइल है, इसे chnage कर सकते हैं और फिर एक नया भेज सकते हैं (पेंट @mhkabir का उपयोग करने की कोई आवश्यकता नहीं है)। दाएं और बाएं हाथ की बात सही लगती है। लेकिन मुझे अभी भी दो अलग-अलग रूपांतरण होने के संबंध में संदेह है, और जब मैंने उस छवि को उस समय किया था, तो मैं भी उन्हें प्राप्त कर रहा था। तो शायद हमें कोड की जांच करने की ज़रूरत है, जो मुझे याद है उसके कारण, अधिकांश कार्यान्वयन उपरोक्त रूपांतरणों का उपयोग करते हैं।

@ TSC21 द्वारा ग्राफिक के संशोधित संस्करण की प्रतीक्षा करते हुए, मैंने इसे थोड़ा और सोचा है और यह जितना मैंने सोचा था उससे कहीं अधिक जटिल लगता है। मैं एक तरह से @ TSC21 से सहमत हूं। समन्वय परिवर्तनों के दो अलग-अलग जोड़े हैं जिन पर हमें विचार करने की आवश्यकता है।

1) बॉडी-फिक्स्ड फ्रेम के आरओएस कन्वेंशन से बॉडी-फिक्स्ड फ्रेम के पिक्सहॉक कन्वेंशन में परिवर्तन।
2) अर्थ-फिक्स्ड फ्रेम के आरओएस कन्वेंशन से पिक्सहॉक कन्वेंशन ऑफ अर्थ फिक्स्ड फ्रेम में परिवर्तन।

जबकि बॉडी-फिक्स्ड कोऑर्डिनेट फ्रेम के लिए उपयोग किए जाने वाले कन्वेंशन के बारे में ROS साइड और पिक्सहॉक दोनों तरफ प्रलेखन है, मुझे पिक्सहॉक साइड पर इनर्टियल (या अर्थ फिक्स्ड) कोऑर्डिनेट फ्रेम के बारे में इस्तेमाल किए गए कन्वेंशन के बारे में विशेष जानकारी नहीं मिली। अगर मुझे अनुमान लगाना होता तो मैं कहूंगा कि पिक्सहॉक की तरफ, जीपीएस की अनुपस्थिति में, अर्थ फिक्स्ड कोऑर्डिनेट फ्रेम बॉडी-फिक्स्ड फ्रेम के शुरुआती ओरिएंटेशन के साथ संरेखित होता है, लेकिन मुझे 100% यकीन नहीं है कि क्या यह माजरा हैं। तो किसी भी गलती और भ्रम को रोकने के लिए, मैं अभी के लिए, केवल बॉडी फिक्स्ड फ्रेम पर विचार करने जा रहा हूं।

आरओएस के लिए प्रलेखन [1] और पिक्सहॉक के लिए [2] पर भरोसा करते हुए, मैंने निम्नलिखित आरेख बनाया है।

एक बार जब हमारे पास उपरोक्त (1) और (2) दोनों के लिए समन्वय फ्रेम आरेख सत्यापित, पुष्टि और सहमत हो जाते हैं, तो मावरोस पक्ष पर वास्तविक परिवर्तन करने के लिए गणित बहुत सीधे आगे है।

[१] http://www.ros.org/reps/rep-0103.html
[२] https://pixhawk.org/dev/know-how/frames_of_reference

कृपया #148 (सहसंयोजन रूपांतरण) भी देखें।

यह रोस-इन्फ्रास्ट्रक्चर/प्रतिनिधि#95 . में मदद कर सकता है

क्या हम इसके साथ कहीं समाप्त हो गए? क्या ENU/NED, बॉडी/वर्ल्ड फ्रेम से वर्तमान रूपांतरण सही हैं? मैं इस कारण से पूछ रहा हूं कि हमें इस संभावना को फिर से शुरू करने की आवश्यकता है कि दृष्टि डेटा भेजते समय @blackcoder को FCU पर एक यॉ रोटेशन मिल रहा है क्योंकि हम चीजें गलत कर रहे हैं।
@वून , @mhkabir , @tonybaltovski , @thedinuka पिंग!

@thedinuka मुझे अच्छा लग रहा है।

अगर मुझे अनुमान लगाना होता तो मैं कहूंगा कि Pixhawk की तरफ, > GPS की अनुपस्थिति में, अर्थ फिक्स्ड कोऑर्डिनेट फ्रेम > बॉडी-फिक्स्ड फ्रेम के प्रारंभिक अभिविन्यास के साथ संरेखित होता है

वास्तव में जीपीएस की जरूरत नहीं है। हमारे पास पहले से ही मैग से वैश्विक यॉ संदर्भ है। इसका मतलब यह होना चाहिए कि इस यॉ द्वारा घुमाए गए ईएफ फ्रेम को घुमाया जाए।

नमस्ते,
मैं मावरोस में mocap_optitrack से Vision_pose/pose तक विषय को रीमैप करता हूं। हालांकि एमएवी सही ढंग से उड़ नहीं सकता है, इसलिए मैं निम्नलिखित कोड बदलता हूं:
Vision_position_estimate(stamp.toNSec()/1000,
स्थिति। वाई (), स्थिति। एक्स (), - स्थिति। जेड (),
रोल, -पिच, -यॉ); // ??? कृपया जांचें!
प्रति
Vision_position_estimate(stamp.toNSec()/1000,
स्थिति। वाई (), स्थिति। एक्स (), - स्थिति। जेड (),
रोल, -पिच, -यॉ + 1.57);
यानी चेंज -यॉ टू -यॉ + 1.57।
ENU से NED तक बॉडी फ्रेम पर बातचीत करते समय, मावरोस अब उपयोग करते हैं
(xyz)-->(x,-y,-z)
(w,x,y,z)-->(x,-y,-z,w), तो हमें मिलता है
ईएनयू ---> नेड
रोल ----> रोल
पिच ----->-पिच
यॉ -----> - यॉ।
हालांकि मुझे लगता है कि हम गलती करते हैं कि यॉ विश्व फ्रेम में एक्स अक्ष पर आधारित है (जब बॉडी फ्रेम में एक्स विश्व फ्रेम में एक्स के साथ है, तो यॉ 0 है), और 90 डिग्री रोटेशन है। इसलिए हमें -yaw + 1.57 बनाना चाहिए। अर्थात
ईएनयू ---> नेड
रोल ----> रोल
पिच ----->-पिच
यव ----->-यॉ+1.57.
मैंने इसे बदलने के बाद, माव सही ढंग से उड़ सकता है। इसलिए मुझे लगता है कि अन्य प्लगइन भी ऐसा ही है।

@congleetea जो local_position विषय से आने वाला डेटा सही दिशा के साथ आता है?

कृपया #148 (सहसंयोजन रूपांतरण) भी देखें।

हमें इसे भी ध्यान में रखना चाहिए।

पीआर #317 परिवर्तन रूपांतरण।

मैंने इस बातचीत का परीक्षण किया है

एनईडी (पिक्सहॉक) -> ईएनयू (आरओएस)
(एक्स, वाई, जेड) -> (एक्स, -वाई, -जेड)

ईएनयू (आरओएस) -> एनईडी (पिक्सहॉक)
(एक्स, वाई, जेड) -> (एक्स, -वाई, -जेड)

यह rviz और real fling दोनों में अच्छा काम करता है।

@supermice जो #317 की पुष्टि करता है, धन्यवाद! :)