Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exploring the software that flies SpaceX rockets and starships

stackoverflow.blog

Post reply on HN
Print view View original

81–90 of 118 posts

Re: Exploring the software that flies SpaceX rockets and starships

#81

Post by froh »

icegreentea2 wrote: post #10
devit wrote: post #5

Earlier quoted context omitted.

You could abstractly structure the computation as a graph (there are many concrete approaches to that) and only recompute the parts that change due to changed input or changed intermediate results. If you have multiple outputs you can also have a scheduling/prioritization system for the subtasks. And yes, use interrupts or multiple timers to detect only changed parts without having to compare current input to previou…

Right, but since you typically want timing guarantees (for example, "respond to change in measured acceleration within 20ms"), you'd often end up structuring and resourcing everything for the worst case (everything needs to be computed) anyways... which means that your graph optimization didn't end up saving any resources. Also, there sometimes ARE interrupts meshed in with these main loop based systems (for whatever…

for battery electric use cases it saves energy: you do just the necessary computations and you sleep the CPU until the next cycle. if little has changed you can sleep a lot. if a lot of rumpus is happening, you use the full cycle.

Re: Exploring the software that flies SpaceX rockets and starships

#82

Post by bodhiandphysics »

jetrink wrote: post #76
bombcar wrote: post #66

Earlier quoted context omitted.

They've been known to leak memory ... https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98... >This sparked an interesting memory for me. I was once working with a customer who was producing on-board software for a missile. In my analysis of the code, I pointed out that they had a number of problems with storage leaks. Imagine my surprise when the customers chief software engineer said "Of course it leaks". H…

That is a great story, but I cringed at the part about adding additional hardware to support their leaky code. Surely there had to be a better way?

Don’t overengineer! Malloc has o(n) time in reallocs, so leaking memory can be a viable strategy

Edit: yes I know it’s more complicated than that!

Re: Exploring the software that flies SpaceX rockets and starships

#83

Post by pjc50 »

TchoBeer wrote: post #75
funklute wrote: post #63

Earlier quoted context omitted.

This one might also be interesting https://web.cecs.pdx.edu/~kimchris/cs201/handouts/The%20Powe... It's basically just a quick list of 10 useful rules to follow for safety-critical code. (I've seen a different format in the past, that wasn't quite as fancy, but this is the only version I can find at the moment)

Interesting. I wonder how compiler-dependent rule 10 is. Like, if I'm writing for a compiler that gives really bad and usually unhelpful warnings that make my code worse... but I suppose these are more very strict guidelines than rules.

That section explicitly addresses that question and says you should rewrite it in a way that avoids the warning, since "usually unhelpful" means "sometimes critical". It's certainly an uncompromising view but that's what you get when failure is disastrous.

Re: Exploring the software that flies SpaceX rockets and starships

#84

Post by Yoofie »

BigMajestic wrote: post #53
yetihehe wrote: post #40

Earlier quoted context omitted.

Very likely: while(true) { ...[50hz tick tasks] if(tick%5==0) { ...[10hz tick tasks] } wait_for_next_tick(); tick++; }

Nope, more likely there are internal CPU timers which emits hardware interrupts on which the tasks are performed

No, he is correct. Alot of embedded software uses a more complex form of that exact technique that he is shown in the code.

You technically can have a dedicated timer interrupt for every task but there are usually alot more tasks than HW timers, so instead they use a dedicated HW timer for time-keeping and use that as reference for all other tasks.

Re: Exploring the software that flies SpaceX rockets and starships

#85

Post by rm445 »

TchoBeer wrote: post #74
bombcar wrote: post #66

Earlier quoted context omitted.

They've been known to leak memory ... https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98... >This sparked an interesting memory for me. I was once working with a customer who was producing on-board software for a missile. In my analysis of the code, I pointed out that they had a number of problems with storage leaks. Imagine my surprise when the customers chief software engineer said "Of course it leaks". H…

I think we've solved the GC vs Manual debate. Just add more RAM and explode your computer when it's done running

Very funny. But leak memory until you have to restart the process seems to be a very common strategy in practice. The programs explode even if the computer doesn't.

Re: Exploring the software that flies SpaceX rockets and starships

#86

Post by treespace88 »

sudhirj wrote: post #4
plq wrote: post #2

The article is a bit light on technical details, but the following is noteworthy: > Flight software for rockets at SpaceX is structured around the concept of a control cycle. “You read all of your inputs: sensors that we read in through an ADC, packets from the network, data from an IMU, updates from a star tracker or guidance sensor, commands from the ground,” explains Gerding. “You do some processing of those to de…

Seems like a really clean and testable system, too. Can make a harness with a set of inputs, run the cycle and test outputs consistently. Performance is also easily checked, each cycle needs to run without 100ms for the 10hz systems, I guess, including garbage collection. Nice it see things kept this simple.

Really nice for integration testing. Not to be confused with unit testing.

You could literally replay entire missions.

Re: Exploring the software that flies SpaceX rockets and starships

#87

Post by jccooper »

xen2xen1 wrote: post #72
Anarch157a wrote: post #38

Earlier quoted context omitted.

That's basically how an arduino works and, IIRC, the Apollo Guidance Computer.

And didn't the Apollo Guidance Computer do some of it in analog?

It had manually encoded ROM in the form of "core rope memory", which is pretty wacky, but it was a digital computer. In fact, it was the first IC computer.

You can learn way too much about it and even operate (a simulation of) one here: http://www.ibiblio.org/apollo/

Re: Exploring the software that flies SpaceX rockets and starships

#88

Post by rtkwe »

ehnto wrote: post #19

> This marks the beginning of a new era for SpaceX, one where it will aim to routinely fly astronauts to the ISS Does anyone have much insight into the longevity of the ISS from now? I can see it's approved for operation until 2024, so just 3 years, but could potentially continue to operate after that. If the ISS does get decommissioned, how many years does that process take, and once it's gone, what purpose does Cre…

I think the ISS will be dragged along until there's a plan for a new station which may include replacing the more ancient components instead of an entirely new station. I have a hard time seeing NASA and the US government giving up on having a continuously operated space station in LEO. What that likely means given the overall gridlock and every administration messing with the plans at NASA is that the ISS limps along until the modules themselves need to be replaced.

Re: Exploring the software that flies SpaceX rockets and starships

#89

Post by polishdude20 »

On the topic of rocket flight computers, here's a link to an FC I built last year for my model rocket. It does thrust vectoring and some rudimentary navigation. The control loops on this thing run at 200hz though. It's got a state machine for knowing what to do at each stage of flight as well.

https://github.com/polishdude20/CygnusX1

Re: Exploring the software that flies SpaceX rockets and starships

#90

Post by maxlybbert »

LeifCarrotson wrote: post #61
mrfusion wrote: post #49

Earlier quoted context omitted.

Do you have a link to bjarnes writeup? My ask Jeeves skills are failing me.

I don't think it was actually written by Bjarne, I think it was K. Carroll and others from Lockheed Martin, but I expect the document is this one: https://www.stroustrup.com/JSF-AV-rules.pdf which is linked from the Applications page of Bjarne's website.

There are a couple others as well:

https://stroustrup.com/autonomics09.pdf

https://stroustrup.com/sec09.pdf

https://stroustrup.com/mbd09.pdf

Post reply on HN