Both sides previous revision
Poprzednia wersja
Nowa wersja
|
Poprzednia wersja
|
pl:miw:miw08_mindstormsdesign [2008/06/03 12:38] 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 ====== |
| |
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. |
| |
| |
| |
| |
| |
__**UWAGI!!!**__ | __**UWAGI!!!**__ |
Tworzenie algorytmu od postaw: | Tworzenie algorytmu od postaw: |
- Dodawanie atrybutów | - Dodawanie atrybutów |
* 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]])? | * //[[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. | - //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. |
- //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 }} | - //[[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 }} | - //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 }} |
- //Błąd przy zmianie znaku zmiennej//. Przy zmianie znaku na przeciwny dla atrybutu pojawia się błąd. {{ :pl:miw:miw08_mindstormsdesign:ekran4.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. |