1 पॉइंट द्वारा GN⁺ 2024-07-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GPS लोकेशन की गणना एक ऐसी समस्या है जिसमें सैटेलाइट तक की pseudorange दूरी, ephemeris और रिसीवर clock error को साथ में solve करना होता है; कच्चे डेटा को Matlab में process करके वास्तविक position estimation तक implement किया गया
  • गणना के लिए latitude/longitude की तुलना में WGS 84 ECEF coordinate system अधिक उपयुक्त है, और user-reference azimuth/elevation angles तथा error analysis के लिए ENU local coordinate system भी साथ में इस्तेमाल होता है
  • सैटेलाइट की position GPS Interface Specification की प्रक्रिया और orbital parameters से निकाली जाती है; signal travel के दौरान पृथ्वी घूमती है, इसलिए transmission time के coordinates को reception time के ECEF frame के अनुसार correct करना होता है
  • user position और receiver clock bias का estimation कम-से-कम 4 सैटेलाइट की corrected pseudorange पर iterative least squares चलाकर किया जाता है, और example analysis में ionospheric/tropospheric delay को शामिल नहीं किया गया
  • u-blox NEO-M8T/6T, RTKLib STRSVR, RTCM 1002/1019 और goGPS का उपयोग करके stationary receiver experiment में position standard deviation East 14.00m, North 39.88m, Up 47.35m था, और clock bias 4.27e-7sec/sec की linear drift दिखाता था

GPS लोकेशन गणना की मूल समस्या

  • GPS का मुख्य काम user की position calculate करना है
  • latitude, longitude और altitude पृथ्वी की सतह पर position बताने के लिए परिचित हैं, लेकिन latitude या longitude में 1 degree का अंतर हमेशा समान physical distance नहीं दर्शाता, इसलिए mathematical calculation के लिए ये असुविधाजनक हैं
    • longitude में 1 degree का distance equator पर सबसे बड़ा होता है और ध्रुवीय क्षेत्रों में लगभग 0 हो जाता है
  • गणना के लिए ऐसा Cartesian coordinate system चाहिए जिसमें unit coordinate difference एक स्थिर physical distance को दर्शाए
  • GPS कई सैटेलाइट तक की दूरी और सैटेलाइट positions का उपयोग करके user position निकालता है
    • पहले सैटेलाइट तक की दूरी और हर सैटेलाइट की position calculate करनी होती है

Coordinate systems: ECEF, WGS 84, ENU

  • पृथ्वी से fixed और उसके साथ घूमने वाले Cartesian coordinate system को ECEF(Earth Centered, Earth Fixed) कहा जाता है
    • पृथ्वी की सतह पर stationary user के coordinates समय के साथ constant रहते हैं, इसलिए यह user position representation के लिए उपयुक्त है
  • सबसे आम ECEF coordinate system अमेरिकी रक्षा विभाग द्वारा विकसित WGS 84 है
    • origin पृथ्वी के center of mass पर होता है
    • z-axis CTP(Conventional Terrestrial Pole) से होकर गुजरता है
    • CTP 1900~1905 के दौरान पृथ्वी के pole positions का average है, और वास्तविक pole position लगभग 15m radius वाले circle के अंदर move करती है
    • x-axis CTP equatorial plane और reference meridian, यानी Mean Greenwich Meridian, के intersection से होकर गुजरता है
  • सैटेलाइट motion को Newtonian mechanics के अनुसार inertial coordinate system में handle करना स्वाभाविक है, लेकिन GPS Interface Specification किसी specific time पर सैटेलाइट position को ECEF frame में calculate करने की प्रक्रिया देता है
  • local applications में user position को origin मानने वाला ENU(East-North-Up) coordinate system सुविधाजनक होता है
    • ECEF coordinates को user के latitude/longitude का उपयोग करके matrix multiplication से ENU coordinates में बदला जा सकता है
    • सैटेलाइट के azimuth और elevation angle की गणना में ENU transformation इस्तेमाल होता है

Altitude definition: reference ellipsoid और geoid

  • altitude के लिए पहले यह तय होना चाहिए कि “किसे reference माना जा रहा है”
  • reference ellipsoid पृथ्वी को एक flattened ellipsoid के रूप में abstract करने वाला model है
    • यह पृथ्वी के center पर स्थित होता है, और rotation axis ECEF z-axis से मेल खाता है
    • पृथ्वी को sphere मानते समय आम तौर पर इस्तेमाल होने वाला 6371km radius, semi-major और semi-minor axis के बीच का value है
    • वास्तविक पृथ्वी की सतह का कोई point reference ellipsoid के ऊपर या नीचे हो सकता है
  • geoid समान gravitational potential value वाले points का समूह है, यानी physical meaning वाली surface
    • geoid-reference altitude को orthometric height या mean sea level(MSL) से ऊपर की height कहा जाता है
    • geoid को आमतौर पर reference ellipsoid के ऊपर height values के समूह के रूप में specify किया जाता है
  • latitude/longitude/altitude ellipsoidal coordinates के रूप में define होते हैं
    • geodetic latitude, point P पर ellipsoid surface के perpendicular line और equatorial plane के बीच का angle है
    • पृथ्वी के center और point P को जोड़ने वाली line का angle geocentric latitude है; अगर पृथ्वी perfect sphere होती तो यह geodetic latitude से match करता
  • ellipsoidal coordinates से Cartesian coordinates में conversion एक step में संभव है, लेकिन ECEF से ellipsoidal coordinates में conversion के लिए तेजी से converge होने वाली iterative procedure चाहिए

सैटेलाइट position की गणना

  • ideal satellite orbit एक elliptical orbit है जिसे 6 Keplerian orbital elements से describe किया जाता है
    • 5 elements ellipse का size/shape और orbital plane की direction तय करते हैं
    • 6th element किसी specific epoch पर सैटेलाइट position तय करता है
  • वास्तविक satellite orbit पृथ्वी की composition में non-uniformity और सूर्य/चंद्रमा के gravitational effects के कारण perfect ellipse नहीं होती
  • GPS इन perturbations को correct करने के लिए 16 orbital parameters broadcast करता है
    • GPS Interface Specification के table 20-IV में orbital corrections सहित satellite position calculation procedure है
  • user position reception time t पर calculate की जाती है, लेकिन GPS signal सैटेलाइट से t-τ समय पर निकला होता है
    • satellite position signal transmission time t-τ पर calculate की जाती है
    • signal travel करने में लगने वाले τ के दौरान पृथ्वी घूमती है, इसलिए satellite position vector को पृथ्वी के rotation amount के अनुसार rotate करके reception time t के user ECEF frame से align किया जाता है
    • यह satellite position को सिर्फ t time पर calculate करने जैसा नहीं है

Pseudorange और clock bias

  • GPS receiver सैटेलाइट signal में शामिल transmission timestamp और receiver time की तुलना करता है, और difference को speed of light से multiply करके सैटेलाइट तक की दूरी का rough estimate निकालता है
  • यह measured value pseudorange है
    • अगर satellite clock और receiver clock पूरी तरह synchronized हों और signal vacuum में सीधी line में speed of light से travel करे, तो यह वास्तविक distance के बराबर होगा
    • वास्तविकता में clock offset और atmospheric delay के कारण यह real distance से अलग हो जाता है
  • satellite clock bias को जरूर correct करना पड़ता है, क्योंकि इससे position error हजारों meters तक जा सकता है
    • इसे GPS ephemeris message के coefficients का उपयोग करके polynomial और relativistic term से calculate किया जाता है
    • polynomial अधिकांश correction देता है, और relativistic effect satellite position के आधार पर लगभग 1~10m contribute करता है
  • receiver clock bias एक unknown है जिसका estimation user position के साथ करना पड़ता है
    • algorithm में clock bias को speed of light से multiply करके distance units में handle किया जाता है
  • atmospheric delay को ionospheric और tropospheric components में बांटा जाता है
    • ionospheric delay आम तौर पर लगभग 25m position error पैदा करता है
    • tropospheric delay आम तौर पर लगभग 2m position error पैदा करता है
    • इस लेख के experiment analysis में इन delays को ignore किया गया है

User position और clock bias estimation algorithm

  • corrected pseudorange measurement को वास्तविक user-satellite distance, receiver clock bias और unmodeled errors के sum के रूप में express किया जाता है
  • user position और clock bias ऐसे values के रूप में खोजे जाते हैं जो measured pseudorange और predicted pseudorange के difference को minimize करें
  • solution iterative least squares procedure है
    • user position initial value [0 0 0]
    • user clock bias initial value 0
    • हर iteration में current position estimate के आधार पर satellite direction unit vectors को stack करके G matrix बनता है
    • position correction और clock bias correction solve किए जाते हैं, और बदलाव threshold से छोटा होने तक repeat किया जाता है
  • अगर ठीक 4 सैटेलाइट हों और configuration non-degenerate हो, तो direct solution निकाला जा सकता है
    • sky unobstructed हो तो अधिक सैटेलाइट दिखते हैं, और आम तौर पर least-squares solution इस्तेमाल होता है
  • implementation procedure निम्न flow follow करती है
    • raw pseudorange और satellite ephemeris को input के रूप में लेना
    • हर satellite के clock bias को calculate करना और pseudorange correct करना
    • संभव हो तो ionospheric/tropospheric corrections apply करना
    • current receiver clock bias से pseudorange correct करना
    • signal propagation time τ निकालने के लिए pseudorange को speed of light से divide करना
    • t-τ time पर satellite position calculate करना
    • τ के दौरान पृथ्वी के rotation को reflect करके satellite position को user ECEF frame से align करना
    • G matrix और pseudorange difference बनाना, और position तथा clock bias corrections calculate करना

Matlab implementation की details

  • Matlab code का अधिकांश हिस्सा दाईं ओर के known values से बाईं ओर के unknown को एक बार में evaluate करने वाले रूप में है
  • कुछ calculations के लिए analytical closed-form solution नहीं है, इसलिए solver चाहिए
    • example: satellite position calculation में mean anomaly M से eccentric anomaly E निकालने वाला step
    • E - e*sin(E) == M relation को closed-form में solve नहीं किया जा सकता, इसलिए vpasolve इस्तेमाल होता है
  • appendix code में ये functions शामिल हैं
    • user position और clock bias calculation
    • satellite position calculation
    • user position और clock bias के least-squares solution की calculation
    • satellite clock bias calculation
    • ECEF WGS84 coordinates को ellipsoidal coordinates में convert करना
    • ephemeris data format conversion

कच्चा GPS डेटा collect करने की setup

  • raw GPS data पाने के लिए ऐसे general GPS device की जगह receiver चाहिए जो सिर्फ internally position calculate करके output न करे, बल्कि raw pseudorange और satellite ephemeris जैसी timing information output करे
  • u-blox NEO-M8T और 6T chips requirements पूरी करते हैं
    • GPS unit, antenna और serial output port वाला hardware assembly Amazon पर लगभग 40 dollars में खरीदा जा सकता है
  • raw GPS signals receive और store करने के लिए RTKLib की STRSVR utility इस्तेमाल होती है
    • RTKLib GPS, Glonass, Galileo, Baidu आदि GNSS के standard और precise positioning को support करने वाला open-source program package है
    • STRSVR u-blox receiver के custom format output को RTCM standard format में convert करता है
  • जरूरी information RTCM messages 1002 और 1019 में होती है
    • 1002 raw pseudorange information रखता है
    • 1019 satellite ephemeris information रखता है
  • STRSVR को serial port 9600 Baud से data लेने और RTCM 3 format file में save करने के लिए configure किया जाता है
  • data collection apartment building की छत पर किया गया
    • GPS receiver को ऐसी जगह रखा गया जहां sky unobstructed हो
    • u-blox u-center software से verify किया गया कि पर्याप्त satellites दिख रहे हैं और अच्छा position fix संभव है
    • लगभग 1 घंटे का raw GPS data collect किया गया

RTCM processing और goGPS का उपयोग

  • STRSVR raw GPS data को binary RTCM3 format में save करता है
  • Matlab में process करने के लिए RTCM3 data को decode करके Matlab data structure बनाना पड़ता है
  • खुद RTCM decoder लिखने के बजाय goGPS Matlab library का load_stream function इस्तेमाल किया गया
    • यह RTCM format file पढ़ता है और RTCM messages extract करता है
    • extracted data को .mat file में save करके position calculation algorithm के input के रूप में इस्तेमाल किया जाता है
  • rtcm_data file भी दी गई है
    • WordPress security restrictions के कारण इसे .mat के बजाय .txt extension से दिया गया है
    • download करने के बाद इसे वापस .mat नाम देना होगा

Experiment results: position variation और clock drift

  • data collection के दौरान receiver stationary था, इसलिए calculated position में time variation position calculation algorithm की वास्तविक performance दिखाता है
  • user-centered ENU frame में position components के standard deviations इस प्रकार हैं
    • East: 14.00m
    • North: 39.88m
    • Up: 47.35m
  • position variation East और North directions में लगभग 30m के स्तर पर है, और Up direction में अधिक है
  • receiver clock bias constant नहीं है, बल्कि समय के साथ linearly drift करता है
    • algorithm में clock bias को distance units में handle किया जाता है
    • result plot में इसे speed of light से divide करके time units में convert किया गया
    • drift amount 4.27e-7sec/sec है

Satellite azimuth और elevation angle calculation

  • satellite azimuth और elevation angle user perspective से define होते हैं, इसलिए इन्हें user-centered ENU frame में calculate किया जाता है
  • calculation procedure इस प्रकार है
    • ECEF frame में user से satellite की ओर जाने वाला position vector calculate करना
    • user position को ellipsoidal coordinates, यानी latitude/longitude, में convert करना
    • उस position vector को user-centered ENU frame में rotate करना
    • ENU coordinates से azimuth और elevation angle calculate करना
  • example epoch में calculate किए गए 8 satellites के elevation angles सभी positive हैं
    • azimuth positive और negative दोनों हो सकता है
    • user horizon के नीचे satellites नहीं देख सकता, इसलिए elevation angle positive होना स्वाभाविक है
  • कई epochs में यही procedure इस्तेमाल करके satellite positions calculate करने पर GPS processing software दिखाने वाला satellite track chart बनाया जा सकता है

DOP: position estimation quality का geometric factor

  • DOP(Dilution of Precision) position estimation कितना अच्छा है, इसका metric है
  • position error पर measurement noise के साथ-साथ user-satellite geometry का भी प्रभाव पड़ता है
    • pseudorange और satellite position measurements जितने अधिक noisy होंगे, position error उतना बढ़ेगा
    • satellites azimuth और elevation angle में जितने ज्यादा फैले हों, geometry उतनी favorable होती है और DOP कम होता है
  • position और clock bias error का covariance user range error और G matrix के function के रूप में decompose होता है
    • G matrix user से satellite की ओर जाने वाले unit vectors से बनता है
    • ECEF frame का G matrix DOP calculation की सुविधा के लिए ENU frame में rotate किया जाता है
  • DOP components East, North और Up directions में define होते हैं
    • HDOP East और North components को combine करने वाला horizontal DOP है
    • VDOP Up component का vertical DOP है
  • actual data में HDOP और VDOP आम तौर पर 2.5 से कम हैं
    • यह value पर्याप्त मानी जाती है
    • VDOP, HDOP से बड़ा है
    • surface user horizon के नीचे satellites observe नहीं कर सकता, और horizon से 10 degrees से कम ऊपर वाले satellite signals भी बहुत noisy होते हैं इसलिए आमतौर पर इस्तेमाल नहीं किए जाते; इसी वजह से VDOP अधिक हो जाता है

GPS infrastructure का scale

  • GPS constellation बनाने में लगभग 30 billion dollars लगे, और अमेरिकी सरकार इसके maintenance पर सालाना लगभग 1 billion dollars खर्च करती है
  • Uber, जो GPS के बिना exist नहीं कर सकता था, उसका valuation 70 billion dollars से अधिक बताया गया है
  • GPS ने जिन कई applications को संभव बनाया, उन्हें शामिल करें तो GPS में public investment बहुत बड़े economic और technical impact का example माना जा सकता है

1 टिप्पणियां

 
GN⁺ 2024-07-16
Hacker News की राय
  • Android काफी समय से carrier phase approach तक access देता आया है, और इससे एक ही मोहल्ले के आसपास मौजूद devices के बीच relative position इतनी precision से निकाली जा सकती है कि यह भी मायने रखने लगे कि GNSS antenna device में कहाँ छिपा है
    अपने आप में यह बहुत असाधारण नहीं है, लेकिन हर device के accelerometer और gyroscope को भी साथ मिला दें तो यह बेहतर हो जाता है
    GNSS pseudorange measurements में बदलाव, device स्थिर न होने पर भी predictable होता है, इसलिए real-time में चलते हुए भी performance degradation कम रहता है
    उदाहरण के लिए, बिना पहियों वाले model airplane को truck bed में automatically land कराया जा सकता है, और खरोंचों या grass runway पर निर्भरता से भी बचा जा सकता है
    अगर power consumption बहुत critical नहीं है, तो काफी अच्छे GNSS receivers को भी महंगा बनाने की जरूरत नहीं होनी चाहिए; समझ नहीं आता कि 100 डॉलर में एक जोड़ी सीधे क्यों नहीं खरीद सकते

  • जो लोग खुद GPS receiver बनाना चाहते हैं, उनके लिए एक पूरी तरह open source project है जो theory भी काफी समझाता है: http://www.aholme.co.uk/GPS/Main.htm

    • वहाँ जिस project को link किया गया है और inspiration माना गया है, वह और भी प्रभावशाली है:
      https://lea.hamradio.si/~s53mv/navsats/theory.html
    • यह याद रखना चाहिए कि ITAR restrictions का उल्लंघन न हो, इसलिए जानबूझकर performance घटानी पड़ती है
  • GPS comments में अक्सर आने वाला, लेकिन अच्छे कारण से, एक लेख: https://ciechanow.ski/gps/

  • एक अलग explanation, और शायद ज्यादा interactive:
    https://ciechanow.ski/gps/

  • एक और अच्छा open source implementation है:
    https://m.youtube.com/watch?v=dVD1Yws__v0

  • मैंने ऐसे researchers देखे हैं जो aquatic animals के GPS data इकट्ठा करते हैं, जो कभी-कभी और वह भी बहुत थोड़ी देर के लिए ही पानी की सतह पर आते हैं
    raw data record करके बाद में post-process करने से power consumption और satellite signal के exposure की minimum duration दोनों काफी कम हो जाती हैं, और exposure time 1 second से भी कम तक जा सकता है

  • “नीचे की figure दिखाती है कि user-source geometry user position की uncertainty को कैसे प्रभावित करती है” वाला हिस्सा देखकर लगा कि phone map apps में location uncertainty का shape circle के बजाय इस तरह के arc-intersection form में बदलने की setting हो तो अच्छा होगा

  • सुना है कि GPS उन गिने-चुने applications में से एक है जहाँ रोजमर्रा की जिंदगी में relativistic effects को ध्यान में रखना पड़ता है। तो क्या generated data में ये relativistic effects पहले ही हटाए जा चुके होते हैं?

    • यहाँ “generated data” से आपका ठीक-ठीक मतलब क्या है, और किसके generated data की बात कर रहे हैं?
      अगर commercial GPS device का output है, तो हाँ। output generate करने के लिए acquisition के बाद की processing में तरह-तरह के error-inducing effects correct किए जाते हैं
      यह लेख कई satellites से stream होने वाले raw GPS data पर है, जिसमें output values बनाने के लिए processing चाहिए, और accuracy बढ़ाने के लिए अक्सर ground stations या maritime corrections जैसे extra inputs भी शामिल होते हैं
      कई GPS equipment vendors मोटे तौर पर ऐसा ही करते हैं, लेकिन details ही असली बात हैं
      दूसरे comments में link किया गया https://ciechanow.ski/gps/ भी पढ़ने लायक है
    • समय gravitational “force” की strength के हिसाब से, और ज्यादा सही कहें तो किसी object के Earth के mass से बनी spacetime curvature में गिरने की rate के हिसाब से अलग-अलग चलता है
      observer से तेज चल रहे objects में time भी धीमा चलता है, और satellites काफी तेज चलते हैं
      GPS में observer और satellite के बीच time synchronize होना जरूरी है, इसलिए time flow को special relativity और general relativity के effects reflect करने के लिए corrected किया जाता है
    • satellites तक की pseudorange error budget में relativity से जुड़े कई factors होते हैं, लेकिन position estimate पाने के लिए solve किए जाने वाले least-squares problem में वे बस error terms के साथ शामिल हो जाते हैं
      इसलिए relativity महत्वपूर्ण है, लेकिन अपनी position solve करने के लिए relativity बहुत ज्यादा जानना जरूरी नहीं है
      हालांकि long-baseline/network RTK के कई forms में ज्यादा sophisticated modeling की जरूरत हो सकती है
    • “relativistic effects” खुद GPS के काम करने के तरीके का हिस्सा हैं
  • अगला कदम PPP या RTK है। GNSS संभावनाओं की बहुत मजेदार rabbit hole है

  • flat earthers के लिए exercise: spherical Earth की परिक्रमा करने वाले satellites के बिना phone का GPS map कैसे काम करता है, समझाइए। अपना solution दिखाइए

    • अगर आप काफी मजबूती से मानते हैं कि सरकार आपको धोखा देना चाहती है, तो आप सोच सकते हैं कि हमने जो satellite physics सीखी है वह parallel construction(https://en.m.wikipedia.org/wiki/Parallel_construction) है और असल में भारी-भरकम mains power जोड़कर उसे flat Earth से मिलाया गया है
    • यह कहा जा सकता है कि phone सटीक location पाने के लिए किसी “magic”, यानी technology, का इस्तेमाल करता है
      पहले आपको यह साबित करने के लिए काफी जटिल argument देना होगा कि satellites के बिना phone ऐसा नहीं कर सकता
      इससे थोड़ा आसान और flat earthers के लिए टालना मुश्किल example यह है कि ISS लगभग नंगी आँखों से दिख जाता है और backyard telescope से तो साफ दिखता है। Starlink satellites भी ऐसे ही हैं
    • मेरे अनुभव में flat earthers इस सवाल का जवाब देने की कोशिश करने लायक rigorous inquiry नहीं कर पाते
      flat Earth कोई ऐसा stance नहीं है जिस तक reason से पहुँचा गया हो; यह लगभग हमेशा confusion से निकलता है या किसी अडिग core belief का अनिवार्य परिणाम होता है। आम तौर पर Bible को अत्यधिक literal तरीके से पढ़ने, या “official चीजें सब झूठ हैं” जैसे paranoid delusion से पैदा होता है