zbuffer

Cześć! Od pewnego czasu chodzi mi po głowie zmiana fokusera...a dokładniej za każdym razem jak widzę ugięcie mojego Baader Steeltrack 2'' (stara wersja, nie Diamond). Niby to cudo ma regulację w czterech punktach, na łożyskach, ale nawet po żmudnym ustawieniu ciągle coś nie gra. Wymieniłem nawet śruby do regulacji na normalne z łbem cylindrycznym, żeby nie obrobić gniazd wkrętów dociskowych. ale jak bym ich nie próbował skręcić (w granicach przyzwoitości) to i tak nie jestem w stanie wyeliminować ugięc i nie mam do tego fokusera zaufania. Korektor mam na chwilę obecną na nosku 2'' ale tutaj udało się wyeliminować tilt bo nosek ma w miarę dobry stożek. 1. Jakich fokuserów używacie? Jakie są ich plusy i minusy? 2. Jak mieć pewność, że dany prześwit fokusera jest wystarczający? 3. Co sądzicie o Primalucelab Esatto? Ktoś posiada? Warto? Pozdrawiam! P.S. Jedyne czego mi trochę żal, to faktu że wykonałem do niego przyzwoicie wyglądający i działający motofokuser, dzięki temu że oryginalnie na pokrętle ostrości są nacięte zęby koła pasowego.

To akurat nie problem bo sterownik może implementować dowolną kombinację interfejsów i być widoczny jako np. fokuser, montaż i stacja pogodowa. Zysk jest taki, że wszystkie narzędzia automatycznie współpracują (tak jest w Indi, ale pewnie Ascom ma coś podobnego, tylko ja Windows’a nie tykam brrr…;-). Ciekawy jestem kiedy napiszesz swoje planetarium…. Ja byłem na tej drodze dawno temu…

Oczywiście Twój wybór, nie rozumiem po co ta ironia... Przecież poza tym, że budujesz własną wersję montażu, chcesz go używać do robienia zdjęć, więc tak czy inaczej musisz jakoś obsługiwać kamerę, guiding itp. Poza tym jakoś przecież badasz wyniki swojej pracy i mając to zintegrowane w jednym środowisku miałbyś dostęp do zarówno standardowych elementów jak i Twoich własnych rozwiązań. Nie wymaga to aż takiego nakładu pracy. Programuję codziennie i też napisałem wiele własnych rozwiązań, ale są rzeczy, których po prostu głupio nie wykorzystać, szczególnie jakbyś chciał się z kimś tym pomysłem podzielić. Też nie przepadam za integracją z dużym softem napisanym przez kogoś innego, ale jak dokumentacja jest dobra i soft jest open source, uważam że warto. BTW też lubię kombinować przy sprzęcie więc nie widzę nic dziwnego w budowaniu swojego enkodera czy montażu, co zresztą planuję. W końcu zabawa nie polega tylko na ładnych fotkach ;-)

Ufff..... czemu nie korzystasz z narzędzi które są standardowe i dają Ci kontrolę nad całym setupem? To, że masz własny sterownik montażu w niczym nie przeszkadza - po prostu implementujesz driver dla EKOS'a, który będzie sterował Twoim montażem. Napisanie własnego driver'a teleskopu nie jest trudne, tak samo jak fokusera itp.

Nie wiem jak precyzyjny jesteś z tym ustawianiem, ale staram się robić to samo i błędy są w minutach... Swoją drogą nie wiem jak kontrolujesz teleskop. Ja używam EKOS'a i szczerze mówiąc ustawianie na Polarną to mniej niż 5 minut bo montaż sam się obraca, robi zdjęcia i pokazuje o ile co poprawić na żywo, odświeżając obraz z kamery. Trochę nieuzasadnione lenistwo nie ustawiać za każdym razem

Świetne te pyły! Mam dwa pytanka: 1. Wróciłem po dłuższej chwili na forum i nie kojarzę w jaki sposób można zrobić taki opis obiektów na zdjęciu jak u Ciebie? To jakiś soft czy coś online? 2. Skąd fotografujesz? Bo efekty są powalające jak na czas ekspozycji, a sprzęt znowu tak bardzo się nie różni od mojego… Pozdrawiam!

Hey! Ja postanowiłem dołożyć i kupić Prusa Mini+ i był to świetny zakup. Zero problemów, praktycznie bezobsługowa. Świetne stalowe płyty do druku, które nie wymagają żadnych klei i innych wynalazków i wydruki zdejmuje się banalnie prosto. Przed każdym wydrukiem wielopunktowa kalibracja stołu, nigdy nie trzeba nic ustawiać poza offsetem głowicy raz na początku. Kupiłem z dwoma płytami - PEI oraz teksturowaną. Ta druga jest do wydruków PETG. Drukuje tak samo dobrze niezależnie od materiału. Swoją drogą Prusament to też ciekawa sprawa - każda szpula ma pełną historię średnicy podczas produkcji, nawinięty perfekcyjnie. Poza tym zdecydowanie wole kupić produkt czeski niż chiński, ale to już sprawa indywidualna. Kolega ma Endera3 i jego wydruki są niezłe ale nie raz musiał coś wymienić, potem oczywiście kupić jakiś upgrade itp. i koniec końców wydał pewnie więcej niż na Prusę. Poza tym ta drukarka wymaga kalibracji stołu, zależnie od typu stołu może wymagać klei itp. Pozdrawiam!

@Tayson Wow! Dzięki za ten przykład! Muszę zdecydowanie poprawić swój warsztat co do obróbki zdjęć... @Grzegorz Czernecki Dzięki za stack'a. Postanowiłem zebrać materiał w idealnych warunkach - czyste niebo, nów, ostrość bardzo dobra, 30x300s - żeby sprawdzić czy to wina Księżyca i porównać ze stack'iem kolegi. Poniżej oba stacki w Pixie, zastosowany tylko STF, po lewej kolega po prawej ja. Jak dla mnie wynik jest ewidentny - na moim zdjęciu sygnał z otoczki jest zdecydowanie słabszy, inny jest kontrast pomiędzy częściami mgławicy. Wygląda to tak jakby filtr przepuszczał inne pasmo. Kolega ma filtr Antlia 3.5nm a ja Baader 8.5nm. Mimo że mój filtr jest znacznie szerszy wygląda jakby łapał niewłaściwe pasmo bo jakim cudem nie łapie tego co węższy... Nie wiem czy to może być tylko kwestia kontrastu? Czytałem na jednym zagranicznym forum, ze filtry 8.5 nm dają bardzo trudny w obróbce, ziarnisty obraz, co świetnie opisuje moje wrażenia - zawsze przez ten filtr klatki są zaszumione i sygnał kiepsko widoczny.

Dzięki wielkie. Przyglądnąłem się materiałowi i z jednej klatki jednak ciężko coś wywnioskować. Jestem jednak pewny że na Twojej klatce majaczy otoczka a u mnie jej praktycznie nie widać. Może byłoby to bardziej ewidentne na stacku... Jeśli mógłbyś się nim podzielić to będę podwójnie wdzięczny Swoją drogą spróbuję dzisiaj wypalić parę klatek w nowiu...jak to nie pomoże to chyba coś jest nie tak z filtrem.

@Grzegorz Czernecki Dzięki za ten przykład. Coś ewidentnie tu nie gra. Czy mógłbyś się podzielić jedną klatką tlenu? Chciałbym porównać ze swoimi. Mam filtr Baader 8,5nm, ze starej serii. Może potrzebuję węższego?

Załączony przez Ciebie link pokazuje typowe kolory - czerwień i niebieski. Moja obróbka przecież jest w innych kolorach. Dzięki temu zimne gwiazdy są pomarańczowe a nie czerwone. Co do tlenu to próbowałem w typowych kolorach i też kiepsko. Generalnie duży szum jak na czas ekspozycji. Przeczytałem gdzieś, że Księżyc masakruje OIII, więc to może być źródło problemu. Spróbuję dopalić w lepszych warunkach. Btw… czy to typowe że obraz przez OIII nie jest tak ostry jak przez Ha? Możliwe że korekcja dla tej długości jest gorsza w moim zestawie.

Cześć! Tym razem zmierzyłem się z kolejnym klasykiem, ale w moim stylu. Zdjęcie powstało z nietypowego połączenia obrazów z dwóch filtrów: Ha i OIII. Zastosowałem mały trik polegający na takim pomieszaniu kanałów, że udało mi się "oszukać" fotometryczną kalibrację koloru i zmusić ją do pracy, tak jakby to był obraz RGB. Idea była taka żeby uzyskać możliwie najbardziej poprawny kolor gwiazd. Starałem się też wyciągnąc możliwe największy kontrast na mgławicy. Zaskoczyło mnie jak ciężko jest wydobyć tą niebieską otoczkę... Ha 66x300s + OIII 98x300s Pozdrawiam!

Mam dla Ciebie jedną sugestię. Zainteresuj się implementacją filtru Kalmana do estymacji prędkości obrotowej osi. Mimo uśredniania pikseli będziesz się borykał z niepewnością/szumem wynikającymi z detekcji ruchu pasków i samej dokładności wykonania itp. Wystarczy liniowy filtr, w którym zamodelujesz obrót osi jako ruch ze stałą prędkością a enkoder będzie wprowadzał poprawki. Będziesz miał ciągły odczyt ruchu obrotowego z wysoką częstotliwością poprawiny co jakiś czas przez enkoder. Zaletą tego rozwiązania jest możliwość określenia kowariancji pomiaru i modelu czyli statystycznie określasz ich dokładność, zakładając rozkład Gaussowski błędów (co normalnie jest wystarczjącym przybliżeniem). Dodatkowo możesz potem rozwinąć model o dryft i inne składowe które zauważasz. Filtr Kalmana jest podstawową metodą estymacji wykorzystywaną praktycznie we wszystkich systemach pomiarowych, szczególnie jeśli zachodzi fuzja różnych sensorów. Ale dla jednego sensora też ma sens. Bez FK np. żaden dron by nie działał. Poszukaj „Kalman Filter” a ja tu podepnę link jak znajdę jeden fajny pdf, który widziałem.

A nie ma tam jakiejś regulacji osiowości? Poza tym może nie wyciąg tylko połączenie z teleskopem? U mnie w Baader Steeltrack są śruby do regulacji w dwóch płaszczyznasz ale szczerze mówiąc i tak wyciag się ugina od obciążenia

Tutaj próbka tego co miałem na myśli. Wrzuciłem teorię, kody i dodałem kilka gadżetów. Możesz zobaczyć jak fajnie w dokumencie można osadzić równania i wykresy. Colab jest używany przez wiele osób pracujących nad deep-learning i big data, bo google udostępnia w tym celu GPU. https://colab.research.google.com/drive/1jfG0PDYO3CoL4SINmCa-O2Aueiw7BlIB?usp=sharing Jak otworzysz wszystko powinno być policzone ale możesz odpalić z menu "Runtime -> Run all". Możesz dowolnie zmieniać kod, np testując sobie inne daty itp. bo ten link działa w opcji "viewer" - żadne zmiany nie zostaną zapisane w oryginalnym pliku. Jeśli chcesz zapisać zmiany musisz zapisać plik na swoim dysku google.

Nie wiem czy to koniecznie potrzebne bo np. używając Indi i Kstars możesz sterować wszystkim zdalnie. Jeżeli jednak widzisz jakieś zastosowanie to ja mam jeden pomysł - użyć ROS (Robot Operating System). Komputer podłączony do kamer musi mieć zainstalowane Ubuntu. ROS to zestaw bibliotek i narzędzi który pozwala na budowanie systemów rozproszonych, które oparte są o małe programiki (nodes) gadające ze sobą przez sieć. W robotyce jest praktycznie wszędzie, bo pozwala np. na umieszczenie sterowników sprzętu, nawigacji i systemu sterowania na komputerze robota (albo kilku komputerach połączonych w sieć) i umieszczenie mniej krytycznego oprogramowania w zewnętrznym komputerze, np. planowania trajektorii, które wymaga dużej mocy obliczeniowej. Wszystkie informacje publikowane przez nodes są dostępne dla każdego komputera w sieci. Jeśli chodzi o interfejs webowy to ROS zawiera już paczki które do tego służą (rosbridge_server, web_video_server). Wykorzystuje się to do tworzenia interfejsów web dla robotów. W ten sposób nie musisz instalować Ubuntu na pozostałych komputerach, tylko na tym, który jest podłączony do urządzeń. ROS zawiera sterowniki do większości sprzętu (tzn. istnieją paczki które instalujesz dla danego urządzenia), ale nie wiem jak z kamerami DS.

Chyba nie również tylko przede wszystkim… Cała idea programowania obiektowego czy jakiegokolwiek innego niż czysty assembler to kwestia zrozumienia programu przez człowieka i logicznego podzielenia go na funkcjonalne bloki, dane i ich wzajemne relacje. Szczególnie w językach kompilowanych, przy obecnym zaawansowaniu kompilatorów, program napisany na piechotę i taki używający klas i template’ów, po skompilowaniu będzie wyglądał tak samo. Nawet przekazywanie przez referencje i wartości nie ma już takiego znaczenia bo kompilatory doskonale się orientują gdzie nie trzeba kopiować pamięci itp. Wszystkie języki programowania zostały stworzone tylko po to żeby bardziej efektywnie pisać programy (wyrażać co się chce zrobić) a nie dlatego że to pomaga komputerowi w czymkolwiek. W nielicznych przypadkach ma znaczenie każda linia assemblera, ale to w programowaniu mikrokontrolerów…

Ok. Zawsze lepiej napisać żeby nie było żadnych problemów, bo teoretycznie jak coś wrzucasz bez licencji to nie wolno tego nikomu przesyłać dalej ani zmieniać.

Użycie Numpy albo nie to drugorzędna sprawa. Dla mnie szkoda fajnej inicjatywy, która wg mnie jest kiepsko podana. Jako astro amator chciałbym zrozumieć teorię, która stoi za obliczeniami, na ile to możliwe i np zobaczyć wykres z orbitą czy z drogą Słońca na niebie itp. Tutaj dostajemy kod z komentarzami lub nie, z mieszanką języków, i teorię wytłumaczoną w postach na forum albo w komentarzy do funkcji. W przypadku tego typu materiału naprawdę widzę duży potencjał użycia Jupyter Notebooks, bo to najlepsze narzędzie do celów edukacyjnych. Mówię z doświadczenia bo uczę robotyki na uniwersytecie (w Hiszpanii) i tu prawie każdy przygotowuje materiały i ćwiczenia w Notebooks. @Wiesiek1952 na jakiej licencji jest ten kod? Pytam bo w wolnym czasie mógłbym część przenieść do Colab i Ci pokazać co mam na myśli.

@Wiesiek1952 Rozumiem co masz na myśli ale to zupełnie nietrafione w przypadku biblioteki, która jest wykorzystywana przez naprawdę wszystkich do robienia obliczeń. Idąc takim rozumowaniem programowanie obiektowe i biblioteki w ogóle nie powinny istnieć. Kompletnie się nie zgadzam z podejściem, że wszystko trzeba pisać za pomącą czystego języka. Są pewne standardy i osoba początkująca musi je po prostu poznać, jeśli myśli o obliczeniach w Pythonie. To tak jakbyś powiedział, że ktoś ma liczyć zawsze na kartce chociaż istnieją kalkulatory. Trzeba najpierw nauczyć jakie są narzędzia i potem je wykorzystać. Szczególnie, że jeśli dobrze wytłumaczysz te narzędzia albo odeślesz do dobrze przygotowanych materiałów na ich temat to taka osoba pozna coś dzięki czemu zrozumie nie tylko Twój kod, ale niezliczone przykłady, które znajdzie w internecie. Nie ma chyba bardziej typowego początku programu niż te dwie linie: import numpy as np import matplotlib.pyplot as plt

Nie myślałeś o tym żeby do obliczeń używać biblioteki Numpy? Jak wszyscy…. Zamiast tych wszystkich pętli można po prostu użyć odpowiednich funkcji a indeksowanie „samo się robi”, jak w Matlabie. Nie podoba mi się to mieszanie języka polskiego z angielskim. Komentuję bo szkoda byłoby żeby Twoja praca i chęć dzielenia się wiedzą nie została doceniona przez sposób podania, który jest mało atrakcyjny i pewnie odstrasza początkujących. Jak będę miał chwilę to wrzucę jakiś Twój kod do Jupytera i zobaczysz co mam na myśli jeśli go nie używasz.

Moim zdaniem lepszym rozwiązaniem niż kod Python'a wrzucony tylko na GitHub byłoby skorzystanie z Jupyter Notebook's na jakimś darmowym serwisie. Nie używałem jeszcze ale dość popularny jest Colab od Google. Największa przewaga Jupyter Notebooks jest taka, że można napisać całą teorię, łącznie z formułami matematycznymi do każdej z funkcji, osadzone bezpośrednio w dokumencie. W ten sposób nie byłby to tylko kod ale baza wiedzy na temat obliczeń astronomicznych. Można do tego złączać obrazy no i generować wykresy osadzone w tym samym dokumencie. Dodatkowa przewaga jest taka, że używając Colab'a lub podobnych serwisów nie ma konieczności instalacji pythona ani żadnych bibliotek, bo wszystko działa przez przeglądarkę.

Hmm... najpierw przyszło mi na myśl żeby wykorzystać sinusoidę zamiast pasków, bo wtedy masz ciągłą zmianę wartości a nie tylko impulsy. Jednak rozumiem, że koło z drukarki jest tanie i jest to zaleta rozwiązania. Jeśli chodzi o uśrednianie, o którym mówisz, to w jakimś sensie może wyeliminować błędy losowe - defekty w paskach - ale z drugiej strony nie wyeliminuje błędu systematycznego, który wynika z dystorsji obiektywu i który musisz skalibrować. Inaczej Twoje uśrednianie może być gorsze niż wybranie pikseli z jednego rzędu czy kilku sąsiednich, w miejscu w którym dystorsja jest niska. Myślę jednak że użycie 2D ma inna przewagę. Zamiast robić naiwne uśrednianie jakichś gradientów, które nigdy nie będą perfekcyjnie równolegle do kolumn CCD, i walczyć z wieloma defektami w paskach które widzę na załączonej klatce z kamery, mógłbyś spróbować zastosować optical flow. Jest to metoda estymacji ruchu obrazu. Wykorzystywana jest np. w analizie modalnej z wykorzystaniem kamer. Rozdzielczość pomiaru sięga 1/100 wielkości piksela. Nie wiem czy to ma szansę działać na wspomnianym mikrokontrolerze, może potrzebne jest FPGA, ale mógłbyś spróbować z komputerem na początek. Główna zaleta jest taka, że nie ma znaczenia jak te paski wyglądają, właściwie może to być dowolna tekstura. Szybkie wyszukiwanie dało mi taki wynik na ten temat: https://learnopencv.com/optical-flow-in-opencv/ Prześledziłem mniej więcej i jedno czego nie rozumiem to dlaczego czekasz aż błąd przekroczy krok silnika zamiast używać sterowania mikrokrokowego? Druga sprawa to że ja bym oparł odtwarzanie o czas a nie enkoder, bo i tak nie ma on wystarczającej rozdzielczości. Dla mnie enkoder byłby użyteczny żeby rozpocząć odtwarzanie w odpowiednim momencie i dlatego zastosowałbym absolutny.

Ciekawe eksperymenty. Gratuluję zapału i trzymam kciuki! Kilka rzeczy mnie zastanawia. 1. Używasz kamerki i nie wykorzystujesz kompletnie faktu, że obraz jest 2d. Naprawdę nie warto zainwestować trochę w wydruk/grawer sinusoidy/cosinusoidy na kole? 2. Planujesz tą kamerę z optyką skalibrować (używając np. klasycznej szachownicy)? Dystorsja Ci wprowadzi kolejne błędy. 3. Aby skalibrować ten enkoder musisz mieć inny sensor, który mierzy o rząd wielkości dokładniej.... to raczej będzie trudne. Generalnie zastanawiam się czy sens ma używanie sensora, który sam w sobie będzie miał błąd okresowy, do korygowania innego błędu okresowego. Nie lepiej użyć prostego enkodera absolutnego na osi ślimaka i po prostu nagrać PEC'a w oparciu o guiding, i potem go precyzyjnie odtwarzać. Wystarczył by oczywiście nawet pojedynczy impuls ale z enkoderem absolutnym nie trzeba by tyle przewijać montażu na początku. Można by taki zewnętrzny PEC oprzeć o mikrokontroler i po USB połączyć z komputerem. Potem napisać driver, który będzie grał rolę guider'a - tzn. będzie odbierał pulsy, które mają iść do montażu i je modyfikował dodając PEC. Ja osobiście będę się mierzył z enkoderem RA w niedalekiej przyszłości, bo kupiłem w tym celu używany enkoder sin/cos za 170 eur. Mam jednak zamiar zmienić całą elektronikę montażu na własny projekt oparty o FPGA, bo chcę mieć bezpośrednią kontrolę nad napędami i przy okazji dodać kilka gadżetów. Poza tym soft montażu jest generalnie kiepski i brakuje wielu rzeczy (iOptron ieq45). Jak coś zacznę robić to na pewno stworzę wątek na forum, w celu utrzymania motywacji

Dzięki! Właśnie kolory gwiazdek (kalibracja fotometryczna Pix) są dla mnie bardzo ważne, bo osobiście to co mnie najbardziej zachwyca w zdjęciach okolic drogi mlecznej to mnogość i kolorystyka gwiazd. Nie rozumiem trendu zdjęć z usuniętymi gwiazdami…