NASA Testing Linux-Based Exploration Robots

SeenOnSlash.com writes "This week NASA is testing a Linux-based lunar rover called K-10 in the Arizona desert. To cut costs and promote maintainability the K-10 runs Linux and uses commercial off-the-shelf parts where possible. The robot rover's control and communications system is based on an IBM Thinkpad X31 and attaches to subsystems with standard PC interfaces. Real-time tasks such as fine-grained motor control are offloaded to a distributed network of microcontroller-powered control boards. Maneuvers can be watched through a live webcam."

Comments

Re:less worry about radiation on a planet?

[Speare]

One, this is a development model. Hardware subject to upgrade when making a "real" unit after the software achieves a basic level of maturity.

Two, you don't need a rad-hardened processor if you can wrap the whole computing unit in a rad-hardened box. Same goes for putting ice cubes in your freezer; if the fridge's materials and power units can withstand a thermal bombardment from the outside, the ice cube inside will remain solid.

I worked on that project this summer =)

[doomday]

I worked this summer at NASA Ames on an internship, particularly designing a control/power system for an arm thats to be mounted on K-10. The reason they used Red Hat Linux is because it is the system they use throughout the Ames base on the regular linux desktop machines, and it probably allows them to consolidate some maintenance without dealing with multiple distros. Also, its not designed to be space-ready, its basically a test bed for developing software and effective techniques for operation, that would be later translated to space ready rovers. In response to other comments: yes, there is an older version called K-9, which is actuall more designed to look space ready although K-10 is far more useful as a test bed. Additionally, in the coming months there is a new version K-11 being developed.

Re:"To Cut Costs"????

[Digicrat]

They actually use VxWorks for several spacecraft, I don't know what they use for the rovers though.

There does seem to be a trend in NASA though to try moving away from commercial/proprietary products across the board. I have seen them using Fedora and other shades of Linux on their testbeds for simulation, and I have heard talk of them looking into RTOS versions of Linux for the future.

Also check out ATHLETE

[ScottMaxwell]

At least one of the other robots participating in the test, ATHLETE, is also Linux-based (PPC CPUs, incidentally, not x86). How do I know? I'm writing part of the software we're using to drive it -- by adapting RSVP, the software we wrote to drive the MER rovers -- so I actually got to go out there and drive ATHLETE around for a few days as part of this test.

I love my job.

ATHLETE is one of the coolest damn things I've seen in a long time, designed and built by a team of absolutely brilliant engineers. Think of a two-meter-tall six-legged metal spider on roller skates. Or, heck, just check the link above.

The current ATHLETE is a prototype (of course); the ones we send to the moon -- if we're selected -- will be twice that size. Yes, Slashdotters, welcome our four-meter-tall six-legged roller-skate-wearing metal spider overlords!

For additional coverage of K-10, ATHLETE, Centaur/Robonaut, and other vehicles participating in this test, check out the updates from JSC.

Re:"To Cut Costs"????

[Mr2cents]

I really, really doubt that the licence cost is an issue when talking about millions of dollars (even for those low-cost missions). Instead, the real advantage in using linux for robotics (IMO) is the network transparency. Remote access is no issue with Linux (or any other unixish OS for that matter). It has lots of network protocols too (AX25 comes to mind).

One issue might be the code size. Remember that the Mars Exploration Rovers had multiple software upgrades sent over during the mission. An embedded RTOS is usually smaller in size, so that's a real time saver. But then again, with linux you could simply include gcc in the rover, send over the diff's, and let the rover compile the flight software in situ, and compare the output with md5. That would be a first! And you could simply interrupt the make process if the power runs low, and restart later. A standard make will find out where it was and continue from there, right out of the box.

PS: One more reason not to use windoze: just imagine getting a message from the other side of the solar system saying "Your version of windows is not genuine. Please contact ..."