added raport 3 and restored raport 1

This commit is contained in:
Michał Starski 2019-05-14 23:50:47 +02:00
parent 431d130379
commit 433a8b1ec9
2 changed files with 198 additions and 0 deletions

138
Raports/SI_Raport_1.md Normal file
View File

@ -0,0 +1,138 @@
# Sztuczna inteligencja 2019 - Raport 1
**Czas trwania opisywanych prac:** 06.03.2018 - 26.03.2018
**Członkowie zespołu:** Anna Nowak, Magdalena Wilczyńska, Konrad Pierzyński, Michał Starski
**Wybrany temat:** Inteligentna śmieciarka
**Link do repozytorium projektu:** https://git.wmi.amu.edu.pl/s440556/SZI2019SmieciarzWmi
## Środowisko agenta i reprezentacja wiedzy
Pracę zaczeliśmy od spisania wszystkiego co będzie nam potrzebne do napisanie działającego środowiska. Notatki
można obejrzeć pod [tym linkiem](https://git.wmi.amu.edu.pl/s440556/SZI2019SmieciarzWmi/src/master/README.md). Pod uwagę wzieliśmy następujące czynniki:
* Jak dana technologia radzi sobie z graficznym przedstawieniem informacji (render mapy i rozmieszczenie na niej obiektów, zmiana stanów obiektów w zależności od sytuacji ...)
* Poziom skomplikowania operacji na strukturach danych
* Podejście języka do paradygmatu obiektowego
* Trudność w implementacji mechanizmów sztucznej inteligencji
* Preferencje programistyczne grupy
Po naradzie i sugestiach od strony prowadzącego zdecydowaliśmy, że do projektu najlepiej będzie pasował język **python** z uwagi na jego uniwersalność i łatwość przetwarzania danych.
### Plansza po której porusza się agent
**Założenia**
1. Plansza jest generowana losowo przy każdym uruchomieniu skryptu
2. Każda plansza zawiera *n* domów i 3 wysypiska śmieci
3. Każdy domek klatkę generuje jeden z 3 rodzajów śmieci z prawdopodobieństwem P (domyślnie 1/25)
4. Agent chodzi po domkach zbiera śmieci i wyrzuca je na odpowiednie wysypisko
5. Agent ma pojemność 10 na każdy rodzaj śmiecia
6. Dom może wygenerować maksymalnie 10 śmieci
7. Plansza jest dyskretna
**Detale implementacyjne**
Środowisko powstało przy użyciu biblioteki **pygame**, która udostępnia nam narzędzia do wygodnego zbudowania schludnie wyglądającej symulacji. Plansza ma postać dwuwymiarowiej płaszczyzny kartezjańskiej podzielonej na komórki (Cells). Na komórkach umieszczane są po kolei obiekty, tak, aby nie doszło do sytuacji, w której agent nie ma możliwości ruchu. Środowisko jest generowane dynamicznie w zależności od parametru **home-count**, który podajemy przy starcie skryptu. Dzięki temu możemy testować agenta w możliwie różnych sytuacjach. Opis elementów środowiska został przedstawiony przy użyciu paradygmatu obiektowego, dzięki temu kod jest czytelniejszy i wydzielony.
Na ten moment na planszy pojawiają się instancje klas:
*Grass* - klasa reprezentująca komórkę po której agent może swobodnie się poruszać, wypełnia większość mapy
*House* - klasa reprezentująca dom, agent wchodzi z nią w interakcję, zabiera wygenerowane śmieci
*Landfill* - klasa reprezentująca wysypisko, agent wchodzi z nią w interakcję, oddaje zebrane śmieci
*Garbage_collector* - klasa reprezentująca agenta - porusza się po mapie i wchodzi w interakcję z innymi obiektami
*HUD* - klasa reprezentująca HUD aplikacji (jeszcze niezaimplementowany)
**Struktura plików projektu**
--enums => Klasy dziedziczące po klasie *Enum*, ułatwiające parsowanie informacji
--fonts => Czcionki
--images => Obrazy i ikony używane w aplikacji
--raports => Raporty
--sprites => Klasy reprezentujące obiekty na mapie
.gitignore
config.py => Plik przechowujący funkcję zarządzające konfiguracją aplikacji
game.py => Plik rozruchowy programu
utils.py => Funkcje pomocnicze
README.md => Informacje o aplikacji
requirements.txt => Przechowuje informacje na temat używanych bibliotek
to_do.txt => Lista przyszłych zadań do zrobienia
### Reprezentacja Wiedzy
Przyjeliśmy na potrzeby projektu, że agent będzie wiedział co się dzieje na całym obszarze środowiska. W tym momencie wszystko co wie agent wyświetlane jest w oknie terminala, w czasie rzeczywistym, podczas trwania programu. Do informacji posiadanych przez agenta należą:
* Ile zebrano śmieci od startu programu
* Stopień zapełnienia śmieciarki
* Ile śmieci zostało na mapie
Podczas dalszego rozwoju powyższe informacje będą przedstawiane na ekranie aplikacji.
### Uruchamianie aplikacji
**Linux**
Uruchomienie standardowe (z 5 domami)
```bash
make init #stworzenie wirtualnego środowiska
make install #zainstalowanie zależności
make start #uruchomienie z domyślnym parametrem home-count=5
```
Uruchomienie niestandardowe
```bash
env/bin/python3 ./game.py home-count=amount #Liczba domów nie może być mniejsza niż 3
```
**Windows**
```powershell
py -m virtualenv env # Stworzenie wirtualnego środowiska
env\Scripts\pip.exe install -r requirements.txt
env\Scripts\python.exe ./game.py --home-count=amount
```

60
Raports/SI_Raport_3.md Normal file
View File

@ -0,0 +1,60 @@
# Sztuczna inteligencja 2019 - Raport 3
**Czas trwania opisywanych prac:** 03.04.2019 - 14.04.2019
**Członkowie zespołu:** Anna Nowak, Magdalena Wilczyńska, Konrad Pierzyński, Michał Starski
**Wybrany temat:** Inteligentna śmieciarka
**Link do repozytorium projektu:** https://git.wmi.amu.edu.pl/s440556/SZI2019SmieciarzWmi
## Planowanie ruchu - Algorytmy BFS i Best-first search
#### Implementacja
##### BFS (Iteracyjnie)
Algorytm przeszukiwania drzewa w głąb.
W przypadku BFS użyte struktury pozostają w gruncie rzeczy te same (z tym, że tym razem zamiast stosu do przechowywania stanu używamy kolejki), zmienia się tylko kolejność wykonywanych instrukcji:
**Przebieg algorytmu**:
- Dodaj do kolejki pierwszy krok
- Dopóki kolejka nie jest pusta:
1. Zdejmij z kolejki następny nieodwiedzony wierzchołek grafu
2. Jeżeli możliwa jest jakaś akcja (zebranie/oddanie smieci) wykonaj ją
3. Sprawdź wszystkie sąsiednie wierzchołki wybranego wierzchołka, które jeszcze nie zostały odwiedzone
##### Best-first search
Agent idzie w kierunku celu do którego jest najbliżej w linii prostej w danym momencie.
**Przebieg algorytmu**
1. Ustaw pozycję początkową
2. Znajdź obiekt w znajdujący się najbliżej w linii prostej
3. Jeżeli odległość od obiektu wynosi 1, wykonaj interakcję i usuń obiekt z listy celów, zwróć ścieżkę do obiektu
4. Jeżeli przekroczono limit rekursji lub nie można wykonać kroku zakończ
5. Na podstawie pozycji nowoobranego celu wybierz preferowane oraz niechciane kierunki poruszania się
6. Posortuj dozwolone ruchy zgodnie z preferencjami
7. Dla każdego kierunku na liście przeszukuj dostępne ścieżki dopóki jakakolwiek nie zostanie znaleziona
========
Ponadto, dołożyliśmy śmieciarzowi możliwość oddawania śmieci na wysypisko w ten sposób kompletując założenia planszy.
#### Obserwacje
W porównaniu do poprzednio zaimplementowanego DFS oba algorytmy sprawują się zdecydowanie szybciej. Przez to, że szukanie drogi nie odbywa się w głąb, agent nie traci czasu na przeszukiwanie wierzchołków z góry skazanych na porażkę. Poniżej przedstawiamy tabelę mierzącą liczbę kroków, która była potrzebna do wykonania przez agenta przy użyciu DFS, BFS i Best-first search na 5 przygotowanych do testów mapach:
| Algorytm / Kroki | Mapa 1 | Mapa 2 | Mapa 3 | Mapa 4 | Mapa 5 |
| --- | --- | --- | --- | --- | --- |
| DFS | 134 | 45 | 67 | 191 | 12 |
| BFS | 59 | 20 | 54 | 98 | 12 |
| Best-first | 55 | 20 | 58 | 99 | 12 |
Po wykonaniu testów możemy stwierdzić, że najlepszym z tych 3 algorytmów okazał się Best-first search. Warto jednak zauważyć, że na mapach numer 1,3 i 4 różnica kroków jest mała, a na mapie 2. identyczna jak BFS.
Co widać bez jakichkolwiek wątpliwości DFS okazał się najgorszy (zgodnie z uzasadnieniem znajdującym się w raporcie nr. 2). Liczba kroków jest prawie dwukrotnie większa od tej w konkurujących algorytmach.
(Mapa 5 posiadała tylko jedną możliwe przejście posiadające 12 kroków ten wynik można pominąć.)