>>> Yes. Like I've said above the explicit purpose of this mission is to gather advanced scientific data which requires comparatively bulky instruments and high power availability. Because it is so ridiculously expensive to get anything to Mars you want it to last as long as possible. "Disposable drones" make absolutely no sense when it costs so much to launch them into orbit, transport them 60 million km across the solar system, and then enter the Martian atmosphere and land in a coordinated place on the surface. Each gram you get to that point costs many thousand dollars. You don't just plan your strategy around losing a bunch of them - that would be many hundreds of millions of dollars down the drain. <<<

I've thought about what you have said and I think that we are measuring the likelihood of success in different ways. I'm measuring it in terms of the likelihood one pair of devices will complete the outcome at the cost of all the others and, if I am correct, at some level you are measuring it in terms of reducing the possibility of a loss while achieving the mission objectives.

I think that we can afford to build disposable machines because if they are tiny and can fit within say a 50 cm cube (which is the diameter of curiosity's wheel) the mass of each machine will also be radically less. Curiosity weighs 899 KG, a well designed vehicle base could weigh as less as 1 KG with instrumentation we could work with the assumption of 2 KG. That is around 450 rovers! If they are divided into teams of say 6 and are dropped off using some method at discrete intervals then you have 75 teams exploring the martian surface. If each team explores during just the warm martian months (I'm working with assumption of 400 sols) with a rate of a very conservative .5 m^2 explored in a day then all of the teams combined will explore 15000 m^2 in the course of a single mission. That's huge. Further, in this scenario, if individual units fail at some point then the entire mission won't be jeopardised and that number will roughly stay the same. I think that if the units are allowed to be autonomous (again because they are disposable) then you could rapidly increase the area explored and get more out of a single mission.

In this scenario the success of the mission has now bifurcated from the functioning of a single device and because of that you are free to pursue several orthogonal benefits such as these which ultimately reduce costs. I think that if you factor in a decrease of launch costs due to company's like SpaceX, then this ought to become even more attractive.

natep linked to a wonderful article ( http://www.dau.mil/pubscats/ATL%20Docs/Mar-Apr10/ward_mar-ap... ) on this which argues the point in a much better way.

>>> The solar concentration of a Martian winter is extremely low, and this problem is exasperated the smaller the probe and the resulting battery that it can carry. <<<

One of the main uses of the battery during winter months is to keep the processor warm. If the assembly is small enough then you should be able to use just insulation, a very small heater and perhaps a long lasting exothermic reaction which proceeds slowly over time. The amount of heat generated by such a reaction would be too small for something like curiosity, but perhaps it might work for a very small machine? Again since tolerances are low you shouldn't you be able to use a wider variety of batteries which store more per unit volume? I might be wrong on all counts, but a smaller design and lowered tolerances might actually work to our advantage.

>>> Just like in computing and electronics, physical and mechanical distributed systems are inherently complex - more so than monolithic systems. <<<

I'm actually not that into computing and electronics, I used to build physical systems and how they fail fascinates me. My designs failed so often upon meeting the real world that I realised the only way to know if something would ever work was to actually implement it IRL. If you can carry out a mission at one-tenth of the cost then you can do that much more willingly and learn from unforeseeable failure modes much more quickly. It should be an answer to this problem than the other way around.