Rover brains?

JPL has some limited information about the Mars rover electronics and the
VME bus:
http://marsrovers.jpl.nasa.gov/missi...er_brains.html

What kind of CPU and O/S are the rovers using (or do I really want to know)?

JJ Robinson II
Houston, TX
****************
* JOKE *
****************
* SERIOUS *
****************
* SARCASTIC *
****************
* OTHER? *
****************

In article , hrtbreak wrote:
JPL has some limited information about the Mars rover electronics and the
VME bus:
http://marsrovers.jpl.nasa.gov/missi...er_brains.html

What kind of CPU and O/S are the rovers using (or do I really want to know)?
They run vxWorks,on a 32 bit RAD6000 CPU iirc(Not an ordinary cpu..)

http://www.windriver.com/marsrover/

--
Vennlig hilsen/Best Regards
Nils Olav Selåsdal NOS at Utel.no
System Engineer
UtelSystems a/s

Uhh...i heard something about extensive use of JAVA. I just hope it
wasn't in rover itself. It's nice for rebootable web-based systems but i
can't stand the tought of bloated, buggy code running inside the poor rover.

Somehow, I'm afraid rover "bluescreened" after bloatware choked on
something that was impossible to account for. Let's hope they can
"reboot" the thing from EPROM and start again...


hrtbreak wrote:
JPL has some limited information about the Mars rover electronics and the
VME bus:
http://marsrovers.jpl.nasa.gov/missi...er_brains.html

What kind of CPU and O/S are the rovers using (or do I really want to know)?

JJ Robinson II
Houston, TX
****************
* JOKE *
****************
* SERIOUS *
****************
* SARCASTIC *
****************
* OTHER? *
****************

Archibald wrote in message ...
Uhh...i heard something about extensive use of JAVA. I just hope it
wasn't in rover itself. It's nice for rebootable web-based systems but i
can't stand the tought of bloated, buggy code running inside the poor rover.


Bad code is a very strong function of the programmers and only a weak
function of language. C/C++/Ada/Java can all end up as bloated buggy
code. I have worked on code where Assembly would have been just as
easy to read if written properly in the first place.

IMHO it's the code review process as well as the coding environment
that can make all the difference. ie managers that have the attitude
of "just get it done on time on matter what" are generally managers to
avoid.


Greg

In article ,
(Greg) wrote:

IMHO it's the code review process as well as the coding environment
that can make all the difference. ie managers that have the attitude
of "just get it done on time on matter what" are generally managers to
avoid.

Everything I've ever read about software engineering says that NASA has
one of the best software development processes in the world. The idea
that you could diagnose a crashed box from 100,000,000 miles away is
amazing. The planning and conservative design work that makes that
possible is absolutely mind-blowing.

As for "get it done on time", well, you thought you had deadline
pressure? If my code is late, my company's quarterly numbers will
suffer, but as long as things are not too bad, we'll get it released
next quarter. If the planets aren't lined up right, the mission is a
no-go. Miss your launch window, and it may be a very long time before
you get to try again.

In article ,
says...
In article ,
(Greg) wrote:

IMHO it's the code review process as well as the coding environment
that can make all the difference.

Yep. For the past 25 years, the software industry has repeatedly
discovered that having a second set of eyes see a program is the single
best way of improving quality.


ie managers that have the attitude
of "just get it done on time on matter what" are generally managers to
avoid.

It isn't just the managers. Long ago, I worked in a startup with very
good people. Except the managers of the development team. We developers
managed to create a good product despite the attitudes of our managers.


As for "get it done on time", well, you thought you had deadline
pressure? If my code is late, my company's quarterly numbers will
suffer, but as long as things are not too bad, we'll get it released
next quarter.

You clearly misunderstand the VC-dominated commercial software
environment. If the VCs liquidate the company after a bad quarter, there
is no "next quarter". In contrast, there will be another launch window
for Mars within the next couple of years.
--
Kevin Willoughby lid

Imagine that, a FROG ON-OFF switch, hardly the work
for test pilots. -- Mike Collins

In article ,
says...
Uhh...i heard something about extensive use of JAVA.

I'm not quite sure of the extent of "extensive", but yes, Java (not all
upper-case, please) was one of the many, many tools used on MER.


I just hope it wasn't in rover itself.

There is Java code in the rover. So what?

[i]
It's nice for rebootable web-based systems but
can't stand the tought of bloated, buggy code running inside the poor rover.

uh, the first MER lander is rebooting frequently, with (as far as I
understand these things) no reason to blame the Java Virtual Machine.

Java code does not have to be "bloated, buggy code". Virtual machine
architectures are a classic way to to create a small, tight program --
consult Knuth for details.

"Bloated, buggy code" is more common in non-Java environments, e.g., MS
Office running on MS Windows.


Somehow, I'm afraid rover "bluescreened"

"Bluescreen" is a Microsoft-ism. Note that Microsoft is legally
restrained from doing much of anything with Java.
--
Kevin Willoughby lid

Imagine that, a FROG ON-OFF switch, hardly the work
for test pilots. -- Mike Collins

Kevin Willoughby wrote:

In article ,
says...

Somehow, I'm afraid rover "bluescreened"


"Bluescreen" is a Microsoft-ism. Note that Microsoft is legally
restrained from doing much of anything with Java.

Which, as far as I'm concerned, is it's principle redeeming feature!

Brett

Kevin Willoughby writes:
[i]
It's nice for rebootable web-based systems but
can't stand the tought of bloated, buggy code running inside the poor rover.

uh, the first MER lander is rebooting frequently, with (as far as I
understand these things) no reason to blame the Java Virtual Machine.

Java code does not have to be "bloated, buggy code". Virtual machine
architectures are a classic way to to create a small, tight program --
consult Knuth for details.

See, for example, FORTH --- which uses a =MUCH= simpler virtual machine
than JAVA, and can pack an entire operating system / extensible compiler
into a mere 8k...


"Bloated, buggy code" is more common in non-Java environments, e.g., MS
Office running on MS Windows.

"Microsoft code is a way of thinking --- or rather, of =NOT= thinking..."


-- Gordon D. Pusch

perl -e '$_ = \n"; s/NO\.//; s/SPAM\.//; print;'

Gordon D. Pusch wrote:

See, for example, FORTH --- which uses a =MUCH= simpler virtual machine
than JAVA, and can pack an entire operating system / extensible compiler
into a mere 8k...

You can have JVM-s with sizes within the same order of magnitude. A JIT
JVM will obviously be larger, but not by *that* much.


-- Gordon D. Pusch

perl -e '$_ = \n"; s/NO\.//; s/SPAM\.//; print;'

--
Sander

+++ Out of cheese error +++