Slashdot Mirror
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."
... for inter-planetary patch tuesdays!
This is not the greatest
No one is safe from the IE7 upgrade. Not even on another planet.
Are they talking about the number of times the Earth has oribted the Sun since the rovers landed, or the number of times Mars orbited the Sun?
dom
is VXWorks, from Wind River ( http://www.windriver.com/ ). It's a *nix-like real-time OS.
"National Security is the chief cause of national insecurity." - Celine's First Law
Doesn't NASA know that this is a big no no? They are most definitely voiding their warranty by attempting this
Comment removed based on user account deletion
While I know you're making a joke, other people might be interested - they run VxWorks and the flight control software is written in Java. NASA are pretty fond of VxWorks - it pops up in lots of their projects
Global symbol "$deity" requires explicit package name at line 2. - If only $scripture started "use strict;"
Unfortunately the rover's first action was to declare Mars free and demand equal rights. Maybe including new AI protocols was a bad idea after all.
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.
Nunchuck skills, bowhunting skills, computer hacking skills, and I'm pretty sure it can also catch a delicious bass...
Push Button, Receive Bacon
This is another milestone in what may turn out to be the most successful space mission ever. After they pulled off two landings, and perhaps right after they they revived one of the rovers from a perpetual reboot error (the ultimate remote bios fix) and before the dust devils cleaned their solar panels, before they unstuck one from a sand dune, and even before the 3 month mission went 3 YEARS, these rovers are showing everyone who is paying attention that the information age driven robotic exploration, moving forward at moores law speed, is the obvious choice over still stuck in the 60's manned space exploration.
Why does Nasa refer to this as "revised flight software" these rovers don't fly
It's just a standard term. At NASA, "flight" software is mission software which executes within a spacecraft computer. "Ground" software usually refers to that which is used for spacecraft control/ground support (the software in the control center on Earth).
Worst...sig...ever!
They did everything they intended to accomplish the rovers and more. I'm just surprised they decided to upload the updates to both of them instead of just one of them.
c =7150&s=2
They may have done it that way because it may not possible for their mission support software on the ground to handle two different versions of flight software on Mars.
In any event, NASA's flight software development process is extremely rigorous, up to and including an Independent Verification and Validation center in West Virginia which independently evaluates all NASA flight software (http://www.ivv.nasa.gov/). It's not like it's a beta version of code being sent to the Rovers - the likelihood of finding a bug in the code that escaped testing was sufficiently low to justify uplinking to both rovers.
If anyone wants some light holiday reading, you can check out NASA's software engineering requirements at: http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&
Worst...sig...ever!
I guess since the two units are on free time, they figure it is ok to screw them up now.
... which - believe it or not - run a version of Windows 95, a frozen setup from back in the nineties, of which the software guys know every bit by it's first name.
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. That's all the code running on the Orbiters regular systems, exept only the third-party experiments with own systems and a non-critical original mid-nineties Thinkpad or two they take along
To give you a picture of what they have to deal with: A timing mistake in some piece of the shuttles navigation code by one cpu clockcount would put the shuttle 3 miles off course.
The Voyager Software Team reprogrammed a 20 year old device 3-quarters across the solar system to send color pictures instead of black and white - with a system that was only built to picture and send black and white.
You have not the slightest idea what these spacecraft-software guys are capable of and how insanely bulletproof their code is.
We suffer more in our imagination than in reality. - Seneca
You made what appears to be an attempt at a joke:
Checksum error, this file is corrupt. Please try downloading it again.Preventing checksum failure in high-latency communication isn't rocket science. You'd be surprised how many errors you can paper over by sending 50 percent more data.
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:
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?
Global symbol "$deity" requires explicit package name at line 2. - If only $scripture started "use strict;"
When I was still employed by the University of [Censored...the largest uni in New Zealand] I was called out to investigate a network problem at an off-campus site. Long-story-short I discovered that two Indian-born "techs" were trying to install the 272MB SP2 file on the site's hundreds of PCs via a 2Mb WiFi link all at the same time.
I attempted to explain to them that it was also the cause of most of the PCs now being frozen, something they were scratching their heads about, but they wouldn't listen, so I informed my boss and the site administrator then went to lunch. That was four years ago, and myself and all the other non-Indian, non-South African, non-work-for-peanuts techs were "let go" sometime later, but I bet those two guys are probably still on-site waiting for the install to finish.
This is a very good question. There's a very good, but not well known answer.
Mars has a lot of dust. Earlier missions got a good dusting on the landers and rover (Viking 1 and 2, Mars Pathfinder and the Sojurner rover). The more modern missions use solar cells for power, which are blocked slowly over time as dust builds up.
Dust accumulation on Mars solar cell arrays was a big problem within the early and mid-1990s Mars research community. Researcher Geoff Landis (http://en.wikipedia.org/wiki/Geoffrey_Landis) had an experiment on the Sojurner rover with a solar cell with a little movable cover glass on it, to see how much dust accumulated over time. Results from that were a prediction that solar arrays would lose most of their power over say four to six months.
Geoff had another experiment on the Mars Surveyor 2001 lander mission, which was supposed to try using static electricity to remove all the dust off a test cell, but the mission was cancelled after the Mars Polar Lander / Mars Climate Orbiter losses.
The two Mars Exploration Rovers were the next landers we sent. The expectation was that they'd last at least 3 months (90 days), and the hope was that nothing else would wear out until the solar arrays were too obscured for them to be able to power up properly anymore, perhaps six months or so into the mission.
What actually happened is one of those unexpected bonuses that the universe throws at you at random intervals. It turns out that the Mars winds at the height of the MER solar panels are just enough stronger than they are closer to the ground that the MER solar panels built up a moderate load of dust and stabilized there. There's plenty enough power remaining (except for mid-winter on Mars) for the rovers to keep operating, and it looks like the whole solar array dust problem just goes away if you put the arrays up off the ground.
There were some people who hoped that the arrays would be kept clean by the winds, but the best models we had before the MER rovers landed was that the winds weren't nearly strong enough. Pleasant suprise, and one that makes future missions a lot easier than we'd been afraid they were going to be. But not something which was taken into account in the MER designs to start with.
There was no expectation that the arrays would last more than about six months; designing anything else to last much longer than that, other than for safety's sake to make sure that nothing else failed before the solar cells dusted up, didn't seem to make any sense beforehand.
The next two Mars rovers are going to be powered by radioisotope thermal generators (RTGs) anyways, so that they can keep driving at night and in wintertime, now that we know that the basic MER design mechanisms will last for many years on the surface. Being able to turn on some headlights and keep driving at night should triple their effectiveness or better.
I think you meant to say "ping times must be out of this world".
I am the inventor of the hilarious refrigerator alarm.
That's been known for years and they haven't dared fix it.
In all fairness that's a software requirement (or lack of one) that the shuttle flight software group does not have control of. As has been rehashed several times on slashdot, the shuttle program early on took the savings from not building that capability into the ground and flight software (it's not quite as simple as it seems). It only became a problem recently when it restricted certain launch windows, and now the shuttle program is paying to add it in.
That sort of rigidity makes their methodology totally useless for software outside NASA.
As you say, it's totally useless for non-life critical systems. However, outside of NASA I know of DOD applications such ballistic missile guidance are equally as rigid.
Give me our full-featured, buggy software over nothing any day
As someone who has depended on NASA flight software, I'd rather sacrifice features for bug free code. That's a basic difference between consumer software and mission critical software.
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?
No other group at NASA writes flight software like this, because Shuttle is the only man rated launch vehicle. Orion will be similar (and it's software is being written by the same people). Other flight software at NASA is not this extreme, but there is a NASA software development standard for all flight software and it's still pretty rigid compared to consumer software.
Worst...sig...ever!
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.
:) 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.
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
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.
From my post in the viking 30th anniversary thread. 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.)
You are in a twisty maze of processor lines, all alike.
There is a lot of hype here.
Wrong planet. They should've sent them to Jupiter.
Lump lingered last in line for brains, and the ones she got were sorta rotten and insane.
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.