NASA wil opstartproblemen met Mars-drone Ingenuity oplossen met software-update

De NASA gaat een software-update sturen naar de Ingenuity-helikopter op Mars. Het voertuig zou dit weekend zijn eerste vlucht maken, maar dat lukte niet door een fout. De NASA zegt nu dat een software-update dat moet oplossen.

De update wordt naar de robot gestuurd die werd meegenomen met de Perseverance-rover die op dit moment op het Mars-oppervlak staat. Ingenuity had afgelopen zondag voor het eerst een vlucht moeten maken, maar dat werd uitgesteld. De helikopter weigerde bij een rotortest naar de definitieve vluchtstand te gaan. Daardoor werd de vlucht uitgesteld. De NASA schrijft nu dat er in de komende dagen een update wordt uitgebracht.

Het team achter de helikopter heeft verschillende oplossingen onderzocht, maar kwam tot de conclusie dat de enige mogelijkheid is om de flight control software aan te passen en volledig opnieuw te installeren. In die update worden aanpassingen gedaan in de volgorde waarin de vluchtprocessen opstarten.

Het gaat daarom nog langer duren dan gepland voordat de helikopter kan vliegen. Het aanvankelijke idee was om dat komende woensdag te doen, maar inmiddels 'is de tijdlijn fluïde'. De NASA wil de software in stappen uitrollen. Eerst moet de software geschreven worden, maar vooral het testen en valideren van de update gaat veel tijd kosten. De NASA zegt dat de helikopter verder in goede staat verkeert. Ergens in de komende week wordt een nieuwe datum genoemd waarop de historische vlucht moet plaatsvinden.

Ingenuity

Door Tijs Hofmans

Nieuwscoördinator

13-04-2021 • 08:51

133

Reacties (133)

133
130
73
10
0
30
Wijzig sortering
Hoe lang zou het duren als je de update van aarde naar Mars verzend en daadwerkelijk wordt uitgevoerd? Helaas kan ik hierover niets in het artikel terugvinden.

[Reactie gewijzigd door aliberto op 24 juli 2024 01:41]

Op de NASA website staat het volgende:

The data rate direct-to-Earth varies from about 500 bits per second to 32,000 bits per second (roughly half as fast as a standard home modem).

Neem als gemiddelde 16.000 bits en stel dat de patch 5 MB is duurt dit 17 uur? Het is even geleden dat ik een 56k modem had.
Missies communiceren tegenwoordig via de Mars Reconnaissance Orbiter. Deze kan hogere snelheden halen. Ik kan alleen niet helemaal goed uit de bronnen halen of die snelheid bi-directioneel hetzelfde is.
Mars Reconnaissance Orbiter sends data to Earth for 10 to 11 hours, and does that for about 700 days. The data rate is about 0.5 to 4 megabits per second.
Voor zover ik heb begrepen, gebruikt de helicopter de rover als 'thuis basis'. Dus vanaf de Orbiter gaat het signaal via Perseverance naar Ingenuity?
Ik verwacht van wel al heb ik dit nog niet uitgezocht. Ik verwacht alleen niet dat ze Ingenuity uitgerust hebben met de mogelijkheid om met Orbiter te communiceren.
Voor live informatie over de communicatie over het 'Deep Space Network': https://eyes.nasa.gov/dsn/dsn.html

Het beantwoord alleen niet helemaal de vraag, want de communicatie gaat inderdaad via de Orbiter en die heeft een hogere brandbreedte. Daarnaast switched dit netwerk continue tussen de verschillende satellieten in het zonnestelsel.
Voor zover ik weet is alle communicatie directional: er wordt altijd gestuurd of ontvangen, niet tegelijkertijd (is denk ik ook wel ingewikkeld met de enorme vertragingen door de lichtsnelheid: bij Voager is die meer dan anderhalve dag inmiddels)
16kb = 0.002 MB (bit to Byte)
5 / 0.002 = 2500 seconden = 41.7 minuten
Of doe ik nu wat verkeerd?

Maar goed, zowel de snelheid van de verbinding als de tijd die de verbinding nodig heeft om de afstand af te leggen wisselt dus nogal. 5MB lijkt me ook vrij weinig, maar wel mogelijk. En hoe lang de hardware doet over installatie, zeker als elke stap getest moet worden, lijkt me ook nogal een factor. Kan me voorstellen dat de ingenieurs hier liever geen uitspraken over doen.
Met 5MB kan je een raket lanceren, aansturen en vervolgens terug sturen naar aarde. Inclusief OS en netwerk drivers etc.
Wellicht. Maar tegenwoordig draaien ook raketten gewoon op een Linux.
Dat past prima op 5MB.
systemd zullen ze daar wel niet voor nodig hebben vermoed ik :)
Waarom lijkt 5 MB je weinig? Niet iedereen brengt patches van 32 GB uit zoals game-ontwikkelaars dat tegenwoordig graag doen.
Eens.
Hangt af van aantal onderdelen.
Moet er een volledige update gestuurd worden? Of is er"slechts" een deel nodig?

Kan er gecomprimeerd worden?

Ik kom uit het tijdperk dat er "geworsteld" moest worden met elk bitje. Dat betekende dat je vernuftige "subroutines" maakte die meervoudig gebruikt konden worden waardoor efficiënt de omvang "gedrukt" werd. Scheelde veel kostbare bits. Uiteraard ook in het huidige tijdperk gewerkt waar "omvang" weinig meer betekent. Behalve performance en debuggen dan...

Hier dus noodzakelijk.
De Ingenuity helicopter draait op linux. Ik kan niet vinden hoe groot de firmware is, maar de SOC is een Snapdragon 801.

Hoewel er linux distributies zijn die op een floppy passen zal het mij niet verbazen als de variant in Ingenuity aanzienlijk groter is.

Ter referentie, vroegah spendeerde ik wel eens twintig minuten tot een half uur om een MP3tje te downloaden. Die 41.7 minuten lijkt mij dan ook erg redelijk. Hopen dat niemand de telefoon oppikt als de update bijna binnen is!
Geestige Amerikanen.... Zit als sinds jaar en dag op een 500 lijn.... Half as fast.... Bij die snelheden worden niet alleen mijn kids gek, maar ik ook
Ik denk dat de "packet loss" wel iets groter is dan over een utp kabeltje, stel dat er 3x verificatie moet worden verstuurd om geen data loss te hebben.

Lijkt me knap lastig om foutief een BIOS te updaten door 1 bit flip
"Een radiosignaal vanaf Mars doet er dus 3,3 tot 21 minuten over" aldus een snelle Google search. Ik mis dit zelf ook in het artikel eerlijk gezegd. Dit zijn het soort feitjes waar je een nieuwsbericht interessanter en leuker mee kan maken.
Dat is natuurlijk alleen maar de latency. De echte duur ligt ook aan de bandbreedte die er beschikbaar is tussen het Deep Space Netwerk en de Mars Mars reconnaissance orbiter die het signaal weer doorstuurd naar de grond. En natuurlijk de grootte van de update. De bandbreedte van het DSN naar de Mars reconnaissance orbiter kan 2 MBps halen. Maar niet in alle gevallen.

edit: verkeerde waarde voor DNS-Mars bandbreedte

[Reactie gewijzigd door hiostu op 24 juli 2024 01:41]

En hier kun je zien hoe dat DSN eruit ziet, waar de grondstations staan en waar ze momenteel mee communiceren. Echt heel mooi om te zien.
Ben ik de enige die alleen een zwarte pagina ziet op die link?
Ik zie de website wel gewoon normaal, volgens mij.
Dat is toch eigenaardig, werkt niet, zowel Firefox als Edge geprobeerd. Het werkt wel op mijn iPhone, zelfde internetverbinding 8)7
Misschien een zwart gat?
Blijft altijd mooi om te zien als er dan weer een verbinding is met voyager 2 _/-\o_
RANGE: 18.96 billion km
ROUND-TRIP LIGHT TIME: 1.46 days
Ja gaaf is dat. Van een 'verbinding' kun je eigenlijk nauwelijks spreken, met zo'n roundtrip time. _/-\o_
dit vind ik dus een leuk weetje. :)
Dit zijn het soort feitjes waar je een nieuwsbericht interessanter en leuker mee kan maken.
er zijn veel leuke feitjes over Mars te vertellen, maar is het relevant voor dit artikel? De vertraging zal vooral zitten in het ontwikkelen en testen van de code, die maximaal 21 minuten vertraging in verzenden zal geen significante rol spelen. Ik zou het ook interessant vinden welke programmeertaal ze gebruiken, hoe groot het programma is, of ze een standaard protocool gebruiken of alles speciaal voor deze missie is ontwikkeld etc.

Ik vermoed dat het programma eerst vanaf aarde naar een satelliet ond Mars wordt gestuurd, dat deze het naar Perseverance stuurt, dat deze een checksum controleert vooraleer het naar Ingenuity te sturen, dat deze eerst alles in zijn geheugen zet, dan de checksum controleert, dan het naar opslag kopieert zonder de oorspronkelijke software te verwijderen, dan weer een checksum controleert, vervolgens de bootloader aanpast om het nieuwe programma te starten en dan zichzelf reset.

Dat is niet alleen interessant, maar veel relevanter voor dit artikel.
nee, want dat is allemaal niet specifiek aan Mars. juist dat je een OTU (over the universe) update doet is een leuk feitje waar ik meteen op trigger.
nee, want dat is allemaal niet specifiek aan Mars.
Welk deel is precies niet specifiek aan Mars? De Orbiter die als relay station fugeert? De hoge mate van stabiliteit die vereist is om te voorkomen dat Ingenuity gebricked wordt?
over the universe
Voor alle kennis die ik over het heelal heb is Mars heel dichtbij, dus om dit nou "Over the Universe" te noemen doet een beetje te kort aan kosmische proporties. Maar dat zou je ook kunnen zeggen over Starship natuurlijk.
En Perseverance installeert bij haar eigen software dan volgens mij eerst op 1 van de 2 computers aan boord zodat desnoods de 2e computer de oude versie kan terugzetten mocht dat nodig zijn.

Of de computer van Ingenuity een backup heeft weet ik niet zeker Die draait Linux overigens. Ik dacht ergens gelezen te hebben dat als daar wat misgaat tijdens vliegen het ding dan supersnel reboot en dan de controle weer overneemt. Het zal geen standaard Ubuntu server zijn wat er draait :-)

[Reactie gewijzigd door Loy op 24 juli 2024 01:41]

Maar dan krijgt het al snel weer een Pro sticker... dus dan maar googelen
Ik wilde je neermodden vanwege de impliciete negatieve toon, maar je hebt natuurlijk gelijk. Een artikel waarin gewoon nieuws zonder al teveel diepgang wordt gegeven hoort thuis in het "frontpage"-aanbod. Als we verwachten dat de redacteurs meer informatie met betrekking tot het bericht opzoeken en hier een mooi verhaaltje over gaan typen dan gaat dat de redactie meer tijd en dus geld kosten en dan willen ze dat geld terugverdienen. Het zou natuurlijk leuk zijn als het artikel een soort wiki-pagina was, dat jij en ik dit soort informatie toe kunnen voegen om het artikel beter te maken, maar volgens mij is een nieuwswiki nog nooit succesvol geweest.
Een nieuwswiki zou hier wel kunnen op basis van het karma systeem. Vaak lees ik het artikel niet eens want dat heb ik dan wel op nu.nl/tech of ergens anders eerder gelezen en ga ik meteen door naar de reacties.
Hier idem. De nieuwsartikelen scan ik snel en ga dan door naar de comments. Er is een leuke meme over experts in de comment-sectie (imgur), maar voor T.net geldt dat dus echt :+
Tussen de 4 en 24 minuten. Afhankelijk van de afstand. gemiddeld dus zo'n 14 minuten.

edit: Link

[Reactie gewijzigd door Hu9o op 24 juli 2024 01:41]

Ongeveer 3 min nu voor iets vanaf aarde naar Mars te sturen. Met 2mbit/s.
Software update zal in stappen gaan.
Dus opsturen. Controleren of het is aangekomen. Uitvoeren. Opnieuw checken. Etc. Al met al denk ik dat ze een halve dag nodig hebben
Ok dus de software moet eerst geschreven worden...Getest en uitgerold op de drone.

Waarom noemen ze het eigenlijk helikopter en geen drone? Wat is het verschil tussen een helikopter en een drone?
Omdat 'drone' een algemeen modewoord is. Je wil niet weten hoeveel mensen mijn quadcopter een drone noemen, terwijl ik hem toch echt zelf bestuur. ;)
Een drone is alles wat onbemand is en vliegt. Daar valt van alles onder, dit is toevallig een helikopter.
Nou ja, deze drone vliegt dus niet, dat is precies het probleem :+
Wellicht omdat helikopter specifieker is? Een drone kan een heleboel propulsie methoden hebben, de belangrijkste eigenschap van een drone is dat hij niet bemand is. De belangrijkste eigenschap van een helikopter is de wieken op de boven kant.

Dat is in ieder geval het idee dat ik heb.
Een drone is onbemand.
Een helikopter kan een drone zijn, maar hoeft dat niet. Of iets een drone is wordt bepaald of er een menselijke bestuurder in het voertuig zit. Met nadruk op bestuurder, want als het voertuig zelf vliegt en er zit een menselijke passagier in dan is het nog steeds een drone.

Helikopter verwijst nu voornamelijk naar de aandrijving. Een helikopter vliegt met behulp van een rotor die zorgt voor lift. Doorgaans spreken we van een helikopter als deze 1 of 2 rotoren heeft. Wanneer er meerdere van deze rotoren op een voertuig zitten dan kun je spreken van bv een quadcopter (4) of octocopter (8). Maar uiteindelijk zijn de laatste 2 ook gewoon helikopters.
Wat is nu de oorzaak? Ik vind het toch wel apart dat de software niet werkt, hebben ze dat niet getest? In elk geval dat is mijn eerste gedachte. Ik vraag me af welke complicatie ze op aarde niet konden testen, zoals de 21 minuten latency.
Wat ik zo snel kon vinden op de site van NASA is dit.
During a high-speed spin test of the rotors on Friday, the command sequence controlling the test ended early due to a “watchdog” timer expiration. This occurred as it was trying to transition the flight computer from ‘Pre-Flight’ to ‘Flight’ mode. The helicopter is safe and healthy and communicated its full telemetry set to Earth.

The watchdog timer oversees the command sequence and alerts the system to any potential issues. It helps the system stay safe by not proceeding if an issue is observed and worked as planned.
Haha die testen is voor dummies! Althans dat vonden the rocket enigineers van Nasa waarschijnlijk.
Trouwens, als programmeur/tester, vergeet je altijd wel iets.... Noem mij een software die geen enkel fout heeft ?

[Reactie gewijzigd door Jemboy op 24 juli 2024 01:41]

NASA's software voor de Space Shuttle had 0 fouten. Maar die code heeft duizenden USD's gekost per regel :) Jarenlang is daar aan gewerkt door een leger programmeurs.

NASA's software is marktleider als het op fouten per 1000 regels code aan komt. Het gemiddelde is ~15 per KLOC (thousand lines of code), Microsoft zit er wat onder met ~0.5. NASA gaat met sommige software naar de 0.
console.log("Hello world!");
Die 21 minuten latency is niet van belang.
Ingenuity werkt autonoom en heeft dus geen externe aansturing nodig. Ingenuity communiceert natuurlijk wel, maar met Perseverance, de rover die op enkele tientallen meters afstand staat. De software update zal dan ook eerst ge-upload worden naar Perseverance en van daar worden ge-upload naar Ingenuity.
z’n meest standaard instructies
Welk instructies waren dat dan? Voor zover ik heb gelezen ging het om fout tijdens de transitie van een startup-modus naar een vlucht-modus. Ik neem aan dat daar een aantal controles aan vooraf gaan en wat mij het meest waarschijnlijk lijkt is dat bij die controle een parameter buiten zijn limieten liep en dat de procedure is stopgezet.

Zo lang we niet weten wat er mis is gegaan, vindt ik het nogal voorbarig om van een "grote misser" te spreken.
Je beseft dat die helicopter op een andere planeet staat waar je nog niet alles van weet en dat tijdens testen er dus zaken zullen waar tijdens testen niet naar is gekeken? Bijvoorbeeld hoe de rotoren zich op Mars, met andere luchtsamenstelling en zwaartekracht gedragen? Men test wat men kan, maar dit is een wetenschappelijk experiment, geen commercieel product.
Dit is een goed artikel over de simulatie etc achter die helicopter: https://spectrum.ieee.org...-fly-a-helicopter-on-mars

Ze zijn erg voorzichtig, er is niks kapot gegaan etc. Minder voorzichtig zijn en na al die jaren ontwikkeling te onvoorzichtig zijn zou pas echt een enorme misser zijn.
Precies, geen plaats voor een "yolo!" instelling.
You Only Levitate Once?
Wel eens software ontwikkeld? :+
Voor de software engineers die al jeuk krijgen van een update naar een andere planeet sturen ( :X ), in 1997 was er een test met een ruimte-probe die LISP icm C draaide: Remote Agent. Door die combinatie was er een soort deadlock die ze konden fixen met LISP's Read-Eval-Print-Loop (net als je in bijv. Python hebt) : http://flownet.com/gat/jpl-lisp.html

Maar dan wel met 45 lichtminuten vertraging tussen [Enter] drukken en antwoord zien.
Maar dan wel met 45 lichtminuten vertraging tussen [Enter] drukken en antwoord zien.
Ik heb wel eens aan CI/CD-straatjes gewerkt die er nog een stuk langer over deden :)
Als je kijkt naar de ontwikkeling van CPU's tot de dag van vandaag, dan zie je dat REPL de grote verliezer is. Éen moderne multicore Out-of-Order pipelined CPU past veel beter bij talen zoals C++ of Java. Functioneel is niet eens zo het probleem, F# op .Net is ook prima, maar CPU's willen graag weten wat de volgende 100 instructies zijn die uitgevoerd moeten worden, en LISP past daar niet in.
Wat ik nog mis in deze draad is de vraag hoe deze situatie kan ontstaan. Is er dan een scenario niet uitgedacht. Er is toch uitgebreid getest lijkt mij?
Dat was dus ook mijn idee. Ze sturen voor miljarden een object naar Mars, dan zijn alle scenario's wel zo vaak bekeken en getest dat dit niet een normale update is, eerder een verruiming van de parameters.

Waarschijnlijk is het toch een hardware matige fout of onvoorziene omstandigheden (wind, temperatuur, druk) waardoor hij niet door de checks komen en die ze nu met de update proberen te omzeilen. Zal technisch dus idd wel "in orde" zijn om te vliegen, maar niet binnen de eerder gestelde omstandigheden.
@Mopi_Ranger en @GWBoes

Ik denk dat jullie hier een belangrijk aspect van een ontwikkelproces over het hoofd zien: Exponentieel toenemende complexiteit in combinatie met onbekendheden en voortschrijdend inzicht gedurende het traject.
De combinatie van deze twee maken het onmogelijk om vooraf precies te bedenken wat je allemaal te wachten staat. Je komt namelijk al gauw op een bijna oneindig aantal scenarios en tests die je zou moeten afdekken voordat je zo'n ding lanceert. Binnen de software-industrie is dit al langer een probleem en wordt de oplossing gevonden in wat we 'Agile' noemen (jeweetwel, dat gebeuren wat nu zó sterk overhyped is dat bijna niemand nog weet wat het ècht betekent :p ).

SpaceX is een mooi voorbeeld van een bedrijf dat dit goed begrijpt. Ze passen (i.t.t. NASA) een empirisch model toe tijdens hun ontwikkelproces: Je weet het pas als je het hebt geprobeerd. Om die reden lanceren ze heel veel versimpelde testplatformen die veelal in een vuurbal eindigen. Buitenstaanders en media noemen het dan een 'mislukking', maar voor SpaceX is het waardevolle kennis over een aanname die wel of niet werkte.


Ps.
Het zou natuurlijk altijd kunnen dat het een hardwarefout in de Ingenuity is. Mijn opmerking gaat puur over de aanname dat je dit soort dingen vooraf kunt voorspellen :)
SpaceX is een mooi voorbeeld van een bedrijf dat dit goed begrijpt. Ze passen (i.t.t. NASA) een empirisch model toe tijdens hun ontwikkelproces: Je weet het pas als je het hebt geprobeerd.
En hoe zie je dat voor je met een helikopter op Mars? Of bemande ruimtevaart/
In dat geval is redundante hardware en updatable software je vriend ;) En er zullen er genoeg helikoptertjes gecrashed zijn in de vacuumtanks bij NASA.

Bemande ruimtevaart vind doorgaans ook pas plaats nadat het platform meerdere malen een veilige vlucht heeft gemaakt zonder passagiers.
Trial-and-error heeft een erg negatief imago, maar in moderne ontwikkeltrajecten maken er graag gebruik van.
Inmiddels heeft SpaceX als gevolg van dat ontwikkel traject met succes mensen in de ruimte gebracht en zijn ze het enige particuliere bedrijf met een FAA licentie om dat ook te mogen doen.
Ze passen (i.t.t. NASA) een empirisch model toe tijdens hun ontwikkelproces: Je weet het pas als je het hebt geprobeerd. Om die reden lanceren ze heel veel versimpelde testplatformen die veelal in een vuurbal eindigen
Toen, decennia geleden, NASA een vrijwel onbeperkt budget had, werkte NASA op exact dezelfde manier. Gewoon testen en kijken wat er gebeurd. NASA heeft duizenden raketten op deze wijze gelanceerd en opgeblazen. SpaceX komt qua aantal daar nog echt niet bij in de buurt.

Maar sinds de jaren 70 moet NASA elke cent 3 keer omdraaien en zijn ze veel voorzichtiger geworden. Het budget dat SpaceX beschikbaar heeft om mee te spelen, is heel wat groter dan het budget dat de NASA daar voor heeft.
Ik heb het even nagezocht (voor zover mogelijk)
Om te beginnen is de schatting van de ontwikkelkosten van Starship door Morgan Stanley op 5 tot 8 miljard dollar geschat. De ontwikkelkosten voor SLS (vergelijkbaar met Starship) zijn ongeveer 9 miljard dollar. Dus zuiver kijkend naar de ontwikkelkosten hebben SpaceX en NASA ongeveer hetzelfde bedrag om mee te spelen.

Dan dat aantal opgeblazen raketten. Dat is een wat lastige variabele omdat de definitie van "ontploffende raket" nogal vaag is. Hoewel wat SpaceX nu enthousiast aan het opblazen is "Starship" wordt genoemd is het dat natuurlijk nog niet. Er ontbreken nog wat motoren, je kunt er vracht in stoppen, maar de deuren ontbreken, het landingsgestel is nog helemaal niet uitontwikkeld etc. Dus als je het hebt over Nasa-raketten die ontploffen, waar hebben we het dan over?
Om het nog wat complexer te maken is de ontwikkeling van de Saturn 5 raket ook in etappes gedaan, waarbij de tussenliggende stappen ook gewoon bemande vluchten waren.

Ik heb wat rondgesnuffeld op Internet, maar ik kon niets vinden over ontploffende (test-)raketten tijdens de ontwikkeling van bijvoorbeeld de Saturn 5 raket. Maar misschien heb je een paar links voor me?
Het NASA budget voor SLS is heel strak en elke USD moet verantwoord worden. Even een raket laten onploffen "om te kijken wat er gebeurd" is niet een uitgebreid beschikbare optie.

https://www.youtube.com/watch?v=g79K-R7xTFo
Mooie compilatie van het begin van de ruimtevaart. De Saturn V is een geval apart, dat was pure prestige. Daar mocht niets fout gaan, de VS kon geen gezichtsverlies hebben en het vertrouwen van het volk moest zo hoog mogelijk blijven. Daar heeft de NASA ook het budget voor gekregen om te zorgen dat de kans op fouten nihil was. Ook was de VS toen al meer dan een decennium bezig.

De VS loopt ook niet graag te koop met hun gefaalde expirementen en tests. Er zijn in de jaren 60 9 Amerikanen overleden doordat een raket explodeerde, dit is wel makkelijk terug te vinden. Wel lastig om de details te vinden van het aantal geëxplodeerde ruimtevaartuigen of raketvliegtuigen. Duizenden is misschien overdreven, maar misschien ook niet. Er is ~40 jaar lang ontzettend veel getest en gekloot door de NASA, Boeing en Lockheed Martin.

Het probleem is dat je deze info niet makkelijk kan opzoeken in het digitale archief van de NASA en het vooral uit vele documentaires moet halen. De ruimtevaartkanalen die ik op YouTube volg hebben het ook niet veel over het verre verleden en vooral alleen over SpaceX, Delta-II en de Challenger.
Het NASA budget voor SLS is heel strak en elke USD moet verantwoord worden. Even een raket laten onploffen "om te kijken wat er gebeurd" is niet een uitgebreid beschikbare optie
Daar ging het niet om, jij beweerde dat Nasa een kleiner budget had dan SpaceX en dat is dus niet zo.

Daarnaast laat SpaceX geen raketten ontploffen om te kijken wat er gebeurt. Elke test van SpaceX is bedoeld om informatie te vergaren en hoewel een ontploffing op zich ook informatie oplevert is de ontploffing nog steeds geen wenselijk einde van een test. De landing is toch een redelijk essentieel onderdeel van het vluchtplan en tot nu toe zijn die ontploffingen een ongewenste onderbreking van dat vluchtplan.

En we kunnen dus niets zeggen over het aantal ontplofte raketten tijdens de ontwikkelfase omdat niemand de moeite heeft genomen die duidelijk samen te vatten.

Een kleine aanvulling op het ontwerp-proces bij Nasa: Werner von Braun had een zeer conventionele ontwikkel-filosofie, met zeer veel kleine stappen en tests bij elke stap. Pas toen president Kennedy druk op de NASA zette om naar de maan te gaan, werd een risico-vollere strategie gevolgd waarbij hele systemen in 1x werden getest. En dat is kennelijk weer losgelaten toen de druk weer afnam en de politiek het overnam.

[Reactie gewijzigd door multikoe op 24 juli 2024 01:41]

Maar sinds de jaren 70 moet NASA elke cent 3 keer omdraaien en zijn ze veel voorzichtiger geworden. Het budget dat SpaceX beschikbaar heeft om mee te spelen, is heel wat groter dan het budget dat de NASA daar voor heeft.
Een groot gedeelte van het budget van de NASA gaat niet op aan experimenteren(om mee te spelen). Die hebben behoorlijk wat vaste lasten en veel andere projecten lopen. https://www.planetary.org/space-policy/nasas-fy-2020-budget
Er is niet helemaal bekend hoeveel budget SpaceX tot zijn beschikking heeft, maar die gaan dit jaar iig minstens 1,6miljard uitgeven aan de ontwikkeling van Starship. Dat is nog maar ~0,5 miljard onder het budget van de SLS.

Kort door de bocht is experimenteren niets meer dan "Kijken wat er gebeurd".
Een groot gedeelte van het budget van de NASA gaat niet op aan experimenteren(om mee te spelen)
Ook hier roep je weer iets vreemds. Alsof SpaceX aan het "experimenteren" is. SpaceX zit midden in een volwaardig ontwikkelingsproces, met zeer professionele ingenieurs en een waarschijnlijk zeer gestructureerde organisatiestructuur. Wat zij zien is het spectaculaire stukje daarvan, maar we zien bijvoorbeeld helemaal niets van de ontwikkeling van de Raptor engines, we zien niets van de ontwikkeling van nieuwe soorten roestvast staal, we zien niets van de enorm complexe software-simulaties die vooraf gaan aan de fysieke testen. Dat is ook niet zo gek, want lang niet zo spectaculair.
SpaceX is op z'n minst even professioneel als NASA. Ze pakken de zaken alleen anders aan en ze hebben Elon Musk die ontzettend goed is in het projecteren van het cowboy-imago.
Dat is nog maar ~0,5 miljard onder het budget van de SLS.
Is dat niet het punt van discussie ? Dat SpaceX veel meer budget zou hebben om te spelen? En nu zitten ze dan toch onder het budget van de SLS? Ik snap je even niet meer.
Er is ongetwijfeld bizar, uitzonderlijk, onvoorstelbaar veel getest zoals dat vaker gaat in de ruimtevaart. En dat werpt vruchten af want de kans dat het dan mis gaat wordt dan steeds kleiner en kleiner. Maar let wel: kleiner. Niet non-existent. Dat is een fantasie.
Men test wat men weet, maar men heeft nog nooit op Mars met iets gevlogen, dus dit is echt nog onontgonnen gebied. Dat is wat het werk van NASA wetenschap maakt.

Men is ook wel degelijk voorbereid hierop: NASA heeft kopieen van zo'n drone en kan dus op aarde testen wat gewijzigde parameters doen. Men beseft dus dat men niet alles weet en lost het op deze manier op.
Dit vind ik nou leuk!
Software update naar een andere planeet sturen :)
Zou hier al een benaming voor zijn? Geen OTA want het gaat door de ijle ruimte.
In 1977 noemden ze die mogelijkheid "programmable in-flight"
Sinds hun lancering in dat jaar hebben de ruimtesondes Voyager 1 en Voyager 2 meerdere software-updates ontvangen.
Iets heel nieuws is dit dus bepaald niet.
En de beide Voyagers waren toch echt wat verder van huis dan de planeet Mars, dus dit moet een eitje zijn voor NASA.
Over Thin Air?
offtopic:
Dat doet me denken aan discussies die ik op mijn werk had. Wij verplaatsten vloeistoffen door een vacuüm te creëren, maar hij had in de halfgeleiderindustrie gewerkt en vond dat 0,3 bar geen vacuüm was maar slechts onderdruk. Natuurlijk had hij gelijk, maar ook in de halfgeleiderindustrie wordt ook geen echt vacuüm gebruikt maar slechts extreme lage druk. Over een "vacuum cleaner" hoeven we het al helemaal niet te hebben. Dus je hebt gelijk, aan absoluut vacuüm zul je tussen ons en Mars niet vinden, dus technisch gezien is "Over This Air" waarschijnlijk niet fout.
Technisch gezien is een vacuüm een ruimte zonder materie. 300 mbar wordt ruw vacuüm genoemd. Verder heb je matig vacuüm 1-10-3 mbar, hoog vacuüm 10-3 - 10-7 mbar en ultrahoog vacuüm < 10-7 mbar.
In plaats van over druk te praten wordt ook wel over vrije weg lengte gesproken. Hoe ver moet een molecuul zich verplaatsten voordat hij botst met een ander molecuul. Die stijgt van 100 nanometer bij atmosferische druk naar 10 kilometer bij een druk van 10-6 mbar.
PTP (Planet To Planet)
Noem het dan P2P en zorg ervoor dat naast Linux updates, Perseverance er ook de film "Perseverance" uit 2010 mee kan downloaden.
Zelfde zoals ze foto's kregen van new horizon.
Via het deep space netwerk.
TTV - through the vacuum?
OTV (Over-The-Vacuum) ? :+
eerst wel ff overleggen met de gebruikers aldaar - of het wel uitkomt... :+
via subspace? gaat rete-snel...
NASA stuurt een update naar Mars, en ik moet met mijn auto nog steeds naar de garage voor een navigatie-update. :P
Je rijdt zeker geen Tesla ;)
Dat hoeft met Google maps ook al niet meer :P

Wel linke soep trouwens zo'n update. Als je moet rebooten en hij schiet in kernel panic kun je niet even langsgaan.
"Press F1 to continue"
"No keyboard detected"
kun je niet even langsgaan.
"even" is relatief :+
Nee, zou ik wel willen!
Dan hoeft je auto alleen een paar maanden stil te staan bij fysieke schade.
Waar kan ik de update downloaden, mijne heeft de zelfde problemen :P
i am from Jupiler
Zou Microsoft Xcloud werken op Mars?
Hopelijk niet.

Zijn geregeld problemen mee, dus maar een andere.
tja het is nou eenmaal patch-tuesday :)

Maar man wat is dit toch gaaf, even remote updaten.

Op dit item kan niet meer gereageerd worden.