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

11–20 of 118 posts

Re: Exploring the software that flies SpaceX rockets and starships

#11

Post by canadianfella »

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.

What does “without 100ms” mean?

Re: Exploring the software that flies SpaceX rockets and starships

#12

Post by WJW »

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.

Pretty sure they use a language without a garbage collector for the control software. Probably C or ADA. Look at the FAA specifications for more guidelines. For airplanes it's DO-178C I think, not sure about rockets.

EDIT: One of the coolest projects I saw in recent time was CoPilot, which is a Haskell dialect that compiles down to C control loops which are statically guaranteed to run in constant time and memory. There is also arduino-copilot for if you want to play with ultra-hard real time software but can't afford an entire rocket.

Re: Exploring the software that flies SpaceX rockets and starships

#13

Post by icegreentea2 »

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.

Yes, this stuff is nice.

But it is worth noting that these control loops can often have some sort of memory, so you normally need to test over multiple cycles - you usually have a test vector to load in, and watch for the response vector.

Trivial example would be if you had a PID controller implemented into your main loop. Your main loop would be storing the integral and "previous" error term.

Re: Exploring the software that flies SpaceX rockets and starships

#14

Post by tomp »

devit wrote: post #5
codeulike wrote: post #3

Earlier 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…

But surely you can still do that, while maintaining compliance to the "event loop" interface...

Re: Exploring the software that flies SpaceX rockets and starships

#15

Post by bagels »

icegreentea2 wrote: post #13
sudhirj wrote: post #4

Earlier quoted context omitted.

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.

Yes, this stuff is nice. But it is worth noting that these control loops can often have some sort of memory, so you normally need to test over multiple cycles - you usually have a test vector to load in, and watch for the response vector. Trivial example would be if you had a PID controller implemented into your main loop. Your main loop would be storing the integral and "previous" error term.

Equivalent to handling an additionaanl sensor input and an additional output, no?

Re: Exploring the software that flies SpaceX rockets and starships

#16

Post by fighterpilot »

codeulike wrote: post #9
devit wrote: post #8

Earlier quoted context omitted.

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?

It can work well for dynamic event-driven problems, with no need for a central busy loop[1]. Any sensor changes are responsible for triggering an update in any nodes that depend on it, who are responsible for triggering nodes that depend on those, and so on. One way to do it: abstract class Node, which has a list of child nodes that it loops through and alerts whenever there's been a state change in the parent node.

[1] There is a busy loop but it's only there to trigger tasks on a timer.

Re: Exploring the software that flies SpaceX rockets and starships

#17

Post by ragebol »

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…

Industrial applications often use PLCs, Programmable Logic Controllers that also do this.

Re: Exploring the software that flies SpaceX rockets and starships

#18

Post by holoduke »

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…

You could probably use some of the game "Kerbal Space Program" source code. Would be a good start to control the rockets.

Re: Exploring the software that flies SpaceX rockets and starships

#19

Post by ehnto »

> 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 Crew Dragon serve?

Not trying to be negative, hopefully by 2028 or even 2024 we will have concrete operations underway for continued space station development that could use Crew Dragon, but it does seem bold calling it a new era, when it's so precariously reliant on the ISS existing.

Re: Exploring the software that flies SpaceX rockets and starships

#20

Post by EmielMols »

bagels wrote: post #15
icegreentea2 wrote: post #13

Earlier quoted context omitted.

Yes, this stuff is nice. But it is worth noting that these control loops can often have some sort of memory, so you normally need to test over multiple cycles - you usually have a test vector to load in, and watch for the response vector. Trivial example would be if you had a PID controller implemented into your main loop. Your main loop would be storing the integral and "previous" error term.

Equivalent to handling an additionaanl sensor input and an additional output, no?

True, but you do want to test the emergent control system.
Post reply on HN