Rejestrator

Aparatura pokładowa, układy pomiarowe i wykonawcze.
Awatar użytkownika
arekp
Supersonic PROFI
Posty: 136
Rejestracja: niedziela, 17 kwie 2011, 00:31
Kontakt:

Arecorder zmiany

Post autor: arekp » wtorek, 10 maja 2016, 21:21

Wyzwalanie awaryjne spadochronu głównego działa tak (algorytm jest wykonywany co pół sekundy):

1. z ciśnienia wyliczam wysokość,
2. z wysokości wyliczam prędkość opadania,
3. jeśli prędkość opadania w danym kroku jest większa niż w poprzednim, zwiększ licznik, jeśli mniejsza, to zmniejsz licznik,
4. jeśli licznik dojdzie do 4 (czyli w czterech kolejnych krokach prędkość się zwiększy albo w pięciu zwiększy a w jednym zmniejszy itd), to wyzwalaj awaryjnie spadochron główny,
5. zliczaj przypadki, gdy prędkość opadania jest ujemna (powinno wystąpić tylko wtedy, gdy rakieta opada na pilocie), cztery takie przypadki wyłączają algorytm (w Arecorderze w wersji 2.1 były to dwa takie przypadki),
6. jeśli upłynie pięć sekund od wyzwolenia pilota (czyli max dziesięć kroków), to i tak wyłącz algorytm.

Na dwóch ostatnich pozycjach zapisywanych w pomiarach jest prędkość opadania wyliczana z ciśnienia i ParachuteFailureSenseCnt. Każdy może sobie więc zobaczyć jak algorytm zadziałał w przypadku jego rakiety. Należy jednak pamiętać, że po tych pięciu sekundach prędkość opadania z ciśnienia nadal jest wyliczana, ale algorytm już nie działa (zmienna ParachuteFailureSenseCnt nie będzie już się zmieniać).

Jeszcze raz to wszystko przemyślając:
- myślę, że algorytm jest ok, ale mamy trzy zmienne, które trzeba rozsądnie ustawić (zapewne w zależności od rakiety): licznik do awaryjnego wyzwolenia spadochronu ParachuteFailureSenseCnt, licznik do wyłączenia algorytmu ParachuteFailureDisableCnt i czas, po którym algorytm jest wyłączany.
- prawdopodobnie w locie Bigosa algorytm się włączył, bo pilot był za mały i prędkość opadania wzrastała,
- prawdopodobnie w locie RTP9 algorytm się nie włączył, bo wystarczyły dwie próbki (to było zdecydowanie za mało) ujemnej prędkości opadania do wyłączenia algorytmu, o co pewnie było łatwo biorąc pod uwagę teorię z pustym zbiornikiem na podtlenek i pływającą zatyczką produkujące po wyzwoleniu zapalnika spore zawahania ciśnienia wewnątrz rakiety.

Znowu występuje to, co we wcześniejszych wersjach Arecordera, ale w innym miejscu - przypadki nietypowe i jak sobie z nimi radzić. Trzeba by mocno pomyśleć do jakich wartości zaprogramować te trzy zmienne. I trzeba oczywiście pamiętać, że wysokość obliczona z ciśnienia po wyzwoleniu pilota może mieć duży błąd.

Awatar użytkownika
przemo
Podniebny Filmowiec
Podniebny Filmowiec
Posty: 188
Rejestracja: piątek, 25 sty 2013, 19:15
Lokalizacja: Poznań

Re: Rocket Team Poland 9

Post autor: przemo » środa, 11 maja 2016, 08:14

arekp pisze:.... I trzeba oczywiście pamiętać, że wysokość obliczona z ciśnienia po wyzwoleniu pilota może mieć duży błąd....
Mógłbyś to proszę wytłumaczyć?
Tzn chodzi mi o powód dla którego wysokość z ciśnienia posiada już potem błąd lub nawet "duży błąd".
Nie mówię o momencie wyzwalania pilota, a o fazie w której pilot jest już wyzwolony.
Z góry dziękuję za wyjaśnienie tej tezy.
pozdrawiam

Awatar użytkownika
rawsock
****
Posty: 213
Rejestracja: niedziela, 5 lut 2012, 11:59
Lokalizacja: Gdańsk
Kontakt:

Re: Rocket Team Poland 9

Post autor: rawsock » środa, 11 maja 2016, 10:05

Wg mnie jest tu kilka problemów. Po pierwsze punkt 5 i 6 jest zbędny. Nie ma potrzeby wyłączać tego algorytmu. Nawet jak pilot się otworzył, to zawsze może się zerwać. Wyłączanie niczemu w zasadzie nie służy.
Po drugie, powinien być warunek na bezwzględną wartość prędkości. Jesteśmy w stanie bez problemu ustalić próg prędkości, powyżej którego jesteśmy pewni na 100%, że coś poszło nie tak.
Po trzecie zauważ, że cały algorytm to jest substytut filtru ciśnienia. Takie podejście (na licznikach itp.) jest dobre np. dla układów FPGA gdzie bardzo trudno zaimplementować porządny filtr. Ale w przypadku uC implementacja dobrego filtru nie stanowi większego problemu. Oczywiście zakładam że masz założony filtr Kalmana na dane z ciśnienia, ale:
- skoro musiałeś zbudować algorytm w oparciu o dodatkowe filtrowanie w postaci liczników, zamiast bazować na bezwzględnej wartości prędkości, to znaczy, że filtr / współczynniki są źle dobrane
- filtr jest liniowy, a masz do dyspozycji akcelerometry. Kalman powinien być trzeciego rzędu (pozycja i przyspieszenie w jednej osi, prędkość - brak sensora - jest wyjściem z filtru), tak jak tutaj: http://adrianboeing.blogspot.com/2010/0 ... art-2.html. Oczywiście jest to dużo więcej roboty i testowania, może nawet trzeba by zmienić mikrokontroler na mocniejszy, np. STM32 (to akurat z korzyścią dla całości), ale po dobrym dostrojeniu współczynników takiego filtru rezultaty urywają łeb.

I tu wracamy też do punktu wyjścia. Wyłączasz algorytm, ponieważ dane są źle filtrowane i jest obawa że wystrzeli główny pomimo prawidłowego opadania na pilocie. Takie filtrowanie na raty w kilku miejscach nie jest dobre. Ciężko coś takiego dostroić, lub wręcz jest to niemożliwe. Filtr powinien być jeden i to możliwie najbliżej źródła danych i korzystać ze wszystkich dostępnych sensorów. Pewną trudnością jest to że ciśnienie jest tylko w jednej osi, więc najlepiej zrobić z tego po prostu 6-DOF IMU (3x acc, 3x gyro, kompas raczej odpada ze względów praktycznych, trzeba by go kalibrować w każdej rakiecie osobno) z filtrem takim jak ten http://www.x-io.co.uk/open-source-imu-a ... lgorithms/ i wtedy powiązać te dane z ciśnieniem przy pomocy Kalmana nieliniowego. Coś takiego stroimy raz a algorytm bazuje już tylko na konkretnych wartościach prędkości / wysokości. Roboty dużo więcej, ale jeżeli przechodzimy już z rakietek na 300 metrów do 10k, to i urządzenie musi być bardziej skomplikowane.
Sebastian

Awatar użytkownika
rafciodz
****
Posty: 1207
Rejestracja: niedziela, 30 sty 2011, 18:31
Lokalizacja: Stargard Szczeciński
Kontakt:

Re: Rocket Team Poland 9

Post autor: rafciodz » środa, 11 maja 2016, 14:28

Cześć,
wiem, że wyskoczę ni z gruszki ni z pietruszki ale czy nie można dołożyć jeszcze jednego "czujnika" który:
- mierzyłby poziom światła w komorze spadochronowej - np fotorezystor zainstalowany w odpowiednim miejscu,
- lub napięcie liny, - nie mam propozycji...
- lub wysunięcie /rozłączenie dwóch elementów rakiety czyli otwarcie przedziału spadochronowego - np. przerwanie obwodu elektrycznego

w celu sprawdzenia czy komenda wyzwól pilota została sprawnie wykonana innymi obwodami niż czujniki ciśnienia który daje dane pośrednie wynikające z czynników niezależnych od nas ( nietypowe sytuacje w locie ).
Zakładam, że to zmusza do przebudowy arecordera. Mikrokontroler spokojnie to obsłuży... A wersja 3.0 z wyjściami na czujniki bezpieczeństwa to jest to.. Obrazek


Jeżeli nie - to zostaje po prostu kolejne zliczanie próbek po wyzwoleniu pilota w celu sprawdzenia czy wyskoczył, lub się nie zerwał... czyli jak napisał Rawsock powinien dalej działać choć według mnie bazownie na tym jednym obwodzie kontroli to błąd który często się mści.

Pozdrawiam
Rafał
Free Your Mind

Awatar użytkownika
wrx
****
Posty: 219
Rejestracja: sobota, 22 lut 2014, 20:15
Lokalizacja: Siedlce

Re: Rocket Team Poland 9

Post autor: wrx » środa, 11 maja 2016, 20:49

Nie mama Arecodera, więc nie powinienem się wtrącać, ale, popieram pomysł Pana Rafała.
Wpinany fotorezystor to jest to!

Do tego zwykły opornik i kawałek zworki, albo odpowiednia wzmianka w AreConfigu + kilka linijek kodu i jazda.

Ale lepiej, niech się twórca Arecodera wypowie.

Poza tym, gratuluje, Panie Rafale, za świetny pomysł z fotorezystorem, małe i proste.
„Wszyscy wiedzą, że czegoś nie da się zrobić. I wtedy pojawia się ten jeden, który nie wie, że się nie da, i on właśnie to coś robi” A. Einstein.

Awatar użytkownika
AGH Space Systems
**
Posty: 34
Rejestracja: poniedziałek, 20 kwie 2015, 20:02

Re: Rocket Team Poland 9

Post autor: AGH Space Systems » środa, 11 maja 2016, 22:48

Też wtrącimy swoje conieco :D
W naszej elektronice do CanSata mieliśmy 3 fotodiody mierzące natężenie światła w celu wykrycia momentu wyrzucenia z rakiety. Całość spisywała się bezbłędnie za każdym razem. Myślę, że warto umieścić fotoczujnik na kablu i rozważyłbym możliwość zastosowania więcej niż jednego.

Awatar użytkownika
przemo
Podniebny Filmowiec
Podniebny Filmowiec
Posty: 188
Rejestracja: piątek, 25 sty 2013, 19:15
Lokalizacja: Poznań

Re: Rocket Team Poland 9

Post autor: przemo » czwartek, 12 maja 2016, 08:27

Foto czujnik ekstra sprawa. Zresztą im więcej danych trafia na czarną skrzynkę tym lepiej i łatwiej odtworzyć ostatnie sekundy/minuty "lotu we mgle" :wink:
Ale niestety sprawę przedmiotową (algorytm awaryjnego otwarcia głównego) załatwia tylko ułamkowo.
Otwarcie komory pilota (sygnał z foto czujnika) gwarantuje tylko jedno - rakieta jest zdestabilizowana i jedyne co możemy powiedzieć to że nie leci w dół jak V2 na Londyn.
Pytanie czy na pilocie czy bez, bo się urwał, jest bez odpowiedzi.
Rozpatrując ten przypadek ułożenie korpusu może być dowolne i zmienne zatem, moim skromnym zdaniem, również skorzystanie z akcelerometrów może być daremne lub bardzo kłopotliwe, nawet sprzęgając programowo z magnetometrem/żyro/gps/.....
Tylko i aż czego potrzeba to znać pionowe v lub ∆v
Ponowię zatem pytanie : dlaczego skorzystanie z baro podczas wznoszenia jest ok ale przy opadaniu już jest "bee" ?
Widziałem wiele wykresów z baro-altimetrów i po wycięciu piku szczytowego przy wyrzuceniu pilota wykresy wznoszenia i opadania wyglądają na spójne.
Nawet jeśli wysokość się nie zgadza co do cm/dm/m/km (choć jeszcze się nie wypowiedzieliście dlaczego), to przecież co stoi na przeszkodzie aby dalej wykorzystywać go, nawet po filtrowaniu i obróbce, do nieszczęsnego v lub ∆v choćby tylko na potrzeby awaryjne?
Jak wspomniał @rawsock - zostałoby jedynie wyznaczyć próg ujemnej prędkości pionowej.

Awatar użytkownika
rawsock
****
Posty: 213
Rejestracja: niedziela, 5 lut 2012, 11:59
Lokalizacja: Gdańsk
Kontakt:

Re: Rocket Team Poland 9

Post autor: rawsock » czwartek, 12 maja 2016, 08:58

Dokładnie - sprawę załatwia tylko ułamkowo. Takie elementy są dobre do małych rakiet, bo proste i skuteczne w większości przypadków. Ale zupełnie nie są skalowalne do coraz większych rozwiązań. Gdyby nie interesowała nas skalowalność, to w zasadzie najlepiej byłoby dać jeden czujnik rtęciowy i wszystko w temacie.
Sprzężenie akcelerometrów z żyroskopami właśnie ma na celu pozycjonowanie w trzech osiach i działa na prawdę dobrze. Eliminuje zakłócenia od sił odśrodkowych itp. Nie powinno też być żadnego problemu z wyznaczaniem prędkości z barometru przy opadaniu. Oczywiście jest problem z wyznaczeniem prędkości chwilowej, ale tutaj potrzebujemy jedynie średnią w danym przedziale (w praktyce wyjście z filtru podaje prędkość chwilową, ale z opóźnieniem, tutaj ono nie przeszkadza nawet gdyby wynosiło ponad sekundę). A sprzężenie tego z sensorami jak powyżej powinno dać jeszcze lepsze efekty, z wynikami prędkości pionowej zbliżonymi do czasu rzeczywistego.
Sebastian

Awatar użytkownika
stary Leszek
****
Posty: 183
Rejestracja: sobota, 6 kwie 2013, 12:34

Re: Rocket Team Poland 9

Post autor: stary Leszek » czwartek, 12 maja 2016, 09:11

Fotorezystor jak pisz Przemo sygnalizuje tylko że rakieta jest otwarta.
Czy nie wystarczy dać czujnik który określi nam siłę jaka działa na
linkę pilota. Będziemy wiedzieli nie tylko,że nastąpiła destabilizacja
modelu, ale również czy prawidłowo działa pilot.

A co do lotu rakiety- czy pilot był uwalniany po odstrzeleniu głowicy,
czy gdzieś niżej. Pytam bo na tym "zakręcie" gdzie położyło rakietę
wystąpiły duże siły poprzeczne, które mogły zaklinować miejsce
podziału.

Awatar użytkownika
rawsock
****
Posty: 213
Rejestracja: niedziela, 5 lut 2012, 11:59
Lokalizacja: Gdańsk
Kontakt:

Re: Rocket Team Poland 9

Post autor: rawsock » czwartek, 12 maja 2016, 10:07

Dane z czujnika siły jaka działa na linkę obarczone byłyby dokładnie takim samym szumem jak odczyt z barometru. Zmiana sensora niczego nie rozwiązuje. To odpowiednie podejście do filtrowania jest rozwiązaniem.
Sebastian

ODPOWIEDZ

Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 1 gość