Just like with most open source code - I have absolutely no idea what to do with it, but I still love that it’s freely available.
The article is technically correct in that the code has been open-sourced and published, except it happened in 2016, so I’m guessing the author just decided to ride the Artemis hype.
Adding that the Apollo 11 soft isn’t much more complex as the one of an current pocket calculator, I doubt that it can even run DOOM. NASA anyway has a huge OpenSource catalogue, all their soft used is OpenSource, despite some with restricted licenses only for official uses. Same for other Space agencies, eg. from the ESA. Good sources for astronomic fans.
See ya losers I’m going to moon \s
/s everywhere making the jokes less funny, its funny to see people not getting the jokes anyway.
Ah, but it’s also funny to see people whine about /s anytime it’s used. It’s quite the conundrum.
my bad then I didnt know everyone was whining about it lol
They said \s, stupid
/s
the crucial 30 lines of assembly for calculating Apollo 11’s navigation trajectories.
I was never skeptical we went to the moon until now.
How the hell can you do all that in 30 lines?!?
I mean, the math required is basically first year college level stuff.
Making a machine that will accurately follow that trajectory and not kill you is the hard part.
Very efficiently.
Or for a less cheeky answer, I believe the method they used at a high level was pointing a camera at a few guide stars, so the 30 lines of assembly might have been a loop that checked those cameras for any drift of those stars and did a correction pulse of the rotation boosters to keep them centered. Oh, one of the references might have been the signal strength from home, too (signal gets weaker if the antenna isn’t aligned).
Unless it was an emergency, it might only need to look at 5 pixels to determine alignment and correction.
Also, just because it’s assembly doesn’t mean it can’t call subroutines and functions, so that 30 lines might be misleading in the way those several lines in the other reply have way more going on. That said, if it’s just doing a pixel brightness comparison, that’s one line to read the central pixel, then for each direction one line to read that pixel, one more to compare, one line to jump to next comparison if center is brighter, one instruction to initiate correction burn, one instruction to stop it immediately after, then one instruction to return to the start of the loop… Which comes to 22 lines total, leaving 8 for logging or maybe timing the burn. And that’s assuming their instruction set didn’t have anything fancy like read and compare, compare and jump, or a single instruction burn pulse.
