3 ms·

Here's the paper that summarizes the results of the Remote Agent flight experiment ("RAX"), which is the project Erann was working on at the time: www-aig.jpl.

by mturmon 16y ago

Here's the paper that summarizes the results of the Remote Agent flight experiment ("RAX"), which is the project Erann was working on at the time: www-aig.jpl.nasa.gov/public/papers/rax-results-isairas99.ps The stuff about integrating a Lisp executive/planner and the rest of the C flight software is in section 4.1. It's for sure none of this flight software is in Lisp any more. Additionally, I would be highly surprised if any shred of the ground software that supports it is in Lisp. Both flight and ground s/w is almost certainly in C/C++ and Java. One of the successors to RAX is: http://ase.jpl.nasa.gov/ http://ase.jpl.nasa.gov/ in which an Earth-orbiting spacecraft can recognize events like volcano eruptions) and autonomously (without ground control) take extra data from it. * It's hard to appreciate just how unwilling a flight mission is to take on any unnecessary technical risk. Risk, along with cost, schedule, and mass, is one of the fundamental things mission designers must cope with. Lisp looks like risk, and risk will be eliminated ruthlessly (as in the meeting Erann describes in the OP). Additionally, there are the software lifecycle considerations. That is, flight s/w, if it works, tends to be passed forward from mission to mission, and quirky choices tend to be weeded out.

deleted 16y ago
[deleted]
stcredzero 16y ago
It's hard to appreciate just how unwilling a flight mission is to take on any unnecessary technical risk. Risk, along with cost, schedule, and mass, is one of the fundamental things mission designers must cope with. Lisp looks like risk, and risk will be eliminated ruthlessly I've spoken with programmers at NASA. There have been times when management thought source control was a risk. Discovering a bug in the mathematics of an algorithm and fixing it is a risk. (Seriously, management was like: the software worked last time with the math bug, so it should work this time with the math bug.) ...flight s/w, if it works, tends to be passed forward from mission to mission, and quirky choices tend to be weeded out. Like most organizations, I'd bet most of these decisions are more "gut feeling" than based on anything approaching empirical. (Arguably, the continued existence of old-school companies using "Steak and Strippers, Baby!" sales tactics is a bet that such irrational decision mechanisms persist.)
- mturmon 16y ago
  Regarding risks, I think you're understating the sophistication and importance of risks on flight projects. (I work at JPL, but not on flight projects; once upon a time, the OP's office was right down the hall from mine.) A modest sized flight project will have a risk list which is itemized down to great detail, covering many pages, and this list will be one of the main things the mission managers work on reducing. In general, there are two parameters, likelihood of the risk materializing, and cost if it does. Sometimes the cost is easier to bear (dollars and schedule), sometimes it's harder (lose the mission). For units like dollars and schedule, it does make sense to do a weighted average (sum over risks of probability * cost); for others it does not. People go farther and use various Monte Carlo methods to deal with risks that interact, so that the sum above does not work. Here's someone at JPL who's in that area: http://www.usc.edu/dept/ise/directory/jairus_hihn.htm http://www.usc.edu/dept/ise/directory/jairus_hihn.htm
  - stcredzero 16y ago
    Sounds like JPL is a lot more sophisticated than NASA in this regard. This is weird, since NASA flys a lot more manned missions.
rbanffy 16y ago
> Both flight and ground s/w is almost certainly in (...) Java. Which is why we have to use chemical rockets - Java's license would prohibit it from controlling a nuclear engine ;-) Seriously, I have seen many projects jettison good, solid, time-tested and efficient code on the grounds that it was written in a language "nobody understands" (exotic and hard-to-master things like... Python). My last problem was with someone having the bright idea of re-implementing Amazon's S3 internally because they would need to handle huge amounts of data. It turns out their "huge amounts of data" is a couple terabytes of large files. The other was when someone said a given system was written using J2EE "(what else?)". Sometimes I wonder if this is the dumbest generation ever to operate the smartest tools ever.
- dedward 16y ago
  Pretty sure most ground software UI stuff is in Java, and on-board spacecraft stuff is compiled down to the smallest package possible.

by mturmon 16y ago

deleted 16y ago

[deleted]

stcredzero 16y ago

It's hard to appreciate just how unwilling a flight mission is to take on any unnecessary technical risk. Risk, along with cost, schedule, and mass, is one of the fundamental things mission designers must cope with. Lisp looks like risk, and risk will be eliminated ruthlessly I've spoken with programmers at NASA. There have been times when management thought source control was a risk. Discovering a bug in the mathematics of an algorithm and fixing it is a risk. (Seriously, management was like: the software worked last time with the math bug, so it should work this time with the math bug.) ...flight s/w, if it works, tends to be passed forward from mission to mission, and quirky choices tend to be weeded out. Like most organizations, I'd bet most of these decisions are more "gut feeling" than based on anything approaching empirical. (Arguably, the continued existence of old-school companies using "Steak and Strippers, Baby!" sales tactics is a bet that such irrational decision mechanisms persist.)

mturmon 16y ago
Regarding risks, I think you're understating the sophistication and importance of risks on flight projects. (I work at JPL, but not on flight projects; once upon a time, the OP's office was right down the hall from mine.) A modest sized flight project will have a risk list which is itemized down to great detail, covering many pages, and this list will be one of the main things the mission managers work on reducing. In general, there are two parameters, likelihood of the risk materializing, and cost if it does. Sometimes the cost is easier to bear (dollars and schedule), sometimes it's harder (lose the mission). For units like dollars and schedule, it does make sense to do a weighted average (sum over risks of probability * cost); for others it does not. People go farther and use various Monte Carlo methods to deal with risks that interact, so that the sum above does not work. Here's someone at JPL who's in that area: http://www.usc.edu/dept/ise/directory/jairus_hihn.htm http://www.usc.edu/dept/ise/directory/jairus_hihn.htm
- stcredzero 16y ago
  Sounds like JPL is a lot more sophisticated than NASA in this regard. This is weird, since NASA flys a lot more manned missions.

rbanffy 16y ago

> Both flight and ground s/w is almost certainly in (...) Java. Which is why we have to use chemical rockets - Java's license would prohibit it from controlling a nuclear engine ;-) Seriously, I have seen many projects jettison good, solid, time-tested and efficient code on the grounds that it was written in a language "nobody understands" (exotic and hard-to-master things like... Python). My last problem was with someone having the bright idea of re-implementing Amazon's S3 internally because they would need to handle huge amounts of data. It turns out their "huge amounts of data" is a couple terabytes of large files. The other was when someone said a given system was written using J2EE "(what else?)". Sometimes I wonder if this is the dumbest generation ever to operate the smartest tools ever.

dedward 16y ago
Pretty sure most ground software UI stuff is in Java, and on-board spacecraft stuff is compiled down to the smallest package possible.