Dawno nic nie było o postępach w pracach nad Micromousem, więc pora na mały update. Od ostatniego wpisu o regulatorze obrotów z sierpnia udało się zrobić parę rzeczy. Udało się również parę rzeczy zepsuć. Projekt posunął się do przodu na różnych frontach, ale postępy przystopowało trochę spalenie płytki.

Regulator ruchu postępowego

Jakiś czas temu opisałem jak zaprojektować regulator obrotów silnika (link). Zaprojektowany w ten sposób regulator został zaimplementowany i uruchomiony. Oczywiście teoretyczne nastawy są jedynie punktem wyjścia do dalszych testów. Na Githubie na gałęzi dev można znaleźć build testu hw motor_linear (link), który posłużył mi do testowania nastaw. Ostatecznie zrezygnowałem z członu całkującego, wykonałem od nowa obliczenia teoretyczne dla samego PD i dostroiłem nastawy po testach na rzeczywistym obiekcie. Z rezultatów byłem nawet zadowolony – robot jechał w miarę prosto i trzymał na silnikach zadaną prędkość.

Regulator ruchu obrotowego

Po uporaniu się z jazdą prosto przyszła kolej na skręty. W założeniu regulator ruchu obrotowego miał opierać się na pomiarach prędkości kątowej z żyroskopu. Okazało się jednak, że nie mam zaimplementowanej obsługi czujnika IMU. Pierwszym krokiem było więc umożliwienie odczytu danych z czujnika. W tym celu należało napisać driver I2C Master do komunikacji z czujnikiem oraz task IMU wysyłający odpowiednie komendy i adresy rejestrów oraz poprawnie interpretujący otrzymane dane. W tym celu powstał kolejny program testowy – imu (link). Odczytuje on dane z akcelerometru i żyroskopu – magnetometr na razie nie jest aktywowany – i wysyła je przez UART.

Następnie przystąpiłem do identyfikacji układu dla ruchu obrotowego dokonując modyfikacji w programie testowym motor_ident (link). Aktualnie za pomocą odpowiednich define można zmieniać prędkość bazową oraz offset, który do jednego silnika jest dodawany, a od drugiego odejmowany. W ten sposób robot zaczyna się obracać.

Podczas uruchamiania tego programu natrafiłem na ciekawy błąd. Otóż taskIMU poprawnie odczytywał wartości z czujnika jedynie kiedy układ był podłączony do debugu na biurku z zasilaczem laboratoryjnym. Jeśli robot robił powerup z baterii i uruchamiał wgrany wcześniej program, komunikacja z czujnikiem nie działała. Okazało się, że przyczyną jest zbyt szybka próba inicjalizacji czujnika zanim zdąży on wstać po włączeniu zasilania. Aby pozbyć się tego problemu wystarczyło w tasku czujnika dodać początkowy delay.

Niestety prac nad regulatorem sterującym skrętami robota nie udało się dokończyć. Podczas wgrywania programu testowego zrobiłem zwarcie i spaliłem płytkę. Zwarte są linie 5V i 3,3V. Nie pomogło wylutowanie stabilizatora, ani mostka H. Potrzebna jest nowa płytka.

Naprawienie failującego builda Travis-CI

Z Travis-CI stoczyłem już długą walkę w kwietniu i w końcu udało mi się tak wszystko skonfigurować, żeby build przechodził. Kompilowałem bleeding-edge-toolchain ze źródeł i wkońcu udało mi się zmieścić w limicie czasu Travisa. Niestety zcache’owane binarki są przechowywane przez Travisa dosyć krótko, a składniki toolchaina są często aktualizowane i od jakiegoś czasu kompilacja ze źródeł znowu nie chodziła. Na gcc7 trwa to dłużej niż wcześniej i w końcu zdecydowałem się na ściąganie skompilowanej binarki gcc5. Na moje potrzeby jest to wystarczające.

Poprawienie mocowań kół

Udało się również poprawić nieco mechanikę. Mocowania kół na śrubę posiadały dosyć spore luzy. Koła trochę latały powodując różnicę w zachowaniu dla obu stron. Użyłem więc większej ilości kleju do gwintów i teraz cała konstrukcja jest dużo bardziej stabilna. Niestety teraz z jednej strony koła są zbyt blisko zębatki i w pewnym momencie występuje zwiększony opór przy obrocie kół, przez który koła się często blokują. Poza tym okazuje się, że przy takiej samej prędkości podanej na oba silniki ta strona zawsze kręci się wolniej. Tak więc udało się poprawić jeden problem i od razu pojawił się kolejny. Mam zamiar zminimalizować ten efekt za pomocą softu. Regulatory dla obu kół będą miały inną charakterystykę, a regulator dla ruchu obrotowego zrobię z uwzględnieniem tej różnicy.

Lutowanie nowej płytki

Na szczęście miałem na stanie wszystkie potrzebne elementy, aby zlutować nową płytkę w miejsce tej spalonej. Na razie nie lutowałem elementów odpowiedzialnych za wykrywanie ścian. Robiłem testy z silnikami na nowej płytce i faktycznie jedna kręci się szybciej dla tej samej mocy silników.

Dalsze plany

Jak widać prace może nie idą w zatrważającym tempie, ale jakoś posuwają się do przodu. W najbliższym czasie skupię się na dopracowaniu regulatorów silników dla ruchu postępowego i obrotowego tak, aby niwelowały wpływ różnic w zachowaniu obu stron. Kiedy będę miał gotową regulację i odczyt aktualnej prędkości i kąta, będę mógł wziąć się za estymację pozycji oraz wykrywanie ścian.