 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2005Mars Rover Controlled By Java
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 l8r, Mike N. Christoff > Java, the software developed by Sun Microsystems in the mid-1990s as a > universal operating system for Internet applications, gave NASA a low-cost [quoted text clipped - 4 lines] > > l8r, Mike N. Christoff The software on earth is in java, but is the software running on the thing itself java? Thats' correct. Look at http://www.cnn.com/2004/TECH/space/01/16/space.mars.java.reut/index.html 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! > > Java, the software developed by Sun Microsystems in the mid-1990s as a > > universal operating system for Internet applications, gave NASA a low-cost [quoted text clipped - 7 lines] > The software on earth is in java, but is the software running on the > thing itself java? Read the article carefully. Java is being used to create 3D views of terrain, and for command and control functions, ON EARTH. The last paragraph correctly states that Wind River Systems made the embedded software in the Spirit and Opportunity rovers. They run applications created by JPL which execute on the VxWorks real-time operating system (RTOS). I know this because a little of my work is in that RTOS - I worked for Wind River until recently. 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 > Thats' correct. Look at > http://www.cnn.com/2004/TECH/space/01/16/space.mars.java.reut/index.html [quoted text clipped - 17 lines] >>The software on earth is in java, but is the software running on the >>thing itself java? 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! 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? > Read the article carefully. Java is being used to create 3D views of > terrain, and for command and control functions, ON EARTH. The last [quoted text clipped - 32 lines] > >>The software on earth is in java, but is the software running on the > >>thing itself java? dalibor.hrg@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. -- Dave Harris, Nottingham, UK >dalibor.hrg@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. [snip] > 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 [quoted text clipped - 3 lines] > 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.  SignatureUncle Al http://www.mazepath.com/uncleal/ (Toxic URL! Unsafe for children and most mammals) "Quis custodiet ipsos custodes?" The Net! | [snip] ... | > 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. ... | 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? 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 > 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. Is the java License valid in other planets? :-) > 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] SignatureChris Gray chris@kiffer.eunet.be <snip> > 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 >>Why mention oxygen specifically? >>The solar panels mentioned would have no [quoted text clipped - 3 lines] > also for generating the required lift by its wings or copter blades or > whatever. 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! In article <bulei6$ipk4p$1@ID-161931.news.uni-berlin.de>, Michael Borgwardt <brazil@brazils-animeland.de> writes: >seemanta dutta wrote: >>>Why mention oxygen specifically? [quoted text clipped - 14 lines] >Don't forget that the necessary lift is *also* much lower on Mars >since it has only one tenth the mass! Well, the gravity is not proporitonal to mass alone. It's radius is smaller as well, so its gravity, on surface, is doen only by a factor of 2 or so. Its atmospheric density, on the other hand, is down by more than two orders of magnitude. So, the necessary lift is lower by much less than the available lift. Mati Meron | "When you argue with a fool, meron@cars.uchicago.edu | chances are he is doing just the same" > 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 <Chris@Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| > > 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. 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] SignatureRandy 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! |_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| > 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. 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. SignatureRandy Howard 2reply remove FOOBAR >> 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 <Chris@Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| >[snip] > [quoted text clipped - 10 lines] >torr. How many planes do you know that cruise at 100,000 feet absent >any oxygen at all? Martian aircraft are a bad dream. That's as maybe, but ESA (European Space Agency) are dreaming of putting Aerostats on Mars. I heard a talk from someone involved in this. See also http://users.aber.ac.uk/dpb/aerobots.html. From what I remember, they are balloons with fan motors. Much R&D will go into interpreting the pictures they take well enough to only send back the interesting bits. They illustrated the talk with a radio-controlled helium balloon they have been using to learn the practicalities. Don't know the programming language, but those involved have experience in Ada and Matlab. (cross-posting trimmed to only moderately insane). SignatureA. G. McDowell > 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. 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 jbluck@mail.arc.nasa.gov or mmewhinney@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 > > 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 [quoted text clipped - 3 lines] > just a bad dream? ;-) Work has begun on a propellered version of the > glider cited below. Enjoy. > 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 | [SNIP] | [quoted text clipped - 6 lines] | may be more robust and easier to deploy - plus if something | momentarily breaks it's less like to fall out of the sky. 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. ;-) -- Andrew Thompson * http://www.PhySci.org/ PhySci software suite * http://www.1point1C.org/ 1.1C - Superluminal! * http://www.AThompson.info/andrew/ personal site > > > 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 [quoted text clipped - 8 lines] > The empirical fact is that lowland Martian air pressure is 7-10 torr. > The is equivalent to 120,000-100,000 feet terrestrial altitude. Read the article: the glider was released at 101,000 feet. > If > the silly thing will be diddling at even 1000 ft altitude Martian, the > air will be thinner. Martian gravity is less, hence the pressure relative pressure difference between 0 and 1000 feet will be less than that on Earth: less than 5%. > "Ye canna break the laws of physics." > [quoted text clipped - 3 lines] > 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? This is all remarkably fascinating! Just one question: What does it have to do with Java? Thanks, Greg >>>>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 [quoted text clipped - 66 lines] > the test glider was carried to 101,000 ft? I suppose that was a > physical impossibility too? >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? 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 __@/ Uncle Al schrieb: > Local atmospheric pressure is 7-10 torr. Earth sea level is 760 > torr. 1 torr = 4/3 hPa (hekto Pascal), for those of us who are more familiar with the metric system. Carsten >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. >>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 [quoted text clipped - 3 lines] >It is slow, slow, slow, slow, SLOW, and not to mention slow. >And on top of that it is slow. 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 > >>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 [quoted text clipped - 27 lines] > would be a BAD choice. Java is NOT designed with real-time operating > systems in mind. 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 >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: OK, but my latest test on THAT java mars rover soft ran 1.3 frames / second on a 1 GHz PC. Before it crashed mind you. This was posted to sci.astro a week or 2 ago: >from the rovers will be provided and can be loaded into the program. > [quoted text clipped - 8 lines] >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 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 [quoted text clipped - 5 lines] > designed for, but C/C++ is a good alternative that is widely supported > and well known. 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 >>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 [quoted text clipped - 3 lines] >It is slow, slow, slow, slow, SLOW, and not to mention slow. >And on top of that it is slow. Haven't tried it lately, have you ;-) SignatureAl Balmer Balmer Consulting removebalmerconsultingthis@att.net | >>You know, | >>the time of .NET is coming Bwa Ha HA Ha Ha Ha Ha HA. Thanks for making me laugh at the end of a bad day :-) Signature-P >>>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 [quoted text clipped - 5 lines] > >Haven't tried it lately, have you ;-) 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. mmm Solutions of Yesterday already NOW on your desktop with JAVA (snailmark). Sorry Would it be *on-topic* to query the relevance of this to... 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. >Would it be *on-topic* to query the relevance of this to... > [quoted text clipped - 12 lines] >first or second reply and we've given aircraft and Java advocacy >a good run now. 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. SignatureAl Balmer Balmer Consulting removebalmerconsultingthis@att.net > 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. 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 > > Java is the worst thing that could happen to computing since the > > invention of the chuwing gum hard disk. [quoted text clipped - 7 lines] > Now that we've taken this step, we can start to think about the next step: > focus on safety and correctness. 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 hocking@cs.virginia.edu | decisions you and I make every day are of | such infinite importance." - C. S. Lewis --------------------------------------------------------------------- >> Java is the worst thing that could happen to computing since the >> invention of the chuwing gum hard disk. [quoted text clipped - 9 lines] > > Stefan 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. > How safe is a car that cannot accelerate (when needed). > How correct is a solution that runs 10x slower then other ones. [quoted text clipped - 3 lines] > Popups, webcrap... > Or use 10 x power for the same final speed, efficient? Why don't you go and learn about programming languages (and their history)? Stefan In comp.arch Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote: > 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. 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. SignatureBjørn-Ove Heimsund Centre for Integrated Petroleum Research University of Bergen, Norway > 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. 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 In comp.arch Jan C. Vorbrüggen <jvorbrueggen@mediasec.de> wrote: >> For some large >> scale computations, my Java codes perform identical to Fortran codes, > > Really? Even if you compile with optimization? 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 [quoted text clipped - 3 lines] > 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 :-) SignatureBjørn-Ove Heimsund Centre for Integrated Petroleum Research University of Bergen, Norway Jan C. Vorbrüggen <jvorbrueggen@mediasec.de> writes: > 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. SignatureRichard Maine | Good judgment comes from experience; email: my first.last at org.domain | experience comes from bad judgment. org: nasa, domain: gov | -- Mark Twain >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?) --------------------------------------------------------------------- | "Good and evil both increase at compound Ben Hocking, Grad Student | interest. That is why the little hocking@cs.virginia.edu | decisions you and I make every day are of | such infinite importance." - C. S. Lewis --------------------------------------------------------------------- >>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 ] SignatureToon Moene - mailto:toon@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) > Jan C. Vorbrüggen <jvorbrueggen@mediasec.de> writes: > [quoted text clipped - 10 lines] > through all the formal development process (for what little that > was actually worth :-() and was in production use. 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. >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. SignatureAl Balmer Balmer Consulting removebalmerconsultingthis@att.net > 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. ..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 )> 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. 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 SignatureDisclaimer: 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 > Read the article carefully. Java is being used to create 3D views of > terrain, and for command and control functions, ON EARTH. The last [quoted text clipped - 10 lines] > > --mitch 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. > 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! You give it too much credit! > 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. 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. >> Java, the software developed by Sun Microsystems in the mid-1990s as a >> universal operating system for Internet applications, gave NASA a low-cost [quoted text clipped - 6 lines] >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/ SignatureAl Balmer Balmer Consulting removebalmerconsultingthis@att.net > > Java, the software developed by Sun Microsystems in the mid-1990s as a > > universal operating system for Internet applications, gave NASA a low-cost [quoted text clipped - 55 lines] > a few Java enthusiasts do seem bent on misrepresentation of Java's > capabilities, potentially at Sun's credibility expense. 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 > > 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. 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. 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 > > > Java is certainly not a member of this tight-knit > > > club of system implementation languages, and I simply cannot picture [quoted text clipped - 3 lines] > a VM for the OS that allows one to run Java code with deterministic time > contraints on operations. No, what you actually posted was (unless attrition of this to you was in error): "> > Java, the software developed by Sun Microsystems in the mid-1990s as a > > 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. > > > > Java is certainly not a member of this tight-knit > > > > club of system implementation languages, and I simply cannot picture [quoted text clipped - 70 lines] > > Harry C. > > > > Java is certainly not a member of this tight-knit > > > > club of system implementation languages, and I simply cannot picture [quoted text clipped - 12 lines] > > > 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." 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 [quoted text clipped - 9 lines] > 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 > 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. 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 C. Vorbrüggen <jvorbrueggen@mediasec.de> wrote in message news:<400F7DA7.8891E58C@mediasec.de>... 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. > Jan C. Vorbr?ggen <jvorbrueggen@mediasec.de> wrote in message news:<400F7DA7.8891E58C@mediasec.de>... > Sorry Jan, I couldn't locate the original source of the text you > quoted and to which I am responding. [quoted text clipped - 43 lines] > believe that the utility of a virtual machine so very unrealistic for > RTOS use. 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. http://www.rtj.org/ 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 > Here often anything greater than a few processor instruction cycle > latency leads to a non-recoverable error situation. 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 > 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. :-) SignatureRichard Heathfield : binary@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 <reply satirical_mode="on"> Actually, the use of Java on the Mars rover is quite brilliant because of Java's write once run anywhere model. 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. Signature................................................. 99 percent of lawyers give the rest a bad name. Rod Davison - Critical Knowledge Systems Inc. >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. 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 > >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 [quoted text clipped - 6 lines] > hint: in case you missed it, the rover doesn't use any Java code, the > Java is all for manipulating the data rec |
Enable EMail Alerts
Start New Thread
Reply to this Message