What's Inside the Mars Rovers 458
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..."
Radiation hardness (Score:5, Interesting)
Radiation Shielding (Score:4, Interesting)
---
Re:Self-warming (Score:5, Interesting)
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
Should it have some redundancy? (Score:3, Interesting)
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?
Re:I hope the flash memory was not commodity hardw (Score:5, Interesting)
And the flash memory has probably not failed. It seems to have been a software problem, not hardware.
Rootbear
Re:Radiation hardness (Score:5, Interesting)
A quote: Raises some interesting questions about software reliability, I think. Did nobody think about running out of disk space?
Beagle-2 (Score:3, Interesting)
Save HST! Sell Sojourner knock-offs (Score:5, Interesting)
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!
Re:What's the bus speed on that thing? (Score:4, Interesting)
space shuttle uses 1969-vintage ibm 360 computers (Score:5, Interesting)
I want some real specs. (Score:2, Interesting)
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!
Re:Is there a Linux is space yet? (Score:2, Interesting)
NASA has been evaluating it...
On a related note, they use NVIDIA/Linux setups to view the Mars Rover data.
Article [linuxelectrons.com]
Re:Radiation hardness (Score:4, Interesting)
Re:20 MHz is not enough (Score:3, Interesting)
Re:Self-warming (Score:3, Interesting)
FPGA's (Score:4, Interesting)
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.]
Re:What's the bus speed on that thing? (Score:2, Interesting)
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...
Re:What's the bus speed on that thing? (Score:4, Interesting)
Re:Radiation hardness (Score:4, Interesting)
Re:Processor is *not* a PowerPC (Score:5, Interesting)
Mission control software is in Java (Score:3, Interesting)
As noted in a previous slashdot posting [slashdot.org], the software in the control room was written in Java.
A ZDNet [com.com] 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 [sun.com] also describes how the same application was used for the Pathfinder mission back in 1997.
Re:Radiation hardness (Score:5, Interesting)
As someone with first-hand experience with VxWorks let me say that VxWorks' memory handling code sucks. Their malloc implementation has got to be the worst one ever designed. It fragments horribly and when fragmented has unusable performance. A malloc call can take many milliseconds when memory gets fragmented. Our box used to crash due to the fragmentation. I replaced Wind River's code with DLMalloc and that fixed the memory issue. We went from many tens of thousands of fragments to only a few dozen. Our reliability significantly increased as well after dumping Wind Rivers brain-dead malloc code. BTW, glibc uses a variant of Doug Lea's malloc code, so it's been widely tested.
Furthermore, in VxWorks there is no way to identify what process malloced a block of memory. There is no memory protection either (think DOS). If a task has a memory leak, VxWorks does not provide any method of tracking down the culprit. I had to add that support to the DL Malloc code I ported so we could find memory leaks and general memory usage by task.
Since malloc is critical to the working of VxWorks, if you run out of memory you are basically completely dead. Often the only way to recover is to wait for the hardware watchdog timer to kick in and reboot the system.
If a task dies in VxWorks with a bad pointer there is no way to recover other than reboot. The OS will not clean up after a task (i.e. free memory, close files, release semaphores).
As far as flash goes, VxWorks supports the FAT16 file system. As you know, FAT16 sucks. It only supports a limited number of files in the root directory. It's relatively easy to corrupt, and when corrupt it tends to corrupt itself even worse. There is no wear leveling support. If the FAT table or root directory gets corrupted, you're screwed. VxWorks is even worse since there arn't tools to fix a corrupt file system.
VxWorks is not a scalable OS. The OS gets slower as the number of tasks increases. Realtime support sucks. Although it has support for things like priority inheritance to prevent priority inversion, the best guaranteed realtime latency is half the system tick rate (the tick rate is usually 10ms).
Also remember that unlike open source operating systems, the source code to VxWorks is not available unless you pay some major $$$. Without the source you're basically working blind.
VxWorks is an old RTOS, and its age is definitely showing. It is not a robust OS.
As far as turning VxWorks into a firewall, you'll need to write all your own code. The VxWorks TCP/IP stack is an archaic vulnerable version of the BSD stack. TCP sequence number guessing is trivial. There is no built-in support for firewall support, NAT, or anything else. I have heard many many complaints about the VxWorks networking code. Although the box I'm working on is a router and broadband remote access server, we don't use the VxWorks TCP/Ip stack much. I am sure the VxWorks stack is vulnerable to many of the current DOS attacks as well.
Some of you might say why not use VxWorks AE, which adds memory protection. Think hacked-in memory protection far worse than Windows 95. It's slow, very buggy, and poorly supported. We tried AE and after many months we dumped it and went back to the non-AE version. Very few companies actually went with AE.
Today there are many other choices for an RTOS that are better than VxWorks. For our next major project we're looking at both QNX and TimeSys Linux. QNX is a true microkernel design with the core being around 70K. Every driver is protected and can be restarted if it crashes. I think you can even buy a medical grade version of QNX. TimeSys Linux is also pretty cool, with excellent real-time support and all the advantages of Linux. For something like the Mars rover, QNX would be better due to the limited amount of memory and greater robustness.
Wi
Re:Save HST! Sell Sojourner knock-offs (Score:2, Interesting)
Re:Self-warming (Score:3, Interesting)
Re:Sigh (Score:3, Interesting)
*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.
Re:Radiation hardness (Score:2, Interesting)
Re:FPGA's (Score:2, Interesting)
The last time I read Xilinx's line on "radiation-tolerance" it was that you could reprogram (or refresh) sections of a Virtex while the rest of the chip was in use. So if a stray gamma particle flips a bit in your configuration SRAM you can reset it.
This seems more like radiation-dodging rather than tolerance.
As a former Windriver employee... (Score:2, Interesting)
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.
Re:Why does it need an RTOS? (Score:1, Interesting)
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...