Once you build an "over the air" upgrade capability and a fail-safe mode (unlike my Android phone, thanks for nothing G & S) you can do it
But the software, as far as I know, is very modular, so this could be only an upgrade of some modules
Edit: by RTFA this looks more like a replacement rather than an update, like, making usage of all the landing software space since this is not needed anymore.
I was gonna say the only reason I can think of to not load the software before it takes off is because it isn't finished yet. I'd imagine memory is pretty small/inexpensive even if it has to be specially fitted to get blasted across the solar system and work next to a nuclear power plant.
Cassini launched before they had finished writing the software needed to enter and tour the Saturnian system. They finished writing it while it was en route and uploaded it prior to arrival.
I am fairly amazed that they need to do this because of what looks like space constraints. I wouldn't have thought that programming code would take significant space and the potential for screw ups just seems way too high to my mind.
Not to be rude, but it sounds like you're just unfamiliar with standard procedure.
"We designed the mission from the start to be able to upgrade the software as needed for different phases of the mission,"
>I wouldn't have thought that programming code would take significant space
It doesn't. I bet it takes just as much space as you imagine it does. The rover just have that little space to work with. These aren't last year's FPS gaming rigs with hundreds of gigs on SSD available. These are hardened, turn-of-the-millennium embedded computers.
>the potential for screw ups just seems way too high
Both Voyager and Pioneer spacecraft have been sent software updates, without fault. MSL was designed from the get-go to have software updates mid-mission.
> Both Voyager and Pioneer spacecraft have been sent software updates, without fault. MSL was designed from the get-go to have software updates mid-mission.
OK, but the Viking 1 lander on Mars was lost due to human error during a software update.
That's not to say software updates don't make sense, but you can't just justify them with "MSL was designed to do it and it's been done successfully before." Rather, you have to weigh the benefits and risk as usual. Luckily, I have confidence this was carefully though about and that the right decision has been made.
It actually has a reasonable amount of flash. Two gigabytes, empty of experimental data, should be able to hold multiple versions of the OS fine. They can't be particularly squeezed for space when they tossed in four times that much per camera.
I'll be baffled if they're doing this for any other reason than pushing the most recent and polished code.
Fortunately they have redundant machines. I suspect they'll figure it out.
It does sound funny that they wouldn't just have thrown a few more SSDs on there, but then again this is a space probe. When my SSD fails I get mad because I'm forced to waste three whole hours traveling to the Apple Store for warranty service. Curiosity's Apple Store is a bit farther away.
Their storage has to be radiation-hardened, guaranteed to last through the mission, have minimum weight, consume minimum power, avoid overheating under extremely weird environmental conditions…
It's also effectively required to be quite a few years old, in order to have had plenty of time to be baked in to the hardware and software platform. Curiosity was designed years ago, and it was based on designs that are far older, and on a mission like this it's more important to preserve the well-tested platform and hard-won expertise than to try something new. You spend the risk budget on more important things.
It's also effectively required to be quite a few years old, in order to have had plenty of time to be baked in to the hardware and software platform. Curiosity was designed years ago, and it was based on designs that are far older, and on a mission like this it's more important to preserve the well-tested platform and hard-won expertise than to try something new. You spend the risk budget on more important things.
This is why I really like the idea of sending vast numbers of lightweight probes built with consumer- and/or industrial-grade components. If some of them fail completely, it doesn't matter too much, because there are a dozen others on the same mission.
That's all well and good until you want to get some real science done. The kinds of instruments carried by Curiosity are expensive and their science output cannot really be achieved by a number of cheaper alternatives. Quantity does not always compensate for quality.
Besides, in that kind of an environment it doesn't really matter how many probes you send if the electronics aren't massively rad-hardened--every one of them is pretty much guaranteed to fail sooner rather than later.
That may become feasible when launch costs decrease. But when it costs $10k a pound to get stuff into orbit (and probably much more to get it to Mars) it pays to be conservative about the payload.
That reference states that it's about $4k for low earth orbit, $10k for higher orbit (geosynchronous transfer orbit). So the cost to get a pound to Mars is certainly >$10k.
Most commercial/industrial/military grade components will break permanently after a short while (weeks) due to charge deposit from impacting ions, or from ion induced short circuit. They will also malfunction regularly because of soft errors caused by the radiation (this could at least be solved with different types of redundancy).
You should have watched the press conferences where this was explained. The current software is optimized for the flight and landing. Now that they are on the surface, much of this functionality is not needed so they are switching to a driving and experimenting optimized version.
NASA has updated software exactly like this on a number of previous missions so no one expects any trouble.
I could be very wrong but since the software was loaded during transit to Mars before landing on the surface they must have had both loaded on local storage. Maybe the software wasn't done in time for launch?
Correct. It was scheduled for 2009 but due to problems with the new dry lubricated motors and software issues they decided to delay to the next launch window which of course was Aug 2012.
A very nice documentary is currently running on Discovery which goes into much detail on the construction of MSL.
I was wondering what kind of security they have on the upgrade system. Presumably the software packages are signed. No hacker on Earth wouldn't like to be able to say they'd cracked a system on Mars.
But then I thought, "Who actually has the hardware to broadcast to Mars in the first place?".
I've never realized there was a .org domain before. Thought something weird happened because I was logged in this site and when I tried to vote in your link I couldn't!
Looks like an example of progeny mimicking creator.
"You're someplace you've never been, seeing and experiencing things almost no one else gets to, and you spend your weekend fiddling with computers."
That's OK. We have all done it, and hopefully the outcome will be slightly better than "Crap, I hosed up my RAID array and now this random obscure OS build I installed is completely broken."
I'm fairly sure that completely separating system boot functionality and software reprogramming functionality was one of the first requirements of the rover software update subsystem!
Sticking the bootloader in a ROM is a fairly secure way to accomplish this.
I'm pretty sure they have a duplicate hardware setup for testing beforehand and debugging problems, which ought to help avoid such problems, and help fixing problems that arise.
There is plenty of redundancy to deal with this sort of thing and they've done lots of on the fly updating of various robot probes including on 40y/o Voyager 2 which had a flipped bit in its memory.
Am I the only one having a very nervous moment when the update's applied?