no super, praktycznie nie trzeba latac bo widoczki same sie generuja
: środa 14 gru 2011, 00:57
autor: mounter
cholo pisze:no super, praktycznie nie trzeba latac bo widoczki same sie generuja
to jest ratunek, jak kamera padnie, albo zaskoczy Cię mgła - wtedy obraz mógłby być generowany na podstawie wskazań czujników horyzontu i baro
: środa 14 gru 2011, 06:44
autor: pawlo
Lub w oczekiwaniu na lepszą widoczność pograć w Pac Mana
: środa 14 gru 2011, 07:45
autor: krall
mounter pisze:
cholo pisze:no super, praktycznie nie trzeba latac bo widoczki same sie generuja
to jest ratunek, jak kamera padnie, albo zaskoczy Cię mgła - wtedy obraz mógłby być generowany na podstawie wskazań czujników horyzontu i baro
To trzeba iść krok dalej - czyli nie "robić" OSD w modelu tylko puszczać na dół pakiet danych (gps, imu, kompas) a na dole hulaj dusza... synthetic vision bez kompromisów
: środa 14 gru 2011, 10:09
autor: Rurek
optymalnie by było mieć :
-na modelu proste OSD które wyraźnie i czytelnie pokazuje strzałkę na dom i ewentualnie dystans do domu
- reszta przesyłana telemetrią i generowana we wszystkich kolorach świata w bazie.
Mój pomysł wynika z intuicyjnego wyczucia że telemetria może się "wyłożyć" a dopóki mamy obraz z modelu dopóty mamy namiar na dom i w jakiś sposób jest zachowana redundancja
: środa 14 gru 2011, 10:58
autor: krall
Rurek pisze:
Mój pomysł wynika z intuicyjnego wyczucia że telemetria może się "wyłożyć" a dopóki mamy obraz z modelu dopóty mamy namiar na dom i w jakiś sposób jest zachowana redundancja
Wszystko może się wyłożyć
Tak hipotetycznie - jeśli by postawić na taką superhiper osd na ziemi to albo to albo to. Nie ma sie co rozdrabniać. U ZBiga dane telemetri przesyłane są coś na zasadzie teletekstu, wiem, że jak testowali to dane przechodziły nawet przy prawie nieczytelnym-zaszumionym obrazie.
: środa 14 gru 2011, 12:02
autor: Rufio
Właściwie idea OSD w modelu sprowadza się chyba do tego aby nie targać dodatkowego osprzętu - czyli model kompaktowy.
Tak czy owak dzieś, czy to w module na latadałku czy na ziemi, i tak trzeba policzyć parametry i coś "namalować" pilotowi.
Swoją drogą takie rozwiązania (OSD w bazie) są przynajmniej od 2006 roku. Wychodzi na to, że w model wystarczy wpakować IMU z autopilotem i transmisją wszelkich parametrów i zapewnić jej "niezawodność" (czyli nawet jeśli będzie szum z video to dane i tak przejdą).
No a na ziemi to już hulaj dusza z grafiką.
Z filmiku z 1szego posta, chciałem nieco uświadomić i sobie, że generowanie Composit PAL z zastosowaniem procka i oporników jest jak najbardziej wykonalne (i to z dźwiękiem).
Do niedawna żyłem w przekonaniu, że to wymaga przynajmniej wykorzystania zewnętrznego dla procka generatora, wysoko taktowanego procka albo 2ch procków czy czego tam jeszcze), i że "tanio" się zrobić po prostu nie da.
ps. no i takie demo w starym dobrym stylu jak na ZX Spectrum, chyba warto obejrzeć .
: środa 14 gru 2011, 12:45
autor: Rurek
Rufio pisze:...że generowanie Composit PAL z zastosowaniem procka i oporników jest jak najbardziej wykonalne....
Dobrze napisałeś - GENEROWANIE.
Zupełnie co innego jest z KLUCZOWANIEM sygnału z kamerki napisami generowanymi w innym źródle, to już nie jest takie hop-siup..i dlatego nie ma pokładowych-kolorowych OSD
Sam procesor nie zsynchronizuje się z podnośną koloru w PAL. Do tego potrzebny jest specjalizowany układ. Albo analogowy (PLL + enkoder kwadraturowy itd) - niestety od dawna takich już nie produkują, albo cyfrowy dekoder + enkoder z funkcją graficznego OSD (i zewnętrzną pamięcią RAM), albo przynajmniej z wejściem OSD RGB (od pewnego czasu conajmniej "obsolete" - stosowane były dla złącza SCART w telewizorach SD). Tak czy inaczej sporo miejsca, prądu i dodatkowe opóźnienie obrazu. Z drugiej strony PAL jeszcze się trzyma, bo nie ma dobrej alternatywy HD dla projektów DIY (czyli dalekiego zasięgu). Ale to chyba tylko kwestia czasu...
A do samego wygenerowania PAL/NTSC to wystarczał stareńki 8051 czy Z80, oczywiście dla PAL z lekkim "naciągnięciem" standardu :)
w bazie.