SVENSKA

NASA: s okända hjältar: Apollo kodare som att sätta människor på månen

167

Noll

Denna artikel publicerades ursprungligen på TechRepublic.

Homer Ahr hade legat och sovit i 15 minuter när han fick ett samtal från sin chef på Johnson Space Center.

“Allt han sade var,” Homer, komma in i mission control så fort du kan.” Jag inte har en aning om varför jag skulle gå på det,” sade han.

“Inom 30 minuter vid de flesta visste jag att de verkligen var i en liv eller död situation,” sade Ahr.

Tidigare på kvällen, Apollo 13 astronauten Jack Swigert hade fört NASA mission control till stillastående med den numera berömda uttalande, “Houston, vi har haft ett problem.”

Apollo 13 craft var mer än 300 000 kilometer in sin resa till månen när en explosion slet sönder den lilla kapseln.

Den dagen i April 1970, med fartyget avluftning av sin dyrbara tillförsel av syre, NASA visste att det inte hade några alternativ för att få de tre astronauterna på den drabbade rymdfarkoster hem på ett säkert sätt.

“Från och med den insikten om, allt vi gjorde var att göra allt vi kan för att få dem tillbaka”, Ahr sagt.

“Det är ungefär som att vara i ER, ni vet? Om du har till sylt med en nål in i någons bröst att återaktivera sitt hjärta, du gör det bara. Du behöver inte tänka på vad du gör. Du bara gör det.”

En av de många angelägna frågor som handlade om hur man kan montera en räddning utan att avfyra motorer på den skadade delen av hantverk. Vid Johnson Space Center i Houston, TX, mission control smalare alternativ till en manöver aldrig gjort innan. Överlevnad av astronauterna nu gångjärn på att använda härkomst motorer på lunar lander att sätta båten på en banan hemåt.

Mission control hade begränsad tid för att räkna ut hur man ska dra av den manövern. Lyckligtvis, bara månader innan besättningen sprängas bort från Cape Canaveral, två programmerare hade skrivit programmet för mission control för att beräkna en sådan åtgärd.

“Inom 30 minuter vid de flesta visste jag att de verkligen var i en liv eller död situation.” Homer Ahr, NASA programmerare

En av dem som programmerare var den 22-åriga Ahr, bara ett år av college och arbeta för IBM som en manöver-planering expert stödja NASA flygning tjänstemän i mission control.

“Om vad som hade inträffat på Apollo 13 som hade inträffat på Apollo 12, vi skulle ha haft en riktig björn av ett problem,” sade Ahr, eftersom algoritmer för att beräkna den manövern hade bara lagts till.

“Rent fysiskt kan du göra det, men beräkningsmässigt och i mission control center, det skulle ha varit mycket svårt att räkna ut när man ska göra manövern och hur man gör det,” sade han.

Mission control som behövs garantier för att avfyra härkomst motorer skulle fungera, och Ahr och en kollega tillbringade natten kör vad som kallades en spridning analys, kontroll av varje möjligt parameter för att se om de skulle sätta båten på rätt kurs.

“Jag kunde inte ens berätta hur många gånger vi sprang beräkningar,” sade Ahr, “men vi har spridningen analys, och slutsatsen var att” Gå vidare och göra den manövern.'”

De datorer som hjältar

Eventuellt återvända på ett säkert astronauterna var på grund av långt mer än den serie av beräkningar, men Ahr: s sammanställning visar bara hur viktig den tidiga datorerna var att lunar uppdrag.

Med sitt mål att sätta en människa på månen, NASA: s Apollo-programmet är det kanske mest ambitiösa tekniska strävan som någonsin genomförts. Hela 15 Apollo uppdrag som ingår sex månlandningar, den precision som krävs-i form av placering och hastighet-för att sätta båten på rätt bana på resan till och från jorden var krävande.

Varje manöver som skulle utföras av de rymdfarkoster som beräknades i förväg av IBM-datorer i realtid Dator Komplex (RTCC) på Johnson Space Center, och kontrolleras mot craft faktiska manövrar under hela uppdraget.

Lika viktigt är att avkastningen av Apollo 13, framgång och bredare program, var de datasystem som stöder den många simulatorer på Johnson Space Center och Cape Canaveral. De simulatorer som ingår fungerande kopior av rymdfarkoster befäl och lunar moduler, och lät NASA astronauter och flygledarna på marken för att träna på varje del av resan: från lanseringen, till månlandningen, att jorden re-entry, som arbetar tillsammans som de skulle under uppdraget.

Simulatorer replikeras inte bara hur den inbyggda datorer, men också matas data in i marken system, återskapar upplevelsen av en verklig uppdrag så noga som möjligt, och att förbereda personal för att hantera en mängd potentiella problem.

Jack Vintrar, som lyckades simulatorer för att testa och började skriva programvara för simulatorer under tidigare Gemini-uppdrag, sade utbildningen för flygledare var ovärderlig för Apollo-Projektet.

SE: NASA visar världen sin 20-åriga virtuell verklighet experiment för att utbilda astronauter: The inside story (TechRepublic)

“På Apollo 13, till exempel, de var mycket, mycket bättre möjlighet att upptäcka problem och utveckla lösningar på grund av utbildning,” sade han.

Under Apollo 13, dessa simulatorer skulle låta ingenjörer och astronauter på marken–att arbeta tillsammans med astronauten Ken Mattingly, som hade ersatts om Apollo 13 flygbesättningen i sista stund–lista ut hur man ge kommandot module inbyggda system tillbaka online med begränsad effekt som är tillgänglig, ett viktigt steg framåt för att åter komma in i jordens atmosfär.

Merritt Jones arbetade på Johnson Space Center, en programmerare och en astrodynamicist, beräkning av mekanismerna för hur en rymdfarkost rör sig i en omloppsbana.

Träna rätt för att återställa lander system var otroligt viktigt för en säker avkastning på Apollo 13 besättning, sade han.

“De hade för att minska den kraft som krävs för startordningen. Startordningen var kritisk. Om du inte börja i rätt ordning, system inte skulle fungera bra eller inte skulle fungera på alla.”

Tänja gränser

De datorer som används under Apollo-uppdrag var omöjligt råolja med modern standard. Varje RTCC fem IBM System/360 Modell J75 stordatorer hade ca 1MB minne, inte ens tillräckligt för att ladda en typisk webbsida 2017.

“Den programvara som styr vad som händer när du flyttar musen på din PC-mus-drivrutin för Windows–tar mer minne än alla NASA superdatorer sätta ihop hade för Apollo,” sade Jones.

Trots att fylla en hel hall med elektronik, stordatorer varje toppade på ca fem miljoner instruktioner per sekund (MIPs), cirka 30 000 gånger långsammare än den snabbaste processorer som används i dagens datorer.

“Musen drivrutin för Windows kräver mer minne än alla NASA superdatorer sätta ihop hade för Apollo.” Merritt Jones, NASA programmerare och astrodynamicist

NASA var stöta upp mot gränserna för vad tekniken på den tiden kunde göra, vilket ofta innebar att förlita sig på cutting-edge, och ibland oprövade, hårdvara och mjukvara. Och där tech helt enkelt inte existerade, NASA: s kommersiella partners tvungna att uppfinna det.

Ett typexempel var Apollo Vägledning Dator (AGC). Medan marken system kan låta underpowered, inbyggda datorer storleksordningar mer enkel. Vägledning dator för Apollo-farkosten som krävs för att vara tillräckligt små för att passa i trånga kapseln och lätt nog för Saturnus-raket för att få det i rymden. Den garderob storlek IBM stordatorer som används NASA på marken var uteslutet.

Massachusetts Institute of Technology Instrumentation Laboratory (MIT-IL), som hade kontrakt att utveckla AGC, vände sig till en ny teknik, integrerade kretsar, som hade potential att göra datorer snabbare och mindre genom etsning flera transistorer på små marker. På den tiden 1961, integrerade kretsar bara hade uppfunnits två år tidigare och var något av en okänd storhet, men 1963 MIT-IL hade beställt för cirka 60 procent av världens tillgängliga internet-Anslutningsdelning.

“En stor del hade att göra med makt och vikt,” sade Bob Zagrodnick, en ingenjör som arbetade på AGC vid Raytheon, som byggt 43 av datorer under Apollo-programmet.

“Dessa är små enheter och att de inte tar upp en hel del makt. Skulle vi strävar ständigt efter att minimera vikt och energiförbrukning.”

Mer ovanligt var det sätt den programvara som körs på AGC var bokstavligen vävs samman. Vid Raytheon produktionslinje i Waltham, MA, vävare slinga tråd genom cirkulär magneter, skapa en metallic-tapet vars mönster motsvarade digitala ettor och nollor, som i sin tur har kodat program som körs på datorn.

“De faktiskt gängade flyg program information i kärnan rep minnen,” sade Zagrodnick. “Det var en mycket intensiv aktivitet, så oftast kvinnor som var bra på nål och tråd var de som vävt eller sätta ihop kärnan minnen.”

Tillbaka i Johnson Space Center, IBM hittade själv inför en helt annan utmaning. Som namnet antyder, datorer i RTCC som behövs för att kunna hantera nya jobb och data i realtid, för att uppfylla sin roll övervakning rymdfarkoster banor och köra komplexa simuleringar av uppdrag. Problemet var att vid den tidpunkten i början av 1960-talet real-time operating system inte existerar.

Enligt Ahr: “Vi hade för att få en multi-tasking, multi-jobbing operativsystem på 1960-talet, innan IBM någonsin hade byggt en multi-enstyck, multi-tasking operativsystem.”

Så IBM uppfann en ändring av befintliga OS på sitt System/360 stordator, förutom att skapa en real-tid databas som kallas DataTables, “innan du hade något som kallas för en relationell databas,” sade Ahr, med strikta regler kring vilka data som kan uppdateras och när, för att säkerställa att viktig information som rör den rymdfarkoster skulle vara korrekt och tillgänglig när den behövs.

Att arbeta med ett nytt OS lagt till en ny rynka till en uppgift som redan är fylld med utmaningar, med beräkningar som att kasta upp oväntade resultat beror inte bara för att ansökan fel, men också misstag i den relativt oprövade operativsystem.

Ladda ner denna artikel som PDF (gratis registrering krävs).

Skytte för månen

Trycket på unga IBM programmerare var intensiv, med individer som arbetar för så många som 80 timmar i veckan, i ett försök att drabbas hårdast av tidsfrister.

Vintrarna sade: “NASA hade ett schema. De var på väg att flyga på vissa datum. De meddelade att till allmänheten och IBM säkert inte vill vara den som orsakade flygning kommer att försenas.”

Att köra till jobbet dygnet-runt-var delvis som en följd av att straffa tidsplan, men också med spänning på att arbeta för att sätta en människa på månen, och viljan att slå Ryssarna i rymdkapplöpningen.

“Vi var så glada över,” sade Vintrar. “Vi var unga. Jag tror att jag var 21 när jag började. Vi visste inte vad vi kunde inte göra. Vi tänkte bara att vi kunde göra något. Här var jag arbetar med programvara som kommer att gå ut i rymden och så småningom till månen. Adrenalinet faktor var enorm.”

Att vara ung nog för att inte fullt ut uppskatta vad de inte kunde eller inte bör göra ibland betalat sig vackert, enligt Harry Grottan, som främst arbetat på den programvara som används vid simulatorerna i Houston innan ni går ut på att övervaka andras kod.

Grottan erinrar om att ha svårt att simulera drivmedel tankar på Agena obemannad raket under Gemini uppdrag, den AMERIKANSKA bemannade rymdfärder projekt som föregick Apollo, när han tog en tur ner till sin lokala Sakowitz varuhus.

“Det på hyllan, tillsammans med den vanliga typer av böcker som du ser i en butik, var en bok som heter Rocket Drivmedel och Pressurization System,” sade han.

SE: Hur man ska genomföra AI och maskininlärning (ZDNet/TechRepublic särskild rapport)

“Jag köpte den, och det visade sig att boken var exakt säga vad jag ska göra med de krav som jag hade. Jag bara helt åsidosatt de krav som NASA hade skrivit och programmerad av denna bok som jag köpte på Sakowitz,” sade Grottan. “Det fungerade bra. Ingen fångade mig, och resultaten av det fungerade alldeles utmärkt. De kunde simulera vissa saker för att en högre grad av exakthet än vad som krävs.

“Det viktiga är att jag var, kanske, 22 år gammal, och jag visste inte att jag gjorde fel. Jag sa bara: “Detta verkar för mig som om vad jag borde göra.’ Jag misstänker att det var ganska lite av detta,” sade han.

Det är inte att säga att det var alltid lätt att hitta rätt balans mellan det personliga och yrkesmässiga åtaganden. Många av de unga programmerare hade börjat familjer på den tiden, men fann sig ofta med att arbeta sent för att testa programvara, på grund av att maskiner att vara i konstant användning under dagen.

“En stor del av vår utveckling gången var i mitten av natt,” sade Vintrar.

“Jag tillbringat många sena timme i datasalen testa mjukvara och övervakning av testning av mjukvara. I själva verket är min första skilsmässa var nog på grund av alla timmar jag arbetade under den perioden”, sade han.

SE: Foton: programmerare bakom NASA: s Apollo-uppdrag

På baksidan av varje ingenjör sinne var inte bara en framgång för uppdraget, men också livet för de astronauter som beror på programvaran som gör sitt jobb.

Från det ögonblick Tom Steele gick IBM 1963, arbetar från Huntsville, AL den programvara för system för vägledning om Saturnus raketer som används under Apollo, sade han hans team gjort mycket medveten om vad som står på spel.

“Alla entreprenörer hade ett program för bemannad flygning medvetenhet. Dessa program har utformats för att både få dig att göra saker bättre, men också för att få dig att kunna hantera tanken att du skulle kunna döda en kille om du trasslat upp detta,” sade han.

Ahr kände att ansvar särskilt mycket under Apollo 11 1969 uppdrag som landade de första männen på månen.

Hans jobb var att köra program som beräknas manövrar av den raket och sonden, i varje steg av uppdrag, och kontrollera i realtid position av rymdfarkoster mot förväntade resultaten, som arbetar för att stödja flyget tjänstemän i mission control.

Rollen var på intet sätt enkel, kräver Ahr att sitta på en konsol för att lyssna till cirka åtta olika telefonlinjer på en gång, liksom de ljud foder från astronauter. Han minns skräcken han kände när dessa rader började ekande ljudet av ett alarm som Apollo 11 lunar module ned mot månens yta.

“När de larm som gick bort under första härkomst, det var skrämmande, minst sagt,” sade Ahr. “Det var kaotiskt att lyssna till alla som på en gång och försök att vara lugn, hålla huvudet uppe och inte få panik.

“Det var som att du sitter på en fotbollsmatch, det finns massor av människor som skrek, och skrek, och skrek, samtidigt finns det eld. Du vet, brandbilar visa upp, ambulanser visa upp, polisen dyker upp, och de har alla sina sirener på,” sade han. “Det är vad du lyssnar på när du försöker att sitta där och lugnt titta på data i realtid som kommer in.”

Lyckligtvis nedstigningen till månens yta var nära på perfekt: “Så bra härkomst som vi någonsin kunde ha flugit,” sade Ahr, tack vare de många misslyckas-skåp inbyggda i Apollo-system. I detta fall, rendezvous radar i modul hade varit påslagen, överbelastning Apollo Vägledning Datorn med jobb. Var dock kunna prioritera de uppgifter som är nödvändiga för nedstigning, och ignorera de som är relaterade till radar.

Ahr krediter hans förmåga att hålla sig lugn och göra sitt jobb för att de omfattande utbildning inför uppdraget, där alla typer av problem hade varit simulerad, och en medvetenhet om den viktiga roll som han och andra markpersonalen hade.

“Varje åtgärd som du gjorde på konsollen påverkas framgången för uppdraget och kunna påverka livet för astronauterna,” sade han. “Var du tvungen att ha form av en karakteristisk där mer tryck det var, och ju mer stress det var, bättre att du har arbetat.”

Det fanns en ömsesidig respekt mellan IBM ingenjörer och deras NASA kollegor, född ur sina nära samarbete och höga insatser som är inblandade i att göra bemannade rymdfärder till verklighet.

“Vi var verkligen ett band of brothers”, sade Ahr. “Vi har alltid som arbetar för samma mål: framgångsrika uppdrag.”

Ladda ner denna artikel som PDF (gratis registrering krävs).

“Jag är lite förvånad över att vi klarade det”

Lägga till trycket var djup begränsningar av den primitiva teknik i tiden, om det var den lätthet med vilken konsol aktörer som Ahr kan göra misstag när du skriver data till en teletype maskinen under ett uppdrag eller med att skriva program för IBM: s stordatorer på stansade kort.

“I efterhand så är jag faktiskt lite förvånad över att vi kunde dra bort det,” sade Vintrar.

Varje skede i planeringsprocessen var otroligt besvärligt. Program för IBM: s stordatorer i Houston var skrivna på kodning kuddar, som sedan skulle ges till keypunch operatörer som kan slå dem på kortlekar.

Med IBM Federala System Division kontor ligger nästan en mil från datorer, var det ofta nödvändigt för en kurir för att leverera kortet fack att Computing Center och resultat, begränsa antalet gånger programvara kan köras i genomsnitt 1,2 gånger per programmerare per dag.

“Min månadslön var det samma som en timme på stordatorn.” Merritt Jones, NASA programmerare och astrodynamicist

Grottan sade: “Om du var lycklig, du fick köra tillbaka nästa dag. Vad du fick tillbaka var papper, och ganska ofta, det var en core dump,” ett tecken på att programmet hade kraschat. Felsökning denna kod, mestadels assembler med vissa Fortran, för att identifiera orsaken till problemet var inget som idag.

Core-dump skulle vara en bunt papper, “kanske åtta eller nio inches” hög, utan ett ord i det mänskliga språket på det.

“Det skulle allt vara i hexadecimal-och du var tvungen att lära sig att läsa och hitta viktiga punkter som var inom dumpa. Vad du behövde förmodligen skulle få plats på en sida, men det var inte någon verklig möjlighet att veta vad du verkligen behövs, så att du fick dessa enorma core dumps tillbaka,” sade Grottan.

“Du var tvungen att vara mycket flytande i hexadecimal-och att kunna känna igen din assembler språk instruktioner bokstavligen i maskinspråk,” sade han. “Man fick veta en hel del människor att få hjälp. På en dålig dag, det kan ta två eller tre dagar för att arbeta ut det.”

Dokumentationen var också minimal, särskilt i början av uppdrag. Grottan påminner om att arbeta på telemetri programvara som hör till Agena raket som används i Project Gemini. Programmerare som hålls en bit-för-bit uppdelning av varje av programvaran grundläggande komponenter, som kallas ord, som var skriven på en bit kartong som de kallade den lite styrelsen.

“Den enda dokumentation var det här lite styrelsen att vi hade satt ihop. Det fungerade ganska bra ända tills en natt rengöring besättning kastade ut det,” sade Grottan. “Vi hade ingen backup för den. Vi hade en riktig kris, där vi var tvungna att räkna ut vad var och en av dessa bitar var och försöka återskapa lite styrelsen, som aldrig var helt lyckad.”

Över tid, men aldrig tidigare skådad omfattning av de program som arbetade som krävs för IBM att utveckla sofistikerade projekt-management-planer, metoder som skulle användas för årtionden framöver.

“Det var mycket stort program. Det var över en miljon rader kod av programvara,” sade Vintrar. “Det var mycket få lyckade exempel på att utveckla utbudet av programvara framgångsrikt.”

Det var ca 500 IBM programmerare som bygger runt Johnson Space Center i Clear Lake Houston, spridda över ca 10 olika byggnader. För att effektivt samordna arbetskraften, IBM kom upp med en strategi för att bryta ner programvara i moduler som förvaltas av olika grupper och att fastställa datum för när design, kodning, integrering och testning av koden skulle vara komplett.

SE: Digital Omvandling: EN CXO ‘ s Guide (ZDNet/TechRepublic särskild rapport)

Vintrarna, säger en av de tidiga chefer, Dick Hanrahan, “banat väg för den typen av teknik”, och tillade att den strategi som skulle komma att användas för stora projekt över IBM: s Federala System Division.

Kraften av processorer och mängden minne som är tillgängligt var så begränsade att programmerare skulle spendera extra mycket tid på att försöka förenkla koden, särskilt om en instruktion genomfördes upprepade gånger.

“Jag skulle spendera månader på att försöka sätta den ekvationen till en form som skulle ta mindre minne och köra snabbare och ändå få en acceptabel rätt svar. Och jag menar månader”, sade Jones i hans arbete beräkning av rymdfarkoster banor på IBM: s stordatorer.

“Om jag hade en loop där jag skulle göra några beräkningar på insidan av slingan där jag skulle göra det tusen gånger, att jag skulle spendera en månad att försöka ta bort en instruktion från loop,” Jones sa. “Om jag tog en instruktion, jag kunde spara, säga 10.000 instruktion avrättningar. Jag hade bara 1,000,000 tillgängliga för mig och operativsystemet tog några av dem.”

Ett annat exempel såg Jones att skriva kod för att direkt manipulera ettor och nollor av maskinen kod, med hjälp av “maskering instruktioner” för att härleda ett långt mer effektivt sätt kontrollera om ett tal är större än den andra.

“Om du tittat på koden, det skulle se hemsk, men det skulle vara snabb,” sade han.

Enligt Jones, utan att dessa extrema optimeringar, programvara som utförs i realtid beräkningar, såsom rymdfarkoster nuvarande position helt enkelt inte skulle ha kunnat köra på de datorer som finns tillgängliga.

Med tanke på den IBM-stordatorer används i mission control hade tusentals gånger mindre minne än en maskin idag, programvara läses in i sektioner, som var relaterade till en annan fas av resan till månen. Varje avsnitt skulle ta några sekunder att ladda, vilket ytterligare skulle komplicera processen för att spåra en rymdfarkost som kan flytta så fort som sju km per sekund.

System ombord som var kraftigt mer begränsade än de på marken, med Instrument Enhet dator ombord Saturn V-raket kan bara en 15 000 operationer per sekund och inte stödja floating-point matematik. “Du kan inte ens börja att jämföra med i dag,” sade Jones.

Bristen på datorkraft innebar att det relativa värdet av programmerare är dags att datorns tid var de omvända mot vad det är i 2017, sade Jones.

“Idag kan du köpa så mycket beräkna makt som du behöver om du har pengar att köpa det, och programmerarens tid är värt mer än datorn med råge. I dessa dagar, en timme på en IBM stordator var värt en månad av någon med en magisterexamen i matematik att göra detta arbete. Min månadslön var det samma som en timme på stordatorn.”

Överraskande, Steele sa att de flesta av programmering som används i dag var tillgängliga under 1960-talet: “om Du bara inte har några datorer som kan dra nytta av dem,” sade han.

Begränsningar i teknik var så många och de beräkningar som är så komplex att det bästa är att ingenjörerna kunde hoppas på var att komma så nära visshet som möjligt.

“Det fanns inte någon absolut ja / nos. [Men] ni var tvungna att fatta det beslut som det var,” sade Steele.

Att komma så nära som möjligt till säkerhet innebar att testa för alla tänkbara utfall. Men vissa saker kunde inte vara testade på marken, som hur den tyngdlösa miljön i rymden skulle störa luftbubblor i lödpunkter på de elektroniska kretsarna. Så, lika viktigt, att lära sig från alla tidigare uppdrag.

“En sak som är sann: vi har aldrig, någonsin flög ett uppdrag som inte hade ett misslyckande. Någonsin”, säger Steele.

Trots de till synes oöverstigliga utmaningar, Apollo-programmet inte bara har uppnått President John F. Kennedy ‘ s massivt ambitiösa målet att placera en Amerikan på månen i slutet av 1960-talet, men följde upp det med flera resor tur och retur till jorden rocky satellit.

Decennier senare, Apollo programmerare beskriva en känsla av stolthet, men ännu mer av att vara otroligt lycklig.

“Jag känner mig mycket lyckligt lottade att ha haft möjlighet att ha varit en del av det. Jag känner att det är förmodligen en av de mest lyckligt lottade saker som har hänt mig i mitt liv,” sade Vintrar.

Steele sammanfattar det ännu mer kortfattat: “Det var aldrig en dag, aldrig en enda dag var det inte ett problem att lösa, och det var fantastiskt. Det var en fantastisk resa.”

Ladda ner denna artikel som PDF (gratis registrering krävs).

Se också:

HPE och NASA-experiment med “Spaceborne Dator,” en superdator som kan hjälpa oss att komma till Mars (TechRepublic)NASA Mission Control: Bilder av det förflutna och närvarande vid Johnson Space Center (TechRepublic)Hur NASA använder virtuell verklighet att utbilda astronauter (TechRepublic)NASA plockar forskargrupper för att ta itu med framsteg inom drone, som själv kör bil tech (ZDNet)NASA skjuter framför med asteroid nedböjning tester (ZDNet)Uber som arbetar med NASA för att göra flygande taxi verklighet (ZDNet)

Relaterade Ämnen:

Utvecklare

CXO

Digital Omvandling

Tech-Industrin

Smarta Städer

Cloud