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? 😉
Uczymy się programowania elektroniki powielając ciekawe projekty, czasami dodajemy coś swojego. Przychodzi jednak taki czas, że w głowie zaświta nam „świetny pomysł” i go realizujemy. Mamy więc pomysł i produkt. Ale to tylko wycinek z cyklu życia projektu (Pomysł -> Analiza rynku -> Projektowanie -> Walidacja -> Wdrożenie -> Utrzymanie/serwis -> Zakończenie wsparcia). A potem? O tym, jak się komercjalizuje udane projekty można przeczytać w marcowym wydaniu Elektroniki Praktycznej (3/2021) w artykule Od pomysłu do wdrożenia. Jest to lektura obowiązkowa dla osób projektujących rozwiązania elektroniczne.
Dodatkowo polecam też artykuł o profesjonalnym podejściu do tematu okiem dużej firmy: Prototypowanie – jak to wygląda w praktyce?
Polecam i zachęcam do wizyty w uczelnianej czytelni.
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
Ciekawe rzeczy dzieją się ostatnio na Marsie – mówię o próbach lotniczych drona z najnowszej misji Amerykańców. Ale warto wrócić do samego łazika i zapoznać się ze specyfikacją jego jednostki centralnej. Okazuje się, że wybór padł na RAD750 z architerkturą PowerPC 750 (RISC), który zadebiutował w roku 1998! Staruszek! Ma już ponad dwie dekady i faktycznie parametrami nie znokautuje współczesnych CPU.
Procesor taktowany jest zegarem 200 MHz, do dyspozycji ma 2GB pamięci FLASH i 256 MB RAM (więcej o nim w linku klikając powyższe zdjęcie z Wikipedii). Dlaczego właśnie taki procek? O tym można przeczytać w marcowym wydaniu Elektroniki Praktycznej (3/2021) w artykule Rad-hard już na pierwszych stronach czasopisma! Polecam i zachęcam do wizyty w uczelnianej czytelni.
