Timeline for Does anybody work on a "spacecraft linux"?
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 23, 2023 at 1:26 | history | edited | Rick 0xfff | CC BY-SA 4.0 |
Update in 2023 on changes in HPSC program.
|
| Apr 18, 2019 at 21:11 | comment | added | esduran | As an extra note, a recent paper titled "Current Use of Linux in Spacecraft Flight Software" was published. Check it out here: ieeexplore.ieee.org/abstract/document/8170152 I believe the paper is also on ResearchGate if you do not have access to IEEE | |
| Jun 9, 2017 at 5:43 | history | edited | Rick 0xfff | CC BY-SA 3.0 |
Add Planet Labs.
|
| Jun 9, 2017 at 5:35 | history | edited | Rick 0xfff | CC BY-SA 3.0 |
Update to add Astro Digital slides and a later discussion.
|
| Jun 9, 2017 at 5:29 | history | edited | Rick 0xfff | CC BY-SA 3.0 |
Update to add Astro Digital slides and a later discussion.
|
| Jun 9, 2017 at 5:13 | comment | added | uhoh | @Rick0xfff thanks for the reply, this is interesting stuff, and will continue to become more and more interesting. One example is very low and intermittent power; brandonlucia.com/pubs/chain.pdf and some background phys.org/news/2016-10-energy-harvesting-reliable.html the group abstract.ece.cmu.edu | |
| Jun 9, 2017 at 5:06 | comment | added | Rick 0xfff | @Giskard42: I heard about SpaceX using Linux on Falcon 9 and Dragon as well. In fact, in the case of Falcon 9, I heard that a scheme of fault tolerance was built in. For the short duration of a Falcon 9 flight, that is an interesting approach vs. expensive rad-hard electronics. However, given the rapid evolution of the booster, I could not confidently assert what their current approach without talking to current engineers on the avionics. ... Dragon: I imagine the power needs of the spacecraft computers are dwarfed by the power needs of life support and user interfaces. :-) | |
| Jun 9, 2017 at 4:52 | comment | added | Rick 0xfff | @uhoh: I used "code efficiency" loosely, but millijoules to accomplish a task, e.g., execute a function, is roughly correct rather than source code lines. For tight dedicated real-time tasks where no paging has to happen, it makes sense to get rid of MMUs. But if you have a diverse workload changing with time and mission phase, then the flexibility of an MMU is very useful, which is why NASA postulates Linux in a deep space mission with a high degree of autonomy. | |
| Jun 8, 2017 at 12:58 | comment | added | 0xDBFB7 | SpaceX uses Linux on all their flight hardware (not sure if in the spirit of the question, but anyhow) space.stackexchange.com/questions/9243/… | |
| Jun 8, 2017 at 5:02 | comment | added | slebetman | @uhoh: The last two plus number of tasks you can run per given time (it is related but not necessarily proportional). The problem is that industrial electronics will fry in space so you end up needing to program for a 100MHz CPU with 4MB of RAM or something. At which point all the things we take for granted as programmers become critically scarce. | |
| Jun 8, 2017 at 4:00 | comment | added | uhoh | @Rick0xfff "...this is an environment in which code efficiency and low power consumption far outweigh programmer productivity." What is 'code efficiency' exactly? Number of lines of source? milliJoules per iteration? Memory allocation? | |
| Jun 8, 2017 at 3:57 | comment | added | user12 | @uhoh 'Power required to perform the functions necessary', more likely. Memory allocation, for example, would naturally require more memory onboard - and it takes power to run memory. For a stick of DDR3, I'm coming up with numbers in the 5W range - quite a bit if you're on a tight power budget. Of course, satellites probably aren't using DDR3, but the point stands - the lighter your software, the lighter your hardware needs to be, which translates to less power required. | |
| Jun 7, 2017 at 20:40 | vote | accept | J. Doe | ||
| Jun 7, 2017 at 20:39 | vote | accept | J. Doe | ||
| Jun 7, 2017 at 20:40 | |||||
| Jun 7, 2017 at 20:27 | history | answered | Rick 0xfff | CC BY-SA 3.0 |