Navi by Breweryhills

Autorskie projekty naszych użytkowników

Moderatorzy: marbalon, moderatorzy2014, moderatorzy

breweryhills
Posty: 746
Rejestracja: czwartek 01 wrz 2011, 10:44
Lokalizacja: Gdańsk

Navi by Breweryhills

Post autor: breweryhills »

Cześć !

Wszyscy coś robią, jak nie strugają ram czy gimbali to konstruują inne cacka :-) Po moich przeżyciach i doświadczeniach, postanowiłem też coś sklecić. Zresztą po przejściach z Hornetem X4 i utracie MK obiecałem sobie że doprowadzę Horneta do stanu, w którym będzie latał nie gorzej niż MK na pełnym wypasie. Część tego planu została wykonana po tym jak Klenio z RC Concept wymienił mi CSDU na latające prosto. Teraz Hornet lata bardzo ładnie, jednakże jest głupi. Albo inaczej - nie jest mądry :mrgreen: No a mówiąc bardziej poważnie, to nie posiada komputera nawigacyjnego oraz wielu innych funkcji, które mogą powstać w mojej rozkapryszonej głowie. Tak więc powstała idea kompa "wszystkomającegocopotrzeba", dającego się sprzęgnąć z różnymi FC w elegancki sposób.

W dniu dzisiejszym zakończyłem prace projektowe nad prototypem, mogę więc się troszkę pochwalić. Otóż idea była taka, by w możliwie kompaktowy i elegancki sposób stworzyć wielofunkcyjny komputer pokładowy, nie realizujący funkcjonalności FC ale ją uzupełniający o wszystko inne, czego typowy FC nie ma. Nawigację, telemetrię, sterowanie long range, obsługę wyposażenia pokładowego, OSD... W efekcie powstało coś takiego:

Obrazek
Obrazek

Komputer złożony jest z dwóch płytek. Dolna, główna zawiera główny procesor, czujnik ciśnienia atmosferycznego, zasilacze, wzmacniacz audio, złącza zasilania oraz we/wy. Górna zawiera moduł radiowy, odbiornik GPS, magnetometr i akcelerometr oraz obsługę toru AV oraz OSD. Mechanicznie konstrukcja jest dostosowana do zabudowania na CSDU z RC Conceptu bez użycia kabli oraz dodatkowo posiada otwory montażowe zgodne z MK/CD.

Najważniejsze cechy przyjęte w projekcie:
* 12 wejść/wyjść PWM, PPM lub programowanych
* łączność dwukierunkowa w paśmie 868MHz, pozwalająca na telemetrię oraz sterowanie bez użycia dodatkowego odbiornika RC (możliwe będzie użycie obu jednocześnie, co zapewni redundancję sterowania)
* obsługa sześciu wiązek sonaru (góra, dół, przód, tył, lewa, prawa), pozwalających na loty w sąsiedztwie przeszkód oraz realizację sprzężonego (sonar + baro + acc Z), samodzielnego startu i lądowania oraz niski lot po profilu stałej wysokości nad poziomem gruntu
* osiem wyjść wysokoprądowych o napięciu baterii, umożliwiających programowane sterowanie różnymi odbiornikami (LED, spadochron etc.)
* czujnik temperatury i wilgotności, pozwalający wykrywać wlot w strefę możliwego zawilgocenia, oszronienia itd.
* dodatkowe złącze UART
* dodatkowe złącze UART lub I2C (definiowalne)
* obsługa czytnika RFID, pozwalającego rozpoznawać podłączone pakiety (poprzez przyklejone na nich tagi RFID) i odpowiednio reagować na ich pojemność, zarządzać naładowaniem itd.
* wbudowana sygnalizacja dźwiękowa w oparciu o głośnik ceramiczny (nie biper ceramiczny) - zapewnia to wysoką głośność i eliminuje problemy z magnetometrem
* OSD graficzne o rozdzielczości 352x288, z dwubitowym pikselem (czarny, biały, przeźroczysty oraz półprzeźroczysty; poziom czerni, bieli oraz półprzeźroczystości definiowalny i zmienny w ramach ramki obrazu)
* wbudowany przełącznik dla trzech sygnałów video
* zasilanie kamer i nadajnika 5V/12V z przetwarzaniem (częstotliwość przetwarzania ok. 1MHz) oraz filtracją LC, napięcia niezależne od napiecia zasilania navi
* zasilanie navi od 2S do 8S
* obsługa mikrofonu elektretowego
* sygnalizacja akustyczna i głosowa w OSD

Całością zarządzać będzie kontroler NXP LPC1788 120MHz, obsługę OSD oraz AV robić będzie drugi Cortex M3 - LPC1759. Pomiar ciśnienia barometrycznego realizowany będzie czujnikiem MPXHZ6130A z użyciem 24-bitowego przetwornika MAX11210 i niskoszumnego źródła napięcia odniesienia MAX6143, dostarczającego także informacji o temperaturze. To pozwoli na wtórną kompensację dryfu temperaturowego czujnika. Cały układ zamknięty będzie nieszczelną puszką ekranującą, która osłoni układ pomiarowy przed światłem, wiatrem oraz zakłóceniami.

Projekt obecnie traktuję jako dopełnienie tego co daje mi praca przy FPV Recorderze. FPVR jest jednak czysto software'owym projektem a do pełni szczęścia potrzeba mi grzebania się w hardware :-) Proszę nie pytać o możliwości kupna itd. - to ma być dla mnie przyjemność i nauka nowych zagadnień, więc nie zamierzam się spieszyć tym bardziej że mam też inne rzeczy na głowie. Oczywiście jeżeli z tego wyjdzie coś naprawdę wartościowego, nie wykluczam wprowadzenia tego na rynek jako produktu. Do tego jednak droga dość daleka.
Pozdrawiam, Sebastian
Awatar użytkownika
Rurek
Posty: 16419
Rejestracja: środa 10 mar 2010, 15:21
Lokalizacja: AIP ENR 5.5 - AAA 153 :-)

Post autor: Rurek »

napiszę krótko: WOW :shock:
her Holger będzie mógł tylko wydusić z siebie jakieś przekleństwo, może nawet po polsku ;-)
A spytam tylko po co pełne IMU skoro dane z gyro i acc możesz pobierać z płytek głownego FC ?
infekcja FPV postępuje w zastraszającym tempie...
cholo
Posty: 3371
Rejestracja: środa 03 lut 2010, 21:38
Lokalizacja: Kraków

Post autor: cholo »

Rurek pisze: A spytam tylko po co pełne IMU skoro dane z gyro i acc możesz pobierać z płytek głownego FC ?
jak rozumiem produkt ma byc uniwersalny wiec po co za kilka dolczaskow meczyc sie w jaki sposob pobrac dane z roznych fc ;-)
breweryhills
Posty: 746
Rejestracja: czwartek 01 wrz 2011, 10:44
Lokalizacja: Gdańsk

Post autor: breweryhills »

Rurek pisze:napiszę krótko: WOW :shock:
Mam nadzieję że urządzenie zasłuży na to WOW - generalnie jednak założenie było takie, by zrobić coś co będzie lepsze niż MK. W mojej opinii MK wcale nie jest żadnym cudem świata, natomiast ma jedną wielką zaletę i to ona stawia go na razie w czołówce: jest jedynym projektem który oferuje taką funkcjonalność.
Rurek pisze:A spytam tylko po co pełne IMU skoro dane z gyro i acc możesz pobierać z płytek głownego FC ?
Tu nie będzie pełnego IMU. Akcelerometr jest natomiast potrzebny do kompensacji danych z magnetometru. Przy okazji dane z niego będą używane do wyświetlania sztucznego horyzontu. Navi będzie mogło współpracować z FC (poprzez złącze UART), ale samo w sobie będzie całkowicie niezależne w realizacji własnych zadań.
Pozdrawiam, Sebastian
breweryhills
Posty: 746
Rejestracja: czwartek 01 wrz 2011, 10:44
Lokalizacja: Gdańsk

Post autor: breweryhills »

cholo pisze:jak rozumiem produkt ma byc uniwersalny wiec po co za kilka dolczaskow meczyc sie w jaki sposob pobrac dane z roznych fc ;-)
Dokładnie :-) Poza tym już nawet nie chodzi o różne protokoły (a niektóre w ogóle nie wypluwają takich danych), pomiary wektora przyspieszenia oraz wektora pola magnetycznego muszą być wykonane możliwie jednocześnie. Kompensowanie wektora pola wektorem przyspieszenia odczytanym np. sekundę wcześniej może być...hmmm... lekko mylący ;-) W efekcie ogon stabilizowany takim sposobem mógłby być bardzo niespokojny... :-D
Pozdrawiam, Sebastian
pit202

Post autor: pit202 »

a czemu wybrałeś 868 zamiast 433.xx ? wiem , że na elektrodzie wszyscy narzekają na 433 i się przeprowadzają na 868 , ale czy przez to nie będzie tak , że się zrobi śmietnik w 868 a 433 zrobi się puste i czyste ?
Awatar użytkownika
elektron
Posty: 1169
Rejestracja: sobota 29 sty 2011, 22:37
Lokalizacja: Dęblin/Warszawa
Kontakt:

Post autor: elektron »

Fantastycznie, że polska myśl techniczna w takim tempie się rozwija !!
Będę z uwagą śledził postępy prac !!
Brawo !
Awatar użytkownika
PeTe
Posty: 85
Rejestracja: niedziela 28 lis 2010, 20:30
Lokalizacja: Gdynia

Post autor: PeTe »

Wygląda ciekawie, jeżeli mogę pomęczyć - co rozumiesz po pojęciem sonar, jakie odległości od przeszkód masz na mysli, jakiej szerokości będą wiązki, o jakiej selektywności myślisz, jak zamierzasz rozwiazać problem Dopplerowski...
Awatar użytkownika
kuki83
Posty: 2091
Rejestracja: wtorek 19 paź 2010, 19:08
Lokalizacja: Ropczyce/Podkarpacie

Post autor: kuki83 »

kuki lubi to :-)
breweryhills
Posty: 746
Rejestracja: czwartek 01 wrz 2011, 10:44
Lokalizacja: Gdańsk

Post autor: breweryhills »

pit202 pisze:a czemu wybrałeś 868 zamiast 433.xx ? wiem , że na elektrodzie wszyscy narzekają na 433 i się przeprowadzają na 868 , ale czy przez to nie będzie tak , że się zrobi śmietnik w 868 a 433 zrobi się puste i czyste ?
Po pierwsze - 868MHz to dwa razy mniejsza antena a to w naszym wypadku ma znaczenie. Po drugie i jak sam wspomniałeś, 434MHz to śmietnik. Pracuje tam wszystko - piloty samochodowe, zabawki, radiomodemy, zdalne sterowanie wszelkiej maści oraz ciągle jeszcze w użyciu są radiotelefony 433MHz. 868MHz jest czyste i nie należy zakładać że zrobi się w nim śmietnik. W tym paśmie pracują i będą pracować urządzenia relatywnie nowoczesne technologicznie, szybkie i oszczędnie gospodarujące pasmem. 434MHz nie zrobi się nagle puste, ciągle masa urządzeń pracuje na 434MHz i ciągle produkowane są nowe.
Pozdrawiam, Sebastian
breweryhills
Posty: 746
Rejestracja: czwartek 01 wrz 2011, 10:44
Lokalizacja: Gdańsk

Post autor: breweryhills »

PeTe pisze:Wygląda ciekawie, jeżeli mogę pomęczyć - co rozumiesz po pojęciem sonar, jakie odległości od przeszkód masz na mysli, jakiej szerokości będą wiązki, o jakiej selektywności myślisz, jak zamierzasz rozwiazać problem Dopplerowski...
Pod pojęciem sonar rozumiem pomiar odległości poprzez pomiar czasu drogi impulsu odbitego od przeszkody. To wbrew pozorom proste i tanie rozwiązanie a rozwiązuje wiele problemów z lataniem blisko podłogi. Na pierwszy ogień wziąłem do testów czujniki Parallax-a PING))) - http://www.parallax.com/tabid/768/Produ ... fault.aspx. Są to gotowe moduły pomiarowe, działające w prosty sposób, sprawdzone w innych zastosowaniach i niedrogie. Oferują zakres od 2cm do 3 metrów, co uważam za wystarczające na potrzeby wspomagania startu i lądowania oraz poruszania się w sąsiedztwie przeszkód. Znając temperaturę powietrza oraz pochylenie/przechylenie platformy można precyzyjnie określać odległość od podłoża. Lądowanie automatyczne może wówczas być wykonywane dwuetapowo - pierwszy etap to schodzenie w dół z wykorzystaniem czujnika baro. Po osiągnięciu 3-metrowej strefy działania sonaru, zaczyna się drugi etap w którym navi korzysta z sonaru, sprawdzając dla bezpieczeństwa korelację między sonarem a baro (to jest właśnie to sprzężenie, przy czym jest ono słabsze im mniej zostało do ziemii) - w razie jakiegoś znacznego rozjechania się obu sygnałów można przerwać podejście. W każdym razie na sonarze można kontynuować podejście aż do przyziemienia, bo sonar jest precyzyjny i niewrażliwy na efekt przyziemny, który fałszuje odczyt baro. Po osiągnięciu określonej minimalnej wysokości następuje wyłączenie gazu... i wylądowali :) Jest to zresztą analogia do dużego lotnictwa - tam stosuje się radiowysokościomierz do tego samego celu. Zasada ta sama, tylko tam odbijają się fale radiowe a tu ultradźwięki.

To oczywiście ogólny koncept - diabeł będzie tkwił w szczegółach i na pewno tak łatwo nie pójdzie. Dzięki ultradźwiękom jest to jednak do zrobienia :) W swojej koncepcji założyłem do sześciu czujników, pozwalających teoretycznie umieścić kopterka w pokoju i będzie on starał się wisieć w połowie między podłogą a sufitem, zachowując dystans do ścian. W praktyce chodzi o możliwość wykrywania przeszkód, co jednak wymagać będzie relatywnie wolnego latania tak aby sonar zdążył zmierzyć te trzy metry (chociaż są czujniki pracujące nawet do 10 metrów) i zatrzymać platformę zanim dojdzie do kolizji.
Pozdrawiam, Sebastian
Awatar użytkownika
PeTe
Posty: 85
Rejestracja: niedziela 28 lis 2010, 20:30
Lokalizacja: Gdynia

Post autor: PeTe »

Nazwa sonar jest tu niezbyt wygodna bo z właściwym sonarem niewiele ma wspólnego. Dalmierze ultradżwiekowe o których piszesz mają jedna zasadnicza wadę jeżeli zalożysz ich kilka (tak przynajmniej napisaleś) na tak malym obiekcie jakim jest to latadelko to biorac pod uwagę szerokosc poszczegolnych wiązek same nawzajem zaczną sie zakłucać przekłamując pomiary echami nie swoich nadajników, nie mówię o pokoju gdzie echa falszywe mogą spowodować konieczność conajmniej odmalowania scian i sufitu jak... z ta klasą sprzętu pomysl lekko nietrafiony.
breweryhills
Posty: 746
Rejestracja: czwartek 01 wrz 2011, 10:44
Lokalizacja: Gdańsk

Post autor: breweryhills »

PeTe pisze:Nazwa sonar jest tu niezbyt wygodna bo z właściwym sonarem niewiele ma wspólnego.
No nie wiem - określenia sonar użyłem w odniesieniu do pierwotnego rozwinięcia zwrotu "SOund Navigation And Ranging". Niewątpliwie mamy tu "navigation" (nawigację) oraz "ranging" (określanie odległości). Oczywiście, współczesne sonary to bardzo rozwinięte urządzenia, ale to że one są rozwinięte nie ujmuje tym czujnikom prawa nazywania ich sonarami.
PeTe pisze:Dalmierze ultradżwiekowe o których piszesz mają jedna zasadnicza wadę jeżeli zalożysz ich kilka (tak przynajmniej napisaleś) na tak malym obiekcie jakim jest to latadelko to biorac pod uwagę szerokosc poszczegolnych wiązek same nawzajem zaczną sie zakłucać przekłamując pomiary echami nie swoich nadajników, nie mówię o pokoju gdzie echa falszywe mogą spowodować konieczność conajmniej odmalowania scian i sufitu jak... z ta klasą sprzętu pomysl lekko nietrafiony.
Przykład z lataniem w pokoju miał raczej obrazować ideę kontroli dystansu :-) Co do wzajemnego zakłócania się to się raczej nie zgodzę, bo czujniki nie będą pracować jednocześnie a sekwencyjnie - z odstępem gwarantującym nie łapanie się na drugie echo. Poza tym, w danej chwili będą używane najwyżej cztery czujniki a w normalnym lataniu trzy: dolny oraz dwa po każdej ze stron kierunku lotu. Wiązki nie są szerokie i na pewno nie będą się nachodzić, co akurat z mojego punktu widzenia nie jest korzystne bo powstaje martwa strefa detekcji. To wszystko jednak ma jednak znaczenie badawcze - ja wcale nie jestem przekonany że to się sprawdzi. Może się okazać że cała tak pięknie wyglądająca idea nie sprawdzi się w kopterach i to z przyczyn, których sobie teraz nie wyobrażamy :-)
Pozdrawiam, Sebastian
Awatar użytkownika
Rurek
Posty: 16419
Rejestracja: środa 10 mar 2010, 15:21
Lokalizacja: AIP ENR 5.5 - AAA 153 :-)

Post autor: Rurek »

chłopaki w projekcie multiwii przetestowali tego sonarka ...troche tańszy od Twojego bing-banga :-)

I wątek na temat: klik! forum multiwii


Obrazek
infekcja FPV postępuje w zastraszającym tempie...
breweryhills
Posty: 746
Rejestracja: czwartek 01 wrz 2011, 10:44
Lokalizacja: Gdańsk

Post autor: breweryhills »

Rurek pisze:chłopaki w projekcie multiwii przetestowali tego sonarka ...troche tańszy od Twojego bing-banga :-)
Bo to wcale nie musi być PING :-) Tych modułów troszkę jest i wszystkie one mogą się nadać. Generalnie spore pole do ciekawych eksperymentów ;-)
Pozdrawiam, Sebastian
ODPOWIEDZ