The article is a bit light on technical details, but the following is noteworthy:<p>> 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.”<p>Wow, sounds an awful lot like a typical event loop from a game engine.<p>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 :))
I work in avionics and the principles are exactly the same. And I think it applies to all somewhat critical embedded systems.<p>There are some details that may change, for example, we use mostly C, specialized software and a bit of ADA, no C++ in embedded systems. But the input-output periodic loops, isolation and making sure things continue working in degraded condition principles are the same.<p>Nothing special about SpaceX here, for good reasons. In fact, some of it might be mandatory if you want to fly something that can cause serious damage if you it fails, be it a rocket or a plane.
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.”<p>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.
On the topic of rocket flight computers, here's a link to an FC I built last year for my model rocket. It does thrust vectoring and some rudimentary navigation. The control loops on this thing run at 200hz though. It's got a state machine for knowing what to do at each stage of flight as well.<p><a href="https://github.com/polishdude20/CygnusX1" rel="nofollow">https://github.com/polishdude20/CygnusX1</a>
Note that part 2 is also out now: <a href="https://stackoverflow.blog/2021/05/11/building-a-space-based-isp/" rel="nofollow">https://stackoverflow.blog/2021/05/11/building-a-space-based...</a>
<p><pre><code> 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.”
</code></pre>
I didn't know what IMU meant but according to this[0] it's an Inertial Measurement Unit, I believe.<p>[0] - <a href="https://en.wikipedia.org/wiki/Inertial_measurement_unit" rel="nofollow">https://en.wikipedia.org/wiki/Inertial_measurement_unit</a>
FWIW, the NASA Technical Reports Server is a good resource for technical docs from Apollo to Shuttle. Many of them have enough detail to implement the algorithms.<p><a href="https://ntrs.nasa.gov/search?q=shuttle%20guidance" rel="nofollow">https://ntrs.nasa.gov/search?q=shuttle%20guidance</a>
> This marks the beginning of a new era for SpaceX, one where it will aim to routinely fly astronauts to the ISS<p>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.<p>If the ISS does get decommissioned, how many years does that process take, and once it's gone, what purpose does Crew Dragon serve?<p>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.
Is it possible for a programmer with the relevant experience to apply for a role at spacex? Maybe as a consultant/contractor on non sensitive software ?
are the 50hz chips manufactured at 50hz ? or are they downclocked to 50hz.<p>why cant you use higher clocked speeds ? like even 500 mhz, etc ? is there something special about 10 and 50hz ?