Originally, the ZDNet article “From Earth to orbit with Linux and SpaceX” caught my attention (https://www.zdnet.com/article/from-earth-to-orbit-with-linux..., June 3, 2020). A little searching turned up this research paper, which investigates a range of vehicles beyond Falcon 9.
> The Dragon spacecraft also runs Linux with flight software written in C++. The ship's touchscreen interface is rendered using Chromium and JavaScript.
I'm actually shocked by this statement. I would never trust JavaScript on a spacecraft.
And web browsers often have js interpreters too. And if things screw up, what's the harm? These are different scenarios where lives matter in one, no the others.
I'm disturbed you should ask. Several answers but for me the main one is simplicity (lack of it).
Add to that, lack of explicit memory handling and dynamic typing at least. You could say you could use a small subset of the language, in which case you'd have to enforce that subset only is used, in which case you'd strip out the unused stuff from the language, and then you don't have javascript any more.
Sounds just like a great cost-effective "hack" that Elon's company would use. It's just an UI, a perfect fit for browser/javascript solution. (I don't mean "hack" in negative sense, but just doing things unconventionally.)
I'm actually amazed that Tesla's UI does not use similar solution but is Qt-based.
The astronauts are cargo. Dragon capsules have already been flown to the ISS without any of this stuff. It’s too unfair to call it decoration but it’s not far off that.
> "During the mission, a problem in the Linux system was discovered that caused a
temporary loss of control. A comma-separated values file grew out of bounds due to
a bug, causing the system to halt; fortunately, a radiation-induced single-event effect caused the main computer to reboot, temporarily fixing the problem, and allowing a bug
fix to be applied in orbit. After the bug fix, the solar sail deployment was successfully performed - just in time before the low-flying satellite deorbited".
G. Manyak and J. M. Bellardo, “Polysat’s next generation avionics design,”
in Space Mission Challenges for Information Technology (SMC-IT), 2011 IEEE
Fourth International Conference on, Aug 2011, pp. 69–76. [Online]. Available:
http://dx.doi.org/10.1109/SMC-IT.2011.13
[22] R. Ridenoure, R. Munakata, A. Diaz, S. Wong, B. Plante, D. Stetson, D. Spencer,
and J. Foley, “LightSail program status: one down, one to go,” in Proceedings of
the AIAA Small Satellite Conference, SSC15-V-3, 2015.
Funny seeing this on HN. I worked at PolySat until 2010 (a year before that article was published), so I know most of those names.
When I worked there, our avionics was embedded C on bare metal. We had several problems we were trying to solve when we realized that switching to embedded Linux makes solving them easier. We wanted to abstract away from the hardware to be able to make more use of automated testing. Switching to Linux meant we didn't have to build our own HAL. For the algorithms I was working on, I wanted to do more of my development on a Linux system. And we saw it as a way to make on-orbit patches easier. I wasn't involved in making the transition to Linux though. That effort started around the time that my focus shifted to my master's thesis.
> SpaceX uses ordinary electronics parts in their flight electronics, as opposed to ded-
icated radiation-hardened parts, since systems can be made radiation-tolerant with re-
dundancy, and commercial off-the-shelf components are easier to work with.
Something about this confuses me -- for years, I'm assuming since the earliest days of human spaceflight, the convention has been to used radiation-hardened hardware, yes?
I absolutely see the benefits of not using this expensive, unfamiliar, specialized hardware when you can instead use cheap, well-known, store-bought CPUs that everyone is familiar with and knows how to use.
But... how do you solve the original problem? Does it turn out that radiation is not that big of an issue after all? Is it a big deal, but SpaceX found a workaround? Do you have three CPUs all running the exact same computations and you assume there was no impact from radiation if at least 2/3 give the same result?
It makes me somehow both extremely satisfied, and a little jittery, to know we just flew two humans to the space station on off-the-shelf CPUs :)
They probably won't all have the exact same bits affected by radiation, and they vote on the results. The architecture gives you fault tolerance and low likelihood of failure. A rad hardened processor will make the likelihood better, but it's not worth it if it's already good enough.
No, SpaceX did the exact same thing the shuttle did. 3 normal RtLinux Intel boxes running the very same model, with one hardened controller comparing the results. This can run at much higher CPU frequencies to get the required controller speed and HW latencies. This is just for low orbit and very short missions.
The longer the missions, the higher the orbit, the more radiation fallouts then. The Moon or Mars missions would need to fall back to hardened CPU's and RAM, but there's not much need for high speed controllers there. Just reliable reboots. 200Mhz is enough. The controller high speed is mostly needed for the earth gravity. Up there it's much more relaxed.
> expensive, unfamiliar, specialized hardware when you can instead use cheap, well-known, store-bought CPUs that everyone is familiar with
My impression (from wikipedia) is that several popular radiation-hardened CPUs are just embedded CPUs with a different manufacturing process. They should be as familiar as traditional embedded CPUs, just old and expensive.
For example RAD750 is based on PPC750 which can be found in older macs.
25 comments
[ 2.8 ms ] story [ 67.5 ms ] threadI'm actually shocked by this statement. I would never trust JavaScript on a spacecraft.
IMHO, most of the flak javascript gets is primarily due to 2 reasons -
1. Using javascript indiscriminately
2. Using javascript frameworks to a point where it becomes it's own universe and people end up with blinders unable to see anything else.
In both these cases, the issue is not as much as with the language as with the people (ab)using it.
Add to that, lack of explicit memory handling and dynamic typing at least. You could say you could use a small subset of the language, in which case you'd have to enforce that subset only is used, in which case you'd strip out the unused stuff from the language, and then you don't have javascript any more.
I'm actually amazed that Tesla's UI does not use similar solution but is Qt-based.
> "During the mission, a problem in the Linux system was discovered that caused a temporary loss of control. A comma-separated values file grew out of bounds due to a bug, causing the system to halt; fortunately, a radiation-induced single-event effect caused the main computer to reboot, temporarily fixing the problem, and allowing a bug fix to be applied in orbit. After the bug fix, the solar sail deployment was successfully performed - just in time before the low-flying satellite deorbited".
G. Manyak and J. M. Bellardo, “Polysat’s next generation avionics design,” in Space Mission Challenges for Information Technology (SMC-IT), 2011 IEEE Fourth International Conference on, Aug 2011, pp. 69–76. [Online]. Available: http://dx.doi.org/10.1109/SMC-IT.2011.13
[22] R. Ridenoure, R. Munakata, A. Diaz, S. Wong, B. Plante, D. Stetson, D. Spencer, and J. Foley, “LightSail program status: one down, one to go,” in Proceedings of the AIAA Small Satellite Conference, SSC15-V-3, 2015.
When I worked there, our avionics was embedded C on bare metal. We had several problems we were trying to solve when we realized that switching to embedded Linux makes solving them easier. We wanted to abstract away from the hardware to be able to make more use of automated testing. Switching to Linux meant we didn't have to build our own HAL. For the algorithms I was working on, I wanted to do more of my development on a Linux system. And we saw it as a way to make on-orbit patches easier. I wasn't involved in making the transition to Linux though. That effort started around the time that my focus shifted to my master's thesis.
Something about this confuses me -- for years, I'm assuming since the earliest days of human spaceflight, the convention has been to used radiation-hardened hardware, yes?
I absolutely see the benefits of not using this expensive, unfamiliar, specialized hardware when you can instead use cheap, well-known, store-bought CPUs that everyone is familiar with and knows how to use.
But... how do you solve the original problem? Does it turn out that radiation is not that big of an issue after all? Is it a big deal, but SpaceX found a workaround? Do you have three CPUs all running the exact same computations and you assume there was no impact from radiation if at least 2/3 give the same result?
It makes me somehow both extremely satisfied, and a little jittery, to know we just flew two humans to the space station on off-the-shelf CPUs :)
The longer the missions, the higher the orbit, the more radiation fallouts then. The Moon or Mars missions would need to fall back to hardened CPU's and RAM, but there's not much need for high speed controllers there. Just reliable reboots. 200Mhz is enough. The controller high speed is mostly needed for the earth gravity. Up there it's much more relaxed.
My impression (from wikipedia) is that several popular radiation-hardened CPUs are just embedded CPUs with a different manufacturing process. They should be as familiar as traditional embedded CPUs, just old and expensive.
For example RAD750 is based on PPC750 which can be found in older macs.
https://sci-hub.tw/10.1109/MAES.2017.160182
The MarCO cubesats that flew past Mars in 2018 used Linux and Python with an off-the-shelf single board computer and camera: https://arc.aiaa.org/doi/pdf/10.2514/6.2016-2491
The Mars 2020 rover launching next month carries a helicopter that contains a phone SoC running Linux: https://rotorcraft.arc.nasa.gov/Publications/files/Balaram_A...