Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “mission software”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 973 records · Page 54

Mars Reconnaissance Orbiter, Ground Data System, Receivables and Deliverables (REC/DELs)

This paper presents one JPL element manager's approach to describe a complex Ground Data System (GDS) with its receivables and deliverables (REC/DEL). The Mars Reconnaissance Orbiter (MRO) Ground Data System is the integrated set of ground software, hardware, facilities and networks that support mission operation. REC/DEL is a powerful tool for specifying hierarchy of commitments among systems and teams. Receivable of a system is a deliverable of another system. Focusing on tangible products enables the manager to objectively measure progress in a schedule. Jet Propulsion Laboratory mandates the use of REC/DEL for flight projects. Tutorial and training is provided for managers to create integrated REC/DEL database using automated systems. Project schedules are based on REC/DELs. This paper is not focusing on the mechanics of REC/DEL database creation, but it provides a guideline how one systematically creates categories of deliverables and receivables for ground data system components.

guidelines↗

A Rapid, Flexible Approach to Conceptual Space Mission Tradespace Definition and Exploration

This paper provides an overview of the Mission Tradespace Tool (MTT), a methodology and software framework developed to improve JPL's early design process by offering a rapid, structured, and inexpensive way to identify feasible design architectures from a wide array of candidate architectures. There has been a growing consensus at JPL that to improve the quality of service offered to design customers it is desirable to explore a wide tradespace of candidate architectures prior to forming a conceptual design baseline. This paper describes the rationale behind the MTT's approach to meet this need. Notable features of the framework are introduced and explained.

early designs↗

General Mission Analysis Tool (GMAT) Acceptance Test Plan [Draft]

The information presented in this Acceptance Test Plan document shows the current status of the General Mission Analysis Tool (GMAT). GMAT is a software system developed by NASA Goddard Space Flight Center (GSFC) in collaboration with the private sector. The GMAT development team continuously performs acceptance tests in order to verify that the software continues to operate properly after updates are made. The GMAT Development team consists of NASA/GSFC Code 583 software developers, NASA/GSFC Code 595 analysts, and contractors of varying professions. GMAT was developed to provide a development approach that maintains involvement from the private sector and academia, encourages collaborative funding from multiple government agencies and the private sector, and promotes the transfer of technology from government funded research to the private sector. GMAT contains many capabilities, such as integrated formation flying modeling and MATLAB compatibility. The propagation capabilities in GMAT allow for fully coupled dynamics modeling of multiple spacecraft, in any flight regime. Other capabilities in GMAT inclucle: user definable coordinate systems, 3-D graphics in any coordinate system GMAT can calculate, 2-D plots, branch commands, solvers, optimizers, GMAT functions, planetary ephemeris sources including DE405, DE200, SLP and analytic models, script events, impulsive and finite maneuver models, and many more. GMAT runs on Windows, Mac, and Linux platforms. Both the Graphical User Interface (GUI) and the GMAT engine were built and tested on all of the mentioned platforms. GMAT was designed for intuitive use from both the GUI and with an importable script language similar to that of MATLAB.

Dove, Edwin↗

Operational Experience with Autonomous Star Trackers on ESA Interplanetary Spacecraft

Mars Express (MEX), Rosetta and Venus Express (VEX) are ESA interplanetary spacecrafts (S/C) launched in June 2003, March 2004 and November 2005, respectively. Mars Express was injected into Mars orbit end of 2003 with routine operations starting in spring 2004. Rosetta is since launch on its way to rendezvous comet Churyumov-Gerasimenko in 2014. It has completed several test and commissioning activities and is performing several planetary swingbys (Earth in spring 2005, Mars in spring 2007, Earth in autumn 2007 and again two years later). Venus Express has also started routine operations since the completion of the Venus orbit insertion maneuver sequence beginning of May 2006. All three S/C are three axes stabilized with a similar attitude and orbit control system (AOCS). The attitude is estimated on board using star and rate sensors and controlled using four reaction wheels. A bipropellant reaction control system with 10N thrusters serves for wheel off loadings and attitude control in safe mode. Mars Express and Venus Express have an additional 400N engine for the planetary orbit insertion. Nominal Earth communication is accomplished through a high gain antenna. All three S/C are equipped with a redundant set of autonomous star trackers (STR) which are based on almost the same hardware. The STR software is especially adapted for the respective mission. This paper addresses several topics related to the experience gained with the STR operations on board the three S/C so far.

Lauer, Mathias↗

Mars Reconnaissance Orbiter, Ground Data System, Receivables and Deliverables (REC/DELs)

This paper presents one JPL element manager's approach to describe a complex Ground Data System (GDS) with its receivables and deliverables (REC/DEL). The Mars Reconnaissance Orbiter (MRO) Ground Data System is the integrated set of ground software, hardware, facilities and networks that support mission operation. REC/DEL is a powerful tool for specifying hierarchy of commitments among systems and teams. Receivable of a system is a deliverable of another system. Focusing on tangible products enables the manager to objectively measure progress in a schedule. The Jet Propulsion Laboratory mandates the use of REC/DEL for flight projects. Tutorial and training is provided for managers to create an integrated REC/DEL database using automated systems. Project schedules are based on REC/DELs. This paper is not focusing on the mechanics of REC/DEL database creation, but it provides a guideline how one systematically creates categories of deliverables and receivables for ground data system components...

ground data system (GDS)↗

HyspIRI Intelligent Payload Module(IPM) and Benchmarking Algorithms for Upload

Features: Hardware: a) Xilinx Virtex-5 (GSFC Space Cube 2); b) 2 x 400MHz PPC; c) 100MHz Bus; d) 2 x 512MB SDRAM; e) Dual Gigabit Ethernet. Support Linux kernel 2.6.31 (gcc version 4.2.2). Support software running in stand alone mode for better performance. Can stream raw data up to 800 Mbps. Ready for operations. Software Application Examples: Band-stripping Algiotrhmsl:cloud, sulfur, flood, thermal, SWIL, NDVI, NDWI, SIWI, oil spills, algae blooms, etc. Corrections: geometric, radiometric, atmospheric. Core Flight System/dynamic software bus. CCSDS File Delivery Protocol. Delay Tolerant Network. CASPER /onboard planning. Fault monitoring/recovery software. S/C command and telemetry software. Data compression. Sensor Web for Autonomous Mission Operations.

Mandl, Daniel↗

Representation of Serendipitous Scientific Data

A computer program defines and implements an innovative kind of data structure than can be used for representing information derived from serendipitous discoveries made via collection of scientific data on long exploratory spacecraft missions. Data structures capable of collecting any kind of data can easily be implemented in advance, but the task of designing a fixed and efficient data structure suitable for processing raw data into useful information and taking advantage of serendipitous scientific discovery is becoming increasingly difficult as missions go deeper into space. The present software eases the task by enabling definition of arbitrarily complex data structures that can adapt at run time as raw data are transformed into other types of information. This software runs on a variety of computers, and can be distributed in either source code or binary code form. It must be run in conjunction with any one of a number of Lisp compilers that are available commercially or as shareware. It has no specific memory requirements and depends upon the other software with which it is used. This program is implemented as a library that is called by, and becomes folded into, the other software with which it is used.

James, Mark↗

Service Oriented Robotic Architecture for Space Robotics: Design, Testing, and Lessons Learned

This paper presents the lessons learned from six years of experiments with planetary rover prototypes running the Service Oriented Robotic Architecture (SORA) developed by the Intelligent Robotics Group (IRG) at the NASA Ames Research Center. SORA relies on proven software engineering methods and technologies applied to space robotics. Based on a Service Oriented Architecture and robust middleware, SORA encompasses on-board robot control and a full suite of software tools necessary for remotely operated exploration missions. SORA has been eld tested in numerous scenarios of robotic lunar and planetary exploration. The experiments conducted by IRG with SORA exercise a large set of the constraints encountered in space applications: remote robotic assets, ight relevant science instruments, distributed operations, high network latencies and unreliable or intermittent communication links. In this paper, we present the results of these eld tests in regard to the developed architecture, and discuss its bene ts and limitations.

service oriented architecture↗

Robotic Technology Efforts at the NASA/Johnson Space Center

The NASA/Johnson Space Center has been developing robotic systems in support of space exploration for more than two decades. The goal of the Center's Robotic Systems Technology Branch is to design and build hardware and software to assist astronauts in performing their mission. These systems include: rovers, humanoid robots, inspection devices and wearable robotics. Inspection systems provide external views of space vehicles to search for surface damage and also maneuver inside restricted areas to verify proper connections. New concepts in human and robotic rovers offer solutions for navigating difficult terrain expected in future planetary missions. An important objective for humanoid robots is to relieve the crew of "dull, dirty or dangerous" tasks allowing them more time to perform their important science and exploration missions. Wearable robotics one of the Center's newest development areas can provide crew with low mass exercise capability and also augment an astronaut's strength while wearing a space suit. This presentation will describe the robotic technology and prototypes developed at the Johnson Space Center that are the basis for future flight systems. An overview of inspection robots will show their operation on the ground and in-orbit. Rovers with independent wheel modules, crab steering, and active suspension are able to climb over large obstacles, and nimbly maneuver around others. Humanoid robots, including the First Humanoid Robot in Space: Robonaut 2, demonstrate capabilities that will lead to robotic caretakers for human habitats in space, and on Mars. The Center's Wearable Robotics Lab supports work in assistive and sensing devices, including exoskeletons, force measuring shoes, and grasp assist gloves.

Diftler, Ron↗

Orion Optical Navigation Progress Toward Exploration: Mission 1

Optical navigation of human spacecraft was proposed on Gemini and implemented successfully on Apollo as a means of autonomously operating the vehicle in the event of lost communication with controllers on Earth. It shares a history with the "method of lunar distances" that was used in the 18th century and gained some notoriety after its use by Captain James Cook during his 1768 Pacific voyage of the HMS Endeavor. The Orion emergency return system utilizing optical navigation has matured in design over the last several years, and is currently undergoing the final implementation and test phase in preparation for Exploration Mission 1 (EM-1) in 2019. The software development is being worked as a Government Furnished Equipment (GFE) project delivered as an application within the Core Flight Software of the Orion camera controller module. The mathematical formulation behind the initial ellipse fit in the image processing is detailed in Christian. The non-linear least squares refinement then follows the technique of Mortari as an estimation process of the planetary limb using the sigmoid function. The Orion optical navigation system uses a body fixed camera, a decision that was driven by mass and mechanism constraints. The general concept of operations involves a 2-hour pass once every 24 hours, with passes specifically placed before all maneuvers to supply accurate navigation information to guidance and targeting. The pass lengths are limited by thermal constraints on the vehicle since the OpNav attitude generally deviates from the thermally stable tail-to-sun attitude maintained during the rest of the orbit coast phase. Calibration is scheduled prior to every pass due to the unknown nature of thermal effects on the lens distortion and the mounting platform deformations between the camera and star trackers. The calibration technique is described in detail by Christian, et al. and simultaneously estimates the Brown-Conrady coefficients and the Star Tracker/Camera interlock angles. Accurate attitude information is provided by the star trackers during each pass. Figure 1 shows the various phases of lunar return navigation when the vehicle is in autonomous operation with lost ground communication. The midcourse maneuvers are placed to control the entry interface conditions to the desired corridor for safe landing. The general form of optical navigation on Orion is where still images of the Moon or Earth are processed to find the apparent angular diameter and centroid in the camera focal plane. This raw data is transformed into range and bearing angle measurements using planetary data and precise star tracker inertial attitude. The measurements are then sent to the main flight computer's Kalman filter to update the onboard state vector. The images are, of course, collected over an arc to converge the state and estimate velocity. The same basic technique was used by Apollo to satisfy loss-of-comm, but Apollo used manual crew sightings with a vehicle-integral sextant instead of autonomously processing optical imagery. The software development is past its Critical Design Review, and is progressing through test and certification for human rating. In support of this, a hardware-in-the-loop test rig was developed in the Johnson Space Center Electro-Optics Lab to exercise the OpNav system prior to integrated testing on the Orion vehicle. Figure 2 shows the rig, which the test team has dubbed OCILOT (Orion Camera In the Loop Optical Testbed). Analysis performed to date shows a delivery that satisfies an allowable entry corridor as shown in Figure 3.

Holt, Greg N.↗

Robotic Technology Efforts at the NASA/Johnson Space Center

The NASA/Johnson Space Center has been developing robotic systems in support of space exploration for more than two decades. The goal of the Center’s Robotic Systems Technology Branch is to design and build hardware and software to assist astronauts in performing their mission. These systems include: rovers, humanoid robots, inspection devices and wearable robotics. Inspection systems provide external views of space vehicles to search for surface damage and also maneuver inside restricted areas to verify proper connections. New concepts in human and robotic rovers offer solutions for navigating difficult terrain expected in future planetary missions. An important objective for humanoid robots is to relieve the crew of “dull, dirty or dangerous” tasks allowing them more time to perform their important science and exploration missions. Wearable robotics one of the Center’s newest development areas can provide crew with low mass exercise capability and also augment an astronaut’s strength while wearing a space suit.This presentation will describe the robotic technology and prototypes developed at the Johnson Space Center that are the basis for future flight systems. An overview of inspection robots will show their operation on the ground and in-orbit. Rovers with independent wheel modules, crab steering, and active suspension are able to climb over large obstacles, and nimbly maneuver around others. Humanoid robots, including the First Humanoid Robot in Space: Robonaut 2, demonstrate capabilities that will lead to robotic caretakers for human habitats in space, and on Mars. The Center’s Wearable Robotics Lab supports work in assistive and sensing devices, including exoskeletons, force measuring shoes, and grasp assist gloves.

Diftler, Ron↗

Orion Optical Navigation Progress Toward Exploration Mission 1

Optical navigation of human spacecraft was proposed on Gemini and implemented successfully on Apollo as a means of autonomously operating the vehicle in the event of lost communication with controllers on Earth. The Orion emergency return system utilizing optical navigation has matured in design over the last several years, and is currently undergoing the final implementation and test phase in preparation for Exploration Mission 1 (EM-1) in 2019. The software development is past its Critical Design Review, and is progressing through test and certification for human rating. The filter architecture uses a square-root-free UDU covariance factorization. Linear Covariance Analysis (LinCov) was used to analyze the measurement models and the measurement error models on a representative EM-1 trajectory. The Orion EM-1 flight camera was calibrated at the Johnson Space Center (JSC) electro-optics lab. To permanently stake the focal length of the camera a 500 mm focal length refractive collimator was used. Two Engineering Design Unit (EDU) cameras and an EDU star tracker were used for a live-sky test in Denver. In-space imagery with high-fidelity truth metadata is rare so these live-sky tests provide one of the closest real-world analogs to operational use. A hardware-in-the-loop test rig was developed in the Johnson Space Center Electro-Optics Lab to exercise the OpNav system prior to integrated testing on the Orion vehicle. The software is verified with synthetic images. Several hundred off-nominal images are also used to analyze robustness and fault detection in the software. These include effects such as stray light, excess radiation damage, and specular reflections, and are used to help verify the tuning parameters chosen for the algorithms such as earth atmosphere bias, minimum pixel intensity, and star detection thresholds.

Holt, Greg N.↗

The Design of the Reference Orbit for NISAR, the NASA-ISRO Synthetic Aperture Radar Mission

The NISAR mission plans to use a 12-day-repeating sun-synchronous orbit for repeat-pass interferometry at multiple time scales using SAR data. For the interferometry to work the radar measurements must be made from within a critical baseline, which happens if all of the orbits are maintained to be within a fixed tube around a reference orbit. This paper describes the choice of dynamical models used in defining such a reference orbit, the perturbative effects of dynamics not considered in the repeat orbit, and the process of designing the orbit to repeat. We also describe our method for sharing the repeat orbit among multiple mission participants who use different models and software.

Hatch, Sara J.↗

The Design of the Reference Orbit for NISAR, the NASA-ISRO Synthetic Aperture Radar Mission

The NISAR mission plans to use a 12-day-repeating sun-synchronous orbit for repeat-pass interferometry at multiple time scales using SAR data. For the interferometry to work the radar measurements must be made from within a critical baseline, which happens if all of the orbits are maintained to be within a fixed tube around a reference orbit. This paper describes the choice of dynamical models used in defining such a reference orbit, the perturbative effects of dynamics not considered in the repeat orbit, and the process of designing the orbit to repeat. We also describe our method for sharing the repeat orbit among multiple mission participants who use different models and software.

Hatch, Sara J.↗

Terrain Relative Navigation in a Lunar Landing Scenario Using autoNGC

NASA Goddard Space Flight Center is developing Autonomous Navigation Guidance and Control (autoNGC) as a flight software system for future onboard use for missions in a variety of orbital regimes, including cislunar space and beyond. This paper describes processor-in-the-loop (PIL) testing using a lunar landing scenario with terrain relative navigation (TRN) and weak-signal GPS. We give an overview of the autoNGC project and describe preliminary navigation simulation results. We also describe the TRN PIL tests on a flight-like development board, using simulated images rendered from Lunar Reconnaissance Orbit high-resolution digital terrain models. The navigation simulations show that weak-signal GPS combined with TRN during a descent from a low lunar parking orbit results in sufficiently low navigation uncertainties to support such a mission profile independent of ground-based navigation. The PIL tests show that onboard image processing and landmark correlation is achievable at a sufficiently high measurement rate.

Michael A Shoemaker↗

Quality Assurance of ISS LIS lightning Data

Optical lighting detection from space has been ongoing since 1995 from the Optical Transient detector (1995-2000), then later by the Lightning Imaging Sensors (LIS) on the Tropical Rainfall Measuring Mission (TRMM) satellite (1997-2015) and the International Space Station (ISS) (ISS 2017-present). A rapid readout (2 ms) 128x128 pixel CCD (Charge-coupled Device) array detects optical transients from lightning (events) and transmits the observations to ground. Ground processing determines whether individual events are likely due to lightning or noise. Likely lightning events are then grouped into groups, flashes, and areas and their location on the earth are determined. The lightning data are saved in orbit files; each file containing the time, location, and intensity of the lightning events, groups, flashes, and areas detected during one orbit. Even after this processing anomalies may exist in some of the orbits. A manual quality assurance (QA) procedure is performed monthly to assess the data and omit orbits with obvious anomalies from the dataset. These files are not included in the final dataset that has undergone QA. The manual QA was developed during the OTD mission to identify artifacts that made it through ground processing algorithms. The manual QA process was continued for the TRMM and ISS LIS missions. Many anomalies have been identified and software updates now address many of them. However, some anomalies still occur in the processed datasets. The manual QA process examines the data for obvious issues in the lightning files that passed through the processing algorithms. These files are considered anomalous and are not included in the final QA dataset. Some issues that may cause an orbit to be considered anomalous include: obvious noise (excess events that make it through the processing), suspect geolocation, and excessive missing data packets. As an example, one way noise manifests is as “streaks” in lightning climatology plots. These streaks are especially apparent in low lightning rate regions (eg., over oceans). Since there is no method at present to extract these anomalies during processing, orbit files with significant anomalies are identified and removed from the final QA ISS LIS dataset. The final QA dataset can be obtained files from the Global Hydrometeorological Resource Center (GHRC). This presentation will provide examples of the various anomalies and examine how often the various anomalies occur and how much data is lost due to the omission of the anomalous orbits. Comparisons with OTD and TRMM LIS will also be examined.

ISS↗

Smarter Software For Enhanced Vehicle Health Monitoring and Inter-Planetary Exploration

The existing philosophy for space mission control was born in the early days of the space program when technology did not exist to put significant control responsibility onboard the spacecraft. NASA relied on a team of ground control experts to troubleshoot systems when problems occurred. As computing capability improved, more responsibility was handed over to the systems software. However, there is still a large contingent of both launch and flight controllers supporting each mission. New technology can update this philosophy to increase mission assurance and reduce the cost of inter-planetary exploration. The advent of model-based diagnosis and intelligent planning software enables spacecraft to handle most routine problems automatically and allocate resources in a flexible way to realize mission objectives. The manifests for recent missions include multiple subsystems and complex experiments. Spacecraft must operate at longer distances from earth where communications delays make earthbound command and control impractical. NASA's Ames Research Center (ARC) has demonstrated the utility of onboard diagnosis and planning with the Remote Agent experiment in 1999. KSC has pioneered model-based diagnosis and demonstrated its utility for ground support operations. KSC and ARC are cooperating in research to improve the state of the art of this technology. This paper highlights model-based reasoning applications for Moon and Mars missions including in-situ resource utilization and enhanced vehicle health monitoring.

Larson, William E.↗

Modular Software for Spacecraft Navigation Using the Global Positioning System (GPS)

The Goddard Space Flight Center Flight Dynamics and Mission Operations Divisions have jointly investigated the feasibility of engineering modular Global Positioning SYSTEM (GPS) navigation software to support both real time flight and ground postprocessing configurations. The goals of this effort are to define standard GPS data interfaces and to engineer standard, reusable navigation software components that can be used to build a broad range of GPS navigation support applications. The paper discusses the GPS modular software (GMOD) system and operations concepts, major requirements, candidate software architecture, feasibility assessment and recommended software interface standards. In additon, ongoing efforts to broaden the scope of the initial study and to develop modular software to support autonomous navigation using GPS are addressed,

Truong, S. H.↗