Jump to content

Elektronika koziołka i wilgoć


Adm2
 Share

Recommended Posts

Mam glupi pomysl. Sterowanie autoguiderem mozna rozwiazac bezprzewodowo, przez WiFi. Zamiast np Arduino Pro Mini mozna uzyc ukladu opartego na ESP8266 (je rowniez mozna programowac w Arduino). Przykladowa plytka: Wemos D1 mini.

Na komputerze tworzymy wirtualny port szeregowy, komunikujacy sie z napedem poprzez TCP/IP. Podajemy go w konfiguracji progamu do guidingu.

 

Wady:
- wlaczamy WIFi w laptopie, co skraca jego czas pracy na akumulatorze
- zwiekszamy lag od wydania komendy do momentu jej realizacji
- i tak pozostaje kabel komputer-kamera autoguidera, wiec zysk jest niewielki

 

Moze ktos jednak bedzie chcial sie koniecznie pozbyc jednego kabla, laczacego komputer z koziolkiem ;-) Podobnie, bezkablowo mozna tez rozwiazac sterowanie kolem filtrow, motofocusem itp.

Edited by r.ziomber
Link to comment
Share on other sites

Jak dla mnie najlepiej byłoby mieć wszystko wbudowane w montaż, a podłączać tylko kabel zasilania.

Jeśli do naświetlania zdjęć potrzebujemy tylko niewielkiej ilości funkcji (autoguide, kontrola ekspozycji, kontrola montażu) to lepiej byłoby mieć dedykowane urządzenie(-a?) przy montażu zajmujące się tylko tymi rzeczami, zamiast podłączać wszystko do komputera, czyli zasadniczo do kombajnu, który może zrobić wszystko.

Wyobrażam sobie - kiedyś - że mój ATM montaż będzie miał właśnie takie 2-3 puszeczki malutkie, może w jednej będzie jakiś wyświetlacz z kalkulatora, ale raczej diodki, trochę guzików, poza tym zasilacz i jeden, gruby kabel do prądu :) Może dlatego, że jeszcze nie próbowałem "poważnej" astrofotografii, ale zawsze wydawało mi się, że dodawanie do zestawu laptopa mija się z celem i niepotrzebnie komplikuje sprawę okablowania... życie zweryfikuje ten idealizm :)

Link to comment
Share on other sites

na Raspberry Pi 3 można zainstalować Win 10 wiec może się udać też zainstalować jakieś oprogramowanie astro

ma to 4 rdzenie 64-bit, wifi i 4xUSB. Czego chcieć więcej?

 

pozdrawiam

Edited by ZbyT
Link to comment
Share on other sites

To jest specjalna wersja WIn 10, niepotrafiaca uruchamiac aplikacji przeznaczonych dla zwyklego Windowsa. Powodem jest architektura sprzetowa (x86 vs. ARM). Np pod Linuksem najpierw trzeba uruchomic emulator x86 - Qemu-i386, a dopiero potem pod nim Wine, by uruchomic aplikacje Windowsiane.

Na szczescie Linux powinien bez problemu poradzic sobie z astrofotografia.

INDI Library on Raspberry PI

Edited by r.ziomber
Link to comment
Share on other sites

Behlur_Olderys, kiedyś też myślałem, że napiszę sobie wszystko sam i zacząłem Tworzyć soft typu Maxima (nie wiedząc, że takie coś istnieje). Jak się skapowałem, że są już gotowe rozwiązania wszystkich moich problemów, to zrezygnowałem. Szkoda czasu na wynajdywanie koła na nowo! Poza ogormem czasu, jaki trzeba na takie coś poświęcić jest jeszcze druga sprawa - taki Twój soft nie jest w żaden sposób uniwersalny. Jest stworzony dla jednej, konkretnej konfiguracji sprzętowej i zmieniając cokolwiek trzeba pisać obsługę urządzenia na nowo. Również nie ma sensu takiego rozwiązania udostępniać innym, bo i tak nikt nic z tego nie zrobi bez przepisania połowy.

 

Komputer to wcale nie jest przerost formy nad treścią. Komputer daje Ci ogromną uniwersalność, każde produkowane urządzenie bez problemu do niego podłączysz i będzie działać. Na komputer jest dostępna masa softu i na prawdę już praktycznie wszystko zostało wymyślone i zakodzone. Komputer daje możliwość łatwej zmiany funkcjonalności - wystarczy coś nowego zainstalować. A dlaczego Windows? Bo na Windowsa jest ogromny wybór softu astro i po prostu wszystko jest na niego zaimplementowane. Na linuxa bardzo wielu rzeczy brakuje i będzie brakować.

 

Komputer to nie musi być od razu wielki blaszak, czy laptop 17" z i7. Jest wiele miniaturowych komputerów, wielkości tego chlubnego RaspberryPi. Ale w odróżnieniu od Raspberry, na tych komputerkach uruchomisz wszystko i wszystko będzie działać.

 

Jako student informatyki mógłbym pewnie sobie wybrać jako temat pracy inżynierskiej napisanie takiego softu na Raspberry, który by sterował teleskopem. Tylko po prostu nie widzę w tym żadnego sensu, zyski z tego będą niewielkie, a ilość poświęconego czasu ogromna. Lepiej zająć się czymś bardziej przydatnym.

Link to comment
Share on other sites

ale przecież wystarczy tylko poprosić twórców oprogramowania żeby skompilowali wersje na arma :flirt:

To poproś Difracion Limited, żeby Maxima na arma wydali :P Potem pisz do wszystkich producentów kamer, montaży, focuserów, kół filtrowych, kopuł i czego tam jeszcze. Jak już skończysz- daj znać :)

Link to comment
Share on other sites

A dlaczego Windows? Bo na Windowsa jest ogromny wybór softu astro i po prostu wszystko jest na niego zaimplementowane.

Mowimy tu o komputerze do rejestracji. Obsluga autoguidingu (w tym watku kluczowa, bo rozwazamy prowadzenie "koziolka") czy tez znacznej czesci kamer dziala pod Linuksem bez problemu. Sluzy do tego wspomniany pakiet INDI. Umozliwia on tez pelna automatyzacje obserwacji.

Ogromna zaleta Raspberry Pi jest wieksza energooszczednosc od wiekszosci maszyn x86.

Raspberry Pi - Power Consumption

 

Na linuxa bardzo wielu rzeczy brakuje i będzie brakować.

Akurat jesli chodzi o profesjonalne pakiety do obrobki danych (np IRAF, MIDAS czy tez dedykowane aplikacje do redukcji danych satelitarnych jak np CIAO) to... czesto pisane sa tylko dla Linuksa/MacOSa. Pod Windowsem trzeba sie bawic w Cygwina.

 

Potem pisz do wszystkich producentów kamer, montaży, focuserów, kół filtrowych, kopuł i czego tam jeszcze. Jak już skończysz- daj znać :)

Nie musisz sie o to martwic. Deweloperzy INDI robia to za Ciebie :)

 

Nie zbaczajac z glownego tematu watku - Raspberry Pi spokojnie poradzi sobie z autoguidingiem koziolka, korzystajac z juz istniejacego softu ;-)

Edited by r.ziomber
Link to comment
Share on other sites

Prawda jest taka, że gdybym chciał korzystać z gotowych rozwiązań, to kupiłbym EQ-5 czy coś takiego, a nie budował Fastrona :)
Traktuję to jako zabawę, hobby. Oczywiście, nie odlewam samodzielnie śrubek z własnoręcznie wykopanej rudy żelaza... Ale chciałbym spróbować trochę softu popisać tego typu. Zawsze można sobie do CV później wpisać: embedded real time systems programming project ;)

  • Like 1
Link to comment
Share on other sites

Szkoda czasu na wynajdywanie koła na nowo! Poza ogormem czasu, jaki trzeba na takie coś poświęcić jest jeszcze druga sprawa - taki Twój soft nie jest w żaden sposób uniwersalny. Jest stworzony dla jednej, konkretnej konfiguracji sprzętowej i zmieniając cokolwiek trzeba pisać obsługę urządzenia na nowo. Również nie ma sensu takiego rozwiązania udostępniać innym, bo i tak nikt nic z tego nie zrobi bez przepisania połowy.

Jak opublikujesz kod zrodlowy, ktos inny bedzie mogl skorzystac z Twojego algorytmu, poprawiajac go jedynie o protokol komunikacyjny do swojego urzadzenia.

 

PODOBNO (sie nie znam) programisci systemow wbudowanych potrafia czytelnie rozdzielac swoj kod zrodlowy na czesc "sprzetowa" (zalezna od konkretnej platformy mikrokontrolerow) od uniwersalnej logiki dzialania programu. Dzieki temu przeportowanie funkcjonalnosci na inny sprzet jest znacznie latwiejsze.

 

Pamietajmy, ze:

- MaximDL jest platny (a EQ-5 drozszy od poszczegolnych czesci do budowy koziolka)

- jest zamknietozrodlowy, przez co dziala tylko na platformie "namaszczonej" przez producenta. Przez to nie uruchomimy go na Raspberry Pi :-)

- po mimo, ze doskonaly, jest szansa, ze ktos bedzie potrzebowal funkcjonalnosci w nim niezawartej. Jesli bedzie mial dostep do kodow zrodlowych innych aplikacji, bedzie mogl je jedynie zmodyfikowac, bez koniecznosci pisania calego oprogramowania od podstaw.

 

Jesli Behlur_Olderys podzieli sie z nami kodem zrodlowym, na pewno bedzie sie mozna z tego wiele nauczyc. To nic, ze funkcjonalnie niekoniecznie przekroczy gotowe, komercyjne rozwiazania.

Edited by r.ziomber
Link to comment
Share on other sites

- po mimo, ze doskonaly, jest szansa, ze ktos bedzie potrzebowal funkcjonalnosci w nim niezawartej. Jesli bedzie mial dostep do kodow zrodlowych innych aplikacji, bedzie mogl je jedynie zmodyfikowac, bez koniecznosci pisania calego oprogramowania od podstaw.

Tak, jest sporo rzeczy, których w Maximie brak. Ale ma on tą świetną właściwość, że ma bardzo dobre API - można z nim zintegrować inną aplikację, która uzupełni jego funkcjonalność. Jest wiele przykładów na takie podejście, że Maxim jest używany jako łącznik między sprzętem, a oprogramowaniem (z uwagi na to, że obsługuje każde urządzenie astro). W takim wypadku zewnętrzna aplikacja, o funkcjonalności wyższej niż Maxim używa go jedynie jako taką "przejściówkę" (takie podejście jest np w sofcie ASA lub innym, umożliwiającym pełną automatyzację, czego w Maximie trochę brakuje).

Także mimo zamkniętości oprogramowania jest ono jednak bardzo elastyczne.

  • Like 1
Link to comment
Share on other sites

Oczywiście, zarówno abstrakcja algorytmu od sprzętu jak i rozszerzalność kodu to ważne zasady programowania. Ale zanim zacznę pisać swojego Maxima to jeszcze długa droga :) na razie podejście "wszystko samemu" daje mi efekty na tyle obiecujące, że jeszcze dużo zrobię fotek, zanim się przesiądę na gotowe rozwiązania za xxxxzł :)

Link to comment
Share on other sites

Macie trochę wyobraźni trójwymiarowej? :-)

 

Zrobiłem przed chwilą test koziołka z szukaczem. Coś gdzieś jest nie tak, tylko gdzie?

Znalazłem dwie gwiazdki koło siebie i wycelowałem w jedną o 1:30

Okazuje się że gwintu mam na trochę ponad półtorej godziny.

O godzinie 3:00 gwiazdki wyglądały jak na rysunku niżej.

Nie mogłem zdjęcia zrobić, więc narysowałem na szybciora.

Wygląda jakby gwiazda była na środku szukacza przez cały czas (na boki), ale na północ uciekła.

 

Ta moja poziomica do ustawiania poziomu podstawy aż tak dokładnie nie pokazuje, to i kąt na polarisa może nie pasować.

 

 

DSC_0096b.JPG

Edited by Adm2
Link to comment
Share on other sites

To jest specjalna wersja WIn 10, niepotrafiaca uruchamiac aplikacji przeznaczonych dla zwyklego Windowsa. Powodem jest architektura sprzetowa (x86 vs. ARM)

 

chodziło mi raczej o aplikacje typu APT czy FC skompilowane pod Raspberry. To chyba nie powinien być problem

 

 

No momencik, panowie, a to co Wy chcecie uruchamiać, że potrzeba Windowsa od razu?

 

to pokazuje możliwości tego maleńkiego komputerka

nic nie stoi na przeszkodzie by zrealizował wszystkie zadania potrzebne w trakcie fotografowania. W końcu ma moc obliczeniową większą niż laptopy z pojedynczym, a nawet dwoma procesorami czyli takie sprzed kilku lat, a te potrafiły sprostać wszystkim zadaniom związanym z astrofotografią. Dzięki wifi można obsługiwać sesję zdalnie, a 4 porty USB zapewnią sterowanie kamerami, fokuserami czy kołami filtrowymi

 

 

Behlur_Olderys, kiedyś też myślałem, że napiszę sobie wszystko sam i zacząłem Tworzyć soft typu Maxima (nie wiedząc, że takie coś istnieje). Jak się skapowałem, że są już gotowe rozwiązania wszystkich moich problemów, to zrezygnowałem. Szkoda czasu na wynajdywanie koła na nowo!

 

słuszne podejście. Sam chciałem zbudować od zera sterownik do montażu paralaktycznego ale gdy okazało się, że istnieje AstroEQ odpuściłem. Z zasady nie robię urządzeń, które są dostępne. Buduję tylko takie jakich nikt nie konstruował lub gdy istniejące rozwiązania mają jakieś wady i przez to nie spełniają moich wymagań

 

nie podejmuję się też budowy urządzeń, które są tak skomplikowane, że ich budowa zajmie na tyle dużo czasu, że po skończeniu będą już przestarzałe

 

pozdrawiam

  • Like 1
Link to comment
Share on other sites

Przydaje się jeszcze robić open source hardware i software, jeśli nie istnieje.

 

Wydaje mi się, że w zwiazku z niskim kosztem i popularnością platformy arduino (oryginalna płytka ok 70 zł, zamiennik kilkanaście zł), jak również prostotą jej programowania i użytkowania możnaby opracować prosty sterownik dla wszelkiego typu koziołków/fastronów. Coś takiego mogłłoby się składać z:

 

-projektu shielda umożliwiajacego kontrolę silnika krokowego oraz włączanie/wyłączanie/przewijanie. wykonana tak, aby każdy mógł sobie to polutować z dostępnych w sklepach elementów.

-projektu zasilania najlepiej opartego wymiennie na koszyku baterii/zasilaczu usb 5V.

-kodu sterującego

-arkuszu kalkulacyjnym lub małym programie umożliwiającym wyliczenie sekwencji prędkości dla napędów typu koziołka/klon astrotraca/napęd ze ślimacznicą jak np w tym temacie: http://astromaniak.pl/viewtopic.php?f=5&t=42026

 

Tematu guidingu bym narazie nie ogarniał, ale można w przyszłości dodać, umożliwiajać sterowanie wszystkim z jakiegoś komputerka z podłączoną kamerą do guidingu.

  • Like 2
Link to comment
Share on other sites

to banalnie proste

do zrobienia w jeden weekend

przypuszczam, że takich rozwiązań wiele już istnieje i ktoś to wreszcie opublikuje

jakby co to przypominam, że zamieściłem kiedyś pełną dokumentację prostego fokusera. Wystarczą drobne przeróbki w programie aby napędzić tym koziołka

 

pozdrawiam

  • Like 1
Link to comment
Share on other sites

Właśnie z opublikowaniem to jest generalnie problem. Trzeba po pierwsze to zrobić, a po drugie umieć to zrobić, a to nie jest takie łatwe w przypadku hardware. Myślę, że mógłbym napisać program w pythonie liczący prędkości krokowca i kręcący nim program do arduino. Mniej więcej mam pojęcie co ma robić shield. ale np. nie wiem jak zaprojektować sterownik krokowca(kupiłem gotowy) tak, żeby to było łatwo odtwarzalne.

Mogę też np. wykonać w autocadzie prosty plik .dxf zawierajacy potrzebne do wycięcia elementy ze sklejki do wykonania koziołka, tak, aby ktoś mógł kupić sobie arkusz 10 mm sklejki, pojsc do punktu gdzie wycinaja litery do reklam itp.i wyjść z porządnie wyciętymi elementami, tylko poskręcać.

  • Like 1
Link to comment
Share on other sites

oś obrotu koziołka nie pokrywa się z osią szukacza. trzeba go skolimować otwierajac i zamykając koziołka i porównując widok w okularze, powinien być taki sam.

 

Dzięki.

 

Nie wiecie może czy nie ma jakiegoś szukacza który jest w rurce o stałej średnicy? Można by było go do któregoś rogu na koziołku docisnąć.

Te co mam mają różną średnicę na dwóch końcach. I ten krzyżyk zasłania to w co się celuje.

Link to comment
Share on other sites

Coś zacząłem rzeźbić.

 

Jak narazie jest to skrypt w Pythonie, jak ktoś ogarnia podstawy to może skorzystać, pewnie nadam temu bardziej humanitarną formę w najbliższym czasie

Jest też chyba trochę niedokonczone, ale pokazywać powinno poprawne wartosci, zrobie update jak będę miał chwilę.

 

Chciałbym wpakować tam jakieś projekty hardware, miło by było, gdyby ktoś się przyłączył;)

 

https://github.com/piroman999/Astrotracker

 

 

 

 

  • Like 2
Link to comment
Share on other sites

Mój program w domyśle bazuje na założeniu, że jedyna zmienna, której potrzebuję do ruchu montażem, to odstęp pomiędzy kolejnymi krokami silnika krokowego.

Każdy krok silnika to pewne drobne przesunięcie ramienia o stałą odległość dy. Zakładając, że odstęp czasowy dt jest na tyle mały, że można pominąć wyrazy większe niż liniowe wychodzą mi bardzo ładne funkcje odstępu pomiędzy krokami (dt) w zależności od czasu, jaki montaż już działa (zakładam bowiem, że prędkość kątowa ramienia jest równa prędkości kątowej Ziemi = omega).

Dzięki temu, po drobnych przekształceniach wychodzi prosty wzór:

 

delta t = dy * cos(omega*t)^2 / (R * omega) dla koziołka ze śrubą prostopadłą do ramienia

 

delta t = dy / (R * omega * cos(omega * t / 2 )) dla napędu nożycowego

 

Moim zdaniem wzory są na tyle proste, że można je obliczać na bieżąco w arduino. Jedyna zmienna to czas działania.

Pewien problem, to że odstęp pomiędzy krokami trzeba podać jako całkowitą liczbę milisekund, a wyniki wychodzą jako liczby zmiennoprzecinkowe.

Ale to akurat można łatwiutko obejść zapisując na boku resztę dziesiętną i dodając ją do każdego następnego t.

Drugi problem to skończony czas na obliczenia - tutaj trzeba byłoby skorzystać z dokładnych funkcji mierzenia czasu zamiast prostego delay.

 

Jak tylko znajdę więcej czasu to przedstawię swoją wersję programu, jakkolwiek czysto teoretyczną, bo ostatnio rozwaliłem koziołka aby transformować go do wersji nożycowej. Efekt: zostałem z niczym :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Our picks

    • Droga Mleczna w dwóch gigapikselach
      Zdjęcie jest mozaiką 110 kadrów, każdy po 4 minuty ekspozycji na ISO 400. Wykorzystałem dwa teleskopy Takahashi Epsilon 130D i dwa aparaty Nikon D810A zamocowane na montażu Losmandy G11 wynajętym na miejscu. Teleskopy były ustawione względem siebie pod lekkim kątem, aby umożliwić fotografowanie dwóch fragmentów mozaiki za jednym razem.
        • Love
        • Thanks
        • Like
      • 36 replies
    • Przelot ISS z ogniskowej 2350 mm
      Cześć, po kilku podejściach w końcu udało mi się odpowiednio przygotować cały sprzęt i nadążyć za ISS bez stracenia jej ani razu z pola widzenia. Wykorzystałem do tego montaż Rainbow RST-135, który posiada sprzętową możliwość śledzenia satelitów.
      Celestron Edge 9,25" + ZWO ASI183MM. Czas ekspozycji 6 ms na klatkę, końcowy film składa się z grup 40 klatek stackowanych, wyostrzanych i powiększonych 250%.
      W przyszłości chciałbym wrócić do tematu z kamerką ASI174MM, która z barlowem 2x da mi podobną skalę, ale 5-6 razy większą liczbę klatek na sekundę.
      Poniżej film z przelotu, na dole najlepsza klatka.
        • Love
        • Thanks
        • Like
      • 62 replies
    • Big Bang remnant - Ursa Major Arc or UMa Arc
      Tytuł nieco przekorny bo nie chodzi tu oczywiście o Wielki Wybuch ale ... zacznijmy od początku.
       
      W roku 1997 Peter McCullough używając eksperymentalnej kamery nagrał w paśmie Ha długą na 2 stopnie prostą linie przecinajacą niebo.
       
      Peter McCullough na konferencji pokazał fotografię Robertowi Benjamin i obaj byli pod wrażeniem - padło nawet stwierdzenie: “In astronomy, you never see perfectly straight lines in the sky,”
        • Love
        • Thanks
        • Like
      • 16 replies
    • Jeśli coś jest głupie, ale działa, to nie jest głupie - o nietypowych rozwiązaniach sprzętowych
      Sformułowanie, które można znaleźć w internetach jako jedno z "praw Murphy'ego" przyszło mi na myśl, gdy kolejny raz przeglądałem zdjęcia na telefonie z ostatniego zlotu, mając z tyłu głowy najgłośniejszy marsjański temat na forum. Do rzeczy - jakie macie (bardzo) nietypowe patenty na usprawnienie sprzętu astronomicznego bądź jakieś kreatywne improwizacje w razie awarii czy niezabrania jakiegoś elementu sprzętu  Obstawiam, że @HAMAL mógłby samodzielnie wypełnić treścią taki wątek.
        • Haha
        • Like
      • 21 replies
    • MARS 2020 - mapa albedo powierzchni + pełny obrót 3D  (tutorial gratis)
      Dzisiejszej nocy mamy opozycję Marsa więc to chyba dobry moment żeby zaprezentować wyniki mojego wrześniowego projektu. Pogody ostatnio jak na lekarstwo – od początku października praktycznie nie udało mi się fotografować. Na szczęście wrzesień dopisał jeśli chodzi o warunki seeingowe i udało mi się skończyć długo planowany projekt pełnej mapy powierzchni (struktur albedo) Marsa.
        • Love
        • Thanks
        • Like
      • 131 replies
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.