Tag Archives: JPL

A close(ish) encounter with Voyager 2

Proudly source from: http://robohub.org/a-closeish-encounter-with-voyager-2/

It is summer 1985. I’m visiting Caltech with colleague and PhD supervisor Rod Goodman. Rod has just been appointed in the Electrical Engineering Department at Caltech, and I’m still on a high from finishing my PhD in Information Theory. Exciting times.

Rod and I are invited to visit the Jet Propulsion Labs (JPL). It’s my second visit to JPL. But it turned into probably the most inspirational afternoon of my life. Let me explain.After the tour the good folks who were showing us round asked if I would like to meet some of the post-docs in the lab. As he put it: the fancy control room with the big wall screens is really for the senators and congressmen – this is where the real work gets done. So, while Rod went off to discuss stuff with his new Faculty colleagues I spent a couple of hours in a back room lab, with a Caltech post-doc working on – as he put it – a summer project. I’m ashamed to say I don’t recall his name so I’ll call him Josh. Very nice guy, a real southern californian dude.

Now, at this point, I should explain that there was a real buzz at JPL. Voyager 2, which had already more than met its mission objectives was now on course to Uranus and due to arrive in January 1986. It was clear that there was a significant amount of work in planning for that event. The first ever opportunity to take a close look at the seventh planet.

So, Josh is sitting at a bench and in front of him is a well-used Apple II computer. And behind the Apple II is a small display screen so old that the phosphor is burned. This used to happen with CRT computer screens – it’s the reason screen savers were invented. Beside the computer are notebooks and manuals, including prominently a piece of graph paper with a half-completed plot. Josh then starts to explain: one of the cameras on Voyager 2 has (they think) a tiny piece of grit* in the camera turntable – the mechanism that allows the camera to be panned. This space grit means that the turntable is not moving as freely as it should. It’s obviously extremely important that when Voyager gets to Uranus they need to be able to point the cameras accurately, so Josh’s project is to figure out how much torque is (now) needed to move the camera turntable to any desired position. In other words: re-calibrate the camera’s controller.

At this point I stop Josh. Let me get this straight: there’s a spacecraft further from earth, and flying faster, than any manmade object ever, and your summer project is to do experiments with one of its cameras, using your Apple II computer. Josh: yea, that’s right.

Josh then explains the process. He constructs a data packet on his Apple II, containing the control commands to address the camera’s turntable motor and to instruct the motor to drive the turntable. As soon as he’s happy that the data packet is correct, he then sends it – via theRS232 connection at the back of his Apple II – to a JPL computer (which, I guess would be a mainframe). That computer then, in turn, puts Josh’s data packet together with others, from other engineers and scientists also working on Voyager 2, after – I assume – carefully validating the correctness of these commands. Then the composite data packet is sent to theDeep Space Network (DSN) to be transmitted, via one of the DSNs big radio telescopes, to Voyager 2.

Then, some time later, the same data packet is received by Voyager 2, decoded and de-constructed and said camera turntable moves a little bit. The camera then sends back to Earth, again via a composite data packet, some feedback from the camera – the number of degrees the turntable moved. So a day or two later, via a mind-bogglingly complex process involving several radio telescopes and some very heavy duty error-correcting codes, the camera-turntable feedback arrives back at Josh’s desktop Apple II with the burned-phosphor screen. This is where the graph paper comes in. Josh picks up his pencil and plots another point on his camera-turntable calibration graph. He then repeats the process until the graph is complete. It clearly worked because six months later Voyager 2 produced remarkable images of Uranus and its moons.

This was, without doubt, the most fantastic lab experiment I’d ever seen. From his humble Apple II in Pasadena Josh was doing tests on a camera rig, on a spacecraft, about 1.7 billion miles away. For a Thunderbirds kid, I really was living in the future. And being a space-nerd I already had some idea of the engineering involved in NASA’s deep space missions, but that afternoon in 1985 really brought home to me the extraordinary systems engineering that made these missions possible. Given the very long project lifetimes – Voyager 2 was designed in the early 1970s, launched in 1977, and is still returning valuable science today – its engineers had to design for the long haul; missions that would extend over several generations. Systems design like this requires genius, farsightedness and technical risk taking. Engineering that still inspires me today.

*it later transpired that the problem was depleted lubricant, not space grit.

Won S. Kim, who is working in JPL.

Personal Page Publications Image Gallery Videos
Won S. Kim's Picture
Address: 
Jet Propulsion Laboratory
M/S 82-105 
4800 Oak Grove Drive 
Pasadena, CA 91109
Phone:
818.354.5047
Fax:
818.393.3254
Email:
Click here
Member of:
3473
Mobility and Manipulation Group

Won S. Kim, Ph.D.
Senior Member of Technical Staff
(Full description>>)

Biography (more>>)
Won S. Kim is a Senior Member of Technical Staff in the Mobility and Manipulation Group. He has over 20 years experience in telerobotics research and development including software design and implementation, model and sensor based control, real-time motion control, calibration, system integration, validation, and flight software implementation.

Education (more>>)
Ph.D. in Electrical Engineering and Computer Science, 1986, University of California, Berkeley
M.S. in Electrical Engineering, 1978, Korea Advanced Institute of Science and Technology, Korea
B.S. in Electronics Engineering, 1976, Seoul National University, Korea

Professional Experience (more>>)
Task Manager, Integration of Visual Target Tracking into MER (2005-present)
Task Manager, Mars Science Laboratory (MSL09) Focused Technology: Instrument Placement Validation (2003-present)
Motion/Manipulation/Mobility (M3) Lead, CLARAty Testbed (2003-2005)

Research Interests (more>>)
Software design and implementation for mobility and manipulation systems, supervisory and autonomous system concepts and algorithm development, model and sensor-based real-time control, system integration and validation, flight software implementation

Selected Publications (more>>)

Won S. Kim, Robert D. Steele, Adnan I. Ansar, Danielle E. Ator, Shawn S. Catron,Visual Target Tracking Technology Validation Report [JPL Internal Only],” JPL D-33416, Jan. 2006.

W. S. Kim, A. I. Ansar, R.D. Steele, Khaled Ali, Issa Nesnas, Rover-Based Visual Target Tracking Validation and Mission Infusion,” AIAA Conf., Space 2005, Aug. 2005.

W. S. Kim, A. I. Ansar, R.D. Steele, Rover Mast Calibration, Exact Camera Pointing, and Camera Handoff for Visual Target Tracking,” IEEE 12th Int. Conf. on Advanced Robotics (ICAR’05), Jul. 2005.

The Internet through the outer space.

The interplanetary network that Vint Cerf envisioned years ago got its first real test recently. The EPOXI spacecraft, which carried the Deep Impact probe to Comet Talent 1 in 2005, had its software reconfigured after delivering the payload to work as a test bed for NASA’s new Disruption-Tolerant Networking protocol. As the craft dropped back toward Earth for one of the gravity assists that will ultimately sling it back toward the comet in 2010, it transmitted simulated images of the Martian moon Phobos using the new protocol.

The trial turned EPOXI into one of 10 nodes in a test network (the other nine were on Earth), to verify the reliability and robustness of the new networking architecture.

This new networking system, an outgrowth of Cerf’s Interplanetary Net project, can be layered on top of TCP/IP, the protocol that today’s Internet uses. But although DTN is designed for a different environment than Earth, ultimately the technology may find its way back here, to improve communication back home.

How to network in space
JPL’s Adrian Hooke, team lead and manager of space-networking architecture for NASA, explained the limitations of TCP/IP-based Internet to me. Although we tend to think of the Internet as routing around faults, he said, it is “not actually tolerant of disconnection between two machines.” If you lose a link between relay stations (routers), he explained, “the routers start dumping packets on the floor after a few milliseconds.”

Out in the solar system, where distance means that point-to-point communication time of a single bit can take minutes or hours, and where there is no system of interconnected routers, relay stations need to be smarter and more robust. Dropping packets doesn’t work. “In space, it’s very rare that you have an end-to-end path,” Hooke said.

Disruption-Tolerant Networking devices don’t just send off packets to the next device in the communications chain, as routers do. Instead, they hold on to packets until they expect that they will be received, and after they send them, they keep holding on to them until they receive an acknowledgment. Only once the packets are acknowledged do they release “custody” of the data to the next link in the communications chain.

 

It’s a network. In space.

(Credit: NASA/JPL)

 

DTN networks need more smarts and storage than typical routers. They need to know which devices they can send to, and when, since planets and space vehicles don’t stay put. And they need enough storage to hang on to packets that are coming in even when there may not be a receiver onto which they can offload them.

These concepts are not new. E-mail routers use store-and-forward architectures to transfer information, and mesh networks are opportunistic with their connections. But getting the DTN protocols certified for space operations requires a lengthy development cycle. Hooke told me that NASA hopes to have DTN ready to be built into spacecraft and ground-based radios in 2011, but that it will be four or five years after that before the technology will then make it into space. In 2015 or 2016, he said, “an interesting cluster of missions to the moon” will be launching, and he hopes to see DTN on them.

He also expects DTN to be part of the communications protocol for the Mars Sample Return mission, which is scheduled to launch in 2020 (but will probably be more like 2025). In that mission, a “full fleet of spacecraft” from several countries will all need to interoperate, and DTN should make the communications more reliable, and easier to build, than a patchwork of point-to-point radios. But first NASA and other space agencies need to know it works.

Meanwhile, back on Earth
DTN concepts are being applied to similarly flaky networks back home. Not surprisingly for a DARPA-funded project, the US military (the Marine Corps, to be specific) is experimenting with DTN for “stressed tactical military communications.” On a battlefield, as in space, there’s rarely an existing communications infrastructure a device can drop in to, so data radios need to be more tolerant of poor networks and opportunistically take advantage of communications links when they are available. Likewise, the Navy is looking at DTN to help submarines send and receive data in bursts when they surface or come close to a relay buoy.

DTN can integrate with existing TCP/IP networks, Hooke told me. “Bundle agents” can sit on the Internet and handle the store-and-forward protocols as well as the transfer of data from occasionally-connected devices to the main Internet.

And not all applications are military. A team in Sweden is using DTN to track reindeer movement (via geolocators tagged to animals), for example. Intel is looking at DTN to build out networks in developing countries with no communications grid. And in our own backyard, cellular equipment manufacturers are thinking about DTN for devices at the edges of expanding networks.