Latem 2019 roku podjęto decyzję o udziale naszej firmy w jesiennych Targach Pracy AGH. Miał to być powrót JPEmbedded do budynku A0 po rocznej przerwie. W związku z tym, pojawiła się motywacja do przygotowania nowej maszyny-atrakcji. Czegoś, co przyciągnie uwagę odwiedzających i pokaże, że na co dzień robimy ciekawe rzeczy z oprogramowaniem i elektroniką. 😉

Poprzednia atrakcja, czyli zdalnie sterowany dźwig-zabawka, służył nam długo i dzielnie, ale zdążył się już znudzić wszystkim zaangażowanym. Dalsze rozwijanie konstrukcji zostało więc jednogłośnie odrzucone. Pojawiły się nawet głosy, że dźwig należy jak najszybciej zniszczyć, aby w ten sposób umożliwić, rozwój nowego pomysłu – na wypadek pojawienia się tzw. niedoczasu i perspektywy „odgrzewania starego kotleta”.

 

Pomysł

Podobnie jak w przypadku emerytowanego dźwigu, z pełną zgodnością podjęliśmy decyzję, że nowa atrakcja będzie czymś interaktywnym i namacalnym. Zależało nam na tym, by na stanowisku wystawienniczym działo się coś więcej, niż tylko wyświetlanie slajdów na ekranie telewizora lub tabletu. Za szczególnie pożądany uznaliśmy, więc element współzawodnictwa.

Pierwszą burzę mózgów zorganizowaliśmy, gdy do targów było jeszcze bardzo dużo czasu, a chętnych do wymyślenia koncepcji projektu tak wielu, że trudno było się pomieścić w naszej sali konferencyjnej. Czas ten zaczął się kurczyć, gdy kolejne spotkania nie przyniosły żadnego pomysłu, który zyskałby poparcie większości. Nie pozostało nam nic innego, jak sprowadzenie dyskusji na ziemię, tak  żeby ograniczyć ryzyko, że projekt minie się z terminem. Efektem czego zostały wprowadzone następujące zasady:

• projekt będzie się opierał na narzędziach i podzespołach, które mamy/wykorzystujemy w firmie;
• do rozwijania i implementacji projektu zostaną, zaangażowane osoby, które na co dzień pracują z wybranymi urządzeniami;
• dodatkowe elementy mechaniczne, które musimy skonstruować samodzielnie, powinny być najprostsze jak to możliwe;

Spośród wielu elektrośmieci zalegających nasze biurka, najbardziej obiecującą wydawała się niewielka maszyna CNC, która kiedyś pełniła rolę mechanicznego palca w zautomatyzowanych testach urządzeń HMI. W połączeniu z kamerą i mikrokomputerem sterującym, taki zestaw mógłby wykrywać ruchy wykonywane przez człowieka i odpowiadać odpowiednimi manewrami maszyny.

 

Szybko pojawiła się koncepcja gry planszowej, w której człowiek i robot na zmianę wykonują ruchy na nieruchomej planszy obserwowanej przez kamerę. Do realizacji wybrano grę zwaną potocznie „czwórki” (znaną jako: connect4, cztery w rzędzie), ze względu na wiele korzystnych cech:

• proste do zrozumienia zasady rozgrywki;
• optymalny poziom trudności;
• pojedyncza rozgrywka trwa tylko kilka minut;
• nie wymaga przesuwania pionków, wystarczy tylko umieścić znak na planszy;
• planszę może stanowić zwykła kartka w kratkę.

Zaakceptowany projekt dostał nazwę roboczą: „Słoneczko i łapka”. Nadszedł czas na stworzenie specyfikacji i podział prac.

Design

Maszyna CNC, którą mieliśmy do dyspozycji posiadała niewielkie rozmiary pozwalające na umiejscowienie jej na ladzie wystawienniczej. Projekt zakładał, że w obszarze roboczym urządzenia zostanie przymocowana maskownica trzymająca planszę (zwykła kartka A4) w polu widzenia kamery.

Do śledzenia wykonywanych w grze ruchów została użyta monochromatyczna kamera przemysłowa z interfejsem Ethernet. Przygotowano również wysięgnik, pozwalający na umieszczenie kamery nieruchomo nad obszarem rozgrywki. Jako narzędzie do oznaczania ruchów wybrano prosty stempel nasączony tuszem. Odbijanie stempla jest dla robota znacznie szybsze niż rysowanie, dzięki czemu mogliśmy skrócić czas rozgrywki. W tym celu zakupiony został zestaw stempli dla dzieci w popularnym sklepie z meblami i klopsikami.

Maszyna CNC posiadała sterownik napisany przez jednego z naszych specjalistów na potrzeby wcześniejszego projektu (mechaniczny palec). Sterownik ten przyjmował polecenia przez interfejs szeregowy. Przez wykorzystanie prostego adaptera RS232-USB można było go podpiąć do Raspberry Pi, które posłużyło za mózg całego urządzenia, komunikując się z robotem i kamerą oraz wyświetlając komunikaty dla użytkownika na 7. calowym wyświetlaczu.

Podział prac w zespole nie był trudnym zadaniem, ponieważ projekt intuicyjnie dzielił się na kilka części składowych:

• elementy mechaniczne
  • mocowanie planszy i kamery;
  • mechanizm stempla;
• oprogramowanie Raspberry Pi:
  • kontroler robota;
  • analizator obrazu;
  • menadżer rozgrywki;
  • menadżer wyświetlania;
  • task główny.

Specyfikacja dla komponentów oprogramowania została szybko nakreślona, dzięki czemu zespoły ochotników mogły od razu, niezależnie, zacząć pracę nad swoimi częściami w projekcie. 😉

Zdecydowano, że oprogramowanie powstanie w języku Python.

Implementacja

Gra w czwórki wykonywana jest na planszy podzielonej na prostokątne pola: siedem kolumn i sześć rzędów. Gracze na zmianę wykonują ruchy, polegające na stawianiu swojego znaku na jednym z wolnych pól. Na planszy obowiązuje zasada grawitacji, co oznacza, że dla danej kolumny, można umieścić znak tylko w najniższym niezajętym rzędzie – jakby znaki spadały do „podstawy” planszy. Wygrywa gracz, który jako pierwszy ułoży linię składającą się z czterech swoich znaków w pionie, poziomie lub po skosie.

Czwórki zostały rozwiązane matematycznie już dawno temu. Oznacza to że, istnieje idealny algorytm gwarantujący wygraną gracza, który zaczyna, jako pierwszy. Jego działanie opiera się na analizie postawionych ruchów i liczeniu pustych miejsc. Brute-force nie jest praktycznym rozwiązaniem dla tej gry ze względu na ilość możliwych kombinacji.

W przypadku projektu na Targi Pracy nie zależało nam na tworzeniu idealnego gracza, wręcz przeciwnie chcieliśmy aby człowiek, który nie jest ekspertem w tej grze, również miał szansę na wygraną. Z tego powodu dostał on przywilej pierwszego ruchu, a AI było bardzo krótkowzroczne. Trudność gry badano poprzez rozpowszechnienie okienkowej wersji programu wśród wszystkich pracowników firmy.

Jednym z najbardziej krytycznych komponentów projektu jest analizator obrazu. Wprowadza on element niepewności, gdyż zmieniające się warunki np. oświetlenie, cień, brud na planszy itp. mogą wprowadzić program w błąd i skutkować przedwczesnym zakończeniem rozgrywki oraz niezadowoleniem gracza. Aby uniknąć takiej sytuacji, koniecznym było dokładne przetestowanie działania analizatora.

Do przeprowadzania operacji na obrazie wykorzystano bibliotekę OpenCV. Testowano różne warianty algorytmu. Podstawowym krokiem analizy było rozpoznanie planszy jako całości: tj. 42 prostokątnych pól. Jest to kluczowe, ponieważ program musi samodzielnie „zobaczyć” kiedy człowiek zakończył wykonywanie swojego ruchu – dopiero wtedy komputer będzie mógł rozpocząć swoją turę. Kryterium, które pozwala stwierdzić, że człowiek wykonał ruch to: (1) ręka lub inny obiekt przestała zakrywać planszę i kamera widzi wszystkie 42 pola; (2) ilość zajętych pól na planszy zmieniła się względem poprzedniego efektu sprawdzania.

Dzięki temu, że gracze umieszczają znaki na zmianę, a na daną turę przysługuje im dokładnie po jednym odbiciu stempla, program wie z kontekstu, jaki znak pojawił się na planszy.

Analizator obrazu nie musi nawet rozróżnić znaku człowieka od znaku komputera – wystarczy, aby zwrócił informację o tym, które pola planszy są w danym momencie zajęte. Oczywiście, AI musi sprawdzić, czy w trakcie trwania tury nie przybyło zbyt wiele znaków, co oznaczałoby, że przeciwnik oszukuje.

Sterowanie robotem nie przysparzało większych trudności. Sterownik maszyny przyjmował współrzędne w milimetrach. Wystarczyło tylko wykonać autokalibrację przed pierwszą grą i robot wykonywał ruchy w sposób powtarzalny i skuteczny. Po stronie Raspberry Pi kod ograniczał się więc do przeliczenia pozycji na planszy na pozycję rzeczywistą i wysłanie odpowiedniej komendy przez port szeregowy. Zespół odpowiedzialny za robota miał, więc dużo wolnego czasu na wymyślenie dodatkowych funkcjonalności.

Przykładowo, zostało dodane automatyczne zakładanie zatyczki na stempel po zakończonej grze, aby  zapobiec jego wysychaniu. Wisienką na torcie było jednak coś o wiele bardziej ekscytującego.

Maszyny CNC znane są z tego, że ich silniki krokowe wydają różne żałośnie brzmiące dźwięki. Zasada działania wymaga dokładnego sterowania pracą silnika. Ton dźwięku wydawanego przez silnik jest zależny od jego prędkości, co oznacza, że jest on wywoływany poprzez odpowiednie sterowanie. Nasza maszyna posiada trzy osie ruchu, więc pozwala na „zagranie” melodii polifonicznej o trzech niezależnych ścieżkach.

Muzykalne CNC nie jest nowym wynalazkiem, a w sieci z łatwością można znaleźć konwertery z formatu MIDI na format G-code, który nadaje się do bezpośredniego wykorzystania. Jako zwieńczenie projektu „Słoneczko i łapka” dodana została więc triumfalna i prześmiewcza melodia wykonywana przez robota na zakończenie rozgrywki w zależności od wyniku.

Testy

Dzięki sporemu zaangażowaniu i entuzjazmowi uczestników projektu, poszczególne elementy zostały napisane i przygotowane do integracji na długo przed ostatecznym terminem. Pozwoliło to na dokładne przetestowanie każdego elementu z osobna, jak i systemu w całości. W testach mogli brać udział wszyscy pracownicy, a dzięki temu dało się doszlifować grę.

Aby upewnić się, że AI działa poprawnie zastosowano test automatyczny, symulujący 10 000 gier, w których komputer grał sam ze sobą. Program testu zapamiętywał wszystkie wykonane ruchy, aby móc je w razie konieczności później odtworzyć do analizy.

W testach automatycznych, średnia długość rozgrywki wyniosła 29 ruchów. Gracz który zaczynał jako pierwszy miał przewagę zwycięstw (50% vs 43%). Stosunkowo rzadko zdarzały się remisy (7%).

Histogram ilości ruchów wykonywanych na jedną grę zdradził, że AI jest w stanie przegrać w zaledwie siedmiu ruchach. Z założenia AI miało być trochę „ospałe”, ale bez przesady! Aby poprawić ten wynik, przeanalizowano przebieg potyczek, które kończyły się w siedmiu ruchach. Pozwoliło to na szybkie zidentyfikowanie i naprawienie błędu w algorytmie, oraz uchronienie komputera przed upokarzającymi porażkami.

Pierwotnie zakładano, że przed wykonaniem ruchu, gracz będzie musiał zaczekać, aż robot całkowicie przestanie się ruszać i zaparkuje poza planszą. Budziło to jednak obawy, czy gra nie będzie zbyt wolna i zbyt nudna. Na szczęście przy pierwszych testach integracyjnych okazało się, że niewielka modyfikacja kodu wystarcza, aby gracz mógł stawiać stempel bezpośrednio po maszynie nie czekając, aż ta całkowicie się zatrzyma. Rozwiązanie zwiększyło dynamikę gry i pozwoliło uniknąć problemu z powstrzymaniem gracza od zbyt nagłych ruchów.

Większym problemem okazało się natomiast wymuszenie na graczu przestrzegania zasady grawitacji. Pomimo tego, że przed każdą grą wyświetlano animowaną instrukcję na wyświetlaczu, a sama plansza zawierała dużą strzałkę przypominającą o grawitacji, często zasada ta była nadal nierozumiana przez przypadkowych graczy. Aby zapobiec nieuprawnionym ruchom i powtarzającym się dyskwalifikacjom, w trakcie gry na ekranie wyświetlano obraz podglądu z kamery z zaznaczonymi polami, w których ruchy są dozwolone. Rozwiązanie przyniosło pozytywny efekt, jednak nie zażegnało problemu całkowicie.

Testy pozwoliły też na dopracowanie analizatora obrazu. Początkowo był on bardzo wrażliwy, aby móc wykryć słabe, niedokładnie odciśnięte stemple. Próg reakcji musiał zostać zwiększony, aby przypadkowy pyłek lub włos nie spowodował całkowitego ogłupienia programu. Ponieważ maszyna była z natury stacjonarna, założono, że kalibrację algorytmu progującego obraz wykona się w miejscu docelowym, aby móc ją zoptymalizować względem warunków oświetlenia. Na wszelki wypadek, do instalacji dodano lampę, gdyby zastane oświetlenie okazało się niewystarczające.

Efekt końcowy

Jak już zostało wspomniane, zaskakując wszystkich, projekt udało się zakończyć przed terminem i to bez nabijania nadgodzin.  Zaoszczędzony czas można było wykorzystać na dokładne przetestowanie systemu, a także na dodanie drobnych elementów poprawiających efektowność, jak animacje na ekranie i dźwięki grane na silnikach krokowych. Użycie sprawdzonych elementów i rozwiązań pozwoliło uniknąć nieoczekiwanych problemów.

Pomimo bardzo prostego AI, gra okazała się być trudniejszą niż zakładaliśmy: choć doświadczeni gracze nie mieli żadnych problemów, aby wygrać, ostateczny bilans zwycięstw i tak przechylał się w stronę komputera.

Algorytm przechwytywania obrazu oraz sterowania robotem okazał się wystarczająco niezawodnym, aby pracować przez cały dzień targów bez większych problemów. Wbrew obawom, nie pojawiły się problemy, z mylnym odczytywaniem planszy.

Sukces projektu można tłumaczyć na wiele sposobów – jasny i przejrzysty podział pracy na zespoły, odpowiednio wczesne przygotowanie specyfikacji interfejsów, dzięki czemu każdy wiedział co jego komponent powinien robić; wybór platformy i języka programowania, czy zastosowane techniki testowe.

Jednak wszystkie te elementy mają zdecydowanie mniejsze znaczenie, wobec innego czynnika, jakim była pomysłowość i pełne zaangażowanie osób biorących udział w projekcie. To dzięki niemu praca nad „Czwórkami” przynosiła ogromną frajdę, a efekt końcowy nieopisaną satysfakcję.

Dla chętnych – skrót projektu w filmowej odsłonie.