Slashdot Mirror
What's Inside the Mars Rovers
Captain Zion writes "Space.com has a story about the hardware and software of Mars Rovers Spirit and Opportunity. Basically, they're radiation-shielded, 20MHz PowerPC machines wirh 128Mb RAM and 256Mb of flash memory, running VxWorks. I wonder if I could make a nice firewall with one of these for my home network..."
Does anyone know what the deal was with the flash memory that caused the outage? I heard something about a "solar event" that caused a problem with the flash memory that led to the outage. It was subsequently resolved by disabling the flash. If so, BAE Aerospace has a possible solution with their upcoming line of rad-hard memory.
Life is the leading cause of death in America.
How is it done? Some external armor, or even insides of the chip are different?
---
SHE does throw dice.
If obsessed environmentalists don't like NASA sending up probes with any radioactive material ('it might blow up, ohh..'), then how did this little tidbit get by them? Do they consider it non-radioactive? If they're only concerned by radioactive propulsion systems, then I think they're a bunch of hypocrites. Radioactivitiy is radioactivity whether it's propulsion or heating.
If they don't mind it, then let's send up those dune buggies with RTG and 18-inch wheels and cover a lot more of Mars.
-Cyc
/.'s 10 Millionth
"It's quite unusual to have a single computer for the whole mission," Scuderi said, adding that many missions tend to have redundant systems as a guard against failure.
Now, while having two rovers is a form of redundancy, wouldn't it be wise to have some redundancy on each individual rover? I understand that there are concerns like weight and budget, but wouldn't some redundancy be a good form or risk management?
www.mikesmind.com - www.daddyworkathome.com - www.freetofarm.org - www.tenfoottable.com
There is very little on the Rovers that is "commodity" in any sense. The CCD image sensors, the computers, everything, is all custom made. Everything has to be made to withstand the rigors of flight and the harsh environments of space and Mars. The CPU does not have a backup, which is a bit unusual for NASA (I'm a contractor at NASA/Goddard, but not involved in any flight missions). However, the particular computer used on the rovers (the RAD6000) has a very good record. There are something like 150 in use on various spacecraft and they've all worked very well.
And the flash memory has probably not failed. It seems to have been a software problem, not hardware.
Rootbear
An interview with one of the Beagle-2 software developers can be found here: http://linuxdevices.com/articles/AT7460495111.html
The profits from Slashdot alone could extend the life of HST or launch the James Web Space Telescope early.
I thought about the current rovers, but I think they are a bit large to be successful!
Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity.
Completely off-topic, but you reminded me of something: given that most modern CPUs have a meg or so of cache built into the chip, would it be possible to build a machine with no plug-in memory modules and have it boot something simple like DOS? Or would the motherboard complain that you were being silly?
"'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
- JRR Tolkien.
The space shuttles run on five AP-101 computers, originally designed in 1969. The started with 32 kilowords of magnetic core memory for radiation protection, since upgraded to semiconductor memory. These computers were chosen due to their success in the Apollo, Skylab, and B52. For science and personal work the astronaut specialists usually bring personal laptops which are thousnds of times more performant.
Hang MPU and the OS. What's this thing using to communicate back to the earth-men? Are they still using a Motorola 400MHz walkie-talkie as Sojurner did to its base station? Or are they up in the GHz range now to get better gain from tiny dishes? More importantly, what frequency is it squawking so I can run out and build a Pringles can phased-array to hear it. The world wants to know these things!
NASA has been evaluating it...
On a related note, they use NVIDIA/Linux setups to view the Mars Rover data.
Article
No? My 25Mhz Macintosh LC III is enough to host a webserver running Linux & Apache. It even runs PHP. The 20Mhz PPC CPU used in the rovers is most likely quite a bit faster than the 68030 in the LC III.
www.brownsauce.org
Someone said a while back that a house made of aerogel would need only a candle to heat it. Surely surrounding the electronics in and Aerogel box would trap so much heat they would melt themselves. I understand that they have to shut the electronics off at night, so the radioisotope heaters make sence, but why all the other heaters?
Eat at Joe's.
Xilinx radiation-tolerant Virtex(TM) FPGAs are being used in the "main brain" of the rover vehicle, controlling the motors for the wheels, steering, arms, cameras and various instrumentation, enabling the vehicle to travel about the planet.
They also controlled the Pyrotechnical stuff during landing.[Disclaimer: I work for this great company.]
get 7 free Japanese lessons.
"I'm amazed they can do it all with as little as they have."
All the more reason you can't help but laugh when people bring up arguments like "with computers/RAM/storage becoming so cheap and abundant who cares if {insert some bloated, interpreted, garbage collected language here} - just update your hardware."
One size fits all never does...
BSD is designed. Linux is grown. C++ libs
However, many processors (the G3/750FX comes to mind) allow you to address cache as physical memory, allowing exactly what the grandparent mentioned. You'll still need an external memory controller, though, to get stuff from ROM for boot purposes.
I've had this sig for three days.
The Rad750, btw, is a deeply cool chip. Once it's mature enough to start using for scientific-level stuff, it will be a real revolution in what we can do. One of the limitations with Hubble was that it had so little processing, a full data dump needed to be done for even checking orientation; there was no ability to offload processing to the sat. If the 750, or something similar (not that I know of anything too similar) is up there for our next big telescope, it will make a real difference in the efficiency of how it is used.
I've had this sig for three days.
As noted in a previous slashdot posting, the software in the control room was written in Java.
A ZDNet article says Java made communicating between multiple software pieces very flexible and James Gosling, inventor of Java, spent considerable time helping develop the system. Sun also describes how the same application was used for the Pathfinder mission back in 1997.
It's not putting out Uranuim, Thorium, Plutonium or other heavy elements. Those are produced in supernovae, and can tell a story that would be erased by a nuclear rocket.
Eat at Joe's.
I'm sure an asteroid that was pelted by the exhaust from a nuke rocket would have very detectable levels of those isotopes.
*Groan* Uranium is COMMON in asteroids. My engines would use no more than a few tens of pounds of uranium. Worst case, we'll say it uses a few hundred pounds. How is the particulate matter being exhausted by my engines anywhere near the TONS of uranium contained in many asteroids? In fact, most Uranium on Earth is from the tons that burn up in the atmosphere every year.
As for point #4, you do change things by existing, but you can try to be intelligent about HOW you change things. If I lived on an island with only 20 coconut trees I would not burn them for light and warmth. I'd burn any other wood I could find even if it was inferior to palm trees.
But if you lived on an island with hundreds of thousands of palm trees, would you really feel bad about burning a few for a fire? Remember, a ship will burn/expel *pounds* of uranium. (Much of which will be some other substance after use.) How does that compare to the BILLIONS OF TONS in the solar system?
Also, natural uranium fires probably didn't spew crap into the air like a nuke blast, most of what was burning probably stayed in the ground.
The "crap spewed" doesn't stay in the air very long. Uranium is too heavy. Carbon dating was messed up from radiation pulses. Nothing more, nothing less. I'm sorry that makes life harder for geologists, but that's an unfortunate part of life. How many archeological digs were made harder by robbers, tourists, curious natives, etc, who had all previously wandered the area? It's a fact of life. Space geologists are going to have to get used to the fact that engines will alter things slightly. Possibly, many of them won't care since it's so little. The ones who do, will have to figure out how to work around it.
Javascript + Nintendo DSi = DSiCade
I can give you some answers.
The fire wall is easy to set up, but the cost of the single VxWorks license would put you in hock for a year or so.
The OS itself needs less memory than you would think. For the rover I would guess the OS image is about 500K to 1M, but that doesn't say anything about how much memory its really using for the OS since it can run out of FLASH and leave the 128M of RAM for the stacks used by the tasks (individual RTOS proccess). I would imagine a lot of that RAM is being used for holding the images while they are being sent back to Earth or evaluated for navigation info.
The PowerPC its using is just a radiation hardend version a common CPU, I don't know which, and you can do a lot with a 20Mhz PPC. The training department used 860 PPC/20Mhz in the classes and never had any issues with task execution times, at least not until the system clock was cranked up to absurededly high speeds.
Unfortunatly for hobbiests and hackers everywhere Windriver has never came out with a "Personel" or non-comercial version of their software/license packages, despite one of the instructors pushing for it every chance he got. Managment at Windriver didn't go for the idea, in fact when they started shuting down the training department that instructore was the first to go. So much for Wind River encouraging inovation by the private developer.
Bottom line is that VxWorks is a great OS, versital to the point that someone even ported Doom onto it and ran it on a Kodak digital camera. However, in my opinion, the company is a bit lacking in the area of inspirering creative inovation and development by anyone who is not representing a MAJOR company/organisation like JPL or Boeing.
If you really want to try out a firewall on a real-time OS give QNX a shot, they have (last time I checked) a free development tools package that included a non-comercial "hobbiest" license for x86 CPUs and it supports USB, ethernet, openGL, and just about everything else VxWorks does.
Sure, I'll take a stab. Here are some thoughts on spaceflight software and why realtime is needed. (I'm not a FSW developer but know people that are).
One reason is the always severely constrained environment. You can't just send up a 2Ghz Athlon with gigabytes of memory - explained elsewhere in this discussion - space would physically kill it. So you never have a huge amount of CPU horsepower or memory to work with - the computer is always very primitive, very small, very slow compared to a decent PC. And RTOS's are designed for this kind of environment. But that's not the main reason to use them for space hardware.
As you said, it takes several minutes for commands to be radioed from Earth to Mars, but during those minutes, the rover is doing a whole buncha stuff. It's kind of like your Linux or Windows machine - it's actually doing a whole boatload of stuff even when you're not doing anything and the machine appears to be "just sitting there".
Similarly, the rover's computer is doing many, many things all the time, things that require precise timing and low latencies. It has to concurrently save off data from science instruments, performing I/O between buses and memory/storage devices, listen for commands from Earth, send data to Earth or a Mars orbiter, keep track of which way to point its antennas, run stored command sequences, and run self-test routines on all its subsystems, not to mention operating the hardware to drive itself around, while trying not to get stuck or drive off a cliff, and do all this in a robust and fault tolerant manner.
At any given time, a number of activities like this are occurring. It is the continuous, concurrent nature and tight timing requirements that makes realtime necessary. For instance, I/O between instruments and storage devices. The bus protocol will have certain timing requirements that the computer has to meet while doing all the other stuff.
Keep in mind that there is a fixed amount of operating memory available, so things like I/O buffers (of which there will be many) are statically allocated and limited in size - if the OS or the rover's application software takes longer than expected to do some task, data will start backing up, I/O commands will get retried, data will eventually start getting dropped, and things will go bad if the problem isn't corrected - probably this would end up with a reboot and dropping into safe mode.
The key is, if everything does what it's supposed to, *when* it's supposed to, things go smooth. When operations take longer than they should, you have problems. Processor time, like memory usage, is strictly budgeted and you just can't afford to have _anything_ run that you didn't plan and design into the system.
Example - on a project I was involved with (a huge realtime system), there was a problem with the data collection server that was driving the designers nuts. The processes would periodically pause for brief amounts of time - just long enough to blow the time budgets for the network communication. Really gave them fits. It turned out the problem was the OS's virtual memory paging routine, periodically waking up to flush things to disk. They were using a soft realtime OS, and this use of CPU time by the OS wasn't technically out of spec, but it really gave them trouble. (As I recall, they asked the vendor "can we turn it off?" and the answer was "no").
Hope this helps...