Mars Rover Controlled By Java

[Alf P. Steinbach]

Re: Mars Rover Not Responding - Update - NASA Makes Contact With Mars Rover

On 24 Jan 2004 07:45:20 -0800, eventhelix@hotm ail.com (EventHelix.com ) wrote:
[color=blue]
>It seems to be a software problem. The rover is rebooting frequently.
>
>Who says there is no life on Mars? ... We have bugs.[/color]


xWorks, who made the operating system for both this probe and
the previous American one that failed, see
<url: http://www.windriver.c om/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>

[Alf P. Steinbach]

Re: Mars Rover Not Responding - Update - NASA Makes Contact With Mars Rover

On 24 Jan 2004 07:45:20 -0800, eventhelix@hotm ail.com (EventHelix.com ) wrote:
[color=blue]
>It seems to be a software problem. The rover is rebooting frequently.
>
>Who says there is no life on Mars? ... We have bugs.[/color]


xWorks, who made the operating system for both this probe and
the previous American one that failed, see
<url: http://www.windriver.c om/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>

[Randy Howard]

Re: Mars Rover Not Responding - Update - NASA Makes Contact With Mars Rover

In article <j9xQb.7487$rW5 .804202@news20. bellglobal.com> , mt0000
@sympatico.nosp am-remove.ca says...[color=blue]
>
> "Randy Howard" <randy.howard@F OOmegapathdslBA R.net> wrote in message
> news:MPG.1a7bbc 37f512f54c989ba f@news.megapath dsl.net...[color=green]
> > 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. :-)[/color]
>
> There is no life on Mars. They all live inside.[/color]

So that is what happened to the Morelocks.

--
Randy Howard
2reply remove FOOBAR

[Randy Howard]

Re: Mars Rover Not Responding - Update - NASA Makes Contact With Mars Rover

In article <j9xQb.7487$rW5 .804202@news20. bellglobal.com> , mt0000
@sympatico.nosp am-remove.ca says...[color=blue]
>
> "Randy Howard" <randy.howard@F OOmegapathdslBA R.net> wrote in message
> news:MPG.1a7bbc 37f512f54c989ba f@news.megapath dsl.net...[color=green]
> > 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. :-)[/color]
>
> There is no life on Mars. They all live inside.[/color]

So that is what happened to the Morelocks.

--
Randy Howard
2reply remove FOOBAR

[Edward Green]

Re: Mars Rover Controlled By Java

Uncle Al <UncleAl0@hate. spam.net> wrote in message news:<4009BB55. 4CCD266E@hate.s pam.net>...[color=blue]
> mitch wrote:[color=green]
> >
> > Uncle Al wrote:[color=darkred]
> > >
> > > Local atmospheric pressure is 7-10 torr. Earth sea level is 760
> > > torr. How many planes do you know that cruise at 100,000 feet absent
> > > any oxygen at all? Martian aircraft are a bad dream.[/color]
> >
> > Hmm. Then the test of a Mars glider plane back in August of 2001 was
> > just a bad dream? ;-) Work has begun on a propellered version of the
> > glider cited below. Enjoy.[/color]
>[color=green]
> > AMES COMPLETES SUCCESSFUL TEST OF MARS AIRPLANE PROTOTYPE[/color]
>
> The empirical fact is that lowland Martian air pressure is 7-10 torr.
> The is equivalent to 120,000-100,000 feet terrestrial altitude.[/color]

Read the article: the glider was released at 101,000 feet.
[color=blue]
> If
> the silly thing will be diddling at even 1000 ft altitude Martian, the
> air will be thinner.[/color]

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%.
[color=blue]
> "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.[/color]

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?

[Edward Green]

Re: Mars Rover Controlled By Java

Uncle Al <UncleAl0@hate. spam.net> wrote in message news:<4009BB55. 4CCD266E@hate.s pam.net>...[color=blue]
> mitch wrote:[color=green]
> >
> > Uncle Al wrote:[color=darkred]
> > >
> > > Local atmospheric pressure is 7-10 torr. Earth sea level is 760
> > > torr. How many planes do you know that cruise at 100,000 feet absent
> > > any oxygen at all? Martian aircraft are a bad dream.[/color]
> >
> > Hmm. Then the test of a Mars glider plane back in August of 2001 was
> > just a bad dream? ;-) Work has begun on a propellered version of the
> > glider cited below. Enjoy.[/color]
>[color=green]
> > AMES COMPLETES SUCCESSFUL TEST OF MARS AIRPLANE PROTOTYPE[/color]
>
> The empirical fact is that lowland Martian air pressure is 7-10 torr.
> The is equivalent to 120,000-100,000 feet terrestrial altitude.[/color]

Read the article: the glider was released at 101,000 feet.
[color=blue]
> If
> the silly thing will be diddling at even 1000 ft altitude Martian, the
> air will be thinner.[/color]

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%.
[color=blue]
> "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.[/color]

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?

[mitch]

Re: Mars Rover Not Responding - Update - NASA Makes Contact WithMars Rover

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

Alf P. Steinbach wrote:[color=blue]
> On 24 Jan 2004 07:45:20 -0800, eventhelix@hotm ail.com (EventHelix.com ) wrote:
>
>[color=green]
>>It seems to be a software problem. The rover is rebooting frequently.
>>
>>Who says there is no life on Mars? ... We have bugs.[/color]
>
> xWorks, who made the operating system for both this probe and
> the previous American one that failed, see
> <url: http://www.windriver.c om/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>[/color]

[mitch]

Re: Mars Rover Not Responding - Update - NASA Makes Contact WithMars Rover

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

Alf P. Steinbach wrote:[color=blue]
> On 24 Jan 2004 07:45:20 -0800, eventhelix@hotm ail.com (EventHelix.com ) wrote:
>
>[color=green]
>>It seems to be a software problem. The rover is rebooting frequently.
>>
>>Who says there is no life on Mars? ... We have bugs.[/color]
>
> xWorks, who made the operating system for both this probe and
> the previous American one that failed, see
> <url: http://www.windriver.c om/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>[/color]

[del cecchi]

Re: Mars Rover Not Responding - Update - NASA Makes Contact With Mars Rover

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."

[del cecchi]

Re: Mars Rover Not Responding - Update - NASA Makes Contact With Mars Rover

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."

[Jan C. Vorbrüggen]

Re: Mars Rover Controlled By Java

> Here often anything greater than a few processor instruction cycle[color=blue]
> latency leads to a non-recoverable error situation.[/color]

On a current processor, "a few [...] cycles" is about a nanosecond. Unless
you want to depart at warp speed from a sun going supernova, I see no
application requiring that small a reaction time. The Shuttle avionics runs
on "cycles" of evaluation that are on the order of several milliseconds,
IIRC - and that is in a _very_ dynamic environment.In particular...
[color=blue]
> This is precisely why interrupt level service routines, fast device
> drivers, and similar time-critical operations are generally
> implemented in assembly or other low-level code optimized to minimize
> the number and duration of required machine instruction executions.[/color]

....experience shows that's not usually the case. The context-switching
overhead determined by software (OS) architecture, but also by the hardware
(size of processor context, memory hierarchy, etc) seem to have led to
latencies that seem not to have improved much in the past decade, if not
worsened.
[color=blue]
> With today's focus on high-level programming languages and software
> implemented virtual machines, many people lose sight of the very
> fundamental differences that exist between software that simply
> executes quickly and real-time system software where interrupt level
> response processing must be assured to be alway less than some
> critical latency limit.[/color]

....which is very difficult to evaluate on a modern processor in any case.

Jan

[Jan C. Vorbrüggen]

Re: Mars Rover Controlled By Java

> Here often anything greater than a few processor instruction cycle[color=blue]
> latency leads to a non-recoverable error situation.[/color]

On a current processor, "a few [...] cycles" is about a nanosecond. Unless
you want to depart at warp speed from a sun going supernova, I see no
application requiring that small a reaction time. The Shuttle avionics runs
on "cycles" of evaluation that are on the order of several milliseconds,
IIRC - and that is in a _very_ dynamic environment.In particular...
[color=blue]
> This is precisely why interrupt level service routines, fast device
> drivers, and similar time-critical operations are generally
> implemented in assembly or other low-level code optimized to minimize
> the number and duration of required machine instruction executions.[/color]

....experience shows that's not usually the case. The context-switching
overhead determined by software (OS) architecture, but also by the hardware
(size of processor context, memory hierarchy, etc) seem to have led to
latencies that seem not to have improved much in the past decade, if not
worsened.
[color=blue]
> With today's focus on high-level programming languages and software
> implemented virtual machines, many people lose sight of the very
> fundamental differences that exist between software that simply
> executes quickly and real-time system software where interrupt level
> response processing must be assured to be alway less than some
> critical latency limit.[/color]

....which is very difficult to evaluate on a modern processor in any case.

Jan

[Jan C. Vorbrüggen]

Re: Mars Rover Not Responding

> NASA is renowned for its antenna failures - the Hubble space[color=blue]
> telescope,[/color]

HST didn't and doesn't have antenna problems.
[color=blue]
> Ulysses at Jupiter[/color]

That one is going 'round the sun, and has had no problems of the sort.
[color=blue]
> and now their little radio-controlled go-cart on Mars.[/color]

....which isn't having an antenna problem, either.

As far as I can remember, the only probe to have an antenna failure was
Galileo. Feature creep caused by delays and other mods caused that one -
a bit of bad luck was also involved. OTOH, if the delays hadn't been,
another problem would likely have caused it to disintegrate during cruise,
if that hadn't been (painfully) found on another satellite and a work-around
identified.

As usual, you win some and you loose some.

Jan

[Jan C. Vorbrüggen]

Re: Mars Rover Not Responding

> NASA is renowned for its antenna failures - the Hubble space[color=blue]
> telescope,[/color]

HST didn't and doesn't have antenna problems.
[color=blue]
> Ulysses at Jupiter[/color]

That one is going 'round the sun, and has had no problems of the sort.
[color=blue]
> and now their little radio-controlled go-cart on Mars.[/color]

....which isn't having an antenna problem, either.

As far as I can remember, the only probe to have an antenna failure was
Galileo. Feature creep caused by delays and other mods caused that one -
a bit of bad luck was also involved. OTOH, if the delays hadn't been,
another problem would likely have caused it to disintegrate during cruise,
if that hadn't been (painfully) found on another satellite and a work-around
identified.

As usual, you win some and you loose some.

Jan

[Robert C. Martin]

Re: Mars Rover Not Responding

On Thu, 22 Jan 2004 17:24:19 -0800, Uncle Al <UncleAl0@hate. spam.net>
wrote:
[color=blue]
>NASA is renowned for its antenna failures - the Hubble space
>telescope, Ulysses at Jupiter, and now their little radio-controlled
>go-cart on Mars.[/color]

I only know of one antennae failure. Gallileo's antenna failed to
open correctly. As I recall there was speculation that some of the
grease in the struts degraded (or something) during the long years of
storage following the Challenger explosion.

NASA has had it's up's and downs. That's understandable. They are
doing things that nobody has ever done before.