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

The software that flies SpaceX rockets and starships

stackoverflow.blog

Post reply on HN
Print view View original

81–90 of 112 posts

Re: The software that flies SpaceX rockets and starships

#81

Post by zardo »

sobellian wrote: post #19
mattlondon wrote: post #5

Interesting that they are doing updates at only 10 and 50Hz. I had kinda assumed they'd be looking at much higher frequencies for telemetry especially for things like the rocket motor metrics

I don't know what I'm talking about, but I believe in optimal control a rocket's orientation changes very slowly and the rocket is designed for aerodynamic stability. 50Hz is also probably much faster than the engine can gimbal or throttle. So if a 50Hz tick is too slow to respond to some stimulus, something has gone horribly wrong.

> So if a 50Hz tick is too slow to respond to some stimulus, something has gone horribly wrong.

Which is why the abort system probably doesn't need to wait for that tick.

Re: The software that flies SpaceX rockets and starships

#82

Post by freemint »

api wrote: post #72
horstmeyer wrote: post #23

Earlier quoted context omitted.

MongoDB is web scale, not universe scale.

It's interesting how much contempt people have around here for one of the most successful open source oriented companies in recent memory. Most of the bad things about MongoDB are actually bad things about the NoSQL fad, and that fad was huge around here a few years ago.

I used NoSQL databases that are ACID.

Re: The software that flies SpaceX rockets and starships

#83

Post by jakeinspace »

elteto wrote: post #43
mattlondon wrote: post #5

Interesting that they are doing updates at only 10 and 50Hz. I had kinda assumed they'd be looking at much higher frequencies for telemetry especially for things like the rocket motor metrics

Keep in mind that this is _reaction time_. As in, if something happens to an engine how fast do I need to react to safe it before it spreads to other things. Turns out that 20ms response time is plenty appropriate. Are there any processes in combustion dynamics faster than 20ms? You bet there are, and when the engine is being tested they are instrumented with high speed probes, because during development/testing you…

Rocket engines have built-in computers, like ECUs in cars, that likely operate at a much finer update cycle than 50hz. Flight computers are not concerned with every aspect of timing when it comes to the engines, they just need to tell the engine's controller when to fire.

Re: The software that flies SpaceX rockets and starships

#84

Post by timClicks »

V_Terranova_Jr wrote: post #77
fallingmeat wrote: post #28

Interesting they seem to ad-hoc the lifecycle processes, or at least no mention of any industry standards mandatory (RTCA/DO-178C, ISO26262 or even sys eng like SAE ARP4754, etc). Also, no talk of formal methods (formal modeling or formal verification, a la DO-333 with something like Simulink Design Verf or TLA+). Works for them obviously!

It's been ~a decade since I was knowledgeable in SpaceX software development details, but at least then, they were not the kind of shop that emphasized rigor and formality. Their culture is oriented toward rapid implementation & test, pragmatism, and empiricism. That has its pluses and minuses. My personal view is that more of the industry, including SpaceX, should be moving toward engineering things to be more corre…

SeL4 is now mostly defunct. The whole team was laid off during a pivot towards AI and blockchain.

Re: The software that flies SpaceX rockets and starships

#85

Post by bob1029 »

jve wrote: post #21
bob1029 wrote: post #16

Earlier quoted context omitted.

50Hz is pretty damn fast for anything happening at rocket ship scale (i.e. gimbaling of engines). 10Hz seems fine for a more strategic roll-up of all subsystems wherein you would have to do more complex logic each round. The physics are pretty stable at any rate considering the masses involved. If we were talking about controlling a 10g nanodrone (hypothetically), 50hz would probably be cause for concern. For a Space…

> 50Hz is pretty damn fast for anything happening at rocket ship scale I was thinking whether this is OK for dragon in-flight abort system. Well, probably is. Or that may use some system on Dragon itself as the rocket may be no more...

FTS/crewed abort is likely a special exception to these control loops. Last I read there are some lengths of wire that run down the rockets which, when broken, would allow for an instantaneous reaction to some catastrophic event.

Re: The software that flies SpaceX rockets and starships

#86

Post by bodhiandpysics1 »

Beached wrote: post #40
numpad0 wrote: post #38

How are distributed realtime systems like a rocket is synchronized? Are there central timeservers and allocated transmission slots and timestamped query-response action messaging or is it just small individual realtime nodes making their own decisions? I’ve been wondering about this for a year or so because I can’t seem to find one that matches my description, other than concept drawings on NIST 4D/RCS paper, but the…

iirc all flight systems are in triplicate and all data is checked against the others, then a quarum is needed from the 3 to make a decision. other rockets use rad hardened computers that make decisions on their own, but for cost and time, I believe SpaceX just triplicated all necessary systems and votes out and reboots any system that gets bit flips.

They actually use more than three now. The basic architecture is that computers are organized in "strings". Each string is doubled. If the two don't agree, the result is chucked, and the system reboots. Each of these "strings" then participates in a quorum. The result is extreme reliability, with relatively fast convergence.

Re: The software that flies SpaceX rockets and starships

#87

Post by yellow_lead »

ironmagma wrote: post #73
sgt wrote: post #4

They're not running a dependency-ridden NodeJS backend with MongoDB and random cloud services? How are they even able to get to space?

They're only using C++ which has 1,853 pages worth of complexity[1] along with all the toolchains that go on top of it. [1] https://www.iso.org/standard/79358.html

I'm sure they're using a strict subset of C++ but it is still complex. I wonder if they'll move to Rust some day.

Re: The software that flies SpaceX rockets and starships

#88

Post by andrewxdiamond »

api wrote: post #72
horstmeyer wrote: post #23

Earlier quoted context omitted.

MongoDB is web scale, not universe scale.

It's interesting how much contempt people have around here for one of the most successful open source oriented companies in recent memory. Most of the bad things about MongoDB are actually bad things about the NoSQL fad, and that fad was huge around here a few years ago.

Mongo’s “return before write” behavior is what earned it this title. It makes it look better on benchmarks, convincing unwitting devs that it is a better choice.

Re: The software that flies SpaceX rockets and starships

#89

Post by wikibob »

bodhiandpysics1 wrote: post #86
Beached wrote: post #40

Earlier quoted context omitted.

iirc all flight systems are in triplicate and all data is checked against the others, then a quarum is needed from the 3 to make a decision. other rockets use rad hardened computers that make decisions on their own, but for cost and time, I believe SpaceX just triplicated all necessary systems and votes out and reboots any system that gets bit flips.

They actually use more than three now. The basic architecture is that computers are organized in "strings". Each string is doubled. If the two don't agree, the result is chucked, and the system reboots. Each of these "strings" then participates in a quorum. The result is extreme reliability, with relatively fast convergence.

Fascinating. Could you write more about this, or do you have suggestions for what to read to learn more?

Re: The software that flies SpaceX rockets and starships

#90

Post by V_Terranova_Jr »

timClicks wrote: post #84
V_Terranova_Jr wrote: post #77

Earlier quoted context omitted.

It's been ~a decade since I was knowledgeable in SpaceX software development details, but at least then, they were not the kind of shop that emphasized rigor and formality. Their culture is oriented toward rapid implementation & test, pragmatism, and empiricism. That has its pluses and minuses. My personal view is that more of the industry, including SpaceX, should be moving toward engineering things to be more corre…

SeL4 is now mostly defunct. The whole team was laid off during a pivot towards AI and blockchain.

- I don't think SeL4 is "defunct" even though CSIRO's decision on the Trustworthy Systems group was profoundly incompetent; here's a relatively recent post from Gernot Heiser: https://microkerneldude.org/2021/09/28/where-is-sel4-heading...

Also: https://sel4.systems/news/2021

Do you know more that would substantiate defunct-ness?

- Your comment also reinforces my point: if aerospace seeks to be more rigorous, then more in aerospace should be figuring out how to shore up development of SeL4. Instead, they continue with no vision as to what should one day replace things like VxWorks.

Post reply on HN