Polskie Towarzystwo Rakietowe - Amatorskie Konstrukcje Rakiet

Przy czujniku naciągu linki pilota nie ma żadnego szumu.
To jest odczyt zero-jedynkowy.
Albo jest naciąg i pilot pracuje prawidłowo-tylko trzeba określić
progi- albo naciągu brak co świadczy o awarii pilota.
Musi być jakiś układ logiczny, który zinterpretuje odczyt naciągu.

A przy okazji, na tych wysokościach gęstość powietrza jest 3-4 razy
mniejsza niż na powierzchni ziemi. Spodziewam się, że konstruktorzy
to uwzględnili.

To że odczyt jest zerojedynkowy nie oznacza, że nie ma szumu. Analogowa siła naciągu jest zaszumiona, więc jej pomiar też jest zaszumiony. A binarny przetwornik daje Ci jedynie złudzenie braku szumu, bo sam w sobie stanowi prymitywny filtr. Tak się robiło 20 lat temu, kiedy nie było tanich mikrokontrolerów i precyzyjnych przetworników jak dzisiaj. Takie rozwiązanie da Ci o wiele gorsze rezultaty niż zastosowanie wielobitowego przetwornika, implementacja filtru siły naciągu i ustawienie progu na tę siłę przy której uznajesz że pilot jest otwarty. Myślenie typu "no ale przecież wiadomo kiedy linka jest naciągnięta, a kiedy nie" nie działa w przypadku bardzo zaszumionych wielkości fizycznych.

Gęstość powietrza to jest właśnie ciśnienie. Sensory barometryczne MEMS w atmosferze ziemskiej powinny dawać wystarczająco dokładne wyniki do około 10km.

Dobry pomysl z tym filtrem Kalmana

Pisząc o gęstości powietrza myślałem o spadochronach nie o barometrze.

Jestem przekonany, że prosty czujnik nacisku jak choćbyTAKIwraz z uśrednieniem napięcia na kondensatorze, do tego komparator i mamy odporne na zakłócenia, analogowe rozwiązanie pomiaru siły. Poza tym tak naprawðe duże zakłócenia to mamy tylko na początku. Potem jest wartość naciągu linki od pilota w okolicy masy modelu, z zakłóceniami na dużo mniejszym poziomie. Wiadomo, zależne to jest od prędkości opadania, bo w miarę wzrostu prędkości opadania wzrasta opór samej rakiety w powietrzu, Tak wiec powinno to być dopracowane jednostkowo do danej rakiety i ustalonych dla niej parametrów.

P.S. A do dobrego dobrania czujnika nacisku, jest i membrana

Ja nie twierdzę, że nie da się zrobić analogowego układu odpornego na zakłócenia. Twierdzę, że nie będzie on w niczym lepszy od układu cyfrowego, dobrze zaprogramowanego. Będzie natomiast gorszy od cyfrowego, zaprogramowanego bardzo dobrze, korzystającego z danych z wielu sensorów. Ponieważ komputer pokładowy i tak w rakietach jest potrzebny, lepiej poświęcić energię na dopracowanie programu, zamiast na redundantny układ.
Oczywiście, zakłócenia są z grubsza tylko na początku. Ale ta sama uwaga dotyczy układu cyfrowego. Jeżeli rozważałbyś zignorowanie początkowych, zakłóconych danych, to dokładnie to samo mógłbyś zrobić w układzie cyfrowym. Nie ma tu żadnej przewagi dedykowanego układu do pomiaru siły. Dlatego obecne problemy Arecodera z obsługą niestandardowych przypadków wynikają w mojej ocenie z pewnych uproszczeń, a nie z tego, że układ cyfrowy jest bardziej upośledzony w swojej naturze. Fakt że trudniej jest zaprogramować układ cyfrowy aby działał bardzo dobrze, niż skonstruować analogowy odpowiednik korzystający z własności fizycznych materii do filtrowania danych, nie powinien być wymówką, aby ten koncept porzucać.

Hej.
Rozmowa potoczyła się w kierunku to czy to. A przecież tu chodzi o dodatkowy układ kontrolno/potwierdzający. Z niczego nie możemy zrezygnować bo to nie nasza rakieta
Sądzę że układy dodatkowe powinny wspierać główną analizę danych i mają działać na żądanie. Typu próbki pobrane rosną, maleją, rosną - sprawdź otwarcie rakiety/wyrzucenie spadochronu/napięcie liny itd...
Co tylko chłopaki zastosują za układy kontrolne.
Pozdrawiam
Rafał

Mysle ze problem jest ciekawy bylo by super gdyby PTR posiadalo repozytorium projektow ktore kazdy moglby testowac budowac i udoskonalac projekty mozna by zalozyc konto na githubie i zrobic je opensource jak np robi sie z drukarkami 3d https://github.com/josefprusa/Prusa3

Rawsock...zrozum mnie dobrze. Nie twierdzę, że analiza cyfrowa jest zła, chciałem tylko przedstawić sensowną alternetywę na miarę elektroniki, którą rozumiem. Dodatkowo widzę, że w ramach cyfrowego podejścia pojawia się dużo niuansów w algorytmach, które czasem odbijają się czkawką. Słowem...chwilami ciut nie ufam zbyt skomplikowanej maszynerii. Ale co do ogólnej wymowy Twojego postu, to się zgadzam...

Wasze rozważania dotyczą głównie rozwiązań, które wymagałyby zmiany hardware'u, natomiast teraz, kiedy mam już trochę płytek i trochę Arecorderów polutowanych, mogę jedynie zmienić software.

Po rozmowie z Andrzejem i Adamem stwierdziłem, że będę robić progowanie po prędkości opadania rakiety wyliczanej z ciśnienia. Jeśli próg zostanie przekroczony, licznik będzie się zwiększał, jeśli nie, będzie on się zmniejszał. Algorytm będzie wykonywany z krokiem 10 ms a licznik będzie zliczać do 100. Próg będzie ustalać użytkownik.

W swoich rozważaniach dotyczących prędkości opadania wyliczanej z ciśnienia zapominacie o tym, że wyzwolenie ładunku pirotechnicznego do wyzwolenia spadochronu powoduje skok ciśnienia (wypchnięcie spadochronu tłokiem również) a rzadko kiedy komora z elektroniką jest szczelnie odizolowana od przedziału spadochronowego. Skok ciśnienia jest chwilowy, ale zaburza Wskazania po filtrze Kalmana - wolny filtr Kalmana uwzględni ten skok ciśnienia jako zmianę wysokości i później będzie zawyżać lub zaniżać wyliczaną prędkość a szybszy filtr Kalmana i tak będzie uwzględniał te skoki, choć w mniejszym stopniu, ale jego wskazania będą falować. Dlatego też do awaryjnego wyzwalania spadochronu głównego będę wyliczał wysokość z niefiltrowanego ciśnienia, wyliczoną wysokość będę uśredniał prostym filtrem i z różnicy wysokości pomiędzy kolejnymi pomiarami będę wyliczał prędkość opadania rakiety. Testowałem algorytm na danych z Bigosa i ostatniego lotu K1X i algorytm działa. Niestety nie mam za wiele danych z lotów, gdzie pilot nie zostałby wyzwolony prawidłowo a rakieta spadała zbyt szybko - jeśli ktoś ma takie dane, to proszę prześlijcie mi je.



Teraz co do zmian hardware'owych:
- IMU - w kolejnej wersji Arecordera prawie na pewno zastosuję IMU.
- fotorezystor - jestem dość sceptycznie nastawiony do fotorezystora. Co prawda wykrywa on czy spadochron został wyrzucony, ale to jeszcze nie jest wystarczające żeby stwierdzić, że pilot nie zawiódł. Ponadto fotorezystor (odpowiedni fotorezystor a nie jakikolwiek) trzeba by podłączyć kabelkiem z Arecorderem oraz dodać opcję w konfiguracji do wyłączenia go dla osób, które nie będą go używać.
- napięcie liny - jeszcze mniej osób będzie to stosować, trzeba by dodać dodatkowy parametr na stopień naciągu liny (zależny od masy rakiety) do oprogramowania przez użytkownika, trzeba by wymyślić niezawodny sposób mocowania czujnika w rakiecie.
- rozłączenie dwóch członów rakiety - jak przy fotorezystorze, to jest tylko informacja, że rakieta się rozdzieliła, nie wiadomo czy spadochron się rozwinął itp.


W uproszczeniu mamy trzy przypadki po wyzwoleniu pilota:
- Pilot się rozwinął i rakieta opada na nim powoli. Prędkość opadania na pilocie użytkownik może sobie mniej więcej wyliczyć (określmy to jako V_pilot),
- Pilot się nie rozwinął, rakieta jest zdestabilizowana. Obliczenie prędkości opadania zdestabilizowanej rakiety jest już trudniejsze, ale można oszacować tę prędkość, przynajmniej w pewnym zakresie (V_destab),
- Rakieta opada lotem balistycznym. W najgorszym przypadku rakieta rozpędza się z przyspieszeniem 1 g do pewnej prędkości granicznej (V_bal?), którą można również sobie wyliczyć.

Do tego dochodzi prędkość V_para_main, to jest maksymalna prędkość, przy której spadochron główny nie ulegnie zniszczeniu.
Mając te prędkości, użytkownik może określić prędkość, przy której algorytm ma zadziałać. Użytkownik może zzdecydować, czy woli wyzwolić spadochron główny, gdy rakieta jest zdestabilizowana (wtedy próg prędkości opadania będzie ustalony pomiędzy V_pilot a V_destab) czy też zdestabilizowana rakieta opada na tyle wolno, że nie warto otwierać spadochronu głównego (wtedy próg prędkości będzie ustalony pomiędzy V_destab a V_para_main). Próg prędkości powienien być ustalony odpowiednio poniżej V_para_main, żeby wykluczyć wpływ opóźnienia zadziałania algorytmu (w czasie, gdy licznik algorytmu się zwiększa, rakieta może przyspieszyć, ponadto wyliczona prędkość opadania wciąż jest trochę zaszumiona).



Prosiłbym moderatora o przeniesienie wszystkich postów zaczynając od mojego poprzedniego do tematu z Arecorderem - [ nie wiem czy dokładnie o to chodziło ale zrobione - rafciodz ]