II Forum Kół Naukowych – zaproszenie

Prorektor ds. studenckich UwB + Prorektor ds. kształcenia UwB zapraszają członków kół naukowych działających na UwB na e-spotkanie 7 czerwca 2021 r. o godz. 18:00 https://eu.bbcollab.com/collab/ui/session/guest/7412060f4b14424694e4a025219494f9

A co działo się w środę (który był czwartkiem?) – powolutku… był obowiązkowy Szeryf, była też naprawa zabawek, a generalnie Wojny Robotów zmierzają w dobrą stronę. Jest też coś nowego (tajemnicze „6050”) i zobaczymy, co z tego wyniknie 😉

(c) K.G. 2021

GARY – PAD „drewniak”

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? 😉

(c) K.G. 2021

Bezprzewodowo… Szeryf :P

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! 😉

(c) K.G. 2021

Zwyczajnie…

Pan Rafał coś tam dłubał przy pojeździe…

Pan Tomasz dostał zadanie zbadanie drugiego serwa i … coś się rozgadaliśmy, jakoś nie wyszło z tego za dużo dobrego.

Pan Bartek zastanawiał się z kolei nad skrzynką profili, silniczków otrzymanych od C.W. i się zastanawiał, co z tego może złożyć…

(c) K.G. 2021

Wojny robotów: sterowanie + prędkość serw

Wojny robotów

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:

Servo: 1200 Predkosc: 163.00
Servo: 1250 Predkosc: 160.00
Servo: 1300 Predkosc: 141.00
Servo: 1350 Predkosc: 124.00
Servo: 1400 Predkosc: 99.00
Servo: 1450 Predkosc: 8.00
Servo: 1500 Predkosc: 0.00
Servo: 1550 Predkosc: 87.00
Servo: 1600 Predkosc: 177.00
Servo: 1650 Predkosc: 134.00

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

No i powstała dygresja o gnuplocie… 😉

(c) K.G. 2021

2x BT master i slave + Maskotka + RGB

Wojny robotów:

Prace podzieliły się na dwa tory – niezależnie powstaje sterowanie, niezależnie poznawane są możliwości kolorowych LED-ów WS2812B. Dzięki takiemu podziałowi projekt brnie do przodu, choć przyznać trzeba, że powstanie tylko jedno sterowanie – bez konkurencji, więc… oby było dobre 😉

BT master

Pan Rafał postanowił wykorzystać dwa moduły Bluetooth (BT) aby komunikować się pomiędzy pojazdem a kontrolerem (bez czekania na wykorzystanie radiówek nRF24L – szkoda… ale do tego pewnie jeszcze wrócimy).

Pojazd (z lewej, moduł BT MASTER) oraz „kontroler” do sterowania (z prawej, BT SLAVE)

Dotychczas to telefon z aplikacją na Androida był MASTEREM (kontrolerem) łączącym się z pojazdem, czyli BT SLAV-em. Teraz jednak używamy dwóch BT w tym celu – choć przyznać trzeba, że prościej, efektywniej i taniej wydaje się zastosowanie wspomnianych na wstępie modułów nRF24L.

Kontroler ma podłączony moduł JOY-stica oraz moduł BT, który wysyła odczyty. Odbiorcą tych pakietów jest moduł BT w pojeżdzie, który łączy się z naszym kontrolerem. Aby to było możliwe należy MASTERA skonfigurować tak, aby po jego uruchomieniu „szukał” kontrolera i się z nim łączył. Realizuje się to przez tryb komend AT.

W tym celu podłączamy BT z dodatkowym pinem ustawionym na HIGH (poniżej pin #6 z Arduino, nazwany KEY, połączony z pinem STATUS w module XM-15B) i programikiem według poniższego schematu:

Wejście w tryb komend AT.

Jak widać program czyta bajty z portu szeregowego PC-ta i wysyła je do modułu BT podłączonego do Arduino (metody readString() oraz write()). Sprawdzamy, czy mamy wszystko poprawnie działające wywołując komendę AT+NAME. Powinna pojawić się nazwa naszego modułu (uwaga: nawet niepoprawnie wyświetlona) ORAZ nowa linia z napisem OK. Jeśli tak nie jest, trzeba sprawdzić podłączenia.

Moduł BT w trybie komend AT. Zwróć uwagę na znacznik końca linii: NL+CR.

Tryb komend AT umożliwia nam zmianę nazwy urządzenia BT, zmianę hasła czy innych parametrów komunikacji (np. szybkość transmisji szeregowej). Ale my wykorzystujemy go najpierw do odczytania numeru identyfikacyjnego urządzenia BT SLAVE – naszego kontrolera. Parowanie urządzeń BT odbywa się przez ten numer (a nie przez przyjazne nazwy, jak w Androidzie). Wydajeny komendę AT+ADDR i mamy odpowiedź: u nas 001135938823. Teraz wychodzimy z tryb AT dla kontrolera (BT SLAVE) i wgrywamy ten sam program na Arduino z BT MASTEREM.

Pojazd (BT MASTER) ma się łączyć z konkretnym modułem BT – znamy jego ID. Musimy więc najpierw ustawić go w tryb MASTER-a (komenda AT+ROLE zwróci 0 gdy moduł jest SLAVE-em, a 1 gdy MASTER-em; zmiana trybu odbywa się komendą AT+ROLE=1). Następnie zapisujemy adres kontrolera poleceniem AT+BIND=001135938823. Teraz można już wyłączyć program dla modułów BT pracujących w trybie AT i wgrać nasz własny programik na Arduino, które przez UART będzie odczytywać dane przesyłane przez kontroler modułami BT (oczywiście – jeśli włączymy pojazd, a kontroler nie będzie włączony – nie nastąpi komunikacja i pojazd nie będzie otrzymywać instrukcji sterująych).

Kto ma być MASTER, kto ma być SLAVE?

Pan Rafał zdecydował, że kontroler będzie SLAVE, a pojazd MASTEREM. Czy to dobrze? Można było by zrobić na odwrót… I takie właśnie rozwiązanie jest chyba lepsze, bo pojazd jako SLAVE czeka na dane wysyłane przez… dowolne sparowane urządznie! Może to być dedykowany kontroler (który właśnie tu powstaje) ale także jakaś apka na Androidzie – wówczas telefon jako MASTER może sterować naszym pojazdem. Takie rozwiązanie jest bardziej uniwersalne, więc pewnie w przyszłości będzie zastosowane.

Można też zajrzeć do opisu łączenia modułów BT master <-> slave na tej stronie – polecam.

WS2812B

Pan Tomasz postawił sobie zadanie płynnego przejścia kolorów: od niebieskiego do czerwonego w module WS2812B. Te dwa kolory mają być odpowiedzialne za wartości odczytanego pola magnetyczna magnesu. Zapis kolorów w systemie RGB nie jest tutaj najwygoniejszy, więc wybór padł na zastosowanie modelu HSV.

Model kolorów RGB. Przejście od czerwieni do niebieskiego to jednoczesna zmiana dwóch amplitud kolorów: R i B.
Model kolorów HSV. Droga od czerwieni do niebieskiego to zmiana jednego parametru – „kąta”, czyli wartości H.

Więcej…

Fajny link: https://www.arduinoslovakia.eu/blog/2018/4/neopixel-ring-hsv-test?lang=en

Maskotka – sterowanie.

Sam PID nie wystarczył. Moduł JOY-sticka ma mechaniczną „wadę”, że wychyla się góra/dół (lewo/prawo) mniej niż „pod kątem”. Maksymalne odczyty (1023 w przypadku Arduino UNO) otrzymuje się przy skrajnym wychyleniu w górę/prawo (dół/lewo) ale wychylając joy „po skosie” mamy (teoretycznie) o pierwiastek z dwóch więcej! Dlatego też to właśnie wychylenia „pod kątem” mają wartości 1023 a skrajne pionowe/poziome uzyskują te wartości jeszcze przed swoim maksymalnym wychyleniem – dalsze wychylanie nic już nie daje (mamy ciągle 1023 – zakres ruchu joya „zmarnowany”). Aby to zniwelować Pan Bartek znalazł ciekawe mapowanie kwadratu na kółko:

Odwzorowanie kwadratu na okrąg (kliknij obrazek aby przejść do źródła).

Taka modyfikacja sterowania pozytywnie wpłynęła na kontrolowanie Maskotki. Gratulacje!

Kolejne spotkanie: czwartek 6 maj 2021, godz. 15:15.

Wojny robotów („kanapka”) + problem: BT + serwo

Wojny robotów: problem – serwa i Bluetooth (BT)

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.

#include <Servo.h>
#include <SoftwareSerial.h>

SoftwareSerial bt(8, 9);//RxD, TxD
Servo 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.writeMicroseconds(1000); break;  //przod
      case 'S': silnik.writeMicroseconds(2000); break;  //tyl
      case 'X': silnik.writeMicroseconds(1500); break;  //stop
    }//switch
}

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.

Kolejne spotkanie: czwartek 15:00

Podcasty? Wojny robotów („kanapka”) + Maskotka

Podcasty?

Rusza Uniwersyteckie Centrum Podcastów „Na końcu świata” – nowa inicjatywa na naszym Uniwersytecie. Dostaliśmy propozycję prowadzenia takiej cyklicznej audycji. Tematyka w naszych rękach, ale z racji specjalności Fizyka gier komputerowych i robotów same narzucają się gry komputerowe, sprzęt komputerowy, sprzęt do programowania elektroniki oraz nowinki robotyczne/IT. Myślę, że w zależności od poruszanej kwestii może to być audycja 30-to minutowa (dłuższa temat do omówienia) ale także krótsza (15 min na „nowinki”). W kilka osób będzie łatwiej prowadzić takie audycje, więc zachęcam do zastanowienia się i zgłoszenia po Świętach.

Wojny robotów: „kanapka”.

Ulepszamy nasze konstrukcje, montujemy lepsze mocowania silniczków. Sporo pracy manualnej… ale projekt idzie do przodu!

W pracach nad drugą konstrukcją wykorzystaliśmy korek od wina – jest wytrzymały, świetnie się modeluje (przycina, docina) a także łączy i dzieli! Brawo Pan RŁ!

Prace trwają… ale już koniec tego etapu!

Maskotka

BB pracuje nad płytą główną do Maskotki – jest już moduł uporządkowujący przewody + integrujący moduł nRF24L. Fajnie!

Nowy moduł Pana Bartka – ten „zielony” shield 😉

Kolejne spotkanie: czwartek 15:00

Wojny robotów („kanapka”) + Maskotka

Wojny robotów: „kanapka”.

Budujemy drugie podwozie (ciągle w wersji v0.1) – chodzi o to, aby na Święta mieć dwa, a może nawet trzy egzemplarze pojazdów rozdysponowane po zainteresowanych Studentach. To powinno przyspieszyć pracę nad projektem 😉

W pracach nad drugą konstrukcją wykorzystaliśmy korek od wina – jest wytrzymały, świetnie się modeluje (przycina, docina) a także łączy i dzieli! Brawo Pan RŁ!

Drugie podwozie i niezastąpiony materiał „konstruktora amatora” – korek od wina 😉

Pan Tomasz w międzyczasie przypomniał sobie komunikację Bluetooth i wykorzystał nową apkę ze sklepu Androida – Arduino RC. Zaletą jest prostota i wystarczająca funkcjonalność!

Maskotka

BB pracuje nad płytą główną do Maskotki…

Kolejne spotkanie

Proponuję czwartek, godz. 11:00. Zapraszam!

Wojny robotów („kanapka”) + Maskotka

Wojny robotów: „kanapka”.

Budujemy podwozie v0.1.

Mieliśmy robić coś prowizorycznego, jednak do montażu kół wykorzystaliśmy przygotowane mocowanie – zaprojektowane i wydrukowane na Wydziałowej drukarce 3D Zoltrax M200. Prosty projekt w Blenderze:

Projekt „trzymaka” koła i silniczka: wykorzystujemy oryginalny orczyk z silniczka, który wtapia się w konstrukcję trzymaka. Trzy otwory 3mm, oddalone od środka o 10mm – pełna profeska 😉

Wydruk 2 sztuk to ~30min pracy drukarki. Efekt poniżej.

Koło Tamiya 70111 z „trzymakiem” – po co 3 śrubki, skoro i na 2 się trzyma? 😉

Napęd to dwa serwa pracy ciągłej – Feetech FT90R.

Serwo pracy ciągłej z zamocowanymi kołami.

Finalnie wszystko wygląda tak:

Kanapka v0.1: czyli pojazd w pełnej krasie 😉 Zasilanie (aku 9V) na polnym pokładzie. W planach kolejny pokład z programowalnymi LED-ami RGB.

Mocowanie silników do podwozia – chwilowo trtytkami. Jednak jest to NAJSŁABSZY element tej konstrukcji. Ale wydawał się wystarczający do sprawdzenia, jak działa.

Pierwsze próby autonomicznej jazdy!

Miało być szybko i minimalistycznie, jednak trzeba wrócić do mocowania silniczków – trytytki należy zmienić na „dedykowane” trzymaki do serw (ponownie projekt 3D i druk na Zoltraxie M200). Liczymy, że dzięki temu pojazd będzie jeździć prosto!

Maskotka

Pan Bartek wraca do projektu Maskotki i zamierza tam wgrać PID-a do lepszego sterowania kołami. Na razie odgrzebał projekt, połączył przewody (sfajczył jedno Arduino UNO – ale jak, tego nikt nie wie) no i projekt jeździ! Z braku swojego kontrolera wykombinował takie oto zabawnie wyglądające cudo 😉

Do sterowania podwoziem Maskotki wykorzystujemy… cztero-kołowy pojazd z JOY shieldem! Po prostu nie chciało się rozbierać/rozkręcać gotowej już konstrukcji…

Słychać ten „piękny” pisk podczas zakrętów? Oj słychać… ale jego źródło zostało już zlokalizowane! To nie silniki (jak nam się pierwotnie wydawało), a… trzecie koło! Będzie trzeba coś z tym zrobić.