Jeszcze jeden? 🙂

Jest kilka otwartych projektów. więc po co następny?
Od początku: zacząłem ten projekt już w 2009, wtedy nie było zbyt wiele opcji dostępnych, gotowe nadajniki o sporych możliwościach były bardzo drogie. No i żaden nie był dostatecznie elastyczny jak dla mnie 🙂 Nawet dzisiaj nie wiem czy podobny nadajnik istnieje, przynajmniej za sensowną cenę, a nie tysiące $$ 🙂

BLOCZKI!

Cała unikalnośc tego projektu tkwi w BLOCZKACH!
Do sterowania każdym modelem mamy jakieś drążki, gałki, przełączniki, i na wyjściu kilka kanałów. Pomiędzy wejściami a wyjściami jest zawsze mniej lub bardziej elastyczna 'czarna skrzynka’.
W moim projekcie wnętrze 'czarnej skrzynki’ można swobodnie definiować łącząc dowolnie matematyczne bloczki.

Bloczki jakie można użyć:

• trymery
• rewersy
• dodawanie
• odejmowanie
• negacja
• expo
• mnożenie
• zamiana wartości analogowej na 3 stany: -1,0,1 (dla przełączników)
• powszechne mixery
• limity
• i wiele innych…

Najlepszą metodą na wyjaśnienie tego jak to wszystko działa jest pokazanie na przykładach.
W podanych przykładach powinieneś wiedzieć tylko, że kanały 0-7 są wejściami (drążki, potencjometry, przełączniki), natomiast 16-23 to kanały wyjściowe (to co dostanie odbiornik). Reszta czasem ma specjalne znaczenie, albo jest zarezerwowana, ale to nie jest tu ważne.

Prosty model – taki jak w większości prostych nadajników.

Podstawowe bloczki:

Kanał 0 (CH0) jest wejściem z drążka, jego wartoś idzie na wejście bloczka revers. Drugie wejście tego bloczka jest podłączone do kanału CH40, który pamięta pozycję przełącznika rewersu. Wyjście rewersu idzie do kanału 52. Następnym etapem jest bloczek trymera, który na jednym wejściu ma kanał 52 (wyjście poprzedniego bloczka), na drugim ma kanał 28 z którego dodaje wartość trymera. Wyjście bloczka trymera idzie już bezpośrednio do kanału wyjściowego.
Pozostałe kanały tworzy się w podobny sposób.

Bloczek specjalny rewers jest tak naprawdę bloczkiem mnożenia, ale w menu jest traktowany specjalnie – drugie wejście automatycznie pojawia się w menu 'Reverse’.
Podobnie jest z bloczkiem trymera, który jest bloczkiem dodawania, a drugie jego wejście pojawia się w menu 'Trims’.

Wygląda prosto, nieprawdaż? 🙂
To teraz coś odrobinę trudniejszego.

Delta lub latające skrzydło

Kolejny przykład: mixer delta.

Na początek warto napisać co taki mikser liczy:

To narysujmy bloczki do policzenia tego:

Ale to tylko sam mixer, a co z trymerami, rewersami itp?

Spójrzmy więc na prawdziwy model:

Wygląda dosyć skomplikowanie, więc wyjaśnijmy o co tu chodzi.

Trochę zmodyfikowane równanie mixera delta:

Myślę, że większość ludzi, którzy mieli okazję latać latającym skrzydłem może potwierdzić, że ten typ modelu jest bardzo wrażliwy na ster wysokości. Jednym z rozwiązań tego problemu jest ustawienie expo na kanale wysokości. Ale można też po prostu znieczulić wysokość na korzyść steru kierunku. Czyli zamiast używać 0.5 jako mnożnik dla obydwu kanałów, używam mniejszego dla wysokości, a większego dla kierunku. Ważne, żeby suma współczynników nie była większa od 1, to wtedy wartości na wyjściu nie będą przesterowane lub obcięte (podobnie zrobiłem w moim małym mikserze na ATTINY13).

Spójrzmy na powyższy obrazek. Bloki 1-3 'wytwarzają’ mnożniki dla mixera delta. Ponieważ CH40 jest podłączony do bloczka trymera, więc jest możliwość z poziomu menu na modyfikację tego mnożnika. Bloczek 2 normalizuje wartość, żeby mieściła się między 0 a 1, Bloczek 3 wytwarza drugi mnożnik odejmując od 1 poprzedni wyliczony.
Bloczki 5,7,10,11,12 tworzą mikser delta z zmiennymi mnożnikami. Po mikserze delta są bloczki rewersów i trymerów dla właściwego ustawienia kierunku i pozycji neutralnej serwa.
Blisko wejść mamy bloczki 4,6 i 8 – zwykłe trymery przydatne do korekcji zachowania samolotu w locie.

Czyli jeżeli można sobie wyobrazić równanie opisujące zachowanie aparatury, to można takie coś zrobić z bloczków.
Oczywiście będą potrzebne jeszcze specjalne bloczki (stany, przełączniki, pamięci itp), ale to można niewelkim kosztem dorobić, i pewnie dorobię jak czegoś będę potrzebował 🙂

Wystarczy o bloczkach, warto jeszcze opisać kilka innych rzeczy 🙂

Architektura oprogramowania

W nadajniku jest kilka typów procesów:

• krytyczny – generowanie sygnały PPM
• wysokiego priorytetu – pobieranie wartości z wejść, przeliczenie bloczków i przygotowanie wartości dla generatora PPM
• reszta – interfejs użytkownika (menu, wyświetlanie czegoś na LCD, trymowanie, opcje etc.)

Generowanie sygnału PPM

Użyłem sprzętowego generatora PWM, żeby PPM był jak najdokładniejszy jak to tylko możliwe 🙂
Udało się dzięki ustawieniu licznika w tryb CTC i modyfikacji go w przerwaniu, ale w niekrytycznym momencie. Cały pomysł opiera się na tym, że zmiana górnej wartości licznika w tym trybie odbywa się automatycznie dopiero po dojściu licznika do końca. Czyli nową wartość dla następnego cyklu można wpisać w dowolnym momencie trwania obecnego bez jego zaburzania. Daje to sporo czasu na przeprogramowanie licznika i nie skutkuje jitterem czy innymi dziwnymi rzeczami. Ponieważ cały kawałek przebiegu dla jednego kanały składa się z impulsu synchronizującego, a później z o wiele dłuższego zależnego od wartości zadanej, uruchamiam licznik zawsze ze stałą wartością dla czasu synchronizacji, a po jego zakończeniu już programuję licznik na nowy cykl. Ponieważ mam na to co najmniej 10000 cykli zegarowych, szansa, że nawet jakieś inne przerwanie opóźni przeprogramowanie jest właściwie zerowa.
A ponieważ przeprogramowywanie odbywa się w przerwaniach, więc niezależnie co robi główny wątek programu, to sygnał PPM jest zawsze generowany.

Odczytywanie wartości, przeliczanie i inne rzeczy

Kolejnym ciekawym rozwiązaniem jakie zastosowałem w tym oprogramowaniu jest multitasking (tak, na AVR:-) )
Ponieważ przerwania powinny być w miarę krótkie, natomiast proces przeliczania bloczków może trwać trochę dłużej, postanowiłem zrobić coś co pozwoli na ciągłe i prawidłowe działanie aparatury nawet jak dużo klikamy po menu czy wykonujemy inne czasochłonne operacje, które zabijają programy oparte na jednej pętli ze wszystkim.

Co się w takim razie naprawdę dzieje w tym sofcie?
Z powyższego widać, że w przerwaniach generowany jest sygnał PPM. Na przerwaniach również odczytywane są przetworniki ADC, przeliczane na zakres -1..1 i wstawiane w odpowiednie kanały. W przerwaniach jest również przeglądana klawiatura. Żadne z tych przerwań nie blokuje procesora na więcej niż kilkaset taktów.
Pozostają jeszcze dwie rzeczy: przeliczanie bloczków, które może zająć więcej czasu (więc nie powinno być robione w przerwaniach) oraz obsługa klawiatury i wyświetlanie informacji na wyświetlaczu (przerysowanie kolorowego wyświetlacza potrafi trwać nawet koło miliona taktów!). W tym wypadku postanowiłem, że wątek 'wyświetlacza’ jest głównym wątkiem i działa cały czas. Natomiast zaraz po tym jak zostaną zebrane nowe wartości z przetworników ADC wątek ten jest wywłaszczany i uruchamiane jest w jego miejsce przeliczanie bloczków. Gdy wszystkie bloczki zostają przeliczone, program wraca do poprzedniego wątku. W ten sposób wszystko robione jest o czasie, a klikanie po menu i wyświetlanie na ekranie nie ma żadnego negatywnego wpływu na działanie nadajnika.

Dodatkową zaletą multitaskingu jest to, że programując 'user interface’ nie muszę się martwić o czas wykonywania, czy dzielenie procedur na kilka części i uruchamianie ich po kawałku (jak to robiłem w GPS-ie).

Pamięć

Zdecydowałem się użyć wewnętrznej pamięci Flash (programu) jako miejsca na definicję modeli (bloczki, wartości kanałów itd). Dane są zapisywane 'kontenerami’ z odpowiednimi nagłówkami (numer modelu, typ bloczku itp), żeby można było szybko znaleźć w takim śmietniku odpowiedni bloczek. A ponieważ jest to pamięć flash o mniejszym życiu niż wbudowany, ale mały eeprom, więc jest jeszcze jedno dodadkowe założenie: każdy bloczek może wystąpić więcej niż jeden raz – w takim wypadku aktualnym jest ostatni. Pozwala to zmodyfikowane bloki po prostu zapisywać na końcu pamięci, a całość 'odśmiecać’ dopiero co jakiś czas na żądanie.
Z drugiej strony używanie trymerów mogło zapchać w ten sposób pamięć bardzo szybko, więc zdecydowałem, że jako tymczasowe miejsce do przechowywania będzie używany eeprom. Gdy już wszystko wytrymujemy jak trzeba, to można przenieść wartości kanałów z eepromu do flasha.

Właściwości nadajnika

• Pamięć modeli (maksimum 31).
• Każdy model składa się z:
  • komentarzy (maksimum 256/model), nazwa modelu jest jednym z nich i jest obowiązkowy, komentarze mogą opisywać kanały jak i bloczki
  • kanałów, niektóre są dedykowane jako wejście, niektóre jako wyjście, reszta moża być użyta jako miejsce na trymery, rewersy czy do połączeń pomiędzy bloczkami (maks. 253/model)
  • bloczków, które robią całą przeliczeniową część 'czarnej skrzynki’ (maksimum 255/model)
  • listy w jakiej bloczki powinny być przetwarzane, obecnie lista musi być ręcznie robiona, ale możliwe, że w przyszłości będzie generowana automatycznie
• 8 kanałów wyjściowych, można zwiększyć, ale należy pamiętać, że wtedy ramka już może się nie zmieścić w standardowym czasie i trzeba będzie coś zmienić
• 8 analogowych wejść z możliwością podłączenia pod nie przełączników
• wyjście PPM (super dokładne, wolne od jiteru, ok. 11000 kroków na kanał)
• wewnętrzne obliczenia robione na 16 bitowych liczbach stałoprzecinkowych (6+10), czyli z rozdzielczością ponad 2048 kroków
• bootloader po porcie szeregowym, czyli upgrade firmware może być zrobione zwykłym kablem usb-serial(ttl)
• kolowy wyświetlacz LCD
• 6 klawiszy do nawigacji po menu
• Open source! (kod wrzucę niedługo)

Troszkę historii

W 2006, kiedy zacząłem interesować się modelami R/C, kupiłem najtańszą 4 kanałową aparaturę z myślą, że jak będę potrzebował czegoś więcej, to na tej bazie zrobię sobie już sam:-)
Gdzieś pomiędzy 2007 a 2008 podczas dyskusji na forum Alexrc narodziła się idea super elastycznego nadajnika.
Pomysłem było, żeby to co jest w środku nadajnika dało się zdefiniować przy pomocy bloczków z podstawowymi funkcjami matematycznymi i połączeniami pomiędzy nimi, wejściami i wyjściami.
W 2008 zrobiłem sobie uniwersalną płytkę do wielu zastosowań na Atmega8L i z wyświetlaczem z telefonu Siemens S65.
W 2009 wymieniłem Atmega8L na Atmega88 – dzięki temu mogłem podnieść taktowanie procesora z 7MHz do ponad 11MHz nadal pozostając w zgodzie ze specyfikacją procesora i zasilając go z 3V. I tu prawdziwa historia się zaczyna 🙂
Pod koniec 2009 miałem już kilka rzeczy skończonych: generowanie ppm, przeliczanie bloczków, multitasking, podstawy interfejsu użytkownika (menu, klawiatura). I od tej pory projekt utknął na prawie 3 lata.
Chciałem zrobić wszystko zbyt uniwersalne i niestety to podejście nie sprawdziło się do intefejsu użytkownika. Podczas tych lat używałem kilku prostych nadajników, które do moich samolotów sprawdzały się całkiem nieźle. Ale nowy projekt Tricoptera zmienił wszystko, gdy nie byłem w stanie żadnym nadajnikiem uzbroić płytki sterującej, poza tym nagle zaszła potrzeba posiadania więcej niż 4 kanałów. W ten sposób stary projekt odżył.
Pod koniec 2012 usunąłem praktycznie cały 'superuniwersalny’ kod generujący menu, przemyślałem pewne rzeczy (trzymanie trymerów również w eepromie) i od tego czasu projekt poszedł naprzód.
Płytkę wsadziłem do starego nadajnika, który kupiłem za 5zł, dodałem moduł FrSky DHT, podłączyłem razem do kupy i teraz można tego już używać w prawdziwym świecie 🙂

Przyszłość

• Zmiana procesora na Atmega168 lub od razu na Atmega328 (kod jest gotowy dla obydwóch – trzeba tylko porobić płytki i polutować)
• Ponieważ obecnie praktycznie nie jest możliwy już zakup wyświetlacza od S65 (mimo, że mam jeszcze zapas 🙂 ), to kupiłem już podobny i postaram się jego również obsługiwać.
• Przejrzenie i zmiana kodu, żeby można było go uruchomić na zwykłej płytce Arduino z procesorem Atmega328 (czyli dostosowanie do innej częstotliwości taktowania).
• Więcej kodu, więce funkcjonalności (niestety już nie na Atmega88, bo więcej tam się już nie zmieści w pamięci)
• Timery, extender i/o (możliwość podłączenia dodatkowych wejść, wejście trenera)
• …