Pythonowe śledzenie satelitarne z pozycjami spg4, pyephem nie pasującymi do

Question

Próbuję napisać podstawowy skrypt pythona, który będzie śledził danego satelitę, zdefiniowanego za pomocą t, z danej lokalizacji. Nie jestem osobą asto/orbitalną, ale staram się być mądrzejszy.

Występuje problem, w którym różne modele, których używam, dają mi bardzo różne odpowiedzi na temat pozycji. Próbowałem, używając: pyEphem spg4 przewidzenia (exec wywołania systemowego ze skryptu)

Satelity jestem testowania są z ISS i directv10 (jeden stały, jeden moving- ze śledzeniem internetowe za weryfikację):

0 Direct10 
1 31862U 07032A 13099.15996183 -.00000126 00000-0 10000-3 0 1194 
2 31862 000.0489 046.9646 0000388 001.7833 103.5813 01.00271667 21104 
0 ISS 
1 25544U 98067A 13112.50724749 .00016717 00000-0 10270-3 0 9148 
2 25544 51.6465 24.5919 0009906 171.1474 188.9854 15.52429950 26067 

Zmodyfikowałem źródło przewidywania, aby podać lokalizację e-mail, dzięki czemu mogę użyć tej informacji, aby poznać rzeczywistą lokalizację. Mam również, aby podać zakres az, el, do wykorzystania do weryfikacji obserwacji. Używam spg4 do uzyskania prawdziwej lokalizacji. W przypadku obserwowanej lokalizacji używam PyEphem.

Dostaję pozycję ECEF z spg4 z:

def get_real(epoch, sv): 
satellite = twoline2rv(sv.tle1, sv.tle2, wgs84) 

#epoch = time.time() 
obsTime = datetime.datetime.utcfromtimestamp(epoch) 
position, velocity = satellite.propagate(obsTime.year, 
             obsTime.month, 
             obsTime.day, 
             obsTime.hour, 
             obsTime.minute, 
             obsTime.second) 


x = position[0] 
y = position[1] 
z = position[2] 

x *= 1000 
y *= 1000 
z *= 1000 

mojego kodu do obserwacji w oparciu pyephem jest:

def get_ob(epoch, sv, obsLoc): 
site = ephem.Observer() 
site.lon = str(obsLoc.lat) # +E -104.77 here 
site.lat = str(obsLoc.lon) # +N 38.95 here 
site.elevation = obsLoc.alt # meters 0 here 
#epoch = time.time() 
site.date = datetime.datetime.utcfromtimestamp(epoch) 

sat = ephem.readtle(sv.name,sv.tle1,sv.tle2) 
sat.compute(site) 

az  = degrees(sat.az) 
el  = degrees(sat.alt) 
#range in m 
range = sat.range 
sat_lat = degrees(sat.sublat) 
sat_long = degrees(sat.sublong) 
# elevation of sat in m 
sat_elev = sat.elevation 

#TODO: switch to using az,el,range for observed location calculation 
#x, y, z = aer2ecef(az,el,range,38.95,-104.77,80/1000) 
x,y,z = llh2ecef(sat_lat, sat_long, sat_elev) 

Konwersja llh2ecef:

def llh2ecef (flati,floni, altkmi): 
#   lat,lon,height to xyz vector 
# 
# input: 
# flat  geodetic latitude in deg 
# flon  longitude in deg 
# altkm  altitude in km 
# output: 
# returns vector x 3 long ECEF in km 

dtr = pi/180.0; 

flat = float(flati); 
flon = float(floni); 
altkm = float(altkmi); 

clat = cos(dtr*flat); 
slat = sin(dtr*flat); 
clon = cos(dtr*flon); 
slon = sin(dtr*flon); 

rrnrm = radcur (flat); 
rn  = rrnrm[1]; 
re  = rrnrm[0]; 

ecc1 = ecc; 
esq1 = ecc1*ecc1 

x  = (rn + altkm) * clat * clon; 
y  = (rn + altkm) * clat * slon; 
z  = ((1-esq1)*rn + altkm) * slat; 

return x,y,z 

aer2ecef:

def aer2ecef(azimuthDeg, elevationDeg, slantRange, obs_lat, obs_long, obs_alt): 

#site ecef in meters 
sitex, sitey, sitez = llh2ecef(obs_lat,obs_long,obs_alt) 

#some needed calculations 
slat = sin(radians(obs_lat)) 
slon = sin(radians(obs_long)) 
clat = cos(radians(obs_lat)) 
clon = cos(radians(obs_long)) 

azRad = radians(azimuthDeg) 
elRad = radians(elevationDeg) 

# az,el,range to sez convertion 
south = -slantRange * cos(elRad) * cos(azRad) 
east = slantRange * cos(elRad) * sin(azRad) 
zenith = slantRange * sin(elRad) 


x = (slat * clon * south) + (-slon * east) + (clat * clon * zenith) + sitex 
y = (slat * slon * south) + (clon * east) + (clat * slon * zenith) + sitey 
z = (-clat *  south) + (slat * zenith) + sitez 

return x, y, z 

Kiedy porównuję i wykreślam lokalizacje na globusie 3D (używając pozycji ECE), otrzymuję odpowiedzi w każdym miejscu. Przewidywana pozycja eci (przekonwertowana na ecef) jest zgodna z tym, co widzę na stronach śledzenia ISS (http://www.n2yo.com/?s=25544)

Wynik z get_real() jest daleko poza skalą i lokalizacją. Wynik z get_ob() mają rację w skali, ale nie tak w miejscu na kuli ziemskiej

wyniki przykład:

przewidzieć na podstawie:

sv: ISS predict observed response @ epoch: 1365630559.000000 : [111.485527, -69.072949, 12351.471383] 
sv: ISS predict aer2ecef position(m) @ epoch: 1365630559.000000 : [4731598.706291642, 1844098.7384999825, -4521102.9225004213] 
sv: ISS predict ecef position(m) @ epoch: 1365630559.000000 : [-3207559.6840419229, -3937040.5048992992, -4521102.9110000003] 
sv: ISS predict ecef2llh(m)  @ epoch: 1365630559.000000 : [-41.67839724680753, -129.170165912171, 6792829.6884068651] 
sv: Direct10 predict observed response @ epoch: 1365630559.000000 : [39.692138, -49.219935, 46791.914833] 
sv: Direct10 predict aer2ecef position(m) @ epoch: 1365630559.000000 : [28401835.38849232, 31161334.784188181, 3419.5400331273049] 
sv: Direct10 predict ecef position(m) @ epoch: 1365630559.000000 : [-9348629.6463202238, -41113211.570621684, 3419.8620000000005] 
sv: Direct10 predict ecef2llh(m)  @ epoch: 1365630559.000000 : [0.0046473273713214715, -102.81051792373036, 42156319.281573996] 

pyton bazie:

sv: ISS ephem observed response @ epoch: 1365630559.000000 : [344.067992722211, -72.38297754053431, 12587123.0][degrees(sat.az), degrees(sat.alt), sat.range] 
sv: ISS ephem llh location(m)  @ epoch: 1365630559.000000 : [-41.678271938092195, -129.16682754513502, 421062.90625][degrees(sat.sublat0, degrees(sat.sublong), sat.elevation] 
sv: ISS ephem xyz location(m)  @ epoch: 1365630559.000000 :[-201637.5647039332, -247524.53652043006, -284203.56557438202][llh2ecef(lat,long,elev)] 
sv: ISS spg84 ecef position(m) @ epoch: 1365630559.000000 : [4031874.0758277094, 3087193.8810081254, -4521293.538866323] 
sv: ISS spg84 ecef2llh(m)  @ epoch: 1365630559.000000 : [-41.68067424524357, 37.4411722245808, 6792812.8704163525] 
sv: Direct10 ephem observed response @ epoch: 1365630559.000000 : [320.8276456938389, -19.703680198781303, 43887572.0][degrees(sat.az), degrees(sat.alt), sat.range] 
sv: Direct10 ephem llh location(m)  @ epoch: 1365630559.000000 : [0.004647324660923812, -102.8070784813048, 35784688.0][degrees(sat.sublat0, degrees(sat.sublong), sat.elevation] 
sv: Direct10 ephem xyz location(m)  @ epoch: 1365630559.000000 :[-7933768.6901137345, -34900655.02490133, 2903.0498773286708][llh2ecef(lat,long,elev)] 
sv: Direct10 spg84 ecef position(m) @ epoch: 1365630559.000000 : [18612307.532456037, 37832170.97306267, -14060.29781505302] 
sv: Direct10 spg84 ecef2llh(m)  @ epoch: 1365630559.000000 : [-0.019106864351793953, 63.80418030988552, 42156299.077687643] 

AZ , el i range nie pasują między dwiema obserwacjami. Pozycje nie pasują do "prawdziwych" lokalizacji. (Długość i długość nie ma znaczenia, ale nie po konwersji ecef2llh.)

W porównaniu z webowym trackerem, zauważam, że przewidywane "prawdziwe" lokalizacje odpowiadają tej stronie. Dla directv10, pyEphem odpowiada azymutowi i elewacji - ale nie dla ISS

Kiedy wykreślam je na kuli ziemskiej, przewiduję "prawdziwą" lokalizację eci we właściwym miejscu - pasuje do strony trackera. Pozycja spg84 ecef (która, jak myślałem, powinna być taka sama jak przewidywana, znajduje się po drugiej stronie kuli ziemskiej) Przewidywanie "obserwowanej" lokalizacji jest zbliżone do lokalizacji spg84.PirEphem jest całkowicie wyłączony na wysokości i nie jest wyświetlany (zbyt niski, wewnątrz ziemi)

Moje pytanie brzmi: czy używam modeli Pythona źle?Rozumiem, że wywołanie propagacji spg84 powinno zwrócić pozycję exec satelity w metrach. Pomyślałem, że powinien pasować do przewidywanej pozycji po konwersji eci2efec. Też oczekiwałbym, że mecz następnie llh2ecef() przy użyciu sat.sublat, sat.sublong, sat.levation.

Jak już powiedziałem, jestem nowy w stosunku do wszystkich rzeczy na orbicie, więc jestem pewien, że popełniam prosty błąd matematyczny lub cokolwiek. Próbowałem google i wyszukiwać odpowiedzi, przykłady i samouczki w jak największym stopniu, ale nic nie pomogło do tej pory (próbowałem wielu metod ecef2llh i llh2ecef, aby spróbować rozwiązać te błędy.)

Wszelkie sugestie, porady, wskazówki we właściwym kierunku byłbym bardzo doceniony.Mogę wysłać/wysłać kompletny e-mail, jeśli byłoby to pomocne dla kogoś.By próbowałem upewnić się, że zamieściłem tu ważne części i nie chciałem tego zrobić (już bardzo) długi post i dłużej.

Dzięki za pomoc.

Aaron

AKTUALIZACJA:

Znalazłem conajmniej część problemu. spg84.propagate() zwraca lokalizację w ECI, a nie ECEF. Szybki przebieg przez eci2ecef i idealnie komponuje się z przewidywaną reakcją.

zawsze wydają się znaleźć rozwiązania po zaksięgowaniu o pomoc;)

Teraz trzeba dowiedzieć się, co dzieje się z miejsc obserwacyjnych. Sprowadza się to do: Jak mogę pobrać wynik z pyEphem.compute() i uzyskać pozycję ecef dla satelity? Wolisz robić to za pomocą wartości az, el, range, a nie szerokości, długości, wysokości.

Zgaduję błąd w moim wywołaniu aer2ecef.

Dzięki.

UPDATE 2:

Got obserwację linii z pozycji "prawdziwego". Wygląda na to, że miałem problem z jednostkami. Kod pracy:

az  = degrees(sat.az) 
el  = degrees(sat.alt) 
#range in km 
range = sat.range 
sat_lat = degrees(sat.sublat) 
sat_long = degrees(sat.sublong) 
# elevation of sat in km 
sat_elev = sat.elevation 


#x, y, z = aer2ecef(az,el,range,obsLoc.lat,obsLoc.long,obsLoc.alt) 
x,y,z = llh2ecef(sat_lat, sat_long, sat_elev/1000) 

x *= 1000 
y *= 1000 
z *= 1000 
return x,y,z 

Teraz wystarczy aer2ecef metodę(), aby powrócić właściwej pozycji ...

Answer 1

Jeśli mógłbyś podać link do nowej pytanie otwarciu, a także oznaczyć tę odpowiedź z zielone pole wyboru, to pytanie nie będzie już wyświetlane jako pytanie bez odpowiedzi na PyEphem w Stack Overflow i tłumie konsole tych z nas, którzy szukają odpowiedzi na pytania bez odpowiedzi w tej dziedzinie. Dziękuję, że podzieliłeś się swoją pracą za tych, którzy mogą podążać w twoich krokach!