Freestyle Robot balansujący sterowany pilotem TV

[Sztef]

Pomimo, że roboty balansujące już kilkakrotnie pojawiały się na forbocie, chciałbym zadebiutować na forum prezentując moją nową konstrukcję. Skoro jest cała armia linfollowerów i minisumo, to niech i robotów balansujących przybędzie.

Początkowo myślałem, że będzie to ciężkie i złożone zadanie. Jednak w praktyce okazało się jedynie trochę czasochłonne. Działanie konstrukcji dało mi bardzo wiele satysfakcji, dlatego szczerze polecam ten projekt osobom, które już dość swobodnie czują się w robotyce, a chcą spróbować czegoś nowego. Odwrócone wahadło jest dość intrygującym urządzeniem, które aby się utrzymać w pionie, wymaga ciągłej kontroli i precyzyjnej regulacji. Właśnie dlatego projekt taki sprawia naprawdę dużo frajdy.

Założenia:

Robot ma utrzymywać równowagę i przemieszczać się w kierunku zadanym przy pomocy pilota od telewizora. Służyć ma przede wszystkim dobrej zabawie i poszerzeniu doświadczenia. Ma wykorzystywać żyroskop i akcelerometr oraz poruszać się na silnikach krokowych. Konstrukcja wykonana w domowych warunkach, z wyjątkiem ramy, która została wydrukowana u kolegi.

Konstrukcja:

Rama robota jest wydrukowana na drukarce 3d z materiału PLA w czterech częściach, które zostały później ze sobą skręcone.

Koła to połączenie bezkonkurencyjnych pod względem jakości półpneumatycznych kół Lego oraz wydrukowanej z PLA felgi, która pozwala na przymocowanie do huba POLOLU. Ten ostatni bezpośrednio trzyma się wału silnika.

Robota napędzają silniki krokowe, które są łatwiejsze w obsłudze, niż zwykłe silniki DC z enkoderami. W tym konkretnym zastosowaniu niezbędne jest uzyskanie dokładnie ustalonej prędkości obrotowej – inaczej robot nie będzie się dobrze trzymał. Niestety natura silników krokowych pozostawia sobie wiele do życzenia. Nie mogą one osiągać zbyt dużych prędkości, a to oznacza, że robot nie będzie zbyt żwawy, a przy większych prędkościach może okazać się niestabilny.

Elektronika:

Układy sterujące robotem postanowiłem umieścić na dwóch płytkach drukowanych. Na dole robota znajduje się płytka ze sterownikami silników, czujnikiem LSM6DS3 oraz prostym układem zasilania. Druga płytka zawiera mikrokontroler, odbiornik podczerwieni i moduł bluetooth.

Czujnik LSM6DS3 to żyroskop i akcelerometr, który pozwala na pomiar kąta pochylenia robota. Zarówno impulsy sterujące silnikami, dane z czujnika oraz zasilanie płyną przez 24-żyłową taśmę FFC.

Sterowanie:

Idea sterowania odwróconym wahadłem była już wielokrotnie opisana, dlatego nie będę dublował kolegów z różnych forów. Mój robot wykorzystuje filtr komplementarny (do ustalenia aktualnego kąta wychylenia na podstawie pomiaru żyroskopu i akcelerometru), regulator PD (do utrzymania zadanego kąta) i regulator PID (do obliczenia kąta, o jaki powinien się wychylić robot na podstawie prędkości silników). Seria tych wszystkich obliczeń wykonywana jest z częstotliwością około 104 Hz, ponieważ na taką częstotliwość pracy został ustawiony czujnik, który generuje przerwania. Całym robotem steruje mikrokontroler ATmega88P taktowany z częstotliwością 12MHz. Bez najmniejszych problemów radzi sobie w 10 ms ze wszystkimi obliczeniami, które w wielu miejscach zawierają operacje zmiennoprzecinkowe.

Wspomniany wcześniej moduł bluetooth był wykorzystywany przy dostrajaniu regulatorów oraz do debugowania programu. W tej chwili robot jest sterowany pilotem od telewizora.

[madman07]

Ładna konstrukcja. Ode mnie wielki plus za wydrukowanie elementów, oraz jeszcze większy za samodzielnie wytrawienie płytek i oparcie projektu o uc, zamiast pchania tam rpi 😉

Dlaczego silniki krokowe a nie BLDC? Chodziło tylko o łatwość sterowania czy były też inne względy?

Dlaczego podczas ruchu robot lekko 'utyka'?

Rozumiem zasadność użycia operacji zmiennoprzecinkowych, ale strasznie razi to w oczy. Zawsze można posiłkować się operacjami stałoprzecinkowymi, które są dość proste i szybkie 😉

Czy rozważasz sterowanie poprzez np. telefon (dotyk lub pochylenie) zamiast pilota?

[Chumanista]

madman07, utyka jak przypuszczam ponieważ ruch jest realizowany przez zadanie kąta, a ponieważ regulacja jest z przycisków zmienia się on skokowo.

[Sztef]

Najpierw dzięki za miłe słowa 🙂

Dlaczego silniki krokowe a nie BLDC? Chodziło tylko o łatwość sterowania czy były też inne względy?

Nigdy nie widziałem, żeby ktoś dawał BLDC w takim zastosowaniu. Zdaje mi się, że BLDC nie do końca dobrze radziłyby sobie z małymi prędkościami, ale tutaj zbyt dużo nie powiem, bo nie wiem. Co innego silniki DC z enkoderami, ale ponieważ to wymaga dodatkowej filozofii sterowania, wygrały krokowe.

Dlaczego podczas ruchu robot lekko 'utyka'?

"Utykanie"... Zastanawiam się, które masz na myśli. Sytuacja wygląda tak, że bardzo czasochłonne jest strojenie regulatorów i jest to niewdzięczna robota trochę. Generalnie na chwilę obecną PD (ten regulator od kąta) jest trochę przeregulowany, natomiast PID (który ustala zadany kąt na podstawie prędkości) jest niedoregulowany, bo inaczej strasznie trząsł tym pierwszym. Dlatego kąt jest uzyskiwany błyskawicznie, a PID przy reakcji na prędkość zaczyna się zachowywać nie do końca zgodnie z planem – falowanie, wolna reakcja itd. Stąd jest na pewno wolne rozpędzanie, problemy ze startem i niemożność utrzymania stałej prędkości na niektórych podłożach. Jeszcze gdzieś koło 26 sekundy filmu robot jedzie takimi "kroczkami". Tutaj najprawdopodobniej odbiera błędną ramkę danych z pilota, nie ma w takim razie nowej instrukcji, więc wyzwala się przerwanie "time out" i robot staje. Po chwili już dochodzi poprawna ramka i jest polecenie poruszania się. Tak, jak mówi Chumnista pilot zmienia zadaną prędkość skokowo. Tu zacząłem trochę machać tym pilotem, co mogło się robotowi nie spodobać, a poza tym błędy w odebranych ramkach przy komunikacji na podczerwień są normalką i trzeba z tym żyć.

Rozumiem zasadność użycia operacji zmiennoprzecinkowych, ale strasznie razi to w oczy. Zawsze można posiłkować się operacjami stałoprzecinkowymi, które są dość proste i szybkie 😉

Taak. Rozumiem ten ból. Gcc jakoś tam wspiera arytmetykę stałopozycyjną, ale uC ma całe 10 milisekund na obliczenia, co daje przy aktualnej częstotliwości aż 120 000 taktów na obliczenia (od tego odjąć różne przerwania). Niech się drań nie nudzi i coś robi! Tak na poważnie to wynika to raczej z lenistwa i chwaląc się implementacją floatów raczej chciałem pokazać ile da się wycisnąć z ATmegi88P. Oczywiście pierwszy krok w optymalizacji kodu pójdzie właśnie w tym kierunku.

Czy rozważasz sterowanie poprzez np. telefon (dotyk lub pochylenie) zamiast pilota?

Moim marzeniem jest sterowanie poprzez przechylanie smartfona w kierunku w jakim robot ma jechać, ale już na starcie miałem problem z BLE, więc odłożyłem to na później. Muszę jeszcze się nauczyć porządnie kodzić na IOSa/Androida najpierw 😉

Poza tym chciałbym zrobić z tego robota istny gulasz, dać mu więcej czujników, jakąś orientację w otoczeniu. Dlatego właśnie rozbiłem elektronikę na 2 płytki i teraz mogę niedużym kosztem rozbudowywać moją platformę. Wiadomo, że wszyscy pasjonaci mają deficyty czasu na takie projekty, więc są to plany długoterminowe.

[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

[Marooned]

Dlaczego silniki krokowe a nie BLDC?

Klasyczne BLDC się nie nadają, nie są odpowiednie do małych prędkości. Trzeba by mieć przewinięte plus nowy soft dla ESC, jak to ma miejsce w gimbalach BLDC.

[Marooned]

Dziś sobie z córą krążę po Cyberbocie i w tłumie opuszczających salę główną rzucił mi się w oczy niebieski balanser na krokowcach. Żarówka się zapaliła. Bingo 🙂

Miło było poznać, głos poszedł 😉

[anton753159]

Bardzo fajna konstrukcja, swietna robota 🙂 Również oglądałem na Cyberbocie