The CPUs of Spacecraft Computers in Space
cpushack.com
cpushack.com
https://forrestheller.com/Apollo-11-Computer-vs-USB-C-charge...
Hacker News comment link: https://news.ycombinator.com/item?id=22254719
We now have pretty capable low-power SoCs and FPGAs that we've yet to see broadly leveraged for govt. space applications. SpaceX flies Starlink with Xilinx FPGAs, while NASA and DoD are still baselining new platforms on incredibly expensive (albeit rad-hard) PowerPC RAD750 and similar. This is a huge bottleneck for any computationally intensive task we might want to do on-orbit, and I'm curious if or when it will change. It's one technical reason, in my opinion, that the private sector is currently calling the shots in space.
But your comment makes me wonder if the private sector doesn't have those certification requirements?
The other differentiating factor is that the private sector is not sending multi-year (indeed multi-decade) deep space missions, where the need for battle tested systems is paramount.
So like the Perseverance rover on its way to Mars is powered by redundant RAD 750s (same as Curiosity), but the Ingenuity helicopter along for the ride is powered by a Snapdragon 801.
It will be interesting to see how it holds up.
After a few minutes of awkward shock and denying all involvement, we realized it was a colleague at the same research institute (and of the same name). He was, one building down, doing his PhD research on radiation hardened detectors for the CMS experiment at CERN(1). He was using the source for the testing. But I had a minute of real stress before that came together in my mind...
(1) I think this was his work: https://onlinelibrary.wiley.com/doi/abs/10.1002/pssa.2007763...
The real problem is that we don't have good solutions for improving the performance of rad-hard designs, so we're stuck with older, larger process sizes that limit what can be implemented. Look at the lengths involved in getting A* to run on Curiosity, and you see just how limiting the hardware is. Everyone, Nasa especially, wants more compute available.
In low earth orbits and shorter mission durations, you can get away with redundant hardware instead of rad-hard. Most of the damage done by radiation is upsets, so you can reboot the affected hardware and keep going. But on an unprotected design some of the damage can be permanent, and thus redundancy alone isn't enough for longer/farther missions.
RAD5500?
The reality hasn't changed much, though, there's really only one game in town for high rad-hard performance, and it's still well behind conventional processors.
It works for some things, but for pathfinding it isn’t a great fit.
The other issue is bandwidth between the craft and Earth, which is quite limited.
Maybe there would be benefits to a “orbiting datacenter” around Mars carrying a bunch of rad-hardened compute? I assume NASA has considered this and decided it would be a bad idea.
So practically it would still experience significant radiation.
But having the main compute for Mars remain in orbit with the relay isn't a bad idea.
There must be some equation of motion in space robots that combines terrain difficulty, robot speed, round trip time to Earth, and how far ahead you’d need to be able to see.
Curiosity moves about as fast as a Roomba. The ping is (min/avg/max) 10’/24’/40’. Ergo, it needs to be able to see X yards ahead of itself to plan A* from Earth, requiring a camera boom Y feet tall producing images with Z megapixels of resolution.
I wonder what X, Y and Z are.
Some quick googling says-
Curiosity max speed equals 0.08699 mph.
Roomba equals a foot per second which is 0.682 mph.
Off by about 7.82x.
I remember once hearing that Curiosity, flat out, could do 1km a day.
- You want a travel speed of 0.5 m/s - Worst-case round trip time from command to result is 40 minutes, or 2400 seconds - Max distance covered is 1200 meters - Assume you can drive over any rock 10cm or less in size (the rover can do better, but at a reduced speed)
So you need to scan an area 1200m x 1200m, with range accuracy of, say, +/-5cm. Forget the camera boom height, or the time it might take to scan and process, there's no sensor that will give you that kind of accuracy. The stereo baseline would be huge, and leave you entirely at the mercy of whatever texture or not a given part of the martian surface has to offer. LIDAR is OK if you definition of "long range sensing" is larger objects at 200m. The time cost for shipping back all the raw data for processing would kill performance as well, and if you wanted to process it locally the compute requirements would be just as high as doing the planning locally as well.
Onboard, or at least much closer,compute is the only way forward in autonomy. Honestly, the best bet on improving local compute would be to send a robot bulldozer, some C4, a rack full of milspec servers, and a big RTG. Blow a nice crater, push the servers to the bottom, and bury them in dirt for shielding. If you get really lucky, you could find some old cave or lava tube.
One drawback of the remote A* approach is that you end up using more energy as the rover would have to be constantly communicating with its onboard antenna. Its relay satellites are only in range for a limited period each day. Fine grained maneuvers (like drive around that big rock to get to this small rock) would also prove difficult because of likely errors in the rover's inertial-navigation system.
Also it seems to be doing sometype of image processing to identify a suitable landing spot and guiding on to that point.
The RAD750 in particular is a bit of a nightmare because of the high pin count, need for a support chip, and the 32-bit bus forces the use of more RAM and ROM than a smaller micro would need. I took a pass on that. I also never have liked IBM's reverse bit numbering and the implications it has on SRAM power consumption.
That makes sense but I didn’t realize that it was difficult to simple swap the wiring. Are the physical pins ordered backwards as well (that is, do PowerPC’s A31 and A30 appear where A0 and A1, respectively, would be on a “normal” system)?
Almost all modern memory is built in a large matrix where the upper bits select the row into a buffer and the lower bits control a multiplexer that selects a slice of that row. Scanning incrementally through the memory will hit the fast multiplexer path and result in much faster access.
Propagating into the whole matrix at each increment is not only a power draw but a massive slowdown.
Can you link to something that goes into detail? Googling it doesn't turn up anything relevant, but it sounds like it'd be interesting to read about.
Ignoring that Starlink isn't very far away, I would assume NASA stuff would also have FPGAs and ASICs on them - they aren't CPUs and aren't used like them.
“ A.30 Software. Computer programs, procedures, scripts, rules, and associated documentation and data pertaining to the development and operation of a computer system. Software includes programs and data. This also includes COTS, GOTS, MOTS, reused software, auto generated code, embedded software, firmware, and open source software components.”
https://nodis3.gsfc.nasa.gov/displayCA.cfm?Internal_ID=N_PR_...
Here’s the website for the SpaceCube platform (developed at NASA Goddard). This is a little out of date (I worked on flight software for a mission called STP-H6 which I don’t see listed here), but gives an idea of how this idea is slowly but surely gaining steam in NASA.
The cost savings from using regular chips is so high that I bet SpaceX will continue to use them even in deep space. Just surround them with sheilding. When a $400 desktop cpu is 500X faster than a $40,000 space rated one a couple pounds of shielding is well worth it
The effectiveness of shielding is proportional to its mass and thickness, and both are at a premium for spacecraft.
SpaceX missions are also a lot shorter. Having one unrecoverable latchup a week isn't a big deal if your mission is 2 weeks long. If you mission is 10 years, it starts to become a problem (especially since some radiation damage can be cumulative)
>NASA and DoD are still baselining new platforms on incredibly expensive (albeit rad-hard) PowerPC RAD750 and similar
NASA and DOD have also been sending up Xilinx and Altera boards for ages (even the non space-grade ones). However you can get rad-hard ARM CPUs that are cheaper and more powerful than the ones in a Zynq board.
The lifetime and radiation environment for those applications are very limited, though. It seems that for short missions (e.g. <2 years) and low orbits (<500km), COTS hardware should be fine if properly shielded.
It would be interesting to see what difference it actually makes for HEO or even BEO missions, especially if a high degree of redundancy is introduced as well.
Unless it happens in your attitude control system or your command and control system, causing you to lose control of or communication with your spacecraft.
http://www.esa.int/Enabling_Support/Space_Engineering_Techno...
1: By process, where chips are created with special or larger features to better resist cosmic rays. This is Expensive since they're made in very low volumes and the cost of the new fab line can't be spread among many millions of units. Instead, a few thousand chips might be made.
2: By design, where redundant systems such as triple redundant memory or voting computers are used. This is probably the most interesting as you can get into issues like the Byzantine Generals problem here. All the redundancy can be implemented in a single FPGA by simply routing out the design 3 times and using voting logic, assuming the FPGA is large enough.
3: By shielding. Just fly regular chips in a shielded box. This causes thermal issues, but is sometimes necessary, such as in Juno, which has to deal with the enormous radiation flux around Jupiter.
A small amount of water for shielding is undoubtedly much more massive than simply using bigger, rad-hard processors.
If we're talking about $50/kg [1] in the future... well...
- Sending a few kg of water (or other shielding) to space costs a fraction of the price of a fast non-rad-hardened CPU.
- It really costs less than the extra development cost associated with having to use bespoke toolchains.
[1] Number from the other space post on the front page today: https://getmeflyingcars.medium.com/how-much-does-it-cost-to-...
Looks like it was deleted.
> - Sending a few kg of water (or other shielding) to space costs a fraction of the price of a fast non-rad-hardened CPU.
It doesn’t sound like a few kg is going to cut it. Recall that a 1 kg of water is about 1 L, which gives you about 6 cm of shielding, which is simply not enough. That’s less than 50% attenuation of the ionizing radiation you find in space. Mass increases with the cube of the thickness. If you want 20 cm of shielding, that’s 33 kg, and something like 86% attenuation.
It seems to me like there are better things you can do with your mass, which also needs to be spent on things like fuel for stationkeeping. Lower mass also means more satellites.
> - It really costs less than the extra development cost associated with having to use bespoke toolchains.
POWER is not exactly some obscure ISA. It is well-supported and battle-tested. You don’t need a bespoke toolchain.
And that's something you'll get even if you're running MS-DOS on 286 in space ;-)
(I understand why, but that this is so just blows me away)
Source: The scientific objectives and payloads of Chang'e 4 mission. DOI 10.1016/j.pss.2018.02.011. No free source, use Sci-Hub.
Is this just for NASA craft? Are there any regulations for private craft or international standards?
They do modify them slightly to remove the lithium-ion batteries, which you do not want inside a space craft.
I think they replace them wit NiMH cells if the devices still need to be battery powered.
Diagnosing novel failures on hardware in space is hard, but the overall types of failures and their underlying physical phenomena are known. Obviously, in the case of a satellite that goes completely unresponsive you can't answer 100%, but you may have sensor data in the leadup to the failure, or from other "nearby" satellites that would allow you partially reproduce conditions before the failure in a test scenario.