Cieľom úlohy bolo vymazať nepoužívané a nepotrebné importy. Bol použitý nástroj v IntelliJ Idea IDE na inšpekciu kódu. Konkrétne Code → Optimize code. Postupne potom boli skontrolované, vymazané alebo upravené importy v triedach.

Zoznam modifikovaných tried:

Jim/src/sk/fiit/jim/Settings.java

Jim/src/sk/fiit/jim/agent/AgentInfo.java

Jim/src/sk/fiit/jim/agent/communication/Communication.java

Jim/src/sk/fiit/jim/agent/communication/testframework/Message.java

Jim/src/sk/fiit/jim/agent/communication/testframework/TestFrameworkCommunication.java

Jim/src/sk/fiit/jim/agent/highskill/Bending.java

Jim/src/sk/fiit/jim/agent/highskill/KickTestHighSkill.java

Jim/src/sk/fiit/jim/agent/highskill/kick/Kick.java

Jim/src/sk/fiit/jim/agent/highskill/move/MovementSkills.java

Jim/src/sk/fiit/jim/agent/highskill/move/Walk.java

Jim/src/sk/fiit/jim/agent/highskill/move/WalkFastZMP.java

Jim/src/sk/fiit/jim/agent/highskill/move/WalkFastZMPOld.java

Jim/src/sk/fiit/jim/agent/highskill/runner/HighSkillPlanner.java

Jim/src/sk/fiit/jim/agent/kalman/KalmanExample.java

A ďalšie …

Po vymazaní importov knižníc by sa program nemal stať akýmkoľvek spôsobom nefunkčný alebo poškodený. Overenie v podobe krátkeho otestovania funkčnosť potvrdilo.

---

Cieľom úlohy bolo vymazať nepoužívané a nepotrebné metódy aby sa sprehľadnil kód. Takto bude aj pre budúce tímy jednoduchšie sa v kóde orientovať a nebudú musieť zbytočne strácať čas nad metódami, ktoré sa nevyužívajú.

Bol použitý nástroj v Idea IDE na inšpekciu kódu. Konkrétne Analyze → Inspect Code → Inspection Profile (…) → Declaration redundancy → Unused declaration, označenie ako chyba. Postupne potom boli skontrolované a vymazané metódy z tried začínajúcim na písmeno A až M. Väčšinou išlo o staré triedy, ktoré sa prestali používať (a nie je k nim dostupné žiadne info) pravdepodobne z dôvodu nepotrebnosti a boli nahradené novými. Taktiež bola vymazaná jedna trieda, ktorá sa nepoužívala.

Zoznam modifikovaných tried:

Jim\src\sk\fiit\jim\agent\highskill\Bending.java Jim\src\sk\fiit\jim\agent\highskill\HeadDownSkill.java

Jim\src\sk\fiit\jim\agent\models\AgentModel.java

Jim\src\sk\fiit\jim\agent\models\BodyPart.java

Jim\src\sk\fiit\jim\agent\skills\HighSkill.java

Jim\src\sk\fiit\jim\agent\skills\HighSkillUtils.java

Jim\src\sk\fiit\jim\annotation\data\MoveValidator.java

Jim\src\sk\fiit\jim\log\JimLocalCsvFileCreator.java

Jim\src\sk\fiit\jim\log\JimLocalFileCreator.java

RoboCupLibrary\src\sk\fiit\robocup\library\geometry\Angles.java

TestFramework\src\sk\fiit\testframework\annotator\serialization\MoveValidator.java

TestFramework\src\sk\fiit\testframework\beta\ui\ComparingTab.java

TestFramework\src\sk\fiit\testframework\communication\agent\AgentManager.java

TestFramework\src\sk\fiit\testframework\init\Implementation.java

TestFramework\src\sk\fiit\testframework\monitor\AgentMonitor.java

TestFramework\src\sk\fiit\testframework\monitor\AgentMonitorMessage.java

TestFramework\test\sk\fiit\testframework\MessageParserTest.java

Vymazaná trieda:
TestFramework\src\sk\fiit\testframework\incomplete\GoalieTestCase.java

Niektoré nájdené metódy vymazané neboli. Išlo hlavne o konštruktory GUI tried, ktoré inšpekcia taktiež označila za nepoužívané, avšak ich vymazanie by znefunkčnilo GUI.

Po vymazaní metód by program nemal byť akýmkoľvek spôsobom nefunkčný alebo poškodený. Overenie v podobe krátkeho otestovania funkčnosť potvrdilo. Kód by po dokončení ostatných úloh na vymazanie zbytočnosti mal byť čistejší a ľahšie sa v ňom orientovalo.

---

Počas pracovania s kódom, ktorý vyvíjali ostatní študenti sme sa často stretli s poznámkou TODO v kóde. Keďže sa s touto poznámkou stretla väčšina členov nášho tímu predpokladáme, že v kóde je veľa načatej, no nedokončenej práce.

sk.fiit.jim.agent

• highskill.move.MovementSkills.java

(113, 7) TODO consider relativeDistanceToTarget, consider annotation's min_distance

Popis: Inžinierske dielo, Tím BAREKO s. 61

• highskill.move.WalkFastZMPOld.java

(307, 5) TODO moves/walk_dynamic.xml

• highskill.move.WalkMedium.java

(16, 5) TODO try to create solution with reusable Singleton Factory to do not need to write getInstance and private constructor for each new class

• models.prediction.Probhet.java

(17, 5) TODO: implement the prediction module correctly - not sure it works.

Popis: Inžinierske dielo, Tím Megatroll s. 54

• models.AgentModel.java

(451, 6) TODO can be removed if Zero moment point is working fine …

(832,55) TODO accelerometer is relative to torsoPosition, not centerOfMass

• models.AgentPositionCalculator.java

(77,6) TODO <Delete> odstranit podmienku po doimplementovani story 244

(81,6) TODO </Delete>

(584,6) TODO 244

Popis: Na 30. strane finálneho inžinierskeho deja sa spomína táto metóda, no nie je tam spomenuté či sa story 244 ukončila

• models.DynamicObject.java

(11, 4) TODO: implement calculation of opponent position

Popis: Popis ku konkrétnemu TODO som nenašiel v žiadnej z dokumentácii, no tím SixPack sa vo svojom inžinierskom diele zaoberal touto problematikou na 30. strane

• models.LinePatternRecognition.java

(11, 4) TODO: Calculate if two lines are part of central circle

Popis: Táto metódia nie je naimplementovaná, no v komentári je popísané aký return očakáva.

(138, 50) (152, 52) TODO: A deviation has to be considered

Popis: Výpočet sa vykonáva len v dvojrozmernom priestore, je potrebné výpočty aktualizovať do trojrozmeného priestoru.

• models.TacticalInfo.java

(622, 21) TODO- Implement computation with rotation agent to ball.

(688, 39) TODO - Implement computation with rotation agent to ball.

Popis: metóda chanceToGetBall nepočíta s natočením hráča voči lopte, bližší popis je v komentári.

(780, 5) TODO Compute relative fitness to strength of kick (annotations)

Popis: bližší popis je v komentári

• models.WorldModel.java

(68, 4) TODO:calculating who is on our team and who is the opponent.

• moves.Phase.java

(80, 4) TODO:effectors into HashMap

Popis: Effectory sú uchovávané v Arrayliste, no dopytujú sa podľa Stringu, preto by bolo vhodné zvoliť inú dátovú štruktúru

• moves.Preceptors.java

(80, 4) TODO refactor into class hierarchy

Popis: V metóde je zbytočne dlhý if, je možné ho nahradiť switchom

• skills.HighSkill.java

(300, 5) TODO: does it work? should it work this way?

(323, 5) TODO: is this safe (no)? is it called from the test framework?

• trajectory.Obstales.java

(72, 12) : Nova verzia ma v nastaveniach Agent Radius 0.4. Je otazne z coho je tato hodnota 0.2 urcena.

• trajectory.TrajectoryPlanner.java

(449, 8) (468, 9) (519, 9) (534,10) TODO: premysliet, ako sa bude riesit zla nadvaznost pohybov

• AgentInfo.java

(63, 4) TODO #Bug(Agent's goal is allways left, also during second period) #Solver() #Priority() | xmarkech 2013-12-10T20:38:13.4560000Z

(247, 7) TODO:move to RoboCupLibrary?

• CommunicationTest.java

(9, 4) TODO: Communication test not finished. Insert testing parameters.

Popis: Podľa popisu sa jedná o nedokončenú úlohu tímu Androids. V ich dokumentácii som však nenašiel bližšie informácie

• sk.fiit.jim.annotation.data.MoveValidator.java

(215, 5) TODO: Replace with purpose of method. Start with verb.

sk.fiit.jim.decision

• strategy.OffensiveStrategy.java

(36, 5) Todo #Task(better check two lists ? Maybe HASH ? NumberOfMatch - one.) #Solver() #Priority() | xmarkech 2013-12-10T20:38:13.4560000Z

• tactic.oldGoalie.Goalie.java

(75, 4) Todo #Task() #Solver() #Priority() | xmarkech 2013-12-10T20:38:13.4560000Z

(93, 6) TODO - better check two lists ? Maybe HASH ? NumberOfMatch - one

Popis: Jedná sa o TODO v balíčku „oldgoalie“, preto je otázne či sa oplatí pre finálny produkt nimi zaoberať a snažiť sa ich dokončiť.

• tactic.Tactic.java

(135, 12) TODO - better check two lists ? Maybe HASH ? NumberOfMatch - one

• sk.fiit.jim.init.SkillsFromXmlLoader.java

(42, 4) TODO: is there any reason why this class is not a singleton?

sk.fiit.testframework.annotator

• Annotator.java

(108, 5) TODO:GET CHECKSUM FROM PLAYER

• AnnotatorTestCase.java

(157, 7) TODO: is there some better solution?

sk.fiit.testframework.communication.agent

• AgentJim.java

(111, 12) TODO: Only localhost now | is that still true???

• AgentManager.java

(335, 5) TODO send an exit command to agents not launched by the test framework

• IAgentManagerListener.java

(21, 8) TODO send an exit command to agents not launched by the test framework

• sk.fiit.testframework.incomplete.Mpilmplementation.java

(127, 8) TODO IMPLEMENT TRAINER

Popis: V podmienke chýba telo

• sk.fiit.testframework.moveoptimizator.MoveOptimizer.java

(143, 19) TODO: LOGIC for scoring of result

sk.fiit.testframework.ui

• controllers.TabAgentTrainingController.java

(97, 16) TODO pokracovat

• controllers.TabTournamentController.java

(72, 4) TODO: referencie na ine kontrolery - nechceme to nejak inak riesit?

GameView.java

(324, 50) (337, 51) (350, 32) (364, 35) (367, 35) TODO: treba zapocitat odchylku

(342, 4) TODO delete and remove deprecated test

Identifikovali sme všetky TODO v komentároch. Väčšinu sme rozdelil do samostatných úloh a je potrebné ich riešenie pre prehľadnosť kódu a validáciu funkcionalít. Veľká časť bola veľmi zle popísaná a vložili sme ju do tasku Spracovanie ostatných TODO.

V kóde sa nachádzali aj 2 poznámky, ktoré majú za úlohu napomôcť s lokalizáciou implementácii určitej časti, sú to: „can be removed if Zero moment point is working fine“ a „IMPLEMENT TRAINER“. Taktiež sa už jedna úloha prepojená na problematiku z komentára rieši, preto by bolo zbytočné vytvárať novú úlohu. Tieto TODO sme ponechali bez vytvorenia novej úlohy na ich riešenie.

---

V kóde bola TODO poznámka „consider relativeDistanceToTarget, consider annotation's min_distance“, úlohou bolo analyzovať a prípadne vypracovať túto poznámku.

Analyzovaním danej metódy a inžinierskeho diela tímu BAREKO, ktoré túto poznámku vpisovalo do kódu sme zistili, že daná úloha je už dokončená. Poznámku asi vytvoril autor aby nezabudol v rámci funkcionality zvážiť relatívnu vzdialenosť od cieľa a minimálnej vzdialenosti od cieľa.

TODO už bolo vypracované a nie je potrebná nová implementácia.

---

V kóde sa nachádzalo prehľadávanie dvoch listov foreach cyklami, čo sa javilo ako neefektívne riešenie. Úlohou bolo nájsť vhodnejšiu údajovú štruktúru na prácu s týmito listami a implementácia nového riešenia.

Analýza súčasného riešenia bola časovo náročná, nakoľko sa tieto štruktúry veľmi často používali pri rozhodovaní o stratégiách a taktikách. Nakoľko list obsahoval iba unikátne hodnoty, rozhodol som sa pre použitie údajovej štruktúry Set. Tá je uspôsobená na uchovávanie práve unikátnych hodnôt.

Ďalším krokom analýzy bolo sledovanie obsahu jednotlivých štruktúr. Očakával som, že menší list je podmnožinou väčšieho, čo sa ukázalo ako nepravda – z toho dôvodu som musel zavrhnúť pôvodné riešenie s porovnávaním veľkostí. Algoritmus som však upravil tak, aby zhodné hodnoty vyhľadával z menšej štruktúry kvôli vyššej rýchlosti.

Metódy s názvom getSuitability by mali mať rovnakú funkcionalitu, no stretol som sa s 3 rôznymi implementáciami, ktoré dosahovali iné výsledky. Tieto implementácie som upravil tak, aby ich výpočet bol ekvivalentný pre rovnaké vstupné dáta.

Celková úprava štruktúr ovplyvnila 52 tried.

Nové riešenie opravilo chyby predchádzajúcich výpočtov a počas testovania som sa nestretol so žiadnou komplikáciou. Rýchlosť rozhodovania pre stratégiu by mala byť omnoho vyššia.

---

Compute relative fitness to strength of kick (annotations) je TODO, ktoré sa nachádza v triede TacticalInfo v opise metódy getPassFitness. K tomuto TODO nebol žiadny ďalší komentár.

V metóde getPassFitness sa počíta fitness funkcia, ktorá by mala vyjadrovať s akou „pravdepodobnosťou“ bude prihrávka na určité miesto úspešná – nebude zachytená protihráčom. Táto fitness funkcia sa počíta na základe uhlu medzi protihráčom, miestom z ktorého sa prihráva a miestom, na ktoré sa prihráva. Hodnoty tejto fitness funkcie sú medzi 0 a 1.

Výsledná fitness funkcia je teda vypočítana na základe najmenšieho uhlu medzi smerom kopu a protihráčom.

Keďže sa hodnota počíta len z uhlov hráča,všetky typy prihrávok majú rovnakú fitness. Avšak pravdepodobnosť, že protihráč zachytí prihrávku klesá so silou kopu.

V triede kick sa nachádzajú nasledovné typy kopu:

KICK_FAST

-speedKoef = 2.0

-distanceKoef = 1.0

KICK_NORMAL

-speedKoef = 1.0

-distanceKoef = 1.0

KICK_SLOW

-speedKoef = 1.0

-distanceKoef = 0.5

KICK_STRONG

-speedKoef = 1.0

-distanceKoef = 1.5

KICK_UNKNOWN

-speedKoef = 1.5

-distanceKoef = 1.5

Každý typ kopu má tri atribúty – speedKoef, distanceKoef a succesKoef, avšak succesKoef je pre všetky typy nastavený na rovnakú hodnotu – 1.0. SpeedKoef a distanceKoef vyjadrujú rýchlosť kopu a vzialenosť na akú sa kope. Inicializované su na normal kick (1.0 a 1.0) a pri rôznych typoch kopov sa menia.

Na základe použitého typu kopu na nahrávku by bolo treba upraviť fitness hodnotu. Najjednoduchším riešením by bolo priradiť každému typu kopu hodnotu, ktorou by sa fitness prenásobila (napr hodnota 1 pre kick_fast a hodnota 0.5 pre kick_slow, pre ostatné typy niekde medzi). Tieto hodnoty by následne mohli byť upravené po testovaní. Ďalšou otázkou nad ktorou by sa bolo dobré zamyslieť je, či by nebolo vhodné počítať aj so vzialenosťou protihráča, nie len uhlom.

V tomto dokumente sa nachádza návrh riešenia úlohy na úpravu výpočtu fitness. Úloha zatiaľ nie je naprogramovaná, keďže v tejto faze projektu ešte Jim nehrá proti protihráčom, takže otestovanie vypracovanej úlohy by bolo nemožné. Tento dokument teda slúži ako podklad pre prácu tímu, ktorý bude túto čast projektu riešiť.

---

Effectory sú uchovávané v ArrayListe, no dopytujú sa podľa Stringu, preto by bolo vhodné zvoliť inú dátovú štruktúru.

ZoznamefektorovjeuchovávanývHashMap-e, pričom kľúčom je názov Joint-u. Zmeny bolo potrebné vykonať v nasledovných triedach:

• JointPlacement.java
• Phase.java
• SkillsFromXmlLoader.java

Program je teraz rýchlejší, lebo nie je potrebné iterovať and ArrayList-om.

---

V triede sk.fiit.jim.agent.parsing.Preceptors.java bol zbytočne dlhý if, ktorý bolo treba nahradiť vhodnejším a rýchlejším riešením.

Dlhý if v metóde processPerceptor bol nahradený switchom.

Riešenie so switchom je efektívnejšie.

---

Nadväznosť pohybov je riešená v triede sk.fiit.jim.agent.trajectory.TrajectoryPlanner.java

Všeobecne sa trajektória tvorí zo zoznamu všetkých pohybov typu walk a rotate podľa ich atribútov – dĺžka kroku a uhol otočenia. Trajektória sa skladá postupne z najdlhších krokov a najväčších otočení k cieľu, pričom po každom ďalšom pridanom pohybe sa skontroluje, koľko ešte a akých veľkých pohybov je potrebné pridať na dosiahnutie cieľa.

Je treba podotknúť, že v triede je aj riešenie prekážok v chôdzi – iní hráči, ale v tomto prípade nebolo potrebné brať v úvahu trajektóriu s prekážkami.

Trajektória sa plánuje naraz pre 5 odlišných odchýliek v zmysle uhla a vzdialenosti od požadovaného cieľa. Následne sa z nich vyberie 1 najlepšia – trajektória s najkratším celkovým časom vykonávania.

Pred úpravou sa trajektória plánovala znovu bez ohľadu na úspešnosť po prejdení ¾ vzdialenosti. Robot vďaka strate stability často spadol a celkový čas na dosiahnutie cieľa sa tak iba zväčšil.

int walkNum = (int) ((distance/stdWalk.getMove().getX().getAvg()) * 0.75);

Tento parameter sme jednoducho odstránili. Hráč takto vykoná celú plánovanú trasu a následne vypočíta prípadnú úpravu k cieľu.

int walkNum = (int) ((distance/stdWalk.getMove().getX().getAvg()) );

Nadväznosť pohybov sa realizuje volaním metódy sequenceCheck v rámci metódy walk. Overí sa, či vybraný krok môže nadväzovať na už vypočítanú trajektóriu v tejto metóde. Ak áno, metóda sequenceCheck vráti hodnotu true, inak false.

Podmienky:

1. Ak agent leží == false
2. Ak pozícia na konci pohybu nesedí s pozíciou nasledujúceho pohybu a lopty
3. Ak kĺby nie sú schopné v danej pozícii vykonať nasledujúci pohyb (príliš veľké otočenie a podobne)

Ak nasledujúci pohyb trajektórie splní niektorú z podmienok 1.-3. je vyhodnotený ako nemožný / nevhodný pre pokračovanie pohybu a hľadá a iný zo zoznamu pohybov, ktorý podmienku spĺňa.

Navrhované riešenie:

• Navrhujeme upraviť podmienku jedna a doplniť do nej pridanie pohybu vstávania (čiže podmienka 1. bude true).
• Podmienku 2. nechať nezmenenú (ak sa agent ocitne z nejakého dôvodu mimo plánovanú trajektóriu, je treba nájsť iný pohyb)
• Podmienku 3. upraviť na kontrolu polohy kĺbov a ich nastavenie pre daný pohyb, nie je dôvod pre hľadanie iného potenciálne menej vhodného pohybu v trajektórií

Plánovanie trajektórie je z pohľadu vykonávania a efektivity dosiahnutia cieľa v poriadku. Odstránením podmienky o vykonaní ¾ trajektórie sme skrátili čas pohybu na dlhšie trasy o približne 1/5 v priemere. Nadväznosť pohybov riešená v metóde sequenceCheck sme navrhli upraviť nasledovne:

• Navrhujeme upraviť podmienku 1. a doplniť do nej pridanie pohybu vstávania (čiže podmienka 1. bude true).
• Podmienku 2. nechať nezmenenú (ak sa agent ocitne z nejakého dôvodu mimo plánovanú trajektóriu, je treba nájsť iný pohyb)
• Podmienku 3. upraviť na kontrolu polohy kĺbov a ich nastavenie pre daný pohyb, nie je dôvod pre hľadanie iného potenciálne menej vhodného pohybu v trajektórií

---

V kóde sa nachádzalo ešte niekoľko zvyšných TODO komentárov, ktoré je treba spracovať. Jedná sa o vypracovanie TODO, vytvorenie tasku, ponechanie pre ďalší tým alebo prípadne odstránenie daného TODO.

(307, 5) TODO moves/walk_dynamic.xml

• Komentár sa nachádza na konci triedy WalkFastZMPOld, bez ďalšieho komentáru
• walk_dynamic.xml je xml súbor obsahujúci typ chôdze
• Keďže neboli dostupné žiadne ďalšie informácie navrhujem vytvorenie tasku pre danú úlohu (napríklad pre Andrej, ktorý ZMP už riešil) prípadne zrušenie komentáru.

(68, 4) TODO: calculating who is on our team and who is the opponent.

• Komentár je nad metódou processNewServerMessage
• Keďže sa jedná o TODO, ktoré pracuje so spoulhráčmi a protihráčmi, takže ho necháme pre ďalší tím, keďže my by sme nemali riešenie ako otestovať

(300, 5) TODO: does it work? should it work this way?

• Komentár je nad metódou checkProgress
• Jedinou úlohou metódy je vyhodiť výnimku (throws Exception)
• Jediné využitie metódy je v triede tej istej triede - HighSkill riadok 177

(323, 5) TODO: is this safe (no)? is it called from the test framework?

• Komentár je nad metódou setCurrentSkill – klasikcký setter
• Setter nie je nikde v kóde použitý
• Navrhujem vymazanie TODO

(72, 12): Nova verzia ma v nastaveniach Agent Radius 0.4. Je otazne z coho je tato hodnota 0.2 urcena.

• Premenná ROBOT_RADIUS je inicializovaná na 0.2
• Využitie premennej je v metód checkIntersection v rovnakej triede Obstacles riadok 94
• V triede MessageParserTest je premenná EXPECTED_AGENT_RADIUS nastavená na 0.4
• Bolo by treba otestovať, ako sa správa robot, ak by sme prestavili hodnotu na 0.4, a podľa toho upraviť premennú

(63, 4) TODO #Bug(Agent‘s goal is allways left, also during second period) #Solver() #Priority() | xmarkech 2013-12-10T20:38:13.4560000Z

• Jedná sa o premennú side

• Bránka, ktorá patrí nášmu tímu, je nastavená na ľavú počas oboch polčasov
• Hodnota by mala byť upravovaná v triede AgentModel v metóde processNewServerMessage

(247, 7) TODO: move to RoboCupLibrary?

• Komentár nad metódou isInHalfPlane
• Momentálne riešenie by malo byť funkčné, avšak ak by sa s tým niekto chcel pohrať tak si môže zobrať task

(215, 5) TODO: Replace with purpose of method. Start with verb.

• Komentár je nad metódou getReport – obyčajný getter
• Navrhujem odstránenie TODO

(75, 4) Todo #Task() #Solver() #Priority() | xmarkech 2013-12-10T20:38:13.4560000Z

• Nad metódou run, ktorá je celá zapoznámkovaná (treba ju prerobiť)
• Keďže my brankárov zatiaľ neriešime, ponecháme TODO pre ďalšie tímy.

(108, 5) TODO:GET CHECKSUM FROM PLAYER

• Komentár je nad podmienkou či meno pohybu sa zhoduje s očakávaným menom pohybu
• Neviem čo sa komentárom myslí, navrhujem buď ignorovať TODO alebo vytvoriť task na podrobnejšie preskúmanie

(157, 7) TODO: is there some better solution?

• V metóde destroy() v nútri try-catchu, jediné čo sa v try deje je uspanie vlákna na 2 sekundy.
• Ak by niekto chcel, može si zobrať ako task

(111, 12) TODO: Only localhost now | is that still true???

• Toto TODO nie je treba vypracovať, agent je zatiaľ schopný fungovať iba na localhoste, keďže v inom prípade nestíha spracovávať správy za požadovaný čas a stráca sa veľa informácií
• Odkonzultované priamo s product ownerom
• Vymazanie TODO

(143, 19) TODO: LOGIC for scoring of result

• Metódy scoreResult a scoreBesetResult neboli ešte implementované
• Nenašiel som žiadne komentáre k tomu, čo by funkcie mali odohnocovať
• Navrhujem task na podrobnejšie preskúmanie úlohy

(97, 16) TODO pokracovat

• V metóde RunSimulationListener
• Vôbec netuším v čom treba pokračovať
• TODO by som rád prešiel ešte na stretnutí

(72, 4) TODO: referencie na ine kontrolery - nechceme to nejak inak riesit?

• Navrhnuté riešenie cez MainFrameController, ktorý by obsahoval metódy ktoré by sa volali
• Terajšie riešenie je funkčné
• Ak by niekto chcel, tak si to môže zobrať ako task, inak by som to nechal tak

(324, 50) (337, 51) (350, 32) (364, 35) (367, 35) TODO: treba zapocitat odchylku

• Do daných výpočtov treba zapocitať odchylku
• Treba zvoliť správnu odchylku
• Nechal by som to tiež na samostatný task nech sa to poriadne otestuje

(342, 4) TODO delete and remove deprecated test

• Nad metódou pointDeviation, ktorá sa využíva iba v triede GameViewTest
• Stačí teda asi vymazať metódu (možno aj celú triedu GameViewTest

Boli prejdené zvyšné TODO, na stretnutí 8.4.2019 by som rád prešiel s ostatnými členmi tímu navrhnuté riešenia, pridal itemi do backlogu a rozvrhol úlohy.

---

Bola identifikovaná exception v triede AgentPositionCalculator keď funkcia dostala veľkosť 0.

Funkcia slúži na updatnutie polohy. Vyriešilo sa to tak, že ak je veľkosť polohy 0, tak sa neupdatne poloha, updatne sa až po ďalšej zmene.

Bola implementovaná podmienka v metóde updatePosition.

---

Funkcionalita triedy SkillsFromXmlLoader.java je používaná na mnohých miestach v projektu, vždy však pracujeme s novou inštanciou.

Návrhový vzor singleton zabezpečuje, že vždy pracuje s nanajvýš jednou inštanciou triedy. V našom prípade tak zabránime zbytočnému vytváraniu objektov a réžii spojenej s ich mazaním. Zmena sa dotkla nasledovných tried v module Jim:

• KickTestHighSkill
• JimWindowController
• Main
• SkillsFromXmlLoader
• TestFrameworkMain
• LowSkillTest
• SkillsFromXmlLoader

---

Na základe komentára v triede sk.fiit.testframework.communication.agent.AgentManager.java :

#Removes an agent that was started by the test framework and terminates its process.

# Does nothing for agents that were not launched by the test framework.

# @param agent the agent to remove

# TODO send an exit command to agents not launched by the test framework

Máme implementovať posielanie ukončovacieho príkazu pre agentov, ktorý neboli spustený testovacím frameworkom.

Na základe konzultácií na stretnutí s vedúcim projektu sme sa dohodli o zamietnutí/nevypracovaní tejto úlohy, pretože dôležitosť riešenia tejto úlohy nie je podstatná a nemá dopad resp. prínos pre iné úlohy, ktoré riešime.

Úloha bola zatvorená a komentáre v kóde triedy AgentManager boli doplnené.

Súvisiace triedy:

sk.fiit.testframework.communication.agent.IAgentManagerListener.java

---

Náplňou úlohy je skontrolovať triedy a metódy zaoberajúce sa orientáciou a pozíciou hráča resp. zmenou pozície, ktoré sú na vyššej úrovni ako trieda Vector3D, ktorá obsahuje základnú logiku bodov a počítania súradníc. V nej sú momentálne prehodené súradnicové osi X a Y, čiže po ich spätnej oprave bolo potrebné urobiť zmeny aj na vyšších úrovniach, čo bolo náplňou tejto úlohy.

Snaha bola nájsť miesta vo vyšších úrovniach spracovania súradnicového systému, kde by boli osi očividne prehodené. Nájdené použitia na základe „konštruktorov“ Vector3D.cartesian a Vector3D.spherical boli skontrolované a prípadné opačné použitia osí boli prehodené a otestované. Išlo hlavne o triedy HighSkillov (Walk apod.) a triedy, ktoré sa starajú o videnie a počítanie rotácie/polohy hráča. Skúšaním rôznych kombinácií úprav (už s implementovanou opravou v triede Vector3D) však neboli dosiahnuté očakávané výsledky v podobe správnej orientácie hráča na ihrisku.

Aj napriek snahe neboli miesta, ktoré by mohli dezorientáciu spôsobovať nájdené, a teda požadovaná oprava nebola zrealizovaná. Jedným z veľkých problémov je slabá alebo chýbajúca dokumentácia na wiki k logike, ktorá sa o spomínané veci stará. Aby sme boli schopní chybu odstrániť, museli by sme od základov analyzovať celý kód a prekopať súčasné výpočty súradníc. Zhodli sme sa, že z dôvodu náročnosti v spojení s minimálnym prínosom (keďže všetka hráčova logika už je postavená s tým, že sú osi prehodené) sa nebudeme ďalej danej úlohe venovať.

---

Ide to vypracovanie jedného z TODO, ktoré boli pridané niektorým z predošlých tímov. Úloha sa viaže k triede sk.fiit.jim.agent.models.prediction.Prophet, kde sa vypočítava budúca poloha lopty a hráčov. Trieda bola vytvorená ako experiment a tím si nebol istý, či funguje správne.

Po otestovaní výpočtov bolo zistené, že kvôli nepresnostiam v ostatných výpočtoch polohy, nie sú ani tieto úplne presné. Vypočítané hodnoty sa používajú pri odhadovaní stratégie v triede sk.fiit.jim.agent.models.TacticalInfo. Tieto odhady však nikde nie sú volané, čiže reálne sa táto funkcionalita momentálne nepoužíva.

V triede neboli vykonané žiadne zmeny ale zatiaľ ju nevymažeme, pretože by mohla byť použitá v budúcnosti.

---

Analýzou fungovania plánovania trajektórie v triede TrajectoryPlanner a MoveValidator sme zistili, že metóda sequenceCheck nie je úplná a mala v sebe priestor na zmeny – úpravu podmienok pri zlej nadväznosti pohybov.

• Navrhujeme upraviť podmienku 1. a doplniť do nej pridanie pohybu vstávania (čiže podmienka 1. bude true).
• Podmienku 2. nechať nezmenenú (ak sa agent ocitne z nejakého dôvodu mimo plánovanú trajektóriu, je treba nájsť iný pohyb)
• Podmienku 3. upraviť na kontrolu polohy kĺbov a ich nastavenie pre daný pohyb, nie je dôvod pre hľadanie iného potenciálne menej vhodného pohybu v trajektórií

Podmienka 1. bola pridaná do triedy sk.fiit.jim.annotation.data.MoveValidator.java.

V kóde boli pridané riadky v metóde sequenceCheck:

HighSkillPlanner planner = HighSkillRunner.getPlanner();

planner.addHighskillAsFirst(new GetUp());

valid = true

Podmienka 2. nebola zmenená, podmienka 3. po konzultácií zatiaľ nezmenená.

Po opísaných zmenách bolo plánovanie trajektórie agenta funkčné.

Jedná sa o vypracovanie identitikovaného TODO. V Triede sk.fiit.jim.agent.AgentInfo sa nachádza metóda isInHalfPlane (), ktorá by mala byť presunutá do modulu RoboCulLibrary. Metóda vypočitáva, či bod typu Vector3D spadá do polroviny.

Metóda bola presunutá do triedy sk.fiit.robocup.library.geometry.Vector3D a bola upravená, aby používala súradnice z objektu, nie zo vstupného vektora.

Presunutím bolo splnené TODO, ktoré bolo vytvorené zrejme z dôvodu, že sa z abstratkného hľadiska metóda nehodila do danej triedy.

---

V tejto úlohe sa jedná o vypracovanie identifikovaného TODO. V Triede sk.fiit.testframework.ui.controllers.TabTournamentController sa nachádza metóda updateTournamentTab(), ktorá by mala byť presunutá do triedy sk.fiit.testframework.ui.controllers.MainFrameController, pretože v triede TabTournamentController sa pomocou agregácie volajú metódy triedy MainFrameController.

Pôvodné znenie komentára/úlohy:

„TODO: referencie na iné kontrolery - nechceme to nejak inak riešiť? Navrhnuté riešenie cez MainFrameController, ktorý by obsahoval metódy ktoré by sa volali“.

Metóda updateTournamentTab() bola presunutá do triedy sk.fiit.testframework.ui.controllers.MainFrameController a bola upravená, viď. obrázok nižšie. Metóda updateTournamentTab() sa v triede MainFrameController volá v metóde update() → run(), ktorá je prepísaná v danej triede. Presunutím metódy bolo splnené TODO, ktoré bolo vytvorené zrejme z dôvodu, že sa z abstratkného hľadiska metóda nehodila do danej triedy. V triede TabTournamentController sa metóda zakomentovala s poznámkou, že metóda updateTournamentTab() sa presunula do inej triedy a príznak TODO sa odobral.

---

Počas prehľadávania som z Moves odstránil nepoužívané súbory, ktoré nemali žiadnu výpovednú hodnotu alebo neočakávame ich opätovné vyžitie. Tieto súbory sú:

drepyII.xml

filipskuska.xml

hlavaaruky.xml

nahlavu.xml

rollback2.xml

ruky.xml

shot_left.xml

sit_down.xml

step_circ_left.xml

step_circ_left_small.xml

step_circ_right.xml

step_circ_right_small.xml

test_turn_left.xml

test_turn_right.xml

uvidime.xml

walk_fine.xml

walk_fine_fast.xml

walk_turn_left.xml

walk_turn_right.xml

Ďalšie súbory sa nachádzali buď v priečinkoch označených ako „OLD“. Ďalšie väčšia množina súborov, ktoré boli odstránené boli súbory, ktoré si predefinujú programovacie editory – tieto súbory sú po zavedení Mavenu nepodstatné.

Agent's goal is allwazs left, also during second period je TODO, ktoré sa nachádza v triede AgentInfo.java pri premennej sid

Táto premenná je inicializovaná na hodnotu LEFT, čo vyjadruje, že naša bránka je na ľavej strane, a útočíme na pravú stranu.

Hodnota tejto premennej je upravovaná v triede AgentModel.java v metóde processNewServerMessaage.

Upravovanie tejto hodnoty je závislé od dvoch ďalších premenných. Prvou premennou je HALF_TIME_CHANGE_SIDES, čo je booleanovská premenná vyjadrujúca, či sa počas počasu majú alebo nemajú vymeniť strany. Druhou premennou je OUR_SIDE_IS_LEFT, ktorá je inicializovaná na null, a jej hodnota môže byť upravená správou zo serveru. Ak zo server pride nastavenie premennej na true, tak side sa taktiež upraví na LEFT, ale ak pride false tak sa side upraví na RIGHT.V prípade, ak má premenná HALF_TIME_CHANGE_SIDES hodnotu true, a premenná OUR_SIDE_IS_LEFT ostane null ( čo znamená, že naša strana nie je určená serverom), hodnota premennej side sa správne počas polčasu zmení z LEFT na RIGHT alebo opačne. Avšak táto zmena pre “diváka” nič neupraví, keďže z pohľadu kamery sa stale útočí z ľavej strany na pravú, pričom aj súradnice ihriska ostávajú rovnaké – naša bránka ma zápornú x-ovú súradnicu a súperová kladnú. Preto nie je jasné, či premenná nie je správne využívana, alebo sa len hodnoty prepočítavajú tak, aby všetko ostalo na prvý pohľad nezmenené.

Navrhnutý test na overenie funkcie strán by bol vytvorenie dvoch agentov v dvoch proti sebe hrajúcich tímoch a testovaním funkcie agentov pre rôzne nastavenia premennej side.