fprime VS cFS

servos (three at each rotor swashplate), as well as power management and thermal control functions."[0]

[0] https://rotorcraft.arc.nasa.gov/Publications/files/Balaram_A...

[1] https://nasa.github.io/fprime/

Does anyone have any suggestions for learning to write flight software or have any resources to learn from? I'm not necessarily looking for a framework to learn either, unless you think I should be focusing on something like https://nasa.github.io/fprime/. At this point, I don't know what I don't know... what should I be focusing on?

F´ (F Prime) is originally developed at JPL, which is written under the C++11 standard. The linked video should be based on JPL Institutional Coding Standard for the C Programming Language, which is a guideline for C. They should be using C++11 nowadays.

The navigation camera is something you can buy online, the other terrain camera is a Sony IMX 214, The flight software is on github, the altimeter is from sparkfun.

[1] https://github.com/nasa/fprime

While the Back up is on a LEON 3 (SPARKV8) CPU using the VxWorks and NASA's CFS framework. (https://github.com/nasa/cFS)

NASA actually makes all this publicly available information available on their NTRS server.

Primary and BFS Info:

This article does not go into detail about the actual architecture and RTOS's used.

Orion's primary flight control runs on a quadruple redundant architecture, powered by Green Hills INTEGRITY RTOS on a BAE Systems RAD750 processor. Four independent channels. Radiation hardened. Built to survive deep space. If one channel fails, three more are right behind it + the Back Up Flight software.

But the BFS is something different entirely. It runs on a LEON3 board powered by VxWorks, on separate hardware, executing separate software logic. NASA's own cFS (https://github.com/nasa/cFS) — the Core Flight System. The same open architecture framework that guided the James Webb Space Telescope. The same system running on the Mars rovers. A battle-tested, modular, reusable flight software framework that NASA has trusted across some of the most demanding missions ever launched. If a software bug, a design flaw, or a common cause failure ever compromised the primary system, a redundant copy of that same system would fail in exactly the same way. Dissimilar redundancy eliminates that risk. A completely different OS, different codebase, different development team. If the primary goes down, the BFS does not share its vulnerabilities. Orion's flight software redundancy is not simply "primary + backup." It is a dissimilar redundancy architecture, and that distinction is everything.

You can read more about the Orion Flight Software and BFS here:

https://ntrs.nasa.gov/api/citations/20190000011/downloads/20...

[4] https://github.com/nasa/cFS

I definitely recommend looking at https://github.com/nasa/cFS for some great pure C coding.

Nowadays there's a trend towards openness and reusability. There's frameworks like the NASA Core Flight System (cFS) and the NASA JPL F Prime framework. There's also workshops where all of us flight software engineers get together and discuss new research, trends etc: https://www.youtube.com/c/FlightSoftwareWorkshop

Core Flight System (cFS) https://github.com/nasa/cFS

NASA has a lot of open source projects including a bunch that don't "go to space" but are used in space related projects (check each project for contributor guidelines):

https://github.com/nasa/openmct - web based mission control software

Your best bet is probably to read the documentation of the project itself, as well as documentation from the associated projects FRET, Copilot (https://copilot-language.github.io/documentation.html, https://ntrs.nasa.gov/citations/20200003164), and cFS (https://github.com/nasa/cFS).