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.
Wejścia RC
W APL2 było wejście na tylko jeden odbiornik RC, ale koniecznie chcę mieć dwa wejścia spięte algorytmem wyboru łącza o lepszej jakości sygnału. Na obecną chwilę obsługuję tylko „stare” protokoły, czyli CPPM i S-Bus. Po prostu nie mam jeszcze współczesnej aparatury obsługującej protokół Crossfire, ale to za jakiś czas się zmieni.
Po przemyśleniach zmieniłem zakres sygnału wejściowego. Pierwotnie w APL2 zakres odpowiadał liczbie mikrosekund szerokości impulsu PWM, czyli zmieniał się od okolic 1000 do 2000 z neutrum dla wartości 1500. Wraz z pojawieniem się protokołu S-Bus zakres pracy poszerzył się do 1300, leżąc w widełkach od 380 do 1680. Zwiększanie się dynamiki sygnału RC wydaje się trendem. Protokół Crossfire ma jeszcze szerszy zakres, ok. 1640. Przyjąłem, że sygnał wejściowy będzie normalizowany do zakresu od 0 do 2000 z neutrum dla 1000, co odpowiada zakresowi od -125% do +125%. Chodzi o to, aby nie ograniczać dynamiki nowych protokołów. Lepiej będzie je rozciągnąć, niż redukować.
Wprowadziłem możliwość mapowania kanałów wejściowych. Chodzi o to, że struktura danych i regulatorów PID jest ułożona w kolejności: przechylenie, pochylenie, odchylenie i wysokość, natomiast w mojej aparaturze zamienione miejscami są kanały odchylenia i wysokości. Nie pozwala to na obróbkę kompletu danych w pętli. Po przeczytaniu kilku książek o programowaniu zrozumiałem wagę zalecenia DRY, czyli „Don't Repeat Yourself”. Rozbicie obsługi kanałów na cztery osobne, bardzo podobne kawałki jest błędem, trzeba je obrabiać w jednej pętli, więc konieczne okazało się przemapowanie kanałów. Przy okazji, gdyby ktoś miał aparaturę z nietypowym układem kanałów, to ten mechanizm poradzi sobie z jej obsługą.
Oprócz 4 podstawowych, kolejne kanały też powinny móc pełnić różne funkcje. W APL2 kanały 6 i 7, podpięte w moim Eclipse pod potencjometry, były wykorzystywane do strojenia PID-ów, a kanał 5 na 2-stopniowym przełączniku zmieniał tryb sterowania utrzymaniem wysokości. W APL3 można sobie wyobrazić znacznie więcej, zwłaszcza we współpracy ze współczesną, wielokanałową aparaturą, mającą wiele definiowalnych przełączników. Na razie wstawiłem możliwość sterowania wyjściami OD (otwarty dren) dwóch tranzystorów wysokoprądowych, mogących włączyć np. silny reflektor, elektromagnes czy odpalić pirotechnikę. Inną opcją jest odtworzenie komunikatu. To jeszcze nie jest zdefiniowane, ale można wyobrazić sobie potrzebę ręcznego uruchomienia komunikatu typu: „Nie zbliżaj się do drona, gdy pracują silniki” itp. Sprawa jest do przemyślenia i życie znajdzie zastosowanie dla tej funkcji albo okaże się zbędna i się ją usunie. Współczesne autopiloty mają dosyć bogatą obsługę różnych funkcji, więc to miejsce powinno szybko się zapełnić.
Wyjścia RC
W APL2 wyjścia były na sztywno przypisane do danego silnika. Skoro jest mapowanie wejść, to logicznie spójne wydaje się dodanie mapowania wyjść. Tym bardziej że w prototypie APL3 okazało się, że kanał 1 nie ma możliwości pracy z DMA, więc nie może obsłużyć DShot, a kanał 7 wskutek pomyłki nie jest podpięty do żadnego timera i jest praktycznie bezużyteczny. Chcąc latać z wykorzystaniem DShot, mapowanie kanałów wyjściowych okazało się koniecznością. Tak więc oprócz formatu wyjściowego można ustawić jeszcze logiczną funkcjonalność danego wyjścia. Można zmienić przypisanie silnika do fizycznego kanału, lub przepisać wartość z dowolnego wejścia (aparatura) na wyjście (serwo lub silnik).
Obecnie wyjścia RC są wyprowadzone na tradycyjne złącze szpilkowe 3×100 milsów. Przy takim podejściu łatwo jest zmienić kanał, przepinając wtyczkę, jednak mam wrażenie, że coraz bardziej popularne są regulatory typu „4 w jednym”. Tam wszystkie sygnały wchodzą jedną wtyczką i przepięcie przewodów jest nadal możliwe, ale trochę trudniejsze. Następna wersja APL3 prawie na pewno będzie miała możliwość podpięcia dwóch takich regulatorów, aby móc obsłużyć wirnikowce typu hexa i octo. To jeszcze bardziej utwierdza mnie w konieczności posiadania możliwości programowego przepięcia kanałów.
Oprócz podłączania regulatorów i serw dołożyłem możliwość sterowania wyjściem logicznym. Dla pilota bezzałogowca jest to raczej bezużyteczne, ale dla programisty pracującego ze sprzętem jest to przydatne narzędzie. Wyjście skonfigurowane jako „Port I/O” mogę podłączyć do oscyloskopu, a w kodzie zmieniać stan tego wyjścia. Jest to ogólnie znana metoda debugowania, bardzo przydatna do diagnostyki procesów dynamicznych.
Niektóre wyjścia pozwalają na konfigurację ich jako wejścia analogowe przetwornika A/C. Niektóre mają możliwość pracy jako UART, więc można je skonfigurować jako wyjście S-Bus. Jest to prosty sposób na wykorzystanie nieużywanych wyjść. Życie przyniesie pewnie jeszcze więcej zastosowań.
Sterowanie LED-ami RGB
Ostatnim świeżo napisanym kawałkiem funkcjonalności jest obsługa programowalnych LED-ów RGB typu WS2813, które również mogą być sterowane przez wyjście RC. Historia ich obsługi ma trochę głębszy kontekst. Tam, gdzie zarabiam na życie, pracujemy w dużej hali. W sposób oczywisty zimą jest tam zimno, a latem gorąco. Jeden z kolegów zrobił termometr na podobnych LED-ach. Pomyślałem sobie, że na moim BSP przydałby mi się podobny wskaźnik mogący pokazać parametr, z którym w danej chwili pracuję. Rozwijając funkcjonalność, zwykle nie latam daleko, więc zamiast odrywać wzrok od BSP i szukać danych na ekranie, dobrze byłoby widzieć te dane bezpośrednio na obiekcie.
Protokół sterowania WS2813 jest bardzo podobny do sterowania DShot, więc kupiłem szpulę LED-ów w TME i już następnego dnia mogłem nimi zaświecić. Ale to trochę mało, więc postanowiłem, że chcę mieć możliwość nie jednego, a wielu takich wskaźników. Zrobiłem obsługę dwóch, a ewentualne powiększenie to zmiana kilku definicji w programie. Na moim największym BSP, czyli VTOL Pentakopter 700, zmieści się 20 LED, więc zarezerwowałem pamięć dla 40, aby obsłużyć dwa wskaźniki. W ten sposób mogę porównać względem siebie dwa wybrane parametry, np. prędkość z czujnika różnicowego względem prędkości z GPS. Wskaźnik jest rzędem LED-ów o płynnie zmieniającym się kolorze z jednej wartości w drugą. Cały wskaźnik świeci się ułamkiem swojej pełnej mocy, a jedynie wskazywany punkt świeci się maksymalnie jasno. Na fotografii niżej pokazane są dwa logiczne wskaźniki na jednym fizycznym kawałku taśmy. Pierwszy wskaźnik płynnie przechodzi z koloru czerwonego w niebieski i ma szerokość punktu 4 LED. Widać dwie świecące mocno, ale dwie kolejne po bokach świecą mocniej niż tło i świetlna plamka płynnie przesuwa się po szerokości paska wraz ze zmieniającym się parametrem. Chodzi o to, że jasność świecenia określa funkcja w kształcie trójkąta. Liczba definiująca szerokość jest jego podstawą, a tam jasność jest minimalna. To, co widać wyraźnie, to górna część trójkąta, dlatego wydaje się węższa. Drugi wskaźnik przechodzi z zielonego w czerwony i ma szerokość 6 LED. Obecnie w ramach testów jeden wskaźnik wizualizuje pochylenie, drugi przechylenie.
Ponieważ struktura danych jest całkowicie parametryzowalna, można zdefiniować jeden wskaźnik o szerokości 40 LED albo dowolną inną proporcję rozmiarów. Kolory definiuje się dla końcowych punktów jako składowe RGB, a proces przejścia jest wyliczany jako płynne przejście między wartościami liczbowymi składowych koloru.
Proporcje jasności między tłem a punktem określa parametr: Kontrast tła. Mówi on, ile razy ciemniejsze ma być tło, aby wyraźnie się odróżniało od świecącej plamki. Szerokość plamki można rozszerzyć do 6 sąsiadujących punktów świetlnych, gdyż wskaźnik jednopunktowy okazał się zbyt mało czytelny. Konfiguracja wskaźnika zawiera się w oknie pokazanym poniżej. Zakładki na górze przełączają między konfiguracją dwóch, lub – gdyby kiedyś była potrzeba – większej liczby logicznych wskaźników. Pierwszy panel określa długość struktury, jasność i szerokość plamki wskaźnika, drugi panel definiuje przejście koloru między skrajnymi wartościami: min i max. Ostatni pozwala wybrać zmienną systemową autopilota, która będzie wyświetlana, i ustalić zakres jej wizualizacji. Obsługiwane są układy WS2811 i WS2813, różniące się definicją kolorów.
Ewentualna dalsza rozbudowa będzie dotyczyła wykorzystania części fizycznego łańcucha LED jako osobnych struktur oświetlenia statku powietrznego. Na razie wiem na ten temat zbyt mało i nie jest mi to niezbędne do badań w locie, więc odkładam to na później.
Sam proces sterowania LED-ami jest całkiem szybki. Częstotliwość odświeżania paska 40 LED to ok. 1 kHz. Pomyślałem sobie, że na czymś takim można byłoby zrobić ekran o dużych rozmiarach (ze względu na duży rozstaw pikseli) i wyświetlać na nim obraz. Potrzebne byłoby wiele sterowników takich jak APL3, spiętych szybką magistralą, np. Ethernetem, ale wydaje się to wykonywalne. Niestety nie mam czasu oglądać telewizora, więc odpuszczę sobie tę pokusę. Gdyby jednak wyświetlanie wielkoformatowych obrazów „chodziło za mną”, to raczej będę dążył do zrobienia roju punktów świetlnych. To wymaga dużo pracy koncepcyjnej, a później produkcyjnej, ale praca z rojem jest w moich planach, więc kto wie...