Correct. In the nominal orbit the closest approach to Io is a little under 200,000 km.

Without some kind of active solar panel cleaning, which we don't know how to do in a practical and flight-qualified way, there is simply no way to guarantee even two years of mission life on Mars without an RTG. The MERs got lucky with cleaning events.

MSL was designed to last two years, which means in general that it was life-tested for four years. Anything past that is gravy.

That said, it's been stated that the degree of wheel damage was unexpected. Hindsight is 20/20.

Technically this isn't salt and pepper noise because there are no dark pixels, only bright ones. (No pepper, only salt.) So these are unlikely to be transmission errors (they couldn't be anyway because image compression causes transmission errors to look completely different) but hot pixels. Hot pixels are worse with longer exposure and with higher camera head temperature.
As noted the rear hazcams are closer to the RTG and also to the other neutron source on the rover, DAN.

I doubt that the holes at this point affect mobility. But despite many of the historical comments in this thread, it's now obvious that the magnitude of wheel damage was not anticipated, and given the retreat from driving on sand, there is probably something unexpected about that as well. Clearly soil properties and their effect on mobility are very complicated, analysis and testing under Earth conditions can only go so far, and the system is very highly constrained for mass, power, etc.

We'll just have to wait and see how this plays out.

I thought they had done a lot of testing of driving on sand, so to be concerned about it seems odd. Is there something unusual about this particular sand?

If this had been an option for MSL, it would have been done that way. Simple scaling makes wheel mass go up too much and then there are ripple effects throughout the whole system.

Clearly MSL went a little too far in the lightweighting direction, and I'm sure this will be addressed for 2020, but the problem is more involved than might be immediately thought.

There's some information about SHERLOC in http://www.hou.usra.edu/meetings/georaman2014/pdf/5101.pdf

Generally the main contract is with the PI's home institution, and hardware development is subcontracted. If the PI is at the same institution as the hardware developer there only has to be one contract. We've done it both ways historically.

Are you asking if we were part of other proposals that lost, or other proposals that won? I can't answer either question, but in the abstract the former is usually never disclosed, and the latter would presumably become public at some point.

NASA Selects MSSS to Provide Science Camera for Mars 2020 Rover Mission
http://www.msss.com/news/index.php?id=121

But come with some significant ones of their own -- they're mostly linescan, with very limited exposure times, and optically not very fast.

I expect that every available instrument will make an attempt, but if no visually spectacular product comes of it, I won't be too surprised.

I'm not sure it's necessary to just repost information that can be seen on the ISEE-3 website.

http://mars.jpl.nasa.gov/msl-raw-images/ms...993MF0_DXXX.jpg shows plasma, as do several others.

The video is very interesting, but it doesn't describe exactly what is meant by "test to failure". Usually this has a very specific definition for a subsystem test like this. It's not clear to me that the rover would be unable to move with one or more wheels broken even this badly.

What is the test for your hypothesis that you expect to be resolved in a year?

BTW, referring to the scientific community as "so-called experts" is a sure way to have your work dismissed.

With all due respect to the modeling, I'd only draw conclusions from properly-calibrated images, which I've seen none of in this thread (maybe the Viking images, though Viking calibration is somewhat problematic.) The coverage of the sky at different elevations has been very limited from MSL so far, though there was one zenith image taken with MAHLI if I recall correctly.

Of course, considering the title of this thread, the whole discussion of sky color is wildly off-topic.

I thought it had to use visodom to detect slips, and I wouldn't think it would do so on such a short time scale, but maybe it can.
http://robots.stanford.edu/isrr-papers/final/final-24.pdf

Moreover, as has been discussed at length on this forum, the green tint is largely if not completely an artifact of the Mastcam IR cut filter bandpass, and is not a real feature of the martian sky.

The extended mission begins on sol 670 as far as I know.
http://starbrite.jpl.nasa.gov/pds/viewMiss...CE%20LABORATORY

Not all channels are saturated, so I got reasonable results just taking one as grayscale and tinting it to the overall unsaturated color. I'm sure someone willing to put in the time could do a better, more complete job.

The exposure time was set by autoexposure when the camera was looking into shadow, and then the drive put us in a much brighter illumination geometry. Next time we'll probably use a pre-calculated manual exposure.

I'm a little surprised that no one has commented on the MARDI drive video yet.
http://mars.jpl.nasa.gov/msl/multimedia/ra...mp;camera=MARDI

Yes, we know it's overexposed.

Since we're just contractors on this mission I can't say anything about it, but if you look at the image of the spacecraft forward deck in http://www.planetary.org/blogs/guest-blogs...-structure.html you can see the two Navcams and the Stowcam -- they look like little goblets with their baffles.

Not that I'm aware of, because there's no compelling science to be done by such a camera.

FWIW, there was a purpose-built optical navigation camera on MRO for technology demonstration.

We already built the cameras and flew them to Mars, so the incremental cost of taking these images, even if they had no scientific utility at all, is not very high.

Either it's poorly worded and the spacecraft is already in engineering mode, or it's possible to set the multiplexers to produce a modulated data stream but not pull actual data from sources on the spacecraft. In the latter case one presumes the data being sent would be fill or garbage. I haven't found any information that describes the ISEE systems in enough detail to know for sure. http://nssdc.gsfc.nasa.gov/nmc/spacecraftT...do?id=1978-079A has a little but not much.