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.
