PitLab - Elektronika modelarska

Szczegóły

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

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

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

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

Szczegóły

Autopilot może być wyposażony w kilka magnetometrów. Dwa magnetometry są umieszczone na module inercyjnym IMU I2P, jeden może być umieszczony na zewnętrznym module GNSS oraz potencjalnie jeden w IMU kamery. Tego w kamerze jeszcze fizycznie nie ma, więc spróbujmy skalibrować 3 dostępne czujniki. Obecnie dostępne są trzy procedury obsługi magnetometrów różniące się sposobem wykonania i rodzajem zasilających je danych. Zostaną one omówione poniżej, ale jako wstęp powiedzmy kilka słów o samym pomiarze.

Czytaj więcej: Kalibracja magnetometrów

Szczegóły

Od kilku dni pracuję nad AHRS, czyli podsystemem, który dostarcza informację o kątach orientacji w przestrzeni 3D: przechylenia (ang. roll), pochylenia (pitch) i odchylenia (yaw). Gdy samolot zna swoje kąty orientacji, może za pomocą regulatorów PID tak się sterować, aby utrzymać kąty wymagane w na danym etapie lotu. Tak więc jest to jeden z najważniejszych podsystemów dla wszystkiego, co aktywnie lata, od wielowirnikowca po rakietę.

Pierwsze rozwiązanie powstało przy okazji robienia jednostki inercyjnej. Trzeba było jakoś weryfikować czujniki, sprawdzić na ile stabilne są ich wskazania, itp. To jest rozwiązanie na filtrze komplementarnym, gdzie z jednej strony całkowane są prędkości kątowe z żyroskopów, budując kąty dla każdej osi a z drugiej, poszczególne składowe wektora przyspieszenia są wstawiane do równań trygonometrycznych i w ten sposób obliczana jest druga wersja kątów. Kąty uzyskane z żyroskopów są znacznie mniej wrażliwe na drgania mechaniczne, nie wpływają na nie zakłócenia wywołane zmianą prędkości w czasie manewrów, ale nie są stabilne długookresowo, czyli płyną w funkcji temperatury. W dużej mierze daje się to skompensować rozbudowaną kalibracją, ale nigdy nie jest idealnie. Kąty uzyskane z akcelerometru, oraz magnetometru opierają się na konkretnych wielkościach fizycznych i dzięki temu są stabilne długookresowo. Choćby pomiar był zaszumiony, to poza chwilami zmiany prędkości, średnia grawitacji będzie zawsze wskazywała na ziemię a średnia magnetyczna na północny biegun magnetyczny. Niestety takie pomiary są podatne na zakłócenia np. przyspieszeniami wywołanymi zmianą prędkości, lub lokalnymi zaburzeniami pola magnetycznego. Najgorszą cechą jest to, że zwykłe drgania mechaniczne wywołane pracą silnika, niewyważonym śmigłem, czy turbulencjami, przekładają się bezpośrednio na liczony kąt i taki pomiar jest mocno zaszumiony. Szum można odfiltrować, ale to opóźnia fazę, przez co trudno jest sterować obiektem z opóźnieniem w pętli sterowania. Filtr komplementarny bierze dużą część kąta (powiedzmy 98%) kąta z żyroskopów i dopełnia to kątem z akcelerometrów tyle, aby skompensować ewentualny dryft i żeby składowa z szumem nie była zbyt duża. Bardziej zaawansowane rozwiązania, np. filtr Kalmana, sam dobiera sobie proporcję danych, minimalizując błędy.

To rozwiązanie jest intuicyjne, da się na tym latać, ale ma kilka znanych wad. Jedną z nich jest to, że funkcje trygonometryczne są ułamkiem, gdzie po obu stronach dzielenia są długości kątów trójkąta, jaki tworzą składowe wektora przyspieszenia, lub wektora magnetycznego. W pewnych sytuacjach jeżeli długość składowej wektora znajdującej się w mianowniku jest zerowa, to następuje niedozwolona operacja dzielenia przez zero. Wynik takiej operacji wykonywanej w mikrokontrolerze jest nieokreślony (NaN - Not a Number). Ten wynik z AHRS idzie do dalszych podsystemów sterowania i rozchodzi się lawinowo po całym systemie, zwykle zatrzymując jego pracę a w praktyce nasz bezzałogowiec spada.

Takie punkty nieokreślone można obchodzić, stosując warunki badające czy mianownik jest zerem. Tak działa funkcja atan2(x, y), dając bezpieczny wynik, w odróżnieniu od klasycznej funkcji atan(y/x), która wysypie się dla x=0. W obu przypadkach chodzi oczywiście o arkus tangens. Funkcje trygonometryczne zajmują też dosyć dużo mocy obliczeniowej. Przy współczesnych mikrokontrolerach nie jest to krytyczne, ale są inne metody bezpieczniejsze matematycznie i prostsze obliczeniowo. To są kwaterniony. Jeszcze do niedawna, to była dla mnie czarna magia, o której nawet nie wspominano w szkole, ale gdy zacząłem szukać, to znalazłem kilka fajnych wytłumaczeń jak to działa. Jeżeli jeszcze nie wiesz co co chodzi z kwaternionami, to na początek polecam film dr. Tomasza Millera o historii i podstawach kwaternionów, a już po tym film Mateusza Kowalskiego o algorytmach obrotu w przestrzeni 3D przy użyciu kwaternionów. Jest tego więcej, ale po obejrzeniu tych dwu, już będzie wiadomo czego szukać dalej.

Czytaj więcej: Prace nad AHRS

Strona 4 z 17

Logowanie

Subskrypcja

Znajdz na stronie