Search NASA⌕ Search

SEARCH · Search NASA

Results for “Onboard Flight 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 109 records · Page 6

An Onboard ISS Virtual Reality Trainer

Prior to the retirement of the Space Shuttle, many exterior repairs on the International Space Station (ISS) were carried out by shuttle astronauts, trained on the ground and flown to the station to perform these repairs. After the retirement of the shuttle, this is no longer an available option. As such, the need for the ISS crew members to review scenarios while on flight, either for tasks they already trained or for contingency operations has become a very critical subject. In many situations, the time between the last session of Neutral Buoyancy Laboratory (NBL) training and an Extravehicular Activity (EVA) task might be 6 to 8 months. In order to help with training for contingency repairs and to maintain EVA proficiency while on flight, the Johnson Space Center Virtual Reality Lab (VRLab) designed an onboard immersive ISS Virtual Reality Trainer (VRT), incorporating a unique optical system and making use of the already successful Dynamic Onboard Ubiquitous Graphical (DOUG) graphics software, to assist crew members with current procedures and contingency EVAs while on flight. The VRT provides an immersive environment similar to the one experienced at the VRLab crew training facility at NASA Johnson Space Center. EVA tasks are critical for a mission since as time passes the crew members may lose proficiency on previously trained tasks. In addition, there is an increased need for unplanned contingency repairs to fix problems arising as the ISS ages. The need to train and re-train crew members for EVAs and contingency scenarios is crucial and extremely demanding. ISS crew members are now asked to perform EVA tasks for which they have not been trained and potentially have never seen before.

Miralles, Evelyn↗

Orion Entry Display Feeder and Interactions with the Entry Monitor System

The Orion spacecraft is designed to return astronauts to a landing within 10 km of the intended landing target from low Earth orbit, lunar direct-entry, and lunar skip-entry trajectories. Al pile the landing is nominally controlled autonomously, the crew can fly precision entries manually in the event of an anomaly. The onboard entry displays will be used by the crew to monitor and manually fly the entry, descent, and landing, while the Entry Monitor System (EMS) will be used to monitor the health and status of the onboard guidance and the trajectory. The entry displays are driven by the entry display feeder, part of the Entry Monitor System (EMS). The entry re-targeting module, also part of the EMS, provides all the data required to generate the capability footprint of the vehicle at any point in the trajectory, which is shown on the Primary Flight Display (PFD). It also provides caution and warning data and recommends the safest possible re-designated landing site when the nominal landing site is no longer within the capability of the vehicle. The PFD and the EMS allow the crew to manually fly an entry trajectory profile from entry interface until parachute deploy having the flexibility to manually steer the vehicle to a selected landing site that best satisfies the priorities of the crew. The entry display feeder provides data from the ENIS and other components of the GNC flight software to the displays at the proper rate and in the proper units. It also performs calculations that are specific to the entry displays and which are not made in any other component of the flight software. In some instances, it performs calculations identical to those performed by the onboard primary guidance algorithm to protect against a guidance system failure. These functions and the interactions between the entry display feeder and the other components of the EMS are described.

Baird, Darren↗

Recent Flight Results of the TRMM Kalman Filter

The Tropical Rainfall Measuring Mission (TRMM) spacecraft is a nadir pointing spacecraft that nominally controls the roll and pitch attitude based on the Earth Sensor Assembly (ESA) output. TRMM's nominal orbit altitude was 350 km, until raised to 402 km to prolong mission life. During the boost, the ESA experienced a decreasing signal to noise ratio, until sun interference at 393 km altitude made the ESA data unreliable for attitude determination. At that point, the backup attitude determination algorithm, an extended Kalman filter, was enabled. After the boost finished, TRMM reacquired its nadir-pointing attitude, and continued its mission. This paper will briefly discuss the boost and the decision to turn on the backup attitude determination algorithm. A description of the extended Kalman filter algorithm will be given. In addition, flight results from analyzing attitude data and the results of software changes made onboard TRMM will be discussed. Some lessons learned are presented.

Andrews, Stephen F.↗

Advances in High-rate Delay Tolerant Networking On-board the International Space Station

The High-rate Delay Tolerant Networking (HDTN) project at the NASA John H. Glenn Research Center (GRC) is developing a performance optimized Delay Tolerant Networking (DTN) implementation which is able to provide reliable multigigabit per second automated network communications for near-Earth and deep space missions. To that end, this paper provides an overview of the testing and integration efforts culminating in a high-rate DTN demonstration onboard the International Space Station (ISS). Over several years, the HDTN team has performed a series of end-to-end tests between the Software Development and Integration Laboratory (SDIL) at the Lyndon B. Johnson Space Center (JSC) and Marshall Space Flight Center’s Huntsville Operations Support Center (HOSC). The testing has focused on a realistic emulation of the ISS Ku-band RF link, which operates at a maximum of 500 Mbps downlink with a 600 ms round-trip time. In this environment, the HDTN onboard gateway has been tested for interoperability with ISS payload nodes and the DTN ground gateway, store and forward capability, reliable transport using the Licklider Transmission Protocol (LTP), and successful recovery from unexpected loss of signal. In addition to integration testing, HDTN has developed a series of software engineering practices to ensure the stability and maturity of the implementation. As the result, HDTN has successfully demonstrated high-rate DTN services onboard the ISS. This paper concludes with a summary of preliminary flight testing results from the Integrated LCRD LEO User Modem and Amplifier Terminal networking experiments.

Delay tolerant networking↗

Lessons Learned from OSIRIS-Rex Autonomous Navigation Using Natural Feature Tracking

The Origins, Spectral Interpretation, Resource Identification, Security-Regolith Explorer (Osiris-REx) spacecraft is scheduled to launch in September, 2016 to embark on an asteroid sample return mission. It is expected to rendezvous with the asteroid, Bennu, navigate to the surface, collect a sample (July 20), and return the sample to Earth (September 23). The original mission design called for using one of two Flash Lidar units to provide autonomous navigation to the surface. Following Preliminary design and initial development of the Lidars, reliability issues with the hardware and test program prompted the project to begin development of an alternative navigation technique to be used as a backup to the Lidar. At the critical design review, Natural Feature Tracking (NFT) was added to the mission. NFT is an onboard optical navigation system that compares observed images to a set of asteroid terrain models which are rendered in real-time from a catalog stored in memory on the flight computer. Onboard knowledge of the spacecraft state is then updated by a Kalman filter using the measured residuals between the rendered reference images and the actual observed images. The asteroid terrain models used by NFT are built from a shape model generated from observations collected during earlier phases of the mission and include both terrain shape and albedo information about the asteroid surface. As a result, the success of NFT is highly dependent on selecting a set of topographic features that can be both identified during descent as well as reliably rendered using the shape model data available. During development, the OSIRIS-REx team faced significant challenges in developing a process conducive to robust operation. This was especially true for terrain models to be used as the spacecraft gets close to the asteroid and higher fidelity models are required for reliable image correlation. This paper will present some of the challenges and lessons learned from the development of the NFT system which includes not just the flight hardware and software but the development of the terrain models used to generate the onboard rendered images.

Navigation↗

The State of NOS3

The NASA Operational Simulator for Small Satellites (NOS3) showcases some of the Jon McBride Software Testing and Research (JSTAR) laboratories technologies on an open-source platform. NOS3 is a software digital twin providing a virtualized platform inside which you have your traditional flight software, ground software, environmental simulators, and middleware to keep all pieces in sync. NOS3 leverages the core Flight System (cFS), OpenC3 COSMOS, and NASA GSFC’s 42 software as the baseline to which additional research technologies can be developed. Current technologies to be demonstrated include NOS3 Igniter, constellation support, NASA JPL’s SYNOPSIS integration, and NASA GSFC’s OnAir. NOS3 Igniter is a GUI in which you can configure, build, and run your simulation. This along with improvements to the documentation and training available open source aims to reduce the ramp up time with new users and improve accessibility. As constellations introduce another level of complexity, it is important to ensure the baseline design reference mission covers all the basics required and allows users to experiment, understand, and test at all levels of the system. The Science Yield improvement via Onboard Prioritization and Summary of Information Systems (SYNOPSIS) is an open-source tool developed by NASA JPL to enable data prioritization and planning. GSFC’s Onboard Artificial Intelligence Research (OnAIR) enables custom algorithm development written in python to interface with the flight software allowing scientists to develop what they need for the next generation of missions and easily interface back to the traditional flight software. During the presentation, a review and demonstration of the above technologies is planned along with a roadmap.

NOS3↗

Universal Lambert and Kepler algorithms for autonomous rendezvous

This paper describes Lambert and Kepler algorithms designed to be the core of an autonomous rendezvous guidance system for an onboard computer. Applications include robotic and piloted missions to the moon and planets. Flight software must be compact, fast, and totally reliable. Although high accuracy is not essential for flight, in double precision these algorithms are accurate to at least 14 places almost everywhere. Both are universal; they apply to elliptic, parabolic, hyperbolic, and even rectilinear trajectories. The algorithms are improvements to those published by Battin (1987).

Klumpp, Allan R.↗

In-Space Networking on NASA's SCAN Testbed

The NASA Space Communications and Navigation (SCaN) Testbed, an external payload onboard the International Space Station, is equipped with three software defined radios and a flight computer for supporting in-space communication research. New technologies being studied using the SCaN Testbed include advanced networking, coding, and modulation protocols designed to support the transition of NASAs mission systems from primarily point to point data links and preplanned routes towards adaptive, autonomous internetworked operations needed to meet future mission objectives. Networking protocols implemented on the SCaN Testbed include the Advanced Orbiting Systems (AOS) link-layer protocol, Consultative Committee for Space Data Systems (CCSDS) Encapsulation Packets, Internet Protocol (IP), Space Link Extension (SLE), CCSDS File Delivery Protocol (CFDP), and Delay-Tolerant Networking (DTN) protocols including the Bundle Protocol (BP) and Licklider Transmission Protocol (LTP). The SCaN Testbed end-to-end system provides three S-band data links and one Ka-band data link to exchange space and ground data through NASAs Tracking Data Relay Satellite System or a direct-to-ground link to ground stations. The multiple data links and nodes provide several upgradable elements on both the space and ground systems. This paper will provide a general description of the testbeds system design and capabilities, discuss in detail the design and lessons learned in the implementation of the network protocols, and describe future plans for continuing research to meet the communication needs for evolving global space systems.

space networks↗

SCaN Testbed Software Development and Lessons Learned

National Aeronautics and Space Administration (NASA) has developed an on-orbit, adaptable, Software Defined Radio (SDR)Space Telecommunications Radio System (STRS)-based testbed facility to conduct a suite of experiments to advance technologies, reduce risk, and enable future mission capabilities on the International Space Station (ISS). The SCAN Testbed Project will provide NASA, industry, other Government agencies, and academic partners the opportunity to develop and field communications, navigation, and networking technologies in the laboratory and space environment based on reconfigurable, SDR platforms and the STRS Architecture.The SDRs are a new technology for NASA, and the support infrastructure they require is different from legacy, fixed function radios. SDRs offer the ability to reconfigure on-orbit communications by changing software for new waveforms and operating systems to enable new capabilities or fix any anomalies, which was not a previous option. They are not stand alone devices, but required a new approach to effectively control them and flow data. This requires extensive software to be developed to utilize the full potential of these reconfigurable platforms. The paper focuses on development, integration and testing as related to the avionics processor system, and the software required to command, control, monitor, and interact with the SDRs, as well as the other communication payload elements. An extensive effort was required to develop the flight software and meet the NASA requirements for software quality and safety. The flight avionics must be radiation tolerant, and these processors have limited capability in comparison to terrestrial counterparts. A big challenge was that there are three SDRs onboard, and interfacing with multiple SDRs simultaneously complicatesd the effort. The effort also includes ground software, which is a key element for both the command of the payload, and displaying data created by the payload. The verification of the software was an extensive effort. The challenges of specifying a suitable test matrix with reconfigurable systems that offer numerous configurations is highlighted. Since the flight system testing requires methodical, controlled testing that limits risk, a nearly identical ground system to the on-orbit flight system was required to develop the software and write verification procedures before it was installed and tested on the flight system. The development of the SCAN testbed was an accelerated effort to meet launch constraints, and this paper discusses tradeoffs made to balance needed software functionality and still maintain the schedule. Future upgrades are discussed that optimize the avionics and allow experimenters to utilize the SCAN testbed potential.

radio communication↗

In-Flight Evaluation of the Traffic Aware Planner on the NASA HU-25A Guardian Aircraft

NASA’s Traffic Aware Planner (TAP) software is a research-prototype decision support tool that provides pilots with time- and fuel-saving route recommendations that optimize their current trajectory. The software runs on a first-of-a-kind system architecture onboard three aircraft in revenue service conducting operational evaluations with a major domestic airline. Therefore, significant NASA-internal testing is required prior to releasing the software to the partner airline. This paper describes a flight test plan that exercises the functionality of the TAP software in a representative operational environment, describes the system architecture developed and implemented for the NASA Langley HU-25A Guardian aircraft to support the test objectives, presents outcomes of the flight test campaign, and discusses use cases that demonstrate the value of flight testing for this activity.Research into flight path optimization of transport aircraft conducted by the National Aeronautics and SpaceAdministration (NASA) has produced an operational concept known as Traffic Aware Strategic Aircrew Requests(TASAR) [1, 2]. This near-term concept [3] provides the aircrew with a flight deck decision support tool known asthe Traffic Aware Planner (TAP). The TAP software leverages a growing number of information sources on the flightdeck to make time- and fuel-saving route optimization recommendations to the aircrew while en route. The aircrewcan then use the suggestions provided by the tool to make route change requests with a greater likelihood of acceptanceby air traffic control (ATC). Since TASAR is a concept intended for the current operational environment, it isintentionally designed to have no safety-critical impact or require any changes to current Federal AviationAdministration (FAA) rules and procedures [4, 5].The research prototype TAP system [6–8], explained further in Section III.C, continually incorporates up-to-dateaircraft state data from onboard avionics, as well as the latest position of surrounding traffic, the most recent windforecast, and the most recent convective weather forecast, in order to calculate candidate trajectory modifications thatimprove upon the current active route. These trajectories account for user-selectable objective functions [3] of reducedfuel burn, reduced flight time, or an airline-derived combination of factors known as trip cost. Previous analyses andsimulations have estimated substantial savings for airlines employing this technique within the U.S. National AirspaceSystem (NAS) [9–11]. Operational evaluations with Alaska Airlines seek to validate these projected benefits usingmeasured data while simultaneously providing benefits to the airline [12, 13].The TAP software has undergone a number of human-in-the-loop simulations [14] and flight test activities[15–17] in order to validate the operational concept, evaluate human factors considerations (e.g., workload, usability,distraction, etc.), and to assess the ability of the software to function in a representative operational environment (e.g.,connected to live avionics data, using in-flight internet connectivity, etc.). However, these simulations and flight testcampaigns did not account for the hardware architecture implemented on the three aircraft for Alaska Airlines’operational evaluations of the TAP software. Therefore, a need was identified to thoroughly test the functionality ofthe software in a similar hardware architecture to that of the partner airline’s aircraft. Information regarding testapparatus and environments used to evaluate TAP prior to testing on the HU-25A can be found in reference [18].A campaign of flight trials on a NASA aircraft, the HU-25A Guardian, was conducted to ensure that the researchprototype TAP system functions well in a configuration similar to the Alaska Airlines aircraft prior to deployment.This airborne, networked environment enables an assessment of the operational factors unique to the flight environment. Additionally, this activity evaluated the effectiveness and benefit of new TAP functionality andoperation in a relevant flight environment while allowing the rapid prototyping of new concepts and features.This paper is organized as follows: Section II discusses the details of the flight test plan, flight profiles, and theduties of personnel involved with conducting flight operations. Section III describes the test platform, avionicsequipage, and system architecture. Section IV presents a discussion of results, and Section V contains concludingremarks.

Underwood, Matthew C.↗

Integration of an Arm Kinematics Hot Patch onboard the Curiosity Rover

NASA's Mars Science Laboratory (MSL) mission has updated the Curiosity rover's flight software multiple times since landing on Mars on August 6, 2012. The most common patching method has been a hot patch, in which running flight software is modified after being copied into RAM from its persistent storage. The latest hot patch to be installed on Curiosity fixed an issue in the robotic arm software that computes generalized inverse kinematics. Additional unit testing performed since the start of the surface mission revealed that this software can sometimes produce erroneous solutions.The cause was identified as numerical instability in a quartic root finder. When the inputs to that solver are not well conditioned, floating-point numerical issuescan cause erroneous roots to be reported. In theory, this could result in the robotic arm turret instruments being commanded to unintended positions, for example, below the terrain surface. Out of approximately 3.7 million unit test cases, 97.2\% of the position errors were below 5 mm. However, there were 16 test cases where theposition error was greater than 20 cm, and the maximum position error was 1.2 meters.The patch was uploaded to Curiosity on sol 2642 (January 11, 2020) after the solution was developed, re-implemented as a hot patch, and validated and verified using Earth-based Curiosity testbeds. A checkout test of the patch was performed on Curiosity on sol 2657, and nominal use of the patch began on sol 2658. In this paper, we describe the steps that led to integrating the arm kinematic hot patch into Curiosity's flight software, from the discovery of the bug to the nominal use of the patch in flight.

Maimone, Mark↗

Feasibility of using a knowledge-based system concept for in-flight primary flight display research

A study was conducted to determine the feasibility of using knowledge-based systems architectures for inflight research of primary flight display information management issues. The feasibility relied on the ability to integrate knowledge-based systems with existing onboard aircraft systems. And, given the hardware and software platforms available, the feasibility also depended on the ability to use interpreted LISP software with the real time operation of the primary flight display. In addition to evaluating these feasibility issues, the study determined whether the software engineering advantages of knowledge-based systems found for this application in the earlier workstation study extended to the inflight research environment. To study these issues, two integrated knowledge-based systems were designed to control the primary flight display according to pre-existing specifications of an ongoing primary flight display information management research effort. These two systems were implemented to assess the feasibility and software engineering issues listed. Flight test results were successful in showing the feasibility of using knowledge-based systems inflight with actual aircraft data.

Ricks, Wendell R.↗

Flight test evaluation of a digital controller used in a VTOL automatic approach and landing system

As part of the NASA Langley Research Center's effort to develop technology for VTOL operation in the air transportation system in the late 1980's and beyond, research has been conducted aimed at developing digital controller design procedures. This paper describes the verification of one design procedure by the flight evaluation of an advanced digital control algorithm. The control algorithm, operating at 10 iterations per second, follows step guidance commands with zero steady state error and thus provides an autotrim capability for the nonlinear vehicle. Changes in vehicle dynamics are accounted for using a gain scheduling technique. This control algorithm is combined with sensor filters, a trajectory generator, and a closed loop guidance algorithm to form a VTOL autoland system. A CH-47 tandem rotor helicopter which contains a set of sensors, onboard digital flight computers and electro-hydraulic actuators is used in the evaluation. All software, except input-output routines, is coded in FORTRAN using floating point arithmetic and executed in the flight computer. This autoland system is exercised by automatically flying straight-in descending decelerating trajectories typical of VFR manual approaches to a predetermined landing pad.

Downing, D. R.↗

Shuttle entry performance and stability and control derivatives extraction from flight measurement data

Flight data taken from three Shuttle Space Transportation System flights (STS-1, 2, and 3) during entry are analyzed to determine the shuttle performance and aerodynamic characteristics. Correlations of the performance coefficients and the stability and control derivatives with preflight predictions are presented over the hypersonic speed range from Mach 2 to 25. In addition, an evaluation of the effectiveness of the onboard Reaction Control System (RCS) is given and an effort is made to independently quantify the combined impingement and flow-field interaction effects on the spacecraft rolling moment. Comparisons of stability and control derivatives extracted for the same flight conditions, but using data from different onboard sensors are also made. Results obtained using the same flight data, but different computer software are also shown.

Compton, H. R.↗

Web Design for Space Operations: An Overview of the Challenges and New Technologies Used in Developing and Operating Web-Based Applications in Real-Time Operational Support Onboard the International Space Station, in Astronaut Mission Planning and Mission Control Operations

The International Space Station (ISS) Operations Planning Team, Mission Control Centre and Mission Automation Support Network (MAS) have all evolved over the years to use commercial web-based technologies to create a configurable electronic infrastructure to manage the complex network of real-time planning, crew scheduling, resource and activity management as well as onboard document and procedure management required to co-ordinate ISS assembly, daily operations and mission support. While these Web technologies are classified as non-critical in nature, their use is part of an essential backbone of daily operations on the ISS and allows the crew to operate the ISS as a functioning science laboratory. The rapid evolution of the internet from 1998 (when ISS assembly began) to today, along with the nature of continuous manned operations in space, have presented a unique challenge in terms of software engineering and system development. In addition, the use of a wide array of competing internet technologies (including commercial technologies such as .NET and JAVA ) and the special requirements of having to support this network, both nationally among various control centres for International Partners (IPs), as well as onboard the station itself, have created special challenges for the MCC Web Tools Development Team, software engineers and flight controllers, who implement and maintain this system. This paper presents an overview of some of these operational challenges, and the evolving nature of the solutions and the future use of COTS based rich internet technologies in manned space flight operations. In particular this paper will focus on the use of Microsoft.s .NET API to develop Web-Based Operational tools, the use of XML based service oriented architectures (SOA) that needed to be customized to support Mission operations, the maintenance of a Microsoft IIS web server onboard the ISS, The OpsLan, functional-oriented Web Design with AJAX

Khan, Ahmed↗

High speed simulator: A simulator for all seasons

The evolution of a high speed spacecraft simulator (HSS) is discussed from development and operations perspectives. The HSS is a series of simulators capable of modeling the spacecraft and its subsystems at different levels. The HSS was developed for the validation of the Galileo low gain antenna mission's flight software. Due to the successful performance of the HSS in assisting with the flight software validation, additional Galileo validation applications were identified. These applications include the modeling of other onboard data systems, such as the command and data subsystem and the attitude and articulation control subsystem. The HSS architecture, which consists of a number of components, is described and the operational use of the system is outlined.

Patel, K.↗

Automation of Hubble Space Telescope Mission Operations

On June 13, 2011, after more than 21 years, 115 thousand orbits, and nearly 1 million exposures taken, the operation of the Hubble Space Telescope successfully transitioned from 24x7x365 staffing to 815 staffing. This required the automation of routine mission operations including telemetry and forward link acquisition, data dumping and solid-state recorder management, stored command loading, and health and safety monitoring of both the observatory and the HST Ground System. These changes were driven by budget reductions, and required ground system and onboard spacecraft enhancements across the entire operations spectrum, from planning and scheduling systems to payload flight software. Changes in personnel and staffing were required in order to adapt to the new roles and responsibilities required in the new automated operations era. This paper will provide a high level overview of the obstacles to automating nominal HST mission operations, both technical and cultural, and how those obstacles were overcome.

Burley, Richard↗

In-Space Networking On NASA's SCaN Testbed

The NASA Space Communications and Navigation (SCaN) Testbed, an external payload onboard the International Space Station, is equipped with three software defined radios (SDRs) and a programmable flight computer. The purpose of the Testbed is to conduct inspace research in the areas of communication, navigation, and networking in support of NASA missions and communication infrastructure. Multiple reprogrammable elements in the end to end system, along with several communication paths and a semi-operational environment, provides a unique opportunity to explore networking concepts and protocols envisioned for the future Solar System Internet (SSI). This paper will provide a general description of the system's design and the networking protocols implemented and characterized on the testbed, including Encapsulation, IP over CCSDS, and Delay-Tolerant Networking (DTN). Due to the research nature of the implementation, flexibility and robustness are considered in the design to enable expansion for future adaptive and cognitive techniques. Following a detailed design discussion, lessons learned and suggestions for future missions and communication infrastructure elements will be provided. Plans for the evolving research on SCaN Testbed as it moves towards a more adaptive, autonomous system will be discussed.

space networks↗