Both sides previous revision
Poprzednia wersja
Nowa wersja
|
Poprzednia wersja
|
pl:miw:miw08_mindstormsdesign [2008/06/03 10:00] miw |
pl:miw:miw08_mindstormsdesign [2019/06/27 15:50] (aktualna) |
| |
| |
| ====== Pliki Hqed ====== |
| |
| |
| {{:pl:miw:miw08_mindstormsdesign:alg1.xttml|Omijanie przeszkód}} |
| |
| {{:pl:miw:miw08_mindstormsdesign:alg3.xttml|Poruszanie się wzdłuż linii}} |
| |
| {{:pl:miw:miw08_mindstormsdesign:alg4.xttml|Poruszanie się wzdłuż linii (2)}} |
| |
| {{:pl:miw:miw08_mindstormsdesign:alg5.xttml|Omijanie przeszkody (plansza z przeszkodami)}} |
| |
| {{:pl:miw:miw08_mindstormsdesign:alg6.xttml|Labirynt}} |
| |
| {{:pl:miw:miw08_mindstormsdesign:alg2.xttml|Przykladowy algorytm z podzialem atrubutów na robot_action}} |
| |
====== Sprawozdanie ====== | ====== Sprawozdanie ====== |
* prezentacje: | * prezentacje: |
* [[http://fountain.isis.vanderbilt.edu/teaching/2004/presentations/msrobot.ppt/download|Robot w labiryncie]] | * [[http://fountain.isis.vanderbilt.edu/teaching/2004/presentations/msrobot.ppt/download|Robot w labiryncie]] |
| |
| |
| |
| |
| + dodatkowa informacja o stanie robota | + brak konieczności zapewniania zerowaniana wartości | | | + dodatkowa informacja o stanie robota | + brak konieczności zapewniania zerowaniana wartości | |
| - należy pamiętać, że wówczas inkrementujemy wartości, np. turn += 45 zamiast turn = 45 | + prosty zapis | | | - należy pamiętać, że wówczas inkrementujemy wartości, np. turn += 45 zamiast turn = 45 | + prosty zapis | |
| - konieczność zerowania wartości w celu np. zatrzymania robota po wykonaniu reguły | - zerowanie wymusza konieczność ponownego pozyskania informacji o stanie robota | | | - konieczność zerowania wartości w celu np. zatrzymania robota po wykonaniu reguły | - zerowanie wymusza konieczność ponownego pozyskania informacji o stanie robota co prowadzi do zwiększenia ilości atrybutów | |
| | ? zerowanie powinno odbywać się albo po wykonaniu reguły, albo przy kolejnym cyklu (metoda "Pojedyncze wywołanie") | | | | ? zerowanie powinno odbywać się albo po wykonaniu reguły, albo przy kolejnym cyklu (metoda "Pojedyncze wywołanie") | |
| |
W projekcie przyjęto, że dla reguł atrybuty są wartościami bez pamięci. | W projekcie przyjęto, że dla zapisu regułowego algorytmów __atrybuty są wartościami bez pamięci__. |
Podjęto próbę dokonania zapisu wg przykładu z termostatem. Czyli dokonania grupowania atrybutów. Wady i podejścia tego zapistu zostały przedstawione w punkcie XTT. | Podjęto próbę dokonania zapisu wg przykładu z termostatem. Czyli dokonania grupowania atrybutów. Głównym napotkanym problemem było oddzielenie akcji od atrybutów. Częst zdażało się, że atrybut był akcją. Upakowywanie atrybutów i akcji często prowadziło do zwiększenia ilości reguł oraz do mniejszej czytelności. W miarę możliwości powinno się upraszczać opis do reguła->akcja |
| |
| ^ Atrybuty - prosty zapis ^ Atrybuty - zapis złożony (upakowywanie atrybutów, np. termostat) ^ |
| | + prostota | + bardziej przejrzysta forma zapisu | |
| | - więcej warunków wstępnych do wykonania reguły | + logiczna konsekwencja zapisu reguł | |
| | - przy dużej ilości warunków reguły tracą czytelność | - zazwyczaj prowadzi do zwiększenia ilości reguł | |
| |
===== Prolog - UWAGI ===== | ===== Prolog - UWAGI ===== |
* algorytmy zostały zapisane przy użyciu przygotowanego API przez Pana Piotra Hołownię. Wszelkie uwagi i spostrzeżenia zostały wymienione z kolegą Piotrem. Uwag było niewiele. Przygotowane funkcje wydają się jak najbardziej poprawne. | W trzeciej części iteracji projektu należało zapisać wcześniej wymyślone algorytmy przy użyciu funkcji nxt_movements w Prolog'u. Cel był prosty. Sprawdzono użyteczność stworzonych predukatów. Część z nich była nadmiarowa. Jednak stworozne API przez pana Hołownię w zupełności wystarczyło do zapisania algorytmów sterowania. Wszelkie uwagi oraz spostrzeżenia były konsultowane z kolegą. Uwag było niewiele. Zatem przygotowane funkcje były jak najbardziej poprawne z punktu widzenia użytkownika. |
* Na obecnym etapie napotkano problem związany z ewentualną alokacją zmiennych w pamięci. Czy to ma być zwykły **assert**?? | |
| Podczas tworzenia algorytmów w Prolog'u przy alokacji dodatkowych zmiennych korzystano z funkcji **assert**. Tu możana by się zastanowić nad wprowadzeniem predykatów alokacji pamięci dla Mindstorma, jeżeli jest to konieczne. |
| |
| W sterowaniu robotem najtrudniejszym elementem było zapamiętanie stanu robota. Należało tworzyć dodatkowe zmienne, tablice przechowyjące stan robota. Jako, że korzystanie ze stanów poprzednich jest tu w zasadzie elementarną operacją, można zastanowić się również na wprowadzeniu historii ruchów w postaci jakiś logów, do których możnaby odwoływać się odpowiednimi predykatami. Takie zapisane stany mogłyby ułatwić, ujednolicić oraz sformalizować zapis algorytmów. |
| |
| |
| |
| |
| |
| |
| |
| |
===== XTT - UWAGI ===== | ===== XTT - UWAGI ===== |
* W jednym z algorytmów zastosowano puste przebiegi oraz próbę zaimplementowania konstrukcji z **'else'** [[https://ai.ia.agh.edu.pl/wiki/pl:miw:miw08_mindstormsdesign:grid#xtt|Proponowane puste przebiegi]] | W czwartej iteracji należało zapisać reguły przy użyciu XTT. Ponieważ, XTT jest tylko formą zapisu zwykłych reguł, więc zapisane reguły na ogół nie różniły się od tych z 2 iteracji. W niektórych przypadkach odstąpiono od tej zasady i probowano zapisać reguły zmieniając atrubuty. |
* [[https://ai.ia.agh.edu.pl/wiki/pl:miw:miw08_mindstormsdesign:strona_2#xtt|Problem z wpisaniem ujemnej wartości w XTT]] | Tak jak poprzednio w iteracji 2 pojawiają się problemy: |
* [[https://ai.ia.agh.edu.pl/wiki/pl:miw:miw08_mindstormsdesign:labirynt#xtt|Przy większych algorytmach pojawiają się problemy z reprezentacją tablic atrybutów. Ponadto zapętlanie algorytmu robi się bardzo nieczytelne.]] | * podział na atrybuty i akcje |
| * czy atrybuty/akcje są zerowane, czy też mają pamięć? |
| * jak uruchamiać XTT? |
| * pojedyncze wywołanie? |
| * monitorowanie? |
| * nawroty? |
| * brak znacznika START'u/STOP'u |
| * problem operowania na większej ilości danych, np. tablice |
| * puste przebiegi jako defaultowa reguła (konstrukcja **else**), czy mogą być używane? |
| * wielokrotne zapętlanie algorytmu prowadzi do nieczytelności |
| Te i wiele innych problemów zauważono przy korzystaniu z XTT. Ponieważ, zapis XTT, w moim odczuciu powinien być jak najbardziej elastyczny, postanowiłem odejść od formalnego zapisu jak np. termostat i postanowiłem zapisywać algorytmy na różne sposoby. |
| |
| __**UWAGI!!!**__ |
| Tworzenie algorytmu od postaw: |
| - Dodawanie atrybutów |
| * //[[pl:miw:miw08_mindstormsdesign:labirynt#xtt|brak złożonych atrybutów, jak tablica]]//. Przypuszczam, że wprowadzenie atrbutu tablicowego jest trudne i zmieniłoby koncepcje działania XTT. Jednak jak zapisać większe struktury danych, jeżeli jest taka potrzeba (patrz algorytm [[pl:miw:miw08_mindstormsdesign:labirynt#xtt|labirynt XTT]])? |
| - //Znacznik rozpoczęcia programu//. W przypadku wielu tablic warunkowych na początku XTT powinien być jakiś znacznik wskazujący START programu. Może być systuacja taka, że za tablicami 'fact table' pojawiają się tablice z warunkami bardzo podobnymi i wówczas należy wskazać, która tablica jest nadrzędna. Oczywiście projektant powinien unikać takich sytuacji, ale mimo wszystko może zaistnieć taka sytuacja. |
| - //[[pl:miw:miw08_mindstormsdesign:grid#xtt|Puste przebiegi]]//. Może pojawić się potrzeba wprowadzenia pustych reguł, które spełniały by rodzaj konstrukcji **else**. {{ :pl:miw:miw08_mindstormsdesign:ekran2.png }} |
| - //Zapętlanie reguł//. Bardzo przydatne okazuje się w niektóruch przypadkach wprowadzanie pętli. Można stworzyć w ten sposób dowolną pętlę. {{ :pl:miw:miw08_mindstormsdesign:ekran3.png }} |
| - //[[pl:miw:miw08_mindstormsdesign:strona_2#xtt|Błąd przy negacji znaku zmiennej]]//. Przy zmianie znaku na przeciwny dla atrybutu pojawia się błąd. {{ :pl:miw:miw08_mindstormsdesign:ekran4.png }} |
| - //Sposób wywoływania reguł// w zasadzie niewiele koncepcji można tu wymyśleć. Czy zostanie przyjęty system wywołania pojedynczego co jakiś okres, czy zastosowane zostaną nawroty (w sensie zapętlania programu) to zasada i tak zostanie ta sama. Jedynym aspektem, nad którym można by się zastanawiać to moment aktualizowania danych wejściowych z 'fact table'. Bo to czy aktualizacja nastąpi podczas jednego przebiegu (gdzie przebiegiem nazywamy przejście od tablicy początku do końca), czy w trakcie, bądź też np. podczas spływania sygnałów do tablicy, nabiera znaczenia. |
| |
| Wydaje mi się, że niezależnie od sposobu przedstawiania atrubutów (np. termostat lub zwykły zapis prostych atrybutów), to zapis XTT powinien: |
| * przybierać postać alternatywnych ścieżek przejścia reguł |
| * powinna być możliwość wprowadzanie zapętlania reguł |
| * powinna być możliwość stosowania pustych reguł, gdyż ułatwiają one zapis |
| XTT powinien być na tyle elastyczny, by mogła zostać zapisana dowolna struktura na potrzeby bardziej złożonych algorytmów. |
| |
| |
| |
===== ARD - UWAGI ===== | ===== ARD - UWAGI ===== |
| W piątej iteracji należało zastanowić się nad ujęciem algorytmów w ARD. |
* wydzielanie atrybutów dla algorytmów sterowania nie zawsze jest łatwe. Pojawiają się problemy z rozróżnieniem akcji od atrybutu. | * wydzielanie atrybutów dla algorytmów sterowania nie zawsze jest łatwe. Pojawiają się problemy z rozróżnieniem akcji od atrybutu. |
* również, atrybuty występują w w różnych częściach algortymu. Stąd, relacje pomiędzy atrybutami często są złożone. Przejawie się to choćby w późniejszej realizacji XTT. Czytelność XTT jest słaba. | * również, atrybuty występują w w różnych częściach algortymu. Stąd, relacje pomiędzy atrybutami często są złożone. Przejawia się to choćby w późniejszej realizacji XTT. Czytelność XTT jest słaba. |
===== Program HQED - UWAGI ===== | |
| |
| ===== Program HQED - UWAGI ===== |
| Wszystkie poniższe bugi zostały już zgłoszone przez kolegę Łukasza Rachwalskiego. |
* podczas przeciągania połączenia od jednej tabeli do drugiej pojawiają się błędy. A dokładniej linia (connector) nie podąża za kursorem, co uniemożliwią dokonanie poprawnego połączenia tabel | * podczas przeciągania połączenia od jednej tabeli do drugiej pojawiają się błędy. A dokładniej linia (connector) nie podąża za kursorem, co uniemożliwią dokonanie poprawnego połączenia tabel |
* obecna wersja programu nie jest jeszcze stabilna. Program zawiesza się np. przy wprowadzaniu danych do tabel. | * obecna wersja programu nie jest jeszcze stabilna. Program zawiesza się np. przy wprowadzaniu danych do tabel. |