Płytki PCP – frezowanie CNC

Dziś Pan Bartek testował wydziałową frezarkę CNC w zastosowaniu do przygotowania płytek PCB. Najpierw przygotował projekt pierwszej płytki w KiCad-dzie, który składa się z Arduino Nano + moduł nRF24L + LED + rezystor (polecamy filmik na YT z tutorialem jak pracować w KiCadzie). Dalej wczytał wyeksportowany plik do GRBL-u w Candle i podłączył frezarkę. Candle to fajny program, intuicyjny i pomimo dość skomplikowanie wyglądającego interfejsu – da się zrozumieć o co w nim chodzi. Jedyny minus to to, że jest 32-bitowy: dlatego uruchomiliśmy go pod Windowsem, który wspiera prehistoryczne aplikacje 🙂 W międzyczasie zająłem się wersją na Linuxa (na końcu wpisu wersja 64 bit do pobrania). Aby nie tracić czasu sterowanie frezarką odbywało się z Windowsa.

Kolorowa mapa wysokości płytki – próbkowanie 3×3 punkty.
LIVE podgląd podczas pracy frezarki – fajna sprawa!
Maszyna w działaniu – pierwszy projekt płytki PCB.

Konfiguracja frezarki polegała na poprawnym podłączeniu, zdefiniowaniu pozycji startowej (punkt 0,0, czyli „dom”), stworzenie mapy wysokości (skanowanie kierunku na osi Z). Chwilowo używamy dwustronnej taśmy przylepnej, niebawem będzie coś odpowiedniejszego.

Frezarka w trakcie pracy. UWAGA: ścisz swoje głośniczki!

Efekt końcowy po 30 minutach pracy (no i po wyczyszczeniu płytki z opiłków):

Pierwszy frez!

Ciągle jest jeszcze sporo pracy przed ostatecznym przygotowaniem płytki (np. wywiercenie otworów). Jak na razie cieszymy się, że wszystko zadziałało (nawet pomimo tymczasowego mocowania stołu i płytki – na taśmę dwustronną). Niestety, ścieżki są miejscami połączone, ale to wina a) mocowania stołu, b) luzach na głowicy frezującej lub c) złego zdefiniowania parametrów frezu w Candle. Projekt do poprawki, ale i tak jesteśmy zadowoleni 😉

Candle 64-bit

Jak wspomniałem na początku wpisu, z repozytorium githuba pobiera się archaiczną wersję 32-bitową (niezależnie czy Win czy Linux). Windows zawsze był przestarzały więc obsługę aplikacji 32-bitowych ma wszyte w system, pomimo faktu, że jest systemem operacyjnym 64-bitowym. Dla Linuxa (oczywiście 64-bitowego) musiałem zainstalować pakiet ia32-libs aby umożliwić działanie starych programów. Na szczęscie nie trzeba się męczyć w ten sposób. Można przekompilować źródła i mieć własną wersję 64-bit. Dla dystrybucji bazująych na Ubuntu (czyli np. Ubuntu, Mint) należy mieć zainstalowane biblioteki QT5 (patrz krok 0), pobrać źródła (krok 1), wykonać konfigurację i kompilację (krok 2) a potem pobrać wersję v1.1, rozpakować (krok 3) i podmienić plik wykonywalny 32-bitowy Candle na właśnie skompiowany plik 64-bitowy (krok 4). Poniżej kilka instrukcji z poszczególnymi krokami.

(krok 0 - biblioteki)
sudo apt install qt5-default qt5-qmake libqt5serialport5-dev
(krok 1 - źródła)
cd
git clone http://github.com/Denvi/Candle.git
Klonowanie do „Candle”...
warning: przekierowanie do https://github.com/Denvi/Candle.git/
remote: Enumerating objects: 5618, done.
remote: Counting objects: 100% (55/55), done.
remote: Compressing objects: 100% (37/37), done.
remote: Total 5618 (delta 29), reused 36 (delta 18), pack-reused 5563
Pobieranie obiektów: 100% (5618/5618), 35.47 MiB | 5.36 MiB/s, gotowe.
Rozwiązywanie delt: 100% (4166/4166), gotowe.
(krok 2 - konfiguracja) 
cd ~/Candle/src/
qmake
make
(krok 3 - binarki 32-bit) 
wget http://github.com/Denvi/Candle/releases/download/v1.1/Candle_1.1.7.tar.gz 
sudo tar -xf Candle_1.1.7.tar.gz -C /opt/
(krok 4 - podmiana na 64-bit) 
cd /opt/Candle
sudo mv Candle Candle.32bit.old
sudo cp ~/Candle/src/Candle .
(krop 5 - sprawdzenie)
file Candle
Candle:       ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=e1cb49635ed9370e88b3744ca76c0990403ad2b0, for GNU/Linux 3.2.0, not stripped

Dla leniwych wykonywalny Candle (wersja 64-bit) do pobrania tutaj (md5sum: dbcade0a80bc555d4ec3cbaba9105852).

(c) K.G. 2021

Projekty/koncepty/usprawnienia

Wakacje się kończą, ale to już nasze drugie spotkanie w trakcie wolnego czasu! Brawo dla uczestników. Dziś prace koncentrowały się wokół trzech tematów.

Tuning przeszła Maskotka, dostając czwarte koło (zapobieganie przewracaniu się przy nagłej zmianie kierunku ruchu), nie trzeba już kombinować z przeciwwagą 😉

Koło z przodu, dystans 3 mm z płyty pilśniowej (precyzyjnie wyciętej, co widać na zdjęciu).

Pan Bartek zaprezentował finalnie swój mini-pad, więcej na stronie projektu

Mini-pad autorstwa BB.

No i ciągle rozmawiamy o wojnach robotów. Najważniejsze, że nowe koncepty zostały zaakceptowane i wydają się obiecujące. Czas pokaże, co z tego wyjdzie.

Prace koncepcyjne – jak mają wyglądać walczące roboty?

(c) K.G. 2021

Wakacje

Sesja się zakończyła, nadszedł czas upragnionych wakacji… Wypoczynek? błogie lenistwo? a może praca nad projektem, na który w roku akademickim ciągle brakuje czasu? Jeśli są chętni do spotykania się w okresie wakacyjnym na uczelni – proszę o kontakt (ustalimy termin spotkań). Warto nie zmarnować tego czasu…

(c) K.G. 2021

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

Od pomysłu do wdrożenia

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.

(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

Łazik Perseverance i jego CPU

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.

RAD750.jpgProcesor 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.

 

(C) K. G. 2020