Som tittelen hinter om så var det en del som gikk galt. Først var det et forsøk på å fortsette å bruke koden som ble brukt under kartleggingen av overflaten, ved å se på hvor raketten ville være i forhold til vårt referansepunkt. Dette innså vi ikke fungerte av en eller annen grunn. Vi brukte samme kode, med noen justeringer, slik at vi kunne putte inn en start vinkel som var vinkelen der den forrige simuleringen stoppet. Planen var å kjøre simuleringer etter hverandre som tok for seg ulike manøvrer, eks, en gang for selve runden rundt planeten. Derifra skulle den neste bli for å fly nærmere overflaten, for så å kunne simulere for en egen definert tid som skulle være siste før vi skøyt ut landingsmodulen. Eksempel på problemer var at vi etter å ha kartlagt overflaten plutselig hadde tilbakelagt en større avstand enn forventet. Dette gjorde at vi måtte ta vinklene for landings plassene med en klype salt. Hele ideen bak denne koden var å kunne utføre tester automatisk, og uten å måtte drive så mye med å manuelle input. Ikke bare var posisjonen feil i forhold til det vi fikk når vi orienterte oss, men vinklene ble også helt feil. Etter en liten stund var dette en tapt sak, og dermed stoppet vi å tukle med denne koden. Problemet var enten at vi ikke inkluderte atmosfæren under simuleringene, men i og med at vår orientering lå lenger fremme enn det vår simulering forutså gjør den muligheten lite sannsynlig. Det har derimot blitt funnet en liten feil eller bug i hovedsystemet som må rapporteres til HQ for nærmere inspeksjon, men denne skulle ikke ha vært stor nok til å forårsake så store avvik som vi fikk. Koden i seg selv er mer eller mindre samme som vi har brukt tidligere som da ga oss riktig posisjoner. Så hva feilen var, er vi usikre på, kan ha vært tidsstegene, men med så stor unøyaktighet var det ikke noe poeng å fikse opp i det.
Så uten noe å kunne navigere med eller forutse hvor vi ville ende opp etter en gitt tid måtte vi ty til gode gammeldagse metoder, visuell navigasjon. Heldigvis har vi allerede kartlagt hele overflaten, så det gjaldt bare å komme nærme nok, og prøve å gjenkjenne terrenget. Vi brukte tidligere kode til å komme oss nærme nok, og gjorde så umiddelbart etter at vi hadde fullført kartleggingen. Desto lengere vi ventet, jo mindre av kodene kunne brukes uten for store usikkerheter.
Av noe tekniske årsaker fikk vi ikke \(\rho(r)\) fort nok, og måtte dermed klare oss uten. Vel heldigvis, som er det man ville ha sagt, så fikk vi den etter en stund. Det var bare en liten hake med den. \(\rho(r)\) vi kom fram til etter spektral analysen av atmosfæren lot oss ikke simulere landingen, og var dermed også feil, og upålitelig. Hvordan vi vet dette kommer av at vi fikk det bekreftet senere, men også at våre simuleringer begynte å oscillere om det tok for lang tid. Dette kan tyde på at implementeringen av fysikken var feil eller at \(\rho (r)\) var feil. Mest sannsynlig en kombinasjon. Fysikken bak det var bare å bruke euler-cromer og bruke summen av kreftene i en gitt avstand til å flytte landingsmodulen nedover. hele prosessen ble i bunn å grunn et en dimensjonalt problem, på grunn av hvordan vi utførte landingen. Dette vil bli oppklart senere.
Uten \(\rho\) er det vanskelig å forutse om vi vil brenne opp på vei ned, på grunn av at \(Pa = \frac{F_d}{A}\) motstandstrykket ikke kunne bli mer enn \(Pa > 10^7\ N/m^2\), går det over denne grensen brenner vi opp. Vi kan heller ikke finne ut om fallskjermen vil gå i stykker på grunn av at \(F_d > 250\ kN\). Det at vi ikke har en pålitelig \(\rho (r)\) gjør ting vrient, men ikke umulig. Det er på tide å legge en ny plan.
Koden vi hadde tenkt til å bruke ga oss følgende resultater som et eksempel. Her har vi plottet med bruk av kun thruster. For alle plottene har vi satt at atmosfæren starter å påvirke oss i en høyde på \(200\ km\) over bakken.
