Home

MER SPICE Interface

MER SPICE Interface is a software module for use in conjunction with the Mars Exploration Rover (MER) mission and the SPICE software system of the Navigation and Ancillary Information Facility (NAIF) at NASA's Jet Propulsion Laboratory. (SPICE is used to acquire, record, and disseminate engineering, navigational, and other ancillary data describing circumstances under which data were acquired by spaceborne scientific instruments.) Given a Spacecraft Clock value, MER SPICE Interface extracts MER-specific data from SPICE kernels (essentially, raw data files) and calculates values for Planet Day Number, Local Solar Longitude, Local Solar Elevation, Local Solar Azimuth, and Local Solar Time (UTC). MER SPICE Interface was adapted from a subroutine, denoted m98SpiceIF written by Payam Zamani, that was intended to calculate SPICE values for the Mars Polar Lander. The main difference between MER SPICE Interface and m98SpiceIf is that MER SPICE Interface does not explicitly call CHRONOS, a time-conversion program that is part of a library of utility subprograms within SPICE. Instead, MER SPICE Interface mimics some portions of the CHRONOS code, the advantage being that it executes much faster and can efficiently be called from a pipeline of events in a parallel processing environment.

Posted in: Briefs, TSP

Read More >>

Ground Support Software for Spaceborne Instrumentation

ION is a system of ground support software for the ion and neutral mass spectrometer (INMS) instrument aboard the Cassini spacecraft. By incorporating commercial off - the - shelf database, Web server, and Java application components, ION offers considerably more ground - support - service capability than was available previously. A member of the team that operates the INMS or a scientist who uses the data collected by the INMS can gain access to most of the services provided by ION via a standard point-and click hyperlink interface generated by almost any Web-browser program running in almost any operating system on almost any computer. Data are stored in one central location in a relational database in a non-proprietary format, are accessible in many combinations and formats, and can be combined with data from other instruments and space-craft. The use of the Java programming language as a system-interface language offers numerous capabilities for object-oriented programming and for making the database accessible to participants using a variety of computer hard-ware and software.

Posted in: Briefs, TSP

Read More >>

Further Improvement in 3DGRAPE

"3DGRAPE/AL:V2" denotes version 2 of the Three - Dimensional Grids About Anything by Poisson's Equation with Upgrades from Ames and Langley computer program. The preceding version, 3DGRAPE/AL, was described in "Improved 3DGRAPE" (ARC-14069) NASA Tech Briefs ,Vol.21, No.5 (May 1997), page 66. These programs are so named because they generate volume grids by iteratively solving Poisson's Equation in three dimensions. The grids generated by the various versions of 3DGRAPE have been used in computational fluid dynamics (CFD). The main novel feature of 3DGRAPE/AL:V2 is the incorporation of an optional scheme in which anisotropic Lagrange-based trans-finite interpolation (ALBTFI) is coupled with exponential decay functions to compute and blend interior source terms. In the input to 3DGRAPE/AL:V2 the user can specify whether or not to invoke ALBTFI in combination with exponential-decay controls, angles, and cell size for controlling the character of grid lines. Of the known programs that solve elliptic partial differential equations for generating grids, 3DGRAPE/AL:V2 is the only code that offers a combination of speed and versatility with most options for controlling the densities and other characteristics of grids for CFD.

Posted in: Briefs, TSP

Read More >>

Conflict-Aware Scheduling Algorithm

An algorithm is being developed to automate NASA’s Deep Space Network antenna allocation. A conflict-aware scheduling algorithm is being developed to help automate the allocation of NASA’s Deep Space Network (DSN) antennas and equipment that are used to communicate with interplanetary scientific spacecraft. The current approach for scheduling DSN ground resources seeks to provide an equitable distribution of tracking services among the multiple scientific missions and is very labor intensive. Due to the large (and increasing) number of mission requests for DSN services, combined with technical and geometric constraints, the DSN is highly oversubscribed. To help automate the process, and reduce the DSN and spaceflight project labor effort required for initiating, maintaining, and negotiating schedules, a new scheduling algorithm is being developed.

Posted in: Briefs, TSP

Read More >>

Real-Time Diagnosis of Faults Using a Bank of Kalman Filters

Gradual changes associated with aging are taken into account in the diagnostic process. A new robust method of automated real-time diagnosis of faults in an aircraft engine or a similar complex system involves the use of a bank of Kalman filters. In order to be highly reliable, a diagnostic system must be designed to account for the numerous failure conditions that an aircraft engine may encounter in operation. The method achieves this objective though the utilization of multiple Kalman filters, each of which is uniquely designed based on a specific failure hypothesis. A fault-detection- and-isolation (FDI) system, developed based on this method, is able to isolate faults in sensors and actuators while detecting component faults (abrupt degradation in engine component performance). By affording a capability for real-time identification of minor faults before they grow into major ones, the method promises to enhance safety and reduce operating costs.

Posted in: Briefs

Read More >>

Ground-Based Localization of Mars Rovers

The document discusses a procedure for localizing the Mars rovers in site frame, a locally defined reference frame on the Martian surface. MER onboard position within a site frame is estimated onboard and is based on wheel odometry. Odometry estimation of rover position is only reliable over relatively short distances assuming no wheel slip, sinkage, etc. As the rover traverses, its onboard estimate of position in the current site frame accumulates errors and will need to be corrected on occasions via relocalization on the ground (mission operations). The procedure provides a systematic process for ground operators to localize the rover. The method focuses on analysis of acquired images used to declare a site frame and images acquired post-drive. Target selection is performed using two main steps. In the first step, the user identifies features of interest from the images used to declare the current site. Each of the selected target’s position in site frame is recorded. In the second step, post-traverse measurements of the selected features’ positions are recorded again, this time in rover frame, using images acquired post-traverse. In the third step, we transform the post-traverse target’s positions to local level frame. In the fourth step, we compute the delta differences in the pre- and post-traverse target’s position. In the fifth step, we analyze the delta differences with techniques that compute their statistics to determine the rover’s position in the site frame.

Posted in: Briefs

Read More >>

Methodology for Designing Fault-Protection Software

A document describes a methodology for designing fault-protection (FP) software for autonomous spacecraft. The methodology embodies and extends established engineering practices in the technical discipline of Fault Detection, Diagnosis, Mitigation, and Recovery; and has been successfully implemented in the Deep Impact Spacecraft, a NASA Discovery mission. Based on established concepts of Fault Monitors and Responses, this FP methodology extends the notion of Opinion, Symptom, Alarm (aka Fault), and Response with numerous new notions, sub-notions, software constructs, and logic and timing gates. For example, Monitor generates a RawOpinion, which graduates into Opinion, categorized into no-opinion, acceptable, or unacceptable opinion. RaiseSymptom, ForceSymptom, and ClearSymptom govern the establishment and then mapping to an Alarm (aka Fault). Local Response is distinguished from FP System Response. A 1-to-n and n-to-1 mapping is established among Monitors, Symptoms, and Responses. Responses are categorized by device versus by function. Responses operate in tiers, where the early tiers attempt to resolve the Fault in a localized step-bystep fashion, relegating more system-level response to later tier(s). Recovery actions are gated by epoch recovery timing, enabling strategy, urgency, MaxRetry gate, hardware availability, hazardous versus ordinary fault, and many other priority gates. This methodology is systematic, logical, and uses multiple linked tables, parameter files, and recovery command sequences. The credibility of the FP design is proven via a fault-tree analysis “top-down” approach, and a functional fault-mode-effects-andanalysis via “bottoms-up” approach. Via this process, the mitigation and recovery strategy( s) per Fault Containment Region scope (width versus depth) the FP architecture.

Posted in: Briefs, TSP

Read More >>