Isn't temperature cycling on external hardware (like the Pancams and Navcams) still an issue? As far as I know, Pancam has no survival heater, only a warmup heater for nighttime operations. Surviving 2000 sols' worth of deep temperature cycles is proving to be a little bit of a challenge for our MSL instruments. (Up on the mast we can't get any of that nice RTG waste heat to keep us warm at night.) Maybe the margins for the MER cameras were really large, or maybe our solder joint lifetime models are just way too conservative.

Sure, but luck doesn't usually come with a clearly-marked price.


This is the conventional view (and, as a Mars'98 veteran, one I'm getting tired of hearing, can you tell?) But how much more money would it have taken? Ultimately, both Mars'98 failures and the Genesis failure could have been fixed with 5 extra minutes of engineering time apiece, costing a few dollars. If you think that you eliminate mistakes, even stupid ones, with buckets of extra money, you're dreaming. Look at how close some of the MER problems came to failure, and they spent 4x what Mars'98 cost. Look at the HST and Galileo problems. I suspect that a large fraction of the money spent on mission assurance is "wasted" in that it solves no problem that could have caused a failure. Taking a completely scattershot approach to mission assurance has lead to escalating mission costs. There simply has to be a balance. I can think of a lot of mission assurance effort on Mars'98 that could have been left out, and which only diverted attention from the real problems.

Mars Observer wasn't part of FBC; Goldin wasn't even working for NASA when it was being developed, and he had been the administrator for less than 6 months when it was launched.

And to say that the '98 missions failed because of an inherently-flawed program is a gross oversimplication at best. Look at the razor-thin margins that separated the MERs from failure.

This is just inaccurate, self-congratulaory hype from Cornell. All they "cracked" were the PRN codes being used on the development satellite. The PRN codes for the operational system will be publically available. The current satellite isn't useful for navigation.

Obviously. But my point was that the heavier structure of the Russian module didn't maintain its structural integrity in this case, did it?

How about if the module just pops a seal and has to be abandoned in place? That's pretty much what happened with the Spektr module on Mir, "battleship" or no.

I'd rather fly a kg of payload than a kg of insufficiently lightweighted structure. And I really don't think that chem milling adds that much expense. It's extensively used in commercial aircraft.

If it meets the strength requirements, why do you want to make your structure heavier? Chem-milling got us to the Moon, after all; it was extensively used on the LM and is a well-established technology.

I don't think this is why the ISS cost so much.

Well, Jim certainly knows more about Pancam than I do, but it's a little surprising to me. Maybe it's because the lenses are so optically slow. The radial distortion parameters in the CAHVOR model for Pancam are certainly not zero, but that may be an artifact of the way the CAHVOR pinhole model works.

Given fiscal realities, imagining 8 or 9 of anything is pretty much living in fantasyland at this point. It's important for somebody to live in fantasyland, I guess, but I've got real flight hardware to design and build, and I lose patience with science advisory groups pretending to understand engineering.

We've debated this many times on this forum. Given the very limited ability of the MER system to land at interesting places, I'd wonder about the science return of this. Plus, it's become somewhat obvious that the mobility of the MER system in soft, sandy areas is pretty limited. Science advisory groups should be recommending science, not engineering solutions in search of problems.

Of course, they may not be talking about the MER EDL system but only about the rover proper. But that's a whole different set of engineering tradeoffs, and the resulting vehicle may look little like MER in the end. MER's heritage is in subsystems, not necessarily in the overall vehicle design.

I have to take exception to one thing that Jim said, about the Pancam field of view. It isn't necessarily as simple as taking the IFOV and multiplying it by the number of pixels, because most optical systems with fields of view more than a few degrees have optical distortions that cause the IFOV to vary slightly from the center to the edge of the field. I'm not sure if the Pancams have appreciable distortion, but the Navcams certainly do.

I find the candor of these comments very refreshing; there should be more of this. I think the engineering on MSL would be better served if it was more widely acknowledged that a lot of MER involved such close calls. In some quarters there's an awful lot of "we have to do it this way because that's how we did it on MER" and frankly, some of these things (the pyro controller would be a good example) are not worthy of emulation.

The line between success (e.g. MER) and failure (e.g. MPL) is really a lot thinner than many people would claim it is.

I think you're confused. What you're describing is called Time Delay Integration or TDI, and has nothing to do with pushframe, which is a multispectral technique. It's true that these can be combined, but I don't know of that being done in any previous flight instrument (though our JunoCam instrument will do it to a limited degree.)

We call this a "pushframe" system. An N-color pushbroom system needs N separate linear CCDs and N different signal chains. An N-color pushframe needs one area CCD and one signal chain. MARCI weighs 350 grams; it would be simply impossible to build a linear pushbroom system for anything like that mass.

As for the difficulty of processing: who cares? Computers are fast and cheap.

See http://www.msss.com/mro/marci/images/2006/...tail/index.html

I haven't seen the book or the text therein, so I may be way off base, but my concern with it is that Jim may appear to be taking too much credit for what in reality was the team effort of hundreds of people. It's one thing for Squyres to write a personal account of the mission from his perspective (and his narrative certainly gives credit where credit is due); I'm just hoping that Jim didn't go over the line with this book. The subtitle frankly doesn't bode well.

Furthermore, if it's claimed that Charon was named according to this convention, that's back-rationalization: the name was picked purely because it was close to Jim Christy's wife's name.

From the Word document:

If there is such a convention, it would seem to not apply to Uranus.

It's an interesting question as to whether the rovers have ever been driven to a specific location solely to get the most aesthetic view of something. I would tend to doubt it, though it's probably impossible to sort out intentions after the fact.

And as long as I'm ragging on "the Ansel Adams of the space age", I'd be curious to know how many of the most aesthetic MER images ended up that way because of some intentional choice of planning options, and how many of them are aesthetic simply because the scene was aesthetic and the images were technically well-commanded.

Oh, OK. So a working definition of a "photograph" from an orbiter is "an oblique image of no scientific value."

Not to get bogged down in the semantics, but I disagree. See, for example, Tim Mutch's remark in http://history.nasa.gov/SP-425/ch19.htm about the first Viking panorama:



And yes, if some people are ticked by Jim's glory-hounding, intentional or not, I can't blame them. I already gave him a fair bit of crap for Squyres calling him the "Ansel Adams of the space age".

Most of the teams preprogrammed the entire route from airphotos/satellite images and could have (or did) dead-reckoned nearly the whole way on GPS without even having vision or laser-scanning systems. And the vision systems were highly optimized to find the road edges.

I looked at this fairly extensively a few months back, and in my opinion the applicability to planetary rovers is pretty low. I won't even discuss the relative power density between gasoline and solar or RTG systems. Between lidar and racks of processors, the GC vehicles were burning through kilowatts of electricity.

And on a road.

Three answers: mass, power, and cost. A single flight RAD750 board uses tens of watts, weighs over a kilo (just for the board, not counting card cage, etc.) and costs, last time I checked, nearly a million dollars. And we don't need more cycles anyway.



Games have driven graphics development, sure. But I would argue that there's nothing like real AI in any game out there. Real AI of a sort useful for rovers would be able to sense the environment and react/plan accordingly. Games just don't have to do that; they define the environment, there's no need to sense it.

Generally, Doug is right. There's a lot of semi-informed speculation on this thread, less real info. The RAD750's performance is comparatively poor from two factors: first, the process changes that make its internal registers immune from radiation-induced bit flips slow down the clock speed considerably, but more importantly, external components, also rad-hard, are running more slowly, as are the busses. The RAD750 on MRO doesn't even have an L2 cache and it's using a 33-MHz PCI bus.

If you wanted a non-mission-critical computing resource that didn't have to be totally bulletproof against radiation, there are many options, including commercial processors that happen to be latchup-immune and various gate arrays. For our MSL instruments we are using Xilinx FPGAs; clocked at 40 MHz they are many times faster at doing JPEG compression than code running on a fast desktop system would be.

Rover speed is typically limited more by the capabilities of the drivetrain and the overall power budget. It's not like MER would be going 50 KPH with a faster processor. Despite what AI people will try to tell you, we don't know how to write autonomous nav software regardless of how fast our processors are.

And finally, MIPS (aka "Meaningless Indicator of Processor Speed") is a bad metric for judging computer performance in this or any other problem domain.

I'll have to retract that because I can't find any public supporting documentation about rises in instrument cost. It might have just been that VIMS was the most expensive instrument.