Witam

Mój projekcik nabiera rozpędu, więc pomyślałem, że się pochwalę, oraz ew. dam pole do sugestii i uwag ze strony szanownych forumowiczów.

Jak wspominałem w powitalni, majstruję quadro, które głównym komputerem ma być... zwykły smartfon. Założenie jest takie, że w większości smartfonów cała potrzebna elektronika już jest (akcelerometry, żyroskopy, GPSy etc.) plus jest wygodne do programowania środowisko, plus cała gama zabawek związanych z łącznością itd. Wg mnie to szalenie interesująca perspektywa.

Jestem na etapie majstrowania drona i przygotowywania całego zestawu do lotu. Na dzień dobry maszyneria:
- rama S500-PCB (http://abc-rc.pl/Quadcopter-S500-PCB)
- silniki emax MT2213 (935KV)
- śmigła GF 10x4,5 (nylon+carbon)
- Esc Emax SimonK 20A
- akumulatorek 3s 2200 mAh (jakiś niedrogi)
(Wrzucam tylko jedno zdjęcia, bo każdy z Was wie mniej więcej jak wygląda poskładany dron, a i ja nie stosuję żadnych specjalnych myków konstrukcyjnych )


Co do elektroniki to tu zaczyna się kombinowanie. Generalnie mój chytry plan jest taki, żeby stowrzyć następujący łańcuch:
"urządzenie sterujące" ---> (jakaś forma łączności radiowej) --->"kontroler lotu" ---> (bluetooth) ---> "sterownik silników"

Komentarz do kolejnych elementów:
- sterownik silników to zbiorowisko mikroukładów (używam arduino), które mają zapewnić mi możliwość wysterowania ze smartfona silników. Ja używam Arduino Micro + sterownik PWM Adafruit + HC-05 do łączności BT (padło na Bluetooth bo jest tanio i łatwo). Ten zestaw nie zawiera żadnej logiki (no może poza prostą procedurą awaryjnego lądowania, gdyby padł smartfon kontrolujący lot - ale to i tak nie zadziała za specjalnie, bo te płytki nie mają żadnych sensorów stabilizujących ), ma za zadanie tylko wystawić po bluetooth API dla smartfona do sterowania silnikami.
- kontroler lotu to rzeczony smartfon. Będzie posiadał soft, który na podstawie wskazań czujników będzie miał za zadanie utrzymać drona w powietrzu. Ma być na stałe przytwierdzony do drona.
- urządzenie sterujące to dodatkowy element, który dla odmiany do drona przytwierdzony nie będzie. Planuję trzymać go w łapach i sterować z niego lotem (i ew. modyfikować parametry pracy kontrolera lotu). Swoista aparatura sterująca, w praktyce pewnie tablet z dodatkowym softem. Do łączności chyba znowu na początke pójdę w bluetooth - kilkanaście metrów zasięgu powinno starczyć do pierwszych testów. Potem będę kombinował, może po WiFi albo LTE - ciekawe jak będzie z opóźnieniami.

Tutaj mam zdjątko układzików podczepionych już pod drona (sorry za jakość):


Na pierwszy ogień jako kontroler lotu planuję wykorzystać smartfona LG L9 (staroć, więc nie będzie mi szkoda jakby co ). Z pożytecznych rzeczy ma na pokładzie akcelerometr. Może mi trochę brakować żyroskopu, ale moim najbliższym celem jest osiągnięcie stabilnego zwisu, myślę że akcelerometr do tego w zupełności wystarczy. Jak pomysł wypali, to poszukam smartfona z kompletem sensorów i będę kontynuował.

Aktualny etap prac jest następujący:
- latadło poskładane
- soft do adaptera PWM napisany i działa
- soft do smartfona sterującego w produkcji
- soft to urządzenia robiącego za aparaturę - w planach

To tyle, chętnie wysłucham uwag i komentarzy, jak i propozycji na co zwrócić uwagę lub z czym mogę mieć problemy

PS. Taka wątpliwość mnie naszła - każdy z tych ESC ma zintegrowanego BEC'a. Wpiąłem to wszystko w sterownik PWM i jakoś działa, ale mam zawsze wątpliwości czy dobrze robię, jak łączę V+ z kilku niezależnych źródeł (a tak wyszło, bo wszystkie V+ na płytce z wyjściami PWM są zmostkowane). Czy ESCom nie będzie przeszkadzało takie połączenie? W sumie to by mi było bardzo na rękę, bo mając takie 4 BECe spięte razem, nagle mi się robi na łączu V+ dostępne 5V/8A, czyli jakby mi w przyszłości odbiło żeby tam coś jeszcze podłączać to jest spore pole do popisu. Tylko... właśnie, czy takie spinanie BECów jest OK (pytanie noobowskie, ale wolę się tego nie nauczyć poprzez konieczność zakupu nowych ESC)?

Ciekawy projekt się zapowiada - będę z ciekawością obserwował. A teraz w miarę po kolei, odpowiedzi.
Mam te same silniki i złego słowa o nich nie powiem, pracują kulturalnie, żadnych problemów z nimi nie było. W okolicy jest również parę latających zestawów z nimi i wszyscy mają podobne wrażenia. Cichutka równa praca za niezłe pieniądze.

Co do używania telefonu jako mózgu to już miałeś paru poprzedników:
Taki mały samolocik:
http://www.poweruptoys.com/products/powerup-v3
Taki mały robocik:
http://www.designboom.com/technology/smartphone-controlled-robot-by-romotive/
A to już prawie Twoje rozwiązanie:
http://www.geek.com/mobile/quadcopter-becomes-autonomous-by-using-your-smartphone-as-a-brain-1620047/
Itd, itp - do znalezienia za pomocą wujka gugla. Na rcgroups były ze dwa nieźle opisane.

Najsłabsze ogniwo moim zdaniem jest tu:
"kontroler lotu" ---> (bluetooth) ---> "sterownik silników"
Nie uda się tu przesłać tylu danych ile jest potrzebnych żeby gładko latać ale z pewnością warto spróbować

Dlatego właśnie multiwii wymarło, gdyż nie było w stanie obsłużyć tak szybkiej komunikacji jaka jest wymagana do komunikacji z czujnikami, do wytworzenia pwm400Hz i paru innych rzeczy, które są niezbędne w takich konstrukcjach.
Atmegi 328 mają niestety sporo ograniczeń dlatego zastąpiły je układy z serii 2560 a następnie towarzystwo wzięło się za STM które mają nieco więcej mocy.

Jeśli chodzi o czujniki to pamiętaj, że wszelkie wibracje, nawet te najmniejsze powodują, że każdy cyfrowy czujnik głupieje. Postaraj się je więc od początku wyeliminować. Półeczka na wibroizolatorach od pixhawka powinna rozwiązać sprawę.
Acc to raczej za mało na stabilny lot ale z pewnością trochę pomoże zminimalizować przechyły.

Co do zasilania to tylko niektóre BECe można łączyć więc lepiej założyć, że te Twoje nie. Wypnij zasilanie (środkowy pin) ze wszystkich trzech a zasilaj całość tylko z jednego z nich.

Przejrzyj stronę projektu multiwii znajdziesz tam sporo tematów z którymi sam będziesz się musiał zmierzyć;, polecam także stronę open pilota tam są bardzo fajnie wytłumaczone algorytmy wygładzające a tych nie unikniesz jeśli chcesz bazować na danych z czujników.

Pamiętaj jeszcze żeby ściągać śmigła! Najlepiej zawsze bo można sobie nimi po prostu coś odciąć. Jeśli nie wierzysz wujek gugle podsunie Ci z pewnością parę zdjęć

Hej. Dzięki za komentarze.

Tak się właśnie spodziewałem, że już ktoś mógł używać telefonu do kontroli lotu, niemniej dalej sądzę że zrobienie tego samemu da mi dużo frajdy

Co do łączności Bt to mam następujące doświadczenia - jak próbowałem wysyłać sygnały jako łańcuch znaków,w stylu "kod:wartość" i potem do zdekodowania, to faktycznie było wolno jak diabli. Spróbowałem wtedy zmodyfikowac transfer na tablice bajtowe. Wtedy chyba adapter BT korzysta z innego trybu pracy, bo transfer zaczął śmigać w czasie rzeczywistym. Samo arduino bylo by faktycznie kłopotliwe jeśli chodzi o wytworzenie dopowoedniego sygnału pwm, ale ten dodatkowy uklad sterujący dość precyzyjnie pozwala ustawić parametry zgodne ze specyfikacją esc.

Jak nie wypali to będę kombinować z USB.

Eliminacja wibracji i algorytmy to coś co dopiero będę ogarnial. Dzięki za wszystkie podpowiedzi.

Z becami poczytam czy u mnie mozna czy nie, w ostatecznosci faktycznie je poodłącza.

Wiem o smiglach, już mi się paluchy zagoiły po pierwszych testach.

I kolejna garść linków:
http://flone.aeracoop.net/
https://code.google.com/p/androiv-uav-over-android/
https://software.intel.com/en-us/articles/how-to-develop-an-intelligent-autonomous-drone-using-an-android-smartphone

Dzięki za linki. Pobieżnie rzuciłem okiem co tam jest, muszę się w to powczytywać, bo wygląda na wielce pomocne .

Przy pisaniu oprogramowania dochodzę do momentu gdy będę musiał napisać logikę przerabiającą parametry lotu na power poszczególnych silników. W związku z tym zacząłem się rozglądać co tak naprawdę mam w tym swoim telefonie. Generalnie bida, ale mam akcelerometr (zakładam że wystarczy do stabilizacji zwisu) oraz magnetometr, przy którego użyciu może uda mi się poradzić coś na ruch obrotowy. Jeśli tak się uda, to obejdę się bez żyroskopu i będzie dobrze.

W kwestii wygładzania drgań myślę, że na początek polecę z uśrednianiem kilkunastu ostatnich odczytów z sensorów, jak będzie dalej szalało, to spróbuję może jeszcze odcinać wartości wybitnie odstające od średniej. Taki myk na początek.

Zaczynam za to docierać do innego problemu, który może się okazać poważny, mianowicie android ma jakieś drakońskie limity na liczbę wątków - jak patrzę na kody bibliotek to wychodzi że obsłuży 3 wątki. Jeden mam zajęty przez tzw. heartbeat (wątek, który daje znać wszystkim urządzeniom dookoła, że FC żyje). Powiedzmy, że na odczyty z sensorów zaczaję się eventami, ale cholera wie, czy on też nie wybudza wątków dla tych eventów. Tak czy siak potrzebuję jeszcze wątek nasłuchujący na transmisję z aparatury, i jakiś drugi heartbeat między aparaturą a kontrolą lotu. Na styk, jak pojawi się coś jeszcze to zaczną się schody.

Zacząłem pracować nad ogarnianiem danych z sensorów smartfona. Akcelerometr całkiem przyzwoicie, zresztą można było się tego spodziewać.
Za to z moich krótkich doświadczeń wynika, że liczenie obrotu ze wskazań magnetometru daje nieobliczalne wyniki Idę szukać taniego telefonu z żyroskopem.

A może tablet? Jest cięższy ale za to tańszy

właśnie obawiam się, że tablet może być za ciężki. Jak się nie da to będę się rozglądał za tabletem. Na razie wyczaiłem, że są dwa telefony, które nadają się do moich celów, i można się spodziewać, że będą dość tanie. Huawei Ascend P1 oraz Htc One S. Kilka dni popoluję na nie, zobaczymy co z tego wyjdzie.

Nawet przez chwilę się zastanawiałem czy nie kupić oddzilenie sensorów do arduino, nie przekazywać z nich danych do telefonu do analizy, albo wręczni nie zakodzić całego FC w Arduino, ale płytka z akcelerometrem i żyroskopem zdaje się być droższa niż telefony (oczywiście z drugiej ręki) które wymieniłem powyżej, więc na razie chyba szkoda zachodu.

EDIT:
Dobra, jednak czujniki do arduino można dostać też taniej niż sprawdzałem. Jeśli więc nie uda mi się wyhaczyć żadnego z tych telefonów w okolicach 100zł, to pewnie będę kupował płytkę 9DOF i przenosił logikę FC na arduino.

Wyhaczyłem Ascenda P1 za ok 100zł, lekko uszkodzonego, ale w sposób nieszkodliwy dla mojego projektu.

Na dniach będę finalizował oprogramowanie FC i wtedy się pochwalę jak to wygląda.

Tak na deser - takie coś znalazłem
https://www.kickstarter.com/projects/13 ... or-your-sm

Link coś nie działa

Działa, działa...

Wczoraj w końcu przyszedł drugi smartfon. Mam odczyty z akcelerometru oraz z żyroskopu, więc wszystko jest na pokładzie .

Jednak widzę, że czasami te sensory zwracają wartości dość drastycznie różne od tego co wynika z ich fizycznego położenia. Jest to tym bardziej martwiące, że aktualnie wartość "ostateczną" składam z 20 kolejnych próbek i do tego filtruję szczególnie wysokie odczyty. Jeśli po uśrednieniu czegoś takiego dostaję i tak chwilowe odczyty zupełnie z bani, to zaczynam się zastanawiać, czy smartfon to najszczęśliwszy pomysł i czy to w ogóle poleci.

A może trochę dramatyzuję? spróbuję jakoś to jeszcze wygładzić...
EDIT:

Nie ,dobra, cofam to marudzenie, coś w moich genialnych algorytmach musiałem popsuć, bo czyste dane z sensorów wyglądają całkiem rozsądnie. Chyba muszę porządniej przysiąć do tego mojego FC... Następny update dopiero jak się uda.

W większości trybów stabilizujących stosuję się algorytm/regulator PID czyli proporcjonalno-całkująco-różniczkujący (spróbujcie to powiedzieć szybko i po pijaku) jego głównym założeniem jest to, że każdy z modułów: proporcja, całka i różniczka zajmuje się innym kawałkiem przewidywania:
- P kompensuje uchyb bieżący
- I kompensuje akumulację uchybów z przeszłości
- D kompensuje przewidywane uchyby w przyszłości
Jest w sieci tyzylion opisów do niego, w tym również jak się go stosuje w praktyce w wielowirnikowcach

Dzięki ,w sumie to nawet miałem przyjemność na swojej ścieżce edukacyjnej się z tym regulatorem spotkać, jakoś tak podejrzewałem, że będę musiał go zaimplementować u siebie.

Na razie przewalczyłem temat sensorów, mam już czyste i ciągłe odczyty z żyroskopu i akcelerometru, na następny ogień pójdzie algorytmy wyliczające z tego wszystkiego ostateczny ciąg silników (gdzie zapewne odświeżę sobie znajomość z PIDem).

A potem może wrócę w końcu do testów praktycznych i znowu uruchomię drona

Dobra, chyba powoli zbliżam się do pierwszej wersji FC. (wolno idzie bo człowiek nie ma czasu w tygodniu posiedzieć )
Interfejs wygląda następująco:


Idąc rzędami kontrole, FC robi następujące rzeczy:
- wiąże się z elektroniką sterującą silnikami ("Connect to Drone")
- wiąże się z aparaturą sterującą ("Connect to Control") - jeszcze nie mam drugiej strony tego połączenia, będzie w następnym kroku.
- funkcje testowe:
-- engine demo - odpala silniki po kolei na 2 sekundy każdy po 10% mocy - żeby zobaczyć czy w dobrej kolejności je podpiąłem itd.
-- Test Mode - wszystki silniki włączone na 15 % oraz aktywna regulacja mocy zależnie od wskazań sensorów - cobym mógł obadać czy to w ogóle reaguje jakkolwiek, zanim oderwę drona od ziemi
- engine adjustments: w pierwszym rzędzie możliwość wpisania procentowo korekt dla poszczególnych silników - szczerze to nie wiem czy będe miał powód tego używać, jeśli prawidłowo zadziała logika analizująca wskazania sensorów. W drugim wierszu tabelki aplikacja pokazuje aktualną moc podaną na każdy z silników.
- accelerometer adjustments - korekty oraz aktualne wskazania wszystkich sensorów (czyli akcelerometr X, Y, oraz żyroskop Z).
- współczynniki regulacji - na razie z regulatora PID zaimplementowałem regulację proporcjonalną (składową P), powinno wystarczyć do oderwania drona od ziemi i posadzenia go z powrotem. Jak to zadziała to dołożę jeszcze składnik I, ponoć D niewiele wnosi. Oddzielnie mogę ustalać współczynnik dla wskazań akcelerometru i oddzielnie dla żyroskopu.

Uff. Tyle ze sprawozdania. Teraz trzeba to będzie wgrać na komórkę, przykleić ją do drona i popatrzeć jak to się zachowuje.

A nie GUI?

Sprawdź przede wszystkim co się stanie jak ktoś zadzwoni na ten telefon, albo przyjdzie sms. No chyba, że nie masz w nim karty. Takie dzwonienie w środku programu już niejeden projekt położyło

umówmy się że będzie "międzymordzie", tak żeby ochrona języka polskiego była na miejscu

Telefon jest obrany ze wszystkiego i ma powyłączane wszystkie rzeczy które mogą zaburzyć działanie programu. I tak pewnie w praktyce coś wyskoczy, jakaś aktualizacja czy komunikat o najnowszej wersji systemu android .

Aktualnie najmniejszą możliwą jednostką zmiany ciągu silnika jest u Ciebie 1% zastanawiam się czy to nie zbyt zgrubne ustawienie. Tu pewnie pierwsze loty sporo powiedzą.

Oj nie, w pola są wpisane zera "całkowite" bo tak po prostu startowo wpisałem, ale każde z pól wejściowych przyjmie dowolną liczbę zmiennoprzecinkową, i też na takich liczbach wykonywane są wszystkie obliczenia, na końcu sprowadzane do liczby naturalnej z przedziału 0 - 4095, w celu transmisji do Arduino. Samo arduino trochę to jeszcze przycina ze względu na ograniczenia sygnału PWM przyjmowanego przez sterowniki obrotów, ale całość pozwala na kontrolę silnika z dokładnością do 0,0625%, więc to już powinno wystarczyć.

No to "Go, go, go!" jak mawiali Marine z rasy Terranów

Po tygodniu przerwy ma za sobą sesję z dronem w akcji (jeszcze nie latał jakby co, ale patrzyłem w tym moim testmodzie jak to wszystko pracuje).

Efekty moich zabaw, poza kilkunastoma poprawkami do oprogramowania, są następujące:
- wygląda na to, że wszystkie algorytmy mam zaimplementowane prawidłowo (dron reaguje zgodnie z oczekiwaniami).
- coś nie tak robię z bluetooth.*

*Generalnie jest coś na rzeczy z responsywnością BT. Na początku ustawiłem aplikację, aby korygowała silniki co ok 2ms (co się przekłada na częstotliwość poprawek w okolicach 500 Hz). Niemal natychmiast po rozpoczęciu procesu transmisji dostawałem zwis na aplikacji a dron raportował, że dostawał niekompletną wiadomość. Spróbowałem przestawić na wysyłanie poprawek co 3 ms (ok 333 Hz), ale sytuacja powtórzyła się kilka razy. Jak przestawiłem na 10 ms (odświeżanie 100 Hz), to nie doświadczyłem takiego problemu (jeszcze muszę spróbować z 5 ms - 200 Hz, może pójdzie). Muszę zagłębić się w to trochę, raczej chyba nie mam tutaj do czynienia z technicznymi ograniczeniami - bluetooth 2.0 (który jest dostępny w arduino i chyba jest najsłabszą wersją z całego sprzętu jaki będzie podłączany) powinien mi zapewnić możliwość odświeżania stanu silników z częstotliwością przynajmniej 2500 Hz (licząc 16 bajtów na poj. aktualizację). Ale w pierwszym rzędzie chciałbym oblatać drona, więc mam nadzieję, że 200 Hz zadziała i wystarczy. Jeśli nie wystarczy, będę zmuszony troszkę zmienić koncepcję i jednak przenieść sensory i liczenie mocy silników do arduino.

Następny krokiem będzie napisanie sobie aparatury sterującej, i potem już w powietrze. Mam nadzieję, że do Sylwestra będę miał już wylatane kilka minut

Status na dziś:
- przewalczyłem bluetooth - znalazłem opcję przyspieszenia układu, którego używam przy arduino, teraz śmiga bez problemów, gubienia pakietów i czkawek.
- dopisałem aplikację do sterowania zdalnie całym dronem - tzw kontroler - bedzie na drugiej komórce i łączył się przez BT do FC.
- aplikacja kontroli lotu na smartfonie jest w 100% zaimplementowana i dogaduje się zarówno z arduino jak i z kontrolerem.


Zostało zamontować smartfona zawierającego FC do drona, skalibrować osie i chyba jutro spróbuję go oderwać od ziemi <jara się jak dziecko> .

BRAWO!
Bardzo ciekawy projekt i zrozwiązania. Nie zapomnij nagrać wszystkiego

Właśnie, bo bez filmu nic nie zaliczymy

Może na początek na uwięzi. ..

Jestem po pierwszej próbie. Pełen sukces - dron oderwał się od ziemi. Na jakieś ćwierć sekundy. Później obrócił się do góry nogami i na nią wrócił :/ Na szczęście ani nie zapiaszczyłem silników, ani nie połamałem śmigieł, więc mogę majstrować dalej. Z tego co sprawdziłem to widzę dwie możliwe przyczyny:
- przesył informacji o wychyleniu trwa za długo, w efekcie silniki reagują z opóźnieniem.
- mam jakiś zonk w algorytmie, ale w to wątpię, bo robiłem też próby trzymając drona za nóżki i "wyrywa się" prawidłowo.

Chciałem tego uniknąć, ale obawiam się, że czeka mnie sesja testów na sznurkach (dokładnie jak proponuje baxter). Jeśli testy potwierdzą moje obawy, lub nie wskażą innej przyczyny problemów to niestety mój szlachetny plan oparcia wszystkiego o smartfona trochę weźmie w łeb i zakupię jakiś akcelerometr / żyroskop podłączalny bezpośrednio do arduino...

Ew takie stanowisko :

ładne... nie wiem czy mi cierpliwości starczy na budowę takiego ładnego

Zamiast sznurków polecam gumę. W czasach kiedy walczyło się z MultWii o każdy parametr fajnie się to sprawdzało. Guma zawieszona centralnie dawała około 1 metra swobodnego ruchu i się nie wkręcała w śmigła.

Zrobiłem testy na uwięzi na gumie (thx Ellipsis) dla jednej z osi i zaczynam się skłaniać coraz bardziej ku tezie, że komunikacja komórka - arduino jest z jakiejś przyczyny zbyt wolna.

Sprawa wyglądała tak, że katastrofa przy starcie spowodowana była tym, że regulator był o wiele za czuły (zbyt duży współczynnik). W sensie miałem go ustawionego na ok 30-50, podczas gdy quadro przwidywalnie zachowywał przy 0.5-2. Jednak w czasie testów dokonałem następujących obserwacji:
- gdy współczynnik regulatora jest za wysoki (~10), dron zaczyna się wychylać ze zwiększającą się amplitudą (dość szybko zwiększającą się amplitudą) aż do kompletej utraty kontroli.
- gdy współczynnik jest w rozsądnych granicach (ok 1) dron nie zwiększa amplitudy wychyleń, ale dość wyraźnie "pływa" - czyli zgodnie z literaturą objaw zbyt niskiego współczynnika regulatora.
- podnosząc współczynnik regulatora zaczynam on reagować coraz sprawniej i sprawniej, ale za to ryzyko przekroczenia "krytycznego" wychylenia wzrasta - po którym dron wpada w cykl powiększających się wychyleń opisanych w punkcie pierwszym.

Czyli
1) z zachowania się drona wynika, że współczynniki w okolicach 1 są za niskie, aby prawidłowo ustabilizować lot (generalnie trzyma się on dość stabilnie, ale zdarza się mu dłuższy zwis w pozycji wychylonej, co zaowocowało by jego dość szybkim oddaleniem się ode mnie, co jest dodatkowym problemem ze względu na łączność BT, która mnie obowiązuje).
2) współczynniki >5 to już prawie pewność że się zacznie w którymś momencie rozhuśtywać. Tutaj położyłbym to na karb opóźnienia między komórką a arduino - zanim arduino faktycznie zmieni moc silników, smartfon naładuje jeszcze do nich nadprogramowej mocy, co powoduje szybkie wychylenie w drugą stronę, na które smartfon też reaguje z opóźnieniem.

Hmm... czy ktoś widzi luki w tym doświadczeniu? Jeśli nie, to obawiam się że trzeba odtrąbić klęskę i kupować scalaka z żyroskopem i akcelerometrem...

A może wina leży po stronie PWM Adafruit? Tu jest opis jak to robią w MultiWii: https://code.google.com/p/multiwii/wiki/PWM_Generation Przejrzałem pobieżnie bez wgryzania się.

Zawsze jest opcja, że ten mój sterownik PWM powoduje opóźnienia, fakt, generalnie mam dużo miejsc gdzie mogę powstawać, pełny łańcuch komunikacji wygląda tak:
smartfon z FC -> nadajnik BT smartfona -> odbiornik BT arduino -> port UART odbiornika BT -> port UART arduino -> szyna I2C arduino -> odbiornik I2C steronika PWM -> reakcja silnika.

Na każdym etapie mogą powstawać opóźnienia, ale w tej chwili BT wydaje mi się głównym kandydatem (intuicja mi tak podpowiada). W sensie nie mam podstaw do nie ufania sterownikowi PWM, zwłaszcza że nie znalazłem w necie sytuacji, żeby ktoś się na niego skarżył. Spróbuję sprawdzić jak szybko po przekazaniu mu nowej wartości PWM jest on faktycznie zapisywana w jego rejestrach, ale naprawdę jestem głęboko przekonany, że po prostu na którymś UARTcie jednak za wolno czyta komunikaty i się kolejkują co powoduje opóźnienie, albo w ogóle Android z jakiejś przyczyny odczekuje chwilę przed wysłaniem kolejnej paczki bajtów.

Buuu, moja silna wola nie jest aż taka silna. W drodze jest płytka z akcelerometrem i żyroskopem pod arduino. Poddaję się z tym bluetooth

To może Wifik?

Wiesz, tak ogólnie powiedziałem bluetooth , ale należało by raczej powiedzieć smartphone. Generalnie porobiłem jeszcze kilka testów, między innymi test szybkości transmisji. Chodziło o to jak szybko komórka wemituje 20 tys sygnałów sterujących, co przy częstotliwości przeliczania mocy ok 400hz i 4 silnikach powinno trwać poniżej 20 sekund. Chciałem tak naprawdę zobaczyć po jakim czasie arduino zarejestruje te 20 tys sygnałów i zobaczyć jakie jest średnie opóźnienie. Przy okazji wyszło, że komórka generuje te sygnały przez 100 sekund a nie 20. Czyli to znaczy, że transmisja przebiega 5 razy wolniej niż wymaga tego docelowa praca drona. I jako że arduino zareagowało natychmiast po zakończeniu transmisji, wnioskuję że opóźnienie generuje albo moduł bluetooth albo sam android. Jaka opcja by się tu nie sprawdziła, oznacza to walkę po stronie smartfona. Jednak ostatecznym celem dla mnie nie jest zaznajomienie się z androidem, ale polatanie dronem, więc dodając do tego moje lenistwo i brak pewności czy cokolwiek uwalczę - zamówiłem czujnioi położenia i będę portował mój algorytm sabilizujące z androida na arduino

Hej Joorva,
Jakoś ucichło, co tam kolego z twoim projektem ?
Jak posuwają się prace ?
Czy może odpuściłeś uznając, że szkoda czasu na odkrywanie dawno odkrytego ?

Komercyjne zastosowanie, pełne sterowanie z telefonu/tabletu + wirtualna rzeczywistość.



Czyli da się

Heja,

Ucichło bo mi się trochę zadań nagromadziło, nie mam czasu dłubać. Statu jest taki, że mam dolutowany akcelerometr z gyro i poprawione oprogramowanie, żeby wszystko liczyło arduino. Dalej chcę drania skończyć, ale nie mam czasu, żeby poprawić soft w telefonie, żeby za aparaturę robił.

Czyli na razie on-hold, dopóki trochę czasu nie wygospodaruję :/ Dla mnie jest i tak istotne, żeby poleciał, zrobienie takiego drona po swojemu jest dla mnie właściwie platformą bazową do dalszych, dużo bardziej ambitnych zabaw. Ale na razie sza!, zróbmy pierwszy krok prawidłowo.

@Ellipsis - fajne to i ciekawe, ale na filmiku sama grafika, nic z realnych zdjęć - pytanie czy to w ogóle działa niemniej fajnie, że ktoś tkie coś zrobił komercyjnie - dowód, że jednak się da.

Jak tylko pozbieram się do kupy i poskładam wszystkie elementy zabawki, tak żeby razem gadały, to coś na pewno napiszę