[meteorite-list] Phoenix Lander

[Sterling K. Webb]

Hi,

    I note that all your examples involve return and the possibility
of a rapid exit. We want a robot to last and to perform for as
long as possible; it can't dash home and we wouldn't want it to.
Operating a robot by telepresence over a long light-time delay
is chancy. Phoenix has already had "problems" with radio
transmission and various other minor glitches.

    I recommend reading the following piece about the way the
command structure of the Phoenix "robot" works:
http://phoenix.lpl.arizona.edu/blogsPost.php?bID=202
As you can see, it's not like pushing a big button on the Robot
Control Panel. Things are done by writing blocks of VML2
code to accomplish a specific task, testing them, sending them,
etc. As the SSI Co-Investigator says, "Frankly, any day with
a tomorrow is a good day on Mars."

    Remember, this is a remake mounted on an unused backup
spacecraft, a hybrid, a kludge, an Apple running Windows which
is emulating Unix (not literally, but you get the idea). You know
how much data the Phoenix can hold overnight (if it needs to)?
Yes, friends -- 14 Megabytes. How big is the flash card in your
digital camera?

    I think it's doing a wonderful job. Go slow. Test every foothold
before you put your weight on it. Look before you leap. Small steps,
small steps...


Sterling K. Webb
---------------------------------------------------------------------------------
----- Original Message ----- 
From: "Francis Graham" <francisgraham at rocketmail.com>
To: <meteorite-list at meteoritecentral.com>
Sent: Tuesday, June 03, 2008 9:35 PM
Subject: [meteorite-list] Phoenix Lander


Dear List
  Mark Ford has a point. In the Apollo Lunar Missions, right away as soon as 
they emerged from the LM, the astronauts obtained a basket of moon rocks and 
sent it up to the LM. The reasoning was, if something went amiss, and they 
had to leave the lunar surface soon after landing, they would not return 
empty-handed. This was called a "contingency sample".
  The argument also applies to unmanned missions. Phoenix might have had a 
provision for an immediate contingency analysis designed in to its program, 
but, at risk of peril, did not, and waited a week.
  Nonetheless it is a good idea to do contingency sampling. It might be also 
a good idea for a future  Mars sample return mission to obtain an immediate 
contingency sample. If things go wrong, and the scoop arm later malfunctions 
while picking around for interesting stuff, or some such, at least they can 
blast the hurried small contingency sample off Mars and back to Earth.
  One can apply this also to astronomy. One might collect what data one can, 
even low grade, right away, in case it clouds up. Then do careful instrument 
tweaking if clouds stay away.   In meteorite collecting, one can grab a few 
random samples around the crater ejecta and then, if the situation remains 
pleasant, seek out better samples elsewhere. Seems like a smart idea.
   There is a host of practical problems to which this idea can be applied, 
where time=increased chance of difficulties.


Francis Graham




______________________________________________
http://www.meteoritecentral.com
Meteorite-list mailing list
Meteorite-list at meteoritecentral.com
http://six.pairlist.net/mailman/listinfo/meteorite-list