1. KLIENT ROBOCUP JAKO SYSTEM EKSPERTOWY
1.1. NATURA ZAGADNIENIA Każdy zawodnik podczas meczu realizuje pewien algorytm, na który składa się wiele instrukcji warunkowych. Musi określić, jaki jest aktualnie tryb gry, jaka jest jego rola na boisku i czy piłka jest blisko niego [2]. Ilość koniecznych do rozpatrzenia warunków sprawia, że kod zaczyna się rozrastać a późniejsze zmiany wymagają dużej uwagi i nakładu czasu. W świecie informatyki istnieje określenie paradygmat programowania, którym nazywa się styl programowania, charakteryzujący się pewnymi wyróżniającymi go cechami i wspierany odpowiednimi językami programowania. Powszechnie stosowane programowanie proceduralne można uważać za odbywające się zgodnie z paradygmatem:
PROCEDURA = ALGORYTM + DANE
Paradygmat ten jest wspierany przez wszystkie proceduralne języki programowania, np. Pascal, C. Systemy ekspertowe można uważać za działające zgodnie z paradygmatem:
SYSTEM EKSPERTOWY = SYSTEM WNIOSKUJĄCY + BAZA WIEDZY
Paradygmat ten jest wspierany przez języki deklaratywne jak na przykład Prolog oraz przez dużą liczbę języków wyższego poziomu, za jakie można uważać ekspertowe systemy skorupowe. W odróżnieniu od popularnych języków proceduralnych, program w języku Prolog nie służy do zapisu algorytmu rozwiązania zadania, lecz służy do opisu zadania za pomocą dość elementarnych pojęć logiki – opis zadania jest zbudowany za pomocą reguł i faktów. Kompilator jest wyposażony w system wnioskujący, dokonujący wnioskowania na podstawie celu i przedstawionych reguł i faktów. Zrealizowany system ekspertowy steruje zachowaniem bramkarza w rozgrywkach RoboCup. Natura zagadnienia gry w piłkę nożną, gdy ją sprowadzimy do opisu matematycznego sytuacji na boisku jest w pełni zrozumiała. Można na jej podstawie wysuwać konkretne wnioski i przewidywać skutki odpowiedniego postępowania. Problem leży w mnogości możliwych do wystąpienia konfiguracji i współrzędnych położenia zawodników. W projekcie zdecydowano, że na początku baza wiedzy będzie pusta [3], a dopiero podczas kolejnych rozgrywek będzie sukcesywnie uzupełniana sytuacjami, jakie wystąpiły w tych spotkaniach. Takie podejście do problemu z założenia spowoduje, że nasz „inteligentny zarządca zachowaniem bramkarza” w pierw-szych meczach będzie tylko zdobywał wiedzę, przez co reakcje zawodnika nie będą adekwatne do sytuacji na boisku. Z czasem na podstawie zdobytego doświadczenia – w postaci bazy wiedzy – zachowanie bramkarza powinno ulec polepszeniu i jego reakcje na dane sytuacje powinny być już bardziej logiczne [4].
Oddzielenie bazy wiedzy (a więc części programu opisującej wiedzę związaną z rozwiązywanym problemem) i systemu wnioskującego (a więc części programu rozwiązującej problem) umożliwia prostą modyfikację bazy wiedzy przez użytkownika bez potrzeby naruszania integralności właściwego programu. Aktualizacja taka, w przypadku programów proceduralnych, o wiedzy dziedzinowej rozrzuconej w dużej liczbie deklaracji typu if … then … else … lub case i kodowanej w sposób słabo czytelny, jest przedsięwzięciem czasochłonnym. Jeżeli program został opracowany w paradygmacie systemu ekspertowego, aktualizację zasad działania w większości uzyskuje się na drodze modyfikacji samej bazy reguł.
1.2. ZAŁOŻENIA PROJEKTU Przystępując do realizacji projektu, którego zadaniem było zamodelowanie, stworzenie i przetestowanie systemu ekspertowego, pomagającego bramkarzowi drużyny podejmować decyzję o jego zachowaniu, w odróżnieniu od większości osób tworzących systemy ekspertowe, zaniechano użycia specjalnie do tego celu przygotowywanych języków programowania (jak na przykład wspomniany wcześniej Prolog), ale postanowiono wykorzystać dotychczas zdobytą wiedzę z zakresu programowania. Połączono system wnioskujący, napisany w C++, z bazą wiedzy opartą o bazę danych pracującą w standardzie SQL. Idea postępowania zawodnika była następująca:
1. Zawodnik wysyła zapytanie SQL do bazy, czy znajdują się w niej parametry odpowiadające aktualnej sytuacji na boisku.
2. Jeżeli odpowiedź jest pozytywna, następuje wykonanie przyporządkowanej do tejże sytuacji komendy wraz z parametrami.
3. Jeżeli nie znaleziono w bazie pasujących elementów (wraz z marginesem błędu), system generuje losową komendę i wprowadza nowy rekord do bazy.
4. Komenda zostaje wykonana i zapisana w strukturze opartej o listę, gdzie czeka na ocenę.
5. Ocena podjętej decyzji zostaje wyliczona po określonym czasie od jej podję-cia i na jej podstawie zostaje zmodyfikowany „współczynnik użyteczności” danej komendy.
W ten sposób tworzona jest baza wiedzy, która jak wspomniano na początku jest pusta. Podczas podejmowania decyzji zawodnik odpytywał bazę w poszukiwaniu pasujących parametrów gry. Głównym celem projektu było sprawdzenie, czy umieszczenie na boisku zawodnika z zerową wiedzą i przeprowadzenie szeregu rozgrywek wpłynie dodatnie na jego zachowanie się na boisku.