Search NASA⌕ Search

SEARCH · Search NASA

Results for “trigger concepts and systems”

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.

78 records · Page 5
All sourcesNASA NTRSDOE OSTI
NASA NTRS1994

A new communication protocol family for a distributed spacecraft control system

In this paper we describe the concepts behind and architecture of a communication protocol family, which was designed to fulfill the communication requirements of ESOC's new distributed spacecraft control system SCOS 2. A distributed spacecraft control system needs a data delivery subsystem to be used for telemetry (TLM) distribution, telecommand (TLC) dispatch and inter-application communication, characterized by the following properties: reliability, so that any operational workstation is guaranteed to receive the data it needs to accomplish its role; efficiency, so that the telemetry distribution, even for missions with high telemetry rates, does not cause a degradation of the overall control system performance; scalability, so that the network is not the bottleneck both in terms of bandwidth and reconfiguration; flexibility, so that it can be efficiently used in many different situations. The new protocol family which satisfies the above requirements is built on top of widely used communication protocols (UDP and TCP), provides reliable point-to-point and broadcast communication (UDP+) and is implemented in C++. Reliability is achieved using a retransmission mechanism based on a sequence numbering scheme. Such a scheme allows to have cost-effective performances compared to the traditional protocols, because retransmission is only triggered by applications which explicitly need reliability. This flexibility enables applications with different profiles to take advantage of the available protocols, so that the best rate between sped and reliability can be achieved case by case.

Baldi, Andrea↗
NASA NTRS2004

Multifunctional Inflatable Structure Being Developed for the PowerSphere Concept

NASA has funded a collaborative team of The Aerospace Corporation, ILC Dover, Lockheed Martin, and NASA Glenn Research Center to develop the Multifunctional Inflatable Structure (MIS) for a "PowerSphere" concept through a NASA Research Announcement. This power system concept has several advantages, including a high collection area, low weight and stowage volume, and the elimination of all solar array pointing mechanisms. The current 3-year effort will culminate with the fabrication and testing of a fully functional engineering development unit. The baseline design of the Power-Sphere consists of two opposing semispherical domes connected to a central spacecraft. Each semispherical dome consists of hexagonal and pentagonal solar cell panels that together form a geodetic sphere. Inflatable ultraviolet (UV) rigidizable tubular hinges between the solar cell panels and UV rigidizable isogrid center columns with imbedded flex circuitry form the MIS. The reference configuration for the PowerSphere is a 0.6-m-diameter (fully deployed) spacecraft with a total mass budget of 4 kg (1 kg for PowerSphere, 3 kg for spacecraft) capable of producing 29 W of electricity with 10-percent-efficient thin-film solar cells. In a stowed configuration, the solar cell panels will be folded sequentially to the outside of the instrument decks. The center column will be z-folded between the instrument decks and the spacecraft housing for packaging. The instrument panel will secure the z-folded stack with launch ties. After launch, once the release tie is triggered, the center column and hinge tubes will inflate and be rigidized in their final configurations by ultraviolet radiation. The overall PowerSphere deployment sequence is shown pictorially in the following illustration.

Peterson, Todd T.↗
NASA NTRS2011

Tracking Object Existence From an Autonomous Patrol Vehicle

An autonomous vehicle patrols a large region, during which an algorithm receives measurements of detected potential objects within its sensor range. The goal of the algorithm is to track all objects in the region over time. This problem differs from traditional multi-target tracking scenarios because the region of interest is much larger than the sensor range and relies on the movement of the sensor through this region for coverage. The goal is to know whether anything has changed between visits to the same location. In particular, two kinds of alert conditions must be detected: (1) a previously detected object has disappeared and (2) a new object has appeared in a location already checked. For the time an object is within sensor range, the object can be assumed to remain stationary, changing position only between visits. The problem is difficult because the upstream object detection processing is likely to make many errors, resulting in heavy clutter (false positives) and missed detections (false negatives), and because only noisy, bearings-only measurements are available. This work has three main goals: (1) Associate incoming measurements with known objects or mark them as new objects or false positives, as appropriate. For this, a multiple hypothesis tracker was adapted to this scenario. (2) Localize the objects using multiple bearings-only measurements to provide estimates of global position (e.g., latitude and longitude). A nonlinear Kalman filter extension provides these 2D position estimates using the 1D measurements. (3) Calculate the probability that a suspected object truly exists (in the estimated position), and determine whether alert conditions have been triggered (for new objects or disappeared objects). The concept of a probability of existence was created, and a new Bayesian method for updating this probability at each time step was developed. A probabilistic multiple hypothesis approach is chosen because of its superiority in handling the uncertainty arising from errors in sensors and upstream processes. However, traditional target tracking methods typically assume a stationary detection volume of interest, whereas in this case, one must make adjustments for being able to see only a small portion of the region of interest and understand when an alert situation has occurred. To track object existence inside and outside the vehicle's sensor range, a probability of existence was defined for each hypothesized object, and this value was updated at every time step in a Bayesian manner based on expected characteristics of the sensor and object and whether that object has been detected in the most recent time step. Then, this value feeds into a sequential probability ratio test (SPRT) to determine the status of the object (suspected, confirmed, or deleted). Alerts are sent upon selected status transitions. Additionally, in order to track objects that move in and out of sensor range and update the probability of existence appropriately a variable probability detection has been defined and the hypothesis probability equations have been re-derived to accommodate this change. Unsupervised object tracking is a pervasive issue in automated perception systems. This work could apply to any mobile platform (ground vehicle, sea vessel, air vehicle, or orbiter) that intermittently revisits regions of interest and needs to determine whether anything interesting has changed.

Wolf, Michael↗
NASA NTRS2018

Using the cFS Command and Data Dictionary (CCDD) to Automate Software Development on Habulous

Final paper is attached. The NASA developed Core Flight System (cFS) is a reusable software architecture that has been used on multiple spaceflight missions. By using this framework, missions are able to reuse code from other missions, as well as leverage deployment onto similar computer architectures (i.e. not "reinvent the wheel" on each new mission). The success in the cFS concept can be seen in the large number of projects using cFS at FSW-2018. The Habulous project is an Earth-based testbed, used for hardware and software that may one day be used on a future space habitat unit, with many participating groups from various NASA centers and aerospace organizations around the country. The distributed nature of the various teams mean that defining (and following) an interface definition is critical on the project. Additionally, since various groups use various types of computer hardware (32/64-bit, big/little endian, Linux/VxWorks/Windows) many additional complications exist in interfacing all the various components into a final integrated system. cFS is used on the majority the flight software (FSW) in running in Habulous. But some subsystems have elected to not use cFS, and use a software bridge (called SBN_lib) to interact with the other cFS nodes in Habulous. In order to most efficiently develop the FSW, a central database is used to define and store each message sent by cFS. A Command and Data Dictionary (CDD) is something nearly universal on spacecraft, but as a team we worked to develop the CDD before the SW development was complete, and not treat it like "as built" documentation. To manage the CDD, the cFS Command and Data Dictionary (CCDD) tool was chosen (available from NASA as open source software). The CCDD tool has successfully been used to automate/autocode a large amount of software used on Habulous, as we are hoping to use it to define even more items in the future (time-triggered Ethernet (TTE) network maps, CPU scheduling). Additionally, Habulous has been exploring the use of cFS on wildly heterogeneous CPUs, and how to coordinate all those various machines using/extending the software bus – network (SBN) application in cFS, as well as TTE to coordinate message passing between various synchronized machines. The major topics to be covered in the presentation are: (1) Updating to the CCSDS_v2 extended headers (and using CPU# as subsystem ID). (2) Managing all the message identification numbers for each cFS message sent/received on any of the various CPUs. (3) Using the CCDD information to automatically generate the C-header files that define the structure for all software bus (SB) commands/telemetry messages. (4) Using the CCDD to automatically generate XML Telemetry and Command Exchange (XTCE) files, which streams display production/integration/testing in a web based display architecture (5) Extending/customizing SBN to pass messages among computers on multiple networks. (6) Using "Protobetter" inside SBN to manage different endian-ness/architectures. (7) Using SBN_lib to allow non-cFS node to communicate with cFS nodes. (8) Developing TTE network and schedule tables for all the various CPUs to use.

Hirsh, Robert L.↗
NASA NTRS2007

Loss-of-Control-Inhibitor Systems for Aircraft

Systems to provide improved tactile feedback to aircraft pilots are being developed to help the pilots maintain harmony between their control actions and the positions of aircraft control surfaces, thereby helping to prevent loss of control. A system of this type, denoted a loss-of-control-inhibitor system (LOCIS) can be implemented as a relatively simple addition to almost any pre-existing flight-control system. The LOCIS concept offers at least a partial solution to the problem of (1) keeping a pilot aware of the state of the control system and the aircraft and (2) maintaining sufficient control under conditions that, as described below, have been known to lead to loss of control. Current commercial aircraft exhibit uneven responses of primary flight-control surfaces to aggressive pilot control commands, leading to deterioration of pilots ability to control their aircraft. In severe cases, this phenomenon can result in loss of control and consequent loss of aircraft. For an older aircraft equipped with a purely mechanical control system, the loss of harmony between a pilot s command action and the control- surface response can be attributed to compliance in the control system (caused, for example, by stretching of control cables, flexing of push rods, or servo-valve distortion). In a newer aircraft equipped with a fly-by-wire control system, the major contributions to loss of harmony between the pilot and the control surfaces are delays attributable to computer cycle time, control shaping, filtering, aliasing, servo-valve distortion, and actuator rate limiting. In addition, a fly-by-wire control system provides no tactile feedback that would enable the pilot to sense such features of the control state as surface flutter, surface jam, position limiting, actuator rate limiting, and control limiting imposed by the aircraft operational envelope. Hence, for example, when a pilot is involved in aggressive closed-loop maneuvering, as when encountering a wake-vortex upset on final landing approach, the control-surface delay can lead to loss of control. Aggressive piloting can be triggered and exacerbated by control-system anomalies, which the pilot cannot diagnose because of the lack of symptoms caused by the absence of feedback through the controls. The purpose served by a LOCIS is to counteract these adverse effects by providing real-time feedback that notifies the pilot that the aircraft is tending to lag the pilot s commands. A LOCIS (see figure) includes cockpit control input-position sensors, control-surface output-position sensors, variable dampers (for example, shock absorbers containing magneto-rheological fluids such that the damping forces can be varied within times of the order of milliseconds by varying applied magnetic fields) attached to the cockpit control levers, electromagnet coils to apply the magnetic fields, and feedback control circuits to drive the electromagnet coils. The feedback control gains are chosen so that the current applied to each electromagnet coil results in a damping force that increases in a suitable nonlinear manner (e.g., exponentially) with the difference between the actual and commanded positions of the affected control surface. The increasing damping force both alerts the pilot to the onset of a potentially dangerous situation and resists the pilot s effort to command a control surface to change position at an excessive rate

AHarrah, Ralph C.↗
NASA NTRSDate not supplied

Using Open Standards and NASA Open Source Simulation Tools to Model Artemis Base Camp Mission Timelines

The United States’ National Aeronautics and Space Administration (NASA) has announced that the Artemis Program will return humans to the Moon, establishing a persistent presence with the Artemis Base Camp (ABC), and extend human exploration to Mars. The NASA Exploration Systems Simulations (NExSyS) team at NASA’s Johnson Space Center is using internationally developed simulation interoperability standards and NASA open source simulation tools to support Artemis concept, analysis, designs, development, training, and ultimately operations. The NExSyS team has been tasked to support early ABC architecture and mission analysis using mission time lines developed by the crew operations mission planning team. The NExSyS team is developing a distributed simulation framework with initial Artemis element implementations to model the ABC mission timelines using the international simulation interoperability standard High Level Architecture (HLA), the Simulation Interoperability Standards Organization’s Space Reference Federation Object Model (SpaceFOM), the NASA open source Trick Simulation Environment, and another NASA open source interface package called TrickHLA. The ABC architecture is composed of a number of key surface elements and resources. Some examples of modeled elements (also known as entities) are landers, habitats, rovers, logistics carriers, and astronauts. Some examples of modeled transferable and consumable resources are power, water, oxygen, nitrogen, scientific samples, and food. These entities and resources are modeled in a collection of individual simulations called Federates. A coordinated collection of interoperable federates is called a Federation and when these federates are tied together in a coordinated simulation run, it is referred to as a Federation Execution. The federates communicate through HLA using data exchange formats defined by a collection of machine readable files called Federation Object Models (FOMs). These FOM files are based on extensions to the SpaceFOM. This enables the instantiation and sharing of objects and interactions between federates in the federation. These provide for entity and resource tracking, object transfer, and data collection. Federate interactions are used to trigger events and notify federates of entity or resource transfers. For the initial implementation, the constituent federates are Trick-based simulations that use TrickHLA to provide the required HLA-base interoperability. These Trick-based simulations provide the required modeling for the individual Artemis elements along with the associated element resources. These federates provide a means to explore traverses between surface elements and exploration sites as scheduled in a mission timeline and explore the affects traverse times have on the overall mission timeline. The mission time lines are modeled using a Trick input file event handling capabilities. Each timeline operation is handled as individual simulation events, and triggered based on previous event status, time of operation, and simulated task completions. In addition, the ABC Federation can be used to perform Monte Carlo analysis. The Monte Carlo tool can vary the inputs, timings, and malfunctions to show how various contingencies in the mission can affect the mission timeline.

Keaton Craig Dodd↗