Exploring the software that flies SpaceX rockets and starships
stackoverflow.blog
Exploring the software that flies SpaceX rockets and starships
1–10 of 118 posts
Re: Exploring the software that flies SpaceX rockets and starships
#2The 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 determine your state, like where you are in the world or the status of the life support system. That determines your outputs – you write those, wait until the next tick of the clock, and then do the whole thing over again.”
Wow, sounds an awful lot like a typical event loop from a game engine.
Of course the main difference from a game engine would be the reliability requirements. The level of verification effort that goes into flight control software can't be comparable with the effort that goes into a game engine (assuming it's greater than zero :))
Re: Exploring the software that flies SpaceX rockets and starships
#3The 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…
I can't really think of any other way of doing it. Interrupts? That would be bonkers though.
Re: Exploring the software that flies SpaceX rockets and starships
#4The 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.
Re: Exploring the software that flies SpaceX rockets and starships
#5The 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…
I can't really think of any other way of doing it. Interrupts? That would be bonkers though.
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 previous input.
It's basically the same problem as updating a browser DOM in response to application state changes.
Re: Exploring the software that flies SpaceX rockets and starships
#6The 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…
SpaceX has been hiring game developers for years now, they even showed up at GDC once to pick up game devs.
Re: Exploring the software that flies SpaceX rockets and starships
#7Earlier quoted context omitted.
I can't really think of any other way of doing it. Interrupts? That would be bonkers though.
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…
By 'abstractly structure the computation as a graph' you mean 'structure the journey of the rocket as a graoh'?
Re: Exploring the software that flies SpaceX rockets and starships
#8Earlier 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…
By 'abstractly structure the computation as a graph' you mean 'structure the journey of the rocket as a graoh'?
No, as in a the graph starts from nodes corresponding to sensor inputs, with edges going to nodes that represent computations based on those, to further computations, to the outputs that drive actuators.
If only one sensor input changes then intermediate computations that don't depend on it don't need to be updated.
Re: Exploring the software that flies SpaceX rockets and starships
#9Earlier quoted context omitted.
By 'abstractly structure the computation as a graph' you mean 'structure the journey of the rocket as a graoh'?
No, as in a the graph starts from nodes corresponding to sensor inputs, with edges going to nodes that represent computations based on those, to further computations, to the outputs that drive actuators. If only one sensor input changes then intermediate computations that don't depend on it don't need to be updated.
Right. I can see how that could be useful in some situations but presumably it wouldn't work very well for a very dynamic situation like a rocket in flight (changing height, orientation, fuel, thrust every millisecond)
And you still need a control loop to look for sensor changes? Its just a way of caching most of the computation?
Re: Exploring the software that flies SpaceX rockets and starships
#10Earlier quoted context omitted.
I can't really think of any other way of doing it. Interrupts? That would be bonkers though.
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 reason). They just aren't predominant. If your willing to through more hardware at things, you can typically always transform anything into a buffer.