Strojenie PID quadkoptera

Kontynuując pytanie, które tu zadałem : niestabilność quadkoptera z prostym startem w trybie autonomicznym ... Chciałbym zadać kilka pytań na temat implementacji podstawowego PID dla quadrotora kontrolowanego przez moduł APM 2.6. (Używam ramki z 3DRobotics)

Rozebrałem cały system sterowania do zaledwie dwóch bloków PID, jednego do kontrolowania przechyłu, a drugiego do kontrolowania skoku (odchylenie i wszystko inne ... Pomyślę o nich później).

Testuję ten zestaw na platformie, która składa się z swobodnie obracającej się belki, w której związałem dwa ramiona quadrotora. Pozostałe dwie mogą się poruszać. Tak naprawdę testuję jeden stopień swobody (przechylenie lub skok) na raz.

Sprawdź obraz poniżej: tutaj A, B oznacza swobodnie obracającą się belkę, na której zamontowany jest zestaw. wprowadź opis zdjęcia tutaj

Dzięki starannemu dostrojeniu parametrów P i D udało mi się osiągnąć ciągły lot około 30 sekund.

Ale przez „przedłużony” rozumiem po prostu test, w którym dron nie przewraca się na bok. Ciągły lot na skale wciąż nie jest w zasięgu wzroku, a ponad 30 sekund lotu również wygląda dość trudnie. Kołysze się od samego początku. Gdy osiągnie 20-25 sekund, zaczyna przechylać się na bok. W ciągu 30 sekund przechylił się na bok o niedopuszczalny margines. Wkrótce widzę, że spoczywa do góry nogami

Jeśli chodzi o sam kod PID, obliczam błąd proporcjonalności na podstawie „filtra uzupełniającego” danych żyroskopu + akcelerometru. Całka jest ustawiona na zero. Wartość P wynosi około 0,39, a wartość D wynosi 0,0012. (Nie używam specjalnie biblioteki PID Arduino, chcę tylko zaimplementować tutaj jeden z moich PID).

Sprawdź ten film, jeśli chcesz zobaczyć, jak to działa.

http://www.youtube.com/watch?v=LpsNBL8ydBA&feature=youtu.be [Ta konfiguracja jest dość stara! Zgadzam się. :)]

Daj mi znać, co mogę zrobić, aby poprawić stabilność na tym etapie.

@Ian: Z wielu testów, które wykonałem z moją konfiguracją, sporządziłem wykresy dla niektórych testów, używając odczytu z monitora szeregowego. Oto przykładowy odczyt Roll vs „Motor1 i Motor2 - wejście PWM” (dwa silniki kontrolujące przechylenie):

Wejście Roll vs Motor PWM

Jeśli chodzi o wejście / wyjście:

Dane wejściowe: wartości przechyłu i nachylenia (w stopniach) uzyskane za pomocą kombinacji akcelerometru + żyroskopu

Dane wyjściowe: wartości PWM dla silników dostarczone za pomocą funkcji motor.write () z biblioteki Servo

Rozkład

Rozwiązałem problem. Oto jak:

Sedno problemu leżało w sposobie, w jaki wdrożyłem program Arduino. Używałem funkcji write () do aktualizacji kątów serwomechanizmu, który akceptuje tylko argumenty liczb całkowitych w argumencie (lub w jakiś sposób reaguje tylko na dane liczbowe całkowite, 100 i 100,2 daje ten sam wynik). Zmieniłem to na writeMicroseconds () i dzięki temu copter był znacznie stabilniejszy.
Zsumowałem RPM na jednym silniku, utrzymując drugi na stałym poziomie. Zmieniłem to, aby zwiększyć RPM w jednym silniku, jednocześnie zmniejszając silnik przeciwny. Ten rodzaj utrzymuje niezmienny całkowity ciąg poziomy, co może mi pomóc, gdy próbuję utrzymać tę wysokość w pionie.
Podnosiłem obroty do maksymalnego limitu, dlatego quadcopter wciąż tracił kontrolę przy pełnym otwarciu przepustnicy. Nie było miejsca na zwiększenie RPM, gdy wyczuł on przechylenie.
Zauważyłem, że jeden z silników był z natury słabszy od drugiego, nie wiem dlaczego. Na stałe wpisałem przesunięcie w tym silniku na wejściu PWM.

Dziękuję za całe wsparcie.

Kod źródłowy:

Jeśli jesteś zainteresowany, oto kod źródłowy mojej prostej implementacji PID : Kod źródłowy PID

Przetestuj go na swoim sprzęcie. Wszelkie wkłady w projekt byłyby mile widziane.

— Metsburg
źródło

Co to jest wejście i wyjście pętli?

— Guy Sirton,

@GuySirton: Zaktualizowałem moje pytanie

— metsburg

Jakie są te płaskie sekcje w poleceniach silnika? Wygląda na to, że coś nasiąka. Rzutujesz zmiany jak funkcja ciągła, ale twoje polecenia wyglądają bardzo gwałtownie. Również dlaczego oba polecenia PWM silnika dryfują w górę, podczas gdy wejście przechyłu pozostaje w czymś, co wygląda na ten sam zakres? Przy okazji, jaka jest przybliżona skala czasu?

— Guy Sirton,

Powód, dla którego tracisz kontrolę po 30 sekundach, jest prawdopodobnie związany z przyspieszeniem obu poleceń. Wydaje mi się, że próbujesz kontrolować różnicę między poleceniami, ale nie możesz pozwolić, aby te nadal dryfowały w górę.

— Guy Sirton,

@GuySirton: Nie dryfują w górę, zwiększam je w górę od zera, aby osiągnęło szczególny stały stan w ciągu 3/4 sekundy. Myślę jednak, że masz rację, mówiąc „powód utraty kontroli po 30 sekundach jest prawdopodobnie związany z szybszym wzrostem obu poleceń”. Jeśli nie użyję tego stopniowego przyrostu, jeśli naprawię wejście PWM na pewnym poziomie (niższym niż maksymalne wejście pokazane powyżej), problem utraty kontroli po 30 sekundach zniknie.

— metsburg

Odpowiedzi:

Wygląda na to, że twój proporcjonalny zysk jest zbyt wysoki.
Wydaje się, że ciągle zwiększasz obroty na jednym silniku, a jednocześnie blokujesz w drugim, aby system obracał się. To nie jest dobra strategia kontroli, ponieważ ostatecznie będą one nasycone i stracisz kontrolę. Również wraz ze wzrostem czasu zmniejsza się zdolność dowodzenia systemem. Potrzebujesz więc lepszego modelu systemu.
Jeśli masz do czynienia z numerem 1 i 2, będziesz mieć bardziej stabilny system, ale możesz nie być zadowolony z przepustowości kontroli. Aby sobie z tym poradzić, należy usztywnić system, co obejmuje pozbycie się opóźnień po stronie czujnika i po stronie sterowania.

— Guy Sirton
źródło

Zacznę od przeczytania tego pytania: Jakie są dobre strategie dostrajania pętli PID?

Gdybym musiał zgadywać, powiedziałbym, że masz problem ze sposobem, w jaki tworzony jest bezpłatny filtr. Przy wyłączonych silnikach quadkoptera należy przechylić ramkę do przodu i do tyłu i sprawdzić, czy zgłaszane wartości przechyłu / nachylenia są rzeczywiście dokładne.

Dla mnie wygląda na to, że istnieje opóźnienie między wejściem z akcelerometru a wyjściem filtra - oscylację można wyjaśnić późnymi reakcjami na dane wejściowe. Ostateczne przewrócenie wygląda jak możliwy błąd integracji, który narasta w czasie - innymi słowy, gdy quadcopter jest na boku, faktycznie myśli, że unosi się poziomo.

(Aktualizacja) Jeśli chodzi o wykres, fakt, że prędkości silnika nadal rosną (zamiast utrzymywać równowagę), oznacza, że gdzieś wystąpił błąd. Być może twój termin Integralny staje się nieograniczony i powinieneś podać rozsądne maksimum.

— Ian
źródło

Podczas przechylania do przodu i do tyłu zaktualizowałem swoje pytanie o wartości rzutu. Rozwiązałem ewentualne przewrócenie, obniżając maksymalne wejście PWM. Wygląda na to, że wartości korekcji nie działają przy bardzo wysokich obrotach. Podczas pracy przy wysokich obrotach mogę łatwo obrócić zestaw ręką. Przy niższych obrotach czuję znaczny opór, a quadkopter wydaje się oscylować z powrotem do swojej pierwotnej pozycji (co, jak sądzę, jest dobre). Tak więc problem „przewrócenia się” prawdopodobnie został rozwiązany przez obniżenie prędkości obrotowej (nie wiem, czy dron w ogóle wystartuje, czy nie, mam nadzieję, że tak się stanie). Problem oscylacji wciąż pozostaje.

— metsburg

- 3^{\circ}

$-3^{\circ}$

- 5^{\circ}

$-5^{\circ}$

\pm 90^{\circ}

$\pm90^{\circ}$

Cóż, wykres nie jest dokładnie dla testu pokazanego na filmie. Jak wspomniano powyżej, wykres pochodzi z jednego z wielu testów, które przeprowadziłem z tą konfiguracją i nie pamiętam dokładnie, jak wyglądał ten konkretny przypadek. Wykres ma tylko dać ci wyobrażenie o tym, jak zachowuje się odpowiedź wejściowa a wyjściowa, a także chciałem ustalić, że nie ma dużego opóźnienia między wejściem a wyjściem (biorąc pod uwagę, że pętla działa przy częstotliwości 150+ Hz). Dopasowywanie wideo do wykresu może nie mieć większego sensu. W filmie nie mam dokładnego zestawu danych do testu.

— metsburg

Uświadomiłem sobie, że wykres jest trochę mylący, przepraszam za to. Spróbuję zaktualizować wykres o bardziej dokładny. W rzeczywistości, odkąd rysowałem dane z portu szeregowego, kiedy tworzyłem ten wykres, tablica Arduino była przywiązana do laptopa. Po pewnym oscylacji musiałem interweniować i ręcznie spowolnić oscylację. Dlatego widzisz, że osiada na poziomie - 5 stopni, podczas gdy w rzeczywistości wynosi około 90 stopni. Spróbuję zaktualizować dokładniejszy wykres później.

— metsburg

Kolejną rzeczą, którą widzę z wykresu, jest to, że twój łączny ciąg zawsze rośnie. To wydaje się złe.

— Ian

Cóż, może się tu zdarzyć wiele rzeczy ...

1) Czy podane przez ciebie kąty są prawidłowe? głośny? Możesz to łatwo sprawdzić, ręcznie przechylając quad i monitorując wychodzące wartości.

2) Twoja własna implementacja PID ma błąd. Za pomocą zaufanej implementacji możesz sprawdzić swój kod.

3) Podpory, silniki zamontowane w niewłaściwy sposób.

4) ...

— dm76
źródło

1) Przechyliłem i sprawdziłem zgłoszone kąty, prawie poprawne, ale zdecydowanie głośne. 2) bardzo prawdopodobne ... w rzeczywistości myślę, że to w pełni podsumowuje: P 3) mało prawdopodobne, dwa zgodnie z ruchem wskazówek zegara, dwa przeciwnie do ruchu wskazówek zegara ... Sprawdziłem rekwizyty wiele razy + Myślę, że ten rodzaj błędu spowodowały dzikie błędy, daleko poza kontrolą. 4) ....

— metsburg

4) ... niewłaściwe strojenie PID może sprawić, że będzie gorzej niż wtedy, gdy w ogóle nie masz PID!

— dm76

Tak, teraz to widzę. Jutro nad tym popracuję. Mój pierwszy plan polega na użyciu zaufanej biblioteki PID, a drugi to zmiana mocy wyjściowej PID z sygnałów PWM na korektę roll.pitch.

— metsburg