Mars Rover Controlled By Java

  • Thread starter Michael N. Christoff
  • Start date
T

Torben Ægidius Mogensen

I think they should turn it off and turn it on again.

It may be a bit hard to reach the on/off switch.

If I was to make such a vehicle, I woul dmake sure to allow it to be
rebooted by remote control even when the computer is in some undefined
state, e.g., by having a simple circuit listening to the incoming
signals and when a specific sequence occurs, reboot the main computer.

Torben
 
A

ak

LOL - love that one Joe, I'll have to
add it to my list of MafiaSoft, M$,
Windoze and MicroBastard* ..

* Has a particularly Australian flavor.
Aussies enjoy that the second word
does not even derive from a word
that starts with the same/similar
letter. ;-)

you write it wrong:
MicrobaStard is right!
 
P

Programmer Dude

Randy said:
That's simply not true.

You're right, of course. I had in mind the big commercial jets
when I was comparing the landing speed of 747s with others of the
same general class.
...accomplished pilots practice flapless landings in
case of a system failure.

Absolutely.
 
A

Alan Balmer

NASA is renowned for its antenna failures - the Hubble space
telescope, Ulysses at Jupiter, and now their little radio-controlled
go-cart on Mars.

Since they're getting good signal, but meaningless data, the antenna
is not likely to be the problem, is it?
Uncle Al eagerly anticipates a Hummer-2 advert beginning with the $240
million pigmy brain fart that couldn't call home. Anticipating that
its working life would be less than 90 days because of dust
accumulating on its solar panels is also precious. Hey NASA, "blow
job."

One presumes the same engineering glitch is in the other rover.

I wouldn't "presume" anything without considerably more data.
Actually, I would - I presume that NASA has people working on the
problem that are at least as competent as you are ;-)
 
A

Andrew Thompson

"ak"
...
| > Windoze and MicroBastard ..
...
| MicrobaStard is right!

LOL! Yep, that fits ;-)
 
H

Harry Conover

Michael N. Christoff said:
As I mentioned, you would not implement the OS in Java, but would implement
a VM for the OS that allows one to run Java code with deterministic time
contraints on operations.

No, what you actually posted was (unless attrition of this to you was
in error):

"> > Java, the software developed by Sun Microsystems in the mid-1990s
as a
Running Java code with deterministic time constraint on operations
could be conceptually employed to construct a real-time OS, but in
reality could not be done simply due to the fact that the Java
implementation is so layered and ridiculously bloated, that it would
be practically incapable of meeting the microsecond and millisecond
timing constraints typically imposed on the deep end of a real-time
operating systems.

Certainly Java is capable of non real-time task such as the timely
update of a wall clock time display, or the issuance of coontrol
sequences based on clock time, but it depends of the capabilities of
some RTOS to provide the time-of-day services on which it feed to
provide these capabilities.

Due to it's very high-order application focus (that it, consists of
application level functions, not machine oriented instructions), I
really cannot imagine of a Java implementation that would lend itself
to RTOS applications, whether a VM implementation or not.

Then too, I don't believe that this is what you are trying to say, and
I believe the confusion is cause by someone erroneously attributed a
quote from the Sun PR blurb to you.

I suspect that tranlated to my language, what you're telling us is
that one could employ a Java implementation running on top of the
environment created by a real-time operating system, something that is
routinely done.

I have no problem with Java, its capabilities, or its applications,
however I do strenuously object to the statement that: "Java, the
software developed by Sun Microsystems in the mid-1990s as universal
operating system for Internet applications, gave NASA a low-cost and
easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and
life."

The simple facts of life are that Java was not developed as a
"universal operating system for Internet applications" nor is a
real-time operating system "option for running Spirit".

Spirit's applications level software could well be Java, or Fortran,
Basic, Jovial, Lisp, Forth (Ghod Forbid), or just about any HOL. My
point is that you can damn't well bet that the RTOS that directly
controls (both the good and now the bad on Spirit) is very likely
programmed in a language providing direct machine instruction level
control of its processor, likely C, C++, or assemly langage just as is
the embedded bios in your computer, RAID server, or network
controller.

Fact is, the controller aboard Spirit is functioning as simply a
glorified PLC, and likely has very similar embedded firmware to that
of earthborne PLCs. Why wouldn't JPL copy this model, 90% of man's
controller experience is using PLCs.

Rant complete! ... -.-

Harry C.
 
M

Michael N. Christoff

Harry Conover said:
As I mentioned, you would not implement the OS in Java, but would implement
a VM for the OS that allows one to run Java code with deterministic time
contraints on operations.

No, what you actually posted was (unless attrition of this to you was
in error):

"> > Java, the software developed by Sun Microsystems in the mid-1990s
as a life."

Running Java code with deterministic time constraint on operations
could be conceptually employed to construct a real-time OS, but in
reality could not be done simply due to the fact that the Java
implementation is so layered and ridiculously bloated, that it would
be practically incapable of meeting the microsecond and millisecond
timing constraints typically imposed on the deep end of a real-time
operating systems.

Certainly Java is capable of non real-time task such as the timely
update of a wall clock time display, or the issuance of coontrol
sequences based on clock time, but it depends of the capabilities of
some RTOS to provide the time-of-day services on which it feed to
provide these capabilities.

Due to it's very high-order application focus (that it, consists of
application level functions, not machine oriented instructions), I
really cannot imagine of a Java implementation that would lend itself
to RTOS applications, whether a VM implementation or not.

Then too, I don't believe that this is what you are trying to say, and
I believe the confusion is cause by someone erroneously attributed a
quote from the Sun PR blurb to you.

I suspect that tranlated to my language, what you're telling us is
that one could employ a Java implementation running on top of the
environment created by a real-time operating system, something that is
routinely done.

I have no problem with Java, its capabilities, or its applications,
however I do strenuously object to the statement that: "Java, the
software developed by Sun Microsystems in the mid-1990s as universal
operating system for Internet applications, gave NASA a low-cost and
easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and
life."

The simple facts of life are that Java was not developed as a
"universal operating system for Internet applications" nor is a
real-time operating system "option for running Spirit".

Spirit's applications level software could well be Java, or Fortran,
Basic, Jovial, Lisp, Forth (Ghod Forbid), or just about any HOL. My
point is that you can damn't well bet that the RTOS that directly
controls (both the good and now the bad on Spirit) is very likely
programmed in a language providing direct machine instruction level
control of its processor, likely C, C++, or assemly langage just as is
the embedded bios in your computer, RAID server, or network
controller.

Fact is, the controller aboard Spirit is functioning as simply a
glorified PLC, and likely has very similar embedded firmware to that
of earthborne PLCs. Why wouldn't JPL copy this model, 90% of man's
controller experience is using PLCs.

Rant complete! ... -.-

Harry C.[/QUOTE]
 
M

Michael N. Christoff

Harry Conover said:
As I mentioned, you would not implement the OS in Java, but would implement
a VM for the OS that allows one to run Java code with deterministic time
contraints on operations.

No, what you actually posted was (unless attrition of this to you was
in error):

"> > Java, the software developed by Sun Microsystems in the mid-1990s
as a life."
[/QUOTE]

I just copied that from the article to introduce the link, it is not my
personal opinion.

[argument based on this snipped]
I suspect that tranlated to my language, what you're telling us is
that one could employ a Java implementation running on top of the
environment created by a real-time operating system, something that is
routinely done.

Spirit's applications level software could well be Java, or Fortran,
Basic, Jovial, Lisp, Forth (Ghod Forbid), or just about any HOL. My
point is that you can damn't well bet that the RTOS that directly
controls (both the good and now the bad on Spirit) is very likely
programmed in a language providing direct machine instruction level
control of its processor, likely C, C++, or assemly langage just as is
the embedded bios in your computer, RAID server, or network
controller.

Perhaps in your group, some messages from the thread are being lost, but the
fact that Java is (almost certainly) not on the rover has been mentioned
numerous times already by many different people.
Fact is, the controller aboard Spirit is functioning as simply a
glorified PLC, and likely has very similar embedded firmware to that
of earthborne PLCs. Why wouldn't JPL copy this model, 90% of man's
controller experience is using PLCs.

Well it depends. Is the new technology easy to use, inexpensive, and does
it offer useful capabilities and features PLCs do not? These are all
factors that may make changing to a new technology, as tried and true as the
older one may be, a good idea.



l8r, Mike N. Christoff
 
E

EventHelix.com

It seems to be a software problem. The rover is rebooting frequently.

Who says there is no life on Mars? ... We have bugs.

In any case what the rover has accomplished thus far is a technical
feat that we should be proud of.

Sandeep
 
M

Matt Timmermans

Randy Howard said:
Ah, the Martians are just playing with us, sending a few brief seconds
on data to make us believe it's still all by itself. Next thing you
know, they'll rig it to send back data proving there is no actual
life on mars. :)

There is no life on Mars. They all live inside.
 
A

Alf P. Steinbach

It seems to be a software problem. The rover is rebooting frequently.

Who says there is no life on Mars? ... We have bugs.


xWorks, who made the operating system for both this probe and
the previous American one that failed, see
<url: http://www.windriver.com/platforms/platformvdt/>, thinks the
following is a real advantage -- and perhaps so also did NASA:


<quote>
Reduces time-to-market by cutting integration and testing ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

typically the most time-consuming stages of the development process.
</quote>
 
E

Edward Green

Good, So, my estimate is fine.

Yes ... interesting as soon as I read "about 1/3" I mentally rounded
that down to ".3", thus making your estimate farther off! ;-)

That must show something: by repeated change of base or denominator
and always rounding down, we could manage to round "1" to "0".
 
E

Edward Green

Uncle Al said:
The empirical fact is that lowland Martian air pressure is 7-10 torr.
The is equivalent to 120,000-100,000 feet terrestrial altitude.

Read the article: the glider was released at 101,000 feet.
If
the silly thing will be diddling at even 1000 ft altitude Martian, the
air will be thinner.

Martian gravity is less, hence the pressure relative pressure
difference between 0 and 1000 feet will be less than that on Earth:
less than 5%.
"Ye canna break the laws of physics."

The Concorde flew at 60,000 feet and gulped air like a madman. The
U-2 did 75,000 feet, breathed air, and it was a bitch to fly. The
SR-71 Blackbird could barely do 100,000 feet while at Mach 3+ with its
cockpit windshield simmering at 620 F. It drank 8000 gallons/hr of
fuel. It breathed 6 million ft^3 of air/minute.

Al ... organizational bashing is fun and rewarding, but must be taken
with up with taste. Sending flawed subtly mirrors into space while
good ones sit in storage, and launching on colder and colder days
until disaster strikes: these are both errors of judgement well within
the capability of the political machine. But making fundamental
science errors in the preliminary design stages, and saying something
(whose gross design parameters are available to anybody willing to
take the time to look) can work when it not only can't but, according
to you, grossly can't?

That is down at the 5 sigma tail of Bayesian probability, and you know
it.

Of your three examples, only the U-2 is remotely relevant, since it
was essentially a powered glider; and it did not gulp air and fuel,
which you seem fixated on. Who the hell said anything about
air-breathing flight, anyway?

The basic principles and parameters are well known: you have your
Martian atmosphere, you have your structural requirements, you have
your power requirements, you have your known solar cell efficiency.
The engineering either comes together or it doesn't. Have you run the
figures? The issue is whether you can build a large enough and light
enough airframe to move enough rarefied gas to generate sufficient
lift to sustain flight at a drag sustainable by some reasonable power
make-up from solar cells. There are people who could do this on the
back of an envelope.

No ... I haven't run the calculations either. But knowing that high
altitude long dwell time solar powered sail planes have been seriously
considered on Earth, that flight costs less power with slower flight
and larger lifting area, knowing the experience with very light weight
miniminally powered structures accumulated by the human-powered flight
school ... all this give credibility to the idea and tends to suggest
that Al is making an ill-considered shot from the hip, as usual.

And this is not to mention aerostats ... you may have noticed also how
the test glider was carried to 101,000 ft? I suppose that was a
physical impossibility too?
 
M

mitch

Ahh, how quickly we blame software. The actual problem appears to
be hardware (see article below) that is causing the computer to
reboot about once every minute. Last I heard from NASA, Spirit
did an unexpected 73 Mbit dump of electrical subsystem information,
which would seem to support NASA's theory of hardware failure, via
the 128 Kbit/sec uplink to the Orbiter. And, BTW, it is NASA's
software running on VxWorks that is allowing the reboot to occur
due to a watchdog timer expiration, i.e., NASA's software is not
resetting the timer before it expires. The OS has nothing to do
with it, in this case. ;-)
---------------------------

NASA fights to revive Spirit on Mars
====================================

By Richard Stenger
CNN

(CNN) --Attempting to diagnose a nearly mute and temporarily delirious
spacecraft more than 100 million miles away, NASA mission controllers
said Friday that they suspect a hardware problem on the six-wheeled Mars
rover may have caused a severe malfunction.

The craft, Spirit, has sent back little more than beeps and sporadic
data bursts since Wednesday, forcing NASA engineers to scramble for
answers at an inopportune time: an identical robot ship is poised to
land on the other side of Mars on Saturday night or Sunday morning.

Cautioning that they will need more time to understand what went wrong,
project engineers said they have determined that Spirit has rebooted or
tried to reboot itself more than 60 times a day since the failure.

The preliminary health checkup includes both bad news and good news for
the $400 million mission, designed to search for evidence of water on
the red planet in the ancient past. First the bad.

"We will not be restoring functionality to Spirit for some time, for
days or weeks, even in the best of circumstances," Pete Thiesinger, Mars
rover project manager, told reporters at NASA's Jet Propulsion
Laboratory in Pasadena, California.


A measure of hope
-----------------

Now the good. NASA engineers think they can maintain the spacecraft's
current health for some time, communicating simple commands and
receiving simple replies, but nothing comparable to the flood of
geological and photographic data from the first 18 days of the mission
in Gusev Crater, a roughly 100-mile-wide pockmark thought to have once
been filled with water.

"I expect we will get functionality back from this rover," Thiesinger
added. The chances that it will be perfect again are not good. But the
chances that will not regain functionality are low, too, he said.

The culprit remains a mystery, but engineers have pinpointed the time
when the glitch began. Spirit was using an onboard motor to move its
thermal spectrometer for a test when the motor unexpectedly conked out.

After that, its messages to Earth became sporadic, feeble and in some
cases garbled. More detective work determined that its processor
repeatedly wakes up, attempts to load software data, finds a problem and
then presses its own reset button.

JPL engineers have coaxed Spirit back into regular and coherent contact
with Earth, albeit in very simple conversations. They think one possible
cause is that a hardware system has broken and affected the software
somehow.

"We're a long, long way from being done here, but we have serious
problems and our ability to work around them is unknown," Thiesinger said.

Into thin Martian air
---------------------

If performing long-distance therapy on Spirit were not enough, NASA must
guide an identical twin rover to a landing in Meridiani Planum, a
high-elevation plain loaded with a mineral that often forms in the
presence of water.

The Martian atmosphere is much thinner there than it is where Spirit
landed, and a recent dust storm in the region thinned it even further.
The conditions mean that Opportunity's parachute will have a harder time
slowing the craft as it prepares to land.

To compensate, the craft will deploy its parachute much sooner before
touchdown, which is scheduled for 12:05 a.m. ET.

"This will be challenging because it's the highest-altitude landing that
NASA has ever attempted," said Wayne Lee, the engineer in charge of
Opportunity's entry, descent and landing.


Find this article at:
http://www.cnn.com/2004/TECH/space/01/23/spirit.contact/index.html
 
D

del cecchi

From a website "spaceflightnow.com" (still sounds like software)

Rover project manager Peter Theisinger gave the following update on
activities to diagnose Spirit's ailment and return the craft to working
order:

"We made good progress overnight and the rover has been upgraded from
critical to serious. We have a working hypothesis we are pursuing that
is consistent with many of the observables and consistent with
operations that we performed on the vehicle last night. It involves the
flash memory on the vehicle and the software used to communicate with
that memory.

"The processor on Spirit has three kinds of memory:

"There is the random access memory just like the memory in your
computer, which is used basically in a real-time mode. And that memory
is volatile, so when we turn off the rover at night that memory goes
away.

"We have flash memory. That memory is just like the memory in a digital
camera. It can also be read to and written from easily. But it has
non-volatile characteristics -- the information that is stored there
stays overnight even if the vehicle is powered down.

"And then we have we call double EPROM, which is
electrically-programmable memory. That is more difficult to write to and
read from, and we use that to store part of the flight software image.

"The vehicle normally uses the flash memory mostly for the storage and
retrieval of engineering and the scientific telemetry. The software has
to communicate with the flash memory -- has to open up files, establish
file directories, close files in that flash memory. That process has to
work correctly.

"We are capable of operating the vehicle without going to the flash
memory in what we call a 'cripple mode.' That is name we have chosen --
you should not read too much into that. That basically tells the flight
software that when it boots up, it should operate with its file
directory out of the random access memory rather than the flash memory.
That would avoid any issues that we might have with either the flash
memory itself or the flight software that is used to write to it.

"Let me talk about the chronology of what happened in the last 24 hours.
If you recall when we last talked at yesterday's press conference, we
were attempting to shut down the vehicle because the batteries were
becoming depleted. We had an apparent inability to shut down the vehicle
last night, yesterday at the end of the Mars day, which is about the
time of the press conference at 9 a.m. Pacific. That was in fact
confirmed because later we had a UHF communications session with Odyssey
where we got 73 megabits of data, mostly fill or garbage data, although
we did get some fault data, some current, some 14 hours old.

"We did not know but thought we might go into low-power overnight if the
batteries were fully depleted. When came up this morning we looked for
the 9:30 Mars time communications window and it was not there,
indicating, we thought, that we had gone into low-power. That would
cause the vehicle to come up at 11 o'clock and tell us that.

"We, just prior to 11 o'clock, sent a command to the vehicle that said
'go into this cripple mode.' That is only done at the next reset, so
then we sent a command to the vehicle that said 'and reset' in order to
do that. And we timed it so that when the 11 o'clock session would
start, we would begin to get that session at 10 bits per second
indicating we'd gone into low-power. When the commands reached the
spacecraft light-time away, it would send us into cripple mode, reset
the computer and we would come up in the mode. And in fact that is
precisely what happened.

"At that point, we commanded a one-hour communications session at 120
bits per second. That communications session happened as planned.

"The progressive set of resets that we were getting into every hour did
not reoccur, leading us to conclude that our hypothesis is largely
correct -- that is there is something involved in the flight software
that talks to the flash memory that's causing this difficulty.

"Why that might cause us difficulty is because when the spacecraft first
wakes up it needs to communicate with the flash memory to establish a
file structure and when it goes to sleep and shuts down, just like you
shut down your computer at home, it needs to go out to that memory and
close all of those files and clean everything up. If it is unable to do
that, it would not complete those tasks appropriately and will basically
reset itself and not shut down.

"In the midst of that 120 bits per second, one-hour session, we decided
to shut down the vehicle in order to replenish the batteries. We
commanded the shutdown just prior to the end of the communications
session so that we would see the communications session terminate early
if we were able to operate it correctly. That happened. And we sent two
post-shutdown beeps, which we expect not to hear if it is asleep but we
would hear if it was not asleep, and we did not get those, once again
confirming that the vehicle to the best of our ability to determine is
now sleeping on Mars.

"We also yesterday as part of the command sessions during this period of
time terminated tonight's UHF passes and reset the uploss timer. The
uploss timer is a set of fault code that go into play when the vehicle
thinks it has a communications problem and causes some things to switch
state and we didn't want to get into that if we could avoid it. Both of
those were confirmed to be successful.

"So we have a vehicle that is stable now in power and thermal. We have a
working hypothesis that we have confirmed. The fault protection to the
best of our estimation has worked as designed. It took us a lot to
figure out what was going on, but we think everything has worked in the
fault protection as we expected it to do.

"We have a go-forward plan. The cripple mode, which we can use every
day, needs to be re-established every day because it loses the memory
that that's the way it should start up. So every morning we will need to
start up in cripple mode, so we need to establish an operational way of
doing that every day for the next few sols (Mars days).

"We need to establish a high-rate link in order to be able to get much
more data back, particularly if we want to read out the flash memory and
determine what has happened. What we will plan to do is likely to use
the Odyssey afternoon relay pass for that purpose prior to the afternoon
shutdown.

"We need to then establish the contents of flash to find out what
happened and then we need to move forward with the diagnosis and
recovery of the vehicle capability based upon what we find there.

"Remember that this was all kicked off by Sequence 2502. That was the
sequence that was using the elevation motor in the mast failing out,
failing to complete (on Wednesday). We still do not know the details of
why that happened and we need to do that.

"The mission consequences of this are uncertain at the present time. But
I think that we feel that we probably have more capability left in the
vehicle that we can establish than the worst-case scenarios by quite a
bit. We still see a couple of weeks to determine what had happened and
to rebuild our confidence into what is working on the vehicle and to get
back closer to routine operations. I think we are probably like three
weeks away from driving, I am guessing.

"The team will begin to go into double-shift operations probably a day
or so after Opportunity's landing where we have a re-plan period and
then an operational period as we begin to work through the forensics of
this.

"But this is a very good news. We've established an ability to
communicate with the vehicle reliably, we've established that in fact we
do have controllability of the vehicle, can establish a good power and
thermal state, our working hypothesis is one that we can work around
with significant measure if it turns out our working hypothesis is
correct. So a good day for an Opportunity landing."
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,780
Messages
2,569,611
Members
45,265
Latest member
TodLarocca

Latest Threads

Top