Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “rovers modeling simulation”

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 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Trajectory Simulation Using Multi Model Monte Carlo with Python (MXMCPy)

EDL (Entry, Descent and Landing) is the process from a vehicle approaching a surface to landing on it, such as a Mars rover approaching the planet before landing. POST2 (Program to Optimize Simulated Trajectories 2) is Langley’s primary EDL simulation tool and is used NASA-wide for simulations. POST2 can generate highly accurate results by running a precise, but time consuming, Monte Carlo (MC) simulation hundreds or thousands of times. Though POST2 can produce highly accurate results, it can take unrealistic time spans to generate these results, which has created a need to speed up the simulations. The new NASA software MXMCPy offers various ways to speed up the simulations while getting just as precise results. Instead of running high-precision POST2 simulations many times for traditional MC, MXMCPy can run fewer high-precision POST2 simulations and many less precise POST2 simulations and merge the results. MXMCPy contains 30+ different methods which will each suggest different allocations between model precision levels, which result in results of varying precision based on the POST2 simulation. I created Python and Bash code to automate the 5 steps of MXMCPy’s application to POST2. I also tested the precision of traditional Monte Carlo simulations to MXMCPy aided simulations and found that MXMCPy can achieve substantially more precise solutions at the same computer runtime. I learned Test Driven Development (TDD), a software programming workflow which involves writing computer-automated tests before writing the code which is being tested. These tests are ran every time the code is changed and they can find glitches in the code much quicker than a human can. This programming workflow saved me a lot of time because the automated tests could tell me exactly where the code had stopped working. I plan on using this software development method for future academic and professional software projects. I have greatly enjoyed my work at NASA, so I have been applying to NASA internships and Pathways positions. In addition, I plan on applying what I have learned about Test Driven Development to my computer science courses next semester

James Warner↗
NASA NTRS2007

Interface for Physics Simulation Engines

DSS-Prototyper is an open-source, realtime 3D virtual environment software that supports design simulation for the new Vision for Space Exploration (VSE). This is a simulation of NASA's proposed Robotic Lunar Exploration Program, second mission (RLEP2). It simulates the Lunar Surface Access Module (LSAM), which is designed to carry up to four astronauts to the lunar surface for durations of a week or longer. This simulation shows the virtual vehicle making approaches and landings on a variety of lunar terrains. The physics of the descent engine thrust vector, production of dust, and the dynamics of the suspension are all modeled in this set of simulations. The RLEP2 simulations are drivable (by keyboard or joystick) virtual rovers with controls for speed and motor torque, and can be articulated into higher or lower centers of gravity (depending on driving hazards) to enable drill placement. Gravity also can be set to lunar, terrestrial, or zero-g. This software has been used to support NASA's Marshall Space Flight Center in simulations of proposed vehicles for robotically exploring the lunar surface for water ice, and could be used to model all other aspects of the VSE from the Ares launch vehicles and Crew Exploration Vehicle (CEV) to the International Space Station (ISS). This simulator may be installed and operated on any Windows PC with an installed 3D graphics card.

Damer, Bruce↗
NASA NTRS2022

How to Build a Rover: An Overview of the Mars 2020 Mission’s Vehicle System Testbed

While NASA’s Mars rover Perseverance continues to make groundbreaking achievements on the Red Planet, its twin is hard at work here on Earth. The Operational Perseverance Twin for the Integration of Mechanisms and Instruments Sent to Mars, or OPTIMISM, is the Mars 2020 Vehicle System Testbed (VSTB) rover operated by NASA Jet Propulsion Laboratory (JPL) in Pasadena, California. OPTIMISM’s home is the JPL Mars Yard; an outdoor field with red soil that simulates the terrain encountered by Perseverance. The VSTB is a full-scale engineering model of the flight rover, serving a number of functions to ensure mission operations can continue smoothly and on schedule. The VSTB possesses instrumentation, computers, mechanisms, cameras, and a Mobility subsystem that are nearly identical to its extraterrestrial twin. Its high fidelity allows the rover to be a highly effective tool to fully test system functionality and performance prior to commanding the flight rover. The early stages of building OPTIMISM began a few months prior to Perseverance departing JPL for Cape Canaveral, FL in early 2020. Electrical integration of the flight system avionics, and compatibility checkouts of the electrical ground support equipment ensured that the foundation of the electrical system was operational and in place. Next, the internal harnessing was installed and compatibility checks of the rover instrumentation and mechanisms were performed to confirm the system was prepared for full buildup. Finally, mechanical assembly of the rover chassis with its external components completed the integration of the system before it was moved to the Mars Yard for its initial phase of testing to perform verification & validation (V&V) of the Mobility subsystem requirements. By the time Perseverance landed at Jezero Crater in February 2021, the first phase of VSTB operations was underway. Surface guidance, navigation, and control (SGNC) testing for the Mobility subsystem ensured functionality and performance requirements were met for various capabilities such as visual odometry (VO), mapping, and automatic navigation (AutoNav). Subsequent integration of the robotic arm (RA) onto the VSTB enabled the V&V campaign for surface sampling operations (SSO) to commence. As the mission’s engineering operations (EO) have gotten underway, the VSTB has been utilized for an array of purposes including troubleshooting software anomalies, and performing dry-runs for first time activities (FTAs) prior to sending the commands to Perseverance. OPTIMISM will continue to serve mission critical functions as long as Perseverance is roving the Red Planet.

Rojas, Jose Trujillo↗
NASA NTRS1975

A manipulator arm for zero-g simulations

A 12-ft counterbalanced Slave Manipulator Arm (SMA) was designed and fabricated to be used for resolving the questions of operational applications, capabilities, and limitations for such remote manned systems as the Payload Deployment and Retrieval Mechanism (PDRM) for the shuttle, the Free-Flying Teleoperator System, the Advanced Space Tug, and Planetary Rovers. As a developmental tool for the shuttle manipulator system (or PDRM), the SMA represents an approximate one-quarter scale working model for simulating and demonstrating payload handling, docking assistance, and satellite servicing. For the Free-Flying Teleoperator System and the Advanced Tug, the SMA provides a near full-scale developmental tool for satellite servicing, docking, and deployment/retrieval procedures, techniques, and support equipment requirements. For the Planetary Rovers, it provides an oversize developmental tool for sample handling and soil mechanics investigations. The design of the SMA was based on concepts developed for a 40-ft NASA technology arm to be used for zero-g shuttle manipulator simulations.

Brodie, S. B.↗
NASA NTRS2009

Rover Attitude and Pointing System Simulation Testbed

The MER (Mars Exploration Rover) Attitude and Pointing System Simulation Testbed Environment (RAPSSTER) provides a simulation platform used for the development and test of GNC (guidance, navigation, and control) flight algorithm designs for the Mars rovers, which was specifically tailored to the MERs, but has since been used in the development of rover algorithms for the Mars Science Laboratory (MSL) as well. The software provides an integrated simulation and software testbed environment for the development of Mars rover attitude and pointing flight software. It provides an environment that is able to run the MER GNC flight software directly (as opposed to running an algorithmic model of the MER GNC flight code). This improves simulation fidelity and confidence in the results. Further more, the simulation environment allows the user to single step through its execution, pausing, and restarting at will. The system also provides for the introduction of simulated faults specific to Mars rover environments that cannot be replicated in other testbed platforms, to stress test the GNC flight algorithms under examination. The software provides facilities to do these stress tests in ways that cannot be done in the real-time flight system testbeds, such as time-jumping (both forwards and backwards), and introduction of simulated actuator faults that would be difficult, expensive, and/or destructive to implement in the real-time testbeds. Actual flight-quality codes can be incorporated back into the development-test suite of GNC developers, closing the loop between the GNC developers and the flight software developers. The software provides fully automated scripting, allowing multiple tests to be run with varying parameters, without human supervision.

Vanelli, Charles A.↗
NASA NTRSDate not supplied

Utilizing 3D-DIC on Mars 2020 Rover Wheel Assembly: Test-Analysis Correlation

Following the successful implementation of full-field photogrammetry, more specifically three-dimensional Digital Image Correlation (3D-DIC), on the Mars 2020 Heat Shield Structural Failure Review assessment, 3D-DIC was selected as one of the primary measurement techniques for the Mars 2020 Rover wheel assembly qualification test at the NASA Jet Propulsion Laboratory (JPL). To validate the Rover wheel landing loads simulations, it was extremely important to have high confidence in the wheel models. Due to the large deformations and strains that the wheel would be subject to during landing, traditional instrumentation such as linear variable displacement transducers (LVDTs), electrical-resistance strain gages and string potentiometers, would not be sufficient on their own to provide all the necessary validation data. Therefore, the NASA Engineering and Safety Center (NESC) provided the 3D-DIC expertise and support to measure the high deformation and strain in the wheel flexures and qualify the overall structural response of the Mars 2020 rover wheel assembly. There were two key objectives for the photogrammetry technique: (1) monitor the wheel response in real-time, guarding against anomalous behavior and failure, and (2) provide test data for test-analysis correlation to validate and/or improve the high-fidelity computational model. The contents of this paper will focus on the challenges of applying 3D-DIC to the Mars 2020 Rover wheel assembly and how these challenges were overcome. Examples of test-analysis correlation during the stiffness characterization and structural qualification will be presented and discussed in detail. Experimental results were compared with the analysis and showed excellent agreement between the predicted behavior and helped validate the high-fidelity models.

Mars 2020 Rover Wheel↗
NASA NTRS2004

Constructing an Educational Mars Simulation

Working in the Educational Programs Office, my task this summer is to model a 3D habitat that will be part of a future Mars base. With the President's charge to further explore mars by way of robotic-led and human-led missions, there has been a surge in the activity regarding the "red planet". Since all present designs are merely conjecture, I have some creative freedom in deciding what the habitat will look like. To get ideas for what a Mars habitat might be like, I looked at several references including websites and NASA documents. One of these was a NASA Technical Memorandum about Space Transportation Systems that I looked at to get insight on spaceship design. Information about the planet's environment, such as the gravity and the weather, is useful as well when designing the structure. The main software that I am using is Lightwave 3D and Modeler 7.5 that comes along with it. Lightwave is very complex in that it lets you model, surface, and animate so there was a lot to learn. To learn the software I watched a series of instructional videos, looked at online tutorials, and referenced several books. Modeling is like shaping clay with a computer. Every item modeled is made of smaller shapes called polygons. For example, each side of a box would be a different polygon. Modelers must be careful to design with users' systems in mind. Having a model made with too many polygons can slow down a walk-through, but it usually improves the small details on a model. Getting speed and quality proved tricky. An important thing for me to remember when modeling the habitat was to save space. Also, I must consider that technology in the future will be much different than now, so I must be especially creative. My project will be used in an educational walkthough simulation in which users can interact with the environment. I worked closely with intern Stephen Henke who built a Mars Rover, terrain and programmed code for the simulation. This summer's project will help me with future aspirations in computer graphics. Modeling is a valuable skill that I appreciate having the chance to learn and practice.

Henke, Stephen A.↗
NASA NTRS2020

Enabling Dynamic Vehicle Analyses With Improved Atmospheric Attenuation Models in Glenn Research Center Communication Analysis Suite

To aid in meeting the NASA objective of returning humans to the Moon, the Glenn Research Center’s Communication Analysis Suite was augmented with two distinct capabilities. The first capability added was the vehicle propagator. This allows the addition of dynamic aircraft and ground vehicles around any celestial body within the solar system during an analysis. This functionality interpolates the position and velocity of the vehicle relative to a celestial body at the time steps analyzed using the type of path and either a series of waypoints or a direction and duration of travel. The implications of this new capability include lunar rovers and/or drones, such as Dragonfly, where the vehicle propagator will analyze the communications architecture. The newly created vehicle propagator is now in use in communications studies for the 2024 lunar missions, simulating the movement of lunar rovers across the Moon’s southern pole. The second capability added was the augmentation of the atmospheric attenuation model. The previous model did not have a uniform low-elevation attenuation model due to the trigonometric approximation for path length and the exponential nature of low-elevation scintillation. User-defined weather parameters were also added to the updated atmospheric attenuation model. The previous model solely used tabular data based upon the season and location of the transmitting antenna. Multiple simulations of the same configuration now return different results based on the differing weather parameters. Cognitive communications analysis efforts can use this second capability to generate neural network training data based on differing weather conditions at utilized ground stations, a critical step in allowing neural networks to learn how weather parameters impact communications performance.

vehicle propagation↗
NASA NTRSDate not supplied

Using Virtual Reality for Science Missions At The Lunar South Pole

The Lunar VR toolkit, built on Mixed Reality Exploration Toolkit (MRET), combines LOLA 5m topographic data, CAD models (e.g., lander, rover), procedural textures, and geologic features (e.g., rocks, craters) for sub-5m simulation of the lunar surface. Future capabilities include the incorporation of real-time mission telemetry to provide a full mission lifecycle tool, test instrument design and operation concepts, pre-operations planning and walk-throughs of traverses, and situational awareness support during actual mission operations. We will discuss the critical features we think are needed for lunar south pole mission planning and the development of our Lunar VR toolkit.

Thomas G Grubb↗
NASA NTRS2011

JPL Thermal Design Modeling Philosophy and NASA-STD-7009 Standard for Models and Simulations - A Case Study

The Standard JPL thermal engineering practice prescribes worst-case methodologies for design. In this process, environmental and key uncertain thermal parameters (e.g., thermal blanket performance, interface conductance, optical properties) are stacked in a worst case fashion to yield the most hot- or cold-biased temperature. Thus, these simulations would represent the upper and lower bounds. This, effectively, represents JPL thermal design margin philosophy. Uncertainty in the margins and the absolute temperatures is usually estimated by sensitivity analyses and/or by comparing the worst-case results with "expected" results. Applicability of the analytical model for specific design purposes along with any temperature requirement violations are documented in peer and project design review material. In 2008, NASA released NASA-STD-7009, Standard for Models and Simulations. The scope of this standard covers the development and maintenance of models, the operation of simulations, the analysis of the results, training, recommended practices, the assessment of the Modeling and Simulation (M&S) credibility, and the reporting of the M&S results. The Mars Exploration Rover (MER) project thermal control system M&S activity was chosen as a case study determining whether JPL practice is in line with the standard and to identify areas of non-compliance. This paper summarizes the results and makes recommendations regarding the application of this standard to JPL thermal M&S practices.

thermal blanket performance↗
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↗
NASA NTRS2015

Intercomparison of Martian Lower Atmosphere Simulated Using Different Planetary Boundary Layer Parameterization Schemes

We use the mesoscale modeling capability of Mars Weather Research and Forecasting (MarsWRF) model to study the sensitivity of the simulated Martian lower atmosphere to differences in the parameterization of the planetary boundary layer (PBL). Characterization of the Martian atmosphere and realistic representation of processes such as mixing of tracers like dust depend on how well the model reproduces the evolution of the PBL structure. MarsWRF is based on the NCAR WRF model and it retains some of the PBL schemes available in the earth version. Published studies have examined the performance of different PBL schemes in NCAR WRF with the help of observations. Currently such assessments are not feasible for Martian atmospheric models due to lack of observations. It is of interest though to study the sensitivity of the model to PBL parameterization. Typically, for standard Martian atmospheric simulations, we have used the Medium Range Forecast (MRF) PBL scheme, which considers a correction term to the vertical gradients to incorporate nonlocal effects. For this study, we have also used two other parameterizations, a non-local closure scheme called Yonsei University (YSU) PBL scheme and a turbulent kinetic energy closure scheme called Mellor- Yamada-Janjic (MYJ) PBL scheme. We will present intercomparisons of the near surface temperature profiles, boundary layer heights, and wind obtained from the different simulations. We plan to use available temperature observations from Mini TES instrument onboard the rovers Spirit and Opportunity in evaluating the model results.

Natarajan, Murali↗
NASA NTRS2021

An Innovative Approach to Modeling VIPER Rover Software Life Cycle Cost

NASA’s “Volatiles Investigating Polar Exploration Rover” (VIPER) will be the first robotic mission to prospect for water ice near the south pole of the Moon in late 2023 on a 100-Earth-day mission. The information that the VIPER rover provides will help improve understanding of the composition, distribution, and accessibility of Lunar polar volatiles and will help determine how the Moon’s resources can support future human space exploration. VIPER, however, represents a radical departure from the way that NASA has traditionally developed planetary robotic missions. A key consequence of these differences is that estimating the cost of VIPER’s rover software is challenging and complex.For example, VIPER is being developed using management procedures typically applied to NASA research and technology projects, rather than space flight programs. In addition, key portions of the rover’s software are being designed as ground software to run on mission control computers (rather than on-board the rover as flight software as with prior planetary missions) taking advantage of continuous, interactive data communications between the Moon and Earth and higher performance computing available on the ground. Moreover, the rover’s software is being engineered using Agile software development practices and incorporates a significant amount of open-source, rather than following traditional (spiral, waterfall, etc.) development methods and in-house code. In this paper, we present an innovative process to estimate the life cycle cost of VIPER’s rover software. We first describe how we modeled the architecture and code counts for three software elements: Rover Flight Software (RFSW), Rover Ground Software (RGSW), and Rover Simulation Software (RSIM). We then discuss key challenges and unique aspects of our approach, such as the lack of Lunar rover analogies, the need to integrate and test large open source software, and the strategies developed to account for use of non-space flight management practices and the impact of the COVID-19 pandemic. We conclude with a summary of our results, including cumulative distribution, nearest neighbors and cluster analysis, as well as heuristics used to confirm the reasonableness of the cost estimate.

Utz, Hans↗
NASA NTRS2011

Designing a Distributed Space Systems Simulation in Accordance with the Simulation Interoperability Standards Organization (SISO)

Simulations are essential for engineering design. These virtual realities provide characteristic data to scientists and engineers in order to understand the details and complications of the desired mission. A standard development simulation package known as Trick is used in developing a source code to model a component (federate in HLA terms). The runtime executive is integrated into an HLA based distributed simulation. TrickHLA is used to extend a Trick simulation for a federation execution, develop a source code for communication between federates, as well as foster data input and output. The project incorporates international cooperation along with team collaboration. Interactions among federates occur throughout the simulation, thereby relying on simulation interoperability. Communication through the semester went on between participants to figure out how to create this data exchange. The NASA intern team is designing a Lunar Rover federate and a Lunar Shuttle federate. The Lunar Rover federate supports transportation across the lunar surface and is essential for fostering interactions with other federates on the lunar surface (Lunar Shuttle, Lunar Base Supply Depot and Mobile ISRU Plant) as well as transporting materials to the desired locations. The Lunar Shuttle federate transports materials to and from lunar orbit. Materials that it takes to the supply depot include fuel and cargo necessary to continue moon-base operations. This project analyzes modeling and simulation technologies as well as simulation interoperability. Each team from participating universities will work on and engineer their own federate(s) to participate in the SISO Spring 2011 Workshop SIW Smackdown in Boston, Massachusetts. This paper will focus on the Lunar Rover federate.

Cowen, Benjamin↗
NASA NTRS2005

NASA Tech Briefs, March 2005

Topics covered include: Scheme for Entering Binary Data Into a Quantum Computer; Encryption for Remote Control via Internet or Intranet; Coupled Receiver/Decoders for Low-Rate Turbo Codes; Processing GPS Occultation Data To Characterize Atmosphere; Displacing Unpredictable Nulls in Antenna Radiation Patterns; Integrated Pointing and Signal Detector for Optical Receiver; Adaptive Thresholding and Parameter Estimation for PPM; Data-Driven Software Framework for Web-Based ISS Telescience; Software for Secondary-School Learning About Robotics; Fuzzy Logic Engine; Telephone-Directory Program; Simulating a Direction-Finder Search for an ELT; Formulating Precursors for Coating Metals and Ceramics; Making Macroscopic Assemblies of Aligned Carbon Nanotubes; Ball Bearings Equipped for In Situ Lubrication on Demand; Synthetic Bursae for Robots; Robot Forearm and Dexterous Hand; Making a Metal-Lined Composite-Overwrapped Pressure Vessel; Ex Vivo Growth of Bioengineered Ligaments and Other Tissues; Stroboscopic Goggles for Reduction of Motion Sickness; Articulating Support for Horizontal Resistive Exercise; Modified Penning-Malmberg Trap for Storing Antiprotons; Tumbleweed Rovers; Two-Photon Fluorescence Microscope for Microgravity Research; Biased Randomized Algorithm for Fast Model-Based Diagnosis; Fast Algorithms for Model-Based Diagnosis; Simulations of Evaporating Multicomponent Fuel Drops; Formation Flying of Tethered and Nontethered Spacecraft; and Two Methods for Efficient Solution of the Hitting- Set Problem.

Source record↗
NASA NTRS2022

Simulating Mars: Enabling Testing of the Perseverance Rover Sampling and Caching Subsystem on Earth

The development of the Sampling and Caching Subsystem (SCS) on the JPL Perseverance Rover lies at the intersection of testing, robotics, and geology. The SCS team established three primary system test campaigns and venues to aid in the development of SCS through verification and validation testing – Qualification Model Dirty Testing (QMDT) to provide a venue for testing in a Martian environment, Vehicle System Testbed (VSTB) for testing while integrated with the mobility subsystem on Martian-like terrain, and the Flight Software Testbed (FSWTB) for conducting tests using the flight motor controllers and software system on a hexapod which had the ability to simulate rover tilt. Each venue contributed a vital piece to the SCS building blocks. However, the QMDT venue operating within a 10-ft diameter Thermal Vacuum chamber to simulate Martian environment provided a sui generis opportunity to fine tune the entire sampling and caching process while building the team’s knowledge base about rock drillability, system life, and target selection. On Earth, because Martian rocks are not readily available, the development team must utilize geoanalogs to the rocks and regolith on Mars. Geologists on the team helped establish a set of standard rock types to use for Mars missions, like Basalt, Sandstone, Mudstone, Gypsum, and other related geoanalogs. These geoanalogs are characterized with a standard suite of tests for density, compressibility, and other characteristics to categorize potential drillability. This concept of drillability is what links the geoanalogs on Earth to the samples we collect on Mars. With the simulant characteristics defined, these geoanalog rocks are ready to be drilled into as we do on the Martian surface. A key aspect of interacting with the surface on Mars is rock target identification and selection. The Perseverance robotic system uses the on-board cameras, instrumentation, and software to collect enough information to identify potential scientific targets. With the targets identified, SCS can place the Corer and abrade the surface or collect a sample. For a ground test activity like QMDT, the test team did not have all of the camera and instrumentation systems that the rover does, so the team developed ground test equivalents to process a rock, build a target map, and define the target. The team constructed a Rock Scanning Station to build a 3D point cloud of the rock. This point cloud was then processed and evaluated with predefined and programmed criteria in a Target Downselect Tool. A primary output of the Target Downselect Tool is a defined target that can be uploaded directly to the robotic software system to simulate and build the robotic sequences used in tests. With these insights and programmatic definition of targets, the QMDT test team was able to make the same decisions that the Perseverance surface operations team does. In addition, valuable lessons learned from developing the target selection ground tools and using them were implemented into the tools used for surface operations.

Kim, Junggon↗
NASA NTRS2002

Brahms Mobile Agents: Architecture and Field Tests

We have developed a model-based, distributed architecture that integrates diverse components in a system designed for lunar and planetary surface operations: an astronaut's space suit, cameras, rover/All-Terrain Vehicle (ATV), robotic assistant, other personnel in a local habitat, and a remote mission support team (with time delay). Software processes, called agents, implemented in the Brahms language, run on multiple, mobile platforms. These mobile agents interpret and transform available data to help people and robotic systems coordinate their actions to make operations more safe and efficient. The Brahms-based mobile agent architecture (MAA) uses a novel combination of agent types so the software agents may understand and facilitate communications between people and between system components. A state-of-the-art spoken dialogue interface is integrated with Brahms models, supporting a speech-driven field observation record and rover command system (e.g., return here later and bring this back to the habitat ). This combination of agents, rover, and model-based spoken dialogue interface constitutes a personal assistant. An important aspect of the methodology involves first simulating the entire system in Brahms, then configuring the agents into a run-time system.

Clancey, William J.↗