Freestyle Zbignaś Kopłapow - następny z rodu

[ethanak]

No wreszcie - po jakimś szale na prezenty, naprawy różnych domowych urządzeń i inne przyziemne sprawy mogłem zabrać się za następnego z rodziny Konserwatorów Płaskich Powierzchni - czyli małego Kopłapowa. Miał on w założeniu służyć do wycierania podłogo w trudniej dostępnych miejscach (np. pod kabiną prysznicową) więc siłą rzeczy musiał byc jak najmniejszy. Założenia były proste:

• zasilanie 1 x 18650;
• dwa silniczki N20 do napędu z driverem DRV8825;
• z przodu pojedyncza gąbka kuchenna;
• wysokość taka, aby się zmieścił pod brodzikiem;
• z czujników: zderzak, żyroskop i kilka czujników odbiciowych;
• Arduino Pro Mini jako "mózg" urządzenia;
• żadnego skomplikowanego algorytmu - ma się przejechać po podłodze i tyle, z możliwością zdalnego sterowania.

Z takimi założeniami zabrałem się do roboty.

Sterownik już miałem - kiedyś zrobiłem sobie coś w rodzaju uniwersalnego nadajnika, sprawdził się już w trzech konstrukcjach a więc tę część miałem gotową.

Tym razem postanowiłem w maksymalnym stopniu wykorzystać drukarkę. Ponieważ miałem felgi z kół Pololu (opony zostały użyte w innym projekcie) wystarczyło dodrukować jakieś ładne oponki z TPU. Również dolna płyta podwozia wraz z koszykiem na 18650 oraz mocowaniami na ładowarkę, przetwornicę i inne drobiazgi typu wyłącznik została wydrukowana w jednym kawałku.

Zadowolony z siebie zmontowałem podwozie, podłączyłem prowizorycznie silniczki pod 5V... i w tym momencie szczęście się skończyło. Okazało się, że robot nawet po lekkim dociążeniu jest jeszcze za lekki i nie da rady przepchnąć gąbki nawet po śliskich kafelkach. Zmartwiony odstawiłem konstrukcję na skraj biurka i zająłem się swoimi sprawami.

Na szczęście był to skraj biurka przy którym pracuję i co chwila chcąc nie chcąc spoglądałem na biednego robocika. Jak go wykorzystać... Pomysł przyszedł sam, gdy nastąpiłem bosą nogą na jakąś śrubkę. A gdyby tak wyposażyć go w magnes i kazać zbierać śrubki z podłogi?
Wywaliłem uchwyt gąbki, w to miejsce zamontowałem obrotowe kółko (o nim więcej w dalszej części), uchwyt na magnesy i również podłączając bezpośrednio do przetwornicy silniczki puściłem go po podłodze. Okazało się, że śrubki i podobne niewielkie metalowe farfocle zbiera doskonale! Tak więc robocik zmienił swoje przeznaczenie, miałem już gotowe podwozie i mogłem zabrać się za dalsze projektowanie.

Oczywiście - potrzebne były nowe założenia. Przede wszystkim - wysokość nie była już krytyczna (robot miał zbierać śrubki porozrzucane po podłodze i nie wjeżdżać do łazienki). Z uwagi na to zrezygnowałem z czujników odbiciowych, w ich miejsce postanowiłem zamontować obrotowy laserowy czujnik TOF o kącie 180°. Pozostał oczywiście żyroskop. Z uwagi na przykre doświadczenia z MPU6050 przy okazji zakupów w Botlandzie zamówiłem moduł L3G, czujnik VL53L0X kupiłem już wcześniej, tak więc zabrałem się za dalsze projektowanie.

I tu mała dygresja: odrzuciłem MPU6050 z uwagi na to, że potrafił zawiesić Arduino po kilkudziesięciu sekundach od włączenia (a z tego co wyczytałem w sieci nie tylko ja miałem z tym problemy). Oczywiście: nie doczytałem, że dotyczy to wyłącznie odczytu danych z DMP, odczyt surowych danych z żyroskopu i akcelerometru był prawidłowy. Dopiero po zmontowniu całości przypadkiem natknąłem się na nową wersję biblioteki która (podobno) nie sprawia takich problemów... a szkoda, bo niepotrzebnie wydałem trzy dychy na nowy żyroskop 😞

Ale wróćmy do robocika. Ponieważ laser na serwie i tak musiał dość mocno wystawać nie było konieczności zachowania wysokości reszty konstrukcji. Postanowiłem zrobić więc coś podobnego jak w poprzednim robocie - podłoga ze spienionego PVC (idealna do eksperymentów z uwagi na łatwość obróbki), do niej mocowane serwo i płytka z elektroniką. Z tamtej konstrukcji skopiowałem również zawieszenie zderzaka i przekładnię do serwa obracającego laser. Płytka z elektroniką miała początkowo być wykonana na frezarce - niestety, wskutek pandemii zostałem odcięty od warsztatu kolegi i musiałem zadowolić się płytką uniwersalną.

Przyszedł więc czas na najprzyjemniejszą część pracy programowanie. Na zdjęciu wyżej widać przytwierdzony do robota najnowszy model SMARDZ-a. Tym razem SMARDZ ma własne zasilanie (akumulatorek Li-Ion 1000 mAh, ładowarka i przetwornica) co uniezależnia go od akumulatorów robota i - co ważniejsze - przy większych wstrząsach (np. uderzenie w przeszkodę) nie ma możliwości, że zrobi sobie reset. Większych niespodzianek nie miałem z wyjątkiem jednej - ale za to bardzo śmiesznej...

Otóż po zmontowaniu wszystkiego na płytce uniwersalnej jak zwykle przedzwoniłem wszystkie połączenia. Po stwierdzeniu że wszystko jest w porządku rozpocząłem testowanie. Wszystko działało - oprócz serwa.

Zdjąłem płytkę, wyjąłem Arduino, sprawdziłem połączenia - wszystko było w porządku. Ki diabeł? Zacząłem szukać w programie czy coś mi nie blokuje timera - nie, najprostszy program ruszający serwem z przykładów też nie chciał działać.

Co prawda serwo było sprawdzone (przed zamontowaniem musiałem ustawić środkowe położenie, a do tego używałem testera serw) - ale wiadomo, popsuć się mogło. Niestety - inny egzemplarz zachował się tak samo. Co ciekawsze - mały HD-1370A zaczął kręcić się w kółko... Nie bardzo mi się chciało podpinać sondę, ale jakoś chęć zbadania przyczyny owego dziwacznego działania przeważyła nad lenistwem. No i co się okazało? Otóż na nóżce 8 do której podłączone było serwo radośnie trwało 5V. Wtedy sobie przypomniałem, że płytkę Arduino wziąłem z pudełka gdzie leżą wszystkie podejrzane moduły (jako że miał wszystkie piny polutowane) - po prostu wyjście 8 było najprawdopodobniej uszkodzone i zwarte na stałe z Vcc 🙂 Na szczęście połączenia robione Kynarem mają to do siebie że szybko można je zmodyfikować - podłączenie serwa do wolnego pinu obok pomogło!

Ech, znowu się okazało, że elementy sprawne działają z reguły lepiej od uszkodzonych!

I jeszcze drobiazg - w pewnym momencie jeden z silniczków uległ uszkodzeniu (mechanicznemu). Chciałem kupić dwa w Botlandzie na wypadek gdyby drugi też miał jakieś skłonności samobójcze - niestety, już nie było (tzn. był jeden ale trochę się bałem). Kupiłem więc podobne - działają chyba nawet lepiej.

W sumie mam na płytce:

• Arduino Pro Mini
• cztery mikroswitche zderzaków (połączone parami, czyli wykrywane jako dwa oddzielne) podpięte do jednego pinu analogowego
• moduł radiowy nRF24L01 (zasilany z wyjścia VDD żyroskopu)
• żyroskop L3GD20H
• driver DRV8835
• buzzer służący do wygrywania różnych krzepiących melodyjek związanych z wykonywaną funkcją
• wyjścia na silniki, serwo i diody WS2812 (wskaźnik wykonywanej funkcji oraz wskaźnik poziomu naładowania akumulatora).

Wszystko zasilane z jednego napięcia 5V z przetwornicy MT3608, do pinu analogowego podpięte wejście przetwornicy (kontrola napięcia akumulatora). O dziwo działa bez żadnych dodatkowych kondensatorów z wyjątkiem jednego 100nF przy module radiowym i dwóch przy silnikach.

W efekcie robot wygląda tak:

Tak więc robot w tej chwili potrafi realizować następujące programy:

1. Sterowanie zdalne (ot, wielki mi program). Jedyne co go różni od samochodzika wnuczka na bateryjkę to fakt, że używa żyroskopu do jazdy prosto (podobnie jak reszta programów).
2. Wałęsak - Bradiaga - najprostszy z możliwych - przejeżdża kawałek i skręca sobie w losowym kierunku. Po spotkaniu z przeszkodą po prostu cofa i zakręca.
3. Wałęsak - Moocher - taki włóczęga bardziej inteligentny. Używa lasera do stwierdzenia czy nie dojeżdża do przeszkody oraz do wyszukania najlepszej (w jego rozumieniu najdłuższej) trasy do dalszej jazdy po spotkaniu z przeszkodą lub gdy mu się zamami zmiana kierunku.
4. Odplamiacz - jedzie sobie po spirali. W przypadku napotkania na przeszkodę wykonuje wcześniej zaplanowany skręt, poprzedzając lekkim cofnięciem jeśli sygnał pochodzi od zderzaków a nie lasera.. Przerywa pracę, gdy nie może skręcić (tzn. w czasie skrętu dostanie sygnał od zderzaków).
5. Polowiec - obrabia prostokątny kawałek podłogi - przejeżdża kawałek, zawraca, znowu przejeżdża, zawraca... jakby orał pole. Również używa oprócz zderzaków lasera jako czujnika przeszkody. Ponieważ zawraca zawsze na zasadzie zastopowania jednego koła (wewnętrznego) przesuwa się nieco za każdym nawrotem. Podobnie jak Odplamiacz przerywa pracę, gdy nie może zawrócić.
6. Patrol - robot stara się ustawić jak najbliżej ściany równolegle do niej, a następnie jeździ od ściany do ściany aż do momentu, kiedy nie może zawrócić.

Kod jest w sumie bardzo prosty, jednak chciałbym zwrócić uwagę na dwie rzeczy:

Używam funkcji printf do wyświetlania różnych informacji o tym, co robi robot. Ponieważ wszystkie funkcję dotyczące żyroskopu działają na liczbach float, musiałem zmusić Arduino do wyświetlania ich właśnie przez printf. Niestety - nie ma możliwości ustawienia tego dla pojedynczego szkicu, ale globalne ustawienie jest bardzo proste: otóż w katalogu, gdzie znajduje się plik platform.txt dla naszego Arduino (czyli w tym przypadku ARDUINO_HOME/hardware/arduino/avr) trzeba założyć nowy plik o nazwie platform.local.txt, a w nim umieścić skopiowaną z platform.txt linię rozpoczynającą się od ciągu "recipe.c.combine.pattern=" z jedną drobną modyfikacją: na końcu linii należy (po spacji) dodać:

-Wl,-u,vfprintf -lprintf_flt

W przypadku wersji 1.8.12 (a podejrzewam, że wielu innych) będzie to wyglądać tak:

recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -mmcu={build.mcu} {compiler.c.elf.extra_flags} -o {build.path}/{build.project_name}.elf" {object_files} "{build.path}/{archive_file}" "-L{build.path}" -l m -Wl,-u,vfprintf -lprintf_flt

Druga sprawa to laser. Na potrzeby programu zmodyfikowałem nieco bibliotekę Pololu dodając możliwość nieblokującego odczytu danych. Mimo to czujnik zachowywał się dość dziwnie: czasami zwracał bardzo pięknie prawidłowe odległości, a czasami kompletnie wariował. Bliższe przyjrzenie się problemowi poskutkowało stwierdzeniem, że czujnik zwraca nieprawidłowe dane po wgraniu kolejnej wersji programu (ściślej po programowym resecie Arduino). Ponieważ w bibliotece zabrakło funkcji resetowania lasera postanowiłem wypróbować najprostszą możliwość - w funkcji setup przed init() wstawiłem następujący kod:

lidar.writeReg(VL53L0X::SOFT_RESET_GO2_SOFT_RESET_N, 0);
delay(100);
lidar.writeReg(VL53L0X::SOFT_RESET_GO2_SOFT_RESET_N, 1);
delay(100);

Od tej pory laser przestał mieć fochy i grzecznie zwraca odczytane odległości.

I jeszcze jedna uwaga dla kogoś, kto na tej podstawie chciałby zbudować własną wersję robota.

Otóż funkcja "Patrol" w teorii działa, w praktyce jednak robot nie jest w stanie ustawić się dokładnie równolegle do ściany. Co najmniej w czasie pierwszego przejazdu powinno się dokonać korekty... niestety, o ile laserowy czujnik jest wystarczająco precyzyjny, o tyle brak enkoderów nie pozwala na pomiar przebytej odległości. Prawdopodobnie i tak dałoby się to zrobić oceniając mniej więcej prędkość robota, i dokonując korekty zanim robot dojedzie do ściany z przodu... ale prawdę mówiąc już mi się nie chciało 🙂 Natomiast uważam zadanie za całkiem ciekawe i pozostawiam sobie na przyszłość - na razie muszę niestety przerwać pracę nad robocikiem i zająć się bardziej przyziemnymi sprawami 😞
    
Aha, obiecałem jeszcze o kółku.

No więc początkowo chciałem wyposażyć robota w kulkę podporową. Bliższa analiza zawartości szuflady wykazała, że mam dwa rozmiary: mianowicie za dużą i za małą. Drukowanie kulki raczej nie wchodziło w grę, natomiast obrotowe kółko można wydrukować na dowolej taniej drukarce. Wygląda to tak:

Oprócz trzech drukowanych elementów do zrobienia kółka potrzebne są:

1 x śrubka M3x8
1 x śrubka M3x16
2 x nakrętka M3
2 x łożysko kulkowe 3x10x4

Kółko mocowane jest dwiema śrubkami M2x10 do podwozia.

Załączam plik OpenSCAD (gdyby ktoś chciał sobie takie kółko zmodyfikować do własnych potrzeb) oraz pliki STL (gdyby ktoś chciał tylko wydrukować bez modyfikacji). Kółko dopasowane jest wysokością do silników Pololu Micro (lub tańszych N20) mocowanych bezpośrednio pod dolną płytą podwozia oraz kół o średnicy 42mm. Łożyska trzeba wcisnąć we właściwe otwory (ja użyłem zwykłego małego imadełka), gdyby okazały się za luźne należy po prostu w OpenSCADzie zmniejszyć nieco ich średnicę.

Nie załączam schematu ani programu sterownika - nie jest specjalnie udany, używam go przede wszystkim dlatego, że nie chce mi się robić innego. Lepiej zastosować np. bezprzewodowy gamepad (w sumie cenowo wyjdzie na jedno).

No i na koniec filmik demonstrujący działanie robota - niestety nie we wszystkich programach (Moocher i Patrol wymagają więcej miejsca, a na dziś nie bardzo dysponuję takim które się nadaje do kamery).

 

 

A - oczywiście winien jestem jeszcze wyjaśnienie, skąd takie dziwne imię Zbignaś. To po prostu skrót od Zbieracz Gwoździków, Nakrętek i Śrubek 🙂

Pora na podsumowanie i wnioski. A więc:

• Robot powinien być okrągły - konstruktorzy Roomby nieprzypadkowo tak go zaprojektowali.
• Zderzak powinien obejmować cały obrys robota (nie tylko przód jak w Roombie) oraz całą wysokość (robot nie może wjechać pod mebel jeśli jest za mało miejsca).
• Nic nie może wystawać ponad zderzak
• Laser musi obejmować 360°, oś obrotu (niekoniecznie sam laser) powinna być w środku robota (jak to połączyć z poprzednim punktem?)
• Enkodery nie muszą być super dokładne kwadraturowe, wystarczą zwykłe niewielkiej rozdzielczości, ale powinny być.

W załączniku: program robota, zmodyfikowana biblioteka do czujnika, pliki do kółka oraz (może się komuś przydadzą) opona i felga (STL i SCAD, do opony/felgi potrzebny openscad w wersji nightly).Zbignas.zip

W razie pytań i pretensji jestem do dyspozycji. Gdyby coś z moich STL-i było potrzebne proszę o informację (tylko nie na priv, błagam).

 

Edytowano Kwiecień 14, 2020 przez ethanak

[SOYER]

Fajne, ale co tam jest takie głośne? 

[ethanak]

Nic nie jest głośne - po prostu nie masz skali odniesienia bo nie ma innych dźwięków. Poza tym tu akurat robot jeździ po panelach pod którymi jest pusto i robi się z tego klasyczny rezonator 🙂

 

[Przemek1967]

Fajny robocik.
Interesuje mnie problem utrzymania kierunku i skrętów.
Czy to funkcja readGyro() i wyliczenie "mikro" rotacji jest za to odpowiedzialna ?

    float delta=(rotspeed = (gyro.g.z - 5.8)) * (ms - gyrotime) * 8.75E-9;
    rotation += delta;

 

 

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Anonim]

A gdzie obrotowe szczotki czyszczące podłogę i spryskiwacz płynu dezynfekującego?? ehhh..

[ethanak]

8 godzin temu, Przemek1967 napisał:

Interesuje mnie problem utrzymania kierunku i skrętów.

Zastosowałem tu bardzo uproszczoną wersję. Zmienna "rotation" (trochę niefortunnie dobrana nazwa, ale to pozostałości po pierwszych testach) zawiera aktualny kierunek jazdy robota. Przy jeździe prosto odchylenie od zera o zbyt dużą wartość powoduje, że robot zaczyna skręcać próbując utrzymać kierunek jazdy. Przy skręcie (jedno koło napędzane) lub obrocie w miejscu(oba koła napędzane przeciwbieżnie) robot kończy skręt kiedy wartość rotation osiągnie zadaną wartość. Co prawda bezwładność układu napędowego powoduje, że w rzeczywistości skręt jest zbyt mocny, ale nadrabiane jest to w następującym po skręcie ruchu do przodu (rotation na początku przyjmuje wartość odchylenia od żądanego kierunku), a w przypadku obrotu o 180° po prostu zadana wartość jest nieco mniejsza, aby uwzględnić i w pewnym stopniu skorygować ową bezwładność. Również przy pomiarach kątów uwzględniona jest rzeczywista pozycja robota.

Oczywiście coś takiego nie nadaje się do poważniejszych celów, ale w przypadku robota który nie musi być precyzyjny co do milimetra (przecież to jeździ po podłodze, a nie polu minowym) wystarcza.

7 godzin temu, atMegaTona napisał:

A gdzie obrotowe szczotki czyszczące podłogę i spryskiwacz płynu dezynfekującego??

To nie ta wersja - na razie to o czym piszesz jest w fazie bardzo wstępnych projektów (próbuję pogodzić ze sobą wymagania co do kształtu i rozmiarów robota z rozmieszczeniem szczotek i ogólnie problemami wynikającymi z braku możliwości wykonania bardziej precyzyjnych elementów). Patrz - wnioski na końcu pierwszego posta.

Poza tym nakrętki i śrubki nie wymagają szczotek ani płynu 🙂

 

[Przemek1967]

@ethanak Dzięki za słowny opis. Tak przypuszczałem że to działa choć nie pomyślałem o bezwładności silników podczas skrętu i korekcie dopiero podczas kolejnego ruchu. Pewnie bym próbował od razu skorygować pozycję co doprowadziłoby do ciągłego "dygotania" robota bo nigdy by się precyzyjnie nie ustawił. Ewentualnie bawił bym się jeszcze regulacją prędkości przez PID.

Widać na przykładzie że Gyroscope jest wystarczająco dokładne dla domowych czy zabawowych zastosowań, a zwłaszcza prostsze niż montaż enkoderów.

Dzięki za inspirację 🙂

Edytowano Maj 5, 2020 przez Przemek1967