AllSkyRadar - odwrócony flightradar

[spinka]

AllSkyRadar - pozycje samolotów są nakładane na podgląd nieba z kamery z obiektywem fisheye tzw. kamery AllSky,
w odróżnieniu od wyświetlania pozycji gps nałożonych na mapę.


Ostatnia wersja z historią lotu w formie trail-sów:


Wersja bez dodanych trail-sów, ale ze smugami widocznymi na niebie:

Legenda:
Wielkość czcionki i ilość linii opisu zależna od odległości.
Kolory:
- żółty - poniżej 5000m;
- czerwony - samolot przeleci w odległości nie większej niż X km;
- ciemnoczerwony - samolot przeleciał w odległości nie większej niż X km;
- magenta - samolot przeleci w odległości większej niż X km;
- fiolet - samolot przeleciał w odległości większej niż X km;
Kierunek wskazywany przez "o- - -" - track - kierunek lotu. Ale nie względem układu współrzędnych biegunowych, tylko "normalnie",
dlatego może to dziwnie wyglądać.
Ogonki - historia przelotu, ostatnich 10 pozycji - aktualizowane co 6s.
Punkt z gwiazdką to w ramach debug, pokazuje pierwszą zarejestrowaną pozycję.
Po 60s bez sygnału z reset.

W założeniu chciałem mieć tylko kamerę AllSky do podglądu pokrywy chmur jak jeszcze rok temu robiłem zdjęcia rnav,
ale temat się trochę rozwinął i skomplikował:



Ze względu na to, że mój widok na horyzont jest mocno ograniczony, to od samego początku używałem przeróbkę takiego programu w pythonie, który na bieżąco analizuje dane z dump1090 i oblicza w jakiej odległości będzie przelatywał dany samolot - wysyłając powiadomienie - takie SWO.
Drugą funkcją jest translacja pozycji gps na Alt/Az dla danej lokalizacji.

Output z tego programu odpalałem w konsoli na telefonie podczas robienia zdjęć (lewe górne okienko):

Na powyższym widać np. THA931 w odległości 100km, z informacją że będzie przelatywać 9km ode mnie, jeśli nie zmieni kursu.
A poniżej w momencie gdy przelatywał najbliżej, 2km pomyłki, ale w międzyczasie informacja o odległości w której przeleci była aktualizowana:

Kiedyś znalazłem taki program, który m.in. generuje trajektorie satelitów na układzie współrzędnych biegunowych, za pomocą biblioteki matplotlib w pythonie, korzystając z pozycji Alt/Az jako koordynatów.
Podobnie generowane są mapy nocnego nieba przy użyciu np. biblioteki astroplan:

Tak się składa, że układ współrzędnych biegunowych, całkiem ładnie nakłada się na obraz nieba z kamer typu AllSky.
Obraz z astroplan idealnie nadaje się też, żeby po nałożeniu na zdjęcie nocnego nieba, ustawić kamerę czy parametry do kalibracji położenia wykresu względem zdjęcia (na powyższym wygenerowany wykres jest luźno nałożony na zdjęcie bez kalibracji obrotu, przesunięcia i skalowania).

Szkielet tej części systemu, który wygenerował powyższe filmy wygląda mniej/więcej następująco (pewnie powinienem to rozrysować, ale na razie opis):

1. AllSky czyli Raspberry Pi Zero z kamerą wykonuje zdjęcia co 5s w dzień i co 10s w nocy (dla maksymalnego czasu ekspozycji) i zapisuje je na tmpfs (żeby nie zabić karty SD, zdjęcia z jednej kamery to ok 25GB na dobę);

2. Zdjęcia i dane np. temperatura, wysyłane są na bieżąco po wifi i trafiają na serwer (10 letni laptop z dwurdzeniowym cpu i linuxem daje radę);

3. Na serwerze odbywa się obróbka:

- nałożenie danych tekstowych na zdjęcie (METAR+kierunek wiatru, exif, temperatury, pomiar naświetlenia zdjęcia);
- przeskalowanie do rozsądnego 1080x1080px;
- wygenerowanie png z danymi samolotów wg aktualnych danych;
- nałożenie tego png na zdjęcie za pomocą ImageMagick;
- podmiana aktualnego zdjęcia dla gui/www;
- wpuszczenie końcowego zdjęcia w pipe dla procesu ffmpeg, który czeka w tle,
aby skompresować kolejne zdjęcia do formatu video h264;

To tak w bardzo dużym skrócie.
Siedzę nad tym cyrkiem w wolnych chwilach od roku.
Na początku wystarczało samo raspberry pi z kamerą żeby wyświetlić www z aktualnym zdjęciem.
Drugie rPi do adsb.
Potem doszedł dysk sieciowy z minimalnym shellem żeby mieć jakieś archiwum.

Na chwilę obecną system składa się z:
- trzech rPi Zero (bo kamery są dwie, a trzecia leży z podłączonym donglem i dump1090);
- starego laptopa, z półterowym hdd, jako serwera (mimo obróbki i kompresji w locie dwóch strumieni video nawet się nie grzeje);
- dedykowanego routera wifi;
- dysku sieciowego na ew. archiwum;

Trochę się kombajn rozrósł, ale może uda mi się to z czasem uprościć.
Póki co więcej dorzucam niż upraszczam.
A chcę jeszcze dodać do AllSkyRadar-u np. ISS i Iridium, generowane z TLE w podobnej formie jak samoloty.
Dodać nakładkę z pozycjami samolotów, na obraz drugiej kamery, którą robię zdjęcia horyzontu,
ale ze względu że jest obrotowa, to muszę jakiś system kalibracji wykombinować.
I całkowity odpał, który nie wiem czy ogarnę programowo i matematycznie, coś jak https://transit-finder.com,
ale przewidywanie czy aktualna trasa samolotu ma szansę na przecięcie tarczy Księżyca widocznej z danej pozycji.
Pewnie sporo nauki mnie czeka i pozostanie kwestia poprawności nadawanej pozycji.
Taki pomysł na razie - mam obsesję żeby złapać nocne AFR - już od dawna nie latają na a380, ale fiksacja pozostała.

To wszystko to raczej hydraulika/łączenie różnych rozwiązań niż pisanie od zera, ale jakoś to poskładałem i działa.

Przez wyżej opisane i przygodę z astrofoto, od ponad roku żadnych zdjęć rnav nie zrobiłem...

Pozdro,
AL

[spinka]

Obraz z drugiej kamery z pozycjami alt/az samolotów nałożonymi na prostokątny układ współrzędnych:

Takie coś podpatrzyłem kiedyś na screenie z PlanePlottera,
ale nie wiem czy można było tam podpiąć podgląd nieba pod generowane ślady samolotów.

Trochę zniekształcenia obiektywu z polem widzenia 170° psują efekt, ale w wycinku klatki z którego korzystam są do przyjęcia.

Edit:
Jest i AFR188:

.

[vader]

Przejrzałem w końcu ten temat i jest to bardzo fajna sprawa. Dodatkowo opcja alertów do przelotów, super! Może kiedyś się sam za to zabiorę, na pewno wtedy się skontaktuję

[spinka]

Powiadamianie mailowe o zbliżających się lotach które przelecą w pobliżu powinno działać na czystym pythonowym flight-warning Darrena bez dodatkowego dłubania w kodzie i na danych z dump1090. Jak trochę ogarnę swój kod to też go udostępnię, ale byłoby dobrze gdyby udało mi się go zoptymalizować i dawał radę działać na Raspberry Pi3 np. razem z dump1090. Jeszcze trochę krzaków się zdarza, ale podgląd semi-live jest. W bieda-wersji możnaby nakładać dane na statyczne zdjęcie otoczenia, ale to pewnie jest dostępne w planeplotte-rze.

Obecnie opóźnienie tego co widzę w podglądzie w gui do stanu na niebie wynosi 5-15s zanim się zdjęcia z obu kamer przemielą przez całą skryptową obróbkę. Pozycje alt/az w konsoli idą bez tak dużych opóźnień - na początku zastanawiałem się czy dałoby się to wykorzystać do sterowania jakimś montażem azymutalnym typu AZ-EQ6 czy innym GoTo, ale w miarę jak z tego korzystałem przy ręcznym kierowaniu syntą uznałem, że jednak precyzja musiałaby być o wiele większa. Do tego po wstępnym namierzeniu w ten sposób i tak byłby konieczny jakiś guiding żeby montaż podążał za obiektem albo rozsprzęglanie napędu i prowadzenie ręczne. Odpuściłem ten temat, już o cenie zestawu który dałby radę to robić i nadążyć, nie wspominając.

Timelapse z dzisiejszych testów na horyzontalnej kamerze:



Trochę szarpie wyświetlanymi pozycjami, bo dłubałem w międzyczasie. Do kalibracji dorzucam na wykres dodatkowo pozycje planet i gwiazd, tym razem z użyciem pythonowej biblioteki ephem, do najjaśniejszych obiektów wystarcza i jest szybsza niż kobyła astroplan/astroplot.

Napęd obrotu kamery nie jest super i ma spore luzy na zębatkach więc synchronizacja nakładki z obrazem wymaga ręcznej kalibracji po wykonaniu obrotu.

[spinka]

Przez jakiś czas skupiałem się na wschodach/zachodach Słońca i deflickeringu, bo trochę mało czystego nieba było na coś innego. Zrezygnowałem z tego wąskiego cropa na kamerze obrotowej, który wycinał górną część obrazu i tą dystorsję. To trochę namieszało bo nałożenie kartezjańskiego układu współrzędnych na taki obraz oczywiście słabo wyglądało. Korekcja każdego zdjęcia żeby wyeliminować dystorsję nie była optymalnym rozwiązaniem więc zastosowałem dystorsję oraz kilka innych przekształceń i korekcji, dla nakładanych na obraz współrzędnych. Metodą prób i błędów kalibrację zrobiłem na gwiazdach. Brak możliwości wypoziomowania kamery też nie pomagał, więc kalibracja na E wymaga kolejnej korekcji na SE itd, ale też jakoś to się udało w miarę ogarnąć. W sumie chyba 13 parametrów się składa na takie "powygninanie" żeby wyświetlane pozycje mniej-więcej się nakładały na obraz.
Przez chwilę kombinowałem z kompasem/akcelerometrem, ale w obudowie kamery jest za ciasno, za dużo metalu i pól magnetycznych - niewypał ale fajna zabawa, pewnie wykorzystam go jakoś z teleskopem. Docelowo spróbuję użyć opencv żeby rozpoznawał kominy i inne elementy horyzontu na zdjęciu do automatycznego pozycjonowania nakładki - może kiedyś.
Dodałem też wyświetlanie trajektorii ISS z 10 minutowym wyprzedzeniem, ale wciąż nie miałem okazji potwierdzić z widocznym przelotem.
W sumie widocznych zmian chyba niewiele, dużo porządkowania kodu, przerzucam do pythona co się daje, np. zrezygnowałem z ImageMagick na rzecz opencv i pillow w pythonie. Dużo optymalizacji. Fajny poligon do dłubania. Widzę że 3 miesiące temu już pisałem, że postaram się to odpalić wszystko na pojedynczej rPi3 żeby zobaczyć czy sobie poradzi, tak wciąż mam to w planie, bliżej niż dalej.

Tu timelapsy z dzisiejszego dnia z widocznymi smugami:
Edit: na poniższych filmach deflickering nie był zastosowany.





Screeny z ISS:

[vader]

Rewelacyjnie to wygląda. Moja żona, to zobaczyłą chwilę temu i mi powiedziała "Ale fajne. Kiedy sobie takie zrobisz?" Informuj na bieżąco co poprawiłeś, co chcesz zrobić. To usunięcie "migotania" obrazu znacznie poprawiło odbiór filmów.

W sumie ta różnica rzeczywistego położenia samolotu (smuga) do tej, która jest przez ciebie wyświetlana również wygląda ok. Dobrze widać smugę i dane.

[spinka]

W sumie ta różnica rzeczywistego położenia samolotu (smuga) do tej, która jest przez ciebie wyświetlana również wygląda ok. Dobrze widać smugę i dane.

Na pewno jakieś przesunięcie w pionie jest, może za duża krzywizna na dole + minimalne przesunięcie w pionie, jak się zbierze trochę materiału porównawczego to pewnie dojdę co i jak.
Ale ze smugami, to już zauważyłem wcześniej, trzeba brać pod uwagę że wiatr je czasem znosi.
Edit: No w sumie dobrze że źle... Ale wolałbym dodawać od siebie przesunięcie niż z przypadku.

To usunięcie "migotania" obrazu znacznie poprawiło odbiór filmów.

Powyższe filmy bez deflickeringu. Obecnie pobierane zdjęcia w pełnej rozdzielczości, bez nakładki z samolotami i gwiazdami, są po wstępnym przycięciu i opisaniu zapisywane jako jpg, a deflickering, korekcje krzywych kolorów i kompresję do mp4 robię, na mocniejszej VM, jak trafi się coś ciekawszego. Ale podczas wstępnej obróbki jednocześnie przeskalowuję te same zdjęcia do 1080p i dostają nakładkę przed zapisaniem do jpg, zaraz potem trafiają do podgladu www, do mp4, i są usuwane na bieżąco. Te ostatnie mp4 służą w zasadzie jako archiwum, no migotanie pozostaje. Próbowałem deflickering robić w czasie rzeczywistym, ale potrzebne są bufory i ogólnie cała sytuacja się komplikuje, wzrasta zapotrzebowanie na moc obliczeniową, więc niechętnie ale się chwilowo poddałem.
Całe to przetwarzanie z nakładkami zajmuje 1.3s - 2.5s na zdjęcie, przy dwóch kamerach i jednoczesnej kompresji obu źródeł do mp4.

[spinka]

Informuj na bieżąco co poprawiłeś, co chcesz zrobić.

Z rzeczy które chciałbym jeszcze dodać, to na pewno ostrzeganie o możliwości przecięcia tarczy Księżyca przez przelatujący samolot.

Przy każdej pełni żałuję, że się za to jeszcze nie zabrałem. Teraz znowu ten temat mnie męczy, bo ostatnie dwie noce kombinowałem jak się zabrać za nagranie zaćmienia. Poprzednie latem na SE, robiłem z tarasu Syntą postawioną na platformie paralaktycznej Leszka Jędrzejewskiego. Poniedziałkowe zaćmienie na W, będę mógł tylko przez okno/szybę obserwować (o ile w ogóle pogoda dopisze) i nie chciałem do tego zaprzęgać Synty z platformą i dslr, bo efekt końcowy niby-timelapse poprzedniego mnie nie przekonał. Tryb filmowania na mojej lustrzance jest słaby i daje też nie najlepszy efekt. No i jeszcze konieczność "resetowania pozycji platformy" co ok godzinę. Odkopałem więc starą "idioten-hd-kamerę zoom x200" i zamontowałem ją na StarAdventurerze w ramach kompromisu. Do powiększenia x20 nie włącza się "digital zoom" i da się ustawić manualnie czas migawki w zakresie 1/4000 - 1/2s, czy zablokować ostrość, a to do sfilmowania zaćmienia powinno wystarczyć.

Podczas testowania, czy ten zestaw uchwyci całą drogę Księżyca podczas zaćmienia, miałem nadzieję że coś przeleci przez kadr.
Przy 1/1000s Księżyc w pełni na tej kamerze jest dobrze naświetlony i powinno to dać nierozmazaną sylwetkę samolotu na jego tle.
Przy 25fps byłaby szansa na kilka klatek.

Opcjonalnie do takiego polowania mógłbym rozstawiać sprzęt z włączonym prowadzeniem i nagrywaniem licząc na szczęśliwy traf. Trochę jednak szkoda tak bezproduktywnie orać karty sd i zębatki oraz nie sprawdziłoby się to w przypadku platformy z teleskopem i dslr.

W niedzielę nad ranem obserwowałem przez okno ruch z Izraela po L617 i z Azji po L735, pozycja Księżyca akurat ładnie się zbiegała z tymi trasami:

Niestety żadnego trafienia. CCA431 był bardzo blisko, startujący LOT9006 zawinął się tuż obok.

Z niedzieli na poniedziałek zobaczyłem, że leci AFR102 i nawet szybko na taras kamerę wystawiłem, ale trochę jednak przestrzelił:

Nocne AFR-y nad Poznaniem latają chyba po L979 w stronę Azji, powrotne mniej więcej tą samą trasą, ale mają dość spory rozrzut, zakładam że często korzystają ze skrótów.

Chciałem zrobić "ostrzeganie/powiadamianie" w dwóch fazach:
1. Wyliczać kiedy z danego punktu obserwacji da się zobaczyć tarczę Księżyca przechodzącą przez dane drogi lotnicze - co by ułatwiało wcześniejsze zaplanowanie sesji. - Ale ten pomysł w związku ze zniesieniem stałych dróg lotniczych nad Polską chwilowo odpada, okaże się po wprowadzeniu w życie przestrzeni POLFRA, może nie będzie aż tak losowo jak sobie wyobrażam.
2. Wyliczanie dla każdego samolotu czy jego obecny kierunek/wysokość lotu daje szanse, że zbliży się do tarczy Księżyca widocznej z danej pozycji - to dawałoby chwilę, góra kilka minut na przygotowanie się. Przede wszystkim jednak eliminowałoby z listy przeloty bez szans na tranzyt.

To tak w ramach rozwinięcia myśli sprzed paru miesięcy.

W sumie eksperymenty z tą kamerą, którą planowałem zaćmienie filmować teraz mnie trochę zmotywowały. Może nie da się nią zrobić dobrych zdjęć przelotówek, ale tak jakby większe pole manewru teraz mam, przynajmniej żeby złapać sylwetkę samolotu na tle Księżyca czy też - z filtrem - na tle Słońca tam gdzie bym się Syntą nie wyrobił.

[spinka]

Coś chyba udało mi się posklejać.

Samolot lecący na określonej wysokości musi się znaleźć na niewiadomych współrzędnych lat/lon aby z danego punktu obserwacji znaleźć się w pobliżu tarczy Księżyca.
Te współrzędne można wyliczyć ze wzorów (zaczerpniętych z: http://www.movable-type.co.uk/scripts/latlong.html pod hasłem "Destination point given distance and bearing from start point"):

φ2 = asin( sin φ1 * cos δ + cos φ1 * sin δ * cos θ )
λ2 = λ1 + atan2( sin θ * sin δ * cos φ1, cos δ − sin φ1 * sin φ2 )

φ1 - lat punktu obserwacji
λ1 - lon punktu obserwacji
φ2 - lat punktu w którym musiałby znaleźć się samolot
λ2 - lon punktu w którym musiałby znaleźć się samolot
δ - niewiadoma odległość kątowa (od punktu obserwacji do punktu w którym musiałby znaleźć się samolot) / Promień Ziemi
θ - bearing - w tym przypadku Azymut na którym widoczny jest Księżyc

Odległość kątową od punktu obserwacji do punktu w którym musiałby znaleźć się samolot można wyliczyć ze wzoru:
δ = ((sin β * FL) / sin α ) / PZ

α - Kąt Alt na jakim widoczny jest Księżyc
β - 90 - α
FL - Wysokość lotu minus wysokość npm punktu obserwacji
PZ - Promień Ziemi = 6371km

Flight_warning.py Darrena do określenia w jakiej odległości od punktu obserwacji przeleci dany samolot korzysta z:
"haversine formula" oraz "Cross-track distance" (również opisanych pod w/w linkiem).
W przypadku operacji z Księżycem w miejsce punktu obserwacji każdorazowo podstawiam współrzędne z powyższych wyliczeń,
które "wędrują" wraz ze zmianami pozycji Księżyca.

W teorii daje to w przybliżeniu odległość w jakiej przeleci samolot od tarczy Księżyca.
W praktyce przydałoby się jeszcze brać pod uwagę różnicę czasu w jakim to nastąpi, robiąc obliczenia dla pozycji Księżyca, dla czasu gdy samolot tam doleci.
Ale bez tego każde następne obliczenie w miarę jak samolot się zbliża do interesującego nas punktu ma większą precyzję.

Czy to działa?

Na czerwono zaznaczyłem kolumny z wyliczoną odległością w jakiej samolot przeleci od idealnych lat/lon nad którymi przeciąłby tarczę Księżyca.
Na zielono w jakiej odległości jest od tych idealnych lat/lon.
Ostatnia kolumna to odległość od punktu obserwacji do idealnych lat/lon.


Sam jestem ciekawy jak to się sprawdzi na dłuższą metę.

[vader]

Pamiętaj też o Słońcu. Czekam na aktualizację i wynik testów :)

[spinka]

Pamiętaj też o Słońcu. Czekam na aktualizację i wynik testów :)

To w zasadzie formalność, mogę podpiąć obliczenia pod każdy obiekt obsługiwany przez PyEphem.
Na screenie poniżej np. dla Marsa, bo akurat wisi wyżej nad horyzontem.
Dodałem też dla testów dodatkową linię, w opisie na podglądzie, z wyświetlaniem odległości w jakiej przeleci samolot od idealnych koordynatów.
Docelowo chyba zmienię to na odległość kątową w jakiej przeleci samolot od wskazanego obiektu na niebie - wyświetlaną np. dla wartości poniżej 3°. Odległość kątową chyba łatwiej zinterpretować wizualnie niż km w tym przypadku.

[spinka]

Chciałem widzieć przewidywaną odległość kątową i w sumie pozmieniałem cały sposób obliczeń.
Zamiast liczyć "cross-track error" czyli jak daleko przeleci samolot od punktu w którym musiałby się znaleźć żeby przelecieć przez wskazane Alt/Az na niebie - teraz liczę gdzie się przetnie tor lotu z azymutem na którym widzę np. Słońce. To wyliczenie daje mi lat/lon tego przecięcia, a to razem z wysokością lotu daje Alt/Az punktu przecięcia. Azymut będzie ten sam, ale różnica pomiędzy Alt np. Słońca i Alt punktu w którym przeleci samolot mi daje odległość kątową, która jest bardziej miarodajna od odległości w kilometrach.

Poniżej dwa przykłady z podglądu nieba - KAC117 i OHY476, które przestrzeliły o ok 10° oraz AAF887, który prawdopodobnie przeszedł przez tarczę Słońca. Ostatnia linia w opisach to aktualna odległość samolotu w km do przecięcia azymutu Słońca i przewidziana odległość kątowa od Słońca w punkcie przecięcia.

Teraz tylko czyste niebo by się przydało żeby przetestować to w praktyce.

-----------------
Kacper1607 mnie trochę podpuścił i krążę myślami w okół tematu aplikacji na androida z rysowaniem maszyn na niebie bez aktualnego zdjęcia, sam wykres w takiej formie jak na AllSky, coś jak na screenie poniżej. Źródłem danych musiałoby być API z pozycjami samolotów zamiast własnego odbiornika. Ew. połączenie zdalne do własnego źródła danych. Do tego obliczanie Alt/Az samolotów dla aktualnej pozycji w jakiej znajduje się użytkownik. Pewnie będę eksplorował ten temat, na razie to bardzo luźny pomysł.