Sztef

Silniki krokowe są rzeczywiście fajne, bo nie mają luzów i sterowanie nimi to czysta przyjemność (zwłaszcza jak masz jakiś gotowy sterownik), ale nie osiągają wysokich prędkości, więc łatwiej jest robota przewrócić. Zawsze można poszukać silników z mniejszymi luzami... Ja w swoim robocie miałem praktycznie to samo, ale się poddałem i uznałem, że lepiej żeby ładnie stał, niż dobrze jeździł 😉 Teraz pracuję nad nową wersją, gdzie postaram się być bardziej bezwzględny.

Ładnie dostrojony – gratuluję, bo to jest chyba najmniej wdzięczne w całym takim robocie 😉 Masz może jakieś filmiki gdzie jeździ po równi pochyłej? Czy radzi sobie kiedy drastycznie mu zmienisz środek ciężkości? Na przykład postawisz coś na nim, ale nie na środku, albo coś doczepisz jak ktoś na tym filmie:

Piękne wykonanie! Gratulacje! Z jakiego materiału jest konstrukcja?

Najpierw dzięki za miłe słowa 🙂 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. "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ć. 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. 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.

Robot balansujący. Wykorzystuje żyroskop i akcelerometr, sterowany pilotem od telewizora. Mikrokontroler Atmega88p, konstrukcja wydrukowana z PLA, napęd – silniki krokowe. link: https://www.forbot.pl/forum/topics7/inny-robot-balansujacy-sterowany-pilotem-tv-vt12349.htm

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.