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

61–70 of 118 posts

Re: Exploring the software that flies SpaceX rockets and starships

#61

Post by LeifCarrotson »

mrfusion wrote: post #49
jb1991 wrote: post #37

Earlier quoted context omitted.

> including garbage collection. Not only does flight control software typically never use garbage collection, it is also preferable to never allocate memory during the runtime -- all memory ever needed is allocated at program startup, and memory is not acquired or released until landing or some other major end event. Because memory issues are often the most significant causes of crashes, which you don't want to trans…

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.

Re: Exploring the software that flies SpaceX rockets and starships

#62

Post by zie »

numpad0 wrote: post #29
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.

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

See the Beam/OTP as part of Erlang and now Elixir, Gleam, etc.

Erlang came out of Ericcson when they were building giant telephone switches.

Nowadays things like RabbitMQ and WhatsApp run on the Beam VM.

The beam handles both local and remote nodes, mostly transparently.

Then there are things like Nomad or k8s which try to tackle the problem more like *nix(linux/BSD/etc) does, but across multiple nodes. These are not meant for hard real-time systems like launching rockets obviously, not even for soft real-time.

Re: Exploring the software that flies SpaceX rockets and starships

#63

Post by funklute »

mrfusion wrote: post #49
jb1991 wrote: post #37

Earlier quoted context omitted.

> including garbage collection. Not only does flight control software typically never use garbage collection, it is also preferable to never allocate memory during the runtime -- all memory ever needed is allocated at program startup, and memory is not acquired or released until landing or some other major end event. Because memory issues are often the most significant causes of crashes, which you don't want to trans…

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

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)

Re: Exploring the software that flies SpaceX rockets and starships

#65

Post by ACS_Solver »

hutzlibu wrote: post #45
ACS_Solver wrote: post #44

Earlier quoted context omitted.

The article's indeed light on details, but what it describes sounds very similar to autonomous driving / driver assistance software I have experience with. That's not really surprising, as the overall system for an autonomous car and a spaceship is very similar - keep processing inputs from sensors, calculate some values and manage state machines, use those results to adjust outputs, some of which may operate actuato…

"One frame could render in 20ms and the next in 25ms, which is completely fine." No it is not fine, if you want to have a real smooth gameplay. So also in game loops, you can adjust for that, by checking timediff. But sure, the difference is that, if you miss a frame in a game loop - no real rockets crash, so there is probably (and hopefully) not as much effort put into that, like they do on SpaceX.

Framerates are averaged over much longer periods than two frames. Rendering 45 frames in 20ms each and then having a couple take 25ms just doesn't matter mostly, and addressing that is the kind of extra "nice to have" (and even then not for every kind of game). Yeah it's nice to have consistent frame times but less important than avoiding individual frames getting very slow, and a framerate drop certainly won't be treated by the engine as a critical failure that causes e.g. a crash or restart.

On a hard real-time system like the Dragon, failing the deadline once is a critical error just like a game engine being unable to talk to the GPU.

Re: Exploring the software that flies SpaceX rockets and starships

#66

Post by bombcar »

jb1991 wrote: post #37
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.

> including garbage collection. Not only does flight control software typically never use garbage collection, it is also preferable to never allocate memory during the runtime -- all memory ever needed is allocated at program startup, and memory is not acquired or released until landing or some other major end event. Because memory issues are often the most significant causes of crashes, which you don't want to trans…

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". He went on to point out that they had calculated the amount of memory the application would leak in the total possible flight time for the missile and then doubled that number. They added this much additional memory to the hardware to "support" the leaks. Since the missile will explode when it hits its target or at the end of its flight, the ultimate in garbage collection is performed without programmer intervention.

Re: Exploring the software that flies SpaceX rockets and starships

#67

Post by jb1991 »

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.

Ah, thanks for the link; yes this is the one I was referring to. I had thought it was by Bjarne since it was on his site, but either way, it's an interesting read.

Re: Exploring the software that flies SpaceX rockets and starships

#68

Post by lukastr0 »

7373737373 wrote: post #64

The 50 Hertz rate surprises me, a lot can happen within 20ms, a lot of distance traveled at high speeds

The question is not the distance travelled but how quickly you need to react. If you're gimballing a rocket engine, this is not going to be a device that can do much movement within 20ms.

Re: Exploring the software that flies SpaceX rockets and starships

#70

Post by Unklejoe »

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…

This is also how I'd normally implement control systems in general. Sample the input, calculate, then set output.
Post reply on HN