At least one of the other robots participating in the test, ATHLETE, is also Linux-based (PPC CPUs, incidentally, not x86). How do I know? I'm writing part of the software we're using to drive it -- by adapting RSVP, the software we wrote to drive the MER rovers -- so I actually got to go out there and drive ATHLETE around for a few days as part of this test.
I love my job.
ATHLETE is one of the coolest damn things I've seen in a long time, designed and built by a team of absolutely brilliant engineers. Think of a two-meter-tall six-legged metal spider on roller skates. Or, heck, just check the link above.
The current ATHLETE is a prototype (of course); the ones we send to the moon -- if we're selected -- will be twice that size. Yes, Slashdotters, welcome our four-meter-tall six-legged roller-skate-wearing metal spider overlords!
For additional coverage of K-10, ATHLETE, Centaur/Robonaut, and other vehicles participating in this test, check out
the updates from JSC.
It's not that simple. The rovers are full of fairly sophisticated sensor packages, most of which can't handle the extremely low temperatures on the Martian surface. They need the batteries to basically, well, run the heater.
Bingo. Indeed, it's even worse than that: if you can't run the heaters, all of the electronics undergo more extreme thermal cycling. This causes components to contract, flex, break, etc. Several critical components -- e.g., the CPU -- have no redundancy; if one of those goes, the whole rover goes.
This failure is the most dangerous thing to happen to Spirit since the flash anomaly on sol 18, when we effectively lost contact entirely for several days. Frustratingly, we're within sight of a safe haven -- only about a football field away -- but we might not be able to get there. Some people on the team think that if we have to drag a wheel, we can't climb the slopes we need to climb to make it to safety. I would just hate for Spirit to go this way; it would be like dying of thirst within sight of water, and she deserves better. (On the other hand, one thing I've learned is this: never bet against the rovers.)
The principal investigator for the missions has written a book, "Roving Mars", that really is worth the read.
Agreed! And since Steve's such a great guy, I'll
linkify that.:-)
Also looks like it's coming out in paperback soon.
I'd use an even stronger word than "necessary" -- I'd say it's vital. Our software lets us associate short, convenient nicknames with targets picked out from imagery, and these nicknames facilitate precise communication within the team. It's better to give a thousand rocks silly nicknames such as "Abba" than to miss a single crucial observation because two people had different ideas about which rock "the flattish rock off to the left over there" was.
We also name particular spots on rocks (or soil) for the same kind of reason. "Patrick," the spot on Spongebob referenced in the article, was a target we explored with the IDD, and we always name those to help ensure that we're putting the IDD where the scientists want it. This is even more crucial when, for instance, we're investigating two or more targets on the same feature and the order is important. Being able to say something like "we want to look at Frodo, then Bilbo, then Gollum" helps us get it right.
A further reason names are important: morale. Coming up with cool and creative namespaces adds to the fun of the mission, both for us and, we hope, for you. (The first thing I got to name was a boundary line between two layers of soil, which we discovered after a trenching operation. I called it "Mason-Dixon.") And we often choose names that are related to what's going on at the time -- for example, Spirit has now climbed to the top of Husband Hill, and the locations there are being named after famous (and dead) mountain climbers.
However, it was drilled into us from the very start that any names we came up with would be nicknames only, and that only the IAU got to choose official names. When talking to the press, we're very careful to use terms such as "nickname" to try to make it clear we're not overstepping our bounds. Personally, I think we should never have violated the restriction on naming things after personal connections such as pets and spouses; that's really poor practice, but at least we've done it on only a couple of occasions. If I recall the story correctly, the guy who named the target after his wife was in the doghouse for having to work on Valentine's Day, so I can at least understand that if not excuse it.:-)
Incidentally, about Spongebob. Project management didn't want us using that name -- I think they were a little embarrassed or something, so they renamed it "Heatshield Rock" (since we found it next to Opportunity's heat shield). But the rover drivers had other ideas -- we kept calling it "Spongebob" (or sometimes "Spongerock") when we weren't talking to the press. I think we won.:-)
Those of you interested in this topic might also be interested in an earlier post, How Endurance Crater Got Its Name, which I think gives some insight into the (nick)naming process. A particularly relevant quote from that post:
... our jobs are easier when the features have names, but it's a hard problem: we don't want to be too exclusive (that is, too America-focused), too generic, too topical, or too serious. ("Too serious" is a problem because we don't want the International Astronomical Union to think we're trying to usurp their job of giving these objects their official names. Lighthearted names not only make the mission more fun, they also signal, accurately, that we're not trying to step on the IAU's toes.)
What I can't understand is, why didn't "management" come in and screw this all up?
:-) Well, as an engineer, I'm the natural enemy of management, so it pains me to admit this. But honestly, the management for this mission has been simply exceptional, and that's a largely uncredited reason for our success.
Remember the Spirit Anomaly, where we lost contact for a while, a couple of weeks after landing? For all we knew at the time, we'd lost the rover. Pete Theisinger and Richard Cook, who were then the project manager and deputy project manager, went down to the press conference alone, so that (a) the engineering team could work on the damn problem without being distracted by the press, and (b) only their faces were associated with the problem. When things were going well, they brought engineers and scientists to the press conference (and let them do most of the talking). When things went wrong, they took the heat.
The tradition continues with our current project manager, Jim Erickson. To take a recent example, Jim went down to the testbed to help shovel the dirt for the special "sandbox" we had to set up to figure out how to extract ourselves from this dune. (Jim's the guy squatting on the far left of this image. That wasn't one of the days he was digging.)
They couldn't have done it without us. But I have to say, we couldn't have done it without them, either.
I still have this question: if they do manage to get it free, how long until it just gets stuck again?
That's an excellent question, and the short answer is, we don't know. We crossed about 4km of this stuff uneventfully before we encountered the current dune (BTW, it's technically a ripple, not a dune), and we aren't completely sure what makes this one different from the rest.
I've been a little out of the loop, since I switched back to Spirit a few weeks before the Ripple Event, but I followed some of the email traffic as best I could. Last I saw, the working hypothesis was something to this effect: this ripple just happened to be a little taller and steeper than normal, and we just happened to be gaining a little elevation anyway (so we were at a greater tilt than normal) when we came across it.
I don't think there are yet any particular guidelines about avoiding them, but as you might expect, there's a team working on it.
The two basic possible explanations seem to be geometry (which I touched on above) and material. Someone threw out the idea that we can tell "dangerous" ripples from the regular kind by their albedo -- possibly, hazardous (fluffy) ripples are made of lighter dust and are therefore brighter. But I don't know whether that idea gained any traction. To my eyes, the ripple we're on didn't look particularly brighter than many others we've crossed without incident, but I didn't do any systematic analysis, so I can't really say.
My impression is that geometry is the leading candidate explanation, and if that proves to be the case, our guidelines will likely include evaluating every sol's traverse path for hazardous geometry. If we can't tell the rover how to avoid them itself, it might also mean no more autonav drives (where we let the rover find its own way), which would significantly slow our progress. But then, so would getting into another of these ripples.
This is all still a work in progress, though. Just remember, this is why we call it "exploration"!
If you want a quick and easy way to find potentially exploitable bugs, try fuzz testing. This is as simple as it could be: feed random data (e.g., from/dev/random) into applications until you crash one. That usually means there's a buffer overflow, which you can then exploit. Re-run the test under a debugger to pinpoint the exact cause of the crash, then craft an attack.
The better approach is to create one or more large files of random data and feed that into the apps; this is better because it gives you a reproducible stream. (Or you can use a Perl script with a known srand() seed.)
The term "fuzz testing" comes from
a seminal 1990 paper (and followups in 1995 and 2000) by Barton Miller et al., who, incidentally, found much higher quality in GNU tools than in their proprietary counterparts. Before my tendinitis got too bad, I used to run
The Bulletproof Penguin
a one-man project devoted to stamping out such bugs (my initial goal, easily achieved, was to eliminate all the bugs reported in the original paper). Ben Woodard was doing something very similar for a while, but I don't know whether he still does.
Incidentally, this makes
a certain recent Slashdot story more embarrassing: it seems that free Web browsers crash on malformed input, the kind of case that free software normally handles better than its proprietary competition.
My only comment on Beagle 2 when the press asked me about it (as a member of the MER mission, we got that question a lot) was that I was sorry it hadn't worked out, but that the only real failure would be if the Beagle 2 team, and the British people generally, gave up and didn't do a Beagle 3. It was an inventive spacecraft design with an exciting mission, and the team behind it clearly was capable of great things.
So I'm as happy as anyone (except maybe Dr. Pillinger:-) to see that they're going for it. From a JPL-based Martian to my friends on the Beagle 3 team (and at ESA), best of luck with Beagle 3!
Odyssey has been a great success in its own right, as well as providing critical support for MER. One of those "other feats" mentioned in the writeup included being the relay satellite for something like 90% of the Mars Exploration Rover downlink.
It costs us a lot less energy to just uplink the data from MER to ODY and let them send it back to Earth than for us to send it all the way back to Earth
directly. The energy we save that way, we can spend on driving around, doing science, and staying warm. ODY did such a great job relaying data for us that it soon became our preferred communication mode -- we haven't returned any significant amount of data through another path for months. (Though we did recently test that we can also return data via ESA's Mars Express.)
To put it another way, without ODY, we'd have only about 10% of the pretty pictures you can find at the MER home page.
So on behalf of all of us MERfolk: thanks, and congratulations, Odyssey!
The parent post is absolutely correct, start to finish. Nobody here, and I mean nobody, thought we'd do so well. Not that we're unhappy to be wrong.:-)
I've been thinking about one of the reasons we so often end up doing better than we expected. Our engineering estimates use necessarily conservative assumptions about a largely unknown environment. That's the only responsible way to do it: our job is to ensure that, even in the worst combination of circumstances, the rovers will still meet their minimum success criteria. So we design them to survive that worst case.
However, in practice, assuming you survive launch and landing, you usually don't experience the worst combination of circumstances, so the spacecraft do better than the minimum.
Anyone who thinks we're underpromising is missing a chance to make hundreds of millions of dollars: bid on space missions (some of them are open to anyone) and promise more than we do. All you have to do is deliver.
They asked him what type of car it was, he said it was a kit car. "How much did the kit cost?" they asked. "Oh, about 450 million dollars." replied the caller.
Yes, an engineer from JPL was calling to get some tongue-in-cheek advice on what to do to keep the rovers safe over the martian winter.
That was John Wright, one of the rover drivers (scroll to bottom). I had suggested another joke for them to use:
From that one story you have hosts of other authors refering to "butterfly effects" and "quantum butterflys".
The term "butterfly effect" derives from the work of
Edward Lorenz, a meteorologist who was an early researcher into chaos theory. (In a way, Lorenz was the first chaos theorist -- James Gleick's excellent book
Chaos: Making a New Science tells the story in detail.)
Lorenz has said his choice of metaphor was not influenced by Bradbury's story (he hadn't read it). Indeed, he first phrased the idea using a seagull, not a butterfly.
So the term oughta refer to Bradbury's story, but it doesn't.:-)
I don't know if this is common knowledge, but I thought y'all might be interested to know how Endurance Crater got its name. I don't think I'll be telling tales out of school if I relate this story. This is an excerpt from a mission diary I've been writing as a way of keeping my wife in the loop, which was especially important when we were all on Mars time and I wasn't seeing her for weeks on end. From way back on sol 3 [insert wavy lines here]....
The most interesting part of the meeting was a fifteen- or
twenty-minute discussion about naming geological features. One of the
first proposals was related to naming the craters we saw in the
descent images. The starting suggestion was to name them after coins,
partly because people are familiar with coins and partly as a
thank-you to the descent imager, which is named DIMES. More
specifically, they'd be named for the people on the coins --
Washington, Lincoln, Roosevelt, and so on. To avoid being too
America-centric, we'd also use coins from other countries --
especially Germany, Denmark, Brazil, and France, our international
partners on this mission.
The same discussion included how to name the landmarks we can see from
the landing site, such as the hills to the east and the peak to the
south. The initial suggestion was to name the distant hills
"Endurance Hills," for the name of Shackleton's ship (and to reflect
what it will take us to get there, if we decide to drive to them), and
then name other features after the members of Shackleton's crew.
There's some concern about tying ourselves so closely to a mission
that, as romantic as it was, was technically a failure ("did not
fundamentally meet its Level-1 requirements," as Squyres jokingly put
it).
A more general version of that proposal emerged later: name the
landmarks after explorers generally (or, in another variant, after
their ships -- this would also allow us to tip our cap to Beagle
2). One advantage of this is that there have been many explorers from
all lands, so we could easily give the names an international flavor.
(And we could include Darwin in the honorees, which is a big plus as
far as I'm concerned.) A problem with this is that the same explorer
is usually perceived differently by different cultures -- Columbus
might be the most obvious example (though nobody brought him up
explicitly), but for nearly any famous explorer you can think of,
there's someone who thinks of him less as an explorer and more as a
marauder. The idea was gaining momentum despite this drawback, until
our NASA HQ rep said something like "I can just see the name 'Pillager
Hills,'" which provoked a lot of laughter and seemed to deflate the
proposal.
Other suggestions for geological features: deliberately generic names
such as "East Hills" and "South Knob" (derided as "too boring"), names
drawn from the coined words in Lewis Carroll's poem "Jabberwocky," and
names of general qualities such as "Forbearance" and "Courage." The
last proposal fits reasonably nicely with the rover names ("Spirit"
and "Opportunity") and lets us preserve "Endurance" as the name for
the hills to the east. But I think it might have lost some of its
support when someone jokingly suggested "Chastity" as one of the names
("Well, it is going to be a long mission," Squyres laughed).
Yet another proposal that came up late: craters are ring-like, and The
Lord of the Rings is popular right now, so why not use Tolkien-based
names? A downside is that this might be too topical, but the idea has
some support despite that.
Right now, I don't think any proposal is winning. We have to settle
on something before too much longer, because our jobs are easier when
the features have names, but it's a hard problem: we don't want to be
too exclusive (that is, too America-focused), too generic, too
topical, or too serious. ("Too serious" is a problem because we don't
want the International Astronomical Union to think we're trying to
usurp their job of giving these o
I am really looking forward to when Spirit reaches the Columbia Hills. If Spirit successfully reaches the top of the hill the view will be breathtaking. Not only could we see the landing site but also see the actual rim of Gusev Crater more clearly. It will be an amazing sight!
I'd like to see that, too. But unfortunately, the current thinking is that we won't be climbing the hills when we get there.
In fact, I just had that conversation with Larry Soderbloom, one of the top scientists on the mission. My side was, basically: "But, Larry, the view would be so cool.":-) He readily agreed, but unfortunately, there's just nothing scientifically compelling up there. (As best we can tell from orbital imagery, that is.)
However, MOC images (MOC is the camera system on the MGS spacecraft) show that there's a lot of cool stuff in the hills' vicinity, making them a worthwhile destination anyway. There are rock outcroppings on the hills themselves, which we'll be able to see fairly well even without climbing to them, and several geological features of great interest in the 500m or so around the hills. (Now that we've upgraded the rovers' flight software, we're regularly covering 70m+ per sol -- indeed, we just set a new Spirit single-sol record of 92m -- so 500m is roughly a week of driving.) As a result, that area is likely to give us our best chance of telling the "water story" we came to Gusev to find.
Incidentally, we're shooting for reaching the hills in about 40 more days (we're targeting sol 160; we just planned sol 119). Stay tuned.
FWIW, as spectacular as the view would be in other respects, I don't think the Gusev Crater rim would look any better from the top of the hills. It's faint because of the high tau (atmospheric opacity) caused by the global dust storm that preceded our landing, and which is still settling. Maybe the view would be better from a little higher, but I doubt it. The good news is that the rim is showing up better and better as the atmosphere clears, so we'll get better views of it over time even without climbing the hills. (If you've never noticed the rim in the images, you can see it in
this image
if you look carefully -- look to the right of the hills, at the right-hand edge of the image. It's faint, but that's the rim of Gusev Crater.)
The Planetary Society
supplied a microphone
that we flew on MPL (Mars Polar Lander), but the mission failed. As described on the linked page, they're trying again in 2007.
BTW, in the spirit of great-minds-think-alike, the idea of sending a microphone to Mars was first suggested by the late, lamented Carl Sagan.
Re:Spirit not that impressive...?
on
News from Mars
·
· Score: 1
Seriously, how democratic is the planning process? In what forum are disputes resolved? I'm sure the debate over which rocks to explore can get quite heated.
To simplify a bit (sorry, but it's a complex process), the planning happens in two big meetings.
First, there's a daily downlink assessment meeting, in which the various groups report the state of their instruments and talk about what happened yesterday. They also throw around ideas about what to do tomorrow. Mostly it's at a high level. This meeting is fun and interesting, and I attend it whenever I can. There's almost always a beautiful PANCAM or MI image being displayed on one of the big screens as well, which helps.:-) People go away from this meeting with a candidate set of activities for the next sol, with assignments to explore the possibilities, generate preliminary versions of their sequences to see what's possible, and so on.
Later, there's the Science Operations Working Group (SOWG) meeting, which is like having your teeth pulled. That's where they do the nitty-gritty work of fitting everything into the available resource constraints -- time, energy, downlink data volume. (SAP (Maestro) is the main tool for this.) This meeting finalizes the plan for the sol, though it's common to deliberately overcommit resources in case we discover late in the process that we have more time than we thought, or that some things can't be done after all, etc. If we've overcommitted (intentionally or otherwise), we throw out stuff during sequencing until it works.
In both meetings, there's a lot of horse trading, and there's a dictator for each, whose job is to say, "You get this today, you get that tomorrow" -- if it comes to that. But that's usually necessary only to keep things moving, not to resolve disputes. The scientists are generally very polite and respectful of each other, and the meetings are mostly consensus-driven.
I'd have to say I haven't seen too much heat yet. (Then again, I'm not on the scientists' email lists, so there may be more going on than meets the eye.) It is certainly a fascinating process to watch.
Re:Spirit not that impressive...?
on
News from Mars
·
· Score: 1
We also have a 3D visualization environment which isn't too bad (especially considering it's Java3D!) Our simulation is much rougher (but very fast) and is used to give scientists a good idea of what their plans will do, and leave the details to the sequencing team.
[...] It's really amazing all the effort that goes into one day on mars, from examing the data to sending the final sequence. Too bad there's no public version of RSVP, otherwise everyone could see how awesome it is:)
Well, as long as we're blowing smoke up each other's bodily orifices:-), I should say that SAP is really nice as well. I rely on it to get my daily pix fix (yes, I know it's more than an image browser; I don't mean to denigrate it; that's just what I use it for;-). I keep meaning to play with the 3-D stuff, but haven't gotten to it yet. Maybe tomorrow.
Re:Spirit not that impressive...?
on
News from Mars
·
· Score: 4, Informative
Why only 3 months? Do the solar panels become too damaged to generate electricity or is the battery toasted or what? Just curious.
There are several problems, some of which interrelate. You touched on a couple of them. Things that I can think of offhand:
Dust builds up on the solar panels, and they stop generating (enough) power. The developers experimented with various mechanisms to avoid dust buildup and/or to remove the dust, but never got anything satisfactory. Perhaps a future mission will have some fix for this; Spirit and Opportunity will tell us more about the properties of Mars's dust, which may help.
The batteries can be cycled only so many times before they stop working.
Mars gets farther and farther from the sun (which also starts to move north in the sky), further reducing the amount of solar power available.
As the available energy declines, the rover has a harder and harder time storing up enough energy to keep itself warm at night. Eventually, the internal components are subjected to sufficient cold that they fail. (Interesting fact: the rover parts that most need to be kept warm live in its main body, that shiny gold box. It's called the WEB, or Warm Electronics Box, for that reason.)
There are limits on the lifetime of the rover's motors.
This is unlikely to be a limiting factor, but radiation may destroy vital electronic and computer components.
There are probably many other conditions; I'm not a hardware guy. I just drive 'em.:-) Per my original point, most of the problems can be mitigated by using RTGs, though some would have to be attacked in other ways.
Spirit and Opportunity will not reach sol 90 and immediately shut down, of course. Instead, they will slowly degrade, like a human body entering old age. It will be a matter of morbid curiosity to see what goes first. It makes me sad to think about it.
Re:Spirit not that impressive...?
on
News from Mars
·
· Score: 3, Informative
RoSE is part of a suite called RSVP, the rest of which does 3-D visualization, simulation, and playback. Our 3-D stuff is very, very cool (I feel OK about saying this because I didn't write that part:-): we do kinematic simulations as the rover drives across the terrain; you can see it articulate realistically. If you've watched the press conferences, you've probably seen one of our playbacks. That visualization stuff is all in C and C++, though, not Java.
I should clarify that RSVP as a whole is used to write the rover command sequences now that we're in surface ops, not just RoSE. RSVP provides a visual editing environment for command sequences, so that you can (for instance)
mark a spot
in the virtual 3-D world and tell the rover to go there. This adds a command to the sequence just as if it had been added in RoSE.
Re:Spirit not that impressive...?
on
News from Mars
·
· Score: 5, Informative
Is it true that spirit makes use of Java? Or does only the "client" software used to control it,use Java. Does it have an OS and if so which/or what type? Does it use a RTOS or Linux or a BSD?
We do use Java to write the rover command sequences. I wrote the software, RoSE (the Rover Sequence Editor), that we use for that; RoSE was also used to command both spacecraft in cruise.
RoSE is part of a suite called RSVP, the rest of which does 3-D visualization, simulation, and playback. Our 3-D stuff is very, very cool (I feel OK about saying this because I didn't write that part:-): we do kinematic simulations as the rover drives across the terrain; you can see it articulate realistically. If you've watched the press conferences, you've probably seen one of our playbacks. That visualization stuff is all in C and C++, though, not Java.
Java is also used upstream of RSVP, to do image browsing and to plan science goals for the sol. That's Maestro's role.
The rovers themselves run
VxWorks,
a well-known real-time Unix variant that's used a lot here at JPL.
Re:Spirit not that impressive...?
on
News from Mars
·
· Score: 3, Insightful
Also remember that sunlight is much dimmer out on Mars than it is on the moon, adn the gravity is higher, thus speeds tend to be slower.
And why is sunlight a limiting factor? Because, for political reasons, we couldn't put an RTG (radioactive power source) on the rovers. That leaves us with solar only, which is what leads to the limited speed and the limited vehicle lifetime. If we could fly an RTG on Spirit, we could make it last for years. Maybe we'll be able to do that with a future mission.
As it is, I think we've done pretty well: we're going to drive a 384kg rover a kilometer (or more) and operate it for three months on just about the amount of energy it takes to power two light bulbs (~140W peak). And we're going to do it again with Opportunity, starting in just a few days.
Anyone know for certain or can identify any terrain disturbed by the landing?
There are a couple of likely bounce marks in Sleepy Hollow. Look approximately in the current egress direction, straight up from the rover's right "wing" in the panorama. The dark circular features are where the airbags disturbed the soil (or this is the current belief, at any rate).
There's another one just above the tip of the right "wing."
You can see a few more in the panorama, but the locations are harder to describe.
But why does it take so long for things to retract, the rover to move, etc etc.
If you had a four-hundred-million-dollar car, you'd drive carefully, too. Especially if the nearest mechanic were a hundred million miles away.
I guarantee you we're every bit as eager to get driving as you are. Have patience, friend. We're doing science already, and we're only about one more day away from egress.
Offtopic - NASA is really embracing Java lately. At least parts of the control and visualising software for the current mission uses Java, including Java 3D. Java not ready for user interfaces eh?
Indeed. The software we used to command both rovers during cruise is written in Java (I wrote it!); we're using the same software to command them on the surface as well. (The surface commanding is actually done with an integrated mix of software -- my half is in Java; the other half, the 3-D visualization stuff, is in C++. We also have various kinds of links to other JPL applications, most of which are written in C or C++.)
And no, this isn't Maestro (a.k.a. SAP) I'm speaking of. But Java is an important part of this mission, as is Linux.
Oh, and just so I can be on-topic: everyone who wants a Mars-time watch pays for it out of his own pocket. I'm cheap, so I'm using the nifty
MarsClock application on my Palm, as well as a GNOME panel applet I wrote myself that displays UTC and Mars time. We also have big electronic whiteboards that display UTC, PST, and Mars times (and the app that does this is written in Java). But I might get a Mars watch anyway, as a souvenir if nothing else.
Slashdot Mirror
I love my job.
ATHLETE is one of the coolest damn things I've seen in a long time, designed and built by a team of absolutely brilliant engineers. Think of a two-meter-tall six-legged metal spider on roller skates. Or, heck, just check the link above.
The current ATHLETE is a prototype (of course); the ones we send to the moon -- if we're selected -- will be twice that size. Yes, Slashdotters, welcome our four-meter-tall six-legged roller-skate-wearing metal spider overlords!
For additional coverage of K-10, ATHLETE, Centaur/Robonaut, and other vehicles participating in this test, check out the updates from JSC.
Bingo. Indeed, it's even worse than that: if you can't run the heaters, all of the electronics undergo more extreme thermal cycling. This causes components to contract, flex, break, etc. Several critical components -- e.g., the CPU -- have no redundancy; if one of those goes, the whole rover goes.
This failure is the most dangerous thing to happen to Spirit since the flash anomaly on sol 18, when we effectively lost contact entirely for several days. Frustratingly, we're within sight of a safe haven -- only about a football field away -- but we might not be able to get there. Some people on the team think that if we have to drag a wheel, we can't climb the slopes we need to climb to make it to safety. I would just hate for Spirit to go this way; it would be like dying of thirst within sight of water, and she deserves better. (On the other hand, one thing I've learned is this: never bet against the rovers.)
Agreed! And since Steve's such a great guy, I'll linkify that. :-)
Also looks like it's coming out in paperback soon.
We also name particular spots on rocks (or soil) for the same kind of reason. "Patrick," the spot on Spongebob referenced in the article, was a target we explored with the IDD, and we always name those to help ensure that we're putting the IDD where the scientists want it. This is even more crucial when, for instance, we're investigating two or more targets on the same feature and the order is important. Being able to say something like "we want to look at Frodo, then Bilbo, then Gollum" helps us get it right.
A further reason names are important: morale. Coming up with cool and creative namespaces adds to the fun of the mission, both for us and, we hope, for you. (The first thing I got to name was a boundary line between two layers of soil, which we discovered after a trenching operation. I called it "Mason-Dixon.") And we often choose names that are related to what's going on at the time -- for example, Spirit has now climbed to the top of Husband Hill, and the locations there are being named after famous (and dead) mountain climbers.
However, it was drilled into us from the very start that any names we came up with would be nicknames only, and that only the IAU got to choose official names. When talking to the press, we're very careful to use terms such as "nickname" to try to make it clear we're not overstepping our bounds. Personally, I think we should never have violated the restriction on naming things after personal connections such as pets and spouses; that's really poor practice, but at least we've done it on only a couple of occasions. If I recall the story correctly, the guy who named the target after his wife was in the doghouse for having to work on Valentine's Day, so I can at least understand that if not excuse it. :-)
Incidentally, about Spongebob. Project management didn't want us using that name -- I think they were a little embarrassed or something, so they renamed it "Heatshield Rock" (since we found it next to Opportunity's heat shield). But the rover drivers had other ideas -- we kept calling it "Spongebob" (or sometimes "Spongerock") when we weren't talking to the press. I think we won. :-)
Those of you interested in this topic might also be interested in an earlier post, How Endurance Crater Got Its Name, which I think gives some insight into the (nick)naming process. A particularly relevant quote from that post:
:-) Well, as an engineer, I'm the natural enemy of management, so it pains me to admit this. But honestly, the management for this mission has been simply exceptional, and that's a largely uncredited reason for our success.
Remember the Spirit Anomaly, where we lost contact for a while, a couple of weeks after landing? For all we knew at the time, we'd lost the rover. Pete Theisinger and Richard Cook, who were then the project manager and deputy project manager, went down to the press conference alone, so that (a) the engineering team could work on the damn problem without being distracted by the press, and (b) only their faces were associated with the problem. When things were going well, they brought engineers and scientists to the press conference (and let them do most of the talking). When things went wrong, they took the heat.
The tradition continues with our current project manager, Jim Erickson. To take a recent example, Jim went down to the testbed to help shovel the dirt for the special "sandbox" we had to set up to figure out how to extract ourselves from this dune. (Jim's the guy squatting on the far left of this image. That wasn't one of the days he was digging.)
They couldn't have done it without us. But I have to say, we couldn't have done it without them, either.
That's an excellent question, and the short answer is, we don't know. We crossed about 4km of this stuff uneventfully before we encountered the current dune (BTW, it's technically a ripple, not a dune), and we aren't completely sure what makes this one different from the rest.
I've been a little out of the loop, since I switched back to Spirit a few weeks before the Ripple Event, but I followed some of the email traffic as best I could. Last I saw, the working hypothesis was something to this effect: this ripple just happened to be a little taller and steeper than normal, and we just happened to be gaining a little elevation anyway (so we were at a greater tilt than normal) when we came across it.
I don't think there are yet any particular guidelines about avoiding them, but as you might expect, there's a team working on it.
The two basic possible explanations seem to be geometry (which I touched on above) and material. Someone threw out the idea that we can tell "dangerous" ripples from the regular kind by their albedo -- possibly, hazardous (fluffy) ripples are made of lighter dust and are therefore brighter. But I don't know whether that idea gained any traction. To my eyes, the ripple we're on didn't look particularly brighter than many others we've crossed without incident, but I didn't do any systematic analysis, so I can't really say.
My impression is that geometry is the leading candidate explanation, and if that proves to be the case, our guidelines will likely include evaluating every sol's traverse path for hazardous geometry. If we can't tell the rover how to avoid them itself, it might also mean no more autonav drives (where we let the rover find its own way), which would significantly slow our progress. But then, so would getting into another of these ripples.
This is all still a work in progress, though. Just remember, this is why we call it "exploration"!
While wind is the most plausible explanation, it is not the most amusing.
The better approach is to create one or more large files of random data and feed that into the apps; this is better because it gives you a reproducible stream. (Or you can use a Perl script with a known srand() seed.)
The term "fuzz testing" comes from a seminal 1990 paper (and followups in 1995 and 2000) by Barton Miller et al., who, incidentally, found much higher quality in GNU tools than in their proprietary counterparts. Before my tendinitis got too bad, I used to run The Bulletproof Penguin a one-man project devoted to stamping out such bugs (my initial goal, easily achieved, was to eliminate all the bugs reported in the original paper). Ben Woodard was doing something very similar for a while, but I don't know whether he still does.
Incidentally, this makes a certain recent Slashdot story more embarrassing: it seems that free Web browsers crash on malformed input, the kind of case that free software normally handles better than its proprietary competition.
The best part about this "invention" is that it apparently took three Microsoft employees to come up with it.
So I'm as happy as anyone (except maybe Dr. Pillinger :-) to see that they're going for it. From a JPL-based Martian to my friends on the Beagle 3 team (and at ESA), best of luck with Beagle 3!
It costs us a lot less energy to just uplink the data from MER to ODY and let them send it back to Earth than for us to send it all the way back to Earth directly. The energy we save that way, we can spend on driving around, doing science, and staying warm. ODY did such a great job relaying data for us that it soon became our preferred communication mode -- we haven't returned any significant amount of data through another path for months. (Though we did recently test that we can also return data via ESA's Mars Express.)
To put it another way, without ODY, we'd have only about 10% of the pretty pictures you can find at the MER home page.
So on behalf of all of us MERfolk: thanks, and congratulations, Odyssey!
I've been thinking about one of the reasons we so often end up doing better than we expected. Our engineering estimates use necessarily conservative assumptions about a largely unknown environment. That's the only responsible way to do it: our job is to ensure that, even in the worst combination of circumstances, the rovers will still meet their minimum success criteria. So we design them to survive that worst case.
However, in practice, assuming you survive launch and landing, you usually don't experience the worst combination of circumstances, so the spacecraft do better than the minimum.
Anyone who thinks we're underpromising is missing a chance to make hundreds of millions of dollars: bid on space missions (some of them are open to anyone) and promise more than we do. All you have to do is deliver.
That was John Wright, one of the rover drivers (scroll to bottom). I had suggested another joke for them to use:
CAR TALK: How old is your car?
JOHN: Less than a year old.
CAR TALK: And how many miles on it?
JOHN: About three hundred million.
Unfortunately, they didn't use it.
The term "butterfly effect" derives from the work of Edward Lorenz, a meteorologist who was an early researcher into chaos theory. (In a way, Lorenz was the first chaos theorist -- James Gleick's excellent book Chaos: Making a New Science tells the story in detail.)
Lorenz has said his choice of metaphor was not influenced by Bradbury's story (he hadn't read it). Indeed, he first phrased the idea using a seagull, not a butterfly.
So the term oughta refer to Bradbury's story, but it doesn't. :-)
I'd like to see that, too. But unfortunately, the current thinking is that we won't be climbing the hills when we get there.
In fact, I just had that conversation with Larry Soderbloom, one of the top scientists on the mission. My side was, basically: "But, Larry, the view would be so cool." :-) He readily agreed, but unfortunately, there's just nothing scientifically compelling up there. (As best we can tell from orbital imagery, that is.)
However, MOC images (MOC is the camera system on the MGS spacecraft) show that there's a lot of cool stuff in the hills' vicinity, making them a worthwhile destination anyway. There are rock outcroppings on the hills themselves, which we'll be able to see fairly well even without climbing to them, and several geological features of great interest in the 500m or so around the hills. (Now that we've upgraded the rovers' flight software, we're regularly covering 70m+ per sol -- indeed, we just set a new Spirit single-sol record of 92m -- so 500m is roughly a week of driving.) As a result, that area is likely to give us our best chance of telling the "water story" we came to Gusev to find.
Incidentally, we're shooting for reaching the hills in about 40 more days (we're targeting sol 160; we just planned sol 119). Stay tuned.
FWIW, as spectacular as the view would be in other respects, I don't think the Gusev Crater rim would look any better from the top of the hills. It's faint because of the high tau (atmospheric opacity) caused by the global dust storm that preceded our landing, and which is still settling. Maybe the view would be better from a little higher, but I doubt it. The good news is that the rim is showing up better and better as the atmosphere clears, so we'll get better views of it over time even without climbing the hills. (If you've never noticed the rim in the images, you can see it in this image if you look carefully -- look to the right of the hills, at the right-hand edge of the image. It's faint, but that's the rim of Gusev Crater.)
BTW, in the spirit of great-minds-think-alike, the idea of sending a microphone to Mars was first suggested by the late, lamented Carl Sagan.
To simplify a bit (sorry, but it's a complex process), the planning happens in two big meetings.
First, there's a daily downlink assessment meeting, in which the various groups report the state of their instruments and talk about what happened yesterday. They also throw around ideas about what to do tomorrow. Mostly it's at a high level. This meeting is fun and interesting, and I attend it whenever I can. There's almost always a beautiful PANCAM or MI image being displayed on one of the big screens as well, which helps. :-) People go away from this meeting with a candidate set of activities for the next sol, with assignments to explore the possibilities, generate preliminary versions of their sequences to see what's possible, and so on.
Later, there's the Science Operations Working Group (SOWG) meeting, which is like having your teeth pulled. That's where they do the nitty-gritty work of fitting everything into the available resource constraints -- time, energy, downlink data volume. (SAP (Maestro) is the main tool for this.) This meeting finalizes the plan for the sol, though it's common to deliberately overcommit resources in case we discover late in the process that we have more time than we thought, or that some things can't be done after all, etc. If we've overcommitted (intentionally or otherwise), we throw out stuff during sequencing until it works.
In both meetings, there's a lot of horse trading, and there's a dictator for each, whose job is to say, "You get this today, you get that tomorrow" -- if it comes to that. But that's usually necessary only to keep things moving, not to resolve disputes. The scientists are generally very polite and respectful of each other, and the meetings are mostly consensus-driven.
I'd have to say I haven't seen too much heat yet. (Then again, I'm not on the scientists' email lists, so there may be more going on than meets the eye.) It is certainly a fascinating process to watch.
There are several problems, some of which interrelate. You touched on a couple of them. Things that I can think of offhand:
There are probably many other conditions; I'm not a hardware guy. I just drive 'em. :-) Per my original point, most of the problems can be mitigated by using RTGs, though some would have to be attacked in other ways.
Spirit and Opportunity will not reach sol 90 and immediately shut down, of course. Instead, they will slowly degrade, like a human body entering old age. It will be a matter of morbid curiosity to see what goes first. It makes me sad to think about it.
I should clarify that RSVP as a whole is used to write the rover command sequences now that we're in surface ops, not just RoSE. RSVP provides a visual editing environment for command sequences, so that you can (for instance) mark a spot in the virtual 3-D world and tell the rover to go there. This adds a command to the sequence just as if it had been added in RoSE.
We do use Java to write the rover command sequences. I wrote the software, RoSE (the Rover Sequence Editor), that we use for that; RoSE was also used to command both spacecraft in cruise.
RoSE is part of a suite called RSVP, the rest of which does 3-D visualization, simulation, and playback. Our 3-D stuff is very, very cool (I feel OK about saying this because I didn't write that part :-): we do kinematic simulations as the rover drives across the terrain; you can see it articulate realistically. If you've watched the press conferences, you've probably seen one of our playbacks. That visualization stuff is all in C and C++, though, not Java.
Java is also used upstream of RSVP, to do image browsing and to plan science goals for the sol. That's Maestro's role.
The rovers themselves run VxWorks, a well-known real-time Unix variant that's used a lot here at JPL.
And why is sunlight a limiting factor? Because, for political reasons, we couldn't put an RTG (radioactive power source) on the rovers. That leaves us with solar only, which is what leads to the limited speed and the limited vehicle lifetime. If we could fly an RTG on Spirit, we could make it last for years. Maybe we'll be able to do that with a future mission.
As it is, I think we've done pretty well: we're going to drive a 384kg rover a kilometer (or more) and operate it for three months on just about the amount of energy it takes to power two light bulbs (~140W peak). And we're going to do it again with Opportunity, starting in just a few days.
There's another one just above the tip of the right "wing."
You can see a few more in the panorama, but the locations are harder to describe.
If you had a four-hundred-million-dollar car, you'd drive carefully, too. Especially if the nearest mechanic were a hundred million miles away.
I guarantee you we're every bit as eager to get driving as you are. Have patience, friend. We're doing science already, and we're only about one more day away from egress.
Indeed. The software we used to command both rovers during cruise is written in Java (I wrote it!); we're using the same software to command them on the surface as well. (The surface commanding is actually done with an integrated mix of software -- my half is in Java; the other half, the 3-D visualization stuff, is in C++. We also have various kinds of links to other JPL applications, most of which are written in C or C++.)
And no, this isn't Maestro (a.k.a. SAP) I'm speaking of. But Java is an important part of this mission, as is Linux.
Oh, and just so I can be on-topic: everyone who wants a Mars-time watch pays for it out of his own pocket. I'm cheap, so I'm using the nifty MarsClock application on my Palm, as well as a GNOME panel applet I wrote myself that displays UTC and Mars time. We also have big electronic whiteboards that display UTC, PST, and Mars times (and the app that does this is written in Java). But I might get a Mars watch anyway, as a souvenir if nothing else.