Slashdot Mirror
Software Patch Fixes Mars Curiosity Rover's Auto-focus Glitch
An anonymous reader writes: Scientists from Los Alamos National Laboratory have successfully uploaded and applied a software patch to NASA's Curiosity Rover on Mars. The patch fixes a focusing problem that cropped up in November when the laser that helps to focus one of its cameras failed. "Without this laser rangefinder, the ChemCam instrument was somewhat blind," said Roger Wiens, ChemCam principal investigator at Los Alamos. "The main laser that creates flashes of plasma when it analyzes rocks and soils up to 25 feet [7.6 meters] from the rover was not affected, but the laser analyses only work when the telescope projecting the laser light to the target is in focus." Before the fix, scientists had to shoot images at nine different focus settings to distill a decent set of data. Now, they say the new software results in better images in a single shot than even before the laser broke down. The program that runs the instrument is only 40 kilobytes in size.
I worked at Los Alamos National Lab for a number of years. There are some very skilled people there who are very dedicated. America can do good science when it has the will. Which unfortunately isn't so often.
What is this?
I've only had to patch up systems from about 6900 Kilometers ( ~4300 miles ) away.
Apollo space program is documented in great detail. Even the software running in the flight computers is nowdays available and you can run the whole thing in a virtualized guidance computer. http://www.ibiblio.org/apollo/
Does anyone have any idea what's the case with probes and landers? I know they are mostly running VxWorks, but I'd love to take a peek on how some of the routines are actually implemented.
This fix still requires much of the resources of the previous method, essentially bracketing the shot and picking the best one. This means it will still take just as long to obtain each image, but apparently that wasn't a huge problem. What this saves is something precious though: bandwidth. Now the rover is picking the best shot, instead of sending a bunch of blind guesses and making us sort it out. I suspect that if the bandwidth wasn't precious, they wouldn't have bothered improving on the existing workaround, so it must have been worth all the trouble.
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
thats four times LiteOS! Get some Huawei developers work on this, and they'll reduce this patch to 64 bytes.
We need these guys to work on Firefox. Chromium too! Hell, just turn them loose on Windows!
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
If I read the article(s) correctly, problem was caused by failure of a small 2nd laser used for range finding. It seems that failure wasn't solved. Permanently out of action? Who knows.
Workaround was to take several shots at different focus settings, and have home base sort out the data. Improved workaround is to take several shots at different focus settings, have software on-site figure out which are the best, and only send that data back home.
If you are going to have a story like this it would be good form to remember the H, aka HOW from who,what,when,where, why and HOW of a journalism article. At some point in the past this was a site oriented to the technical community, most of whom are very interested in the how. You might even think that for the most part the when, why, where and who are all at the who cares level. (Mars being an exception)
Get some Huawei developers working on this and the thing will fail. We all know Asia's legacy of "quality"
There would probably be some dodgy malware thrown in for free in a few KB's.
NASA should definitely not EVER consider contracting Huawei developers or any such developers for that matter.
Huawei is just a cheap Chinese rip off of Cisco, Motorola and others, like any company that comes out of that part of the world..
Software for spacecraft is potentially export controlled either under ITAR or EAR, so just throwing it out on github or source-forge isn't likely. It's true that much of what's running on Curiosity probably is NOT subject to export control (or is "dual-use"), but it would be difficult and tedious (read - expensive) to separate out the pieces and get them reviewed for public release. Space missions are always budget constrained, so do you want to collect more science data or get software released?
As it happens, too, JPL does release a lot of software that feeds into the rover as separate stuff. Check out the NASA Tech Briefs and similar places. People do publish articles in journals and at conferences, and you can contact the author and ask if you can get the software, and they might be able to push it through the release process fairly easily: it's already segregated from the main body of "flight code" (or is in the "before it has been integrated state") both of which make it less likely it is considered "flight code".
Export controls are half of the "public release" issue: the other is the "IP licensing" aspect.
One other thing to bear in mind is that although the taxpayer funded the development, it might include non-taxpayer funded pieces, or pieces from the past. That might make it harder to open-source. Because JPL is part of CalTech, technology developed by JPL is subject to the Bayh-Dole act, so Caltech retains the rights, and the government gets what's called a "government purposes" license. So if you were building another widget for the US government, you could get a free license.
Also practically speaking, Caltech is very liberal with research/non-commercial use licenses: they're free, and the only condition is a "if you make changes, can you send them back to us" kind of clause. Non-exclusive commercial licenses are at fairly low single digit percentage royalties: Caltech would rather the technology get used than sit on the shelf, and having some "skin" in the game ensures that this is so, and pays for the people to review the license application.
40k is a lot of code, when it's not been written in layers of glop-gloop abstraction.
was just gonna say that... 40kb is quite a lot of assembly, or even C as long as it's not using bloated libraries.
Does anyone here happen to know if they code the rovers in assembly? or code the patches in assembly?
I work for the Department of Redundancy Department.
Nobody in their right mind is going to write rover code in assembly. Too much work, and too much chance of a silly mistakes fucking things up, while the actual code saving is not much. It's much easier and cheaper to add some extra memory instead.
"Now, they say the new software results in better images in a single shot than even before the laser broke down."
So it was a good Oportunity to pay some technical debt.
for a low level piece of code probably written in a low level language without the need for a crapload of libraries, gui's etc 40k is actually a bloody big program.
Nobody in their right mind is going to write rover code in assembly. Too much work, and too much chance of a silly mistakes fucking things up, while the actual code saving is not much. It's much easier and cheaper to add some extra memory instead.
This guy obviously hasn't had to pay for radhard SEU immune SRAM.
40 kb? So that's like one call to printf("%s",szMars) ...