Wracamy do huśtawki z nowym podejściem – sterowaniem z wykorzystaniem PID-a. Niestety, konstrukcja mechaniczna uniemożliwiła poprawną pracę układu… trzeba ponownie popracować nad mocowaniem ramienia łączącego serwo z pierścieniem rury.
Warto przeczytać ten artykulik ze wprowadzeniem do PID-a:
Mamy Nowy Rok 2022 i pierwsze spotkanie Koła Fi-BOT. Fajnie, że studenci pracują pomimo przerwy świątecznej, bo wyniki są bardzo ciekawe!
Huśtawka w działaniu.
Pan Stanisław uparł się na dopracowaniu konstrukcji mechanicznej oraz oprogramowania. Sam nie wiem, co było bardziej marudne… Przypomnę na czym polega zabawa w huśtawkę – należy tak sterować położeniem rury (góra/dół – tym zajmuje się serwosilniczek), aby kulka znajdująca się wewnątrz znalazła się w środku rury. To dość znane zagadnienie, ale Pan Stanisław podszedł do tego niestandardowo – zastosował wzorki z fizyki dla zsuwającej się kulki z równi pochyłej (z uwzględnieniem jej obrotów, czyli mechanik bryły sztywnej). Nie ma tu żadnego PID-a, tylko czystka fizyka! Czy to działa? Działa! o dziwo – jak dla mnie – bo myślałem, że taki sposób spowoduje ciągłe bujanie piłki w lewo i w prawo. A tu proszę! Gratulacje! Ze względu na zbliżającą się sesję egzaminacyjną opis rozwiązania zostanie dodany gdzieś w miesiącu luty (po sesji).
W międzyczasie Pan Bartek kombinuje z produkcją płytek PCB na hobbystycznej frezarce CNC, a Pan Dominik wymyślił bardzo nieszablonowy sposób poruszania huśtawką (warto go zrealizować! choć będzie trzeba popracować mechanicznie).
Fajnie, że właśnie tak rozpoczął się Nowy Rok na Fi-BOTcie!
Poniedziałek to nie dzień spotkań koła, ale kto chętny – może! I tak Pan Stanisław postanowił wykorzystać okienko w swoich zajęciach i przystąpił do ulepszania konstrukcji…
Druga wersja huśtawki.
Konstrukcja „buja” się już mniej, pomimo zastąpienia trytytek sztywną wykałaczką 😉 Liczy się pomysłowość! Dalej są spore luzy, bo otwory w obejmie są za duże w stosunku do grubości wykałaczki. Wybór wykałaczki nie jest jednak przypadkowy – idealnie rozmiarami pasuje do otworów w metalowych (oryginalnych) profilach Maker Beama (podwieszenie w górnej części konstrukcji).
Na uwagę zasługuje pierwsza próba łączenia serwa z obejmą rury – wykorzystano gruby, małoplastyczny pręcik. Te dwie jego cechy są tutaj jego zaletami – tworzy on bowiem sztywne połączenie. Były problemy przy jego wyginaniu i przetykaniu przez otwory, ale co tam. Jest pierwsze podejście. Czy działa? Filmik poniżej:
Pierwsze próby sterowania serwem.
Działa to zdecydowanie gorzej niż się spodziewaliśmy 😛 Wszędzie te luzy! No i nogi (płozy?) zdecydowanie za krótkie (i za lekkie, trzeba dociążyć). W międzyczasie pojawił się Pan Bartek i zaproponował wymianę pianki (w mocowaniu serwa) na coś sztywniejszego… korek! Sam się zdziwiłem, że to Pan Bartek zaproponował! Wersja 2 i pół po lekkiej modyfikacji:
Wersja 2.5 huśtawki.
Jednak to niewiele pomogło… Pan Bartek skrzywił się tylko, spytał o średnicę rury i chyba postanowił przygotować nowy projekt w 3D aby przyspieszyć pracę nad projektem 😉 Zobaczymy!
Studenci dzielnie pracują nad projektem sterowanej huśtawki (samopoziomującej się). Schemat układu z poprzedniego tygodnia:
Układ: huśtawka (niebieska), kulka(różowa), silniczek (zielony), Arduino UNO (pomarańczowy).
A tera pierwsze próby jego wykonania „w realu”:
Pierwsza wersja huśtawki.
Jednak wszystko się „buja” 😛 Roboczo wykorzystane trytytki powodują duże luzy w obu osiach, a dalej niejasny jest sposób połączenia orczyka serwa z drugim pierścieniem obejmującym rurę. Coś tu trzeba wymyślić (wydrukować?).
Już wiemy, do czego zmierzamy w tym semestrze – będziemy stabilizować huśtawkę! Projekt bardzo ciekawy i w zasięgu ręki każdego początkującego hobbysty. O co chodzi? Na huśtawce poruszać się będzie kulka (różowa na rysunku poniżej), która zmieniając swoje położenie przechyli huśtawkę w inne położenie. Ale jest też silniczek (zielony), którym będzie sterować Arduino UNO (pomarańczowe) tak, by kulka nie wypadła z huśtawki i pozostawała w środku (położeniu równowagi).
Układ: huśtawka (niebieska), kulka(różowa), silniczek (zielony), Arduino UNO (pomarańczowy).
musimy określać położenie kulki na huśtawce – wykorzystamy poznany tydzień temu czujnik odległości HC-SR04
przechylanie huśtawki: mikroserwo powinno wystarczyć, ale jeśli okaże się za słabe – to mamy też serwa.
Huśtawka z pleksi rury.
Pan Stanisław tak się zaangażował w projekt, że zakupił już element konstrukcyjny huśtawki – rurę (ładna! długa: 50cm, ale gruba, bo ścianki 3mm, no i droga…). Pomysł fajny, ale czy czujnik odległości na końcu takiej rury będzie dobrze wskazywać pomiary odległości? W końcu emituje on dźwięki, które będą „buszować” w zamkniętej rurze i kolejne pomiary mogą być bezsensowne. Dlatego trzeba było to sprawdzić.
Testowanie czujnika w zamkniętej rurze – działa!
Na nasze szczęście okazało się, że (o dziwo!) czujnik działa poprawnie! Sprawdziliśmy to z wykorzystaniem metrówek.
Silniczek – a dokładniej mikro serwo.
Proponuję wykorzystać mikro serwo do poruszania ramieniem huśtawki. Jest to silnik sterowany sygnałem PWM, który możemy ustawić w określonej pozycji: od 0 (zera) do 180 stopni. Do obracającego się orczyka przyczepimy element łączący go z ramieniem huśtawki.
Podłączenie: czarny przewód to GND, czerwony to zasilanie (5V), a pomarańczowy – sterowanie. Obrazek z https://www.makerguides.com/servo-arduino-tutorial/ (polecam zajrzeć).
W tym konkretnym przypadku możemy podłączyć zasilanie serwa bezpośrednio do płytki Arduino UNO, bo pojedyncze serwo pożera jedynie ~200mA prądu (nie możemy przekraczać 500mA, bo uszkodzimy Arduino lub podłączonego z nim kompa – a tego nie chcemy).
Programowanie polega na użyciu biblioteki Servo.h i znajdującego się w niej obiektu Servo. Tworzymy zmienną (u nas silnik) i przypisujemy jej sterowanie do pinu 9 – metoda attach(). Następnie ustawiamy ramię silnika na określoną pozycję – tutaj 5, 90 i 175 stopni – za pomocą metody write(). Celowo pomijam skrajne wartości 0 i 180 stopni, bo to nadwyręża serwa.
Zwracam także uwagę, że po ustawieniu serwa na konkretną wartość należy dać mu czas na realizację tego polecenia – serwa działają powoli! Nasze MG90S obraca się o 60 stopni w 0,1 sekundy – dlatego 2s opóźnienie przed kolejnym ustawieniem to rozsądna wartość.
Budowa konstrukcji.
I tu zaczynają się schody… Trzeba się trochę pobrudzić 😉 Może sklejka lub podobny, miękki materiał – łatwy do obróbki bez zaawansowanego osprzętu? A może wspomniane profile Maker Beam?
Tymczasowe dwie kolumny z osią pomiędzy, do której przyczepiona jest połowa trzymaka do rury.
Jeszcze zobaczymy co zrobimy, ale najpierw trzeba przemyśleć połączenie silniczka z ramieniem huśtawki. Są różne koncepcje. Poniżej wynik prac przy tablicy….
Burza mózgów – schematy połączenia silnika z ramieniem huśtawki.
Trzymak do rury.
Aby złapać rurę (huśtawkę) i przytwierdzić ją do stabilnej konstrukcji – trzeba mieć odpowiedni uchwyt. Pewnie można poszukać w jakimś popularnym sklepie z materiałami budowlanymi, ale postanowiłem lekko pomóc i zaprojektowałem na szybko taki uchwyt – poniżej zdjęcie jego połówki, bo właśnie dwie takie części tworzą całość. Uchwyt ma sporo nadmiarowych „uniwersalnych” otworów – tak na przyszłość, aby nie tylko pełnił funkcję trzymania rury i obracania jej, ale i mechanizmu połączenia z silniczkiem… Powinno się przydać.
3D model trzymaka – uchwytu (jedna połowa, druga identyczna zamyka całość).
Wydrukowany trzymak w testach – na drewnianej prowadnicy/wierzy.
Jak widać sporo się działo… a to dopiero początek tego projektu 😉
Pan Rafał kontynuuje prace nad Wojnami Robotów. Po udoskonaleniu sterowania kołami zrobił kontroler z płyt pilśniowych i korków do wina – powstał PAD drewniak o nazwie GARY.
GARY – PAD „drewniak”.
Jak się okazuje, ulepszone sterowanie + PAD umożliwiają działanie pojazdu jako… Line Follower 😉 Więcej na stronie projektu.
Ręcznie sterowany Line Follower??? Czego to ludzie nie wymyślą…
Serwa
Pan Tomasz zbadał kolejne serwa. Poniżej wyniki:
Cztery nowe serwa (jedna „partia”, a nie losowe z roku czy dwóch) a jakie rozrzuty! Widać, że
obroty w lewo != prawo
…
…
…
Szeryf v0.2
No i mamy nową, świecką tradycję – wchodząc na zajęcia MUSISZ OBOWIĄZKOWO zagrać w Szeryfa 😉 Nowa wersja (v0.2) nie powaliła moich beta-testerów na kolana, trzeba więc dalej pracować, udoskonalać…
Szeryf v0.2 w (obowiązkowym) działaniu – na zdjęciu zwycięzca starcia #2.
A punktacja (czasami dwie rozgrywki, pokazujące progress) : RŁ: 3819, TK: 1337, 3225, P: 0, BB: 799, 1371. Pan Paweł nie ustrzelił wszystkich 4 rzutek jednym magazynkiem (7 pocisków) i dlatego zero punktów – dość deprymujące, muszę to zmienić. Ponownie wygrał Pan Rafał! przypadek? czy mamy w grupie prawdziwego Szeryfa? 😉
Pan Rafał chciał zaprezentować działanie swojego pojazdu i… bateria się skończył! OK, od czego mamy drugą? Oj, druga też! A to pech. Więc może pożyczyć od kolegi? Tomasz nie wygląda na skąpca 😉 No jasne, te dwie (rozładowane) to już dawno pożyczone od P. Tomasza. Zaraza…
XXI wiek – bezprzewodowy pojazd, na kablu! Zwróć uwagę na „mały” pakiecik zasilający ;-D
I w ten oto sposób mamy testowanie bezprzewodowego pojazdu na… kablu zasilającym! Pięknie! XXI wiek 😛
Pan Tomasz zbadał drugie serwo. Wyniki niebawem, tylko dodam mu jeszcze 4 kolejne serwa 😉
Szeryf v0.1
Na tych krótkich zajęciach (z przyczyn osobistych) ZMUSIŁEM studentów do zagrania (przetestowania) moją grę – Szeryf v0.1. Gra powstała w processingu i miała za zadanie przetestować możliwość precyzyjnego sterowania modułem JOY-a w czasie rzeczywistym.
Moduł JOY-a – „rewolwer” Szeryfa.
Precyzyjnym obiektem był CELOWNIK (kolor fioletowy) i należało nakierować go na poruszający się (ruchy Browna) obiekt RZUTKA (kolor biały). Strzela się wciskając przycisk w module JOY-a (każdy wie, że podczas strzału lekko zmienia się pozycja modułu) . Gracz jest więc Szeryfem i ma do dyspozycji 6 pocisków (piękna grafika w lewym-górnym rogu) i strzela na rzutek. Zdobywa punkty jeśli trafi, a wartość nagrody jest iloczynem prędkości rzutki i odległości od środka tarczy (to zmusza gracza do ucieczki od bezpiecznej pozycji w środku i „sępienia się” na nadlatującą RZUTKĘ).
Gra Szeryf: 2 pociski wystrzelone, w bębenku są jeszcze 4.
Nie trzeba dodawać, że nikt nie chciał grać w moją grę 😛 Scenariusz słaby? Wszyscy lubią ratować Księżniczki lub biegać po Skelige z dwoma mieczami na plecach? A może to z grafiką coś nie tak? Chyba nie chodziło też o kwestię utrudnionego sterowania, bo ruch góra/dół w module JOY-a był faktycznie ruchem CELOWNIKA góra/dół, natomiast lewo/prawo było odwrócone – i CELOWNIK poruszał się prawo/lewo. Po pierwszej zmianie „na gorąco” dalej nie było entuzjazmu w mojej pseudo-rozrywce. Dlatego bez ceregieli wykorzystałem swój status na uczelni i przymusiłem uczestników Fi-BOTa do rozgrywki. W ten sposób pozyskałem darmowych beta-testerów 😉
Studenci okazali się niezłymi Szeryfami! Wygrał Pan Rafał, który zdobył ponad 122k punktów! Brawo!
Player name: BB
Player name: T
Player name: R
Plan rozbudowy Szeryfa (pomysły z „rękawa”):
level 0: RZUTKA nie porusza się, a pojawia się (losowa pozycja) na ustalony czas by potem zniknąć; im szybciej zestrzelisz rzutkę, tym więcej punktów; (C) BB
level 1: RZUTKA porusza się ruchami Browna (to już jest)
uwzględnić czas gry: wynik końcowy punktów podzielić przez czas? szybszy Szeryf to lepszy Szeryf!
level 3: więcej RZUTEK? niby dlaczego tylko jedna…
level 4: Szeryf dwuręczny: jeden moduł JOY-a jest mało irytujący? dwa takie to już istny obłęd!
zamiast irytujących modułów JOY-a przyklejone żyroskopy/akceleratory do rąk i sterowanie bezprzewodowe? Kto wie, kto wie 😉
Chyba wprowadzę zasadę na kolejnych Fi-BOTach, że wchodząc na zajęcia MUSISZ OBOWIĄZKOWO zagrać w Szeryfa. To w nawiązaniu do klasyka i obowiązkowej kawy + WZ-etki. Ja natomiast nie staram się o trofeum Złotej Patelni a z dopracowanym produktem lecę prosto do Steama/GOGa/Epica i sukces! i chwała! kasa i uwielbienie! 😉
Pan Rafał przygotowuje drugi pojazd do pracy + coś tam programuje ze sterowaniem… Pewnie w następnym tygodniu zobaczymy efekty tej pracy. Porównamy też sklepowe koła z naszymi – wydrukowanymi w 3D.
Prędkość serw
Pan Tomasz wykorzystał swój układ mierzący liczbę obrotów na minutę do zbadania zależności zmiany tej prędkości od wypełnienia sygnału sterującego serwem. Serwem pracy ciągłej sterujemy podając sygnał PWM z wypełnieniem z przedziału 1000-2000 us (metoda writeMicroseconds() z klasy Servo), gdzie wartość 1500 us odpowiada zatrzymaniu serwa, a wartości 1500-2000 przekładają się na coraz szybsze obroty serwa w jedną stronę (1500-1000 us w przypadku obrotów w przeciwną stronę). Tyle teorii. A praktyka?
No właśnie – serwo serwu nie równe, a tanie serwa dlatego są właśnie tanie, bo nie trzymają się ściśle tym teoretycznym wymogom. Okazuje się, że pozycja STOP jest „gdzieś w okolicy” sygnału 1500. Obroty w prawo i w lewo też nie są równe – pomimo równego odejścia od pozycji STOP. Na poniższym wykresie widać, że odejście wypełnieniem PWM o 100 us skutkuje prędkością 117 rmp (wartość 1600 us) oraz 99 rpm (wartość 1400 us). Wykres nie jest idealnie symetryczny względem osi x=1500.
Wyniki pomiarów pierwszego przebiegu testu prękości. Pomiar trwa 1s a sygnał PWM zmienia wypełnienie co 50 us.
Oczywiście jeden pomiar to za mało, więc procedura została powtórzona dla kolejnych przebiegów, a wyniki zapisane w kolejnych plikach tekstowych. Wniosek – rezultaty są powtarzalne.
Kolejne pomiary tego samego serwa – wyniki są całkiem powtarzalne.
Mając więcej pomiarów, można policzyć odchylenie standardowe i dodać słupki błędów… ale nie przesadzajmy 😉 Dla pewności pomiarów jeden raz dwukrotnie zwiększyliśmy czas zliczania prędkości (czyli dla każdej wartości wypełnienia czekamy 2s i zliczamy impulsy) – wyniki są zgodne.
Poprzednie pomiary plus nowa seria – pomiar 2s dla każdego wypełnienia.
Wnioski: 1) prędkość nie rośnie liniowo ze zmianą wypełnienia sygnału sterującego, 2) STOP dla serwa jest „gdzieś” w okolicach 1500 us, ale drobna zmiana sygnału może już poruszyć serwo w jednym kierunku, podczas gdy ta sama wartość wypełnienia nie wystarczy by ruszyć serwo w przeciwnym kierunku, 3) prędkość nasyca się około ~200 us wartości skrajnych (1000-1200 us -> prawie jedna wartość prędkości, tak samo jak 1800-2000 us), 4) ruch w lewo i prawo nie jest symetryczny.
Dalsze prace: Można kontynuować sprawę testowania serw, poddając tym samym próbom inny egzemplarz tego samego serwa – aby przekonać się, czy widoczne tu zachowanie jest typowe dla każdego serwa, czy jednak trafiło się nam wyjątkowy egzemplarz a inne są inne.
gnuplot
Do stworzenia wykresów „na szybko” wykorzystałem program gnuplot – świetny w takich sytuacjach (wykresy na szybko, dane z numeryki, dane z Arduino). „Surowe” dane wypisywane w oknie Monitora porta szeregowego wyglądały następująco:
Wystarczy przekopiować te dane do pliku tekstowego (np. serwo.txt) a następnie uruchomić gnuplot i wydać polecenie wykresu danych z pliku:
plot 'serwo.txt’ using 2:4
Polecenie to każe wykorzystać plik 'serwo.txt’ oraz kolumnę 2 dla x-ów, kolumnę 4 dla wartości y-ków. Jak widać nie trzeba kopiować danych do arkusza kalkulacyjnego, usuwać niepotrzebne napisy (tutaj: „Servo:”, „Predkosc:”) czy też tworzyć wykres z zaznaczonych tam komórek. Wystarczy posłużyć się prostą komendą plot podając kolumny do wykorzystania (dyrektywa using).
gnuplot w akcji – druga widoczna komenda rysuje dwie krzywe (z dwóch plików) jednocześnie na jednym wykresie.
Gnuplot ma bardzo dużo możliwości – ale tutaj wspomnę tylko o słupkach błędów – gdyby były gdzieś w pliku, np. w siódmej kolumnie, to by wystarczyło wpisać następujące polecenie do ich wyświetlenia:
plot 'serwo2.txt’ using 2:4:7 with yerror
ale cóż – my nie mamy siódmej kolumny… zamiast tego niech wykreślone będą 10% błędy, czyli ponownie wykorzystamy czwartą kolumnę, dzieląc ją przez 10:
plot 'serwo2.txt’ using 2:4:($4/10) with yerror
gnuplot ze słupkami błędów na osi y (with yerror). Komenda plot 'serwo2.txt’ using 2:4:($4/10) with yerror
A może słupki na osi x i y? czemu nie!
plot 'serwo2.txt’ using 2:4:($2/50):($4/10) with xyerror
Pan Rafał oprogramowywał sterowanie swojej „kanapki” z wykorzystaniem modułu BT. Nie jest to może najlepsze rozwiązanie sterowania, ale szybkie i bezproblemowe (jasne, jasne – czytaj dalej). Proste, po włączamy dwie standardowe biblioteki Servo.h oraz SoftwareSerial.h i piszemy prosty kod.
A tu klops! Ilekroć przesyłane są dane przez moduł BT, to serwa „wariują”, zachowują się zupełnie nieoczekiwanie. Można to sprawdzić powyższym kodem gdzie przesyłamy 'W’ przez Bluetooth i silnik kręci się na maksa do przodu, a następnie wysyłamy z apki kolejne, nic nie znaczące znaczki (wciskamy inne, zdefiniowane przyciski, np. 'A’, 'D’ itd). Te komendy powinny zostać zignorowane (brak odpowiednich instrukcji w switch-u), a serwo powinno utrzymywać swój dotychczasowy ruch. Tak się jednak nie dzieje…
Jak zawsze najpierw należało sprawdzić przewody połączeniowe, ale to nie one okazały się przyczyną problemów. Grzebanie w internecie okazało się sukcesem – biblioteka SoftwareSerial.h korzysta z tego samego układu czasowego (timera) w Artudino co biblioteka Servo.h, do sterowania PWM. Chodzi o to, ze Arduino (a dokładniej ATmega 328P) posiada trzy niezależne timery: dwa 8-bitowe oraz jeden 16-to bitowy. Właśnie z tego ostatniego korzystają dwie wspomniane biblioteki i powstaje konflikt!
Rozwiązaniem może być alternatywna biblioteka do obsłui serw: ServoTimer2. Już sama nazwa wskazuje, że korzysta ona z drugiego timera – nie powinno być więc konfliktu z SoftwareSerial.h. Lekko zamieniamy kod programiku i sprawdzamy zachowanie serw podczas przesyłania danych z BT. Klops: jednak nie pomogło.
Jeśli nie biblioteka serw, to szukamy zamiennika do drugiej biblioteki – komunikacji szeregowej. Tutaj trafiamy na AltSoftSerial i nasze nadzieje nie gasną 😉 Ponownie modyfikujemy kod (uwaga: pinami do komunikacji są „na sztywno” pin 9 oraz 10 – nie ma możliwości wyboru, jak w przypadku biblioteki SoftwareSerial.h).
Nie poddajemy się i stosujemy dwa zamienniki bibliotek jednocześnie – bum! mamy to! działa!
#include <ServoTimer2.h>
#include <AltSoftSerial.h>
AltSoftSerial bt;//Arduino UNO -> RxD=9, TxD=10, nie ma wyboru!
ServoTimer2 silnik;
void setup() {
Serial.begin(9600);
bt.begin(9600);
silnik.attach(3);
Serial.println("start!");
}
void loop() {
if (bt.available()){
char komenda=bt.readString());
Serial.print("odebrano= ");
Serial.println(komenda);//dla sprawdzenia
switch (komenda){
case 'W': silnik.write(1000); break; //przod
case 'S': silnik.write(2000); break; //tyl
case 'X': silnik.write(1500); break; //stop
}//switch
}
Niewielkie zmiany, ale istotne. Warto zwrócić uwagę, że funkcja write() dla obiekty ServoTimer2 zapisuje mikrosekundy wypełnienia, czyli dokładnie to co robi funkcja writeMicroseconds() z obiekty Servo (biblioteka Servo.h), co jest trochę mylące. Wystarczy mieć to na uwadze i będzie OK.
Jeszcze jedno: wspomniany problem nie występuje na starszych wersjach środowiska i bibliotek Arduino IDE. Warto sprawdzić.
Wojny robotów: trzecia „kanapka” i korki (przymyślenia).
Pan Kacper buduje trzeci pojazd „kanapka”. Mamy nowe, trochę zmodyfikowane tymczasowe koła – choć drukarka 3D pracuje powoli, to i tak trzeba się natrudzić przy składaniu całej konstrukcji (jakieś 3h?).
Trzeci pojazd. Nowe koła. Ba(k)teria na ścisk!
Myślałem, że wykorzystanie korków od wina jest oryginalne – a tu się okazało, że takie zabiegi były znane i (zapewne) stosowane przynajmniej od roku 1200+. Źródła historyczne donoszą, że prawdziwy podróżnik awanturnik na szlaku musiał posiadać zestaw korków – pewnie w celach majsterkowania, bo po cóż innego miał on je w swoim ekwipunku?
Ekwipunek Geralta: korki to podstawa! Witcher 3, CDPR
Wojny robotów: szybkość obrotowa (RPM) silczka
Pan Tomasz z kolei zawziął się na zbadaniu prędkości obrotej kół (RPM = Revolutions Per Minute). Prosty układ pomiarowy (tymczasowy) pozwolił mu zmierzyć tą prędkość. Układ składa się z potencjometru do sterowania prędkością serwa Feetech FT90R (z prawej strony), oraz czujki szczelinowej (umieszczonej na – oczywiście – korku do wina) wraz z przymocowanym kołem zębatym (druk 3D).
Pomiar prędkości obrotowej serwa.
Pan Tomasz wykorzystał przerwania z Arduino UNO (a dokładniej jedno, ze zboczem narastającym). cdn…
Maskotka
BB zakończył prace nad płytą główną do Maskotki – aktualnie przygotowywane jest lepsze sterowanie prędkością kół – kontroler PID.