Case study: NASA's "Deep Impact" employs embedded systems to score bullseye 80 million miles away

Story

January 13, 2006

On January 12, 2005, NASA, working with the engineers at the Jet Propulsion Laboratory (JPL) and the University of Maryland, launched Deep Impact?s (DI) two-piece space probe with the intention of hitting Tempel 1?a comet 80 million miles away. Scientists hope to use the captured mission data to find clues about how to force comets, asteroids, and meteors off-course in the event that one of them had Earth on its trajectory.

 

Lexicon
DI	Deep Impact
NASA	National Aeronautics And Space Administration
JPL	Jet Propulsion Laboratories
HRI	High Resolution Instrument
MRI	Medium Resolution Instrument
ITS	Impact Targeting Sensor
SDA	Sensor Data Acquisition application
AutoNav	NASA software for autonomous navigation

On January 12, 2005, NASA, working with the engineers at the Jet Propulsion Laboratory (JPL) and the University of Maryland, launched Deep Impact’s (DI) two-piece space probe with the intention of hitting Tempel 1—a comet 80 million miles away. Scientists hope to use the captured mission data to find clues about how to force comets, asteroids, and meteors off-course in the event that one of them had Earth on its trajectory. Earth impact by a large comet is believed to be capable of creating a crater several hundred kilometers wide while simultaneously triggering a firestorm that would engulf the entire world. To complete the $300 million project, JPL went to longtime hardware provider Ball Aerospace & Technologies Corp., (Boulder, CO), specifically tasking Ball with building an 820-pound craft approximately the size of an SUV. The project consisted of a Flyby craft and an Impactor craft, responsible for taking and transmitting the data back to earth. These imaging instruments were also required to aid in the autonomous navigation of the crafts as well.

Figure 1 shows the Flyby (hanging) and Impactor (on the floor). The spacecraft were joined, or "stacked" on April 7 at Ball Aerospace and Technologies Corp. where they were built and prepared for environmental testing. To ensure proper location and impact of the comet, software was essential. As mothership, the Flyby contained two cameras: a High Resolution Instrument (HRI) and a Medium Resolution Instrument (MRI). The Flyby's HRI provided JPL’s ground command with high-resolution images via a combined digital camera and infrared spectrometer, which enabled shots in color and infrared.

Figure 1: Deep Impact Flyby (hanging) and Impactor (on the floor)

Due to its wider field of view, the MRI totally controlled craft navigation for the last 10 days of Deep Impact’s trajectory before actual impact. The MRI achieved this by capturing images of distant stars and interpreting them in real time to determine the spacecraft’s position and trajectory. Then, based on those interpretations, the spacecraft’s altitude, speed, and direction of flight could be adjusted to keep it on its intended course toward the rendezvous with Tempel 1. Together the HRI and the MRI were responsible for navigating both DI crafts precisely while transmitting thousands of images and related data back to earth.

“Ball selected Express Logic’s ThreadX real-time operating system (RTOS) to run on the SPARC processor.”

Deep Impact’s Impactor craft (about the size of a washing machine) had onboard an Impactor Targeting Sensor (ITS). The ITS kept the Impactor in the path of the comet by acquiring and analyzing images relayed from the MRI while navigating itself into the path of the oncoming Tempel 1 comet, taking pictures and transmitting the images and data to Earth until achieving contact with the comet.

Goals and challenges
It took 7 years of preparation — 18 months of that devoted to software development — and in January 2005, the Deep Impact probe launched. On July 4, 2005, the probe reached and collided with comet Tempel 1. In the course of its flight to and impact with the comet, the probe transmitted more than 4,500 photographs. Figure 2, (courtesy of NASA/JPL-Caltech/UMD) shows the initial ejecta that resulted when NASA's Deep Impact probe collided with comet Tempel 1 at 10:52 p.m. Pacific time, July 3 (1:52 a.m. Eastern time, July 4). It was taken by the spacecraft's medium-resolution camera 16 seconds after impact.

Figure 2: (courtesy of NASA/JPL-Caltech/UMD) shows the initial ejecta that resulted when NASA's Deep Impact probe collided with comet Tempel 1 at 10:52 p.m. Pacific time, July 3 (1:52 a.m. Eastern time, July 4)

NASA had several goals for the Deep Impact mission:

• Navigate the Deep Impact probe to collide with a deep-space comet
• Excavate material from the comet’s frozen nucleus
• Transmit back to earth the thousands of photographs and related data necessary for scientific study
• Determine the origins of the comet, and in so doing, the universe itself

This mission timeline was tight. The target comet, Tempel 1, discovered in 1867, only orbits the sun at its closest access point to Earth every five and a half years (Figure 3). Further, the comet’s nucleus is only the size of the District of Columbia, which sounds huge at first; for engineers accustomed to only landing spacecraft on the moon or Mars, though, Tempel 1 was literally only a blip on the radar screen.

Figure 3: The orbit of Comet Tempel 1 - The target comet, Tempel 1, discovered in 1867, only orbits the sun at its closest access point to Earth every five and a half years

Hardware challenges and solutions
Other challenges for the Ball Aerospace team included the design of a dual-vehicle spacecraft capable of carrying the required instruments into space and then separating into a surviving craft and a subcraft that would actually impact Tempel 1 (see Figure 4). Providing power for this system depended on deployment of solar arrays to convert sunlight into electrical energy, but that required almost an hour since the panels couldn’t be deployed until the craft was beyond the Earth’s atmosphere. For that hour, the craft’s batteries had to support all the electronics onboard, deploying the antennas to their full extent before running out. As well, the processor used had to be able to withstand space radiation while still running commercial software.

The system hardware consisted of a combination of mission, navigation, and acquisition systems, using 32-bit embedded microprocessors. For the camera controllers, the processor deployed was Atmel Corporation’s radiation-hardened SPARC TSC695F processor. As a SPARC-compliant processor, it could run SPARC software and use SPARC-targeted development systems, both of which were commercially available. Ball selected Express Logic’s ThreadX Real-Time Operating System (RTOS) to run on the SPARC processor, based on its small memory requirements and its support of the SPARC architecture.

Figure 4 shows an artist's rendition of the Flyby spacecraft releasing the Impactor 24 hours before the impact event. Pictured from left to right are the comet Tempel 1, the Impactor, and the Flyby spacecraft. The Impactor is a 370-kilogram mass with an onboard guidance system. The Flyby spacecraft includes a solar panel (right), a high-gain antenna (top), a debris shield (left, background), and science instruments for high- and medium-resolution imaging, infrared spectroscopy, and optical navigation (yellow box and cylinder, lower left). The Flyby spacecraft is about 3.2 meters long, 1.7 meters wide, and 2.3 meters high. The launch payload has a mass of 1,020 kilograms.

Figure 4: (Deep Impact) An artist's rendition of the Flyby spacecraft releasing the Impactor 24 hours before the impact event

Software challenges and solutions

“AutoNav takes the images captured by the camera, interprets the data, does some edge-detection or enhancement”

Deep Impact’s FSW embedded application flight software called AutoNav, short for autonomous navigation, was created by JPL for its Deep Space One project. At this point in space exploration, AutoNav is JPL’s central embedded technology specifically engineered to deal with the massive distances involved in space missions. With Deep Impact taking place so far from Earth, transmission delays made it impossible to physically control the spacecraft from JPL’s Pasadena command station, making self-navigation via AutoNav a necessity.

The cameras aboard Deep Impact capture target images and pass them to AutoNav for interpretation and required action (Figure 5). The AutoNav software provides the real-time control of everything onboard a spacecraft. The software has a broad range of controls; it tells the thrusters when to fire, tells the reaction wheels when to spin up or down, turns the radio on and off, and so forth. AutoNav was fed by and interpreted the imagery data transmitted to it from a Sensor Data Acquisition (SDA) subsystem that was managed by the ThreadX RTOS. ThreadX managed the operation of the Charge-Coupled Device (CCD) camera controllers in all three imaging instruments –the HRI, MRI, and ITS – on both of Deep Impact’s Flyby and Impactor crafts.

Figure 5: The cameras aboard Deep Impact capture target images and pass them to AutoNav for interpretation and required action

The SDA subsystem consisted of 19 application threads executing in a priority-based, preemptive fashion, under the control of ThreadX on the Atmel processor (see Figure 6). Since the SPARC version of ThreadX was designed to target a standard COTS SPARClite processor from Fujitsu, Ball’s challenges included understanding the differences between the Fujitsu processor, which had been discontinued and for which there was minimal documentation available, and the Atmel processor, in order to adapt ThreadX to run on the closest available alternate.

Figure 6: The SDA subsystem consisted of 19 application threads executing in a priority-based, preemptive fashion, under the control of ThreadX on the Atmel processor

The 19 application threads performed all control actions required to capture images during long-range navigation and travel to Tempel 1’s orbit, and images of the comet once it was within range. The SDA-acquired data was fed to AutoNav for analysis. These images of the comet were used to perform fine-grained position adjustments to assure impact with Tempel 1.

“ThreadX … managed the application software running on the three instrument controllers, including interrupt processing, thread scheduling, and message passing.”

By design as an AutoNav-equipped spacecraft, Deep Impact’s onboard systems and application software monitored its own position, computed its own course, translated that course into commands to its thrusters, and executed its own trajectory corrections as it continued en route to Tempel 1. These real-time functions were continuously performed by the application threads under the scheduling control of the RTOS.

To determine the spacecraft’s present position and to calculate any necessary corrections, AutoNav is completely dependent on imagery data from the Deep Impact sensors, controlled by the SDA application using ThreadX, from which it can calculate spacecraft position and trajectory. With that data, AutoNav enables fully autonomous navigation. As the craft’s image analysis software, AutoNav, takes the images captured by the camera, interprets the data, does some edge-detection or enhancement, figures out where the comet’s center of mass and center of brightness are, and adjusts its trajectory accordingly. AutoNav enabled the Deep Impact spacecraft to become a fully autonomous “robot.”

AutoNav also was in charge of myriad other tasks. AutoNav told the craft to maintain its power balance, to point its arrays at the sun for solar energy collection, and to point the craft’s antennas back to earth for data transmission. Notably all of this software had to be embedded on the signal processing unit onboard the spacecraft.

Role of ThreadX
While AutoNav was Deep Impact’s “brain” on the mission, the actual “eyes” were provided by the HRI, MRI, and ITS cameras. ThreadX was used to control the “eye” aspect of the mission. It managed the application software running on the three instrument controllers, including interrupt processing, thread scheduling, and message passing — tasks necessary to the proper operation of the cameras. ThreadX-managed instruments, then transmitted the raw data back to AutoNav, which then decided what the data showed and what to do next.

“The application code count came in around 20,000 lines of code and involved 19 distinct application threads.”

The SDA system was responsible for capturing image data from the cameras. The CCD arrays had to be read in real time on a fixed time schedule under control of the RTOS. This assured reliable time-spacing of the images, from which spacecraft velocity and direction could be computed. Timer interrupts triggered the CCD data capture thread, which performed the capture and deposited the data in an area of memory from which AutoNav could retrieve it for analysis. AutoNav simultaneously processed the image data before, during, and after actual impact, to guide the Impactor onto a collision course with Tempel 1.  At the same time, AutoNav also transmitted this data back to JPL.

Incidentally, for such a major undertaking as the Deep Impact mission, the software development teams were surprisingly small. The software team consisted of a lead, system engineer, four developers, and a software quality engineer. At Express Logic, a pair of their top developers took the reins. In total, the application code count came in around 20,000 lines of code and involved 19 distinct application threads.

Deep Impact’s total software development, from top to bottom, took only 18 months. The specialized variation of the SPARC architecture used in the Atmel processor required some adaptation of ThreadX from its off-the-shelf version for SPARC. Express Logic performed this minor adaptation for Ball, resulting in a version of ThreadX that ran on the Atmel processor. Ball was able to complete all the application code using existing documentation without needing any additional help from Express Logic. Green Hills’s MULTI IDE was used as a development platform.

Mission results and ongoing research
From Deep Impact's mission launch on January 12, 2005, to comet impact on July 4, 2005, the DI spacecraft took 174 days and 429 million kilometers to reach Tempel 1 at a cruising speed of 28.6 km/s (103,000 km/h or 64,000 mph). Once the spacecraft reached the vicinity of the comet on July 3, 2005 (Figure 7), it separated into two parts — the Impactor and the Flyby probe. The Impactor used its thrusters to move into the path of the comet, impacting 24 hours later at a relative speed of 10.3km/s (37,000 km/h or 23,000 mi/h).

Figure 7: the spacecraft reached the vicinity of the comet on July 3, 2005

Since the washing machine-sized Impactor approached Tempel 1 with a speed of 10.30km/s (6.3 mi/s), the kinetic energy reached the equivalent of 4.5 tons of TNT, which resulted in a collision that excavated a crater larger than the bowl of the Roman Coliseum.

The data that resulted from the Deep Impact mission is already creating a stir in the scientific community. Mission data indicates that the nucleus of Tempel 1 is extremely porous, allowing the surface of the nucleus to heat up and cool down almost instantly in response to sunlight. This suggests that heat is not easily conducted to the interior, and the ice and other material deep inside the nucleus may be pristine and unchanged from the early days of the solar system as scientists have suggested all along.

It’s now clear that the material on the comet’s surface down to a depth of several dozen meters is unbelievably fragile, less strong than a snow bank. Often described as “dirty snowballs,” comets are considered prime candidates for seeding planets, including Earth, with water and organic material.

An analysis of material in the plume created by the probe’s impact showed a huge increase in the amount of molecules that contain carbon. This suggests that comets like Tempel 1 contain a substantial amount of organic material, which means they may have brought such material to Earth early in the planet’s history at a time when asteroid and meteor strikes were common.

It’s clear that with such preliminary results already being touted by scientists, the data yielded from the Deep Impact mission will likely continue for years to come, as existing data continues to be analyzed at JPL and the Flyby spacecraft continues on its trek across space.

As for embedded software’s key role on Deep Impact, the companies integrally involved on the mission are rightly proud of their accomplishments. With missions such as these, things have to work the first time. All aspects of development must be dependable, reliable, and field proven.

Notably, the Deep Impact project was so successful that Ball Aerospace has chosen Express Logic’s ThreadX for deployment in their latest project for NASA and JPL—the Mars Reconnaissance Orbiter (MRO), which launched in August 2005.

. . . . .

William E. Lamie is founder and president of Express Logic. William personally assisted Ball engineers in their use of ThreadX for this mission.

To learn more, go to the  Express Logic website at www.rtos.com.