Bluetooth kommunikation (fortsat)

..fortsat fra forrige blog indlæg

3. Teste stien som vi får tilbage fra pc.
Det viste sig at stien vi fik tilbage fra bluetooth var korrekt. Fejlen vi beskrev tidligere viste sig at være en synkroniserings fejl imellem klient og server, som var hurtigt løst.
Herefter fik vi altid udregnet de korrekte stier og overført dem korrekt tilbage til NXT'en.


4. Opdagelse af mystisk fejl
Inden vi besluttede os for at benytte bluetooth kommunikation for at undgå hukommelsesproblemer, omskrev vi pathfinding algoritmen til at genbruge de lister der er nødvendige når man laver dybde-først søgninger (dette var inden vi eksperimenterede med bredde først). Hver Node gemmer nu fast sine 4 faste naober, samt en ArrayList for hver af disse naboer, som bliver genbrugt når findpath kaldes på hver nabo node. Dermed er algoritmen heller ikke rekursiv mere og der skulle ikke leake noget memory.
Efter at have implementeret denne algoritme kunne vi dog konstatere at vo stadigvæk løb ind i en fejl i andet kald af findPath. Denne gang ikke en hukommelses fejl, men en IndexOutOfBounds. Derfor implementerede vi Bluethooth til sidst da vi ikke kunne finde årsagen.
Nu viser det sig dog at vi får præcist samme fejl - IndexOutOfBoundsException.
Efter intensiv debugging breder mystikken sig endnu mere. Vi formår at kalde PC'en over bluetooth. Vi ved at PC'en returnerer den korrekte sti og at NXT'en modtager den. Men når så findpath metoden returnerer får vi fejlen - og det er på trods af at det første vi gør efter at metoden returnerer, er at kalde Button.LEFT.waitForPressAndRelease(); og ikke andet (af debugging årsager selvfølgelig).

Til sidst fandt vi ud af at det var kun i det tilfælde hvor vi finder en sti fra grid 3,0 til grid 8,0 (vores to referencepunkter) at fejlen opstår. Selv hvis vi lavede en sti fra 3,0 til 7,0 som går igennem 8,0 virker det som det skal.
Vi har endnu ikke kunne finde årsagen til dette problem - vi ved at dette grid er initialiseret korrekt, vi ved at vores sti bliver bygget korrekt, vi ved at vi ikke bruger stien eller noget andet til noget som helst efter at vi får returneret stien (i vores debug setup). Vores mistanke falder på en fejl i Lejos' håndtering af hukommelse, men det er umuligt at vide med sikkerhed.


4. Løsning
Vi fandt dog en måde at omgå problemet på - mere eller mindre tilfældigt. I går havde vi overvejet at sætte et af felterne til ikke at være optaget af en forhindring. Nærmere betegnet et af de felter der kun havde en boulder forhindring på sig.
Da vi gjorde dette, åbnede der sig en anden sti fra 3,0 til 8,0 og vores robot kunne åbenbart godt tolerere denne. Det skal siges at dette felt ikke havde noget at gøre med den anden sti, så det har ikke været dette der har været den oprindelig fejlårsag.

Efter at have konstateret dette er vi gået tilbage til at finde stierne på NXT'en i stedet for over bluetooth. Dette er via den ikke-rekursive dybde-først algoritme som beskrevet ovenover her. Det kom som en overraskelse at det kunne lade sig gøre uden at løbe tør for hukommelse, men det er godt nyt for vores projekt.

I morgen vil vi så endelig have mulighed for at fintune navigeringen yderligere, så vi forhåbentligt kan navigere stabilt rundt på vores spilleplade. Hele denne debugging session med vores mystiske fejl har dog nok kostet os så lang tid, at der ikke bliver tid til at løse alle de opgaver der er på spillepladen.
Som beskrevet tidligere er dette dog heller ikke hovedefokus, da det vigtigste er at kunne komme fra forhindring til forhindring på en konsistent og sikker måde.