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.
Powstający projekt trzeba testować. Na początku, gdy mamy tylko pojedyncze klepki, możemy porównywać je do szablonu, lecz to jest za mało. Finalnym testem jest próba złożenia klepek w beczkę i napełnienie jej wodą. Dopiero wtedy widać, gdzie są wycieki i co należy poprawić. Ten cykl trzeba powtarzać dotąd, aż napełniona po brzegi beczka nie wypuści nawet odrobiny wody.
Porównując projekt APL3 do beczki, okazuje się, że jest on obecnie na końcu etapu tworzenia klepek. Na początku powstał moduł IMU i funkcje obsługi czujników, takie jak inicjalizacja, odczyt i kalibracja. To działa, ale nie można wykluczyć, że po spasowaniu całości coś trzeba będzie jeszcze poprawić. Obliczenia IMU na kwaternionach działają dobrze na etapie rotacji kątów uzyskanych czujników, ale dzieje się coś złego z matematyką kwaternionów podczas fuzji. Wcześniej nie było wiadomo, o co chodzi, ale są już pomysły, jak to testować.
Aby móc oceniać pracę urządzenia, powstał moduł rejestracji danych na karcie SD oraz moduł telemetrii z wykresami. Telemetria działa na UART-cie, jeszcze nie działa po Ethernecie, bo to jest dla mnie nowość i muszę się douczyć, jak używać tego narzędzia. Jestem w stanie otworzyć gniazdo sieciowe i komunikować się na wybranym porcie, ale obsługa tego wymaga dużo więcej pracy niż w przypadku UART-a. Nie jest to rzecz niezbędna na początkowym etapie, więc na razie zadowala mnie fakt, że działa sprzęt i można z tym przejść do kolejnego etapu. Za to nie działa komunikacja po USB, bo nie mając zbyt dużego doświadczenia, użyłem portu USB HS zamiast FS. Komunikacja, która bez problemu uruchamia się na testowym zestawie Nucleo pracującym z USB FS, nie chce ruszyć na moim sprzęcie z USB HS. Pewne rzeczy sknociłem w sprzęcie, np. łącząc ze sobą detekcję polaryzacji wtyczki USB-C przy pomocy linii CC z linią USB_ID. Tak nie można robić, już to wiem. Jednak po wprowadzeniu poprawek nadal nie mogę nawiązać komunikacji po USB. Nad tym trzeba jeszcze chwilę popracować.
Zrobiona jest eksperymentalna klepka obsługi wbudowanej wizji. Działa kamera, na obraz z niej można nałożyć OSD. Chociaż niektóre elementy OSD, w tym czcionka, wymagają dopracowania, nie wstrzymuje to dalszych prac. Finalny obraz jest kompresowany do jednego z 4 formatów JPEG. Nie działa jeszcze kluczowy serwer RTSP, służący do tego, aby obraz przekazać na zewnątrz. Uruchamiałem go, mając do dyspozycji małą ilość pamięci statycznej, więc wypełnianie bufora obrazu było robione małymi porcjami, co jest trudne w implementacji. Teraz jest do dyspozycji duża pamięć dynamiczna, więc można będzie wrócić do serwera, przekazując mu kompletną klatkę skompresowanego obrazu. To powinno być łatwiejsze, a gdy już ruszy, można próbować przesyłać dane na bieżąco paczkami prosto z kompresora, aby uzyskać mniejsze opóźnienie. Proces analizy obrazu to jeszcze nietknięta klepka, ale powiedzmy, że obecnie robię beczkę w rozmiarze S i w takim układzie chciałbym zacząć ją eksploatować. Dopiero później będę próbował dodać obróbkę obrazu, powiększając projekt do rozmiaru L. Na obecną chwilę wystarczy, że jest taka możliwość.
W kontekście mechaniki lotu, to zadanie ma zostać zrealizowane w nadchodzącym roku. Obecnie ze starszej wersji projektu przeniesione są regulatory PID i mikser. Dodany jest nowy generator sygnału DShot dla współczesnych regulatorów silników. Przewidziane jest miejsce w pamięci na zapis konfiguracji, jej podgląd w kontrolerze oraz nastawy w aplikacji NSK. Potrzebne są jeszcze gruntowne testy działania regulatorów przy zakłóceniach jednostkowych i złożenie tego w całość. Współczesne autopiloty mają funkcję autotune. Trzeba będzie nad tym popracować, bo bez tego projekt nie będzie atrakcyjny. W APL2 nie dotarłem do nawigacji po punktach. Włożyłem w to trochę pracy, ale bez uzyskania finalnej konkluzji. Tym razem trzeba będzie dociągnąć to do końca.
Podczas pracy z APL2, czujnik ultradźwiękowy służył jako wsparcie w procesie pomiaru wysokości. Pozwalał on na usunięcie dryftu ciśnienia czujnika barometrycznego i ułatwiał lądowanie na innym poziomie niż start. Synchronizacja pomiaru barometrycznego i ultradźwiękowego odbywała się podczas zbliżania się do podłoża na odległość około metra. Tym razem jest dostępny czujnik ultradźwiękowy działający z odległości 2,5 m. Oprócz tego jest czujnik laserowy liczący drogę powrotu światła. Jest to lidar krótkiego zasięgu. Oba czujniki nie są jeszcze uruchomione. Ten ultradźwiękowy wydaje się prosty w obsłudze, ale laserowy jest trudniejszy ze względu na bibliotekę, której używa. Jego implementacja nie będzie prosta. Nie lubię takiego podejścia, ale trzeba będzie się z tym zmierzyć.
Obecnie trwają prace nad radiomodemem obsługującym modulację GFSK oraz LoRa. Ustawiając modulację GFSK, można osiągnąć wystarczający transfer, aby przesłać telemetrię i polecenia sterujące. Pracując z modulacją LoRa, uzyskuje się większy zasięg i rozmyte pasmo, trudne do obserwacji nawet na analizatorze widma, tym samym bardziej odporne na zakłócenia, ale kosztem znacznie niższego transferu. Jest pomysł na jeszcze jedno szerokopasmowe radio oparte na WiFi do transmisji obrazu lub wymiany dużej liczby informacji między bezzałogowcami w roju, ale tutaj implementacja będzie musiała jeszcze chwilę poczekać. Przy tej okazji okazało się, że fajnie byłoby móc wstawić radio jako moduł wewnętrzny, ale w złączu gniazda nie przewidziałem UART-a, a zamiast tego zupełnie niepotrzebnie wstawiłem CAN. To zostanie poprawione w następnej wersji sprzętu. Do ustalenia jest jeszcze interfejs szerokopasmowego radia: czy to ma być UART, czy raczej SPI. Moduły mają SPI, ale są połączone do rdzenia CM4 sterującego autopilotem, a radio jest sterowane z rdzenia CM7, więc niewykluczone, że przyszłe moduły będą miały 2 porty SPI. Obecnie drugim portem jest QSPI, ale obecne doświadczenie nie potwierdza przydatności QSPI w module.
Istotną nowością w dziedzinie łączności w roku 2025 było wdrożenie połączeń światłowodowych. Jednak to, co jest dostępne na rynku, umożliwia przesyłanie obrazu analogowego. W projekcie APL potrzebne jest przesłanie sygnału cyfrowego. Obecne, początkowe rozpoznanie pokazuje, że istniejące rozwiązania wymagają dwóch nitek światłowodu. Być może to tylko kwestia multipleksera przełączającego Tx/Rx w jednym kanale. Jest to sprawa do zbadania, choć niezbyt pilna, ponieważ nie wpływa na konfigurację sprzętu. W pierwszej kolejności należy skupić się na lataniu z dostępnymi interfejsami komunikacyjnymi.
Wszystko wskazuje na to, że rok 2026 nie będzie nudny.