WIRTUALNY KLUB MODELARZY RC

Jak pewnie pamiętacie z innych moich wątków, używam w swoim OSD oraz autopilocie czujników położenia modelu skonstruowanych na bazie termopili (lub zwanych z polska termostosów), rejestrujących różnicę temperatur pomiędzy ziemia i niebem. Jakkolwiek proste i stosunkowo tanie, mają one swoje wady. Między innymi trzeba je przed każdym lotem kalibrować, oraz reagują na chmury i słońce, co zakłóca trochę działanie autopilota.
Do tego autopilot bazujący na odczytach GPS-a w celu ustalania kierunku ruchu modelu nie jest zbyt dokładny ani szybki.

Postanowiłem więc pójść za ciosem i zbudować czujnik, pozbawiony tych wad. Wybrałem dosyć klasyczną metodę połączenia żyroskopów, magnetometrów oraz czujników ziemskiego pola magnetycznego.
Pierwsze podejście do tematu mogliście zobaczyć w opisie quadrokoptera, który powstał jako pierwsza platforma testowa.

Doświadczenia zebrane z tym pierwszym eksperymentalnym projektem pozwoliły na zgłębienie tematu, oraz poznanie wszystkich uproszczeń, wad i niedogodności podobnych projektów (które przy okazji mniej lub bardziej poznałem).

Przyszedł więc czas na otwarcie własnego projektu z prawdziwego zdarzenia, najpierw jako sama "jednostka IMU" zwracająca dane o położeniu modelu do mojego OSD i autopilota, docelowo jako nowa wersja autopilota, zintegrowana z IMU i OSD.

Pierwsze podejście to dwuwarstwowa "kanapka" składająca sie z płytki czujników (tu jeszcze stara płytka, która jest w trakcie przeprojektowywania), oraz prototypowa płytka mikroprocesora, obrabiajaca dane z czujników i wysyłajaca je do OSD. Gabaryty tej "kanapki są niewiele większe jak czujnika horyzontu na termopilach.
A tak to wygląda:



I dwie składowe płytki:



Wprawdzie mogłem skorzystać z dostępnych na sieci kodów źródłowych projektów IMU (lekko je modyfikując), ale postanowiłem napisać całe oprogramowanie od zera. Raz, ze nie podobał mi się styl pisania kodu, dwa że musiałbym rozwiązać problem praw autorskich (i pewnie tantiem), a po trzecie i najważniejsze rozwiązania te zawierały zbyt daleko idące kompromisy, na które nie mogłem się zdecydować myśląc nie tylko o quadrokopterze "wiszącym" praktycznie zawsze prawie poziomo, ale również o samolotach wykonujących pętle i beczki, zawisy na śmigle, loty odwrócone, torque roll czy lot na żyletkę (takie zjawisko w ogóle nie występuje w Quatro, chyba że myślimy o locie wyłącznie w kierunku ziemi .
Dostępne (i znane mi) algorytmy IMU nie obsługują prawidłowo takich sytuacji. Tak więc decyzja zapadła: startuję od zera.
Druga trudna decyzja to był wybór procesora. Wprawdzie pierwsza wersja powstała na bazie Atmega 644, ale z różnych względów oparłem się o ograniczenia tego procesora. Tak więc zdecydowałem się na zupełnie nowy procesor i zupełnie nowy projekt płytki bazowej. Poprzedni projekt, zrobiony z myślą o quadrokopterze również nie przystawał do moich celów.
No więc teraz kilka założeń:
Moduł IMU będzie komunikować się z OSD zastępując moduł na Termopilach. Podłaczony będzie do tego samego złacza co termopilowy, ale będzie komunikował się cyfrowo przekazując znacznie więcej danych do OSD:
-Pitch (pochylenie nosa modelu w górę / dół)
-Roll (przechył na skrzydło)
-Yaw (kierunek geograficzny w który skierowany jest model)
-Szybkość ruchu (obrotu) modelu w każdym kierunku, w zakresie od 0.15 do 300stopni/sek. Ruchy poniżej 0.15 stopnia/sek, jakkolwiek rejestrowane przez IMU będą przesyłane do OSD jako zero .
-Temperaturę otoczenia
Oczywiście OSD będzie wymagał zaktualizowanej wersji oprogramowania, ale zachowana jest pełna kompatybilność z płytką i złączem w OSD
IMU będzie się posiadał opcję kalibracji (kompensującą niedokładności mocowania w modelu), choć nie będzie wymagał regulacji przed każdym lotem. Ma być bezobsługowy: podłącz zasilanie i leć!
Co mam już zrobione na dzień dzisiejszy?
-Pobieranie danych z czujników, filtrowanie danych (eliminowanie wibracji)
- Rozpracowane i zaimplementowane trygonometryczne zależności między układami odniesienia żyroskopów i akcelerometru, na razie w odniesieniu do pitch i roll (w zalezności od wszystkich 3 zyrokopów), w obróbce również Yaw.
-komunikację między IMU a OSD
-algorytm łączenia informacji z żyroskopów i akcelerometrów oraz kompensowania dryftu żyroskopów (zwany często filtrem Kalmana, choć ta nazwa jest czasem nadużywana. Ja nie stosuję macierzowego filtru Kalmana, tylko mój autorski algorytm)


Prawdę mówiąc transformacja układów odniesienia i przetransponowanie współrzędnych i ruchów żyroskopów na współrzędne względem ziemi (dla wszystkich możliwych i niemożliwych położeń IMU) to chyba najtrudniejsza część projektu. Pierwsze podejście, stricte matematyczne (czy raczej trygonometryczne) jakkolwiek poprawne i rewelacyjnie działające w Excelu poległo w implementacji w na mikroprocesorze, na z racji niedostatecznej dokładności biblioteki funkcji trygonometrycznych. Tak więc musiałem jeszcze raz przyjrzeć się rzutowaniu wektorów na płaszczyznę, zależności między poszczególnymi funkcjami trygonometrycznymi, miejscami najbardziej narażonymi na błędy zaokrągleń i w konsekwencji druga wersja zadziałała całkiem dobrze. W opracowaniu jest już wersja trzecia, która powinna zachowywać się już idealnie. Głowę mam już chyba ze dwa razy większą, a tangensy hiperboliczne to dla mnie bułka z masłem
Tak czy siak, na ekranie telewizora, w moim OSD pięknie widać jak rusza się sztuczny horyzont zgodnie z poruszeniami płytki.
Na święta wyjeżdżam, więc odpocznę od trygonometrii i macierzy. Ale po świętach prace ruszą dalej pełną parą. W końcu sezon otwarty i trzeba latać!

_________________
Zbigniew Bigaj

Moja głowa ratunku.... wracam do szkoły poprosić o zwrot kasy za naukę bo niczego mnie nie nauczyli. Tylko czy moja szkoła jeszcze istnieje? .

Zbyszku, trzymam kciuki i kibicuję

_________________
Łagodnych lądowań
Tomek "Wiedźma" Jędrzejczak

NIE Dzieciom NEO

Rzeczywiscie,dla laika w tym temacie[czyt. ja] to czarna magia Gratuluję pomysłu i cierpliwosci.Oczywiscie tak jak kolega wyzej trzymam kciuki zeby sie wszystko udało.Pozdrawiam.

_________________
piotr
Jeszcze się tak nie zdarzyło,żeby coś zostało w powietrzu i nie spadło........

Problem tak naprawdę nie jest w nauce trygonometrii, tylko w tym, że w żadnej szkole nie uczono nas wyobraźni przestrzennej w odniesieniu do trygonometrii.

Zakończyłem zgrywanie żyroskopów z akcelerometrami. O mało nie ukręciłem sobie nadgarstka, testując wykręcanie płytki na wszystkie sposoby
Przy okazji zastanawiam się, czy 300stopni/sekundę to nie za mało?
W ręku spokojnie mogę "wykręcić" znacznie więcej. Pewnie akrobat tez zrobi to bez trudu. Oczywiście jedyna konsekwencja jest taka, że horyzont po wyprostowaniu jest przechyle ("spóźniony" w osi która przekroczyła to 300deg/s) i w ciągu kilku sekund "nadrabia" to i wraca do prawidłowego położenia. W sumie bez problemów mogę w każdej chwili zrobić 1200deg/s.

_________________
Zbigniew Bigaj

Śledzę temat i staram się coś zrozumieć

_________________
Tomek (Cobra)
latam głównie FPV

Tu nie ma co rozumieć, Tak naprawdę w środku siedzą takie małe Chińczyki, i jak im się podłoga przechyla, to kręcą korbką żeby wyrównać. A korbka jest podłączona kabelkiem do mojego OSD i tam rusza kreską horyzontu. To wszystko.

_________________
Zbigniew Bigaj

Kolejny rewelacyjny temat. Jak zwykle dużo nowych, ciekawych rzeczy człowiek się dowie i uświadomi sobie jeszcze bardziej jaki jest głupi . Kibicuję jak zwykle.

A mnie kiedyś uczono geometrii przestrzennej

_________________
Pozdrawiam Wojtek K.
Turnigy 9X + Assan 2,4 GHz; Pelikan 4kan. 35 MHz; Cessna 480, EG Pro

Witam
Zbig chylę czoła!!! Przed waści zacnym i nie pierwszym wyczynem.
Naprawdę skąd ty masz czas na te dodatkowe projekty?
Człowiek się cały czas uczy, a i tak ciągle odkrywa że jest wielu lepszych
To tak, żeby nie napisać wiecie czego
Pozdrawiam serdecznie Marek von Zbieg

_________________
Marek von Zbieg 2,4GHz
Rafał 35MHz kg 69 kr 80
Biorę udział w akcji "Chcę pisać poprawnie"

Może 1200 to przesada , ale 720 jak najbardziej się przyda. Szczególnie w
małych modelach.

_________________
Kazik