Freestyle Kopłapow - etiuda na temat sprzątacza

[ethanak]

Mam zaszczyt przedstawić: Roko Kopłapow - czyli Robot Koncepcyjny, Konserwator Płaskich Powierzchni. Co mniej więcej ma oznaczać: mopopodobny twór samojezdny, którego zadaniem jest sprawdzenie wszelkich koncepcji przed zaprojektowaniem i skonstruowaniem prototypu robota do czyszczenia podłogi na mokro.

Niestety - nie wszystko poszło po mojej myśli. Niektóre koncepcje okazały się absolutnie nietrafione, inne wymagają dopracowania i ponownego sprawdzenia. Sam robot jednak doskonale się sprawdził pokazując mi, w którą stronę mają iść dalsze prace.

Jakie były założenia:

1. robot ma służyć do przetarcia podłogi na mokro;
2. ma być sterowany pojedynczym Arduino Pro Mini;
3. miło by było aby realizował wszystkie funkcje, ale równie dobrze może pracować jako "inteligentne podwozie ze szczotkami", czyli jako nośnik różnej maści przystawek;
4. Robot powinien umieć poruszać się po podłodze bez jej zmywania (czyli podnieść mechanizm szczotek choćby w celu przejechania przez próg);
5. Robot powinien umieć znaleźć stację dokującą lub miejsce parkingowe.

Co się nie sprawdziło:

Podnoszone szczotki

Założenie całkiem fajne, ale zbyt duża siła jest potrzebna do podniesienia całego mechanizmu. W dodatku podniesiony mechanizm zajmuje zbyt dużo miejsca. Teoretycznie dało by się to obejść ale robot musiałby być dużo większy, a tego nie chciałem.

Podwozie gąsienicowe

O ile na normalnym podłożu zachowywało się bez zarzutu - o tyle na mokrej, śliskiej podłodze to absolutna porażka, gąsienice po prostu nie łapią przyczepności.

Podwozie Pololu (testowo z pojedynczą nieruchomą gąbką) w ogóle nie chciało skręcać, jeśli napędzana była tylko jedna gąsienica jechał sobie dalej prosto, przy napędzanych dwóch przeciwbieżnie robił jakieś dziwaczne ewolucje nie mające nic wspólnego ze skręcaniem.

Podwozie Tamiya (maksymalna długość gąsienic, szerokość zwiększona do 15 cm) - niewiele lepiej. Co prawda przy podniesionych szczotkach dało się tym manewrować, ale jako że podnoszone szczotki też nie zdały egzaminu - zrezygnowałem z gąsienic i zrobiłem kołowe.

Żyroskop

Teoretycznie wszystko było w porządku, robot bardzo ładnie jechał prawie po prostej mimo wirujących szczotek które rzucały nim na boki, skręcał dokładnie o tyle ile chciałem... przez pierwsze 30 sekund. Tyle czasu udało mi się utrzymać mojego MPU6050 przy życiu. Niestety - po bardziej wnikliwych poszukiwaniach okazało się, że nie tylko ja mam takie problemy, niektóre egzemplarze działają bezbłędnie, inne się wieszają (zawieszając przy okazji Arduino). Tak więc na razie robot obywa się bez żyroskopu, chociaż w przyszłości na pewno się na niego zdecyduję (może taki? Poradzicie?).

Stacja dokująca

W związku z brakiem podnoszonych szczotek musiałem z niej zrezygnować - robot nie przejedzie przez próg, a stacja dokująca powinna być w innym pomieszczeniu. Szkoda... Na razie zamiast dokowania robot powinien wjechać w wyznaczony kąt pomieszczenia i się wyłączyć, ale do tego muszę wymyśleć jakiś inteligentny wyłącznik (to już w oddzielnym wątku).

Wąska wiązka czujnika laserowego

Chciałem przy "rozglądaniu się" robota ograniczyć szerokość matrycy. Niestety - tu już nie pozwoliło mi na to oprogramowanie. Mamy do dyspozycji dwie biblioteki do czujnika VL53L1X: jedną uproszczoną (która nie pozwala na ustawienie regionu) i drugą pełną (adaptacja ST, pozwala na wszystko tyle że zajmuje 20 kB, jak na małe Arduinko to nieco za wiele). Być może któregoś pięknego dnia uda mi się dopisać tę możliwość do tej mniejszej biblioteki, ale na razie niespecjalnie mam na to czas, a z szerokością wiązki 27° muszę nauczyć się żyć... Inna możliwość to postawienie drugiego procesorka tylko do obsługi lasera, mógłbym wtedy zmienić serwo na mały silnik krokowy (nawet taki mi w szufladzie leży), tylko czy jest sens?

A co się sprawdziło:

Przede wszystkim - napęd szczotek. Obie szczotki to po prostu kuchenne gąbki włożone w uchwyty, napędzane są pojedynczym silnikiem z dwustronnym wałem. Szczotki są obrócone wobec siebie o kąt 90°, aby zmniejszyć szerokość robota i pozbyć się martwego pola pomiędzy szczotkami, obracają się przeciwbieżnie. Gąbki można w każdej chwili wyjąć i wymienić na czyste, w dodatku mogą być włożone zarówno miękką, jak i szorstką stroną do podłogi.

Druga rzecz bez której dalsza praca nie miałaby sensu to przedni zderzak. Musi być bardzo lekki, znajdować się dość nisko nad podłogą (progi) a jednocześnie mieć wysokość wystarczającą, aby robot nie usiłował wleźć pod jakąś kuchenną czy łazienkową szafkę. Jednoczęściowy zderzak zapewnia wykrycie przeszkody w promieniu 180°, jest na tyle lekki że nie mam nawet żadnych sprężyn - cztery krańcówki wystarczają. Krańcówki są połączone po dwie równolegle z każdej strony, zwierają przez rezystor do masy co umożliwia bezproblemowy odczyt zderzaków przez pojedyncze wejście analogowe Arduino.

Z drobiazgów: materiał. Oprócz elementów drukowanych z PLA mam tu:

• płytę główną podwozia z 3mm PCW. Łatwe w obróbce, w miarę elastyczne i wystarczająco wytrzymałe.
• podłogę piętra ze spienionego PCW 4mm. Nie musi wytrzymywać dużych obciążeń, jest bardzo lekkie i możliwe do cięcia zwykłym ostrym nożem.
• koszyki na akumulatory wydrukowane z PET-G z integralną sprężyną. Początkowo obawiałem się że nie będą kontaktować - okazało się, że sprawują się dużo lepiej niż kupowane podwójne (już nie mówię o porażce pod tytułem "koszyk na jeden akumulator"), a przy okazji mam tu porządny przewód (ucięty od pecetowego zasilacza) a nie jakiś chiński włosek. Dla zainteresowanych podaję link na thingiverse.

A z rozwiązań:

Enkodery na kołach.

No - powiedzmy częściowo, trochę za mała rozdzielczość ale działają. Do bardziej precyzyjnych rzeczy pewnie by się nie nadały, ale tu zdają egzamin.

Ponieważ nie wyszedł mi napęd gąsienicowy, zacząłem szukać jakichś fajnych kółek. Kiedyś znalazłem na Allegro za jakieś śmieszne pieniądze silniczki z kątową przekładnią (odpowiedniki Pololu), dokupiłem do tego koła Pololu 42x19, zmontowałem jakieś prowizoryczne podwozie... i na tym się skończyło bo jakoś straciłem zainteresowanie projektem.  Czyli silniki z kołami już miałem.

W pierwszej wersji robot miał się orientować w przestrzeni za pomocą żyroskopu i laserowego czujnika odległości, ale z braku żyroskopu zostałem skazany na enkodery. Co prawda oficjalnie te silniki nie miały możliwości zamontowania enkoderów, ale na szczęście w to nie uwierzyłem

Postanowiłem umieścić enkodery wewnątrz kół. Co prawda miejsca jest dość mało, musiałem wydrukować nowe felgi, ale jakoś cała konstrukcja się zmieściła. Użyłem popularnego TCRT5000L (zawsze mi kilka w szufladzie leży), dokleiłem uchwyty do silników... i ruszyło! Co prawda enkodery czasami fałszują, ale uczciwa bramka Schmitta powinna im w przyszłości pomóc. Na razie podłączenie wygląda tak:

Dla zainteresowanych - zdjęcia i pliki STL/SCAD.

Czujnik odległości 360°

Niedawno ktoś pytał o coś takiego - o ile pamiętam chodziło o ultradźwiękowy czujnik odległości o zakresie ruchu 360°. Ponieważ moje rozwiązanie działa całkiem nieźle (należałoby tylko maksymalnie zmniejszyć luzy, ale to już zależy od możliwości drukarki) mam tu prostą przekładnię, zakładaną bezpośrednio na serwo i mocowaną tymi samymi śrubami co serwo, z tarczą pozwalającą na zamocowanie czujnika (w moim przypadku laser, ale może to być równie dobrze czujnik ultradźwiękowy). Dwie wersje: większa i kompaktowa (jeśli nie starcza miejsca).

Jako osi użyłem śruby z podwozia Tamiya oryginalnie służącej do mocowania kół jezdnych z uwagi na fagment bez gwintu, ale w ostateczności można spróbować ze zwykłą śrubą M3.

Tym razem nie ma STL-i jako że każdy ma inne potrzeby, zamiast tego plik dla OpenSCAD-a. Potrzebne będą biblioteki: spur_generator oraz parametric_involute_gear_v5.0.

Co do programu:

Program jest dość prosty, nie ma sensu publikowanie bo pewnie jutro jak mi się coś przyśni to będzie inny (możliwe że lepszy, ale niekoniecznie). Zresztą tak jak wspominałem - to jest egzemplarz koncepcyjny, wystarczy mi stwierdzenie że "da się to zrobić". Mój SMARDZ niesamowicie ułatwia programowanie, musiałem go tylko trochę inaczej zamocować (dodatkowy uchwyt i przedłużacz) bo przy gwałtowniejszych manewrach zsuwał się z pinów - prawdopodobnie bez czegoś takiego rzuciłbym to po paru godzinach.

Robot ma cztery tryby pracy:

1. Zdalne sterowanie - wiadomo o co chodzi. Zrobiłem kiedyś takiego uniwersalnego radiopilota, to już czwarte urządzenie które nim steruję;
2. Jazda losowa - taki typowy wszędołaz, potrafi omijać przeszkody, stara się nie jechać prosto za długo aby się poszwendać w ciekawszych miejscach;
3. Plama - analogicznie jak w Roombach, wyciera podłogę w promieniu do ok. 70 cm od miejsca startu i zatrzymuje się po skończeniu pracy;
4. Sprzątanie - tu program nie jest dopracowany, ale w wersji koncepcyjnej nie ma to większego sensu. Ogólnie robot powinien podjechać do najbliższej ściany (to potrafi), ustawić się do niej równolegle (to też potrafi) i krążyć po pomieszczeniu coraz bliżej środka (tu ma problemy związane z niedokładnością enkoderów).

Tak wygląda robot w trybie "plama":

Ktoś za chwilę powie: zaraz, przecież to robot do sprzątania na mokro, a gdzie woda?

Na razie nie ma. Po prostu: ponieważ nie ma stacji dokującej, przed uruchomieniem robota należałoby ręcznie uzupełnić wodę w zbiorniku. Dużo wygodniejsze jest po prostu spryskanie wodą podłogi w pomieszczeniu przed uruchomieniem robota.

A czemu "na razie"? Bo jak wspomniałem na początku, ten robot powinien mieć możliwość współpracy z przystawkami, a taką przystawką może być np. urządzenie do spryskiwania płynem do mycia paneli. Ale taka przystawka powinna mieć swój procesor, robot w tym momencie powinien przestawić się w tryb "inteligentnego podwozia", a to wszystko jest kwestią przyszłości

Na razie robot spełnił swoje zadanie, popracuję jeszcze trochę nad programem (dopóki się da), i zaczynam zbierać kasę na wersję finalną

Obiecane pliki STL i SCAD w załączniku:koplapow.zip

Jak zwykle jestem gotów odpowiedzieć na pytania - choć tym razem chyba ich nie będzie...

Edytowano Październik 28, 2019 przez ethanak

[Treker (Damian Szymański)]

Właśnie zaakceptowałem Twój opis, możesz go teraz zgłosić do akcji rabatowej umieszczając link w temacie zbiorczym. Dziękuję za przedstawienie ciekawego projektu, zachęcam do prezentowania kolejnych DIY oraz aktywności na naszym forum

[TheAresX]

Czy jak byś zamocował na wał silników od napędu zębatkę, a obok enkoder z myszki komputerowej także z zębatką to nie działało to by lepiej?

Edytowano Październik 31, 2019 przez TheAresX

[ethanak]

Pewnie tak, ale by się nie zmieściło. Poza tym dwa TCRT miałem, a dwóch myszy nie

[TheAresX]

@ethanak Zmieścić by sie zmieściło pewnie, ja mam takie co mają Max 1 cm średnicy

[Gość]

Podoba mi się ten pomysł, żeby sobie zminiaturować przemysłową maszynę do mycia podłogi - precz z mopami! @ethanak to jest wersja rozwojowa czy finalna? Ciekaw jestem postępów. Może jakiś ciekawy pomysł względem samej techniki mycia się tu pojawi i będę mógł go zaimplementować swojej żonie ;D

[ethanak]

11 godzin temu, atMegaTona napisał:

to jest wersja rozwojowa czy finalna?

A pisałem, pisałem...

Dnia 28.10.2019 o 18:16, ethanak napisał:

którego zadaniem jest sprawdzenie wszelkich koncepcji przed zaprojektowaniem i skonstruowaniem prototypu

Wiadomo że w tej postaci robot nie nadaje się do normalnego użytkowania, swoje zadanie spełnił i teraz czas na pierwszą wersję użytkową. Na pewno pozostawię przedną część (silnik z gąbkami i zderzak) ale resztę trzeba zrobić od początku - tym razem bez prowizorek bo już wiem co będzie działać a co mogę sobie darować.

13 godzin temu, TheAresX napisał:

Zmieścić by sie zmieściło pewnie, ja mam takie co mają Max 1 cm średnicy

Nie byłbym taki pewny. Zębatka napędowa musiałaby być umieszczona między kołem a korpusem silnika, siłą rzeczy musi mieć mniejszą średnicę niż opona. Zębatka przy enkoderze też jakąś tam średnicę musi mieć, czyli jakby nie patrzeć gdzieś to będzie  wystawać. Koło musiałoby być jeszcze bardziej odsunięte od silnika...

W sumie na upartego dałoby się to upchnąć, ale miałoby to sens, gdyby takie znormalizowane mechanizmy można było gdzieś tanio kupić. Musi być tanie i łatwe do przeróbki - bo przecież w podobnej cenie istnieją silniki z podwójnym wałem, które żadnych przeróbek nie wymagają. Musi być łatwo dostępne - jakaś awaria nie może mi unieruchomić robota bo zastosowany element jest nie do zdobycia...

Tak że jeśli mój sposób po dodaniu bramki Schmitta (akurat nie mam, muszę dopiero zamówić) nie będzie działać prawidłowo - po prostu zastosuję inne silniki.

[sparow]

Najlepiej gdyby był oparty o zasadę działania na środowisku ros. Z budową mapy otoczenia. Wtedy miałbyś dokładniejsze sprzątanie oraz dodatkowe funkcje takie jak planowanie drogi itd. 

[ethanak]

30 minut temu, sparow napisał:

Najlepiej gdyby był oparty o zasadę działania na środowisku ros. Z budową mapy otoczenia.

Na ATmedze 328???

[sparow]

No na atmedze tego nie ogarnieszmin malinka albo coś mocniejszego. Np pc na pokład mini itx mają teraz bardzo małe wymiary i dobre osiągi. 

[ethanak]

3 minuty temu, sparow napisał:

No na atmedze tego nie ogarniesz

Wiem. A w założeniach jest właśnie Arduino Pro Mini

Co do wymiarów - wolałbym postawić w robocie np. ESP32 i połączyć to z domowym pecetem czy laptopem w charakterze serwera - mniej prądu by żarł, a i moc obliczeniowa ciut większa niż malinki... ale to temat na zupełnie inną konstrukcję.