Search NASA⌕ Search

SEARCH · Search NASA

Results for “command generation process”

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 199 records · Page 11

Applications of artificial intelligence to space station and automated software techniques: High level robot command language

The objective is to develop a system that will allow a person not necessarily skilled in the art of programming robots to quickly and naturally create the necessary data and commands to enable a robot to perform a desired task. The system will use a menu driven graphical user interface. This interface will allow the user to input data to select objects to be moved. There will be an imbedded expert system to process the knowledge about objects and the robot to determine how they are to be moved. There will be automatic path planning to avoid obstacles in the work space and to create a near optimum path. The system will contain the software to generate the required robot instructions.

Mckee, James W.↗

Natural Language Processing Methods for Air Traffic Management Text and Speech Data

This presentation discusses two efforts of the NARI AI/ML Intern team during the Fall 2021 OSTEM Internship term. For Letters of Agreement (LoA), we have studied how LoAs are structured and explored the question ‘What is an LoA constraint?’ To do this, our approach is data-driven, iterative, and assisted by machine learning when available. In this presentation, we will walk through our tasks of manually scanning through documents, performing a preliminary entity labelling task, and our unsupervised analysis on LoA procedures sections. After this research phase, we define the smallest constraint unit in an LoA, and start to perform entity extraction. Looking towards constraint extraction, we are also exploring the use of a one-class support vector machine (OneClassSVM) model to identify patterns within the data. The second effort of our team this term is focused on Air Traffic Control System Command Center (ATCSCC) advisory meetings, and the subsequent advisory documents that get published from their content. These advisory documents are important to give readily accessible summaries of daily operations, so that data centers, airline officials, and other stakeholders can easily understand the context of these meetings in real time. In applying machine learning to this scenario, two natural language processing tasks are used. First is developing machine learning models to convert the meeting speech data into text. With this text, use of extractive and abstractive text summarization models are used to automatically generate preliminary versions of the advisory documents.

Natural Language Processing↗

Launch Control System Software Development System Automation Testing

The Spaceport Command and Control System (SCCS) is the National Aeronautics and Space Administration's (NASA) launch control system for the Orion capsule and Space Launch System, the next generation manned rocket currently in development. This system requires high quality testing that will measure and test the capabilities of the system. For the past two years, the Exploration and Operations Division at Kennedy Space Center (KSC) has assigned a group including interns and full-time engineers to develop automated tests to save the project time and money. The team worked on automating the testing process for the SCCS GUI that would use streamed simulated data from the testing servers to produce data, plots, statuses, etc. to the GUI. The software used to develop automated tests included an automated testing framework and an automation library. The automated testing framework has a tabular-style syntax, which means the functionality of a line of code must have the appropriate number of tabs for the line to function as intended. The header section contains either paths to custom resources or the names of libraries being used. The automation library contains functionality to automate anything that appears on a desired screen with the use of image recognition software to detect and control GUI components. The data section contains any data values strictly created for the current testing file. The body section holds the tests that are being run. The function section can include any number of functions that may be used by the current testing file or any other file that resources it. The resources and body section are required for all test files; the data and function sections can be left empty if the data values and functions being used are from a resourced library or another file. To help equip the automation team with better tools, the Project Lead of the Automated Testing Team, Jason Kapusta, assigned the task to install and train an optical character recognition (OCR) tool to Brandon Echols, a fellow intern, and I. The purpose of the OCR tool is to analyze an image and find the coordinates of any group of text. Some issues that arose while installing the OCR tool included the absence of certain libraries needed to train the tool and an outdated software version. We eventually resolved the issues and successfully installed the OCR tool. Training the tool required many images and different fonts and sizes, but in the end the tool learned to accurately decipher the text in the images and their coordinates. The OCR tool produced a file that contained significant metadata for each section of text, but only the text and coordinates of the text was required for our purpose. The team made a script to parse the information we wanted from the OCR file to a different file that would be used by automation functions within the automated framework. Since a majority of development and testing for the automated test cases for the GUI in question has been done using live simulated data on the workstations at the Launch Control Center (LCC), a large amount of progress has been made. As of this writing, about 60% of all of automated testing has been implemented. Additionally, the OCR tool will help make our automated tests more robust due to the tool's text recognition being highly scalable to different text fonts and text sizes. Soon we will have the whole test system automated, allowing for more full-time engineers working on development projects.

Automation↗

Modification of a Limbed Robot to Favor Climbing

The figure shows the LEMUR IIb, which is a modified version of the LEMUR II the second generation of the Limbed Excursion Mechanical Utility Robot (LEMUR). Except as described below, the LEMUR IIb hardware is mostly the same as that of the LEMUR II. The IIb and II versions differ in their kinematic configurations and characteristics associated with their kinematic configurations. The differences are such that relative to the LEMUR II, the LEMUR IIb is simpler and is better suited to climbing on inclined surfaces. The first-generation LEMUR, now denoted the LEMUR I, was described in Six-Legged Experimental Robot (NPO-20897), NASA Tech Briefs, Vol. 25, No. 12 (December 2001), page 58. The LEMUR II was described in Second-Generation Six-Limbed Experimental Robot (NPO-35140) NASA Tech Briefs, Vol. 28, No. 11 (November 2004), page 55. To recapitulate: the LEMUR I and LEMUR II were six-legged or sixlimbed robots for demonstrating robotic capabilities for assembly, maintenance, and inspection. They were designed to be capable of walking autonomously along a truss structure toward a mechanical assembly at a prescribed location. They were equipped with stereoscopic video cameras and image-data-processing circuitry for navigation and mechanical operations. They were also equipped with wireless modems, through which they could be commanded remotely. Upon arrival at a mechanical assembly, the LEMUR I would perform simple mechanical operations by use of one or both of its front legs (or in the case of the LEMUR II, any of its limbs could be used to perform mechanical operations). Either LEMUR could also transmit images to a host computer. The differences between the LEMUR IIb and the LEMUR II are the following: Whereas the LEMUR II had six limbs, the LEMUR IIb has four limbs. This change has reduced both the complexity and mass of the legs and of the overall robot. Whereas each limb of the LEMUR II had four degrees of freedom (DOFs), each limb of the LEMUR IIb has three DOFs. This change has also reduced both complexity and mass. Notwithstanding the decrease in the number of DOFs, the three remaining DOFs are configured to provide greater dexterity for motion along a surface. To extend reach, the limbs of the LEMUR IIb are 25 percent longer than those of the LEMUR II. Additional benefits stemming from the modifications are that the robot body supported by the limbs is now less massive and its center of gravity is now closer to the surface along which the robot is to move. These benefits have been obtained without sacrificing load-carrying capacity. Hence, overall, the LEMUR IIb is a more adept climber.

Okon, Avi↗

ISPATOM: A Generic Real-Time Data Processing Tool Without Programming

Information Sharing Protocol Advanced Tool of Math (ISPATOM) is an application program allowing for the streamlined generation of comps, which subscribe to streams of incoming telemetry data, perform any necessary computations on the data, then send the data to other programs for display and/or further processing in NASA mission control centers. Heretofore, the development of comps was difficult, expensive, and time-consuming: Each comp was custom written manually, in a low-level computing language, by a programmer attempting to follow requirements of flight controllers. ISPATOM enables a flight controller who is not a programmer to write a comp by simply typing in one or more equation( s) at a command line or retrieving the equation(s) from a text file. ISPATOM then subscribes to the necessary input data, performs all of necessary computations, and sends out the results. It sends out new results whenever the input data change. The use of equations in ISPATOM is no more difficult than is entering equations in a spreadsheet. The time involved in developing a comp is thus limited to the time taken to decide on the necessary equations. Thus, ISPATOM is a real-time dynamic calculator.

Dershowitz, Adam↗

Nanosail-D: The Small Satellite That Could!

Three years from its initial design review, NanoSail-D successfully deployed its sail on January 20th, 2011. It became the first solar sail vehicle to orbit the earth and the second sail ever unfurled in space. The NanoSail-D mission had two main objectives: eject a nanosatellite from a microsatellite; deploy its sail from a highly compacted volume and low mass system to validate large structure deployment and potential de-orbit technologies. These objectives were successfully achieved and the de-orbit analysis is in process. This paper presents an overview of the NanoSail-D project and insights into how potential setbacks were overcome. Many lessons have been learned during these past three years and are discussed in light of the phenomenal success and interest that this small satellite has generated. NanoSail-D was jointly designed and built by NASA's Marshall Space Flight Center and NASA's Ames Research Center. ManTech/NeXolve Corporation also provided key sail design support. The NanoSail-D experiment is managed by Marshall and jointly sponsored by the Army Space and Missile Defense Command, the Von Braun Center for Science and Innovation and Dynetics Inc. Ground operations support was provided by Santa Clara University, with radio beacon packets received from amateur operators around the world.

Alhorn, Dean C.↗

Model reference adaptive control of flexible robots in the presence of sudden load changes

Direct command generator tracker based model reference adaptive control (MRAC) algorithms are applied to the dynamics for a flexible-joint arm in the presence of sudden load changes. Because of the need to satisfy a positive real condition, such MRAC procedures are designed so that a feedforward augmented output follows the reference model output, thus, resulting in an ultimately bounded rather than zero output error. Thus, modifications are suggested and tested that: (1) incorporate feedforward into the reference model's output as well as the plant's output, and (2) incorporate a derivative term into only the process feedforward loop. The results of these simulations give a response with zero steady state model following error, and thus encourage further use of MRAC for more complex flexibile robotic systems.

Steinvorth, Rodrigo↗

Spaceport Command and Control System Automated Testing

The Spaceport Command and Control System (SCCS) is the National Aeronautics and Space Administrations (NASA) launch control system for the Orion capsule and Space Launch System, the next generation manned rocket currently in development. This large system requires high quality testing that will properly measure the capabilities of the system. Automating the test procedures would save the project time and money. Therefore, the Electrical Engineering Division at Kennedy Space Center (KSC) has recruited interns for the past two years to work alongside full-time engineers to develop these automated tests, as well as innovate upon the current automation process.

LCS↗

Spaceport Command and Control System Automation Testing

The Spaceport Command and Control System (SCCS) is the National Aeronautics and Space Administrations (NASA) launch control system for the Orion capsule and Space Launch System, the next generation manned rocket currently in development. This large system requires high quality testing that will properly measure the capabilities of the system. Automating the test procedures would save the project time and money. Therefore, the Electrical Engineering Division at Kennedy Space Center (KSC) has recruited interns for the past two years to work alongside full-time engineers to develop these automated tests, as well as innovate upon the current automation process.

Testing↗

NASA's Moon to Mars Autonomous Habitat Status

NASA is developing a strategy for sending humans to the Mars vicinity, known broadly as the Moon to Mars (M2M) Campaign. A critical part of this campaign is the development of in-space and surface habitation systems capable of substantially extending human presence beyond Low Earth Orbit (LEO). Mars missions feature an in-space transit habitat capable of supporting crews of four on ~850-1200-day missions, including transit to and from Mars and time in Mars orbit. Surface and transit habitats are complex elements which must keep crewmembers healthy and productive in deep-space environments with limited resources, long rescue times in contingency situations, and communication delays; all within constrained mass, volume, and power budgets. These habitats provide crew both living and workspace as well as most of the resources needed to support crew life. For deep space habitats, automation needs to be employed due to latency and for significant amounts of time when the habitats are uncrewed. Automation of systems is possible in space applications, but there are limitations. Outside of the Earth’s (or any) magnetosphere, radiation environments are harsh to both the physical hardware and the software components. Radiation (charged particles and ionizing electromagnetic waves) degrades and damages the hardware and causes single event upsets (SEUs) in software. If the hardware is damaged, data can be lost, or control actions not made. For software, SEUs cause algorithms to result in different solutions, or incorrect commands to be sent out. This means that algorithms and hardware used for deep space systems are different than what is used on Earth. Radiation-tolerant hardware is generations behind the current state-of-the-art hardware. Recent NASA missions, such as James Webb Space Telescope, continue to rely on older technologies such as the RAD750 processor, and the most advanced processors are still single core and less than 1.5 GHz. There have been attempts to use higher performance processors, but these often take multiple mitigation steps to handle the radiation environments, which limits the processing power and/or throughput. Current techniques for radiation mitigation have been redundancies, voting, physical separation of hardware, encasing materials, under-clocking hardware, and more. Some radiation mitigation techniques do provide benefits such as having a redundant system to improve the probability that a system will be available when needed. Autonomous software systems will have fewer interactions with humans on deep space missions and therefore need to be able to handle more off-nominal conditions. Microgravity also complicates the autonomous aspects of the mission because autonomous systems are usually built from known deterministic states, but microgravity causes physical objects to shift and move changing the location an autonomous system placed the object. Not only does the software need to be reliable and deterministic, losing resources due to a software error is not only costly but detrimental to reputation. The combination of having lower performance hardware and having to be able to verify and deterministically run software and an ever-changing environment makes deep space autonomous systems more complicated. Multiple gaps have been identified including verification of autonomous software algorithms (including artificial intelligence and machine learning), higher performance processors (graphics and general purpose), high speed networks (onboard and transmissions), memory, power distribution, data security, and variations from these. These gaps need to be closed for more advanced systems to be deployed and reduce the size, weight, and power impacts on the habitats.

Scott B. Tashakkor↗

Active Flutter Suppression Using Reduced-Order Modeling for Transonic Aeroservoelastic Control Law Development

In this paper, several aerodynamic reduced-order models (ROMs) are generated and coupled with structural models to form aeroelastic ROMs. The aerodynamic ROMs generated here include the effects of control surface motion and are appropriate for use in aeroservoelastic applications. Simple observer-based full-state feedback controllers were designed from these aeroelastic ROMs. Additionally, observer gain matrices were designed from and coupled to the aeroelastic ROMs. Each (linear) observer was then used to estimate the dynamics of a (nonlinear) stand-alone computational fluid-structure dynamics simulation. Then, using the estimated states and the full-state feedback controller, control surface commands were fed back into the computational fluid-structure dynamics simulation to successfully achieve active flutter suppression. The process, as well as some results, are presented in this paper.

Waite, Josiah M.↗

XML Flight/Ground Data Dictionary Management

A computer program generates Extensible Markup Language (XML) files that effect coupling between the command- and telemetry-handling software running aboard a spacecraft and the corresponding software running in ground support systems. The XML files are produced by use of information from the flight software and from flight-system engineering. The XML files are converted to legacy ground-system data formats for command and telemetry, transformed into Web-based and printed documentation, and used in developing new ground-system data-handling software. Previously, the information about telemetry and command was scattered in various paper documents that were not synchronized. The process of searching and reading the documents was time-consuming and introduced errors. In contrast, the XML files contain all of the information in one place. XML structures can evolve in such a manner as to enable the addition, to the XML files, of the metadata necessary to track the changes and the associated documentation. The use of this software has reduced the extent of manual operations in developing a ground data system, thereby saving considerable time and removing errors that previously arose in the translation and transcription of software information from the flight to the ground system.

Wright, Jesse↗

Emulation of Core Flight System Applications for Flight Software Development and Validation

The Mars Sample Return (MSR) campaign is an unprecedented attempt in the return of Martian samples back to Earth. The ascent from the surface will be performed by the Mars Ascent Vehicle (MAV), a critical element in the mission that National Aeronautics and Space Administration (NASA) Marshall Space Flight Center (MSFC) is developing. To this end, innovations in flight software development, verification, and validation are occurring. The MAV flight computer will run Core Flight System (cFS), an open-source software environment developed by NASA Goddard Space Flight Center (GSFC). NASA Marshall’s MAV Mission and Fault Management (M&FM) Team has implemented an emulation of two applications of this architecture: Limit Checker and Stored Command. Using an emulation of the functionalities of these applications allows for rapid prototyping of table-based algorithms. Further, M&FM is leveraging an in-house, low-fidelity but high-throughput State Analysis Model (SAM), an integrated MATLAB Stateflow Plant and Software model. This model is run in parallel with the cFS emulation for full flyout testing of the M&FM algorithms, verification of intent of these algorithms, and for future auto-generation of application-ingestible M&FM tables. The tables can then be delivered to the MAV Flight Software (FSW) team in a seamless process, reducing the cost of traditional FSW development and the risk of starting M&FM FSW development at later points in the NASA program life cycle.

Cody Wheeler↗

Emulation of Core Flight System Applications for Flight Software Development and Validation

The Mars Sample Return (MSR) campaign is an unprecedented attempt in the return of Martian samples back to Earth. The ascent from the surface will be performed by the Mars Ascent Vehicle (MAV), a critical element in the mission that National Aeronautics and Space Administration (NASA) Marshall Space Flight Center (MSFC) is developing. To this end, innovations in flight software development, verification, and validation are occurring. The MAV flight computer will run Core Flight System (cFS), an open-source software environment developed by NASA Goddard Space Flight Center (GSFC). NASA Marshall’s MAV Mission and Fault Management (M&FM) Team has implemented an emulation of two applications of this architecture: Limit Checker and Stored Command. Using an emulation of the functionalities of these applications allows for rapid prototyping of table-based algorithms. Further, M&FM is leveraging an in-house, low-fidelity but high-throughput State Analysis Model (SAM), an integrated MATLAB Stateflow Plant and Software model. This model is run in parallel with the cFS emulation for full flyout testing of the M&FM algorithms, verification of intent of these algorithms, and for future auto-generation of application-ingestible M&FM tables. The tables can then be delivered to the MAV Flight Software (FSW) team in a seamless process, reducing the cost of traditional FSW development and the risk of starting M&FM FSW development at later points in the NASA program life cycle.

Cody Wheeler↗

Program for Editing Spacecraft Command Sequences

Sequence Translator, Editor, and Expander Resource (STEER) is a computer program that facilitates construction of sequences and blocks of sequences (hereafter denoted generally as sequence products) for commanding a spacecraft. STEER also provides mechanisms for translating among various sequence product types and quickly expanding activities of a given sequence in chronological order for review and analysis of the sequence. To date, construction of sequence products has generally been done by use of such clumsy mechanisms as text-editor programs, translating among sequence product types has been challenging, and expanding sequences to time-ordered lists has involved arduous processes of converting sequence products to "real" sequences and running them through Class-A software (defined, loosely, as flight and ground software critical to a spacecraft mission). Also, heretofore, generating sequence products in standard formats has been troublesome because precise formatting and syntax are required. STEER alleviates these issues by providing a graphical user interface containing intuitive fields in which the user can enter the necessary information. The STEER expansion function provides a "quick and dirty" means of seeing how a sequence and sequence block would expand into a chronological list, without need to use of Class-A software.

Gladden, Roy↗

Superfluid Helium On-Orbit Transfer (SHOOT) flight demonstration

The Superfluid Helium On-Orbit Transfer (SHOOT) Flight Demonstration was an attached Shuttle payload mounted on a Hitchhiker cross-bay carrier which flew on STS-57 in June of 1993. SHOOT successfully demonstrated the handling and transfer of superfluid helium between two containers, called dewars, in low gravity. SHOOT was a class C payload and for the STS-57 mission was termed a complex secondary payload. The primaries were the retrieval of the EURECA carrier and a collection of modular experiments contained in SPACEHAB. Because the liquid helium was continuously boiling off, SHOOT's activities were scheduled for the first three days of the mission, concurrent with some SPACEHAB experiments, but well before the EURECA retrieval. Control of the SHOOT experiment was highly interactive and originated primarily from the Goddard Payload Operations and Control Center (POCC). Transfer and calibration activities required continuous command windows of up to 50 minutes duration and up to 80 minutes out of each orbit. Occasionally the crew controlled the experiment using the Payload General Support Computer (PGSC) when near-real time control and monitoring was required. SHOOT also placed considerable demands on the orbiter, including a pitch rotation of 3 deg./sec for 15 minutes, and translational burns using both the aft and forward RCS jets to generate accelerations up to 7 milli-g. The basis for these and other requirements are discussed. Interacion with the crew and timing of crew activity during the mission will be detailed. The processing flow of SHOOT at KSC is described with emphasis on the tradeoffs for vertical, as opposed to horizontal, installation in the orbiter. Finally, some lessons learned are presented that are relevant to future cryogenic and Hitchhiker payloads.

Shirron, Peter↗

Robot Sequencing and Visualization Program (RSVP)

The Robot Sequencing and Visualization Program (RSVP) is being used in the Mars Science Laboratory (MSL) mission for downlink data visualization and command sequence generation. RSVP reads and writes downlink data products from the operations data server (ODS) and writes uplink data products to the ODS. The primary users of RSVP are members of the Rover Planner team (part of the Integrated Planning and Execution Team (IPE)), who use it to perform traversability/articulation analyses, take activity plan input from the Science and Mission Planning teams, and create a set of rover sequences to be sent to the rover every sol. The primary inputs to RSVP are downlink data products and activity plans in the ODS database. The primary outputs are command sequences to be placed in the ODS for further processing prior to uplink to each rover. RSVP is composed of two main subsystems. The first, called the Robot Sequence Editor (RoSE), understands the MSL activity and command dictionaries and takes care of converting incoming activity level inputs into command sequences. The Rover Planners use the RoSE component of RSVP to put together command sequences and to view and manage command level resources like time, power, temperature, etc. (via a transparent realtime connection to SEQGEN). The second component of RSVP is called HyperDrive, a set of high-fidelity computer graphics displays of the Martian surface in 3D and in stereo. The Rover Planners can explore the environment around the rover, create commands related to motion of all kinds, and see the simulated result of those commands via its underlying tight coupling with flight navigation, motor, and arm software. This software is the evolutionary replacement for the Rover Sequencing and Visualization software used to create command sequences (and visualize the Martian surface) for the Mars Exploration Rover mission.

Cooper, Brian K.↗

An Information NEXUS: The NASA Global Hawk Link Module

The Link Module described in this paper was first developed for the NASA Global Hawk Pacific Mission (GloPAC), four flights of 30 hour duration, supporting the Aura Validation Experiment (AVE). Its second use was during the Genesis and Rapid Intensification Processes (GRIP) experiment, a NASA Earth Science field experiment to better understand how tropical storms form and develop into major hurricanes. In these missions, the Link module negotiated all communication over the high bandwidth Ku satellite link, archived al the science data from onboard experiments in a spatially enable database, routed command and control of the instruments from the Global Hawk Operations Center, and retransmitted select data sets directly to experimenters control and analysis systems. The availability of aggregated information from collections of sensors, and remote control capabilities, in real-time, is revolutionizing the way Airborne Science is being conducted. Also described is the next generation Link Module now being designed and tested to support the NASA Earth Venture missions, the Hurricane and Severe Storm Sentinel (HS3) mission, and Airborne Tropical Tropopause Experiment (ATTREX) mission. Advanced data fusion technologies being developed will further advance the Scientific productivity, flexibility and robustness of these systems. Historically, the Link module evolved from the instrument and communication interface controller used by NASA's Pathfinder and Pathfinder plus solar powered UAS's in the late 1990's. It later was expanded for use in the AIRDAS four channel scanner flown on the NASA Altus UAS, and then again to a module in the AMS twelve channel multispectral scanner flying on the NASA (Predator-b) Ikhana UAS. The current system is the next step in the evolution, a multi board system packaged in a Curtiss Wright MIL-spec, flight qualified enclosure.

Remote Sensing↗