Polskie Towarzystwo Rakietowe - Amatorskie Konstrukcje Rakiet

Czesć

rawsock pisze:Hmm. A dlaczego wykres wysokości się urywa? No i mam zagwozdkę jeśli chodzi o wykres prędkości - wychodzi z niego że przy kontakcie z ziemią prędkość była większa niż pod koniec pracy silnika (??).

Powinienem też skrócić wykres prędkości. Po odstrzeleniu spadochronu rakieta wariuje na linkach i nie ma co liczyć prędkości i wysokości na podstawie akcelerometru w osi - wychodzą bzdury.

pzdr

Witam,

Wczoraj testowaliśmy nową wersję Arecodera z nowym warunkiem startowym. W założeniu, gdy rakieta stoi na wyrzutni zapalniki mają być nieaktywne (BHP), soft ma zazbroić zapalniki spadochronów dopiero po osiągnięciu przez rakietę 4m wysokości, czyli po opuszczeniu wyrzutni. Rozważaliśmy wiele wariantów na wypadek niestabilnej pracy silnika startowego np. leniwe zejście czy ciufanie i podskoki na wyrzutni. Problem okazał się wcale niełatwy i rozwiązanie go zajęło troche czasu. Teraz wydaje się że algorytm działa w końcu poprawnie. Celem testu było wykonanie dychawicznych lotów na niewielką wysokość i sprawdzenie czy warunki awaryjnego wyzwalanie spadochronów zadziałają oraz czy zapis danych przez nowy hardware jest poprawny. Wykonaliśmy dwa "loty" testowym Paczangiem (1,9kg) na silniku ROS. Pierwszy na 4,3m drugi na 5,9m. Za każdym razem rozdzielenie rakiety nastąpiło jeszcze nad ziemią, oczywiście spadochron nie zdążył sie rozwinąć . Świetnie spisała się innowacyjna, dwuczęściowa wyrzutnia prętowa wraz z prowadnicą na modelu . Niebawem test w normalnym locie.

http://www.rakiety.pomorze.pl/filmy/201 ... aczang.avi

Pozdrawiam,
Andrzej

A na czym polega "zazbrojenie" zapalników? Czy jest to jakaś akcja sprzętowa, czy to wyłącznie stan logiczny w oprogramowaniu?

Nie ma tu nic sprzetowego, soft decyduje o wszystkim.

Witam,

Za nami kolejne testy Arecodera.

15 sierpnia ponownie poleciała testowa rakieta Paczang 3 tym razem na silniku Icaros. Cele:
- sprawdzenie poprawności oprogramowania Arecodera po zmianie warunku startowego.
- sprawdzenie zachowania warunku wyzwolenia pilota przy najmniejszej prędkości (start pod sporym kątem). Ten warunek testowaliśmy z powodzeniem w zeszłym roku ale na starej wersji układu.
Rakieta o wadze 2,39kg wzniosła się na około 350m, oba cele osiągnięte, układ zachował się poprawnie.
Niestety film nagrywałem telefonem, nie umiem go przyciąć (mp4) więc nie zamieszczam.
W trakcie analizy zapisów rejestratora okazało się że gdyby rakieta była wyposażona w dwa spadochrony to główny najprawdopodobniej został by przedwcześnie wyzwolony. Spowodował by to nowy fragment kodu który Arek wprowadził jeszcze w zeszłym roku a który jak dotąd nie został przetestowany. Chodzi o awaryjne wyzwolenie spadochronu głównego gdy na pułapie nie dojdzie do destabilizacji rakiety i zacznie się ona gwałtownie napędzać w dół.


16 sierpnia poleciała rakieta Paczang 4 przygotowana na FM. pod silniki Wessex lub PTR 38mm. Rakieta o średnicy 80mm i wadze 2,43kg tym razem napędzana była silnikiem PTR 400.
Cel testu - przetestowanie poprawności wyzwalania głównego spadochronu.
Model o wadze 2,43kg po dynamicznym starcie wzniósł się na około 850m. Niestety właściwie chwilę po pilocie wyzwolony został spadochron główny i rakietę zniosło o prawie kilometr od miejsca startu w bardzo trudny teren. Kilkugodzinne poszukiwania nie przyniosły efektu. Z pomocą przyszedł przypadkowy paralotniarz który namierzył model z powietrza jeszcze z 200m od miejsca gdzie szukaliśmy. Rakietę udało się w końcu odzyskać. Niestety analiza zapisanych danych nie przyniosła odpowiedzi dlaczego algorytm wyzwolił główny spadochron przedwcześnie. http://www.rakiety.pomorze.pl/filmy/V138.avi
http://www.rakiety.pomorze.pl/filmy/V138.OSZ.short.mov

19 sierpnia Paczang 4 poleciał ponownie tym razem na silniku Wessex. Cel - zebranie danych potrzebnych do poprawienia warunku awaryjnego wyzwalania głównego spadochronu oraz test Wessexa w locie. Trwa analiza danych. http://www.rakiety.pomorze.pl/filmy/V139.and.short.avi
http://www.rakiety.pomorze.pl/filmy/V139.rob.avi

Pozdr

Cześć
Poniżej dwa wykresy ciągu silników uzyskane z Arecordera na podstawie akcelerometru pokładowego:

PTR 400 w obecnej formie


Wessex 250m


Wykresy podmieniłem też w komnacie PTR w katalogu silników.

pzdr

andżej pisze:Niestety analiza zapisanych danych nie przyniosła odpowiedzi dlaczego algorytm wyzwolił główny spadochron przedwcześnie.

A jaki był warunek na spadochron główny? Generalnie wyzwolenie zaraz po pilocie nie może być przypadkowe - pewnie szpilki w odczytach z akcelerometru / wysokościomierza są za to odpowiedzialne. Może by zablokować wyzwalanie głównego na jakiś czas, aż do ustabilizowania parametrów po wyzwoleniu pilota? Lepiej by było oczywiście dojść do tego matematycznie, a nie blokować, ale może się to okazać słabo wykonalne.

Witam,
Faktycznie wyzwolenie głównego spadochronu nie było przypadkowe. Wcześniej program był prosty i wyzwalał spadek na zadanej wysokosci np. 200m nad ziemią na podstawie danych z czujnika ciśnienia. Warunek awaryjnego wyzwalania też jest oparty na odczytach z czujnika ciśnienia a właściwie na pomiarach prędkości obliczanych za jego pomocą. W szczegółach musi wypowiedzieć się Arek. Blokowanie na jakis czas odpada bo gdy rakieta opada w jednym kawałku, bardzo szybko się napędza i po chwili nie ma sensu już wyzwalać głównego spadochronu bo i tak zostanie zerwany. Kluczowe jest jak najszybsze wykrycie że rakieta nie zdestabilizowała się i ostro napędza. Mamy sporo zarejestrowanych lotów bez wyzwolenia pilota na pułapie i na tych danych sie opieramy, tylko ze jak zwykle nic nie jest takie proste jak sie początkowo wydaje.

Pozdr.
Andrzej

Chociaż z drugiej strony to filtr kalmana powinien te szpile wygładzić. Dziwne...

Reguła prosta, dopóki sygnał ma złośliwe szpilki pochodzenia nieznanego a algorytm jest mission critical, dowal medianą z trzech a dopiero potem wrzucaj na filtr Kalmanowszelaki. Pojawi się dodatkowe opóźnienie fazowe równe jednej iteracji, ale ogólnie warto. Zaś logować zawsze warto surowiznę i starać się namierzyć źródło problemu.