Kubik M0: ewolucja 4-nożnych pająków

[deshipu]

Swoją przygodę z elektroniką zacząłem kilka lat temu z celem zbudowania czworonożnego chodzącego robota. Nie bardzo sobie zdawałem wówczas sprawę ze stopnia skomplikowania tego zadania i śmieszy mnie dziś moja ówczesna naiwność, ale od tego czasu minęło parę lat i wiele się nauczyłem. W międzyczasie stworzyłem projekt taniego i łatwego w montażu robota, który opublikowałem pod adresem http://tote.rtfd.io, żeby nieco ułatwić zadanie innym. Naiwnie myślałem, że skoro dałem ludziom prosty punkt startowy, to teraz będą na jego bazie budować bardziej rozbudowane roboty i eksperymentować z platformą. Oczywiście myliłem się straszliwie, choć wiem o kilku konstrukcjach zainspirowanych moją.

Dziś sam jestem dziadkiem^W^Wwiedząc więcej o tym jak to działa, postanowiłem zaprojektować zestaw do samodzielnego montażu oparty na podobnych pomysłach, ale bardziej mający formę gotowca. Zamiast optymalizować cenę postanowiłem tym razem zoptymalizować wygodę. Docelowo zamierzam zestaw sprzedawać częściowo zmontowany na Tindie.

Dużo szczegółów konstrukcji pozostało z Tote. Nadal używam tanich serw SG90, które nadal zasilam bezpośrednio z baterii LiPo, kompensując za niskie napięcie większą częstotliwością sygnału sterującego. Nadal wykorzystuję fakt, że robot jest taki lekki, żeby przemycić nie do końca koszerne rozwiązania, jak wykorzystanie serw jako stawów nóg, bez dodatkowego podparcia, albo sklejanie ze sobą dwóch serw za pomocą hot glue. Ale tym razem nie używam taniego Arduino Pro Mini i C++, tylko mikrokontroler Atmel SAMD21 i CircuitPython. Nie ma już brzęczyka piezo na nóżce GPIO, tylko głośniczek podłączony do DAC. Do tego dodany jest akcelerometr dla prostego reagowania na ruszanie robotem i to tyle. Na górze jest header z nieużywanymi pinami do wpinania ewentualnych rozszerzeń — czujników lub dodatkowych serw czy światełek.

Największą innowacją jest zrezygnowanie z użycia plastikowych orczyków od serw jako elementów konstrukcyjnych nóg, a zamiast tego płytka PCB zawiera, poza układem sterującym robota także wszystkie elementy mechaniczne. Sprawia to też, że łatwo możemy wymienić fragmenty nóg na inne, zawierające czujniki lub inne elementy elektroniczne.

Programowanie, jak to w CircuitPythonie, odbywa się poprzez wgranie plików z kodem w Pythonie do robota, który po podłączeniu przez USB pojawia się w komputerze jako dysk. Możliwe też jest eksperymentowanie na żywo za pomocą konsoli pythonowej dostępnej po serialu.

Robot jest pod względem mechanicznym w zasadzie ukończony, jak zwykle pozostaje jego zaprogramowanie, które pomimo wykorzystania języka wysokiego poziomu zajmuje mi sporo czasu — muszę się przyznać, że to nie ze względu na trudność problemu, ale na zmęczenie dzienną pracą i ciągłe odkładanie tego na później.

Edytowano Wrzesień 19, 2018 przez deshipu

[Treker (Damian Szymański)]

@deshipu, jak zawsze świetny projekt 🙂 Bardzo lubię takie sprytne rozwiązania jak np. "szkielet" robota odłamywany z PCB, świetnie wygląda też ten mały akumulator. Na ile mniej więcej będziesz wyceniał ten zestaw?

Dnia 19.09.2018 o 13:55, deshipu napisał:

Ale tym razem nie używam taniego Arduino Pro Mini i C++, tylko mikrokontroler Atmel SAMD21 i CircuitPython.

Skąd taka zmiana? Arduino było za słabe czy po prostu szukałeś czegoś nowego 😉?

[deshipu]

12 godzin temu, Treker napisał:

Dnia 19.09.2018 o 13:55, deshipu napisał:

Ale tym razem nie używam taniego Arduino Pro Mini i C++, tylko mikrokontroler Atmel SAMD21 i CircuitPython.

Skąd taka zmiana? Arduino było za słabe czy po prostu szukałeś czegoś nowego 😉?

Generalnie przesiadłem się już w całości na Pythona, plus czyste C tam gdzie potrzeba prędkości. W ten sposób po prostu jestem w stanie robić większe projekty i szybciej je debugować.

[Gieneq]

Dnia 19.09.2018 o 13:55, deshipu napisał:

tylko mikrokontroler Atmel SAMD21 i CircuitPython

Jak wygląda sterowanie serwami w Pythonie?

Myślę, że na forum jesteś dobrą osobą do pytań o mikrokontrolery i Pythona.  Ostatnio też ruszyłem temat ESP32 i MicroPythona, raczej z powodzeniem, akurat był to temat MQTT i komunikacji z RPi.
A jak to jest z innymi mikrokontrolerami - przykładowo STM32F4 - w dziale download co prawda jest firmware ale opisany jest jako "not officially supported but should be fully functional". Czy coś to zmienia?

[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

[deshipu]

1 godzinę temu, Gieneq napisał:

Jak wygląda sterowanie serwami w Pythonie?

Zależy na czym ten Python jest uruchomiony. Generalnie w czymkolwiek byś nie programował, to musisz dostarczyć temu serwu sygnał PWM. Przy 12 serwach masz w zasadzie dwie opcje: albo używasz timerów do generowania tego sygnału — tak robię w tym przypadku, używając w CircuitPythonie klasy pulseio.PWM — albo podłączasz osobny czip, który ci ten sygnał generuje, na przykład PCA9685, i wysyłasz do niego tylko pozycje — tak robię w wielu moich innych robotach.

1 godzinę temu, Gieneq napisał:

A jak to jest z innymi mikrokontrolerami - przykładowo STM32F4 - w dziale download co prawda jest firmware ale opisany jest jako "not officially supported but should be fully functional". Czy coś to zmienia?

Generalnie jedyną "oficjalnie wspieraną" przez autorów MicroPythona platformą jest ich PyBoard, wszystko inne jest "nieoficjalne", bo oczywiście chcą tego jak najwięcej sprzedawać. W praktyce wszystkie STM32F4 są na tyle blisko, że wszystko powinno działać. Możesz tylko nie mieć wsparcia dla jakichś wydumanych rzeczy które są specjalne na jakimś czipie.

[deshipu]

No i niestety będę musiał przeprojektować tego robota. Okazało się, że w wersji CircuitPythona której używałem żeby wszystko sprawdzić był błąd w module pulseio w tym jak wybierane był timery i ich kanały przy tworzeniu nowych obiektów PWMOut. Przez to niektóre z nich używały tego samego timera i kanału, dzięki czemu zawsze miały ten sam duty cycle, więc serwa poruszały się razem — nie zauważyłem tego, bo przy testach ustawiałem wszystkie serwa w tej samej pozycji — that było najłatwiej napisać program.

W nowej wersji CircuitPythona błąd jest poprawiony i pulseio rzuca wyjątek jak się próbuje stworzyć PWMOut dla wielu pinów, a nie ma już wolnego kanału timera. No i oczywiście dostaję taki błąd teraz z moim robotem. Będę musiał usiąść i z naleźć taką kombinację nóżek, dla których da się utworzyć PWMOut jednocześnie, a to niestety oznacza przeprojektowanie płytki.

Ale nie ma tego złego co by na dobre nie wyszło: przy okazji wyrzucę akcelerometr (okazał się bezużyteczny), dodam pamięć flash (miejsce w systemie plików się przyda), przeprojektuję układ ładowania baterii (żeby się ładowała przy wyłączonym robocie) i przeniosę wszystko na górę płytki (komponenty schowane pod pojemnikiem baterii wglądają fajnie, ale są strasznie uciążliwe do debugowania). Przy okazji też dorzucę wyłączniki krańcowe na końcach stóp. Jak nie znajdę działającego zestawu 12 pinów, to będę musiał zmienić mikrokontroler na większy.

[Treker (Damian Szymański)]

56 minut temu, deshipu napisał:

Ale nie ma tego złego co by na dobre nie wyszło: przy okazji wyrzucę akcelerometr (okazał się bezużyteczny)

Z ciekawości dopytam: bezużyteczny przez brak praktycznego zastosowania czy były jakieś problemy i np. odczyty były zbyt niestabilne, aby był sens je wykorzystywać?

[deshipu]

I jedno i drugie. Mógłbym go wykorzystać do sprawdzenia czy robot jest do góry nogami czy nie, i to w zasadzie tyle.

[deshipu]

Od ostatniego wpisu trochę wody w Limmacie upłynęło, a projekt nie stał w miejscu. Zmieniło się w zasadzie wszystko, od nazwy i założeń, po mechaniczną konstrukcję i mikrokontroler. Ale może od początku.

Ogólna idea pozostaje taka sama: ma to być tani pająko-podobny robot kroczący na biurko. Nazywa się teraz Fluffbug, bo to jest łatwiej znaleźć. Zrezygnowałem też z jednego początkowego założenia: braku części wycinanych laserem lub drukowanych na drukarce 3D — a to z tego powodu, że techniki te stały się dziś na tyle pospolite, że łatwo można sobie takie części zamówić, nawet nie posiadając odpowiedniego sprzętu i doświadczenia. Zatem elementy nóg są tym razem wycięte z akrylu lub drewna, choć nadal mam opcjonalne nogi z płytki PCB z sensorami (na zdjęciu leży jedna pod robotem).

Konstrukcja mechaniczna zmieniła się całkowicie. Nie ma już hot glue, wyleciały też cztery serwa — w ten sposób robot jest tańszy i lżejszy. Niestety ceną za pozbycie się tych serw jest ograniczenie ruchliwości — robot nie może poruszać nogami na boki, więc jakiekolwiek skręcanie odbywa się w stylu czołgu — nogi po jednej stronie pchają w przód, po drugiej w tył i całość się obraca. Nie jest to poprawne chodzenie bez poślizgu nóg, ale jakoś się z tym pogodziłem.

Usprawniłem też zarządzanie kablami, z czym zawsze miałem duży problem. Kable w serwach są zazwyczaj o wiele za długie, a ich skracanie wymaga dodatkowych części i narzędzi, żeby móc założyć wtyczkę na obcięty kabel. Zatem zrezygnowałem ze standardowych wtyczek i zamiast tego używam wtyczek od tak zwanych "wstążek", które zaciska się bezpośrednio na kablu. Resztę kabla można wtedy spokojnie obciąć i zostaje nam go dokładnie tyle, ile potrzeba.

Zmianie uległ także mikrokontroler. Zamiast SAMD21 wlutowanego na płytkę, wróciłem do gotowych płytek, i użyłem Lolin S2 Mini. To jest płytka z ESP32-S2 na pokładzie (zatem ma natywne USB i chodzi na niej CircuitPython), która jest przy tym kompatybilna ze wszystkimi shieldami do WeMos D1 Mini — zatem możemy naszemu robotowi doprawić wiele twarzy. Wbudowane WiFi (albo ESP-Now) pozwoli na zdalne sterowanie, a dodatkowa pamięć i nóżki może nawet pozwolić na podłączenie kamery (eksperymentuję w tej chwili z OV2640).

Poza tym robot w zasadzie składa się z baterii, czipu ochronnego do tej baterii, układu ładowania, wyłącznika oraz głośniczka piezo. Całość zmontowana jest na płytce, która stanowi także ciało robota.

Największym wyzwaniem jest oczywiście jak zawsze programowanie i tutaj prace postępują powoli. Na razie mam kinematykę odwrotną nóg i zerowanie serw. Pracuję nad pierwszymi chodami (crawl i trot) oraz skręcaniem. Sterowania nawet jeszcze nie dotknąłem. Problem głównie polega na braku czasu — do programowani potrzeba mi więcej skupienia niż do przylutowania kilku komponentów czy przykręcenia paru śrubek i trudniej to robić na raty. Ale co się odwlecze, to nie uciecze i jestem pewien, że prędzej czy później wrzucę tu nagranie chodzącego robota.