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 11:23] 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 106: | Linia 119: | ||
| 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. | 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. | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| Linia 114: | Linia 134: | ||
| * czy atrybuty/akcje są zerowane, czy też mają pamięć? | * czy atrybuty/akcje są zerowane, czy też mają pamięć? | ||
| * jak uruchamiać XTT? | * 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. | ||
| + | |||
| - | * 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]] | ||
| - | * [[https://ai.ia.agh.edu.pl/wiki/pl:miw:miw08_mindstormsdesign:strona_2#xtt|Problem z wpisaniem ujemnej wartości w XTT]] | ||
| - | * [[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.]] | ||
| ===== 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. | ||
