Newsy
Nowinki dotyczące różnych zagadnień dotyczących działalności i użycia projektów Pitlaba
- Szczegóły
- Autor: Piotr Laskowski
Jeszcze za czasów rozwoju APL2 próbowałem zbudować filtr Kalmana i na podstawie kilku przykładów praktycznie udało mi się uruchomić filtr wysokości, wariometru i przyspieszenia w osi Z. Już nie pamiętam szczegółów, ale sprawiało to wrażenie działania, chociaż było dalekie od oczekiwań. Wtedy nie byłem w stanie zrozumieć, jak to działa, a bez zrozumienia trudno jest dostosować się do konkretnego zastosowania, więc tamte próby traktuję jako ćwiczenia praktyczne. Pomimo intensywnych poszukiwań nie udało mi się wtedy znaleźć opracowania, które by w sposób dla mnie zrozumiały tłumaczyło podstawy działania filtra.
W czasie tegorocznego urlopu, gdy przeczytałem już wszystkie zabrane na wypoczynek książki, przejrzałem sieć pod kątem literatury dotyczącej filtra i znalazłem świetne opracowanie Alexa Beckera „Kalman Filter from the Ground Up”. Pod linkiem znajduje się strona typu „landing page” reklamująca książkę, zawierająca kilka podstawowych rozdziałów. Polecam jej lekturę, bo genialnie opisuje zasadę działania, zaczynając od prostych przykładów, stopniowo wprowadzając kolejne zagadnienia i wyprowadzając wzory. Książka już do mnie jedzie, ale informacje znajdujące się na powyższej stronie były wystarczające do uruchomienia kolejnych kilku wersji liniowego filtra na wcześniej wspomnianych danych.
Obecnie pierwsze podejście do filtra zawierało taki sam zestaw danych: wysokość, prędkość pionową i przyspieszenie w osi Z, tworzących wektor stanu:
x = [h, v, a]
Wysokość i przyspieszenie potrafimy zmierzyć z ograniczoną dokładnością, prędkość możemy tylko wyliczyć. Filtr dodatkowo wykorzystuje zależność między elementami wektora stanu, tworząc model matematyczny wiążący je ze sobą. Model jest zawarty w macierzy przejścia F:
- Szczegóły
- Autor: Piotr Laskowski
Na studiach uczyłem się, że regulator (wtedy jeszcze pneumatyczny) parametryzuje się wzmocnieniem Kp, czasem zdwojenia Ti, oraz czasem wyprzedzenia Td. Wyobraźcie sobie moje zdziwienie i irytację, gdy wreszcie zrozumiałem, że wartości Ki i Kd jakimi parametryzuje się regulatory cyfrowe, to nie są znane ze szkoły czasy Ti i Td określające dynamikę regulatora, tylko statyczne wzmocnienia tych członów dynamicznych, określające, jaka część ich odpowiedzi ma wchodzić na wyjście.
O ile nie odczuwam dysonansu przy członie całkującym, gdzie całkowana, czyli w praktyce sumowana, jest wartość błędu od początku pracy do chwili bieżącej. Moje idealistyczne wyobrażenie czasu zdwojenia jako parametru powodującego, że po tym czasie wartość całki podwaja się, nie gryzie się ze współczynnikiem wzmocnienia Ki. Zmieniając współczynnik Ki, mnożymy przez niego błąd e, jaki wchodzi do całki, i wartość całki rośnie szybciej lub wolniej. Całkowanie samo w sobie jest dynamiczne, więc wyprowadzony na zewnątrz współczynnik nadal steruje dynamiką regulatora. Znając dynamikę procesu, można pokusić się o wyskalowanie tego parametru w sekundach.
Natomiast mam dysonans poznawczy z członem różniczkującym. W regulatorach dyskretnych, bo takie implementuje się w sterownikach lotu, wejście członu D to różnica wartości bieżącej i poprzedniej. Dopóki pętla regulacji była dosyć wolna, to wartość poprzednia była przyzwoicie oddalona w czasie od wartości bieżącej i jakoś to działało. Teraz, gdy pętla regulacji przyspieszyła do prawie 2 tys. obrotów na sekundę, porównywane wartości są tak małe, że nikną w szumie pochodzącym z czujnika i taki człon praktycznie nie działa jako różniczkujący, ale jest generatorem szumu z niewielką domieszką różniczkowania. Coś trzeba z tym zrobić, aby móc wyeliminować szum i sięgnąć do wcześniejszych niż poprzednie pomiarów.
Czytaj więcej: Nowe funkcjonalności regulatora PID – regulowany filtr członu D
- Szczegóły
- Autor: Piotr Laskowski
Jakiś czas temu uruchomiłem analizę FFT danych z akcelerometrów i żyroskopów. Od tego czasu oprogramowanie APL3 wzbogaciło się o obsługę protokołu DShot do sterowania silnikami i zostały wyeliminowane błędy, ograniczające prędkość pętli głównej rdzenia CM4 obsługującego kod autopilota, więc prędkość pozyskiwania danych wzrosła z 270 Hz do okolic 1800 Hz. To sprawia, że na wodospadzie FFT powinno być widać dużo szerszy zakres częstotliwości. Rozbudowuje się też docelowa platforma, na której chcę testować APL3, czyli Pentakopter. Pierwszy pomiar zdjęty z Pentakoptera uzbrojonego już w silniki wygląda jednak bardzo ubogo, co znaczy dobrze :-)
Test jest jeszcze bez śmigieł, same 2 tylne silniki. Platforma stoi na własnych nóżkach. W pętli dwukrotnie odczytuję czujniki IMU, więc FFT, które pokazuje zakres częstotliwości równy połowie częstotliwości akwizycji danych, tutaj pokrywa częstotliwość pracy pętli głównej, czyli okolice 1800 Hz. FFT jest zrobione dla 2048 punktów z oknem Hamminga. Silniki sterowane od 0 na górze wykresu do 100% wysterowania na dole (wysterowanie na wodospadzie nietypowo rośnie w dół, częstotliwość normalnie w prawą stronę). Trzy pierwsze wykresy to dane z akcelerometrów w osiach X, Y, Z, kolejne 3 to dane z żyroskopów P, Q, R.
To, co widać, to przede wszystkim poziome paski mówiące tyle, że przy pewnych prędkościach obrotowych silniki drgają bardziej niż przy innych. Ciekawa jest ostra granica między niebieskim obszarem o małych drganiach i czerwonym o dużych.
W tle, głównie na wodospadach przyspieszenia, widać 3 figury typu „X”. Kreska opadająca od lewej do prawej jest czymś normalnym. Zwiększa się wysterowanie i rośnie częstotliwość. Druga kreska od X, ta narastająca, jest dla mnie zagadką. Tak samo zagadką jest występowanie większej liczby tych X-ów. Może to są jakieś harmoniczne? Jak na razie nie widać żadnych rezonansów ramy.
- Szczegóły
- Autor: Piotr Laskowski
Rozwój autopilota przez co najmniej ostatni rok to był szybki marsz do przodu. Prawie każde podejście do projektu rano przed pracą czy wieczorem tworzyło nowy fragment funkcjonalności, aż nagle coś zaczęło się psuć i spowalniać. Po kilku dniach debugowania problemu kluczowe podsystemy praktycznie przestały działać, a kod przestał się linkować. Nie jest to aż tak wielki projekt, żeby nie dało się go ogarnąć – to efekt zaledwie dwóch lat pracy. Nie jest też specjalnie skomplikowany, kilka najtrudniejszych rzeczy jest jeszcze przede mną, a mimo to narzędzie stanęło dęba i nie jestem w stanie nawet zlinkować kodu, aby zacząć szukać przyczyny. Po kilku padach nauczyłem się, jak regenerować pliki projektu, mając plik .ioc i kod źródłowy. Trzeba skasować konfigurację, wygenerować kod z CubeMX, dodać kod z GitHuba i zwykle kolejna kompilacja i linkowanie przechodzi. Jednak po kilkudziesięciu próbach nawet to przestało działać. Jeżeli nawet udało się uruchomić kod, to blokowała się komunikacja z wyświetlaczem po SPI, prawie zawsze nie działał mechanizm wymiany informacji między rdzeniami, a prędkość pętli głównej rdzenia autopilota spadła z około 230 Hz do 13 Hz, a w najgorszym etapie walki do 6,2 Hz.
Problemy zaczęły się pojawiać w chwili, gdy przyszedł zakupiony odbiornik RC pracujący na protokole Crossfire, który trzeba było dopiero oprogramować, a w tle przygotowywałem się do uruchomienia regulatorów DShot. Zimą napisałem obsługę protokołu „na sucho”. Teraz, gdy mam już regulatory i platformę, nadszedł czas, by uruchomić to na rzeczywistym sprzęcie. Na nowej platformie, czyli Pentakopterze, zamocowałem też dwa paski programowalnych LED-ów sterowane timerem przez DMA. Pierwsze przypuszczenie było takie, że uruchomiłem zbyt dużo zasobów korzystających z DMA i być może zatyka się magistrala. W mikrokontrolerze są 3 wielokanałowe układy DMA, wszystkie kanały są zajęte, spora część z nich pracuje jednocześnie, wymieniając z pamięcią duże ilości danych. Jednak testowe wyłączenie największych producentów ruchu na magistrali niczego nie zmieniło.
Może mechanizm międzyrdzeniowej wymiany danych, które rozrosły się do 350 słów 32-bitowych, wymienianych w każdym obiegu pętli głównej, tak zapychał magistralę? Jednak to nie to, ale dane zapisywane przez rdzeń CM4 przestały być widoczne dla CM7. Dostęp do pamięci jest separowany sprzętowymi semaforami, więc nie powinno być konfliktu. Ręczne zapisanie zmiennej jakąś wartością w trybie debugowania jest widoczne podczas debugowania drugiego rdzenia, ale normalna praca, tak jak było przez ostatni rok, już nie działa. Zoptymalizowałem mechanizm przejmowania pamięci, aby żaden z rdzeni nie pisał nowych danych, jeżeli nie są odczytane stare, ani nie czytał ponownie danych już wcześniej przeczytanych. To jednak nie pomogło, a ustawiane flagi też nie były widoczne dla drugiej strony.
Kolejna sprawa to wyświetlacz współdzielący magistralę SPI z panelem dotykowym i kilkoma ekspanderami IO. Każde z nich pracuje na innej prędkości, a ekspandery obsługiwane są w innym wątku niż wyświetlacz i panel dotykowy, więc dostęp do zasobu jest chroniony kolejnym semaforem. W pewnej chwili pojawiło się coś takiego, że wysyłając 3-bajtowe polecenie do układu, fizycznie wychodziły tylko 2 bajty, a magistrala wisiała. Pojawiło się to na chwilę, potem samo ustąpiło — najgorsze, co może być. Po prostu koszmar, siła złego na jednego.
- Szczegóły
- Autor: Piotr Laskowski
Jakiś czas temu, szukając informacji o filtrach, znalazłem film Chrisa Rosera mówiący w drugiej części o znajdowaniu rezonansów ramy wirnikowca przy pomocy analizy FFT danych, zarejestrowanych w czasie pracy silników pochodzących z akcelerometrów i żyroskopów. Bardzo mi się to spodobało i zapragnąłem mieć taką funkcjonalność w swoim autopilocie. Od kilku lat mam własną wersję szybkiej transformaty Fouriera, opracowaną podczas rozwoju niepublikowanego testera modelarskiego. Tak więc najważniejsze elementy składowe są gotowe i można złożyć je w całość. W swojej pierwszej wersji FFT pracowało na rdzeniu Cortex 3, a wykres drgań z wybranej osi akcelerometru wyświetlany był na wyświetlaczu 320×240 pikseli. Szerokość wyświetlacza, rozmiar dostępnej pamięci i wydajność kontrolera powodowały, że rozsądną szerokością FFT było 512 punktów, umożliwiającą na wizualizację uzyskanych 256 wyników na wyświetlaczu. Wtedy rozszerzyłem możliwość konfiguracji do 1024 punktów, co wymagało uśredniania danych, gdyż na jednym pikselu ekranu musiało się zmieścić 1,6 punktów wykresu. Teraz mam troszkę większy wyświetlacz 480×320, ale to wciąż mało. Mimo to zrobiłem wykres z FFT, na tym, co jest dostępne. Dane szersze niż szerokość wyświetlacza są uśredniane a węższe rozciągane, tak aby wypełnić całą roboczą część ekranu, gdyż część ekranu zajmuje skala.
Nowością, jaką podpatrzyłem u Chrisa, jest użycie wodospadu do prezentacji danych historycznych. Wstępnie zrobiłem wodospad przechowujący 100 pomiarów, bo tyle zmieściło mi się na ekranie. Ponieważ w APL3 mam dużo dostępnej pamięci i szybki kontroler, od razu liczę 6 FFT ze wszystkich osi akcelerometru i żyroskopu. Na wyświetlaczu, aby to było w miarę czytelne, jestem w stanie narysować maksymalnie 3 wykresy. Trochę gorzej jest z wodospadem, ale rozwiązałem to w ten sposób, że każda składowa RGB odpowiada jednej osi czujnika. Intensywność świecenia każdej składowej jest proporcjonalna do wyniku transformaty, więc jeżeli szum wszystkich osi jest zbliżony do siebie, to wodospad jest w odcieniach szarości, a gdy jedna z osi zaczyna dominować nad pozostałymi, pojawia się kolorowa poświata sygnalizująca dominację drgań w danej osi. Na fotografii ekranu powyżej jest to praktycznie niewidoczne ze względu na słabe odwzorowanie kolorów.
Czytaj więcej: Analizator drgań i rezonansów konstrukcji BSP
- Szczegóły
- Autor: Piotr Laskowski
Przymierzając się do ulotnienia APL3, trzeba było zebrać zestaw funkcji do obsługi aparatury i sterowania silnikami, a następnie wstawić to do okienka w aplikacji. W jednym miejscu można sprawdzić, czy autopilot widzi aparaturę, skalibrować zakresy drążków, sprawdzić, czy działają silniki lub serwa. Ogólnie prosta sprawa, jednak apetyt rośnie w miarę jedzenia i w trakcie pracy pojawiło się kilka nowych pomysłów. Sporo funkcjonalności jest tylko zasygnalizowanych, ale mają zarezerwowane miejsce na rozwój. Z początkowo małego okienka wyszedł mi potwór, jak na obrazku niżej. Docelowo trzeba go będzie podzielić na osobne okna wejść i wyjść, ale zostawiam sobie trochę czasu do przemyślenia. Oprócz rzeczy znanych jeszcze z APL2, jest trochę nowości wartych omówienia.
Podkategorie
Komputer pokładowy Liczba artykułów: 19
Zagadnienia związane z komputerem pokładowym AutoPitLot
Wariometr SkyAssistant Liczba artykułów: 8
Nowinki związane z wariometrem AkyAssistant
System FPV Liczba artykułów: 19
Firma Liczba artykułów: 24
Dedalus Liczba artykułów: 1
Hermes Liczba artykułów: 2
Artykuły APL3 Liczba artykułów: 27
Zbiór artykułów dotyczących trzeciej wersji komputera pokładowego AutoPitLot nazywanego dalej APL3