Różnice między wybraną wersją a wersją aktualną.
| Both sides previous revision Poprzednia wersja Nowa wersja | Poprzednia wersja | ||
|
pl:miw:miw08_mindstormsdesign [2008/06/03 08:49] miw |
pl:miw:miw08_mindstormsdesign [2019/06/27 15:50] (aktualna) |
||
|---|---|---|---|
| Linia 36: | Linia 36: | ||
| + | ====== 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 ====== | ||
| Linia 51: | Linia 64: | ||
| * 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]] | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| ===== Algorytmy - zapis regułowy ===== | ===== Algorytmy - zapis regułowy ===== | ||
| - | W drugiej iteracji należało zastanowić się i zapisać algorytmy sterowania dla wymyślonego robota Mindstorm. Jako robot przyjęto TriBot, który zawiera wszystkie dosŧępne sensory. | + | W drugiej iteracji należało zastanowić się i zapisać algorytmy sterowania dla wymyślonego robota Mindstorm. Do tego celu użyto robot TriBot, który zawiera wszystkie dosŧępne sensory. |
| Przy zapisie regułowym pojawiło się parę niejasności: | Przy zapisie regułowym pojawiło się parę niejasności: | ||
| * Czy reguły mają się wykluczać? I jeżeli nie, to wówczas jaki przyjąć sposób ich "odpalania". | * Czy reguły mają się wykluczać? I jeżeli nie, to wówczas jaki przyjąć sposób ich "odpalania". | ||
| Linia 61: | Linia 81: | ||
| Od tych zasadniczych pytań zależy sposób zapisania reguł. Wydaje się oczywiste, że najlepiej byłoby dążyć do tego by reguły były zupełne i jednocześnie wykluczały się. Jednak taki zapis nie jest prosty. Oraz narzuca pewne wymogi. | Od tych zasadniczych pytań zależy sposób zapisania reguł. Wydaje się oczywiste, że najlepiej byłoby dążyć do tego by reguły były zupełne i jednocześnie wykluczały się. Jednak taki zapis nie jest prosty. Oraz narzuca pewne wymogi. | ||
| W projekcie wykorzystano zarówno reguły wykluczające się jak i takie, które są luźne. Przy tych ostatnich przyjęto, że __wywoływana jest pierwsza poprawna reguła__ (zapis ten przypomina Prolog). | W projekcie wykorzystano zarówno reguły wykluczające się jak i takie, które są luźne. Przy tych ostatnich przyjęto, że __wywoływana jest pierwsza poprawna reguła__ (zapis ten przypomina Prolog). | ||
| + | |||
| + | | ^ Reguły wykluczające się ^ Luźny zapis ^ | ||
| + | ^ | + pewniejszy zapis | + brak ograniczeń | | ||
| + | ^ | + proste zasady | + mniej reguł | | ||
| + | ^ | - większa ilość reguł | - problem z wywolywaniem reguł | | ||
| + | ^ | - narzucona koncepcja. W niektórych przypadkach utrudnia zapis| | | ||
| + | ^ Pojedyncze wywołanie | Jest to najlepsze sposób wywoływania | Prowadzi do formalizacji(szczegułowaści) zapisu, zwiększa ilość reguł | | ||
| + | ^ Monitorowanie | Nie jest potrzebne | Może prowadzić do wywołania więcej niż jednej reguły | | ||
| + | ^ Nawroty | Są zbędne, niczego nowego nie wprowadzają | Najlepsze podejście. Reguły tworzą logiczną ścieżkę przejść | | ||
| + | |||
| Po przyjęciu sposobu zapisu reguł i przyjęciu mechanizmu ich wywoływania, przystąpiono do ich zapisu. I tu również pojawił się problem. Mianowicie, w przypadku bardziej złożonych algorytmów trudno było wydzielić takie elementy jak: | Po przyjęciu sposobu zapisu reguł i przyjęciu mechanizmu ich wywoływania, przystąpiono do ich zapisu. I tu również pojawił się problem. Mianowicie, w przypadku bardziej złożonych algorytmów trudno było wydzielić takie elementy jak: | ||
| * atrybuty | * atrybuty | ||
| * akcje | * akcje | ||
| * zmiana wartości atrybutu | * zmiana wartości atrybutu | ||
| + | |||
| Czy raz wpisana wartość atrybutu zostaje zachowana do następnej zmiany? | Czy raz wpisana wartość atrybutu zostaje zachowana do następnej zmiany? | ||
| - | W projekcie przyjęto, że dla reguł 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. | + | ^ Atrybuty z pamięcią ^ Atrybuty bez pamię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 | | ||
| + | | - 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") | | ||
| + | |||
| + | 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. 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. | ||
