Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “sequencing commanding operations”

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 145 records · Page 8
All sourcesNASA NTRSDOE OSTI
NASA NTRS2012

Virtual Machine Language 2.1

VML (Virtual Machine Language) is an advanced computing environment that allows spacecraft to operate using mechanisms ranging from simple, time-oriented sequencing to advanced, multicomponent reactive systems. VML has developed in four evolutionary stages. VML 0 is a core execution capability providing multi-threaded command execution, integer data types, and rudimentary branching. VML 1 added named parameterized procedures, extensive polymorphism, data typing, branching, looping issuance of commands using run-time parameters, and named global variables. VML 2 added for loops, data verification, telemetry reaction, and an open flight adaptation architecture. VML 2.1 contains major advances in control flow capabilities for executable state machines. On the resource requirements front, VML 2.1 features a reduced memory footprint in order to fit more capability into modestly sized flight processors, and endian-neutral data access for compatibility with Intel little-endian processors. Sequence packaging has been improved with object-oriented programming constructs and the use of implicit (rather than explicit) time tags on statements. Sequence event detection has been significantly enhanced with multi-variable waiting, which allows a sequence to detect and react to conditions defined by complex expressions with multiple global variables. This multi-variable waiting serves as the basis for implementing parallel rule checking, which in turn, makes possible executable state machines. The new state machine feature in VML 2.1 allows the creation of sophisticated autonomous reactive systems without the need to develop expensive flight software. Users specify named states and transitions, along with the truth conditions required, before taking transitions. Transitions with the same signal name allow separate state machines to coordinate actions: the conditions distributed across all state machines necessary to arm a particular signal are evaluated, and once found true, that signal is raised. The selected signal then causes all identically named transitions in all present state machines to be taken simultaneously. VML 2.1 has relevance to all potential space missions, both manned and unmanned. It was under consideration for use on Orion.

Riedel, Joseph E.↗
NASA NTRS2006

Lessons Learned from Daily Uplink Operations during the Deep Impact Mission

The daily preparation of uplink products (commands and files) for Deep Impact was as problematic as the final encounter images were spectacular. The operations team was faced with many challenges during the six-month mission to comet Tempel One of the biggest difficulties was that the Deep Impact Flyby and Impactor vehicles necessitated a high volume of uplink products while also utilizing a new uplink file transfer capability. The Jet Propulsion Laboratory (JPL) Multi-Mission Ground Systems and Services (MGSS) Mission Planning and Sequence Team (MPST) had the responsibility of preparing the uplink products for use on the two spacecraft. These responsibilities included processing nearly 15,000 flight products, modeling the states of the spacecraft during all activities for subsystem review, and ensuring that the proper commands and files were uplinked to the spacecraft. To guarantee this transpired and the health and safety of the two spacecraft were not jeopardized several new ground scripts and procedures were developed while the Deep Impact Flyby and Impactor spacecraft were en route to their encounter with Tempel-1. These scripts underwent several adaptations throughout the entire mission up until three days before the separation of the Flyby and Impactor vehicles. The problems presented by Deep Impact's daily operations and the development of scripts and procedures to ease those challenges resulted in several valuable lessons learned. These lessons are now being integrated into the design of current and future MGSS missions at JPL.

uplink↗
NASA NTRS1997

Modular Manufacturing Simulator: Users Manual

The Modular Manufacturing Simulator (MMS) has been developed for the beginning user of computer simulations. Consequently, the MMS cannot model complex systems that require branching and convergence logic. Once a user becomes more proficient in computer simulation and wants to add more complexity, the user is encouraged to use one of the many available commercial simulation systems. The (MMS) is based on the SSE5 that was developed in the early 1990's by the University of Alabama in Huntsville (UAH). A recent survey by MSFC indicated that the simulator has been a major contributor to the economic impact of the MSFC technology transfer program. Many manufacturers have requested additional features for the SSE5. Consequently, the following features have been added to the MMS that are not available in the SSE5: runs under Windows, print option for both input parameters and output statistics, operator can be fixed at a station or assigned to a group of stations, operator movement based on time limit, part limit, or work-in-process (WIP) limit at next station. The movement options for a moveable operators are: go to station with largest WIP, rabbit chase where operator moves in circular sequence between stations, and push/pull where operator moves back and forth between stations. This user's manual contains the necessary information for installing the MMS on a PC, a description of the various MMS commands, and the solutions to a number of sample problems using the MMS. Also included in the beginning of this report is a brief discussion of technology transfer.

Source record↗
NASA NTRS2000

Autonomy Architectures for a Constellation of Spacecraft

This paper describes three autonomy architectures for a system that continuously plans to control a fleet of spacecraft using collective mission goals instead of goals of command sequences for each spacecraft. A fleet of self-commanding spacecraft would autonomously coordinate itself to satisfy high level science and engineering goals in a changing partially-understood environment-making feasible the operation of tens of even a hundred spacecraft (such as for interferometer or magnetospheric constellation missions).

Barrett, Anthony↗
NASA NTRS1994

Simplifying Operations with an Uplink/Downlink Integration Toolkit

The Operations Engineering Lab (OEL) at JPL has developed a simple, generic toolkit to integrate the uplink/downlink processes (often called closing the loop) in JPL's Multimission Ground Data System. This toolkit provides capabilities for integrating telemetry verification points with predicted spacecraft commands and ground events in the Mission Sequence of Events (SOE) document. This toolkit is designed to greatly simplify the user's ability to access and view telemetry data, and also provide a means to view this data in a context of the commands and ground events that are used to interpret it. This paper will discuss the toolkit implementation, including design trade-offs and future for enhancing the automated capabilities.

ground↗
NASA NTRS1993

Design and application of electromechanical actuators for deep space missions

The annual report Design and Application of Electromechanical Actuators for Deep Space Missions is presented. The reporting period is 16 Aug. 1992 to 15 Aug. 1993. However, the primary focus will be work performed since submission of our semi-annual progress report in Feb. 1993. Substantial progress was made. We currently feel confident in providing guidelines for motor and control strategy selection in electromechanical actuators to be used in thrust vector control (TVC) applications. A small portion was presented in the semi-annual report. At this point, we have implemented highly detailed simulations of various motor/drive systems. The primary motor candidates were the brushless dc machine, permanent magnet synchronous machine, and the induction machine. The primary control implementations were pulse width modulation and hysteresis current control. Each of the two control strategies were applied to each of the three motor choices. With either pulse width modulation or hysteresis current control, the induction machine was always vector controlled. A standard test position command sequence for system performance evaluation is defined. Currently, we are gathering all of the necessary data for formal presentation of the results. Briefly stated for TVC application, we feel that the brushless dc machine operating under PWM current control is the best option. Substantial details on the topic, with supporting simulation results, will be provided later, in the form of a technical paper prepared for submission and also in the next progress report with more detail than allowed for paper publication.

Haskew, Tim A.↗
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 NTRS1994

Joint operations planning for space surveillance missions on the MSX satellite

The Midcourse Space Experiment (MSX) satellite, sponsored by BMDO, is intended to gather broad-band phenomenology data on missiles, plumes, naturally occurring earthlimb backgrounds and deep space backgrounds. In addition the MSX will be used to conduct functional demonstrations of space-based space surveillance. The JHU/Applied Physics Laboratory (APL), located in Laurel, MD, is the integrator and operator of the MSX satellite. APL will conduct all operations related to the MSX and is charged with the detailed operations planning required to implement all of the experiments run on the MSX except the space surveillance experiments. The non-surveillance operations are generally amenable to being defined months ahead of time and being scheduled on a monthly basis. Lincoln Laboratory, Massachusetts Institute of Technology (LL), located in Lexington, MA, is the provider of one of the principle MSX instruments, the Space-Based Visible (SBV) sensor, and the agency charged with implementing the space surveillance demonstrations on the MSX. The planning timelines for the space surveillance demonstrations are fundamentally different from those for the other experiments. They are generally amenable to being scheduled on a monthly basis, but the specific experiment sequence and pointing must be refined shortly before execution. This allocation of responsibilities to different organizations implies the need for a joint mission planning system for conducting space surveillance demonstrations. This paper details the iterative, joint planning system, based on passing responsibility for generating MSX commands for surveillance operations from APL to LL for specific scheduled operations. The joint planning system, including the generation of a budget for spacecraft resources to be used for surveillance events, has been successfully demonstrated during ground testing of the MSX and is being validated for MSX launch within the year. The planning system developed for the MSX forms a model possibly applicable to developing distributed mission planning systems for other multi-use satellites.

Stokes, Grant↗
NASA NTRS1999

Autonomous Science Decision Making for Mars Sample Return

In the near future NASA intends to explore Mars in preparation for a sample return mission using robotic devices such as landers, rovers, orbiters, airplanes, and/or balloons. Such platforms will likely carry imaging devices to characterize the surface morphology, and a variety of analytical instruments intended to evaluate the chemical and mineralogical nature of the environment(s) that they encounter. Historically, mission operations have involved the following sequence of activities: (1) return of scientific data from the vehicle; (2) evaluation of the data by space scientists; (3) recommendations of the scientists regarding future mission activity; (4) transmission of commands to the vehicle to achieve this activity; and (5) new activity by the vehicle in response to those commands. This is repeated for the duration of the mission, with command opportunities once or perhaps twice per day. In a rapidly changing environment, such as might be encountered by a rover traversing hundreds of meters a day or an airplane soaring over several hundred of kilometers, this traditional cycle of data evaluation and commands is not amenable to rapid long range traverses, discovery of novelty, or rapid response to any unanticipated situations. In addition, to issues of response time, the nature of imaging and/or spectroscopic devices are such that tremendous data volumes can be acquired, for example during a traverse. These data volumes can rapidly exceed on-board memory capabilities prior to an opportunity to transmit it to Earth.

Roush, Ted L.↗
NASA NTRS1999

Autonomous Science Decisions for Mars Sample Return

In the near future NASA intends to explore Mars in preparation for a sample return mission using robotic devices such as landers rovers, orbiters, airplanes, and/or balloons. Such platforms will likely carry imaging devices to characterize the surface morphology, and a variety of analytical instruments intended to evaluated the chemical and mineralogical nature of the environment(s) that they encounter. Historically, mission operations have involved the following sequence of activities: (1) return of scientific data from the vehicle; (2) evaluation of the data by space scientists; (3) recommendations of the scientists regarding future mission activity; (4) transmission of commands to the vehicle to achieve this activity; and (5) new activity by the vehicle in response to those commands.

Roush, T. L.↗
DOE OSTI2024

MVP: a modular viromics pipeline to identify, filter, cluster, annotate, and bin viruses from metagenomes

While numerous computational frameworks and workflows are available for recovering prokaryote and eukaryote genomes from metagenome data, only a limited number of pipelines are designed specifically for viromics analysis. With many viromics tools developed in the last few years alone, it can be challenging for scientists with limited bioinformatics experience to easily recover, evaluate quality, annotate genes, dereplicate, assign taxonomy, and calculate relative abundance and coverage of viral genomes using state-of-the-art methods and standards. Here, we describe Modular Viromics Pipeline (MVP) v.1.0, a user-friendly pipeline written in Python and providing a simple framework to perform standard viromics analyses. MVP combines multiple tools to enable viral genome identification, characterization of genome quality, filtering, clustering, taxonomic and functional annotation, genome binning, and comprehensive summaries of results that can be used for downstream ecological analyses. Overall, MVP provides a standardized and reproducible pipeline for both extensive and robust characterization of viruses from large-scale sequencing data including metagenomes, metatranscriptomes, viromes, and isolate genomes. As a typical use case, we show how the entire MVP pipeline can be applied to a set of 20 metagenomes from wetland sediments using only 10 modules executed via command lines, leading to the identification of 11,656 viral contigs and 8,145 viral operational taxonomic units (vOTUs) displaying a clear beta-diversity pattern. Further, acting as a dynamic wrapper, MVP is designed to continuously incorporate updates and integrate new tools, ensuring its ongoing relevance in the rapidly evolving field of viromics. MVP is available at https://gitlab.com/ccoclet/mvp and as versioned packages in PyPi and Conda.

59 BASIC BIOLOGICAL SCIENCES↗
NASA NTRS2001

A tool for autonomous ground-based rover planning

This paper discusses a proof-of-concept prototype for ground-based automatic generation of validated rover command sequences from high-level science and engineering activities.

automated planning scheduling rover operations art↗
NASA NTRSDate not supplied

Rapid Lightweight Firmware Architecture of the Mobile Metamaterial Internal Co-Integrator Robot

The Mobile Metamaterial Internal Co-Integrator (MMIC-I) is a structure assembly and servicing robot for in-space servicing, assembly, and manufacturing of primary structures and infrastructure. MMIC-I is a battery-powered crawling robot that can travel through periodic structures such as trusses and open framework mechanical metamaterials. It does this through sequences of component extension, contraction, and gripping. This paper provides a detailed discussion of MMIC-I’s lightweight and rapidly developed firmware architecture, to enable demonstration of robot locomotion, secondary operations, and communications with a central command source. The rationale for the lightweight rapid development approach is to allow for assessment of long term system requirements in parallel with the mechatronics development, including optimization of system and subsystem power densities, to inform a future choice of flight ready software frameworks. MMIC-I system computing and I/O requirements are much lower than what is provided by proven baseline computing hardware for existing flight ready software frameworks such as the core Flight System, F prime, and the Robot Operating System. Development of earth gravity ground demonstration of the robotic systems is greatly benefited by limited power and mass factors for computing hardware. Here, we implement inter-process communication, commanding, and telemetry with the Espressif ESP32 module running the Arduino OS.

Damiana Catanoso↗
NASA NTRS1971

A gamma ray monitor for the OSO-7 spacecraft

A 3 in. x 3 in. NaI(Tl) gamma ray (0.3 to 10 MeV) spectrometer with a CsI(Na) charged particle and anti-Compton shield has been developed for the Orbiting Solar Observatory (OSO-7) which was launched September 30, 1971. The instrument, designed for a rotating wheel compartment, utilizes a 377 channel quadratic PHA with accumulation times of 3, 1, or 0.5 minutes. Quick look and calibration data obtained via a direct data link to a minicomputer allows near real time monitoring and control of the experiment. Various commands changing the operating mode can be executed. The functions which can be commanded include: rotation of the quadrants in which data is collected by 90 deg; gain adjustment of the central detector over a 6:1 range; manual or automatic sequencing of calibrations; variations of accumulation times by telemetering selected channels; and selection of reference directions. A small X-ray detector covering the range 7.5 to 120 keV is also included.

Higbie, P. R.↗
NASA NTRS2006

Gesture-Controlled Interfaces for Self-Service Machines

Gesture-controlled interfaces are software- driven systems that facilitate device control by translating visual hand and body signals into commands. Such interfaces could be especially attractive for controlling self-service machines (SSMs) for example, public information kiosks, ticket dispensers, gasoline pumps, and automated teller machines (see figure). A gesture-controlled interface would include a vision subsystem comprising one or more charge-coupled-device video cameras (at least two would be needed to acquire three-dimensional images of gestures). The output of the vision system would be processed by a pure software gesture-recognition subsystem. Then a translator subsystem would convert a sequence of recognized gestures into commands for the SSM to be controlled; these could include, for example, a command to display requested information, change control settings, or actuate a ticket- or cash-dispensing mechanism. Depending on the design and operational requirements of the SSM to be controlled, the gesture-controlled interface could be designed to respond to specific static gestures, dynamic gestures, or both. Static and dynamic gestures can include stationary or moving hand signals, arm poses or motions, and/or whole-body postures or motions. Static gestures would be recognized on the basis of their shapes; dynamic gestures would be recognized on the basis of both their shapes and their motions. Because dynamic gestures include temporal as well as spatial content, this gesture- controlled interface can extract more information from dynamic than it can from static gestures.

Cohen, Charles J.↗
NASA NTRS2012

SRMS Assisted Docking and Undocking for the Orbiter Repair Maneuver

As part of the Orbiter Repair Maneuver (ORM) planned for Return to Flight (RTF) operations, the Shuttle Remote Manipulator System (SRMS) must undock the Orbiter, maneuver it through a complex trajectory at extremely low rates, present it to an EVA crewman at the end of the Space Station Remote Manipulator System to perform the Thermal Protection System (TPS) repair, and then retrace back through the trajectory to dock the Orbiter with the Orbiter Docking System (ODS). The initial and final segments of this operation involve the interaction between the SRMS, ISS, Orbiter and ODS. Previously, a technique entitled "SRMS assisted docking" for installation of a payload to the ODS had been developed and was utilized for the Russian provided Docking Module on STS-74 during Shuttle-Mir missions and both the Node 1 and FGB elements on STS-88/Flight 2A. This procedure consisted of the SRMS grappling the respective payload, maneuvering it to a pre-install position inches above the ODS Androgynous Peripheral Attachment System (APAS) ring, commanding the SRMS into Test mode (which allows brakes-off motion of the joints), and then down-firing Primary Reaction Control System (PRCS) jets in order to effect a capture of the APAS latches. Once a successful capture had been achieved, then the AP AS was operated through its nominal retraction sequence to complete the mating sequence. While this technique can once again be used for the tail end docking portion of the ORM, the initial undocking of the orbiter and ISS vehicles with the assistance of the SRMS has yet to be attempted on orbit. The objective here is to determine the most efficient means to separate or extract the vehicles. Two techniques were analyzed in support of RTF: (1) the 'nominal' demating from the mated interface, and (2) the SRMS performing the operation (either in an active or passive fashion). In the first operation, the demating process would replicate standard undocking operations, with the exception that the SRMS is allowed to arrest the resulting motion. The second operation would be to extend the APAS ring to a ready to dock position, open the capture latches, and then detach the vehicles using the SRMS either actively or passively. In the active case, the APAS ring is extended and latched, and the SRMS is commanded to pull the two interfaces apart (assuming that the effective pull force of the SRMS can overcome the spec values of the combined latch resistance). In the passive case, the SRMS brakes are engaged and the AP AS mechanism is commanded to retract, pulling the two interfaces apart. Since the emphasis of both STS-74 and STS-88 had solely been on the installation operation, as opposed to the separation operation, two new models required development and incorporation within simulation tools designed to analyze those scenarios. These enhancements included: (1) a detailed demating dynamics model to characterize the pusher spring characteristics during undocking, and (2) contact and mechanical system modeling of the back side of the latches to represent unlatching dynamics. This paper first provides an overview of the Monte-Carlo screening analysis for the installation (both nominal and contingency), including the variation of separation distance, misalignment conditions, SRMS joint/brake parameter characteristics, and PRCS jet combinations and corresponding thrust durations. The resulting 'optimum' solution is presented based on trade studies between predicted capture success and integrated system loads. This paper then discusses the upgrades to the APAS math model associated with the new SRMS assisted undocking technique and reviews simulation results for various options investigated for either the active and passive separation of the ISS from the Orbiter.

Space Station Remote Manipulator System↗
DOE OSTI2024

Web Based Beamline Control System (Bluesky Web) v0.1.0

Bluesky Web is a web based interface that provides beam line controls to the end user. It allows users to issue commands to various physical devices at a beam line end station like motors and cameras. It utilizes an open source Python library (Bluesky) as the controller. It uses Bluesky to also allow for running "plans" or a sequence of device operations that can be used when running an experiment. This program is different from other controls technologies because it is intended to be open source and can be accessed from a web browser, as opposed to other paid software that is run as a stand-alone application on a computer.

De Leon, Seij↗