Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Commanding”

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 1,135 records · Page 63
All sourcesNASA NTRSDOE OSTI
NASA NTRS2013

Multi-User Space Link Extension (SLE) System

The Multi-User Space (MUS) Link Extension system, a software and data system, provides Space Link Extension (SLE) users with three space data transfer services in timely, complete, and offline modes as applicable according to standards defined by the Consultative Committee for Space Data Systems (CCSDS). MUS radically reduces the schedule, cost, and risk of implementing a new SLE user system, minimizes operating costs with a lights-out approach to SLE, and is designed to require no sustaining engineering expense during its lifetime unless changes in the CCSDS SLE standards, combined with new provider implementations, force changes. No software modification to MUS needs to be made to support a new mission. Any systems engineer with Linux experience can begin testing SLE user service instances with MUS starting from a personal computer (PC) within five days. For flight operators, MUS provides a familiar-looking Web page for entering SLE configuration data received from SLE. Operators can also use the Web page to back up a space mission's entire set of up to approximately 500 SLE service instances in less than five seconds, or to restore or transfer from another system the same amount of data from a MUS backup file in about the same amount of time. Missions operate each MUS SLE service instance independently by sending it MUS directives, which are legible, plain ASCII strings. MUS directives are usually (but not necessarily) sent through a TCP-IP (Transmission Control Protocol Internet Protocol) socket from a MOC (Mission Operations Center) or POCC (Payload Operations Control Center) system, under scripted control, during "lights-out" spacecraft operation. MUS permits the flight operations team to configure independently each of its data interfaces; not only commands and telemetry, but also MUS status messages to the MOC. Interfaces can use single- or multiple-client TCP/IP server sockets, TCP/IP client sockets, temporary disk files, the system log, or standard in, standard out, or standard error as applicable. By defining MUS templates in ASCII, the flight operations team can include any MUS system variable in telemetry or command headers or footers, and/or in status messages. Data fields can be arranged within messages in different sequences, according to the mission s needs. The only constraints imposed are on the format of MUS directive strings, and some bare minimum logical requirements that must be met in order for MUS to read the mission control center's spacecraft command inputs. The MUS system imposes no limits or constraints on the numbers and combinations of missions and SLE service instances that it will support simultaneously. At any time, flight operators may add, change, delete, bind, connect, or disconnect.

Perkins, Toby↗
NASA NTRS2013

Phoenix Telemetry Processor

Phxtelemproc is a C/C++ based telemetry processing program that processes SFDU telemetry packets from the Telemetry Data System (TDS). It generates Experiment Data Records (EDRs) for several instruments including surface stereo imager (SSI); robotic arm camera (RAC); robotic arm (RA); microscopy, electrochemistry, and conductivity analyzer (MECA); and the optical microscope (OM). It processes both uncompressed and compressed telemetry, and incorporates unique subroutines for the following compression algorithms: JPEG Arithmetic, JPEG Huffman, Rice, LUT3, RA, and SX4. This program was in the critical path for the daily command cycle of the Phoenix mission. The products generated by this program were part of the RA commanding process, as well as the SSI, RAC, OM, and MECA image and science analysis process. Its output products were used to advance science of the near polar regions of Mars, and were used to prove that water is found in abundance there. Phxtelemproc is part of the MIPL (Multi-mission Image Processing Laboratory) system. This software produced Level 1 products used to analyze images returned by in situ spacecraft. It ultimately assisted in operations, planning, commanding, science, and outreach.

Stanboli, Alice↗
NASA NTRS2013

Evaluation of Flight Deck-Based Interval Management Crew Procedure Feasibility

Air traffic demand is predicted to increase over the next 20 years, creating a need for new technologies and procedures to support this growth in a safe and efficient manner. The National Aeronautics and Space Administration's (NASA) Air Traffic Management Technology Demonstration - 1 (ATD-1) will operationally demonstrate the feasibility of efficient arrival operations combining ground-based and airborne NASA technologies. The integration of these technologies will increase throughput, reduce delay, conserve fuel, and minimize environmental impacts. The ground-based tools include Traffic Management Advisor with Terminal Metering for precise time-based scheduling and Controller Managed Spacing decision support tools for better managing aircraft delay with speed control. The core airborne technology in ATD-1 is Flight deck-based Interval Management (FIM). FIM tools provide pilots with speed commands calculated using information from Automatic Dependent Surveillance - Broadcast. The precise merging and spacing enabled by FIM avionics and flight crew procedures will reduce excess spacing buffers and result in higher terminal throughput. This paper describes a human-in-the-loop experiment designed to assess the acceptability and feasibility of the ATD-1 procedures used in a voice communications environment. This experiment utilized the ATD-1 integrated system of ground-based and airborne technologies. Pilot participants flew a high-fidelity fixed base simulator equipped with an airborne spacing algorithm and a FIM crew interface. Experiment scenarios involved multiple air traffic flows into the Dallas-Fort Worth Terminal Radar Control airspace. Results indicate that the proposed procedures were feasible for use by flight crews in a voice communications environment. The delivery accuracy at the achieve-by point was within +/- five seconds and the delivery precision was less than five seconds. Furthermore, FIM speed commands occurred at a rate of less than one per minute, and pilots found the frequency of the speed commands to be acceptable at all times throughout the experiment scenarios.

Wilson, Sara R.↗
NASA NTRS2012

CASSIUS: The Cassini Uplink Scheduler

The Cassini Uplink Scheduler (CASSIUS) is cross-platform software used to generate a radiation sequence plan for commands being sent to the Cassini spacecraft. Because signals must travel through varying amounts of Earth's atmosphere, several different modes of constant telemetry rates have been devised. These modes guarantee that the spacecraft and the Deep Space Network agree with respect to the data transmission rate. However, the memory readout of a command will be lost if it occurs on a telemetry mode boundary. Given a list of spacecraft message files as well as the available telemetry modes, CASSIUS can find an uplink sequence that ensures safe transmission of each file. In addition, it can predict when the two on-board solid state recorders will swap. CASSIUS prevents data corruption by making sure that commands are not planned for memory readout during telemetry rate changes or a solid state recorder swap.

Cassini mission↗
NASA NTRS2014

Results from Testing Crew-Controlled Surface Telerobotics on the International Space Station

During Summer 2013, the Intelligent Robotics Group at NASA Ames Research Center conducted a series of tests to examine how astronauts in the International Space Station (ISS) can remotely operate a planetary rover. The tests simulated portions of a proposed lunar mission, in which an astronaut in lunar orbit would remotely operate a planetary rover to deploy a radio telescope on the lunar far side. Over the course of Expedition 36, three ISS astronauts remotely operated the NASA "K10" planetary rover in an analogue lunar terrain located at the NASA Ames Research Center in California. The astronauts used a "Space Station Computer" (crew laptop), a combination of supervisory control (command sequencing) and manual control (discrete commanding), and Ku-band data communications to command and monitor K10 for 11 hours. In this paper, we present and analyze test results, summarize user feedback, and describe directions for future research.

robotics↗
NASA NTRS2008

An Improved Wavefront Control Algorithm for Large Space Telescopes

Wavefront sensing and control is required throughout the mission lifecycle of large space telescopes such as James Webb Space Telescope (JWST). When an optic of such a telescope is controlled with both surface-deforming and rigid-body actuators, the sensitivity-matrix obtained from the exit pupil wavefront vector divided by the corresponding actuator command value can sometimes become singular due to difference in actuator types and in actuator command values. In this paper, we propose a simple approach for preventing a sensitivity-matrix from singularity. We also introduce a new "minimum-wavefront and optimal control compensator". It uses an optimal control gain matrix obtained by feeding back the actuator commands along with the measured or estimated wavefront phase information to the estimator, thus eliminating the actuator modes that are not observable in the wavefront sensing process.

adaptive optics↗
NASA NTRS2015

Fast Grasp Contact Computation for a Serial Robot

A system includes a controller and a serial robot having links that are interconnected by a joint, wherein the robot can grasp a three-dimensional (3D) object in response to a commanded grasp pose. The controller receives input information, including the commanded grasp pose, a first set of information describing the kinematics of the robot, and a second set of information describing the position of the object to be grasped. The controller also calculates, in a two-dimensional (2D) plane, a set of contact points between the serial robot and a surface of the 3D object needed for the serial robot to achieve the commanded grasp pose. A required joint angle is then calculated in the 2D plane between the pair of links using the set of contact points. A control action is then executed with respect to the motion of the serial robot using the required joint angle.

Shi, Jianying↗
NASA NTRS2008

Preparing Cassini Uplink Operations for Extended Mission

The Cassini-Huygens Mission to Saturn and Titan, a joint venture between the National Aeronautics and Space Administration, the European Space Agency, and the Italian Space Agency, is conducting a four-year, prime mission exploring the Saturnian system, including its atmosphere, rings, magnetosphere, moons and icy satellites. Launched in 1997, Cassini began its prime mission in 2004. Cassini is now preparing for a new era, a two-year extended mission to revisit many of the highlights and new discoveries made during the prime mission. Because of the light time delay from Earth to Saturn, and the time needed to coordinate the complicated science and engineering activities that take place on the spacecraft, commanding on Cassini is done in approximately 40-day intervals known as sequences. The Cassini Uplink Operations team is responsible for the final development and validation of the pointing profile and instrument and spacecraft commands that are contained in a sequence. During this final analysis prior to uplink to the spacecraft, thorough and exact evaluation is necessary to ensure there are no mistakes during commanding. In order to perform this evaluation, complete and refined processes and procedures are fundamental. The Uplink Operations team is also responsible for anomaly response during sequence execution, a process in which critical decisions often are made in real-time. Recent anomalies on other spacecraft missions have highlighted two major risks in the operations process: (1) personnel turnover and the retirement of critical knowledge and (2) aging, outdated operations procedures. If other missions are a good barometer, the Cassini extended mission will be presented with a high personnel turnover of the Cassini flight team, which could lead to a loss of expertise that has been essential to the success of the prime mission. In order to prepare the Cassini Uplink Operations Team for this possibility and to continue to develop and operate safe science and engineering sequences, a review and major update of the current documentation and operations procedures was needed. This paper will address the changes made to extended mission sequence generation processes primarily due to new restrictions in spacecraft operating capability and lessons learned from prime mission. In addition, it will address the state of the prime mission operations procedures, the philosophy changes and updates that were made to those procedures in response to process improvement, and the validation of those new procedures through the training of current and new personnel. And lastly, it will address the lessons learned throughout prime mission and how the Uplink Operations team chose to incorporate those lessons into the working documentation and team knowledge. This incorporation was necessary to facilitate the success of the extended mission with potentially all new personnel at some point prior to the end of the mission.

Maxwell, Jennifer L.↗
NASA NTRS2015

Hardware in the Loop Testing of an Iodine-Fed Hall Thruster

CUBESATS are relatively new spacecraft platforms that are typically deployed from a launch vehicle as a secondary payload,1 providing low-cost access to space for a wide range of end-users. These satellites are comprised of building blocks having dimensions of 10x10x10 cm cu and a mass of 1.33 kg (a 1-U size). While providing low-cost access to space, a major operational limitation is the lack of a propulsion system that can fit within a CubeSat and is capable of executing high delta v maneuvers. This makes it difficult to use CubeSats on missions requiring certain types of maneuvers (i.e. formation flying, spacecraft rendezvous). Recently, work has been performed investigating the use of iodine as a propellant for Hall-effect thrusters (HETs) 2 that could subsequently be used to provide a high specific impulse path to CubeSat propulsion. Iodine stores as a dense solid at very low pressures, making it acceptable as a propellant on a secondary payload. It has exceptionally high ρIsp (density times specific impulse), making it an enabling technology for small satellite near-term applications and providing the potential for systems-level advantages over mid-term high power electric propulsion options. Iodine flow can also be thermally regulated, subliming at relatively low temperature ( less than100 C) to yield I2 vapor at or below 50 torr. At low power, the measured performance of an iodine-fed HET is very similar to that of a state-of-the-art xenon-fed thruster. Just as importantly, the current-voltage discharge characteristics of low power iodine-fed and xenon-fed thrusters are remarkably similar, potentially reducing development and qualifications costs by making it possible to use an already-qualified xenon-HET PPU in an iodine-fed system. Finally, a cold surface can be installed in a vacuum test chamber on which expended iodine propellant can deposit. In addition, the temperature doesn't have to be extremely cold to maintain a low vapor pressure in the vacuum chamber (it is under 10(exp -6) torr at -75 C), making it possible to 'cryopump' the propellant with lower-cost recirculating refrigerant-based systems as opposed to using liquid nitrogen or low temperature gaseous helium cryopanels. In the present paper, we describe testing performed using an iodine-fed 200 W Hall thruster mounted to a thrust stand and operated in conjunction with MSFCs Small Projects Rapid Integration and Test Environment (SPRITE) Portable Hardware In the Loop (PHIL) hardware. This work is performed in support of the iodine satellite (iSAT) project, which aims to fly a 200-W iodine-fed thruster on a 12-U CubeSat. The SPRITE PHIL hardware allows a given vehicle to do a checkout of its avionics algorithm by allowing it to monitor and feed data to simulated sensors and effectors in a digital environment. These data are then used to determine the attitude of the vehicle and a separate computer is used to interpret the data set and visualize it using a 3D graphical interface. The PHIL hardware allows the testing of the vehicles bus by providing 'real' hardware interfaces (in the case of this test a real RS422 bus) and specific components can be modeled to show their interactions with the avionics algorithm (e.g. a thruster model). For the iSAT project the PHIL is used to visualize the operating cycle of the thruster and the subsequent effect this thrusting has on the attitude of the satellite over a given period of time. The test is controlled using software running on an Andrews Space Cortex 160 flight computer. This computer is the current baseline for a full iSAT mission. While the test could be conducted with a lab computer and software, the team chose to exercise the propulsion system with a representative CubeSat-class computer. For purposes of this test, the "flight" software monitored the propulsion and PPU systems, controlled operation of the thruster, and provided thruster state data to the PHIL simulation. Commands to operate the thruster were initiated from an operator's workstation outside the vacuum chamber and passed through the Cortex 160 to exercise portions of the flight avionics. Two custom-designed pieces of electronics hardware have been designed to operate the propellant feed system. One piece of hardware is an auxiliary board that controls a latch valve, proportional flow control valves (PFCVs) and valve heaters as well as measuring pressures, temperatures and PFCV feedback voltage. An onboard FPGA provides a serial link for issuing commands and manages all lower level input-output functions. The other piece of hardware is a power distribution board, which accepts a standard bus voltage input and converts this voltage into all the different current-voltage types required to operate the auxiliary board. These electronics boards are located in the vacuum chamber near the thruster, exposing this hardware to both the vacuum and plasma environments they would encounter during a mission, with these components communicating to the flight computer through an RS-422 interface. The auxiliary board FPGA provides a 28V MOSFET switch circuit with a 20ms pulse to open or close the iodine propellant feed system latch valve. The FPGA provides a pulse width modulation (PWM) signal to a DC/DC boost converter to produce the 12-120V needed for control of the proportional flow control valve. There are eight MOSFET-switched heating circuits in the system. Heaters are 28V and located in the latch valve, PFCV, propellant tank and propellant feed lines. Both the latch valve and PFCV have thermistors built into them for temperature monitoring. There are also seven resistance temperature device (RTD) circuits on the auxiliary board that can be used to measure the propellant tank and feedline temperatures. The signals are conditioned and sent to an analog to digital converter (ADC), which is directly commanded and controlled by the FPGA.

Polzin, Kurt A.↗
NASA NTRS2017

Unmanned Aircraft Systems (UAS) Integration in the National Airspace System (NAS) Project KDP-C Review

The topics discussed are the UAS-NAS project life-cycle and ARMD thrust flow down, as well as the UAS environments and how we operate in those environments. NASA's Armstrong Flight Research Center at Edwards, CA, is leading a project designed to help integrate unmanned air vehicles into the world around us. The Unmanned Aircraft Systems Integration in the National Airspace System project, or UAS in the NAS, will contribute capabilities designed to reduce technical barriers related to safety and operational challenges associated with enabling routine UAS access to the NAS. The project falls under the Integrated Systems Research Program office managed at NASA Headquarters by the agency's Aeronautics Research Mission Directorate. NASA's four aeronautics research centers - Armstrong, Ames Research Center, Langley Research Center, and Glenn Research Center - are part of the technology development project. With the use and diversity of unmanned aircraft growing rapidly, new uses for these vehicles are constantly being considered. Unmanned aircraft promise new ways of increasing efficiency, reducing costs, enhancing safety and saving lives 460265main_ED10-0132-16_full.jpg Unmanned aircraft systems such as NASA's Global Hawks (above) and Predator B named Ikhana (below), along with numerous other unmanned aircraft systems large and small, are the prime focus of the UAS in the NAS effort to integrate them into the national airspace. Credits: NASA Photos 710580main_ED07-0243-37_full.jpg The UAS in the NAS project envisions performance-based routine access to all segments of the national airspace for all unmanned aircraft system classes, once all safety-related and technical barriers are overcome. The project will provide critical data to such key stakeholders and customers as the Federal Aviation Administration and RTCA Special Committee 203 (formerly the Radio Technical Commission for Aeronautics) by conducting integrated, relevant system-level tests to adequately address safety and operational challenges of national airspace access by unmanned aircraft systems, or UAS. In the process, the project will work with other key stakeholders to define necessary deliverables and products to help enable such access. Within the project, NASA is focusing on five sub-projects. These five focus areas include assurance of safe separation of unmanned aircraft from manned aircraft when flying in the national airspace; safety-critical command and control systems and radio frequencies to enable safe operation of UAS; human factors issues for ground control stations; airworthiness certification standards for UAS avionics and integrated tests and evaluation designed to determine the viability of emerging UAS technology. Five Focus Areas of the UAS Integration in the NAS Project Separation Assurance Provide an assessment of how planned Next Generation Air Transportation System (NextGen) separation assurance systems, with different functional allocations, perform for UAS in mixed operations with manned aircraft Assess the applicability to UAS and the performance of NASA NextGen separation assurance systems in flight tests with realistic latencies and uncertain trajectories Assess functional allocations ranging from today's ground-based, controller-provided aircraft separation to fully autonomous airborne self-separation Communications Develop data and rationale to obtain appropriate frequency spectrum allocations to enable safe and efficient operation of UAS in the NAS Develop and validate candidate secure safety-critical command and control system/subsystem test equipment for UAS that complies with UAS international/national frequency regulations, standards and recommended practices and minimum operational and aviation system performance standards for UAS Perform analysis to support recommendations for integration of safety-critical command and control systems and air traffic control communications to ensure safe and efficient operation of UAS in the NAS Human Systems Integration Develop a research test bed and database to provide data and proof of concept for GCS - ground control station - operations in the NAS Coordinate with standards organizations to develop human-factors guidelines for GCS operation in the NAS Certification Define a UAS classification scheme and approach to determining Federal Aviation Regulation airworthiness requirements applicable to all UAS digital avionics Provide hazard and risk-related data to support development of type design criteria and best development practices Integrated Tests and Evaluation Integrate and test mature concepts from technical elements to demonstrate and test viability Evaluate the performance of technology development in a relevant environment (full-mission, human-in-the-loop simulations and flight tests)

outreach↗
NASA NTRS2017

Incorporating Speech Recognition into a Natural User Interface

The Augmented/ Virtual Reality (AVR) Lab has been working to study the applicability of recent virtual and augmented reality hardware and software to KSC operations. This includes the Oculus Rift, HTC Vive, Microsoft HoloLens, and Unity game engine. My project in this lab is to integrate voice recognition and voice commands into an easy to modify system that can be added to an existing portion of a Natural User Interface (NUI). A NUI is an intuitive and simple to use interface incorporating visual, touch, and speech recognition. The inclusion of speech recognition capability will allow users to perform actions or make inquiries using only their voice. The simplicity of needing only to speak to control an on-screen object or enact some digital action means that any user can quickly become accustomed to using this system. Multiple programs were tested for use in a speech command and recognition system. Sphinx4 translates speech to text using a Hidden Markov Model (HMM) based Language Model, an Acoustic Model, and a word Dictionary running on Java. PocketSphinx had similar functionality to Sphinx4 but instead ran on C. However, neither of these programs were ideal as building a Java or C wrapper slowed performance. The most ideal speech recognition system tested was the Unity Engine Grammar Recognizer. A Context Free Grammar (CFG) structure is written in an XML file to specify the structure of phrases and words that will be recognized by Unity Grammar Recognizer. Using Speech Recognition Grammar Specification (SRGS) 1.0 makes modifying the recognized combinations of words and phrases very simple and quick to do. With SRGS 1.0, semantic information can also be added to the XML file, which allows for even more control over how spoken words and phrases are interpreted by Unity. Additionally, using a CFG with SRGS 1.0 produces a Finite State Machine (FSM) functionality limiting the potential for incorrectly heard words or phrases. The purpose of my project was to investigate options for a Speech Recognition System. To that end I attempted to integrate Sphinx4 into a user interface. Sphinx4 had great accuracy and is the only free program able to perform offline speech dictation. However it had a limited dictionary of words that could be recognized, single syllable words were almost impossible for it to hear, and since it ran on Java it could not be integrated into the Unity based NUI. PocketSphinx ran much faster than Sphinx4 which would've made it ideal as a plugin to the Unity NUI, unfortunately creating a C# wrapper for the C code made the program unusable with Unity due to the wrapper slowing code execution and class files becoming unreachable. Unity Grammar Recognizer is the ideal speech recognition interface, it is flexible in recognizing multiple variations of the same command. It is also the most accurate program in recognizing speech due to using an XML grammar to specify speech structure instead of relying solely on a Dictionary and Language model. The Unity Grammar Recognizer will be used with the NUI for these reasons as well as being written in C# which further simplifies the incorporation.

Chapa, Nicholas↗
NASA NTRS2017

MSRR Rack Materials Science Research Rack

The Materials Science Research Rack (MSRR) is a research facility developed under a cooperative research agreement between NASA and the European Space Agency (ESA) for materials science investigations on the International Space Station (ISS). The MSRR is managed at the Marshall Space Flight Center (MSFC) in Huntsville, AL. The MSRR facility subsystems were manufactured by Teledyne Brown Engineering (TBE) and integrated with the ESA/EADS-Astrium developed Materials Science Laboratory (MSL) at the MSFC Space Station Integration and Test Facility (SSITF) as part of the Systems Development Operations Support (SDOS) contract. MSRR was launched on STS-128 in August 2009, and is currently installed in the U. S. Destiny Laboratory Module on the ISS. Materials science is an integral part of developing new, safer, stronger, more durable materials for use throughout everyday life. The goal of studying materials processing in space is to develop a better understanding of the chemical and physical mechanisms involved, and how they differ in the microgravity environment of space. To that end, the MSRR accommodates advanced investigations in the microgravity environment of the ISS for basic materials science research in areas such as solidification of metals and alloys. MSRR allows for the study of a variety of materials including metals, ceramics, semiconductor crystals, and glasses. Materials science research benefits from the microgravity environment of space, where the researcher can better isolate chemical and thermal properties of materials from the effects of gravity. With this knowledge, reliable predictions can be made about the conditions required on Earth to achieve improved materials. MSRR is a highly automated facility with a modular design capable of supporting multiple types of investigations. Currently the NASA-provided Rack Support Subsystem provides services (power, thermal control, vacuum access, and command and data handling) to the ESA developed Materials Science Laboratory (MSL) which accommodates interchangeable Furnace Inserts (FI). Two ESA-developed FIs are presently available on the ISS: the Low Gradient Furnace (LGF) and the Solidification and Quenching Furnace (SQF). Sample-Cartridge Assemblies (SCAs), each containing one or more material samples, are installed in the FI by the crew and can be processed at temperatures up to 1400 C. Once an SCA is installed, the experiment can be run by automatic command or science conducted via telemetry commands from the ground. This facility is available to support materials science investigations through programs such as the US National Laboratory, Technology Development, NASA Research Announcements, and others. TBE and MSFC are currently developing NASA Sample Cartridge Assemblies (SCA's) with a planned availability for launch in 2017.

Reagan, Shawn↗
NASA NTRS2018

GPM Mission's Best Practices: PERP

Similar to other missions, the Global Precipitation Measurement (GPM) Core Observatory's Command and Data Handling (C&DH) subsystem is critical for operations of the spacecraft. The onboard C&DH system comprises of two fully redundant boxes - a primary and a cold backup. Within each box, amongst other components, is a Single Board Computer (SBC) that hosts the flight software (FSW) system. In the event of an SBC reset, the Flight Operations Team (FOT) is poised with a lengthy task of restoring the SBC to nominal configuration. Due to the complexity of the C&DH system, this may take many days at a time to complete. The spacecraft's FSW applications are located in Electronically Erasable Programmable Read-Only Memory (EEPROM) and are copied into Random Access Memory (RAM) upon SBC initialization/reset. Each SBC has two banks of EEPROM, with each bank containing a copy of the FSW. Since launch, there have been many configuration changes to tables and applications that have been loaded into just RAM. Unfortunately, these changes are vulnerable to being wiped during a SBC initialization/reset, when the RAM is overwritten by the EEPROM. Although the EEPROM loads the default FSW configurations, the process to command non-default individual table and application changes is very cumbersome and time consuming. This consequentially increases the time until the spacecraft is back into nominal Mission Science Mode (MSM) drastically. The GPM Power-On Reset (POR) Expedited Recovery Process (PERP) Design introduces a method of consolidating commands into a single file load which the SBC can process independently of the ground - decreasing recovery time, the level of TDRS support reliance, and human error. This tested design can be implemented across many other missions that utilize a similar core Flight Executive (cFE) platform; hence providing an easy-to-follow, safe, and efficient process that can be applied across the board.

recovery↗
NASA NTRS2018

Blockchain Application Within a Multi-Sensor Satellite Architecture

With the thrust towards multi-sensor satellite architectures for earth and space exploration, such as constellations and swarms, new technologies are required to enable the transition to this future capability. One of the areas of interest is establishing secure, efficient and prioritized data and command communication pathways among ground and space-based sources for such systems. This paper presents early research results on the potential role, capabilities and value of blockchain usage within constellation and swarm satellite architectures. It demonstrates the use of blockchain's smart contract and distributed ledger capabilities for secure and prioritized multi-sensor satellite collaborative data exchanges, as well as the logging and tracking of command and control events. Adapting and utilizing this emerging technology will aid in addressing technology gaps expected from future constellation flight architectures, such as managing collective computational operations (correlation), dynamic and autonomous observation planning, time-critical events, and provenance tied to ground and space-based autonomous operations and control recordkeeping. In this scenario blockchain is applied in encrypted command transmittal to multiple, yet specific, entities enabling acknowledgement transmittals, performance scalability, and automatic event-based triggering.

Mital, Rohit↗
NASA NTRS2015

Measured Response for UAS Integration into the National Airspace System

The measured response (MR) is the response time of aircraft to Air Traffic Controller (ATCo) commands and clearances. The overall MR can be broken up into several components, including the pilot verbal latencies (MR1), the time between the end of an ATCo clearance and the beginning of the pilots read back, and the execution initiation latency (MR2), the time between the end of the ATCos clearance and when the pilot begins to execute a maneuver. The MR is a crucial concern for the integration of Unmanned Aircraft Systems (UAS) into the National Airspace System (NAS) due to potentially greater latencies stemming from remote pilot communication and command execution. As a result, it is important to quantify what latencies in verbal responding and command execution are acceptable for safe and efficient operations in the NAS. The present studies begin to address these issues in a series of four simulations supported by the UAS Integration into the NAS program.

UAS in the NAS↗
NASA NTRS2019

Control and Simulation of a Deployable Entry Vehicle with Aerodynamic Control Surfaces

In this paper, we investigate the static stability of a deployable entry vehicle called the Lifting Nano-ADEPT and design a control system to follow bank angle, angle-of-attack, and sideslip guidance commands. The control design, based on linear quadratic regulator optimal techniques, utilizes aerodynamic control surfaces to track angle-of-attack, sideslip angle, and bank angle commands. We demonstrate, using a nonlinear simulation environment, that the controller is able to accurately track step commands that may come from a guidance algorithm.

Margolis, Benjamin W. L.↗
NASA NTRS2019

Effectiveness of Redundant Communications Systems in Maintaining Operational Control of Small Unmanned Aircraft

As a part of NASA’s Unmanned Aircraft System (UAS) Traffic Management (UTM) research, a test was performed to evaluate the effectiveness of the redundant Command and Control (C2) communications system for maintaining operational control of small UAS in the airspace over a rural area. In the test, operators set up a primary and a secondary UAS C2 communications system, sent a maneuver command to an Unmanned Aircraft (UA) with and without a functioning primary system, then verified the execution of the sent command to confirm the operator control. Operators reported that the tested redundancy configurations were effective in maintaining operational control in the test airspace over rural locations. Since the next phase of UTM research focuses on operations in an urban area where an increased level of Radio Frequency (RF) activities occur compared to a rural area, four recommendations are provided to sustain the effectiveness of redundancy in urban operations. First, the operator should not include C2 systems that use the industrial, scientific, and medical (ISM) radio bands in redundancy configurations. Second, the operator should verify the RF characteristics of the intended operation area and examine the area’s radio noise floor. Third, the operator should monitor the availability, quality, and reliability of communications services used by a redundant system. Fourth, the small UAS community should adopt a standard set of contingency steps to handle the loss of C2 communications so that such events are managed in a consistent manner across the airspace. The insights from the test will be used to accommodate the FAA’s UAS integration effort.

Jung, Jaewoo↗
NASA NTRS1993

Merging Concurrent Behaviors on a Redundant Manipulator

Task Space control of manipulators is extended both in the number of simultaneous behaviors and in the dimension of task space. An application is decomposed into multiple simultaneous behaviors whose resultant behavior will provide the motion necessary to execute the task. Each behavior generates commands in its own coordinate system. These simultaneous commands are merged in a motion space using impedance control to complete a resultant command to the manipulator. The task space of each behavior can have the dimensionality of the mechanism being controlled. Control of a seven degree of freedom manipulator is described here so the available task space for each behavior has dimensionality seven.

robotics↗