Behlur_Olderys

Przy czym warto zauważyć, że SBIG utrzymuje: https://www.primalucelab.com/astronomy/adaptive-optics/sbig-ao-x-adaptive-optics.html że korekty wprowadza 10x na sekundę, co jest ekwiwalentem kręcenia filmu 10fps i stackowania. Wydaje się, że to nie jest limit AO dostępnego dla amatorów....

Jeśli ci amatorzy pracują w profesjonalnym, dofinansowanym obserwatorium... Profesjonalne AO nie jest warte zachodu dla mikro luster w stylu 16", myślę, że zabawa zaczyna się od 1m... Ale można spróbować nie-profesjonalnego AO;) Z tego co wiem, to AO pierwszego stopnia to korekcja tip&tilt : https://en.m.wikipedia.org/wiki/Adaptive_optics#Tip–tilt_correction Czyli zasadniczo gdyby ktoś miał na tyle jasną gwiazdę w guiderze (albo na tyle jasny guider ) żeby zbierać kilkadziesiąt klatek na sekundę, a jednocześnie posiadał montaż zdolny do wykonania kilkudziesięciu korekt na sekundę, i guidował seeing, to mamy prosty AO amatorski pierwszego rzędu. Mówiłem już kiedyś o tym przy innej okazji. Pewnie nawet kilka, kilkanaście korekt na sekundę da już zauważalne polepszenie rozdzielczości. Wydaje się to osiągalne dla amatorów, szczerze mówiąc to pewnie ktoś już to stosuje mniej lub bardziej świadomie. Pozdrawiam!

HAMAL, przecież Ty prezentowałeś już lepsze zdjęcia, niż rozdzielczość 1 arcsek, więc nie wiem, do czego wzdychałeś

Pytanie 1: czy ten podział naprawdę ma przełożenie na finansowanie, a jeśli tak, to jakie? Prosiłbym o dokumenty.... Pytanie 2: jeśli tak, to czy fizycy razem z astronomami i biofizykami nie wywalczą większej kasy razem - w sensie: żeby poszła na astro-bio-fizykę niż na teologię czy kulturoznawstwo? EDITED: jeszcze link żeby poczytać na spokojnie, a nie panika "likwidują astronomię" na którą niemal dałem się nabrać. https://legislacja.rcl.gov.pl/docs//506/12314504/12525374/12525375/dokument352505.pdf

Ja dokładnie tak właśnie robię swój "montażyk"

Na zdjęciu jest też Saturn w bardzo ciekawym towarzystwie

Czyli np. coś takiego: https://optcorp.com/products/fli-precision-digital-focuser-pdf Ale jaki jest algorytm liczenia tego PSF - podejmowania decyzji "już jest ostro" / "jeszcze nie ostro" ? To żaden problem precyzyjnie kręcić wyciągiem, problem to wiedzieć, kiedy już trzeba przestać kręcić

Hej, Mam takie pytanie: podobno (wg Wikipedii) większość dużych teleskopów używanych przez profesjonalnych astronomów to reflektory RC. Czy ktoś może wie, w jaki sposób przebiega procedura focusowania w takich maszynach (np. 2m lustro)? Maski Bathinova czy coś jeszcze bardziej wyrafinowanego? Przecież nie ostrzą "na oko" ani "mniej więcej".... Wydaje się, że musi to być robione ultra precyzyjnie, bo już z takim sprzętem to nie ma żartów. Jestem więc ciekaw, a nic konkretnego nie znalazłem w necie (trochę szukałem artykułów w temacie, ale może używałem złych słów kluczowych "ritchey chretien focusing" itp

Astronomia amatorska to - poza fotografią, która w epoce HST jest niestety najczęściej niemal bez jakichś większych walorów naukowych - jeszcze obserwacje egzoplanet, fotometria gwiazd zmiennych, spektrometria supernowych, rejestracje bolidów, .... lista jest długa. To nie jest żadna wycieczka śladami, ale bycie odkrywcą naprawdę. I te aktywności nie mają analogii do żadnego popularnego hobby, które znam. Chociaż szczerze przyznam - nie znam się aż tak, może wędkarze też mierzą ryby i publikują...

A teleskop, montaż - można zdradzić? Małym wiadrem do głębokiej studni szybko wody nie nalejesz Jakiś 16" newton czy co?

A gdyby całość dało się zrobić bez frezarki, bez drukarki 3d, bez zaprzyjaźnionego tokarza.... Żeby każdy mógł to zrobić też w domu - ech, marzenia

Co do alokacji: Najlepiej byłoby mieć wektor z alokatorem na statycznej tablicy, o ile mniej więcej można oszacować ile będzie tasków (a wydaje się, że raczej nie mówimy o jakimś intensywnym dodawaniu / odejmowaniu elementów). Z drugiej strony, jeśli aplikacja jest tak wyżyłowana performance'owo, że trzeba się martwić takimi rzeczami, to znak, że pora zastanowić się nad zmianą hardware'u Mi ten timer jest potrzebny właśnie po to, żeby bez względu na czas różnych innych operacji te kluczowe (obsługa krokowca) odbywała się bez zakłóceń. Pozdrawiam!

Chodzi mi o sprawdzenie, czy corner case'y będą dobrze pokryte, bo wydaje się że tak, ale ja już dawno przestałem ufać swojemu rozumieniu czytanego kodu, i muszę mieć wszystko przetestowane static_cast to wiadomo, że elegancka konstrukcja. Jakoś nie podoba mi się stosowanie raz long, raz unsigned long. Ogólnie - gdyby zaimplementować z boku gdzieś najprostszą protezę std::vector to mój "idealny" kod wyglądałby tak: (pseudo kod raczej) struct Task{ virtual bool IsValid(){ return true; } virtual void PerformIfReady(); } struct TaskWithCount : Task; vector<Task> tasks; tasks.emplace_back(Task(1)); tasks.emplace_back(TaskWithCount(1, 10)); for (task : tasks){ if (!task.IsValid()){ tasks.erase(task); }else{ task.PerformIfReady(); } } Oczywiście PerformIfReady trzeba by zaimplementować odpowiednio, tak jak sugerujecie, ale chodzi mi tylko o ogólną architekturę. PS Zrobił się wątek programistyczny na forum astro

Sytuacja jest taka: now = 1022 interval = 10 timeToWait = 1021 1. Start 2. Warunek spełniony 3. timeToWait := 7 (1031mod 1024) 4. doSomething(now==1022) 5. Powiedzmy, że mija 1ms (now:=1023) 6. Znowu wchodzimy do warunku 7. Warunek spełniony (7 < 1023) 8. timeToWait = 17 9. doSomething (now==1023) 10. Mija znowu 1ms (now:=0) 11. timeToWait > now() Następne doSomething odpali się za 17ms. Będziemy mieli 3 doSomething w czasie 20ms. Czyli średnio wychodzi ok Więc overflow timeToWait to nic groźnego na dłuższą skalę. Overflow now() jest dużo gorszy, bo timeToWait będzie np. 1023 a now() przekroczy już 0 i stracimy wszystkie wywołania! Napisałbym testy do tych funkcji i sprawdził wszystkie case'y z automatu static_cast wygląda najbardziej elegancko, ale znowu - muszę sam się przekonać

Nie mogę powstrzymać się od komentarza - zboczenie zawodowe: To dziwne, że można używać auto i lambdy z C++11, a nie można używać std::vectora, który mocno ułatwiłby sprawę Przez to, że masz "managera" tasków, który musi pilnować wskaźników, indeksów i pamięci Twój kod jest bardzo skomplikowany, a przecież z praktycznego punktu widzenia trzymanie wszystkich tasków razem w jednym obiekcie pamięci nie daje jakichś bezpośrednich korzyści, może poza tym, że jeśli task "wygaśnie" to go usuwasz i nie przetwarzasz niepotrzebnie (choć to marginalny zysk kilku cykli procesora na ewaluację 'ifa'). W moim rozwiązaniu każdy "task" to osobny obiekt, przez co nie muszę się martwić pamięcią (jest alokowana na stosie) ani indeksami (nie ma żadnych tablic). Zasadniczo rozróżnianie tasków "zwykłych" i ET wydaje się również niepotrzebne - no, chyba że oszczędność pamięci. Oczywiście te uwagi są pisane z perspektywy kogoś, kto na co dzień dysponuje 48-rdzeniowymi procesorami z setkami GB RAM-u, dlatego pewnie właśnie taka jest różnica między kodem "zwykłym" a embedded. Dlatego proszę, nie traktuj tego jako krytykę, a raczej jako analizę porównawczą PS Przepraszam za dwa posty, ale to dwie różne sprawy Może moderator jakiś połączy te dwa posty jeśli tak lepiej...

Miałeś rację, działa dokładnie tak samo! W sumie to prosta kalkulacja, trudno żeby matematyka się myliła, a jednak byłem trochę zaskoczony Kod jeszcze bardziej się upraszcza, a średni interwał pomiędzy wywołaniami i tak się zgadza co do ułamka mikrosekundy - super! (właśnie sprawdziłem na żywo)

Czy Czy generowałeś to ręcznie, czy korzystałeś z jakiegoś programu - jeśli tak, to jakiego? Chciałbym wkrótce (hm... ) spróbować zaobserwować jakąś egzoplanetę lustrzanką, i jestem ciekaw, jakie egzoplanety w ogóle mam szansę trafić - wydaje się to żmudnym zajęciem, dlatego pytam, jak Ty sobie radzisz?

Zaryzykuj jakąś gromadę kulistą Zawsze możesz zrobić ROI (chyba że nie możesz) na interesujący fragment i trochę zmniejszyć klatki. Tak Cię tylko podjudzam, bo fajnie by było jakby kolejna osoba poszła w temat wielkiej skali

Wydaje się, że dla gromad gwiazd mógłbyś spokojnie zejść z czasami naświetlania do ułamków sekund - a mógłbyś zyskać większy szczegół na gwiazdach. 8" to już fajna apertura do takich rzeczy, nie myślałeś spróbować bez reducera (z dwóch metrów...?) postrzelać? Mgławice to już gorzej przy f/10, bo są obiektami rozciągłymi, natomiast jasność gwiazd na zdjęciu zależy tylko od apertury, dlatego spróbowałbym ultra krótkie czasy i powiększenie na maksa - jak z planetami...

Może powinienem się zacząć uczyć więcej embedded, jest z tym dużo pracy dla programistów ostatnio

Ciekawe, chyba masz rację z tym timeAwaited, ciekawe co się stanie jak tak napiszę Może w weekend znajdę trochę czasu... Ale operatory przesunięcia w Twoim kodzie jakoś mnie zniechęcają strasznie

Hej, Chciałem się podzielić kodem, który dziś napisałem na potrzeby mojego montażu (do trybu testowo-awaryjnego). Jest to prosta, ale wszechstronna klasa odpalająca dowolną akcję w ściśle określonych interwałach. Jeśli np. chcemy, żeby nasz kod wykonywał jeden krok silnika krokowego na 12345 mikrosekundy z dużą dokładnością (kilkanaście us), to jest w sam raz rozwiązanie. Kod wygląda tak: void setup() { Serial.begin(115200); } template <typename Callable> // Callable to dowolny obiekt posiadający operator() struct ConstantTimedCaller{ /////////////////////////////////////////// ConstantTimedCaller(const unsigned long interval, Callable callable): // przekazujemy do konstruktora interwał i instancję obiektu (tworzy kopię!) żeby ją sobie wywoływać. m_timeStart(micros()), m_timeAwaited(0ul), m_interval(interval), m_callable(callable) { SetAwaitedTime(0ul); } /////////////////////////////////////////// void SetAwaitedTime(const unsigned long leftover){ m_timeAwaited = (unsigned long)(m_timeStart + m_interval - leftover); } /////////////////////////////////////////// // ta funkcja ogarnia odliczanie czasu i należy jej użyć w kodzie tam, gdzie chcemy coś realnie zrobić :) /////////////////////////////////////////// void CallWhenTime(){ const unsigned long timeNow = micros(); if (timeNow > m_timeAwaited){ m_timeStart = timeNow; SetAwaitedTime((unsigned long)(timeNow - m_timeAwaited)); // ta różnica jest kluczowa pomiędzy kolejnymi wywołaniami m_callable(); // wywołaj operator() obiektu, który tutaj przekazałeś } } unsigned long m_timeStart; unsigned long m_timeAwaited; const unsigned long m_interval; Callable m_callable; }; /////////////////////////////////////////// // Przykładowa funkcja do testów - wysyła na serial aktualny czas: /////////////////////////////////////////// void printTime(){ char lineBuffer[64] = {0}; sprintf(lineBuffer, "Time is: %20lu", micros()); Serial.println(lineBuffer); } typedef void (*voidFunctionPtr)(); // ten typedef jest po to, żeby powiedzieć template'owi jaki typ ma funkcja printTime (bo konstruktor się sam nie domyśli) ConstantTimedCaller<voidFunctionPtr> serialPrintCaller(1234567ul, printTime); /////////////////////////////////////////// // główna funkcja w Arduino /////////////////////////////////////////// void loop(){ serialPrintCaller.CallWhenTime(); // tak się tego używa :) // a tutaj poniżej już można sobie wywoływać cokolwiek chcemy. serialPrintCaller i tak wywoła się dokładnie o czasie! jakasFunkcja(); costam(); jakisInnyCallerZInnymInterwalem.CallWhenTime(); // też będzie działał zupełnie niezależnie! } Bardziej skomplikowany przykład użycia: struct OnBoardLedLighter{ OnBoardLedLighter(): m_isLedOn(false) {} void operator()(){ // ta funkcja jest odpalana przez callera. Można tu robić cokolwiek! toggle(); } void toggle(){ // mrugamy ledem... if (m_isLedOn){ digitalWrite(LED_BUILTIN, LOW); m_isLedOn = false; }else{ digitalWrite(LED_BUILTIN, HIGH); m_isLedOn = true; } } bool m_isLedOn; }; OnBoardLedLighter onBoardLedLighter; ConstantTimedCaller<OnBoardLedLighter> ledLighterCaller(900000ul, onBoardLedLighter); void loop(){ ledLighterCaller.CallWhenTime(); // będzie zapalać i gasić leda co 900 ms } Żeby sprawdzić, czy dobrze działa włączamy kod z pierwszego przykładu, uruchamiamy Serial Monitor i czytamy: różnica Time is: 2469172 1234572 Time is: 3703744 1234576 Time is: 4938320 1234544 Time is: 6172864 1234572 Time is: 7407436 1234572 Time is: 8642008 1234576 Time is: 9876584 1234572 Time is: 11111156 1234552 Time is: 12345708 1234592 Time is: 13580300 1234548 Time is: 14814848 1234556 Time is: 16049404 1234580 Time is: 17283984 1234552 Time is: 18518536 1234580 Time is: 19753116 1234556 Time is: 20987672 1234584 Time is: 22222256 1234560 ------------------------------------------------ Średnia: 1234567.29411765 Oczywiście, średnia to już policzone w excelu dla tych danych Jak widać, już kilkanaście próbek daje dosyć fajną średnią zbliżoną do oczekiwanej 1234567 mikrosekund. Dla 180 próbek średnia wyszła już: 1234567.09090909 To znaczy, że nawet jeśli momentami trochę przyspiesza lub spowalnia (odchylenie standardowe ok.13 us) to zasadniczo w dłuższym okresie czasu jesteśmy naprawdę bardzo dobrze synchronizowani. Nie jest to nic nowego ani odkrywczego, ale wydaje mi się, że to bardzo użyteczny kod, np. do sterowania krokowcem zgodnie z ruchem nieba... Można mieć kilka takich callerów uruchomionych jednocześnie i będą doskonale współdziałać. To bardzo wygodne. Pozdrawiam! PS: będę badał zachowanie w okolicach 4294967295 mikrosekundy, bo wtedy przekręca się licznik unsigned long (ponad godzinę od uruchomienia). Raczej nie powinno się nic złego dziać, ale może "przeskoczyć" kilka kroków.

Przed chwilą widziałem filmik na Polsacie - pod koniec Informacji. Podejrzewam, że to wasza sprawka? Gratuluję!

To są prawdziwe osiągnięcia, podziwiam i gratuluję!