Mars Rovers' Software Upgraded

cheros writes to note the news that NASA is upgrading the software in the Mars rovers to make them smarter in a number of ways. From the article: "The unexpected longevity of Spirit and Opportunity is giving the space agency a chance to field-test on Mars some new capabilities useful both to these missions and future rovers. Spirit will begin its fourth year on Mars on Jan. 3 (PST); Opportunity on Jan. 24. In addition to their continuing scientific observations, they are now testing four new skills included in revised flight software uploaded to their onboard computers."

Re:Obligatory comment

[jimktrains]

Any one know why they picked Java and not ADA, C(?), or another language? Nothing against Java, it just wasn't my impression that it was used for any NASA stuff. Is it more extensivly used than jsut the MER's?

BTW, is the VM open source? (:-p)

Re:possibly the most most successful mission ever

[Jugalator]

I still have a hard time getting over the quality of their photos...

Just one picture [imageshack.us] I cropped from one of their ridiculously large ~3000x4000 pixel photos for display on a 24" Widescreen LCD. :-)

What's their power status?

[Jugalator]

Do anyone know of their power status?

Do Martian dust at all collect on their panels or are e.g. winds / dust devils regularly wiping that off completely so it's simply no issue?

I heard about some wheel problem on one of the rovers; is there any other special serious problems they're at all seeing at this point?

Re:Brings to mind...

[slamb]

As far as I know the On-Board Shuttle Software Group has a track record of 3 (in words: 'three') software bugs in installed operating code within 30 years of writing code.

I was much more impressed by that number before the story about avoiding having a shuttle in orbit at New Year's because the software can't handle it. That's been known for years and they haven't dared fix it. Is that counted as one of the three? No? Then they've fixed only three bugs in the last 30 years, and they have more than that, unless you think a serious misdesign is not a bug. If I confused the presence of bugs with having fixes for them, didn't consider a serious misdesign to be a bug, and had barely added a real feature in 30 years (at current head count, 7,800 man-years), I too could claim some ridiculously low bug count.

It also seems to me that the shuttle group's software situation is totally irrelevant to anyone but the shuttle group. Look at this part of the article you mentioned:

Take the upgrade of the software to permit the shuttle to navigate with Global Positioning Satellites, a change that involves just 1.5% of the program, or 6,366 lines of code. The specs for that one change run 2,500 pages, a volume thicker than a phone book. The specs for the current program fill 30 volumes and run 40,000 pages.

That sort of rigidity makes their methodology totally useless for software outside NASA. I occasionally hear people talk about how the Shuttle Group does software right, but for non-life critical systems, the cure is worse than the disease. Give me our full-featured, buggy software over nothing any day. There's got to be a better way.

I suspect it's also useless to the other groups in NASA. Do you actually know that the Mars Rover software was written in this manner?

Re:Obligatory comment

[pdbaby]

Nothing against Java, it just wasn't my impression that it was used for any NASA stuff

Apparently they have quite a lot of Java software for their client-side apps too. It's an interesting sort of history: they seem to have inspired Gosling to a degree, and they mainly chose Java because of platform agnosticism (I'm guessing they run a lot of different processors on their missions). I'm guessing the safety of Java compared to C is also handy.

Re:Obligatory comment

[Digicrat]

From what I've seen, it probably has more to do with individual programmer's preference than anything else in deciding which languages to use. Java probably has a high popularity in ground-side software due to the ease with which you can quickly develop a user-interface for the system, which given the number of developers on any space mission is required quite often.

Re:Brings to mind...

[djupedal]

1.) What does the 25+ year old orbiter have to do with a pair of terrain crawlers on Mars, specifically (rhetorically)? And what does flight software have to do with them now, please explain, thanks.

2.) "You have not the slightest idea what these spacecraft-software guys are capable of and how insanely bulletproof their code is."
You simplify things to no end, I see...sorry for that. Let's start, and end, with the failure to convert from standard to metric that caused that one Mars surface mission fail, shall we? Opps. The best software in the galaxy means nothing if the overall effort isn't done right, so please don't worry that someone may have made fun of just the code :) Funny tho, that all the software people got so easily rankled over a hint that there may be issues there - if there is no worry, why so much diatribe towards software's defense :) A bit of thin skin for some reason, eh? And please try to also understand, it was a joke...laugh...it's funny.

I'm not talking about JUST the software... I am talking about the overall logic of the tasked individuals and their efforts that lead to decisions such as this one, which in this case, happened to involve software specifically, but certainly not only. The original live time for these two rovers was 90 days - after that, new ideas are on the table...that's why it is called 'free' time, because it is all 'extra' time that was never planned for and now begs to be utilized.

As good a thing as that is, someone, sooner or later, is going to ask the question why didn't they know this? And for anyone that shouts "This is Mars! anything can happen!", yes, of course...but why did the original plan not include at least some options for extended runs then, instead of working them now as if the two units were a sandbox, that's all I'm saying.

Re:the most intense firmware upgrade ever..

[ColaMan]

There's already a guy who's done that - the demise of one of the viking landers was because of a firmware update that accidentally overwrote a critical program section.

From my post [slashdot.org] in the viking 30th anniversary thread [slashdot.org].

Funny, all the NASA references these days seem to edit that little bit of info out, and merely say that it was shut off due to impending battery failure. Other sources - and my memory suggest otherwise.

Ah! Here's a reference from the RISKS digest Volume 3, Issue 60 - 1986. (A digest that is still running today, and is a highly insightful window into how technology screwups mess with daily life.)

Ground control lost contact with Viking 1, apparently due to a
software change transmitted to the lander that was accidentally
overlaid upon some mission-critical software already in the lander's
computer. (Bruce Smith, "JPL Tries to Revive Link with Viking 1",
@ux(Aviation Week and Space Technology), April 4, 1983, Volume
118(14), page 16.)

Re:Obligatory comment

[Decaff]

The safe memory management is an important issue. But there is another advantage of Java which is that the byte code Java is compiled to (at least as an intermediate stage) is pretty compact, which makes it very suitable for low-memory systems.

Re:Obligatory comment

[Digicrat]

"I was wondering about this too, but I imagine (and sorely hope!) that they develop any space-related software using formal methods, which would probably discard any idea of development speed"

Speed and convenience aren't necessarily the same thing. Most space-related software is subject to much more thorough processes than this, however when your talking about small development utilities to aid the programmers in managing relatively minor parts of the development process, a quick GUI (or bash script) works well. Remember, not every piece of code written in space-related applications are intended for usage on the actual space-flight hardware or ground control systems, many are just quick utilities to test other components or organize data along the way.