Po wyeliminowaniu błędów w PID opisanych w poprzednim artykule, mogłem przejść do kolejnych poprawek w module silników. Moją uwagę przykuł regulator prędkości kątowej. Postanowiłem wprowadzić w nim zmiany, aby zwiększyć precyzję obrotu robota i zwiększyć jego stabilność. Do tej pory zdarzało mi się, iż robot się wzbudzał i stojąc w miejscu wykonywał czasem niewielkie skręty.
Wybór mierzonego sygnału
Dotychczasowy regulator prędkości obrotowej bazował na odczytach z żyroskopu. Jego dryft sprawiał, iż gdy robot stał w miejscu, była odczytywana prędkość kątowa. Przez to uniemożliwiał bazowanie na bezpośredniej wartości. Można odczytywać wartość czujnika przy inicjalizacji i potem jej używać jako dryft, albo zahardkodować jakąś wartość. Nie podobały mi się te rozwiązania. Dryft może się zmienić w czasie, możemy odczytać początkową wartość, kiedy robot jest w ruchu, zahardkodowana wartość może się mocno rozjeżdżać z rzeczywistością. Może do pierwszego prototypu to by jeszcze przeszło, ale na pewno nie chciałem czegoś takiego używać jako docelowe rozwiązanie.
Tak się jednak składa, iż mam już gdzie indziej wyliczaną prędkość kątową. Filtr Kalmana estymuje prędkość i dryft, używa do tego żyroskopu i enkoderów. Jednak takie rozwiązanie też ma wady. Po pierwsze regulator silnika potrzebuje wtedy działającego Kalmana, który wymaga skomplikowanych obliczeń i nie jest prosty do nastrojenia. Aktualnie mam jakieś nastrojone wartości, ale musiałbym zrobić dodatkowe testy, czy na pewno dryft jest dobrze rozpoznawany zarówno gdy robot stoi, jak i jedzie. Poza tym każda zmiana będzie wymagała ponownego strojenia tworząc deadlocka. Do nastrojenia Kalmana potrzebuję działających silników, do działania silników potrzebuję nastrojonego Kalmana. Być może sprawdziłby się drugi prostszy Kalman tylko do kąta. Jednak dublowałby on funkcjonalność. Więc to rozwiązanie również odrzuciłem.
Ostatecznie wymyśliłem, iż najlepiej sprawdzi się najprostsze rozwiązanie. Do regulatora silnika chcę użyć jedynie odczytów z enkoderów. Dzięki temu otrzymam szybki feedback z minimalną ilością obliczeń. Enkoderów i tak już używam do regulatora ruchu postępowego, więc nie ma żadnych dodatkowych zależności. Największą wadą enkoderów jest błąd pozycji kumulujący się w czasie. Tutaj będą wykorzystywane tylko do określania chwilowej prędkości, a z tym zadaniem poradzą sobie dobrze.
Obliczanie kąta obrotu
Przenalizujmy teraz jak obliczyć kąt obrotu z odczytów enkoderów. Posłużymy się w tym celu niezwykle profesjonalnym rysunkiem w paincie. Robot posiada pewną szerokość d i wykonuje obrót o pewien kąt 
Długości łuków dla poszczególnych kół można wyznaczyć z wzorów:
Jeżeli odejmiemy od siebie te wartości, otrzymamy:
Czyli różnica odległości przebytych przez poszczególne koła jest wprost proporcjonalna do pokonanego kąta. Tak więc wystarczy odjąć od siebie odczyty z obu enkoderów i podać je do algorytmu PID. Jedyną trudnością będzie wtedy określenie wartości zadanej. Chcielibyśmy zadawać prędkość kątową w stopniach na sekundę, a aktualnie operujemy w tickach enkodera na czas próbkowania. W tym celu musimy posłużyć się wzorem:
Gdzie dt to czas próbkowania, a k to przelicznik z milimetrów na ticki enkodera. W moim wypadku wynosi on:
Pewnym problemem może być tutaj rozdzielczość, ponieważ zgodnie z powyższymi wzorami kąt 
Pierwsze testy
Po wprowadzeniu opisanych poprzednio zmian w samym algorytmie PID oraz zmianie na odczyty z enkodera choćby bez specjalnego strojenia widać, iż regulator działa dokładniej, ma mniejsze zakłócenia i nie traci stabilności. Wcześniej stabilność była problemem szczególnie z członem I. Symulacje wykazały, iż regulator PD ma spory uchyb ustalony, więc niezbędne będzie dodanie członu całkującego. Człon różniczkujący kilka wnosi, więc ostatecznie będzie to pewnie regulator PI.
