Search NASA⌕ Search
Home/Archive/NASA NTRS

NASA NTRS · 20150007807

Dreaming on Mars: How Curiosity Performs Actuator Warm-Up While Sleeping

Lee, Gene Y.·Donaldson, James A.
View original source ↗Export metadata ↓

Abstract

Before the Curiosity rover can perform its science activities for the day, such as driving, moving its robotic arm, or drilling, it first has to ensure that its actuators are within their allowable flight temperatures (AFTs). When the rover is awake, flight software uses heaters to warm up and maintain thermal zones at operational temperatures. However, Curiosity spends about 70% of its time sleeping, with the flight computer off, in order to conserve energy. Dream Mode is a special behavior that allows the rover to execute warm-up activities while sleeping. Using Dream Mode, actuators can be warmed up to their AFTs before the flight computer wakes up and uses them - saving power and improving operational efficiency. This paper describes the motivation behind Dream Mode, how it was implemented and tested on Curiosity, and the challenges and lessons learned along the way.

Explore related subjects

fault protectionDream ModethermalsleepCuriosity Rover

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Lee, Gene Y., Donaldson, James A.. 2013-06-02. Dreaming on Mars: How Curiosity Performs Actuator Warm-Up While Sleeping. https://ntrs.nasa.gov/citations/20150007807

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related reports

NASA NTRS2016

Enhancing the Cassini Mission Through FP Applications After Launch

Although rigorous pre-emptive measures are taken to preclude failures and anomalous conditions from occurring in JPL spacecraft missions prior to launch, unforeseeable problems can still surface after liftoff. In the case of the Cassini/Huygens Mission-to-Saturn spacecraft, several problems were observed post-launch: 1) immediately after takeoff, the collected engineering/science data stored on the Solid State Recorders (SSR) contained a significantly higher number of corrupted bits than was expected (considerably over spec) due to human error in the memory mapping of these devices, 2) numerous Solid State Power Switches (SSPS) sporadically tripped off throughout the mission due to cosmic ray bombardment from the unique space environment, and 3) false assumptions in the pressure regulator design in combination with missing heritage test data led to inaccurate design conclusions, causing the issuance of two waivers for the regulator to close properly (a potentially mission catastrophic single-point failure which occurred 24 days after launch) - amongst other problems. For Cassini, some of these anomalies led to arduous work-arounds or required continuous monitoring of telemetry variables by the ground-based Spacecraft Operations Flight Support (SOFS) team in order to detect and fix fault occurrences as they happened. Fortunately, sufficient funding and schedule margin allowed several Fault Protection (FP) solutions to be implemented into post-launch Flight Software (FSW) uploads to help resolve these issues autonomously, reducing SOFS ground support efforts while improving anomaly recovery time in order to preserve maximum science capture. This paper details the FP applications used to resolve the above issues as well as to optimize solutions for several other problems experienced by the Cassini spacecraft during its fight, in order to enhance the spacecraft's overall mission success throughout the 18 years of its 20 year expedition to and within the Saturnian system.

fault protection↗
NASA NTRS2016

Cassini Operational Sun Sensor Risk Management During Proximal Orbit Saturn Ring Plane Crossings

NASA's Cassini Spacecraft, launched on October 15th, 1997 which arrived at Saturn on June 30th, 2004, is the largest and most ambitious interplanetary spacecraft in history. As the first spacecraft to achieve orbit at Saturn, Cassini has collected science data throughout its four-year prime mission (2004–08), and has since been approved for a first and second extended mission through 2017. As part of the final extended missions, Cassini will begin an aggressive and exciting campaign of high inclination, low altitude flybys within the inner most rings of Saturn, skimming Saturn’s outer atmosphere, until the spacecraft is finally disposed of via planned impact with the planet. This final campaign, known as the proximal orbits, requires a strategy for managing the Sun Sensor Assembly (SSA) health, the details of which are presented in this paper.

fault protection↗
NASA NTRS2013

The Unparalleled Systems Engineering of MSL's Backup Entry, Descent, and Landing System: Second Chance

Second Chance (SECC) was a bare bones version of Mars Science Laboratory's (MSL) Entry Descent & Landing (EDL) flight software that ran on Curiosity's backup computer, which could have taken over swiftly in the event of a reset of Curiosity's prime computer, in order to land her safely on Mars. Without SECC, a reset of Curiosity's prime computer would have lead to catastrophic mission failure. Even though a reset of the prime computer never occurred, SECC had the important responsibility as EDL's guardian angel, and this responsibility would not have seen such success without unparalleled systems engineering. This paper will focus on the systems engineering behind SECC: Covering a brief overview of SECC's design, the intense schedule to use SECC as a backup system, the verification and validation of the system's "Do No Harm" mandate, the system's overall functional performance, and finally, its use on the fateful day of August 5th, 2012.

fault protection↗