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ę