Pioneer Venus 1978 mission support
The Ground Data System configuration for support of the Pioneer Venus 1978 Mission is described. Current status of the DSN portion of the Ground Sata System is described.
Miller, R. B.↗
SEARCH · Search NASA
Results for “ground data system”
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.
Reducing Development and Operations Costs using NASA's "GMSEC" Systems Architecture
This viewgraph presentation reviews the role of Goddard Mission Services Evolution Center (GMSEC) in reducing development and operation costs in handling the massive data from NASA missions. The goals of GMSEC systems architecture development are to (1) Simplify integration and development, (2)Facilitate technology infusion over time, (3) Support evolving operational concepts, and (4) All for mix of heritage, COTS and new components. First 3 missions (i.e., Tropical Rainforest Measuring Mission (TRMM), Small Explorer (SMEX) missions - SWAS, TRACE, SAMPEX, and ST5 3-Satellite Constellation System) each selected a different telemetry and command system. These results show that GMSEC's message-bus component-based framework architecture is well proven and provides significant benefits over traditional flight and ground data system designs. The missions benefit through increased set of product options, enhanced automation, lower cost and new mission-enabling operations concept options .
Smith, Dan↗
Lessons learned supporting onboard solid-state recorders
With the advance of semiconductor technology, Solid-State Recorders (SSR) have matured and been accepted as primary onboard data storage devices. Their high reliability, simpler interface and control, and high flexibility have made the SSR's a superb choice in today's spacecraft design. While there are many benefits, the use of SSR's may also add significant complexity to ground data systems. For instance, real-time and playback data may be interleaved into the same data stream, making data sequencing and time ordering difficult. Stored data may be played back out of time order, increasing processing load significantly. Data may also be played back after being sorted by Virtual Channels in the SSR, potentially creating bursts in packet rates that exceed the real-time processing capabilities of the ground systems. This paper presents a summary of lessons learned through the efforts in supporting a number of NASA's missions that employ SSR's. It describes various problems encountered through the design process, and their potential impact on ground system performance, resources, and cost. Recommended approaches to minimizing the impact are demonstrated by examples. The discussion leads to the conclusion that the use of SSR's demands an even higher level of cooperation between spacecraft and ground system designers in order to build the most cost effective end-to-end system.
Shi, Jeff↗
Spitzer Pre Launch Mission Operations System - The Road to Launch
Spitzer Space Telescope was launched on 25 August 2003 into an Earth-trailing solar orbit to acquire infrared observations from space. Development of the Mission Operations System (MOS) portion prior to launch was very different from planetary missions from the stand point that the MOS teams and Ground Data System had to be ready to support all aspects of the mission at launch (i.e., no cruise period for finalizing the implementation). For Spitzer, all mission-critical events post launch happen in hours or days rather than months or years, as is traditional with deep space missions. At the end of 2000 the Project was dealt a major blow when the Mission Operations System (MOS) had an unsuccessful Critical Design Review (CDR). The project made major changes at the beginning of 2001 in an effort to get the MOS (and Project) back on track. The result for the Spitzer Space Telescope was a successful launch of the observatory followed by an extremely successful In Orbit Checkout (IOC) and operations phase. This paper describes how the project was able to recover the MOS to a successful Delta (CDR) by mid 2001, and what changes in philosophies, experiences, and lessons learned followed. It describes how projects must invest early or else invest heavily later in the development phase to achieve a successful operations phase.
observatory↗
System design of the Pioneer Venus spacecraft. Volume 8: Command/data handling subsystems studies
Study tasks for the command and data handling subsystems have been directed to: (1) determining ground data systems, (GDS) interfaces and deep space network (DSN) changes, if required, (2) defining subsystem requirements, (3) surveying existing hardware that could be used or modified to meet subsystem requirements, and (4) establishing a baseline design. Study of the existing GDS led to the conclusion that the Viking configuration GDS can be used with only minor changes required for the Pioneer Venus baseline. Those changes required are associated with providing a predetection recording capability used during probe entry and descent. Subsystem requirements were first formulated with sufficient latitude so that surveys of existing hardware could lead to low cost hardware which, in turn, could modify more narrowly defined subsystem requirements.
Vesely, D. D.↗
Enabling a Larger Deep Space Mission Suite: A Deep Space Network Queuing Antenna for Demand Access
The advent of deep space small spacecraft, as exemplified by the Mars Cubesat One (MarCO), Lunar Trailblazer, Janus, the Escape and Plasma Acceleration and Dynamics Explorers (EscaPADE), and the thirteen Artemis 1 missions, opens the possibility that a much larger number of deep space spacecraft may be launched over the next 10 years and beyond. While scientifically exciting, the prospect of a (much) larger mission suite raises significant challenges for the current approach to ground stations and mission operations. We have been investigating an integrated approach for ground stations and missions operations to enable new modes of operation while maintaining the capabilities of the current operational techniques. This integrated approach is built around three core capabilities: (1) A queuing antenna that enables monitoring the status of a much larger number of spacecraft, and allows spacecraft to transmit requests for telemetry with NASA’s Deep Space Network (DSN); (2) a flexible scheduling system that expands the current DSN scheduling services to enable allocating time on DSN antennas in near real-time; and (3) a cloud-based ground data system that can be spun up and down according to how tracks are assigned by the flexible scheduling system. We shall show that an 18 meter DSN queuing antenna equipped with cyrogenic receivers would enable use of the DSN Demand Access Service for small spacecraft throughout the inner Solar System, thus providing service to a large mission suite. We first discuss the architecture of the queuing antenna and its supporting systems, including, for instance, the service required to generate the schedule for the queueing antenna (which dictates how it slews to monitor multiple spacecraft in a day of operations). Next, we describe the signaling scheme used to encode a request, which is inherited from the already operational DSN Beacon Tone Service, and describe two alternative ways to detect the incoming tone at the ground station, one based on maximum likelihood estimation (MLE), and another one based on Fast-Fourier Transfer (FFT) processing. We then use these results to estimate the maximum range at which a request can be reliably detected as a function of the spacecraft and ground station communication capabilities. Finally, the last part of this part of this paper briefly describes the prototyping effort undertaken at Morehead State University (MSU) and JPL to demonstrate the viability of this new DSN demand access. In particular, we describe the suite of tests conducted using MSU’s 21 meter ground station to validate its use a queuing antenna.
Mattle, Emily↗
Automating a human factors evaluation of graphical user interfaces for NASA applications: An update on CHIMES
Capturing human factors knowledge about the design of graphical user interfaces (GUI's) and applying this knowledge on-line are the primary objectives of the Computer-Human Interaction Models (CHIMES) project. The current CHIMES prototype is designed to check a GUI's compliance with industry-standard guidelines, general human factors guidelines, and human factors recommendations on color usage. Following the evaluation, CHIMES presents human factors feedback and advice to the GUI designer. The paper describes the approach to modeling human factors guidelines, the system architecture, a new method developed to convert quantitative RGB primaries into qualitative color representations, and the potential for integrating CHIMES with user interface management systems (UIMS). Both the conceptual approach and its implementation are discussed. This paper updates the presentation on CHIMES at the first International Symposium on Ground Data Systems for Spacecraft Control.
Jiang, Jian-Ping↗
Astrobee Free Flyers: Integrated and Tested. Ready for Launch!
As of March 2019, four Astrobee free-flying robots have been integrated, tested and shipped to NASA’s Johnson Space Center, Texas, ready to be launched to space. Two of these Astrobee units (Honey and Bumble) will be launched to the International Space Station (ISS) on April 17, 2019, on the Cygnus NG-11 (Northrop Grumman) cargo resupply spacecraft from the Mid-Atlantic Regional Spaceport (MARS) launch facility, at NASA's Wallops Flight Facility, in Virginia, while the third unit (Queen) will be launched in mid-July 2019, with the cargo resupply mission Space-X 18, from Cape Canaveral, at NASA’s Kennedy Space Center. The primary purpose of the Astrobee system is to provide an autonomous and flexible platform for research on zero-g free-flying robotics, with the ability to accommodate guest researchers looking to utilize the unique capabilities of this platform in the microgravity of low earth orbit, and to advance the state of the art of guest science software and research payloads, which range from gecko-inspired adhesives for perching on smooth surfaces, to augmented reality interfaces to help astronauts and robots work together effectively, to RFID reader, performing inventory of RFID tagged items inside the ISS. Astrobee will also serve utility functions, such as free-flying cameras to record video and provide assistance during astronaut activities, and as mobile sensor platforms to conduct surveys of the ISS. In this paper we will give an overview of the status of the Astrobee system, which includes the docking station already launched and mounted in the JAXA JEM module of the ISS, the Astrobee robots, the Astrobee robotic arms, the ground data system (GDS) and the development of the several guest science payloads.
Carlino, Roberto↗
An approach to the design of operations systems
The MultiMission Control Team (MMCT) consists of mission controllers which provides Real-Time operations support for the Mars Observer project. The Real-Time Operations task is to insure the integrity of the ground data system, to insure that the configuration is correct to support the mission, and to monitor the spacecraft for the Spacecraft Team. Operations systems are typically developed by adapting operations systems from previous projects. Problems tend to be solved empirically when they are either anticipated or observed in testing. This development method has worked in the past when time was available for extensive Ops testing. In the present NASA budget environment, a more cost conscious design approach has become necessary. Cost is a concern because operations is an ongoing, continuous activity. Reducing costs entails reducing staff. Reducing staffing levels potentially increases the risk of mission failure. Therefore, keeping track of the risk level is necessary.
Chafin, Roy L.↗
An Oveview of TROPESS Data Products and Services at the NASA GES DISC
The TRopospheric Ozone and Precursors from Earth System Sounding (TROPESS) project generates Earth System Data Records (ESDRs) of ozone, and other atmospheric constituents (CH4,CO, H2O, HDO, NH3, PAN and temperature) by processing data from multiple satellites through a common retrieval algorithm and ground data system. Satellite Level-1B input data used in generating the TROPESS L2 data products include CrIS NOAA-20 (JPSS-1), CrIS SNPP, AIRS Aqua, OMI Aura, and TROPOMI S5P. The common retrieval framework is known as the MUlti-SpEctra, MUlti-SpEcies, Multi-SEnsors (MUSES) science data processing system (MUSES-SDPS). Several of the TROPESS data products are now available from the NASA Goddard Earth Sciences Data and Information Service Center (GES DISC) for users to download. In this presentation we provide an overview of the various TROPESS data products. These data products can be divided into the following Forward Stream types: Standard Products, Summary Products, and Full-Archival Products. Standard Products are for users that are doing full analysis with avenging kernel and covariance corresponding to retrieved vertical profiles. Summary products have a smaller file size and are more convenient for first-look and rapid analysis, include total and partial columns, as well as column averaging kernels. The Full-Archival Products will contain all information used in creating the data. TROPESS also creates Special Products, provided on an as-needed and as-available basis to support NASA field missions and individual-investigator requests over specific regions. Eventually, TROPESS will also produce and deliver a set of Reanalysis Stream products. Data at the GES DISC are being transitioned into the "Cloud". This will allow users with "Cloud” access to perform data analysis directly on the data without downloading the data to their system. Services, such as subsetting and data visualization, will also be provided for TROPESS data products at the GES DISC.
James Johnson↗
The Mars mapper science and mission planning tool
The Mars Mapper Program (MOm) is an interactive tool for science and mission design developed for the Mars Observer Mission (MO). MOm is a function of the Planning and Sequencing Element of the MO Ground Data System. The primary users of MOm are members of the science and mission planning teams. Using MOm, the user can display digital maps of Mars in various projections and resolutions ranging from 1 to 256 pixels per degree squared. The user can overlay the maps with ground tracks of the MO spacecraft (S/C) and footprints and swaths of the various instruments on-board the S/C. Orbital and instrument geometric parameters can be computed on demand and displayed on the digital map or plotted in XY-plots. The parameter data can also be saved into files for other uses. MOm is divided into 3 major processes: Generator, Mapper, Plotter. The Generator Process is the main control which spawns all other processes. The processes communicate via sockets. At any one time, only 1 copy of MOm may operate on the system. However, up to 5 copies of each of the major processes may be invoked from the Generator. MOm is developed on the Sun SPARCStation 2GX with menu driven graphical user interface (GUI). The map window and its overlays are mouse-sensitized to permit on-demand calculations of various parameters along an orbit. The program is currently under testing and will be delivered to the MO Mission System Configuration Management for distribution to the MO community in 3/93.
Lo, Martin W.↗
Mars Terrain Generation
A suite of programs for the generation of disparity maps from stereo image pairs via correlation, and conversion of those disparity maps to XYZ maps, has been updated. This suite implements an automated method of deriving terrain from stereo images for use in the ground data system for in-situ (lander and rover) cameras. This differs from onboard correlation by concentrating more on accuracy than speed, since near-real-time is not a requirement on the ground. The final result is an XYZ value for every point in the image that passes several quality checks. A priori geometric camera calibration information is required for this suite to operate. The suite is very flexible, enabling its use in many special situations, such as non-linearized images required for applications like the Phoenix arm camera, or long-baseline stereo, where the rover moves between left and right images.
Deen, Robert G.↗
Trans-Global Mission Architectures
Mission operations include the utilization of both space and ground resources to achieve mission objectives. Future architectures will make the spacecraft a node on a distributed system, thus expanding the scope of missions beyond the global scale. The history and evolution of planetary mission operations are outlined, together with the current global involvement in planetary missions. The modular nature and reuse of the supporting ground data systems, and the inclusion of automation and dedicated software in space missions, are discussed. A trans-global mission architecture is presented, and consists of an extension of a layered reusable mission operations architecture to create an open ground/space operations system. Concurrent mission engineering with such trans-global structures is discussed.
Anderson, Barbara V.↗
State-of-the-Art: Small Spacecraft Technology
When the first edition of NASA’s Small Spacecraft Technology State-of-the-art report was published in 2013, 247 CubeSats and 105 other non-CubeSat small spacecraft under 50 kilograms (kg) had been launched worldwide, representing less than 2% of launched mass into orbit over multiple years. In 2013 alone, around 60% of the total spacecraft launched had a mass under 600 kg, and of those under 600 kg, 83% were under 200 kg and 37% were nanosatellites (1). Of the total 1,849 spacecraft launched in 2021, 94% were small spacecraft with an overall mass under 600 kg, and of those under 600 kg, 40% were under 200 kg, and 11% were nanosatellites (1). Since 2013, the fight heritage for small spacecraft has increased by over 30% and has become the primary source to space access for commercial, government, private, and academic institutions. The total number of spacecraft launched in the past 10 years is 5,681 and 45% of those had a mass. As with all previous editions of this report, the 2022 edition captures and distills a wealth of new information available on small spacecraft systems from NASA and other publicly available sources. This report is limited to publicly available information and cannot reflect major advances in development that are not publicly disclosed. We encourage any opportunity to publish mission outcomes and technology development milestones (e.g., via conference papers, press releases, company website) so they can be reflected in this report. Overall, this report is a survey of small spacecraft technologies sourced from open literature; it does not endeavor to be an original source, and only considers literature in the public domain to identify and classify devices. Commonly used sources for data include manufacturer datasheets, press releases, conference papers, journal papers, public filings with government agencies, news articles, presentations, the compendium of databases accessed via NASA’s Small Spacecraft Systems Virtual Institute (S3VI) Information Search, and engagement with companies. Data not appropriate for public dissemination, such as proprietary, export controlled, or otherwise restricted data, are not considered. As a result, this report includes many dedicated hours of desk research performed by subject matter experts reviewing resources noted above. Content in this 2022 edition is based on data available by October 2022. This report should not be considered as a comprehensive overview of all the technologies but a great reference for the current state-of-the-art SmallSat technologies. The organizational approach for each chapter is relatively consistent with previous editions and includes an introduction of the technology, current development status of the technology’s procurable systems, and summary tables of technologies surveyed. The content in each chapter is uniquely organized to present a mini-stand-alone report on spacecraft subsystems. As in previous years, chapters include information from previous editions but are updated with new and maturating technologies and reference missions. Tables in each section provide a convenient summary of the technologies discussed, with explanations and references in the body text. The authors have attempted to isolate trends in the small spacecraft industry to point out which technologies have been adopted after successful demonstration missions. Lastly, the authors tried to use the terms “SmallSat,” “microsatellite,” “nanosatellite,” and “CubeSat” in a consistent manner, even as these terms are often used interchangeably in the space industry. Every subsystem chapter contains updated information to reflect the growth in the small spacecraft market. Significant changes are included in several chapters. The “Complete Spacecraft Platforms” chapter now includes information on the two main market options, hosted payload services and dedicated buses. The “Power” chapter provides information on the development of solid-state batteries with significantly higher energy than the current state-of-theart lithium-ion batteries. A large effort was made to update the “Communications” chapter to appropriately capture the recent technology maturation of optical communications for SmallSats. The “Ground Data Systems and Mission Operations” chapter was updated to reflect the recent establishment of the Near Space Network and influx of SmallSat Optical Ground Stations. The “Guidance, Navigation and Control” chapter was updated to include Lidar sensor technology. The “Deorbit Systems” chapter includes a discussion of recently proposed changes by the Federal Communications Commission (FCC) to limit a spacecraft’s lifetime to no longer than 5 years after end-of-mission. The “Identification and Tracking” Chapter includes updated information on the progress of SmallSat tracking. Finally, this report now encompasses technology funded by NASA’s Small Spacecraft Technology (SST) program’s SmallSat Technology Partnerships (STP) initiative which is described further in this Introduction. The reader can find the included SST technology in the “On the Horizon” section of the “Thermal Systems”, “Communications”, and “Guidance, Navigation, and Control” chapters. A central element of this report is to list state-of-the-art technologies by NASA standard Technology Readiness Level (TRL) as defined by the 2020 NASA Engineering Handbook, found in NASA NPR 7123.1C NASA Systems Engineering Processes and Requirements. The authors have endeavored to independently verify the TRL value of each technology by reviewing and citing published test results or publicly available data to the best of their ability. Where test results and data disagree with vendors’ own advertised TRL, the authors have attempted to engage the vendors to discuss the discrepancy. Readers are strongly encouraged to follow the references cited in the literature describing the full performance range and capabilities of each technology. Readers of this report should reach out to individual companies to further clarify information. It is important to note that this report takes a broad system-level view. To attain a high TRL, the subsystem must be in a flight-ready configuration with all supporting infrastructure—such as mounting points, power conversion, and control algorithms—in an integrated unit. An accurate TRL assessment requires a high degree of technical knowledge on a subject device, and an in-depth understanding of the mission (including interfaces and environment) on which the device was flown. There is variability in TRL values depending on design factors for a specific technology. For example, differences in TRL assessment based on the operating environment may result from the thermal environment, mechanical loads, mission duration, or radiation exposure. If a technology has flown on a mission without success, or without providing valid confirmation to the operator, such claimed “flight heritage” was discounted. The authors believe TRLs are most accurately determined when assessed within the context of a program’s unique requirements. While the overall capability of small spacecraft has matured since the 2021 edition of this report, technologies are still being developed to make deep space SmallSat missions more routine and more cost effective. Future editions of this report may include content dedicated to the rapidly growing fields of assembly, integration, and testing services, and mission modeling and simulation–all of which are now extensively represented at small spacecraft conferences. Many of these subsystems and services are still in their infancy, but as they evolve and reliable conventions and standards emerge, the next iteration of this report may also evolve to include additional chapters.
Bruce Yost↗
IT Data Mining Tool Uses in Aerospace
Data mining has a broad spectrum of uses throughout the realms of aerospace and information technology. Each of these areas has useful methods for processing, distributing, and storing its corresponding data. This paper focuses on ways to leverage the data mining tools and resources used in NASA's information technology area to meet the similar data mining needs of aviation and aerospace domains. This paper details the searching, alerting, reporting, and application functionalities of the Splunk system, used by NASA's Security Operations Center (SOC), and their potential shared solutions to address aircraft and spacecraft flight and ground systems data mining requirements. This paper also touches on capacity and security requirements when addressing sizeable amounts of data across a large data infrastructure.
Monroe, Gilena A.↗
Assessment of in-flight anomalies of long life outer plant mission
Thee unmanned planetary spacecraft to the outer planets have been controlled and operated successfully in space for an accumulated total of 66 years. The Voyager 1 and 2 spacecraft each have been in space for more than 26 years. The Galileo spacecraft was in space for 14 years, including eight years in orbit about Jupiter. During the flight operations for these missions, anomalies for the ground data system and the flight systems have been tracked using the anomaly reporting tool at the Jet Propulsion Laboratory. A total of 3300 incidents, surprises, and anomaly reports have been recorded in the database. This paper describes methods and results for classifying and identifying trends relative to ground system vs. flight system, software vs. hardware, and corrective actions. There are several lessons learned from these assessments that significantly benefit the design and planning for long life missions of the future. These include the necessity for having redundancy for successful operation of the spacecraft, awareness that anomaly reporting is dependent on mission activity not the age of the spacecraft, and the need for having a program to maintain and transfer operation knowledge and tools to replacement flight team members.
anomalies↗
Repurposing Drilling Control Diagnostics for Subsurface Edge Detection and Boundary Advisement During Planetary Drilling
Informed decision-making during lunar drilling and sampling missions will require data monitoring tools and specialized ground data systems. Accurate and updated situational awareness, with ongoing data monitoring, is critical for timely responses by to incoming science data. Traverse plans and scheduled activities may need to be flexibly changed in order to react to unexpected data or situations. Unlike (for example) Mars missions, the relative lightspeed closeness of the Moon allows for near-real-time ground processing of incoming mission and instrument data. An Apollo-class lunar regolith drill will in a sense “travel” a meter or two vertically at a given subsurface characterization site. As the drill penetrates into lunar regolith, it is likely to encounter a range of material densities, orientations, fracture toughness, and (perhaps) ice percentages. Lunar drill telemetry can provide science teams with a valuable first look into the subsurface structure, the regolith bulk properties, and constituents at each drilled site. Real-time AI-based recognition and reaction to downhole situations has been developed for automated deeper drilling on Mars and beyond. We can leverage the same knowledge bases and pattern-matching as areal-time interpreter of the subsurface, a situational awareness tool during drilling operations. We recently (Sept. 2019) demonstrated this AI drilling monitoring and analysis capability, in control of in-situ drilling and sampling operations, mounted on a KREX-2 rover in Chile’s Atacama Desert. Terrestrial automated drilling log analyses in oil exploration have used similar machine learning techniques in classifying and identifying features in drilling logs –but these typically are designed assuming a drilling fluid influencing downhole measurements and data (permeability, resistivity). Drilling models and existing AI software designed to detect and respond to drilling faults and hard materials can be repurposed, for near-real-time (ground-based) interpretation of drilling telemetry –a potentially valuable advisory tool for strata boundaries and changes in drilling parameters. On the Moon, this approach could be used to study the structure and to some extent the composition of lunar regolith vs. borehole depth, based on recognizable variations in fracture hardness, drilling energy and penetration rates while actively drilling. Since the early 2000s, a series of increasingly-capable real-time drilling telemetry interpretation and characterization software tools have been developed. These subsurface models and software tools have monitored the real-time drilling data received, and automatically identified changes in drill behavior (e.g., encountering a harder target layer, bit inclusions, drill choking due to infall downhole, and others) correlating these with subsurface structures and features. We discuss the mappings between drill borehole parameters, faults or events detected, and modeled changes in rock layer boundaries, in examples drawn from field testing at analog sites in an Arctic impact crater, Rio Tinto, and Chile’s Atacama Desert. These demonstrate how subsurface structural boundaries led to fault detections and responses by the software.
drilling advisor↗
Support Routines for In Situ Image Processing
This software consists of a set of application programs that support ground-based image processing for in situ missions. These programs represent a collection of utility routines that perform miscellaneous functions in the context of the ground data system. Each one fulfills some specific need as determined via operational experience. The most unique aspect to these programs is that they are integrated into the large, in situ image processing system via the PIG (Planetary Image Geometry) library. They work directly with space in situ data, understanding the appropriate image meta-data fields and updating them properly. The programs themselves are completely multimission; all mission dependencies are handled by PIG. This suite of programs consists of: (1)marscahv: Generates a linearized, epi-polar aligned image given a stereo pair of images. These images are optimized for 1-D stereo correlations, (2) marscheckcm: Compares the camera model in an image label with one derived via kinematics modeling on the ground, (3) marschkovl: Checks the overlaps between a list of images in order to determine which might be stereo pairs. This is useful for non-traditional stereo images like long-baseline or those from an articulating arm camera, (4) marscoordtrans: Translates mosaic coordinates from one form into another, (5) marsdispcompare: Checks a Left Right stereo disparity image against a Right Left disparity image to ensure they are consistent with each other, (6) marsdispwarp: Takes one image of a stereo pair and warps it through a disparity map to create a synthetic opposite- eye image. For example, a right eye image could be transformed to look like it was taken from the left eye via this program, (7) marsfidfinder: Finds fiducial markers in an image by projecting their approximate location and then using correlation to locate the markers to subpixel accuracy. These fiducial markets are small targets attached to the spacecraft surface. This helps verify, or improve, the pointing of in situ cameras, (8) marsinvrange: Inverse of marsrange . given a range file, re-computes an XYZ file that closely matches the original. . marsproj: Projects an XYZ coordinate through the camera model, and reports the line/sample coordinates of the point in the image, (9) marsprojfid: Given the output of marsfidfinder, projects the XYZ locations and compares them to the found locations, creating a report showing the fiducial errors in each image. marsrad: Radiometrically corrects an image, (10) marsrelabel: Updates coordinate system or camera model labels in an image, (11) marstiexyz: Given a stereo pair, allows the user to interactively pick a point in each image and reports the XYZ value corresponding to that pair of locations. marsunmosaic: Extracts a single frame from a mosaic, which will be created such that it could have been an input to the original mosaic. Useful for creating simulated input frames using different camera models than the original mosaic used, and (12) merinverter: Uses an inverse lookup table to convert 8-bit telemetered data to its 12-bit original form. Can be used in other missions despite the name.
Deen, Robert G.↗