http://news.com.com/2100-1007_3-5142220.html?tag=nefd_top
l8r, Mike N. Christoff
Had it been running Microsoft .NET, the payload would be heavier due to more
memory needed to run Windows, the cost higher due to licensing fees NASA
would have to pay Bill Gates/Microsoft, and by now would be sending back the
"blue screen of death" instead of the martian surface!
"Ken Larson" <kendot...@mindspring.com> wrote in message
news:bu9t0o$ukg$00$1...@news.t-online.com...
If you want more info on VxWorks, see the web site: www.windriver.com
The VxWorks RTOS also ran the Mars Lander and is in many other active
NASA probes like Stardust.
--mitch
I was thinking, NASA could run some servers which will present Spirit's 3D
visualization. They could use Java3D in some applet so anybody interested
could navigate path that Spirit has traveled. It will be nice to see that.
How many cameras Spirit has anyway?
I was also thinking why all robots or searchers have wheels, I mean if they
are doing some research on land ok than, but it will be easier to use some
flying robot like small helicopter or something for making map. It will have
its platform with solar panels, it can go faster and I think travel lot more
distance. The platform can have wheels so it can move. The helicopter can be
useful to analyze around the platform and navigate platform. Let's say Sprit
and small robo-copter will be ideal combination. It's just suggestion.
At the end flying robots will depend on Mars's atmosphere, right?
"mitch" <realtime@-no-spam-acm.org> wrote in message
news:100hlno...@corp.supernews.com...
Err, I read him as saying Java is /not/ on Mars today.
-- Dave Harris, Nottingham, UK
You give it too much credit!
> I was also thinking why all robots or searchers have wheels, I mean if they
> are doing some research on land ok than, but it will be easier to use some
> flying robot like small helicopter or something for making map. It will have
> its platform with solar panels, it can go faster and I think travel lot more
> distance. The platform can have wheels so it can move. The helicopter can be
> useful to analyze around the platform and navigate platform. Let's say Sprit
> and small robo-copter will be ideal combination. It's just suggestion.
[snip]
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.
--
Uncle Al
http://www.mazepath.com/uncleal/
(Toxic URL! Unsafe for children and most mammals)
"Quis custodiet ipsos custodes?" The Net!
Why mention oxygen specifically?
The solar panels mentioned would have no
problem with the complete absence of oxygen.
..Though a battery powered chopper would
still be little more effective than one that
uses internal combustion.
And getting back to the original
thrust of this thread.
No, even if it were possible to make
a craft that could fly in Mars' atmosphere,
that would not be controlled by Java either
as it would violate Sun's license.
[ Why the heck was this cross-posted to
sci.physics? Some of the other groups are
borderline, but that one's off the wall.. ]
--
Andrew Thompson
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site
>We can say that Java is most useful language on Mars today :))) You know,
>the time of .NET is coming while Java has already took its place in
>history. Nothing can change that, Java is simply great thing!
Java is the worst thing that could happen to computing since the
invention of the chuwing gum hard disk.
It is slow, slow, slow, slow, SLOW, and not to mention slow.
And on top of that it is slow.
>dalib...@fer.hr (Dalibor Hrg) wrote (abridged):
>> We can say that Java is most useful language on Mars today :)))
>
>Err, I read him as saying Java is /not/ on Mars today.
Correct, and the fact that we already have pics proves that.
Is the java License valid in other planets? :-)
(cross-posting trimmed to only moderately insane).
--
A. G. McDowell
You know, believe it or not, Java isn't all that slow. Here are a
couple of tests comparing different languages for very simple
algorithms:
http://www.bagley.org/~doug/shootout/index2.shtml
http://osnews.com/story.php?news_id=5602
While these simple tests might not hit on some of the weaknesses of a
JIT language like Java, they do tend to indicate that the performance
for most tests isn't all that bad.
That being said, the fact remains that Java is NOT being used on Mars
today. The Java stuff the original article talked about was all
earth-based stuff. In fact, it wasn't even the thing that was getting
the data from the Mars rover, simply the component that let people
view the data after it had been received.
The code on the rover wasn't specified, but it's most likely C/C++ as
that is the primary development language for Wind River VxWorks. I'm
not even sure if that OS has Java support, though even if it did it
would be a BAD choice. Java is NOT designed with real-time operating
systems in mind. It's a fine language for what it is, but it's not
really a suitable choice for this application. Ada might actually be
the best choice, as this is the sort of thing that language was
designed for, but C/C++ is a good alternative that is widely supported
and well known.
-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
>
> No, even if it were possible to make
> a craft that could fly in Mars' atmosphere,
> that would not be controlled by Java either
> as it would violate Sun's license.
Irrelevant. If you really do see Java in space, it won't be made by Sun.
http://www.aicas.com/press/pr_12_en_24-Oct-03.html
[sci.physics deleted from X-postings]
--
Chris Gray ch...@kiffer.eunet.be
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.
--mitch
----------------------------
http://amesnews.arc.nasa.gov/releases/2001/01_58AR.html
Michael Mewhinney Aug. 13, 2001
NASA Ames Research Center, Moffett Field, CA
Phone: 650-604-5026 or 604-9000
jbl...@mail.arc.nasa.gov or mmewh...@mail.arc.nasa.gov
RELEASE: 01-58AR
AMES COMPLETES SUCCESSFUL TEST OF MARS AIRPLANE PROTOTYPE
Soaring gracefully down to Earth from a balloon floating 101,000 feet high
above Oregon, a NASA prototype of an airplane that someday may fly over
Mars successfully completed a high-altitude flight test this week.
Conducted at Oregon's Tillamook airport by the Kitty Hawk 3 project at NASA
Ames Research Center, Moffett Field, CA, the test was designed to validate
the aerodynamic performance of the prototype. Nicknamed "Orville" after
one of the famed Wright brothers who first flew on Dec. 17, 1903, the NASA
731 glider was dropped from a helium-filled balloon that towed it up to an
altitude of 101,000 feet - the highest ever for such a test - before
releasing it. Engineers and scientists hailed the test as a great success.
"It was a great flight and everything went really well. It appears that we
realized all of our test objectives," exclaimed a jubilant Andy Gonzales,
an Ames aerospace engineer who served as the flight test director.
Low-altitude tests of NASA 729, another prototype called "Wilbur," were
conducted last month at Ames.
"Mars has always fascinated people," said Larry Lemke, an aerospace
engineer at NASA Ames who serves as Ames' project manager for advanced Mars
mobility concepts, which include airplanes as well as other systems.
"Every time we send a mission up there, we come back with fascinating
discoveries."
According to Lemke, a Mars airplane is an idea whose time has come. "The
Mars airplane is an idea that has been around for about 25 years, and over
the past five years or so, it has been growing in popularity," he said. "I
think a Mars airplane will play a role in exploring the Red Planet."
Conventional in appearance, the Mars airplane concept developed by Ames
engineers features a long, straight wing and twin tails in the rear. The
remote-controlled glider tested in Oregon featured an approximately
four-foot-long fuselage and an eight-foot wing span.
"The flying we have successfully completed in Oregon is very similar to the
flying that we will be doing over Mars during a productive exploration
mission," Lemke said. "One unique aspect of flying a Mars mission with an
airplane is that it must be constructed in a fold-up configuration in order
to fit inside a spacecraft."
In its future configuration for Mars, the aircraft is expected to have its
own propeller propulsion system capable of operating in the Mars
atmosphere, which is comprised mostly of carbon dioxide. It will also
carry a variety of sophisticated instruments to observe and conduct science
experiments.
"The possibility of life on Mars is a very hot topic and an interesting
question, so I'm sure you will find instruments on board that are designed
to find signs of water on Mars, which is necessary for life," Lemke said.
"In addition, we would have a large array of cameras on the airplane to be
able to see large areas of the Mars terrain in very high resolution," Lemke
said. He said the cameras aboard the aircraft would be so precise, they
could see objects on Mars as small as the size of a quarter. "I think the
images will be stunning," he said. "During a Mars airplane mission, we will
be able to view the planet at very close proximity and this will convey to
the public that there is a real planet there, not just an abstract."
"Our test flight at Tillamook airport showed the airplane's flight was very
smooth and stable which makes for a good platform for science instruments,"
said Gonzales.
Ames engineers predict the next few years will be challenging, as they
prepare for a potential mission to Mars. "We will be expanding the envelope
and developing a much more complex aircraft for exploring Mars," Lemke
said. The next step will be to develop a Mars airplane model with folding
wings and later, one with a propeller propulsion system.
-- end --
Note to Broadcasters: A video file related to this news release is
scheduled for distribution via satellite on NASA Television on August 14,
2001. Because feed times and the schedule are subject to change, please
check the NASA TV video file line-up on the web at
ftp://ftp.hq.nasa.gov/pub/pao/tv-advisory/nasa-tv.txt
NASA TV is available on GE-2, transponder 9C at 85 degrees west longitude,
with vertical polarization; frequency is on 3880.0 megahertz, with audio on
6.8 megahertz. For general questions about the video file, call NASA
Headquarters, Washington, DC: Fred Brown at 202/358-0713
> AMES COMPLETES SUCCESSFUL TEST OF MARS AIRPLANE PROTOTYPE
The empirical fact is that lowland Martian air pressure is 7-10 torr.
The is equivalent to 120,000-100,000 feet terrestrial altitude. If
the silly thing will be diddling at even 1000 ft altitude Martian, the
air will be thinner. I don't care if Hillary Ramrod Clinton left a
big warm wetspot on the chute prior to deployment. Stuff doesn't fly
that high - certainly absent oxygen in the intake.
"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.
> Soaring gracefully down to Earth from a balloon floating 101,000 feet high
> above Oregon, a NASA prototype of an airplane that someday may fly over
> Mars successfully completed a high-altitude flight test this week.
Yeah, right. They have an airfoil that works in vacuum. What is its
payload - one NASA decal? Learn the difference between Official Truth
and real world truth.
[snip]
--
Uncle Al
http://www.mazepath.com/uncleal/qz.pdf
http://www.mazepath.com/uncleal/eotvos.htm
(Do something naughty to physics)
[SNIP]
> The empirical fact is that lowland Martian air pressure is 7-10 torr.
> The is equivalent to 120,000-100,000 feet terrestrial altitude. If
> the silly thing will be diddling at even 1000 ft altitude Martian, the
According to that link they've tested it at over 100,000 ft
already. Cute idea, but I figure the air-ship type option
may be more robust and easier to deploy - plus if something
momentarily breaks it's less like to fall out of the sky.
Cheers,
Rupert
This topic was discussed recently on sci.space.tech.
One of the problems identified for heavier than..
atmosphere craft was the *runway length required
to take-off or land.
[ And to those that would jump in and suggest
keeping it aloft continuously, that is impractical
with sandstorms, ..even assuming you could squeeze
a 'little' RTG into it, and still get it off the ground. ]
Balloon, or better still, orbiter with a bloody
good telescope. No dust, no sand, no runways
to deal with and you can cover far more area.
* Well, of _course_ they would be using all
those really _long_ runways built on Mars
during WWII. ;-)
That is correct. However, standard Java is also not a good choice for cell
phones. You need Java Micro edition (J2ME) for this. On that note, there
is much work being done on developing a version of Java for real time
systems.
l8r, Mike N. Christoff
This was posted to sci.astro a week or 2 ago:
>from the rovers will be provided and can be loaded into the program.
>
>http://mars.telascience.org/home/
>
>"The Jet Propulsion Laboratory has released Maestro, a public version
>of the primary software tool used by NASA scientists to operate the
>Mars Exploration Rovers. Anyone can download Maestro for free from
>http://mars.telascience.org/ and use it to follow along with the
>rovers' progress during the mission. You can use Maestro to view
>pictures from Mars in 2D and 3D and create simplified rover activity
>plans. During the mission, updates will be released for Maestro
>containing the latest images from Mars."
Me replying:
OK I downloaded the Linux version last night (I am in Europe),
realizing after it turned out to be a 2 1/2 hour download on a V90 modem,
that I really must be confident that lander worked this time....
Anyways it is based on java rle, the install script has some errors,
so you can not run it as the indicated executable,
but I had to run it as (I untarred it in /video/compile/maestro/ )
/video/compile/maestro/R2004_01-Public-Linux/JPL/SAP/bin/WITS
while 'SAP', that should start it (in /usr/local/bin), points to
SAP -> /video/compile/maestro/R2004_01-Public-Linux/WITS
So directory JPL/bin is missing from the softlink in /usr/local/bin
Also the install script 'forgets' to do
tar -xvf mer.tar
in
/video/compile/maestro/R2004_01-Public-Linux/JPL/SAP/WITS-db
so that you actually see some data.
Because of java (likely) the thing is slower then a dead snail glued with
superglue to a scrapped Apollo.
I followed the intro to the point where it had to move to a target, then it
froze with this message in the console:
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x400C32F7
Function=memcpy+0x27
Library=/lib/libc.so.6
Current Java thread:
****************
Another exception has been detected while we were handling last error.
Dumping information about last error:
ERROR REPORT FILE = (N/A)
PC = 0x0x400c32f7
SIGNAL = 11
FUNCTION NAME = memcpy
OFFSET = 0x27
LIBRARY NAME = /lib/libc.so.6
Please check ERROR REPORT FILE for further information, if there is any.
Good bye.
So, 1.3 frames / second before it crashed, and this system plays live video
at normal speed no problem.
But THAT code is written in asm and C.
I remember the old vrml browsers (was there al the way from the beginning).
After some of these got ported to Java it was a factor 10 slower (at least).
And NO reason in the world to do that, portability of good C code is excellent.
Java is a mistake.
The AeroVironment Helios Prototype, for one:
http://www.aerovironment.com/area-aircraft/unmanned.html
> Martian aircraft are a bad dream.
No more than Mars sample return or numerous other challenging but
entirely feasible tasks.
Jon
__@/
Haven't tried it lately, have you ;-)
--
Al Balmer
Balmer Consulting
removebalmerc...@att.net
Bwa Ha HA Ha Ha Ha Ha HA.
Thanks for making me laugh at the end of a bad day :-)
--
-P
And that's why it's such an important step forward: it makes it possible for
people to realize that speed is not all that important when choosing
a programming language.
Now that we've taken this step, we can start to think about the next step:
focus on safety and correctness.
Stefan
Actually, speed is very often an important aspect. The question is,
speed of what? If you spent five days writing/debugging a program in
C++ that could be written in two hours in LISP (for example), and the
program is only going to be used for a single experiment or set of
experiments, than most likely the improvement in performance that you
got by writing it in C++ is offset by the time spent writing/debugging
it. Obviously, as been said several times, it depends on what the
language is being used for. If the software is for security-critical
uses, C++ is probably a bad choice. If the software is for cracking a
particular encryption algorithm, C might be a very good choice. (Of
course, assembly might be even better!)
---------------------------------------------------------------------
| "Good and evil both increase at compound
Ben Hocking, Grad Student | interest. That is why the little
hoc...@cs.virginia.edu | decisions you and I make every day are of
| such infinite importance." - C. S. Lewis
---------------------------------------------------------------------
Oh yes I did, but nervous Jave people start spamming my email
that I really *should not mention Java is slow*, well, read my other post
in this tread.
And THAT was written by NASA.
Penty of stuff around to show it, get real.
>
>--
>Al Balmer
>Balmer Consulting
mmm
Solutions of Yesterday already NOW on your desktop with JAVA (snailmark).
Sorry
How safe is a car that cannot accelerate (when needed).
How correct is a solution that runs 10x slower then other ones.
(like web browser).
What does it give us, so you cannot program with pointers, so
you do not want to learn that, so you use java.
Popups, webcrap...
Or use 10 x power for the same final speed, efficient?
Java is as safe as the one who programs with it.
If you forget (because you think it is so safe) about any security issues,
then your eventual lack of knowledge about these issues will break
your code security.
I cannot really think of one useful application of Java except
burning it.
It is like BASIC, except slower, and less used.
Hey I am not just pestering, it is TRUE.
NOTHING is slower then java.
Why don't you go and learn about programming languages (and their history)?
Stefan
> Why mention oxygen specifically?
> The solar panels mentioned would have no
> problem with the complete absence of oxygen.
>
My dear friend, planes need atmosphere not only for combustion but
also for generating the required lift by its wings or copter blades or
whatever. A rarefied atmosphere would not be able to generate enough
lift at a decent velocity like on earth. of course by increasing the
velocity several times we can generate some lift, but that would be a
totally wasteful use of energy.
Besides to keep a copter in the air it woulf consume a great deal of
energy which could be otherwise utilised for some other purpose.
> ..Though a battery powered chopper would
> still be little more effective than one that
> uses internal combustion.
>
again battery power does not solve the probelm of generating enough
lift in a rarefied atmosphere.
regards,
Seemanta Dutta
So he is right: oxygen does not, specifically, matter.
> A rarefied atmosphere would not be able to generate enough
> lift at a decent velocity like on earth. of course by increasing the
> velocity several times we can generate some lift, but that would be a
> totally wasteful use of energy.
Don't forget that the necessary lift is *also* much lower on Mars
since it has only one tenth the mass!
Mati Meron | "When you argue with a fool,
me...@cars.uchicago.edu | chances are he is doing just the same"
comp.arch
comp.distributed
comp.lang.java
comp.lang.java.programmer
comp.object
comp.programming
comp.theory
sci.physics
I'm all for serendipity and all that, and I've learned all sorts
of things from off-topic threads, but I think the OP's claim (and
hence the official subject of the thread) was shot down with the
first or second reply and we've given aircraft and Java advocacy
a good run now.
I think most people have that impression either by playing with Java 1.0
(or listening to those who have), or by using Swing applications.
Newer Java versions and graphical applications using ie. SWT perform
the same as native C/Fortran applications. In fact, the new Hotspot
optimizer in 1.4 is quite good at numerical codes too. For some large
scale computations, my Java codes perform identical to Fortran codes,
with the added benefits of readability and maintainability, not to
mention trivial cross-platform deployment (from my desktop to the local
supercomputer, with excellent scalability).
I might add that Java w/Hotspot quite often outperforms vanilla C
codes, it's only when adding lots of optimization flags to the compiler
that the performance gap closes.
--
Bjørn-Ove Heimsund
Centre for Integrated Petroleum Research
University of Bergen, Norway
While that is likely true, ...
> For some large
> scale computations, my Java codes perform identical to Fortran codes,
Really? Even if you compile with optimization?
> with the added benefits of readability and maintainability, not to
> mention trivial cross-platform deployment (from my desktop to the local
> supercomputer, with excellent scalability).
I consider a reasonably well-written F95 program to be very maintainable
and more portable than Java - if only for the fact that there's only one
F95 standard all compilers are written to, while there are several
incompatible (in various ways) Java "standards" around, not to mention
the different thread semantics of different implementations.
> I might add that Java w/Hotspot quite often outperforms vanilla C
> codes, it's only when adding lots of optimization flags to the compiler
> that the performance gap closes.
For any modern compiler of a 3GL language, not compiling with (the equivalent
of) -fast is grossly negligent.
Jan
Yes, but I might add that the things I do are not easily vectorizable
(sparse matrix calculations). For dense array computations, a good
compiler can do fancy unrolling tricks and other things which is not
(yet) available in Java nor in Hotspot.
>> with the added benefits of readability and maintainability, not to
>> mention trivial cross-platform deployment (from my desktop to the local
>> supercomputer, with excellent scalability).
>
> I consider a reasonably well-written F95 program to be very maintainable
> and more portable than Java - if only for the fact that there's only one
> F95 standard all compilers are written to, while there are several
It's very easy to create unmaintainable code in any language, Java is no
exception. It's just that Java doesn't have a 40 year legacy baggage,
and encourages good design practices. Java seems to be well recieved
in some computer science institutes as well, especially as an
introduction to OO programming.
On the portability side, I have had issues porting some F95 codes
between compilers, both of which had different ideas how the standard
were to be interpreted (and the compilers were quite new too). F77
compiles nicely, though.
> incompatible (in various ways) Java "standards" around, not to mention
> the different thread semantics of different implementations.
Since Java 1.2, I have yet to encounter any issues with thread
implementations, be it on AIX, Solaris, Linux or Windows. There are
of course some more issues relating to thread local storage and
caching, but the semantics of this is being worked out (for Java 1.5)
>> I might add that Java w/Hotspot quite often outperforms vanilla C
>> codes, it's only when adding lots of optimization flags to the compiler
>> that the performance gap closes.
>
> For any modern compiler of a 3GL language, not compiling with (the equivalent
> of) -fast is grossly negligent.
Agreed. But many folks around here run their codes compiled with
"f77 -g" (not that I do that, of course :-)
In unmoderated groups, threads don't have "official" subjects, and
thread drift will be with us forever. Messages do have topicality,
however, and the comparison and qualification of programming
languages, and specifically Java, would seem to be topical in at least
two of the above groups. I will volunteer to trim the cross-post list,
however.
As for your question, yes. Topicality is always on-topic.
> of course by increasing the velocity several times we can generate
> some lift, but that would be a totally wasteful use of energy.
One can also increase wing area. This is, e.g., why 747s can land
so amazingly slowly for such a big bird.
--
|_ CJSonnack <Ch...@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|_______________________|
Seems like Java may well be used on the actual rover in the future:
Jim Sculley wrote:
<quote>
In any event this entire discussion has ignored the Realtime
Specification for Java, implementations of which are being used in
mission critical apps, such as control systems for a future Mars rover:
http://www.opengroup.org/rtforum/uploads/40/2930/OpenGroup_Golden_Gate_May01
-v05.pdf
Jim S.
</quote>
l8r, Mike N. Christoff
> For any modern compiler of a 3GL language, not compiling with (the equivalent
> of) -fast is grossly negligent.
A few years ago, I was asked to help with improving the performance of
a major production code here. The author of the code didn't even
know how to turn on the optimizer. I mean turning on the optimizer
at all, even with a simple -O, much less experimenting with the other
settings. I was a bit shocked that they felt the need to call for
help and hadn't even tried that. This was from a supposedly
professional full-time programmer and was in a code that had gone
through all the formal development process (for what little that
was actually worth :-() and was in production use.
But then, I found plenty of other problems also. I suppose it
figures. :-(
It was a Fortran code, but the major problems didn't have much to
do with the language. If you are sufficiently clueless, you can
manage to express that cluelessness in any language.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
I think this is a quote worthy of a .sig file. (I'm assuming this is a
Richard Maine original?)
Flaps and slats (particularly on large aircraft) make a huge difference.
This is somewhat interesting, although the animation is fairly weak.
http://www.grc.nasa.gov/WWW/K-12/airplane/flap.html
[quote]
During takeoff and landing the airplane's velocity is relatively low.
To keep the lift high (to avoid objects on the ground!), airplane designers
try to increase the wing area and change the airfoil shape by putting some
moving parts on the wings' leading and trailing edges. The part on the leading
edge is called a slat, while the part on the trailing edge is called a flap.
The flaps and slats move along metal tracks built into the wings. Moving the
flaps aft (toward the tail) and the slats forward increases the wing area.
Pivoting the leading edge of the slat and the trailing edge of the flap
downward increases the effective camber of the airfoil, which increases the
lift. In addition, the large aft-projected area of the flap increases the drag
of the aircraft. This helps the airplane slow down for landing.
[/quote]
--
Randy Howard
2reply remove FOOBAR
>> One can also increase wing area. This is, e.g., why 747s can land
>> so amazingly slowly for such a big bird.
>
> Flaps and slats (particularly on large aircraft) make a huge
> difference.
One reason they make a diff on large aircraft is the proportional
difference in increasing the wing area of an already large wing.
Keep in mind that ALL aircraft land with flaps. 747s are slower
because their wings are bigger to begin with.
> [quote]
> ...To keep the lift high (to avoid objects on the ground!), airplane
> designers try to increase the wing area and change the airfoil shape
> ...
Yep. Airfoil shape is another mechanism. High camber affects
performance, so isn't used other than at slow speeds (IIUC).
Compare this to fighter jets with itty bitty razor-sharp wings.
Those babies need serious speed to fly at all!
> Richard Maine <nos...@see.signature> writes:
>
>>If you are sufficiently clueless, you can manage to express that
>>cluelessness in any language.
> I think this is a quote worthy of a .sig file. (I'm assuming this is a
> Richard Maine original?)
It bears a relation to "Real Programmers can write Fortran in any
language", but I hesitate to call it a "corollary".
[ dodges ]
--
Toon Moene - mailto:to...@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)
Mike, I have no facts to support this, but my guess is that that the
PR blurb you post is little more than a bit of marketing spin whose
quotes are being read out of context by a few Java enthusiasts.
First of all, obviously Java is not an operating system. It's an
application programming language or tool targeted to the production of
Internet (particularly browser applications). You also cannot
implement a true operating system using Java as your programming
language. If you doubt this, I'll hand you an 80586 chip with 128-Megs
of online memory and chuckle as you try!)
Java is absolutely useless except when running on a platform already
equipped with an operating system, and many layers of data
communications and application programs, where the top levels include
an operating TCP/IP stack and browser software.
Almost certainly the OS within the rover is a highly optimized
real-time kernel likely programmed in assembler, C, C++ or some other
system implementation langage. (Perhaps even Ada, although that would
be a long-shot.) Java is certainly not a member of this tight-knit
club of system implementation languages, and I simply cannot picture
anyone even attempting to implement a real-time OS using it. Java is
not running the Rover, its real-time operating system is.
My guess is that when you get details of the facts supporting this PR
release, you'll learn that certain Java apps form a portion of the
man-machine interface design employed for the entry of command
sequences here on earth, since Java is capable of simpllifying the
design of this type of software over what could otherwise be
programmed using xlib, C, C++ or even (gasp) assembly language, since
the programming of a control entry MMI is today not exactly rocket
science (no pun intended). (Heck, you could probably even use Visual
Basic for the purpose, if really desperate! Back in the early days of
surveilance satellites, we even programmed the ground based command
interpreters for the K-series birds using Fortran, and they were both
trivial to program and functioned perfectly.)
Also, at last count the foundations of the Internet rested heavily on
C/C++/Assembler implementations running on Unix platforms, however
this may or may not have changed over the years. (At last count, the
thousands of different routines supporting operation of the Internet
involved the use of nearly as many different programming tools...since
so long as they all result in the production of really tight, robust,
executable machine code, the choice of programming language really
doesn't matter.)
When a firm intentionally confuses application programming tools such
as Java with real-time OS implementation methodoloy, in my mind they
both risk and deserve justifiable ridicule. I don't believe that Sun
intended to create such confusion in their publicity release, however
a few Java enthusiasts do seem bent on misrepresentation of Java's
capabilities, potentially at Sun's credibility expense.
Harry C.
Now that I can believe! :-)
I'm still supporting embedded 8051 packages running on the original
Franklin RTOS, nearly all embedded control systems using the Intel
80X86 family now run VxWorks, with the exception of the 80186. Wind
River is certainly doing something right.
Their VxWorks RTOS package is really slick...I know this because I was
once comissioned to write a RTOS OS for the 80186 similar to VxWorks
(which doesn't support the 80186 in order to provide support for a
legacy PLC controller design. Sadly, the firm quickly lost interest
and cancelled the funding 3-months into the project, just when I was
begining to become really good at rewriting VxWorks 80386 OS code into
80186 code! :-)
I never found out if the mission was scrubbed because of an internal
marketing decision, or because Wind River and its attorneys got wind
(no pun inteded) of the project.
What do/did you think of "Tornado"? Seemed to me that it was equally
as bad as "Starteam", and the neither of these two CM systems came
close to equaling the features provided by the old Unix PWB (for you
newbies, PWB "Programmers Workbench", arguably the original software
configuration management tool).
Harry C.
If he was dealing with embedded software, the original designer may
have had good reason not to turn on the optimizer.
In embedded software, we frequently write to memory addresses that are
in turn mapped to hardware control registers. Early optimizer design
was frequently done by software folk not familiar with this practices,
often optimizing out writes to address that they didn't see being
later read.
IIRC, Microsoft's "MASM" was an assembler whose optimization exhibited
this defect. Today, no many people use MASM, so I don't know if the
flaw was ever corrected. As a result, many embedded software/firmware
designers today still operate with the optimizer turned off for
"safety", and prefer to optimize their own code.
Franklin's 8051 development suite initially exhibied the same problem,
but given that their target market was entired embedded software
designers, the problem was corrected by the 2nd release of the
product.
> It was a Fortran code, but the major problems didn't have much to
> do with the language. If you are sufficiently clueless, you can
> manage to express that cluelessness in any language.
Amen to that statement, and suggest that it be etched it in stone.
A skilled programmer can even write in GWBASIC and produce fantastic
results through the clever use of (IIRC) PUT and POKE commands, which
allow the insertion of machine language instructions in the GWBASIC or
the Atari BASIC command stream. (I wonder how many of today's
programmers would be resouceful enough to use of such extreme
techniques to achieve their goals? Heck, for that matter how many have
ever even directly used machine code?)
Harry C.
>"Michael N. Christoff" <mchri...@sympatico.caREMOVETHIS> wrote in message news:<ZCZNb.8151$c1.10...@news20.bellglobal.com>...
>> Java, the software developed by Sun Microsystems in the mid-1990s as a
>> 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.
>>
>> http://news.com.com/2100-1007_3-5142220.html?tag=nefd_top
>
>
>Mike, I have no facts to support this, but my guess is that that the
>PR blurb you post is little more than a bit of marketing spin whose
>quotes are being read out of context by a few Java enthusiasts.
>
You're about four days late with this observation ;-) Folks who
actually read the referenced article, "Java runs remote-controlled
Mars rover", learned that while a Java program "runs" a simulated
rover, here on earth, and is a very useful tool for mission planning,
it does not run *on* the rover, or directly control it. Read the
article.
You can get the software at http://mars.telascience.org/
>A skilled programmer can even write in GWBASIC and produce fantastic
>results through the clever use of (IIRC) PUT and POKE commands, which
>allow the insertion of machine language instructions in the GWBASIC or
>the Atari BASIC command stream. (I wonder how many of today's
>programmers would be resouceful enough to use of such extreme
>techniques to achieve their goals?
Programmers tend to be as resourceful as necessary, to the detriment
of the remainder of the code's life cycle.. Fortunately, such
techniques are usually not necessary on today's programming platforms.
Unfortunately, some programmers use them anyway.
> Heck, for that matter how many have
>ever even directly used machine code?)
Rarely needed, even in my day. Assembler language is much preferable,
and lots of people still use it. Direct use of machine code is (was)
sometimes useful for debugging and patching.
That's simply not true. Not only do some airplane designs simply not
have flaps, but accomplished pilots practice flapless landings in
case of a system failure.
Numerous early Piper aircraft had no flaps at all, and flew very
well. Same is true for quite a few other designs.
Even exotic special purpose modern aircraft, such as the Extra 300
series have no flaps.
a) the article never said that Java was on the rover itself. b) Java is
more than a language, it is a platform. c) the fact that Java needs an
underlying OS has never been disputed by anyone. The idea is for Java to be
portable to other _already developed_ platforms. It would not be very
portable if you had to dual boot into a Java OS to run Java apps. d) There
is no reason to believe a real time system cannot be virtual machine based.
It is technicaly feasible and all the benefits of seperating code from
hardware/OS are just as relevant on embedded systems as they are on
desktops. Just look at cell phones. (note: many many people laughed at the
idea that something as small as a cell-phone could run any VM-based
language. Java on top of VM on top of embedded OS seemed way too bulky to
ever be practical. But Moore's law apparently does not apply only to
desktops, but even embedded devices). Will a real-time Java have all the
features of regular Java? Doubtful. ie: automatic garbage collection may
not be possible.
l8r, Mike N. Christoff
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.
I posted this already in another thread.
> You also cannot
> implement a true operating system using Java as your programming
> language. If you doubt this, I'll hand you an 80586 chip with 128-Megs
> of online memory and chuckle as you try!)
Send them over. I could do with the chip (and the RAM). Feel free to
chuckle, whilst I fetch my screwdriver. :-)
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
..which is the correct thing to do, IMO. If you want such dead stores or
loads to happen in any case, you need to tell the compiler the changed
semantics of that value in any case. In fact, on a modern processor, even
if the compiler did not optimize the memory operation away, it is quite
likely it wouldn't happen at all or in time.
Crippling the optimizer is the wrong solution to this problem.
Jan
Or, indeed, some smart cards (for instance, from GEMplus or axalto).
Their advantage is that you need to certify the JVM only once as to its
sandbox guarantees, and can then put new applications on the card and
certify them without regard to what else is running on the card, while the
current practice would require a re-certification of all the software on
the card as a whole. Megabucks saved.
Jan
Jan wrote:
) ..which is the correct thing to do, IMO. If you want such dead stores or
) loads to happen in any case, you need to tell the compiler the changed
) semantics of that value in any case. In fact, on a modern processor, even
) if the compiler did not optimize the memory operation away, it is quite
) likely it wouldn't happen at all or in time.
)
) Crippling the optimizer is the wrong solution to this problem.
Correct me if I'm wrong, but isn't it true that most compilers have some
kind of flag (like volatile) to indicate that such writes are not to be
optimized away ? And if not, that would be the way to go, wouldn't it ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
This means that NASA can re-license the code to run forklifts, golf
carts,wheelchairs, or any conveyance that could have its own on board
JVM.
Just think of how all that extra licensing revenue will enable us to meet
the President's goal of landing the Democratic candidate for President on
the moon before the election and returning him within four years. More or
less.
Unless the rover was developed under the GPL?
</reply>
Actually, academic debate aside, the success of the rover so far is a
welcome shot in the arm for the space program, especially after the
shuttle tragedy and previous Mars mission failures. In the cold harsh
light of the pragmatic dawn, if the rover works to spec, then using java
was a good decision, if not, then it was a poor decision. To quote the
scribe: all else is commentary.
--
.................................................
99 percent of lawyers give the rest a bad name.
Rod Davison - Critical Knowledge Systems Inc.
A logical conclusion from this statement is that you can't write a "true"
(wonder what that means?) operating system in Lisp. Oops. Symbolics.
Hint: when you're doing that, you add a few well chosen extensions which
you use in the appropriate places.
--
David Gay
dg...@acm.org
Sorry Jan, I couldn't locate the original source of the text you
quoted and to which I am responding.
> > d) There is no reason to believe a real time system cannot be virtual
> > machine based. It is technicaly feasible and all the benefits of seperating
> > code from hardware/OS are just as relevant on embedded systems as they are
> > on desktops. Just look at cell phones.
I believe that accuracy of this statement depends entirely on the
degree of reaction latency that can be tollerated in the real time
system. Even at today's fantastic execution rates, critical real-time
must occur within only a few machine execution cycles.
The execution latency penalty imposed by my concept of a virtual
machine will, at least in my mind, knock it from consideration for
anything approaching that which is normally required for critical
real-time performance. Here often anything greater than a few
processor instruction cycle latency leads to a non-recoverable error
situation.
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.
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. Couple this with the fact that in most
real-time control and operating systems, these latency requirements
are often only a few microseconds and the need for very tightly coded
software becomes obvious.
For an example of real-time OS design, compare the kernel
implementation in something like Wind River's VxWorks RTOS vs. that of
a non-real-time OS such as early Unix or Microsoft Windows.
Particularly note the fact the the task scheduler in a real-time OS of
any reasonable complexity will be both dynamic priority weighted and
perform pre-emptive scheduling because you can't have a slow process
(like I/O) hogging the system and locking out tasks that need to
execute in milliseconds or microseconds.
The above and other considerations in real-time are what cause me to
believe that the utility of a virtual machine so very unrealistic for
RTOS use.
Harry C.
If you're interested into getting to the bottom of this, I'd suggest you
peruse the real time specification for java. That and other related
information can be found here.
I'm sure it could address your questions better than I ever could. I'd be
interested to hear your comments.
l8r, Mike N. Christoff
"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher."
http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm
l8r, Mike N. Christoff
Are they sure it's not just Sun's JVM taking a break to do a GC?
--
Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
If they were using standard Java (ie: not a real-time version) that would
not be beyond the realm of possibility. Hopefully its something just as
recoverable. (Note: I'm pretty certain Java is not actually running on
the rover itself).
l8r, Mike N. Christoff
Unless, of course, the software was written
in something like C++ (as has been suggested[?],
and is more likely).
In that case, would it be more likely caused by,
"dangling pointers to objects in deleted heaps"
perhaps? ;-)
--
Andrew Thompson
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site
NASA is renowned for its antenna failures - the Hubble space
telescope, Ulysses at Jupiter, and now their little radio-controlled
go-cart on Mars.
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.
--
Uncle Al
http://www.mazepath.com/uncleal/
(Toxic URL! Unsafe for children and most mammals)
"Quis custodiet ipsos custodes?" The Net!
> "Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
> news:10748119...@news-1.nethere.net...
> | Are they sure it's not just Sun's JVM taking a break to do a GC?
>
> Unless, of course, the software was written
> in something like C++ (as has been suggested[?],
> and is more likely).
There are go-to-lunch slow garbage collectors for C++ too, such as
the "managed C++" abomination Microslop is trying to shove through
the ECMA. Apparently nothing is safe from the "embrace and extend"
standards pollution and proprietarization strategy.
> In that case, would it be more likely caused by,
> "dangling pointers to objects in deleted heaps"
> perhaps? ;-)
That can happen when some chimp-coder can't quite comprehend RAII.
Another common fudgeup is to throw an exception from a destructor.
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. ;-)
"Andrew Thompson" <andr...@bigNOSPAMpond.com> wrote in message news:<TVYPb.23987$Wa.1...@news-server.bigpond.net.au>...
> I think they should turn it off and turn it on again.
They need to reinstall Winblows...
--
Joe Foster <mailto:jlfoster%40znet.com> Sacrament R2-45 <http://www.xenu.net/>
Or perhaps more to the point, not using Java was a good decision!
hint: in case you missed it, the rover doesn't use any Java code, the
Java is all for manipulating the data received back from the Rover.
-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
> "This is a serious problem. This is an extremely serious anomaly," said Pete
> Theisinger Spirit project manager.
> "There is no single fault that explains all the observables."
>
> "...but Spirit was only transmitting "pseudo-noise", a random series of
> zeroes and ones in binary code and not anything the scientists could
> decipher."
"This behavior is by design."
--
Joe Foster <mailto:jlfoster%40znet.com> Got Thetans? <http://www.xenu.net/>
The rover was programmed with Visual Basic 6.0, but Windows Update
zapped the MSVBVM60.DLL run-time. Obviously, all VB applications
should already have been trashed, redesigned, and rewritten in .NyET!
--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/>
Maybe they should have used java....
Run the system through junit...
Engineers struggled to diagnose what was wrong with the rover. Among the
possible causes: a corruption of its software or computer memory.
Spirit is one-half of an $820 million mission. Its twin, Opportunity, is
expected to land on Mars late Saturday. The twin rovers are supposed to
examine the Red Planet's dry rocks and soil for evidence that it was
once wetter and more hospitable to life.
java.lang.RoverException(line: 10,345)
Dope?
> 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
or WhimClose
you write it wrong:
MicrobaStard is right!
--
____________
http://reader.imagero.com the best java image reader.
>> Keep in mind that ALL aircraft land with flaps.
>
> 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.
--
|_ CJSonnack <Ch...@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|_______________________|
>"Michael N. Christoff" wrote:
>>
>> "This is a serious problem. This is an extremely serious anomaly," said Pete
>> Theisinger Spirit project manager.
>> "There is no single fault that explains all the observables."
>>
>> "...but Spirit was only transmitting "pseudo-noise", a random series of
>> zeroes and ones in binary code and not anything the scientists could
>> decipher."
>>
>> http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm
>
>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 ;-)
--
Al Balmer
Balmer Consulting
removebalmerc...@att.net
LOL! Yep, that fits ;-)
NASA Makes Contact With Mars Rover
http://news4colorado.com/nationworld/topstories_story_023135646.html
l8r, Mike N. Christoff
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
> > 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."
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.
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. :-)
--
Randy Howard
2reply remove FOOBAR
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
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
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - System Architecture Design CASE Tool
There is no life on Mars. They all live inside.
>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>
So that is what happened to the Morelocks.
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?
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
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."
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...
> 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.
...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.
> 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.
...which is very difficult to evaluate on a modern processor in any case.
Jan
HST didn't and doesn't have antenna problems.
> Ulysses at Jupiter
That one is going 'round the sun, and has had no problems of the sort.
> and now their little radio-controlled go-cart on Mars.
...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
>NASA is renowned for its antenna failures - the Hubble space
>telescope, Ulysses at Jupiter, and now their little radio-controlled
>go-cart on Mars.
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.
It sure as Hell did. When they got it up there NASA discovered that
the high gain antenna feed cable intersected space swept out by the
high gain antenna. The technical term for this is "pookie pookie."
> > Ulysses at Jupiter
>
> That one is going 'round the sun, and has had no problems of the sort.
The Jupiter orbiter could never deploy its high gain antenna. While
NASA spurted all over the Media for years, data was being received at
a rate recalling Radio Shack computers and their modems. Only a very
small fraction of the collected data was ever relayed. What a
successful mission.
> > and now their little radio-controlled go-cart on Mars.
>
> ...which isn't having an antenna problem, either.
No. It turns out $240 million won't custom-build a NASA FlashRAM card
as good as one can purchase at Radio Shack. That's no surprise. $1
billion could not grind and polish a NASA version of a Keyhole spy
satellite main optic available off the shelf. In pure NASA Korporate
Kulture tradition, the old fart optician who screamed about the
Hubble's mirrror blank being rough ground to the wrong spec was fired
very early on. It cost another $billion to fix it in orbit.
FOR THE EMPIRICALPRICE OF FINALLY DOING HUBBLE CORRECTLY, NASA COULD
HAVE BUILT AND ORBITED NEARLY THREE OF THEM USING KEYHOLE SATELLITE
OFF THE SHELF PLANS AND PARTS.
[snip]
Taking a picture of Martian dirt is not a major triumph. We already
have surface meterological and chemical data. Unless a nice block of
limestone turns up, with included fossils, this has been a huge and
hugely expensive bullshit party. How many Enron ex-executives are
working at NASA?
--
Uncle Al
http://www.mazepath.com/uncleal/
(Toxic URL! Unsafe for children and most mammals)
"Quis custodiet ipsos custodes?" The Net!
NASA shouldn't be getting a "black eye" for such failures, people
should be saying "good try, when are you going to make another
attempt at solving such a difficult problem". Stop and think
for a minute about how effective you would be at debugging your
project if the link between your development machine and the
system under test was on another planet and the delay between
inputs commensurately slow. Have fun. How would you debug
hardware problems remotely if you could not have any physical
contact with the machine? EVER AGAIN?
> NASA has had it's up's and downs.
Modulo the apostrophes, that's great tee-shirt material.
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Don't be silly, have you ever tried
to purchase bread on Mars?
Even if you can find a baker, it's
stale by the time you're Earthside. [ ;-) ]
| ..How would you debug
| hardware problems remotely if you could not have any physical
| contact with the machine? EVER AGAIN?
Assuming you can get it to obey _any_
commands.
a) Orient front of rover toward big rock.
b) Drive to 3 metres distant from rock, stop.
c) Drive forward 4 metres.
d) Back up 3 metres.
e) Repeat c), d) until problem fixed or rover destroyed.
Easy peasy.
You folks just do not think laterally. ;-)
--
Andrew Thompson
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site
While I hesitate to bash NASA (I do think they're doing very important
work, and I worked there myself for seven years), I regrettably prolong
a thread which has been OT from its inception with this excerpt from a
recent news article:
"[Mission manager Jennifer] Trosper said the problem appeared to be that
the rover's flash memory couldn't handle the number of files it was
storing. ... She pointed out that the scientists had thoroughly tested
the rover's systems on Earth, but that the longest trial for the file
system was nine days, half of the 18 days Spirit operated before running
into the problem."
http://www.cnn.com/2004/TECH/space/01/26/mars.rovers/
"Thoroughly tested"? If you're going to send any object, and especially
an object with a computer and software, to a distant planet where it is
supposed to survive for about 90 days, wouldn't it seem prudent to run
at least a 90 day test of the object on earth before liftoff?
-- Dave
> "[Mission manager Jennifer] Trosper said the problem appeared to be that
> the rover's flash memory couldn't handle the number of files it was
> storing. ...
It seems the Spirit is willing, but the flash is weak...
--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/index.cfm?action=book&bookid=228>