Newsy
Nowinki dotyczące różnych zagadnień dotyczących działalności i użycia projektów Pitlaba
- Szczegóły
- Autor: Piotr Laskowski
Zbliżam się do etapu wstawienia APL3 na platformę latającą. Na razie został wstawiony na 20-calową ramę wykonaną ze sklejki 3 mm, której główną zaletą jest to, że mieści się na biurku. Próbowałem uruchamiać napęd, ale mam już dosyć dłubania w kodzie, więc w ramach relaksu wymyśliłem i narysowałem nową platformę w stylu VTOL (ang. Vertical Take Off and Landing). O ile płatowiec typu delta jest trójkątnym kawałkiem płata nośnego, to dlaczego by nie zrobić płata w kształcie kwadratu i od razu wbudować w to napęd wirnikowca?
Wstępne szkice pozwoliły zauważyć, że wirnikowiec, aby lecieć do przodu, musi pochylić się do przodu. Ujemny kąt pochylenia daje składową poziomą wektora ciągu silników skierowaną do tyłu, która porusza platformę do przodu. Natomiast płatowiec zwykle leci na dodatnim kącie pochylenia, nazywanym kątem natarcia, aby uzyskać siłę nośną przez odchylenie w dół strug powietrza, a profil płata zapewnia dodatkową siłę nośną. Te dwa mechanizmy są sprzeczne. Wychodząc z neutralnej sytuacji zerowego pochylenia, jeżeli zwiększymy kąt natarcia, to kopter będzie wytwarzał składową hamującą ruch do przodu. Jeżeli pochylimy platformę, aby lecieć jak wirnikowiec, wtedy pochylony płat będzie wytwarzał siłę nośną skierowaną w dół. Być może to jest przyczyną części problemów z konstrukcjami hybrydowymi. Dlatego wymyśliłem, że zbuduję platformę ze wstępnie uniesionym płatem.
- Szczegóły
- Autor: Piotr Laskowski
Dawno, dawno temu, w latach 80. XX wieku, za trzema rzekami: Wisłą, Bugiem i Narwią, za siedmioma górami — jednak nie, większych gór nie było po drodze. W ZSR Marianowo nauczyciel przedmiotu technologia materiałowa z jakichś niepamiętanych już względów nie mógł przyjść na lekcję, więc w jego zastępstwie przyszedł dyrektor szkoły. Nie przyszedł nauczać przedmiotu, bo prawdopodobnie nie miał czasu się przygotować, ale przyszedł spędzić ten czas z uczniami, aby nudząca się młodzież nie zdemolowała szkoły pod nieobecność nauczyciela. Zupełnie przypadkiem jednym z tych młodzieńców byłem ja.
Pan dyrektor, prawdopodobnie nie mając większego pojęcia o przedmiocie, aby zająć młodzież, przedstawił nam opowieść o beczce: Za jakiś czas, gdy skończycie studia, będziecie projektować różne rzeczy. Niektóre będą proste, inne mogą być złożonymi systemami. Musicie wiedzieć, że każdy projekt jest jak beczka, składająca się z wielu spasowanych ze sobą klepek. Każda klepka odpowiada pewnemu zakresowi wiedzy i umiejętności. Wykształcony inżynier potrafi wiele, ale w pewnych aspektach jest silniejszy, w innych orientuje się jako tako. Są też takie, na których nie zna się prawie wcale. Jeżeli przełożymy to na klepki, to jedne będą pełnowymiarowe, innym czegoś będzie brakować, np. będą miały dziury po sękach, a jeszcze inne będą krótsze, niż powinny. Jeżeli z tych umiejętności stworzymy projekt jak beczkę z klepek, to będzie można nalać do niej wody tylko do poziomu najsłabszej klepki.
Robiąc projekt, nie można skupić się na perfekcyjnym dopracowaniu tego, na czym znamy się najlepiej. Trzeba dążyć do tego, aby wszystkie klepki zostały dociągnięte do równego poziomu. Niekoniecznie od razu do wysokiego. Aby to osiągnąć, trzeba douczyć się albo zatrudnić kogoś, kto ma potrzebne umiejętności. Praca włożona w perfekcyjne dopracowanie jednego aspektu zwykle zostaje przykryta niedociągnięciami tego, na czym znamy się najsłabiej. Potrzebna jest samodyscyplina i chłodna ocena całokształtu projektu.
- Szczegóły
- Autor: Piotr Laskowski
Kompresja JPEG
Uruchomiłem już wszystkie możliwe tryby kompresji JPEG obrazu i warto byłoby je porównać. Wspominałem o nich w artykule Obraz na latającym mikrokontrolerze STM32H7. Część 1 Sprzęt. Przypomnę, że różnią się liczbą informacji o chrominancji, czyli kolorze. W trybie YUV444 każdy piksel w bloku 8×8 ma pełną informację o luminancji i chrominancji. W trybie YUV422 dwa sąsiednie bloki w rzędzie mają wspólną chrominancję pierwszego bloku. W trybie YUV420 cztery sąsiadujące bloki mają wspólną chrominancję z pierwszego bloku. W trybie Y8 jest zawarta tylko luminancja. Na typowym obrazie z kamery nie ma zauważalnych różnic między trybami kompresji kolorowego obrazu. Widać to dopiero na kontrastowych obiektach OSD, w szczególności na pionowych i poziomych liniach oraz na literach napisów. W YUV422 następuje rozmycie koloru w pionie, a w YUV420 w pionie i poziomie. Dodatkowo w trybach o zredukowanej chrominancji, jeżeli kolor występuje na obszarze mniejszym niż rozmiar bloku i trafi na blok z pominiętą chrominancją, to kolor tego obszaru nie znajdzie się na obrazie. Przy poruszającym się obrazie z kamery, jeżeli kolor punktu na chwilę zniknie, nasz mózg kompensuje tę utratę i nie przeszkadza nam to w jego interpretacji. Natomiast linie OSD , które są statyczne względem początku obrazu w sytuacjach, gdy linia znalazła się w bloku, z którego nie jest pobierana chrominancja, tracą kolor całkowicie.
Utrata jakości jest kompensowana mniejszym rozmiarem obrazu, co jest istotne, zwłaszcza przy transmisji radiowej obrazu. To jest kwestia do wyważenia, jaką utratę jesteśmy w stanie zaakceptować w zamian za redukcję rozmiaru. Jeszcze nie mam radiowego linku wizyjnego, ale już teraz można ocenić, jak parametry kompresji wpływają na percepcję skompresowanego obrazu. Dodatkowo stopień kompresji można regulować w zakresie od 1 do 100. Im większa liczba, tym lepsza jakość, ale większy rozmiar skompresowanego obrazu.Poniżej przedstawiono wykres zmiany rozmiaru pliku i stopień redukcji rozmiaru pliku dla różnych stopni kompresji
Postawą do obliczeń jest teoretyczna liczba danych wynikająca z rozmiaru obrazu i obecności składowych chrominancji powiększona o 558 bajtów bloku Exif, obecnego w każdym pliku JPG. Przyznam się, że oczekiwałem większej różnicy rozmiaru między obrazem kolorowym a monochromatycznym. Jestem pozytywnie zaskoczony tym, że algorytm kompresji pokazał swoją efektywność.
Poniżej przedstawiam tabelę z tymi obrazami w rozdzielczości 320×240. Są malutkie, na większych różnice widać lepiej, ale nie zmieszczę ich na stronie.
Czytaj więcej: Obraz na latającym mikrokontrolerze STM32H7. Część 3 kompresja JPEG i Exif
- Szczegóły
- Autor: Piotr Laskowski
W poprzednim artykule wspomniałem o DMA2D z funkcją mieszania obrazów (ang. blending). To jest podstawa do nałożenia nakładki z informacjami o parametrach lotu na rzeczywisty obraz. Nie jest mi to obecnie niezbędne, ale pokusa narysowania była zbyt silna, abym wytrwał w ascezie tworzenia jedynie potrzebnego na tym etapie kodu. Na obrazkach poniżej jest szkic ekranu OSD w rozdzielczości 480×320 naniesionego na szary obraz (30% bieli, 70% czerni) oraz na obraz z kamery.
Jest to szkic nie tylko dlatego, że parametry w górnej części ekranu są diagnostyczne zamiast rzeczywistych, ale przede wszystkim dlatego, że rysunek jest bardzo uproszczony. Zarówno horyzont, jak i skale prędkości i wysokości nie zawierają jeszcze podziałek. Najważniejsze jest jednak to, że zarówno czcionka, jak i linie rysowane są to pojedynczą linią bez obwiedni. Obiekty ekranowe porządnego OSD powinny mieć obwiednię, np. czarną a najlepiej czarną i białą, aby były dobrze widoczne na ekranie o zmieniającej się jasności. Powinny być widoczne zarówno w locie pod słońce, jak i w nocy. Narysowanie linii z obwiedniami jest rzeczą do zrobienia w kilka poranków i wieczorów (wtedy zwykle pracuję nad projektem). Natomiast zrobienie 4-kolorowej czcionki zawierającej czerń, biel, przezroczystość i kolor użytkownika to jest już grubsza sprawa, do zrobienia na późniejszym etapie.
Czytaj więcej: Obraz na latającym mikrokontrolerze STM32H7. Część 2 OSD
- Szczegóły
- Autor: Piotr Laskowski
W ramach pracy nad nowym projektem autopilota postanowiłem sprawdzić możliwość wykorzystania obrazu do usprawnienia nawigacji. Dostępność systemów satelitarnych sprawiła, że trudne zadanie nawigacji w terenie zostało zautomatyzowane. Jednak żyjemy w czasach, w których nie możemy być pewni ciągłej dostępności tych usług, dlatego potrzebna jest alternatywa, aby w godzinie próby nie obudzić się z ręką w symbolicznym nocnym naczyniu.
Istnieje powszechna świadomość wykorzystania obrazu przez człowieka do rozpoznania znanego terenu. W Wikipedii jest takie hasło jak torodroma, które w żartobliwy sposób definiuje metodę wytyczania trasy przelotu samolotu w pionierskich czasach, kiedy nie było jeszcze GNSS. W trakcie wojny na Ukrainie słyszałem o metodzie określania pozycji na podstawie dopasowania obrazu do mapy terenowej. Szachownica pół uprawnych, dróg i lasów jest często na tyle charakterystyczna, że sieć neuronowa jest w stanie skorelować obraz kamery z obrazem na mapie terenowej.
Od dosyć dawna istnieje też metoda „optical flow”, którą na co dzień posługujemy się w optycznych myszach komputerowych. Metoda określa kierunek i wielkość przesunięcia między kolejnymi obrazami zarejestrowanych przez mysz lub bezzałogowca i wyznacza z nich wektory przesunięcia. Użycie metod zliczeniowych do sumowania wektorów z kolejnych obrazów pozwala na określenie bieżącej pozycji. Metoda daje przyrosty względne, więc sumowanie w skali bezwzględnej musi generować pewien błąd, który z czasem będzie narastał, jednak prędkość jego przyrostu wydaje się, że powinna być w miarę stała. Porównując to z danymi GNSS i INS, można próbować wykryć sytuację pojawienia się zakłóceń GNSS. W szczególności spoofing sygnału, który, jak mi się wydaje, jest jedną z metod walki radioelektronicznej z dronami. Chyba każdy widział obrazki z wielkimi, elektronicznymi „strzelbami” do walki z dronami. Są w stanie sprowadzić drona na ziemię. To znaczy, że co najmniej niektóre z nich muszą robić spoofing, czyli fałszowanie wskazań np. wysokości. Tak sądzę, ponieważ przed samym zagłuszeniem sygnału, np. przez emisję nośnej modulowanej szumem o częstotliwości transmisji danych GNSS można się obronić, odpowiednio definiując warunki reakcji na fail safe.
Jest to ciekawy temat i mając sporo wolnego czasu, warto się nim zająć. Połączenie metody „optical flow” z rozpoznawaniem charakterystycznych punktów może pozwolić na kasowanie błędów zliczeniowych i nawigację przynajmniej po terenie, który posiada w miarę stałe szczegóły morfologiczne (nie może to być morze). Być może w trakcie zmagania się z oporem materii wpadnie do głowy jakiś nowy pomysł.
Poniżej opisuję pierwszy etap tej przygody, czyli proces tworzenia narzędzi do uzyskania obrazu, jego rejestracji „in situ” i kompresji przed wysyłką.
Czytaj więcej: Obraz na latającym mikrokontrolerze STM32H7. Część 1 Sprzęt
- Szczegóły
- Autor: Piotr Laskowski
Autopilot to nie tylko sprzęt i jego oprogramowanie zwane potocznie firmware, ale też oprogramowanie sterujące autopilotem z ziemi. Bez niego sprzęt jest praktycznie bezużyteczny. W rozwoju sprzętu doszedłem już do etapu, gdzie oprogramowanie NSK jest już konieczne, aby móc iść dalej. Na przykład trudno sobie wyobrazić konfigurację PID-ów, czy w ogólności wprowadzanie dużej ilości liczb przy użyciu samego ekranu dotykowego. Kolejną rzeczą może nie użytkową, ale rozwojową jest możliwość narysowania wykresów on-line, czy prezentacji zarejestrowanych logów, po to aby móc diagnozować bieżące problemy.
Na samym początku rozwoju projektu jeszcze pracując z płytką prototypową Nucleo, napisałem szkielet protokołu komunikacyjnego zarówno dla komunikacji po porcie szeregowym, jak i po TCP/IP. Głównie po to aby sprawdzić, czy to da się zrobić. Później powstały jeszcze fragmenty do wykonania zdjęcia kamerą i przesłania go do programu, a jeszcze trochę później pojawiła się konieczność przygotowania i wgrania do pamięci autopilota komunikatów głosowych. Przez długi czas to było wszystko. Teraz gdy uruchomiłem w sprzęcie telemetrię, pojawiła się potrzeba obsłużenia tego z drugiej strony, czyli konfiguracji tego, co i kiedy ma być przesyłane oraz rysowania wykresów z przychodzących danych.
Pierwszą wersję obsługi telemetrii zacząłem budować, wykorzystując okno "Widok klasy" ze standardowego szablonu aplikacji MDI. Zamiast drzewa klas stworzyłem drzewo roju, w którym znajdują się kolejne drony albo wrony ja to lepiej brzmi po polsku. Wyświetliłem tam listę telemetrii jako jeden z parametrów wrona i zacząłem robić jego konfigurację, ale to jest mało wygodne, więc do konfiguracji telemetrii zrobiłem osobne okno, gdzie wyświetla się lista wszystkich zmiennych telemetrycznych i do każdej z nich można przypisać określoną częstotliwość wysyłania od 100Hz do 0,02Hz oraz całkowicie wyłączyć wysyłanie danych. W APL2 dane telemetryczne schodziły paczkami danego typu, np. paczka danych barometrycznych, danych z akcelerometrami, magnetometrami itp. Tutaj zastosowałem inną technikę. Jest jeden typ ramki telemetrycznej, wysyłanej wtedy, gdy licznik odmierzający czas jej wysyłania dojdzie do zera. By móc zidentyfikować te dane, każda zmienna ma przypisany jeden bit dosyć długiego słowa kontrolnego. Wydaje mi się że taka metoda jest efektywniejsza, bo np. analizując regulację kąta nachylenia mogę wysłać tylko te dane, które są mi potrzebne, a nie całą paczkę je zawierającą. W jednej ramce może zmieścić się ok. 120 różnych danych, a można zaadresować około 200. Więcej zwykle się nie wysyła, ze względu na ograniczoną przepustowość łącza UART. Sama przepustowość jest też liczona z uwzględnieniem narzutu protokołu komunikacyjnego i wyświetlana w oknie.
Czytaj więcej: Rozwoj oprogramowania Naziemnej Stacji Kontroli
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