>>> most of my response came from reading "I don't see any reason why someone shouldn't make this. [and I doubt a good one exists]" instead of "I don't see any

>>> most of my response came from reading "I don't see any reason why someone shouldn't make this. [and I doubt a good one exists]" instead of "I don't see any reason why someone shouldn't make this. [and I would like to hear some]"<<< Ah I see. I'll start qualifying my I-don't-see-any-reason-whys from now on with the latter statement. :) >>> I will admit that I do not know much about it, but what I do know is that there were some failures (as you would expect) and the public did not react well.<<< I guess that's the real reason why this won't be implemented by government agencies. Space missions are a matter of national pride and no one wants a "designed to fail/waste of money" accusation on their hands. However, empirically speaking it seems to be the best way to do things as we can increase the amount of explored area quite rapidly and respond to changes much more quickly. I think that when private companies such as Planetary Resources start doing exploration they will be forced to adopt this model because of their constraints and a lot of amazing solutions will come out of it. If that happens then it might open up a pandora's box and advances will happen much more quickly. Some people will see it as a bad thing, but as long as the systems are autonomous it should lead to a lot of good things. >>> 2) the public will not tolerate failure on large NASA projects, even if those projects cost a fraction of what it takes to host an Olympics, or to buy Instagram, or fight a war for a day.<<< More importantly the politician who approves it probably won't get re-elected. >>> [2] And yet, JPL still chose to use the skycrane. Very courageous.<<< I was quite shocked when I heard it worked. I was willing to bet on the side of failure because of the sheer complexity involved. A small timing error, sensor glitch or the other million things that could have gone wrong would have led to failure. It's quite impressive that they managed to do such a high stakes real-time task more or less autonomously. It really was quite a daring thing. >>>your idea<<< It's definitely not mine. I bet people were talking about it when I was in diapers. >>> What I meant by my line of questioning was that I haven't seen an implementation of these concepts outside academia, even though the idea has been around for some time, and the industry isn't entirely driven by irrational beings, so there must be some technical reasons why the ideas haven't been fully adopted.<<< Yes, I'm willing to bet that this has a lethal flaw which quickly led to such implementations to be rejected, but the question is can this be hacked, for the lack of a better word? Remember most organisations where rovers are designed are meant to be risk averse and they, aside from NASA, have an endless pool of resources to draw from. (I'm talking about the military) The sociological and resource incentives in place simply work against any such proposal independent of engineering viability. >>> His argument that most failures were systematic, and not due to unequal 'wear' of various kinds. <<< There's an interesting case to be made over here, one is redundancy at the unit level and another is redundancy at the systemic level. Let's take the swarm as a system, in that case if you have multiple backup copies of machines adept at performing particular tasks then you essentially have redundancy provided that the same method is not followed at the unit level. In that case if one failed for a particular set of inputs (hardware or software) then you can "patch" the rest by either avoiding the physical situation or changing the software. You can repeat that with individual units and let them have free reign. If one of them gets destroyed then the other ought to be able to be modified in time. Although it won't guard against stupidity at the unit level, this should to be a much more redundant system than anything we can create within a single one-use device. At the level of the single unit, systematic failures come into play and more copies is actually less over there. Things must be asymmetrically designed to overcome edge cases and systematic failure modes and robust engineering makes sense over there. I think that one of the best ways to implement such a system would be to spend most of the resources in creating and testing a mobile base which is independent of its payload. (attachable modules which perform specific tasks) You should then be able to deploy this machine across missions and learn from all of the real world testing in each mission to create something truly robust and reliable. Once you achieve that you can start offering redundancy at the swarm level through the payloads. For example in that high gain, low gain antenna scenario, wouldn't it be better to have a dozen robots equipped with a variety of antennas dedicated to communication? >>> It's when the designs and tests don't match reality is when the problems happen. <<< Yes, but isn't the entire point of the exercise to fail early and fail often so that you can succeed? If your system is disposable then any systemic failure becomes yet another data point to engineer against and all future systems are better because of it. There is no better laboratory than nature and surely this is a point in favour of it? (unless I'm missing something) Would you like to carry out this convo via email? If so then please feel free to drop me a line at searchingforabsolution [at] hush.com >>> [3] http://www.dau.mil/pubscats/ATL%20Docs/Mar-Apr10/ward_mar-ap.. http://www.dau.mil/pubscats/ATL%20Docs/Mar-Apr10/ward_mar-ap.... <<< Thanks for linking me to this article! It was great.