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

21–30 of 118 posts

Re: Exploring the software that flies SpaceX rockets and starships

#21

Post by icegreentea2 »

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?

Yes, you could in principle convert any memory within a given loop into a separate unit. You just gotta pick between the tradeoffs between having more I/O and software/hardware units, versus having more memory within specific software/hardware units.

You just gotta find a balance that works for your requirements and constraints. In my application (it was medical devices), we found that stateful loops fit nicely.

Re: Exploring the software that flies SpaceX rockets and starships

#22

Post by furiouslambda »

fighterpilot wrote: post #16
codeulike wrote: post #9

Earlier quoted context omitted.

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

I’ve never seen this implemented well in a real-time setup. I’ve come to associate it with everything falling apart and otherwise being taped together in weird ways to function.

It sounds elegant, but I’m not convinced there’s a benefit to a model of abstractions of abstractions like this unless it’s done at the language level. In practice, I’ve only seen this produce a web of race conditions, performance issues, and system complexity. My experience is anecdotal.

Re: Exploring the software that flies SpaceX rockets and starships

#23

Post by chasd00 »

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…

In all the embedded code I’ve seen there is invariably a “while(true)” somewhere. Is this not the same?

Re: Exploring the software that flies SpaceX rockets and starships

#24

Post by helsinkiandrew »

WJW wrote: post #12
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.

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. Th…

According to the Reddit AMA last year SpaceX use: "C & C++ for flight software, HTML, JavaScript & CSS for displays and python for testing"

Re: Exploring the software that flies SpaceX rockets and starships

#25

Post by galangalalgol »

chasd00 wrote: post #23
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…

In all the embedded code I’ve seen there is invariably a “while(true)” somewhere. Is this not the same?

Unlikely, they talk about 50hz and 10hz tasks. Real time OS often allow you to create threads that run at a given rate and must comolete. Like the 50hz task would have 20ms to complete.

Re: Exploring the software that flies SpaceX rockets and starships

#26

Post by nickik »

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 can answer some of that, 2024 is the current limit. But 2028 is being considered and I think its politically likely.

It could probably be extend even further but it would require incensing maintenance and expensive re-qualification.

NASA already has a plan however. They have a contract with Axiom Space to extend the ISS with new modules. After they have about 4 new modules they should eventually decouple after ISS and be a free floating station.

NASA already has a program in planning for a commercial space station. The same way they did Commercial Crew and the moon lander. They have already asked companies to come up with plans for a station. SierraNevada really wants that contract and SpaceX will probably bid something, probably others. These would be free floating privately run stations

So NASA basically hopes that sometime between 2024 and 2028 there will be two new stations and then its politically easier to drop ISS.

Crew Dragon can still do free flying missions (as they will do later this year) but SpaceX hopes to replace it with Starship.

Re: Exploring the software that flies SpaceX rockets and starships

#27

Post by Nokinside »

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…

It's standard way to program in industrial automation, flight control and safety critical system.

It's how digital PLC process control loop works. Programmable logic controller (PLC) https://en.wikipedia.org/wiki/Programmable_logic_controller

Re: Exploring the software that flies SpaceX rockets and starships

#28

Post by larrydag »

From article “We invented simple domain specific languages to express those things, such that other engineers in the company who are not software engineers can maybe configure it.”

It sounds like they created their own internal API configuration scripts to be highly dynamic and configurable. Similar to many gaming or operating systems config files. Sounds be a highly productive way to test and deploy software changes. Not only for people who are not C++ proficient but also to allow Engineers and Scientist to focus on their own design work and not have to worry about software development.

Re: Exploring the software that flies SpaceX rockets and starships

#29

Post by numpad0 »

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.

I had once thinking about this type of system, and later found that the SNMP(1988) as well as NIST/Army 4D/RCS project(1980s) had this train of thought before I was even born. Now I'm wondering why this type of distributed, synchronized, hard realtime decision making framework don't seem to exist as some Apache Foundation project or something. It just sounds right and massively useful but I can't find an implementation, at least on public Internet -- why?

Re: Exploring the software that flies SpaceX rockets and starships

#30

Post by fighterpilot »

furiouslambda wrote: post #22
fighterpilot wrote: post #16

Earlier quoted context omitted.

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

I’ve never seen this implemented well in a real-time setup. I’ve come to associate it with everything falling apart and otherwise being taped together in weird ways to function. It sounds elegant, but I’m not convinced there’s a benefit to a model of abstractions of abstractions like this unless it’s done at the language level. In practice, I’ve only seen this produce a web of race conditions, performance issues, and…

> I’m not convinced there’s a benefit

I've seen it work well once, but others struggled to contribute to it because it was so complicated and it added little benefit to the usual busy loop approach. So I'm in the same boat as you.

Post reply on HN