Sprawić, żeby robot zaczął jeździć

Trzy miesiące konkursu „Daj się poznać” już praktycznie minęły i o ile jestem zadowolony z treści, które pojawiły się na blogu, to prace nad rozwojem robota są w szczerym polu. Od początku wiedziałem, że realizacja całego projektu potrwa dłużej niż konkursowe trzy miesiące, ale liczyłem, że będę już trochę dalej. Uświadomiłem to sobie w poniedziałek i wtedy też postanowiłem podjąć się wyzwania – do końca maja (czyli w 3 dni) miałem sprawić, żeby robot zaczął jeździć. Z tego powodu w ostatnich dniach solidnie popracowałem nad projektem. Tym bardziej, że przed trzema dniami wyzwania miałem jeszcze owocny weekend z OctoPrint i drukarką 3D. Na zdjęciu puszczony na telewizorze kolejny odcinek serialu „Bootowanie Raspberry Pi”.

Implementacja sterowania

Założyłem sobie, że na koniec maja zrobię odczytywanie komend wysyłanych przez Bluetooth i sterowanie silnikami na ich podstawie. Poza tym musiałem skończyć część mechaniczną, czyli zamontować zębatkę na wał silnika i sprawić, żeby wprawiała ona w ruch zębatki położone na felgach. Część softwareowa poszła bardzo sprawnie. Szybko napisałem sterownik UART odbierający pojedyncze bajty. Na razie UART nie ma opcji nadajnika, samo odbieranie. Na bazie tego odbiornika działa task konsoli debugowej, który przyjmuje komendy wysyłane z terminala. Sterowanie przód – tył – lewo – prawo jest realizowane WSADem. Zatrzymanie silników za pomocą spacji. Można również podać na silniki jedną z trzech prędkości za pomocą klawiszy 1, 2, 3. Na tą chwilę taka konsola jest wystarczająca. Istniejący mechanizm w razie potrzeby będzie można rozbudowywać w wielopoziomowe menu z takimi funkcjami jak np. printowanie mapy labiryntu, pokazywanie wyznaczonej ścieżki czy oszacowania własnej pozycji. Aktualne źródła można znaleźć na GitHubie.

Drukowanie elementów mechanicznych

W weekend udało mi się postawić OctoPrint na Raspberry Pi, skalibrować drukarkę i poeksperymentować z drukowaniem części. Na ten temat na pewno pojawi się jeszcze osobny wpis. Od kiedy postawiłem OctoPrint w sobotę, drukarka chodzi praktycznie non stop. Najpierw wykonałem kompletną kalibrację, czyli kalibrację położenia głowicy, spadków na rogach przestrzeni roboczej i luzów na przekładniach. Zmarnowałem na to solidną dawkę filamentu.

Gdy drukarka była już dobrze skalibrowana, zabrałem się za drukowanie części do felg. Wyniki były dużo lepsze niż przy poprzednich próbach z domyślnym softem, jednak nadal nie jest idealnie.  Zrobiłem również zmiany w modelach 3D uwzględniające mniejszą dokładność drukowania – dodałem większe zapasy. Efektem są nowe felgi ze skróconą nakładką zapewniającą lepsze stykanie się zębatki na wale silnika z zębatką felgi.

Kolejnym etapem było wydrukowanie zębatki na wał silnika z otworem na śrubę mocującą. Pierwsze próby nie wyszły zbyt dobrze. Otwór na wał trzeba było powiększyć w modelu, bo wał się nie mieścił. Problemem było zniekształcenie powodowane przez otwór na śrubę mocującą. Później zamiast zwiększać otwór w modelu zacząłem rozwiercać go w wydrukowanej części. Początkowo wydruki nie wyglądały zbyt obiecująco. Zęby nie były dokładnie wydrukowane, otwór na śrubę się deformował. W końcu postanowiłem powiększyć część elementu nie posiadającą zębatki. Po tej zmianie elementy wychodziły dużo lepiej. Jednak testy z wałem pokazały, że taka zębatka nie wprawia koła w ruch. Dodałem więc drugą śrubę mocującą, jednak to nie pomogło. W końcu postanowiłem zarzucić pomysł drukowania nowej zębatki na wał i zamiast tego wrócić do wcześniejszego pomysłu, czyli przyklejenia metalowej zębatki na Super Glue.

Zamocowanie zębatki na wale

Podczas próby umieszczenia przekładni na wale musiałem rozklejać elementy po nieudanej próbie. Okazuje się, że po wymoczeniu w acetonie Super Glue puszcza. To dobrze, bo dzięki temu zamocowanie przekładni nie będzie pernamentne. Po testach z metalową przekładnią również okazało się, że felga się nie kręci. Felga jest blokowana przez śrubę będącą osią obrotu. Wiertarką powiększyłem otwory w feldze, ale to nic nie dało. Prawdopodobnie łożyska, które są wepchnięte na styk, nie są idealnie współśrodkowe i powodują opór obracania się śruby. Aby przetestować tę hiptezę muszę wydrukować nowe felgi z większym zapasem miejsca na łożysko. Niestety oznacza to, że nie udało mi się zrealizować postawionego celu – na koniec DSP robot nie będzie jeździł.

Podsumowanie

Tak więc trzydniowe wyzwanie mające na celu stworzenie jeżdżącego robota nie powiodło się. Powodem były problemy z konstrukcją mechaniczną. Nie pozostaje mi nic innego, jak tylko kontynuować pracę nad robotem. Następna wersja felg już się drukuje – zobaczymy czy będzie poprawa. Konkurs DSP się kończy, ale prace nad robotem Micromouse nie. Tak naprawdę dopiero przy działającej mechanice będę mógł pochylić się nad naprawdę ciekawymi tematami takimi jak regulatory silników, estymacja pozycji, czy wykrywanie ścian.

 

1 Comment

  1. Gratulacje! Udało się nam, było ciężko ale dotrwaliśmy 😉

Dodaj komentarz

Your email address will not be published.

*

© 2017 ucgosu.pl

Theme by Anders NorénUp ↑