Search NASA⌕ Search

SEARCH · Search NASA

Results for “Command and Tracking”

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 811 records · Page 45

A COTS-Based Attitude Dependent Contact Scheduling System

The mission architecture of the Gamma-ray Large Area Space Telescope (GLAST) requires a sophisticated ground system component for scheduling the downlink of science data. Contacts between the ````````````````` satellite and the Tracking and Data Relay Satellite System (TDRSS) are restricted by the limited field-of-view of the science data downlink antenna. In addition, contacts must be scheduled when permitted by the satellite s complex and non-repeating attitude profile. Complicating the matter further, the long lead-time required to schedule TDRSS services, combined with the short duration of the downlink contact opportunities, mandates accurate GLAST orbit and attitude modeling. These circumstances require the development of a scheduling system that is capable of predictively and accurately modeling not only the orbital position of GLAST but also its attitude. This paper details the methods used in the design of a Commercial Off The Shelf (COTS)-based attitude-dependent. TDRSS contact Scheduling system that meets the unique scheduling requirements of the GLAST mission, and it suggests a COTS-based scheduling approach to support future missions. The scheduling system applies filtering and smoothing algorithms to telemetered GPS data to produce high-accuracy predictive GLAST orbit ephemerides. Next, bus pointing commands from the GLAST Science Support Center are used to model the complexities of the two dynamic science gathering attitude modes. Attitude-dependent view periods are then generated between GLAST and each of the supporting TDRSs. Numerous scheduling constraints are then applied to account for various mission specific resource limitations. Next, an optimization engine is used to produce an optimized TDRSS contact schedule request which is sent to TDRSS scheduling for confirmation. Lastly, the confirmed TDRSS contact schedule is rectified with an updated ephemeris and adjusted bus pointing commands to produce a final science downlink contact schedule.

DeGumbia, Jonathan D.↗

Operating Small Sat Swarms as a Single Entity: Introducing SODA

Swarm concepts are a growing topic of interest in the small satellite community. Compared to a small satellite constellation, a swarm has the distinction of being multiple spacecraft in close proximity, in approximately the same orbit. Furthermore, we envision swarms to have capabilities for cross-link communication and station-keeping. Of particular interest is a means to maintain operator-specified geometry, alignment, and/or separation.From NASA's decadal survey, it is clear that simultaneous measurements from a 3D volume of space are desired for a variety of Earth scientific studies. As this mission concept is ultimately extended to deep space, some degree of local control for the swarm to self-correct its configuration is required. We claim that the practicality of ground commanding each individual satellite in the swarm is simply not a feasible concept of operations. In other words, the current state-of-practice does not scale to very large swarms (e.g. 100 spacecraft or more) without becoming cost prohibitive. To contain the operations costs and complexity, a new approach is required: the swarm must be operated as a unit, responding to high-level specifications for relative position and velocity.The Mission Design Division at NASA Ames Research Center is looking to the near future for opportunities to develop satellite swarm technology. As part of this effort, we are developing SODA (Swarm Orbital Dynamics Advisor), a tool that provides the orbital maneuvers required to achieve a desired type of relative swarm motion. The purpose of SODA is two-fold. First, it encompasses the algorithms and orbital dynamics model to enable the desired relative motion of the swarm satellites. The process starts with the user specifying the properties of a swarm configuration. This could be as simple as varying in-track spacing of the swarm in one orbit, or as complex as maintaining a specified 3D geometrical orientation. We presume that science objectives will drive this choice. Given these inputs, the tool provides the most efficient maneuver(s) to achieve the objective.Second, SODA provides a variety of visualization tools. We acknowledge that the relationship between a desired relative motion amongst the swarm, and the corresponding orbital parameters for each individual satellite may not be immediately apparent for ground controllers and mission planners. The purpose of SODA's visualization tools is to illustrate this concept clearly with a variety of graphics and animations. After computing the optimal orbital maneuvers to modify the swarm, these results are simulated to demonstrate successful swarm control.Our emphasis in this paper is on the importance of relating the desired motion of the swarm satellites relative to one another with the required orbital element changes. One cannot joystick a drifting swarm satellite back into position; the underlying orbital mechanics dictate the most efficient recovery maneuvers. To illustrate this point, results from several case study simulations are presented. We conclude with our forward work for ongoing SODA development and potential science applications.

small satellites↗

Autonomous Navigation Using Celestial Objects

In the twenty-first century, National Aeronautics and Space Administration (NASA) Enterprises envision frequent low-cost missions to explore the solar system, observe the universe, and study our planet. Satellite autonomy is a key technology required to reduce satellite operating costs. The Guidance, Navigation, and Control Center (GNCC) at the Goddard Space Flight Center (GSFC) currently sponsors several initiatives associated with the development of advanced spacecraft systems to provide autonomous navigation and control. Autonomous navigation has the potential both to increase spacecraft navigation system performance and to reduce total mission cost. By eliminating the need for routine ground-based orbit determination and special tracking services, autonomous navigation can streamline spacecraft ground systems. Autonomous navigation products can be included in the science telemetry and forwarded directly to the scientific investigators. In addition, autonomous navigation products are available onboard to enable other autonomous capabilities, such as attitude control, maneuver planning and orbit control, and communications signal acquisition. Autonomous navigation is required to support advanced mission concepts such as satellite formation flying. GNCC has successfully developed high-accuracy autonomous navigation systems for near-Earth spacecraft using NASA's space and ground communications systems and the Global Positioning System (GPS). Recently, GNCC has expanded its autonomous navigation initiative to include satellite orbits that are beyond the regime in which use of GPS is possible. Currently, GNCC is assessing the feasibility of using standard spacecraft attitude sensors and communication components to provide autonomous navigation for missions including: libration point, gravity assist, high-Earth, and interplanetary orbits. The concept being evaluated uses a combination of star, Sun, and Earth sensor measurements along with forward-link Doppler measurements from the command link carrier to autonomously estimate the spacecraft's orbit and reference oscillator's frequency. To support autonomous attitude determination and control and maneuver planning and control, the orbit determination accuracy should be on the order of kilometers in position and centimeters per second in velocity. A less accurate solution (one hundred kilometers in position) could be used for acquisition purposes for command and science downloads. This paper provides performance results for both libration point orbiting and high Earth orbiting satellites as a function of sensor measurement accuracy, measurement types, measurement frequency, initial state errors, and dynamic modeling errors.

Folta, David↗

A proven approach for more effective software development and maintenance

Modern space flight mission operations and associated ground data systems are increasingly dependent upon reliable, quality software. Critical functions such as command load preparation, health and status monitoring, communications link scheduling and conflict resolution, and transparent gateway protocol conversion are routinely performed by software. Given budget constraints and the ever increasing capabilities of processor technology, the next generation of control centers and data systems will be even more dependent upon software across all aspects of performance. A key challenge now is to implement improved engineering, management, and assurance processes for the development and maintenance of that software; processes that cost less, yield higher quality products, and that self-correct for continual improvement evolution. The NASA Goddard Space Flight Center has a unique experience base that can be readily tapped to help solve the software challenge. Over the past eighteen years, the Software Engineering Laboratory within the code 500 Flight Dynamics Division has evolved a software development and maintenance methodology that accommodates the unique characteristics of an organization while optimizing and continually improving the organization's software capabilities. This methodology relies upon measurement, analysis, and feedback much analogous to that of control loop systems. It is an approach with a time-tested track record proven through repeated applications across a broad range of operational software development and maintenance projects. This paper describes the software improvement methodology employed by the Software Engineering Laboratory, and how it has been exploited within the Flight Dynamics Division with GSFC Code 500. Examples of specific improvement in the software itself and its processes are presented to illustrate the effectiveness of the methodology. Finally, the initial findings are given when this methodology was applied across the mission operations and ground data systems software domains throughout Code 500.

Pajerski, Rose↗

Effect of Satellite Formations and Imaging Modes on Global Albedo Estimation

We confirm the applicability of using small satellite formation flight for multi-angular earth observation to retrieve global, narrow band, narrow field-of-view albedo. The value of formation flight is assessed using a coupled systems engineering and science evaluation model, driven by Model Based Systems Engineering and Observing System Simulation Experiments. Albedo errors are calculated against bi-directional reflectance data obtained from NASA airborne campaigns made by the Cloud Absorption Radiometer for the seven major surface types, binned using MODIS' land cover map - water, forest, cropland, grassland, snow, desert and cities. A full tradespace of architectures with three to eight satellites, maintainable orbits and imaging modes (collective payload pointing strategies) are assessed. For an arbitrary 4-sat formation, changing the reference, nadir-pointing satellite dynamically reduces the average albedo error to 0.003, from 0.006 found in the static reference case. Tracking pre-selected waypoints with all the satellites reduces the average error further to 0.001, allows better polar imaging and continued operations even with a broken formation. An albedo error of 0.001 translates to 1.36 W/sq m or 0.4% in Earth's outgoing radiation error. Estimation errors are found to be independent of the satellites' altitude and inclination, if the nadir-looking is changed dynamically. The formation satellites are restricted to differ in only right ascension of planes and mean anomalies within slotted bounds. Three satellites in some specific formations show average albedo errors of less than 2% with respect to airborne, ground data and seven satellites in any slotted formation outperform the monolithic error of 3.6%. In fact, the maximum possible albedo error, purely based on angular sampling, of 12% for monoliths is outperformed by a five-satellite formation in any slotted arrangement and an eight satellite formation can bring that error down four fold to 3%. More than 70% ground spot overlap between the satellites is possible with 0.5deg of pointing accuracy, 2 Km of GPS accuracy and commands uplinked once a day. The formations can be maintained at less than 1 m/s of monthly (Delta)V per satellite.

BRDF↗

Mars Global Surveyor Ka-Band Frequency Data Analysis

The Mars Global Surveyor (MGS) spacecraft, launched on November 7, 1996, carries an experimental space-to-ground telecommunications link at Ka-band (32 GHz) along with the primary X-band (8.4 GHz) downlink. The signals are simultaneously transmitted from a 1.5-in diameter parabolic high gain antenna (HGA) on MGS and received by a beam-waveguide (BWG) R&D 34-meter antenna located in NASA's Goldstone Deep Space Network (DSN) complex near Barstow, California. The projected 5-dB link advantage of Ka-band relative to X-band was confirmed in previous reports using measurements of MGS signal strength data acquired during the first two years of the link experiment from December 1996 to December 1998. Analysis of X-band and Ka-band frequency data and difference frequency (f(sub x)-f(sub ka)/3.8) data will be presented here. On board the spacecraft, a low-power sample of the X-band downlink from the transponder is upconverted to 32 GHz, the Ka-band frequency, amplified to I-W using a Solid State Power Amplifier, and radiated from the dual X/Ka HGA. The X-band signal is amplified by one of two 25 W TWTAs. An upconverter first downconverts the 8.42 GHz X-band signal to 8 GHz and then multiplies using a X4 multiplier producing the 32 GHz Ka-band frequency. The frequency source selection is performed by an RF switch which can be commanded to select a VCO (Voltage Controlled Oscillator) or USO (Ultra-Stable Oscillator) reference. The Ka-band frequency can be either coherent with the X-band downlink reference or a hybrid combination of the USO and VCO derived frequencies. The data in this study were chosen such that the Ka-band signal is purely coherent with the X-band signal, that is the downconverter is driven by the same frequency source as the X-band downlink). The ground station used to acquire the data is DSS-13, a 34-meter BWG antenna which incorporates a series of mirrors inside beam waveguide tubes which guide the energy to a subterranean pedestal room, providing a stable environment for the feed and electronics equipment. A dichroic plate is used to reflect the X-band energy and pass the Ka-band energy to another mirror. The RF energy for each band is then focused onto a feed horn and low-noise amplifier package. After amplification and RF/IF downconversion, the IF signals are sent to the Experimental Tone Tracker (ETT), a digital phase-lock-loop receiver, which simultaneously tracks both X-band and Ka-band carrier signals. Once a signal is detected, the ETT outputs estimates of the SNR in a I -Hz bandwidth (Pc/No), baseband phase and frequency of the signals every I -sec. Between December 1996 and December 1998, the Ka-band and X-band signals from MGS were tracked on a regular basis using the ETT. The Ka-band downlink frequencies described here were referenced to the spacecraft's on-board USO which was also the X-band frequency reference (f(sub ka)= 3.8 f(sub x)). The ETT estimates of baseband phase at I -second sampled time tags were converted to sky frequency estimates. Frequency residuals were then generated for each band by removing a model frequency from each observable frequency at each time tag. The model included Doppler and other effects derived from spacecraft trajectory files obtained from the MGS Navigation Team. A simple troposphere correction was applied to the data. In addition to residuals, the USO frequencies emitted by the spacecraft were estimated. For several passes, the USO frequencies were determined from X-band data and from Ka-band data (referred to X-band by dividing by 3.8) and were found to be in good agreement. In addition, X-band USO frequency estimates from MGS Radio Science data acquired from operational DSN stations were available for comparison and were found to agree within the I Hz level. The remaining sub-Hertz differences were attributed to the different models and software algorithms used by MGS Radio Science and KaBLE-11. A summary of the results of a linear fit of the USO frequency versus time (day of year) is presented in Table I for an initial segment of passes.

Morabito, D.↗

Communicating by Doppler: Detecting Spacecraft Dynamics During Critical Maneuvers

Communicating information from spacecraft in deep space utilizes sophisticated techniques of modulations onto a microwave signal carrier. Under most conditions, there is a high success rate of sending commands to the spacecraft and receiving science data acquired by on-board instruments along with health and status information. There are conditions, however, where the signal dynamics are too high and/or the received signal-to-noise ratio is below the receiver threshold. Under these conditions, often by design and sometimes as a result of planned or unplanned critical maneuvers, events (e.g., orbit insertion or descent and landing), safe mode, etc., it becomes highly critical but exceedingly challenging to receive information about the health and dynamical behavior of the spacecraft. The Deep Space Network, being a world-class instrument for Radio Science research, developed openloop receivers, called the Radio Science Receiver, designed to capture the raw incoming electromagnetic signals and associated noise for Radio Science experiments; post data capture digital signal processing extracts the signal carrier for scientific analysis. This receiver provides a high level of configuration flexibility and can be optimized for the various types of experiments. In addition to its scientific utility, it proved to be useful, and in some cases critical, for the support of missions during specific scenarios were the link budget is below the threshold of the tracking receiver to maintain lock or the frequency dynamics are faster than the limits of the tracking receiver. In these cases, the signal carrier is often detected only in the open-loop receiver to provide information on the specific behavior of the spacecraft from the carrier dynamics. This paper describes the utility of the system to support mission-critical events for the three cases of Cassini's Saturn orbit insertion, Huygens Titan landing, and Mars rovers landing.

radio science↗

Modular Software Interfaces for Revolutionary Flexibility in Space Operations

To make revolutionary improvements in exploration, space systems need to be flexible, realtime reconfigurable, and able to trade data transparently among themselves and mission operations. Onboard operations systems, space assembly coordination and EVA systems in exploration and construction all require real-time modular reconfigurability and data sharing. But NASA's current exploration systems are still largely legacies from hastily-developed, one-off Apollo-era practices. Today's rovers, vehicles, spacesuits, space stations, and instruments are not able to plug-and-play, Lego-like: into different combinations. Point-to-point dominates - individual suit to individual vehicle, individual instrument to rover. All are locally optimized, all unique, each of the data interfaces has been recoded for each possible combination. This will be an operations and maintenance nightmare in the much larger Project Constellation system of systems. This legacy approach does not scale to the hundreds of networked space components needed for space construction and for new, space-based approaches to Earth-Moon operations. By comparison, battlefield information management systems, which are considered critical to military force projection, have long since abandoned a point-to-point approach to systems integration. From a system-of-systems viewpoint, a clean-sheet redesign of the interfaces of all exploration systems is a necessary prerequisite before designing the interfaces of the individual exploration systems. Existing communications and Global Information Grid and middleware technologies are probably sufficient for command and control and information interfaces, with some hardware and time-delay modifications for space environments. NASA's future advanced space operations must also be information and data compatible with aerospace operations and surveillance systems being developed by other US Government agencies such as the Department of Homeland Security, Federal Aviation Administration and Department of Defense. This paper discusses fundamental system-of-systems infrastructure: approaches and architectures for modular plug-and-play software interfaces for revolutionary improvements in flexibility, modularity, robustness, ease of maintenance, reconfigurability, safety and productivity. Starting with middleware, databases, and mobile communications technologies, our technical challenges will be to apply these ideas to the requirements of constellations of space systems and to implement them initially on prototype space hardware. This is necessary to demonstrate an integrated information sharing architecture and services. It is a bottom-up approach, one that solves the problem of space operations data integration. Exploration demands uniform software mechanisms for application information interchange, and the corresponding uniformly available software services to enhance these mechanisms. We will examine the issues in plug-and-play, real-time-configurable systems, including common definition and management and tracking of data and information among many different space systems. Different field test approaches are discussed, including the use of the International Space Station and terrestrial analog mission operations at field sites.

Glass, Brian↗

Human Flight to Lunar and Beyond - Re-Learning Operations Paradigms

For the first time since the Apollo era, NASA is planning on sending astronauts on flights beyond Low-Earth Orbit (LEO). The Human Space Flight (HSF) program started with a successful initial flight in Earth orbit, in December 2014. The program will continue with two Exploration Missions (EM) to Lunar orbit: EM-1 will be unmanned and EM-2, carrying astronauts, will follow. NASA established a multi-center team to address the communications, and related navigation, needs. This paper will focus on the lessons learned in the team, planning for the missions' parts that are beyond Earth orbit. Many of these lessons had to be re-learned, as the HSF program after operated for many years in Earth orbit. Fortunately, the experience base from tracking robotic missions in deep space by the Deep Space Network (DSN) and close interaction with the HSF community to understand the unique needs (e.g. 2-way voice) resulted in a ConOps that leverages of both the deep space robotic and the Human LEO experiences. Several examples will be used to highlight the unique operational needs for HSF missions beyond Earth Orbit, including: - Navigation. At LEO, HSF missions can rely on Global Positioning System (GPS) devices for orbit determination. For Lunar-and-beyond HSF missions, techniques such as precision 2-way and 3-way Doppler and ranging, Delta-Difference-of-range, and eventually on-board navigation will be used. - Impact of latency - the delay associated with Round-Trip-Light-Time (RTLT). Imagine trying to have a 2-way discussion (audio or video) with an astronaut, with a 2-3 sec delay inserted (for Lunar distances) or 20 minutes delay (for Mars distances). - Balanced communications link. For robotic missions, there has been a heavy emphasis on the downlink data rates, bringing back science data from the instruments on-board the spacecraft. Uplink data rates were of secondary importance, used to send commands to the spacecraft. The ratio of downlink-to-uplink data rates was often 10:1 or more. For HSF, rates for uplink and downlink, at least for high-quality video, need to be similar.

Kenny, Ted↗

STS-109 Mission Highlights Resource Tape: Flight Days 1 - 3 - Part 1 of 4

This video, Part 1 of 4, shows the activities of the STS-109 crew (Scott Altman, Commander; Duane Carey, Pilot; John Grunsfeld, Payload Commander; Nancy Currie, James Newman, Richard Linnehan, Michael Massimino, Mission Specialists) during flight days 1 through 3. The activities from other flight days can be seen on 'STS 109 Mission Highlights Resource Tape' Part 2 of 4 (internal ID 2002137664), 'STS 109 Mission Highlights Resource Tape' Part 3 of 4 (internal ID 2002139471), and 'STS-109 Mission Highlights Resource Tape' Part 4 of 4 (internal ID 2002137577). The main activity recorded during flight day 1 is the liftoff of Columbia. Attention is given to suit-up, boarding, and pre-flight procedures. The pre-launch crew meal has no sound. The crew members often wave to the camera before liftoff. The jettisoning of the solid rocket boosters is shown, and the External Tank is seen as it falls to Earth, moving over African dunes in the background. There are liftoff replays, including one from inside the cockpit. The opening of the payload bay doors is seen from the rear of the shuttle's cockpit. The footage from flight day 2 shows the Flight Support System for bearthing the HST (Hubble Space Telescope). Crew preparations for the bearthing are shown. Flight day 3 shows the tracking of and approach to the HST by Columbia, including orbital maneuvers, the capture of the HST, and its lowering onto the Flight Support System. Many views of the HST are shown, including one which reveals an ocean and cloud background as the HST retracts a solar array.

Source record↗

Rovers for Mars Polar Exploration

Mobility is a generic capability needed for Mars exploration. Requirements for mobility range from those to get observations of individual rocks all the way to getting high resolution observations of regional areas. Table 1 shows the required-range of mobility to achieve various tasks. The Pathfinder mission and field experiments simulating rover missions [1, 2, 3, 4, 5] provide guidance as to rover capabilities that can reasonably be expected in the next decade. Rover mobility can be accomplished in a variety of ways, the most common being wheels or tracks and legged-walkers. Wheeled vehicles can traverse over rocks smaller than 1/2 wheel diameter, and with path planning to avoid larger rocks, can traverse terrains comparable to those seen on Mars in the Viking and Pathfinder landing sites. Slopes of 45 deg can be easily negotiated by wheeled rovers. Walking vehicles can negotiate even more complex terrain but requires computation capability to select each leg placement. Extremely complex terrain was traversed by the Nomad II walker which descended into (and most of the way out of) an active volcanic caldera (Mount Spur, AK) in 1995, although a slope failure eventually resulted in broken legs. The traverse range of a rover is limited by its science objectives, performance capabilities, and operational lifetime. The speed of rover traverse is a relative minor factor. With a different communication system, and no stops for science experiments, Sojourner could probably have traveled a kilometer. But, achieving land speed records is not a major objective of a science mission. Achieving science objectives requires targeting particular objects and studying them in detail, and the associated operational requirements will likely limit rover traverse range significantly. Traversing from target to target requires relatively few command cycles provided the traverse is over a short enough distance that it can be adequately planned. An operational goal of 100 m traverse per command cycle, arriving at a predetermined target, seems achievable. Investigating science targets requiring manipulator or instrument placement and sample collection will likely take several command cycles per target. Mission simulations [6] have demonstrated that traverse dI stances of 100-300 m, with detailed investigation of 5-10 targets take 50-100 command cycles, not unlike the Pathfinder experience in spite of the use of larger, faster, more capable rovers. Significant advances in rover autonomy will be needed to improve this Situation and it is not clear how much improvement will be brought to flight programs in the next decade. Dust accumulation on solar panels degrades power over time and, without dust removal, rover operational lifetimes may be limited to 90 sols.

Stoker, Carol↗

Command Center Training Tool (C2T2)

This abstract presents the training approach taken to create a management-centered, experiential learning solution for the Virginia Port Authority's Port Command Center. The resultant tool, called the Command Center Training Tool (C2T2), follows a holistic approach integrated across the training management cycle and within a single environment. The approach allows a single training manager to progress from training design through execution and AAR. The approach starts with modeling the training organization, identifying the organizational elements and their individual and collective performance requirements, including organizational-specific performance scoring ontologies. Next, the developer specifies conditions, the problems, and constructs that compose exercises and drive experiential learning. These conditions are defined by incidents, which denote a single, multi-media datum, and scenarios, which are stories told by incidents. To these layered, modular components, previously developed meta-data is attached, including associated performance requirements. The components are then stored in a searchable library An event developer can create a training event by searching the library based on metadata and then selecting and loading the resultant modular pieces. This loading process brings into the training event all the previously associated task and teamwork material as well as AAR preparation materials. The approach includes tools within an integrated management environment that places these materials at the fingertips of the event facilitator such that, in real time, the facilitator can track training audience performance and resultantly modify the training event. The approach also supports the concentrated knowledge management requirements for rapid preparation of an extensive AAR. This approach supports the integrated training cycle and allows a management-based perspective and advanced tools, through which a complex, thorough training event can be developed.

Jones, Phillip↗

Orbit Determination and Navigation Software Testing for the Mars Reconnaissance Orbiter

During the extended science phase of the Mars Reconnaissance Orbiter's lifecycle, the operational duties pertaining to navigation primarily involve orbit determination. The orbit determination process utilizes radiometric tracking data and is used for the prediction and reconstruction of MRO's trajectories. Predictions are done twice per week for ephemeris updates on-board the spacecraft and for planning purposes. Orbit Trim Maneuvers (OTM-s) are also designed using the predicted trajectory. Reconstructions, which incorporate a batch estimator, provide precise information about the spacecraft state to be synchronized with scientific measurements. These tasks were conducted regularly to validate the results obtained by the MRO Navigation Team. Additionally, the team is in the process of converting to newer versions of the navigation software and operating system. The capability to model multiple densities in the Martian atmosphere is also being implemented. However, testing outputs among these different configurations was necessary to ensure compliance to a satisfactory degree.

Deep Space Network↗

Reactive Sequencing for Autonomous Navigation Evolving from Phoenix Entry, Descent, and Landing

Virtual Machine Language (VML) is an award-winning advanced procedural sequencing language in use on NASA deep-space missions since 1997, and was used for the successful entry, descent, and landing (EDL) of the Phoenix spacecraft onto the surface of Mars. Phoenix EDL utilized a state-oriented operations architecture which executed within the constraints of the existing VML 2.0 flight capability, compatible with the linear "land or die" nature of the mission. The intricacies of Phoenix EDL included the planned discarding of portions of the vehicle, the complex communications management for relay through on-orbit assets, the presence of temporally indeterminate physical events, and the need to rapidly catch up four days of sequencing should a reboot of the spacecraft flight computer occur shortly before atmospheric entry. These formidable operational challenges led to new techniques for packaging and coordinating reusable sequences called blocks using one-way synchronization via VML sequencing global variable events. The coordinated blocks acted as an ensemble to land the spacecraft, while individually managing various elements in as simple a fashion as possible. This paper outlines prototype VML 2.1 flight capabilities that have evolved from the one-way synchronization techniques in order to implement even more ambitious autonomous mission capabilities. Target missions for these new capabilities include autonomous touch-and-go sampling of cometary and asteroidal bodies, lunar landing of robotic missions, and ultimately landing of crewed lunar vehicles. Close proximity guidance, navigation, and control operations, on-orbit rendezvous, and descent and landing events featured in these missions require elaborate abort capability, manifesting highly non-linear scenarios that are so complex as to overtax traditional sequencing, or even the sort of one-way coordinated sequencing used during EDL. Foreseeing advanced command and control needs for small body and lunar landing guidance, navigation and control scenarios, work began three years ago on substantial upgrades to VML that are now being exercised in scenarios for lunar landing and comet/asteroid rendezvous. The advanced state-based approach includes coordinated state transition machines with distributed decision-making logic. These state machines are not merely sequences - they are reactive logic constructs capable of autonomous decision making within a well-defined domain. Combined with the JPL's AutoNav software used on Deep Space 1 and Deep Impact, the system allows spacecraft to autonomously navigate to an unmapped surface, soft-contact, and either land or ascend. The state machine architecture enabled by VML 2.1 has successfully performed sampling missions and lunar descent missions in a simulated environment, and is progressing toward flight capability. The authors are also investigating using the VML 2.1 flight director architecture to perform autonomous activities like rendezvous with a passive hypothetical Mars sample return capsule. The approach being pursued is similar to the touch-and-go sampling state machines, with the added complications associated with the search for, physical capture of, and securing of a separate spacecraft. Complications include optically finding and tracking the Orbiting Sample Capsule (OSC), keeping the OSC illuminated, making orbital adjustments, and physically capturing the OSC. Other applications could include autonomous science collection and fault compensation.

asteroid↗

Athena-I CUBIT Journal Files

The Monte Carlo N-Particle (MCNP)1 transport code version 6 (also known as MCNP6) has the capability for tracking particles on unstructured mesh (UM) geometry models embedded into con structive solid geometry (CSG) cells. This feature has been developed for performing calculations of complex geometry models because manually creating CSG models is a time-consuming and error prone process as the complexities of geometries increase. The UM capability was originally designed to work with UM models created with the Abaqus software and ASCII input files that it generates. The MCNP code version 6.0 and later can process UM models formatted as Abaqus input files. Starting with version 6.3, MCNP can also process HDF5 mesh input files. External codes must be used to generate Abaqus input files for MCNP UM calculations. CUBIT, the Sandia National Laboratory automated mesh generation toolkit, can generate a UM model formatted as an Abaqus input file. However, the Abaqus input files exported from CUBIT cannot be used for MCNP simulations because it lacks the proper syntax. A Python script was developed to convert an Abaqus file created by CUBIT to an Abaqus file format that MCNP can process. Creating UM models for complex geometries is not an easy task. The process of creating UM models in CUBIT for MCNP simulations is detailed in. CUBIT provides several user interface options including a graphical user interface (GUI) and a command line interface. A GUI provides an easy way to use CUBIT without learning the CUBIT command syntax. When using CUBIT with either interface option, command lines are written into an ASCII file known as a journal file; this journal file can be edited and archived so that it can be played back in CUBIT to automatically generate a UM model. This report describes the CUBIT journal files of the UM models developed for Athena-I. The Athena platform, an energy-tuning assembly, was developed to spectrally shape the National Ignition Facility (NIF) deuterium-tritium fusion neutron source to a thermonuclear (fusion) plus prompt fission neutron spectrum with capability to act as a short-pulse neutron source. MCNP6 was used for the Athena experiment design analysis.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗

Flight Software Dictionary Development for the Mars2020 Rover

The Mars2020 project, developed and operated by the Jet Propulsion Laboratory (JPL), successfully landed the Perseverance rover and its flying companion Ingenuity on the surface of Mars on February 18th 2021. Perseverance combines heritage and cutting-edge flight software and hardware to accomplish crucial mission requirements related to Martian surface sampling. The design, development, and operation of NASA’s large strategic science missions require the ability to communicate spacecraft capabilities to hundreds of engineers across multiple disciplines. The interaction between flight and ground software development, Verification and Validation (V&V), Assembly, Test, and Launch Operations (ATLO), and management each demand quick understanding of unique slices of information for each discipline. This information includes the current capabilities of the flight system as well as future capabilities and their status as they are developed and tested. Despite the fundamental and critical nature of this information, the flight software dictionaries used to track it are a stumbling block for many projects. These dictionaries provide the cornerstone for the interpretation of data sent from the spacecraft, allowing for quick comprehension by engineers on the ground. During both spacecraft development and operations, flight software dictionary management includes significant challenges due to the large number of interfacing systems and the subtle yet distinct needs of each.The engineering of flight software dictionaries for Mars2020 had numerous challenges, most-notably: parallel dictionary development to support simultaneous separate flight software build campaigns for each mission phase (cruise and surface), managing requests for operations-enabling information without perturbing the heritage interface with the rover, and the introduction of new tools by the dictionary stakeholders that forced the dictionary team to innovate and redesign the heritage tool chain. These challenges generated guiding principles for the dictionary development effort: emphasize coding best practices and unit testing in the dictionary code development tool chain, use institutionally provided COTS (commercial-off-the-shelf) tools whenever possible, and maintain the heritage flight-ground interface all while advancing operations-enabling information via a loosely coupled interface.Throughout development and operations, the Mars2020 dictionary toolchain included IBM DOORS Next Generation, GitHub, Microsoft Excel, Docker, Jenkins, and a significant custom-built Python codebase. Significant interfaces included JPL’s command and control software, heritage flight software team tools and processes, and the many cloud-based ground tools developed for the mission.This paper will discuss the requirements for the Mars2020 dictionary development, the development team’s response to those requirements, lessons learned throughout the process, steps taken towards automated deliveries and continuous integration of stakeholder inputs, potential toolchain improvements for Mars2020, and key takeaways that could be applied to future missions.

Pyrzak, Guy↗

X-Ray Spectroscopy of Optically Bright Planets using the Chandra Observatory

Since its launch in July 1999, Chandra's Advanced CCD Imaging Spectrometer (ACIS) has observed several planets (Venus, Mars, Jupiter and Saturn) and 6 comets. At 0.5 arc-second spatial resolution, ACIS detects individual x-ray photons with good quantum efficiency (25% at 0.6 KeV) and energy resolution (20% FWHM at 0.6 KeV). However, the ACIS CCDs are also sensitive to optical and near-infrared light, which is absorbed by optical blocking filters (OBFs) that eliminate optical contamination from all but the brightest extended sources, e.g., planets. .Jupiter at opposition subseconds approx.45 arc-seconds (90 CCD pixels.) Since Chandra is incapable of tracking a moving target, the planet takes 10 - 20 kiloseconds to move across the most sensitive ACIS CCD, after which the observatory must be re-pointed. Meanwhile, the OBF covering that CCD adds an opt,ical signal equivalent to approx.110 eV to each pixel that lies within thc outline of the Jovian disk. This has three consequences: (1) the observatory must be pointed away from Jupiter while CCD bias maps are constructed; (2) most x-rays from within the optical image will be misidentified as charged-particle background and ignored; and (3) those x-rays that are reported will bc assigned anomalously high energies. The same also applies to thc other planets, but is less serious since they are either dimmer at optical wavelengths, or they show less apparent motion across the sky, permitting reduced CCD exposure times: the optical contamination from Saturn acids approx.15 eV per pixel, and from Mars and Venus approx.31 eV. After analyzing a series of short .Jupiter observations in December 2000, ACIS parameters were optimized for the February 2003 opposition. CCD bias maps were constructed while Chandra pointed away from Jupiter, and the subsequent observations employed on-board software to ignore any pixel that contained less charge than that expected from optical leakage. In addition, ACIS was commanded to report 5 x 5 arrays of pixel values surrounding each x-ray event, and the outlying values were employed during ground processing to correct for the optical contamination.

Ford, P. G.↗

STS-96 Mission Highlights

In this second part of a three-part video mission-highlights set, on-orbit spacecrew activities performed on the STS-96 Space Shuttle Orbiter Discovery and the International Space Station are reviewed. The flight crew consists of Kent V. Rominger, Commander; Rick D. Husband, Pilot; and Mission Specialists Ellen Ochoa, Tamara E. Jernigan, Daniel T. Barry, Julie Payette (Canadian), and Valery Ivanovich Tokarev (Russian). The primary goals of this mission were to work on logistics and resupply the International Space Station. This second part in the mission series features video from Flight Day 4-7 (FD 4-7). FD 4 of STS-96 presents astronauts Tammy Jernigan and Dan Barry completing the second longest space walk in shuttle history. Footage includes Jernigan and Barry transferring and installing two cranes from the shuttle's payload bay to locations on the outside of the station. The astronauts enter the International Space Station delivering supplies and prepare the outpost to receive its first resident crew, scheduled to arrive in early 2000 on FD 5. The video also captures the crew involved in logistics transfer activities within the Discovery/ISS orbiting complex. FD 6 includes footage of Valery Tokarev and Canadian astronaut Julie Payette charging out the final six battery recharge controller units for two of Zarya's power-producing batteries and all crew members' involvement in logistics transfer activities from the SPACEHAB module to designated locations in the International Space Station. With the transfer work of FD 6 all but complete, the astronauts conduct some additional work, installing parts of a wireless strain gauge system that will help engineers track the effects of adding modules to the station throughout its assembly. Moving the few remaining items from Discovery to the ISS, then closing a series of hatches within the station's modules leading back to the shuttle are the primary activities contained in FD 7. Final coverage features Discovery's astronauts finishing their work inside the International Space Station, closing all of the hatches and readying the shuttle's small thrusters to be fired to raise the entire complex's orbit in preparation for the undocking and departure set for FD 8.

Source record↗