Surface Operations Analyses for Lunar Missions

Hari D. Nayar�, Bob Balaram�, Jonathan M. Cameron�, Matthew DiCicco�,

Thomas M. Howard�, Abhinandan Jain�, Yoshiaki Kuwata�, Christopher Lim�,

Rudranarayan Mukherjee�, Steven Myint�, Alex Palkovicy,

Marc I. Pomerantz�, Stephen Wall�

Jet Propulsion Laboratory, California Institute of Technology,

4800 Oak Grove Drive, Pasadena, CA 91109.

The Jet Propulsion Laboratory is developing the Lunar Surface Operations Simula-tor software package to support analyses for future NASA lunar missions. The packageis built on and extended from previous simulation packages developed at JPL. It simu-lates mechanical motion, soil interaction, environmental, and physical processes. Physicalprocess dynamics include environmental control and life support, thermal, radiation andpower transients. An integrated architecture allows use of common models and enablesinteractions between components operating in di�erent domains to be easily modeled. Wedescribe recent developments and analyses performed to support lunar surface missionsand analog �eld trials.

I. Introduction

The Lunar Surface Operations Simulator (LSOS)12 is a dynamics simulation software package that modelslunar surface systems and the lunar environment. Simulations of lunar mission scenarios are performed

with LSOS to determine performance of surface assets and to analyze feasibility and optimize mission plans.Physics models of vehicles, habitats, and the lunar terrain are implemented in LSOS. LSOS also accuratelymodels the locations of the sun and other planetary bodies with respect to the surface assets on the terrain.In addition, process models and the corresponding dynamic behavior of power, environmental control andlife support, thermal and other systems are incorporated during simulations.

The LSOS software package has been extended from a family of dynamics simulation packages345678

developed at JPL for modeling, simulating and visualizing systems for planetary exploration missions. Thesepackages have been used for simulating entry, descent and landing on Mars, rovers exploring the surface ofMars, the cruise, orbit-insertion, orbit phases for missions to Jupiter and Saturn and many other space andresearch projects.

Dynamics simulations are an essential component of the extensive engineering analyses performed in theformulation and planning stages of space missions. Software simulations provide the following capabilitiesthat are expensive to duplicate with alternative approaches:

a. Replicating environmental conditions found in space or other extra-terrestrial bodies (for example,di�erent or complex gravitational �elds),

b. Investigating the feasibility of new concepts and evaluating alternatives,

c. Performing studies that cover a large range of time and space scales,

d. Performing Monte-Carlo and parametric analysis that modify variables in multiple simulationruns,

�Jet Propulsion Laboratory, California Institute of Technology, 4800 Oak Grove Drive, Pasadena, CA 91109.yDepartment of Computing Sciences, Villanova University, PA 19085.

1 of 15

American Institute of Aeronautics and Astronautics

AIAA SPACE 2010 Conference & Exposition 30 August - 2 September 2010, Anaheim, California

AIAA 2010-8831

Copyright © 2010 by the American Institute of Aeronautics and Astronautics, Inc. The U.S. Government has a royalty-free license to exercise all rights under the copyright claimed herein for Governmental purposes. All other rights are reserved by the copyright owner.

e. Sharing and re-playing simulation results with wide and physically distributed analyses andplanning teams,

f. Investigating alternative operational scenarios,

g. Validating and verifying against alternative analytical studies and physical analog trials, and

h. Visualizing planned operations.

LSOS has been developed for many of the reasons listed above. In the following section, we describeelements of LSOS. In Sub-section II.A we describe habitat vehicle models developed to support LSOS simu-lations. Another important component of LSOS, terrain models, are described in Sub-section II.B. The 3Dvisualization system is described in Sub-section II.C, path planning in Sub-section II.D and scenario scriptingin Sub-section II.E. LSOS has been used to perform analyses in support of mission planning and systemdesign. Two examples are reported in Section III. They are a study of power usage in a traverse from Shack-leton Crater to Malapert Mountain and back (Sub-section III.A) and solar panel performance at ShackletonCrater and Malapert Mountain (Sub-section III.B). We conclude with a summary of the development ofLSOS and future plans in Section IV.

II. Lunar Simulator Components

A. Vehicle and Habitat Models

LSOS simulations incorporate a number of vehicles and habitats. The Lunar Electric Rover (LER), shownon Figure 1a, is a concept vehicle proposed for rapid scouting missions on Lunar missions. Modeling thehigh-�delity dynamics of the LER in LSOS was essential to ensure good physical models for exploring thelocomotion and energy design space. An articulating multi-rigid-body model of the LER was developedand implemented in LSOS. An extension to the dynamics formulation was developed to handle the four-barspring-loaded suspension mechanism.

The ATHLETE, shown on Figure 1b, is a six-legged vehicle with wheels on each leg. The ATHLETE’ssuspension system is its legs. During simulations that incorporate the ATHLETE, its legs are activelycontrolled to comply to the ground to maintain the vehicle’s chassis level when driving over undulatingterrain. An algorithm was developed to

� keep all wheels in contact with the ground,

� keep the chassis level with adequate clearance from ground,

� keep the chassis heading in the drive direction

� keep wheel mounts vertical, and

� keep wheels steered correctly.

Other lunar surface systems modeled in LSOS are lunar habitat modules (see Figure 2a), the Altair lunarlander (see Figure 2b), and the Portable Utility Palette (PUP) shown on Figure 2c.The PUP has a solarpanel and battery for energy generation and storage. LSOS has also modeled placing the PUP on the backof an LER rover as shown on Figure 1a. This option provides additional power to the LER and the PUP canbe dropped o� and left on its own to charge batteries for later use. LSOS can simultaneously incorporatemodels of any number of these vehicle and habitat elements in dynamic simulations.

The LSOS vehicle and habitat systems provide production and consumption modeling of numerous inter-nal properties like O2, and water usage, CO2 production, and energy production (through solar panels) andconsumption (through driving and on-board devices). For environmental control and life support (ECLS)parameters like O2, water and CO2, simple constant linear charge and discharge rates are used and provideenough �delity to aid in the planning of long duration lunar excursions.

Energy modeling is more sophisticated and focuses on two core components: a consumption model basedon vehicle velocities and on-board system energy usage rates and a production model based on solar panels.Battery models are used represent the total stored charge level on the vehicles and habitats. These batteriesdo not model any dynamics on their own and only represent storage of charge produced by the solar panelsand consumed by the vehicle driving.

2 of 15

American Institute of Aeronautics and Astronautics

(a) LER with PUP model (b) ATHLETE model

Figure 1: The LER vehicle carrying a PUP and the ATHLETE vehicle models.

(a) Habitat model (b) Altair Lander model (c) PUP model

Figure 2: The habitat, lander and PUP models.

The energy consumption model uses the vehicles center of mass and linear and angular velocity. Thevehicles velocity is combined with a rolling resistance to calculate the basic driving load. The verticalcomponent of linear velocity is used to calculate additional energy loads from going up and down hills. Thisenergy consumption estimate has been compared to experimental results on a prototype LER rover. A majorcomponent of the vehicle energy consumption while driving is the vehicle mass, which is used to calculatethe rolling resistance. To more accurately model long-term rover excursions, the LSOS simulator supports aconcept of discrete changes in rover mass. This helps to model the addition of large sample masses, whichwould be acquired by scientists or the removal of the PUP mass when it is left on the surface to chargeindependent of the rover.

Energy production for surface operations comes from deployable solar panels. Power levels are estimatedthrough the use of the LSOS rendering and visualization system. Each time the solar panel model needsto calculate the power draw, a special target painted with a emissive green color and of the same size andshape of the solar panel is made visible on the solar panel. A rendering of this green panel is made as viewedfrom the sun location and the number of green pixels is counted and compared to the maximum numberof pixels calculated from another imaged rendered straight at the panel with no obstructions. Example ofthese rendered images is shown on Figure 3. Terrain features, other vehicles or other panels that occludeand shadow the panel will reduce the panels visible green area. If the solar panels are not angled directlyat the sun, their image projection in the direction of the sun will decrease and the power produced willdecrease accordingly. All of the solar panel models (on the PUP and habitats) are designed to track thesun throughout the lunar day, but the solar panels are only actuated in one degree of freedom, resulting inimperfect tracking, especially when the sun is at high angles above the horizon. For the LER vehicle withattached PUP and solar panel, the solar panel sun tracking motor is locked out during rover driving, resultingis a large degree of variation in sun angle for some drives. The computation technique for computing energygenerated by the solar panels provides a fast and accurate measurement of predicted energy generation.

3 of 15

American Institute of Aeronautics and Astronautics

Figure 3: Three views of solar panels as some are partially occluded by terrain and each other.

B. Terrain Models

Two new terrain models were developed recently for LSOS, a Lunar Orbiter Laster Altimeter (LOLA) basedterrain of the south pole of the moon and a high-resolution synthetic terrain.

1. LOLA 75 Degree South Pole Lunar Terrain Model

The Lunar Reconnaissance Orbiter (LRO) mission is now orbiting the moon and collecting elevation dataof the surface of the moon using the LOLA instrument. Recently, a set of data from LOLA that coveredthe south pole of the moon was processed by a United States Geological Survey (USGS) team. This data,received from the USGS, was processed to create a terrain store for the south pole of the moon up to 75degrees south latitude. The area covered is approximately 940 km square centered at the south pole of themoon. Unfortunately, the process to combine the strips of LOLA data currently has some short-comingsand the resulting surface shows signi�cant artifacts near the edge of each of the LOLA strips. This createsarti�cial ridges and peaks that make the LOLA elevation data unusable for our vehicle simulation purposes(see Figure 4a). We therefore did a signi�cant Gaussian smoothing of the raw LOLA elevation data toproduce a usable terrain as shown on Figure 4b. The original resolution of the data was 240 meters. Aftersmoothing, the pixel spacing is still 240 meters, but the accuracy is signi�cantly less. The resultant datastore requires approximately 240 megabytes of disk storage.

(a) Raw LOLA terrain model with processing artifacts. (b) Filtered LOLA terrain model.

Figure 4: The LOLA terrain model with a view from Shackleton Crater looking towards Malapert Mountain.

2. Synthetically Augmented South Pole Lunar Terrain

Vehicle simulations in LSOS model the vehicles wheel interaction with the terrain. With a 240 meterresolution terrain model, the simulations have limited validity because the terrain is smoother than it will bein reality. So it is important to use terrains with resolutions that are comparable to the size of the vehicleswheel. We set out to create a high-resolution terrain with 1 meter resolution based on the LOLA 75 Degreesouth terrain. Using algorithms and software provided by Bob Gaskell,9 we added craters, rocks, and noiseto the 240m LOLA terrain model to construct a realistic 1 meter resolution synthetic terrain model. Weused the JPL Supercomputer cluster to execute many hundreds of programs in parallel to create the terrain.The process takes over 100 hours of computing time on a multi-node super computer cluster and producesa dataset of approximately 102 gigabytes broken into 145 tiles. The resulting terrain is 191 km by 136 kmand is centered approximately half way between Shackleton Crater and Malapert Mountain, two prominent

4 of 15

American Institute of Aeronautics and Astronautics

features close to the South Pole of the moon. An image of the terrain is shown on Figure 5. The terraincovers Shackleton crater, Malapert Mountain, Shoemaker crater, Haworth crater, and de Gerlache crater.

Figure 5: The synthetically augmented high resolution lunar terrain model.

C. 3D Visualization System

The LSOS 3D visualization system, called DspaceOgre, provides accurate real-time 3D visualization ofsimulations. Built on top of the open-source OGRE 3D graphics engine, DspaceOgre allows LSOS to creategraphical objects to represent rovers, terrains, planetary bodies, and skies, among other things and arrangethem in a scene graph hierarchy.

The terrain data sets that LSOS deals with are too large to be displayed all at once in full detail withmodern graphics cards. To render these large data sets, DspaceOgre uses a level-of-detail technique calledclipmapping. This technique allows the highest-resolution mesh to be displayed where it is needed. Thishigh-resolution area is surrounded by rings of gradually lower resolution meshes (see Figure 6). The high-resolution mesh’s location on the terrain changes dynamically. For example, the high-resolution mesh candynamically follow the rover. As the displayed scene changes, each of the vertices are dynamically adjusted toconform to the terrain’s digital elevation map. DspaceOgre utilizes the OpenGL Shading Language (GLSL)to implement the clipmapping technique on the Graphics Processing Unit (GPU). This allows for real-timerendering of terrains at greater than 30 frames per second.

(a) Terrain (b) Wireframe View of Terrain

Figure 6: A rendering of the terrain along with the same terrain rendered in wireframe mode to show the underlyingclipmapping levels of detail.

DspaceOgre also uses advanced GPU techniques to support rendering shadows, bump mapping and wheeltracks. Shadows are rendered using shadow mapping, which involves rendering scene from the vantage pointof the sun and using the depth values to determine which pixels in the scene are in shadow. Surface normals

5 of 15

American Institute of Aeronautics and Astronautics

are perturbed in the fragment shader to do bump mapping, which gives the terrain a synthetic roughness.Surface normals are also modi�ed to give the impression of wheel tracks on the terrain. See Figure 7 for anexample of these features.

Figure 7: A rendering of a rover that shows DspaceOgre’s ability to render wheel tracks, shadows, and terrainbump-mapping.

In addition to being used for visualization, DspaceOgre is also used for GPU-accelerated scene analysis.Results from these analyses can be fed back into the simulation. One analysis capability that DspaceOgreprovides LSOS is line-of-sight detection between pairs of objects. This is used by LSOS to determine whetherthere is line of sight between two vehicles or between a vehicle and a planetary body. Computation of line ofsight between objects is done by rendering the scene from the vantage point of one object and scanning theimage for existence of pixels that represent the other object. Special graphic objects are used to representthe objects to distinguish them from the rest of the scene. See Figure 8 for an example, where DspaceOgrewas used to determine of sight. Green and red color lines were used to give a visual cue of the line-of-sight results. Similar techniques are used for determining solar panel power level (see Sub-section II.A).DspaceOgre counts the percentage of pixels that represent the panel that are visible when rendering fromthe vantage point of the sun.

(a) Line Of Sight Between Vehicles (b) No Line Of Sight Between Vehicles

Figure 8: An example where DspaceOgre is used to determine if there is line of sight between vehicles. Green or redlines are drawn to give a visible cue to the user of the line-of-sight results.

LSOS supports rendering on multiple workstations from a single simulation. This is done by creatingmultiple instances of DspaceOgre and sending messages to the instances via either the Transmission ControlProtocol (TCP) or User Datagram Protocol (UDP) communication. This allows for rendering the identicalinstances of the scene on each workstation. This capability has been used to run LSOS at the NASA JohnsonSpace Center’s immersive dome facility, where there are multiple projectors, each projecting to portions ofthe dome. Each projector is controlled by a workstation. When running LSOS, an instance of DspaceOgreis run on each workstation with slightly di�erent camera position and orientation settings. The projectedimages are blended to give the illusion of a large contiguous screen without any visible seams.

6 of 15

American Institute of Aeronautics and Astronautics

D. Path Planning

Figure 9: Traverse path from Shackleton Crater toMalapert Mountain and back.

The traversal distance of planned lunar activitiescan be very long. For example, one proposed mis-sion is a round-trip traverse, from Shackleton Craterto Malapert Mountain while visiting 13 science way-points, could be as long as 600 km over a lunarday (15 Earth days), The path is shown on Figure9. Even though lunar vehicles such as LERs andATHLETEs could be driven by the astronauts or re-motely operated, it is tedious to manually �nd safepaths, especially for long mission on a hazardous ter-rain full of craters and mountains of various sizes.Given terrain information obtained through remotesensing, the Path Planning component computessafe paths for vehicles involved in such missions.The current planner is based on an A* algorithmapplied to a simple 8-connected graph, althoughit could be extended to a graph that accounts forheading/non-holonomic constraints.10 The traver-sal cost of each edge is a Euclidean distance withsome penalty on the roughness and slope value eval-uated at each terrain pixel (e.g., 1x1m square) ob-tained by querying the terrain model. Because it iscomputationally infeasible to construct a graph of1m resolution over a long 600km course of travel,

the path planner iteratively solves subproblems with multiple resolutions: high-resolution grid and straightline approximation. In each subproblem, the graph consists of a high-resolution grid around the start node(e.g., 100x100m region), and each node on the high-resolution grid boundary is connected directly to thegoal, as shown in Figure 10a. The cost of traversal from a boundary node to the goal is approximated byan Euclidean distance between them with a hazard penalty (e.g., slope and roughness) evaluated at theboundary node.

(a) Multi-resolution grid. (b) Sequence of plans towards the goal.

Figure 10: Cells in the square region 10a on a high-resolution grid (8-connected graph in this �gure) and its boundarynodes (shaded in cyan) are connected to the goal by a straight line. Three steps in �nding a path are shown on �gure10b. The �rst shows the path found in the �rst iteration (colored in orange). The next plan in the middle �gurestarts from a node closer to the goal on the found path. The green line represents the path taken from the previousiteration.

Once a path is found from the start node to a boundary node that is connected to the goal by a straight-line as shown on Figure 10a, the path planner moves the start node towards the goal along the path justfound, for the next iteration. As shown in the middle �gure of 10b, a portion of the path in the high-resolution grid is taken from the previous plan (represented in green), and the new start node is set at itsend. The boundary nodes are also moved with the start node, and the A* search computes a new path. Theprocess is repeated until the goal is reached within the high-resolution grid. Note the start node is not at

7 of 15

American Institute of Aeronautics and Astronautics

the boundary node of the previous plan, so Plan 2 does not necessarily follow the path found from Plan 1.Figure 11 shows a snapshot of the vehicles, terrain evaluation (green is feasible, orange is infeasible), andthe planned path (shown in yellow) to a goal 5km away on a GSSR lunar terrain data.

Figure 11: A path from the mission start towards a distant goal. The lunar terrain model is represented in gray; thesafe region is in green, and the hazardous region in orange.

E. Scenario Scripting

The LSOS scenario scripting component provides an e�cient interface for de�ning, simulating, and analyzinglunar missions. The simulator is driven by a �nite state machine where individual states represent particularbehaviors required to simulate such complex scenarios. In this implementation, each mission-level �nite statemachine creates platform �nite state machines that control the behavior of particular platforms (vehicles,assets, and habitats). Each platform �nite state machine is de�ned by a sequence of events that representtraverses, extravehicular activities, waits, pauses, or any other required mode of operation. An illustrationof an example mission �nite state machine composed of two vehicle models and one habitat model is seenbelow in Figure 12.

Mission FSM

Rover 1 FSM

Habitat 1 FSM

Rover 2 FSM

Traverse EVA Dock Recharge

TraverseCommTraverse

Deploy Solar Panels

Recharge Rover

Recharge Rover

Traverse Comm Traverse EVA

DockRechargeTraverse

Figure 12: An example of a �nite state machine that guides a multi-vehicle mission simulation. In this example, three�nite state machines control the behavior of three independent models (two vehicles and one habitat) to simulate amission.

Custom �nite state machines becomes increasingly di�cult to implement as mission complexity increases.An alternative approach is to initialize the �nite state machine using a markup language. Keyhole MarkupLanguage (KML) in particular is a useful tool for describing such scenarios because geometry information isavailable, schema de�nitions can be augmented, and tools exist to visualize and manipulate such data. Inorder to represent the �nite state machine in Figure 12, individual KML placemarks are de�ned with LSOS-speci�c schemadata that determines the platform, sequence order, event type, duration, energy consumption,or any other measure of interest. LSOS provides an interface that constructs, simulates, and records the �nitestate machine described in a KML �le. The recorded data is then processed through a script to constructa KML �le that overlays the logged data with the original mission plan. An overview of this procedure isillustrated in Figure 13

8 of 15

American Institute of Aeronautics and Astronautics

(a) KML-Based Mission Plan (b) LSOS Rover Simulation (c) KML-Based Analysis

Figure 13: An overview of the mission planning, simulation, and analysis approach for large, complex missions witha KML interface.

F. User Interface

Setting up and using LSOS is typically performed through a graphical user interface (GUI) or throughcustomized scripts written in the Python programming language. For novice users, a simpli�ed GUI wasdesigned with prede�ned capabilities for the anticipated use of LSOS at other NASA centers. The interfaceseparates the use of LSOS into 2 steps. The �rst is the con�guration of the simulation and the second is theexecution of the simulation. The set-up GUI used in the �rst step provides:

� the selection of a terrain model from a list of models

� setting the start time and simulation time step size to use

� the selection of models from a list of vehicles and habitats to use in the simulation

� the choice of setting other parameters like choice of display of shadows and wheel tracks

� an interactive interface to specify drive paths for vehicles, or to specify a drive path de�nition �le

During the execution of the simulation, the run-time GUI provides:

� simple mouse motions to con�gure the view

� buttons to start and stop the simulation and to display stripchart of simulation data and documentationon use of the GUI

� a joystick to interactively drive the vehicle

� intuitive display of data, for example, a speedometer for vehicle speed, a battery icon with red andgreen areas to indicate energy battery charge, etc.

Figures 14a and 14b show the respective GUIs.

III. Analyses and Simulation Studies

A. Shackleton-Malapert-Shackleton Traverse Simulation

A simulation of a Lunar Electric Rover (LER)11 driving on the moon from Shackleton Crater to MalapertMountain and back to Shackleton Crater was recently performed with LSOS. The 40-meter resolution Gold-stone Solar System Radar (GSSR)12 lunar terrain model was used for the simulation. The traverse visited11 locations selected by Weisbin, et. al.13 for their science value. The path followed by the rover is shownon Figure 9. Areas in red indicate no data value areas on the GSSR terrain model.

The schedule for the 14-day mission was based on a plan developed at the National Administration forSpace Astronautics (NASA) Langley Research Center (LaRC). A day in the simulation is a 24-hour period.The mission was designed to occur during the daytime of a day/night cycle on the moon. Unless speci�ed asa Lunar day, the use of the word day in the remainder of this paper represents a 24-hour period. With theexception of two days, the mission plan speci�ed a daily schedule with the following sequence of activities:

9 of 15

American Institute of Aeronautics and Astronautics

(a) Set-up GUI (b) Run-time GUI

Figure 14: The set-up and run-time GUIs used with LSOS.

� traverse to the next science site with the solar panels on the LER locked in an optimal con�guration.The vehicle was commanded to drive at 8 kilometers/hour during this traverse phase.

� upon arrival at the science site, place the solar panel power system on the ground and set it to servocontinuously to point to the sun.

� explore the science site for a speci�ed time (modeled as driving at 2 kilometers/hour in a circular path).

� place the solar panel power system back on the LER.

� rest (no driving but the solar panel continues to servo to point to the sun) until the start of the nextday.

These activities were repeated for 12 days of the 14-day simulation. On days 7 and 10 of the mission, theLER did not perform the �rst item on its activity list { drive to the next science location. Instead, itexplored the current science site. A simulation scenario was constructed to follow the speci�ed schedule.The the simulation was set to begin at 10:00 am on Nov 20, 2023 and ran for fourteen 24-hour days. Duringthe simulation, the sun position was calculated using the SPICE toolkit.14 Solar panel Illumination wasaccurately modeled through a solar panel model which takes into account the panel’s line of sight to the sun(occlusion by the terrain features is accurately captured by the model).

The following data were collected during the simulation:

� Energy generated from solar panels

� Energy used for driving and on-board vehicle operations

� Location of the vehicle on the lunar surface

The power data shown below in Tables 1 and 2 from this simulation was of most interest to the NASALangley Research Center(LaRC) mission planners. Units of time are in hours, distance in kilometers andenergy in kilo-Watt-hours.

10 of 15

American Institute of Aeronautics and Astronautics

Table 1: Energy data for Days 1-7 of Shackleton to Malapert traverse.

Day 1 2 3 4 5 6 7

Time

Traverse 0.74 7.47 6.39 4.26 2.69 2.05 0.00

Explore 3.50 3.50 3.50 4.25 5.25 5.00 5.75

Parked 19.26 12.53 13.61 14.99 15.56 15.95 17.25

Distance

Traverse 7.72 77.53 66.57 44.38 28.18 21.33 0.00

Explore 6.59 6.65 6.60 8.14 9.93 9.73 11.19

LER PUP LER PUP LER PUP LER PUP LER PUP LER PUP LER PUP

Energy

Start Day 90.00 100.00 90.00 100.00 90.00 100.00 90.00 44.32 90.00 68.87 90.00 99.60 90.00 100.00

Traverse

Consumed -2.62 -0.15 -34.68 -1.49 -25.43 -1.28 -19.68 -0.85 -9.87 -0.54 -9.47 -0.41 0.00 0.00

from PUP 2.62 -2.67 34.68 -35.39 25.43 -25.95 19.68 -20.08 9.87 -10.07 9.47 -9.66 0.00 0.00

Recharge 0.00 2.82 0.00 12.17 0.00 8.02 0.00 6.33 0.00 6.08 0.00 4.17 0.00 0.00

End Traverse 90.00 100.00 90.00 75.29 90.00 80.80 90.00 29.72 90.00 64.35 90.00 93.70 90.00 100.00

Exploration

Consumption -7.95 -0.70 -8.21 -0.70 -7.90 -0.70 -10.29 -0.85 -12.25 -1.05 -12.68 -1.00 -14.58 -1.15

from PUP 0.00 0.70 0.00 15.37 0.00 0.00 0.00 18.04 0.00 13.59 0.00 7.30 0.00 1.15

End explore 82.05 100.00 81.79 89.96 82.10 80.10 79.71 46.90 77.75 76.89 77.32 100.00 75.42 100.00

Parked

Consumption -34.67 -3.85 -22.55 -2.51 -24.50 -2.72 -26.98 -3.00 -28.01 -3.11 -28.71 -3.19 -31.05 -3.45

from PUP 42.61 -43.48 30.76 -31.39 32.40 -33.06 37.27 -38.03 40.26 -41.08 41.39 -42.23 45.63 -46.56

Recharge 0.00 47.34 0.00 43.94 0.00 0.00 0.00 63.00 0.00 66.91 0.00 45.42 0.00 50.01

End Day 90.00 100.00 90.00 100.00 90.00 44.32 90.00 68.87 90.00 99.60 90.00 100.00 90.00 100.00

Table 2: Energy data for Days 8-14 of Shackleton to Malapert traverse.

Day 8 9 10 11 12 13 14

Time

Traverse 2.31 10.07 0.00 2.89 9.51 3.24 3.02

Exploration 5.25 6.00 5.25 3.50 3.50 3.50 0.00

Parked 15.94 7.68 18.50 17.11 10.49 16.76 20.98

Distance

Traverse 23.85 104.94 0.00 29.96 99.09 33.66 31.52

Exploration 10.06 11.57 10.13 6.57 6.73 6.78 0.00

LER PUP LER PUP LER PUP LER PUP LER PUP LER PUP LER PUP

Energy

Start Day 90.00 100.00 90.00 100.00 90.00 82.11 90.00 29.90 53.93 10.00 40.00 10.78 40.00 37.33

Traverse

Consumption -17.52 -0.46 -49.34 -2.01 0.00 0.00 -13.75 -0.58 -42.91 -1.90 -17.89 -0.65 -14.44 -0.60

from PUP 17.52 -17.88 49.34 -50.35 0.00 0.00 13.75 -14.03 10.00 -10.20 0.00 0.00 0.00 0.00

Recharge 0.00 1.57 0.00 11.20 0.00 0.00 0.00 1.45 0.00 6.69 0.00 6.53 0.00 3.56

End traverse 90.00 83.24 90.00 58.83 90.00 82.11 90.00 16.74 21.02 4.58 22.11 16.67 25.56 40.29

Exploration

Consumption -13.77 -1.05 -15.10 -1.20 -13.21 -1.05 -7.83 -0.70 -9.19 -0.70 -8.84 -0.70 0.00 0.00

Recharge 0.00 17.81 0.00 26.18 0.00 0.00 0.00 0.00 0.00 14.21 0.00 14.78 0.00 0.00

End explore 76.23 100.00 74.90 83.82 76.79 81.06 82.17 16.04 11.83 18.09 13.26 30.75 25.56 40.29

Parked

Consumption -28.69 -3.19 -13.82 -1.54 -33.30 -3.70 -30.81 -3.42 -18.89 -2.10 -30.17 -3.35 -37.76 -4.20

From PUP 42.46 -43.33 28.92 -29.51 46.51 -47.46 2.57 -2.62 47.06 -48.02 56.91 -58.07 52.20 -53.27

Recharge 0.00 46.52 0.00 29.33 0.00 0.00 0.00 0.00 0.00 42.81 0.00 68.00 0.00 27.73

End Day 90.00 100.00 90.00 82.11 90.00 29.90 53.93 10.00 40.00 10.78 40.00 37.33 40.00 10.56

The results from the simulation showed that the energy available during the mission dipped to dangerouslylow levels during days 11, 12, 13 and 14. The start of the mission was chosen to coincide with the dawnof the Lunar day. The outgoing path to Malapert from Shackleton followed an easterly route that kept thevehicle in mostly illuminated regions during the early parts of the Lunar day. As the Lunar day progressedand the Sun moved to the West. Returning to Shackleton Crater via the Eastern route left the vehicle inshadowed regions, severely reducing the amount of energy generated by the solar panels.

B. Solar Panel Power Generation at Shackleton and at Malapert

A comparison of di�erent solar panel control strategies was performed with LSOS to support the design ofa new version of the LER11 cabin. The objective of the analysis was to help determine a desirable batterycapacity for the new LER cabin design. The results from the simulation analysis were used as inputs to the

11 of 15

American Institute of Aeronautics and Astronautics

analysis performed by the LER cabin design team at the Johnson Space Center. The simulations in LSOSstudied the power generation capability of the solar panels on the LER and the Portable Utility Palette (PUP)carried by the LER. The PUP is a deployable asset that can be placed on the ground to collect solar energywhile the LER explores a site. While deployed, the PUP can servo its solar panels to maximize solar energycollected by its solar panel and saved to its battery. The study evaluated performance at di�erent locationson the moon under two di�erent solar panel control strategies. The �rst solar panel control strategy was tooptimally point the PUP solar panels at the sun at the start of a traverse and lock them before commencingthe traverse. The second was to continuously re-orient the PUP solar panel mimicking its con�gurationwhen deployed on the ground. For all simulations, the LER solar panel was modeled as rigidly attached tothe vehicle. The simulations were performed at two sites: Shackleton Crater close to the South Pole of themoon and at Malapert Mountain at a latitude of about 85 degrees South.

The following data were logged at 10 minute intervals:

� Time

� Sun position (azimuth and elevation)

� LER solar panel illumination

� PUP solar panel illumination

Energy generation data collected from simulations run for each site were for the following conditions:

� PUP solar panel always pointing to the sun simulating a parked PUP with actively controlled solarpanel.

� PUP solar panel pointed to the sun once and only at the start of each day and a rigidly mounted solarpanel on the LER.

� LER solar panel rigidly attached to the vehicle.

Each simulation ran for 56 days covering about two Lunar day/night cycles. During the simulations, thesun position was positioned from data obtained from the SPICE toolkit.14 The 40-meter resolution GSSRlunar terrain model was used for these simulations. PUP solar panel Illumination was accurately modeledthrough a solar panel model which takes into account the panel’s line of sight to the sun (occlusion by theterrain features are accurately captured by the model). We did not have a solar panel model for the LER sothe LER Illumination was estimated by taking the cosine of the angle between the vector from the rover tothe current sun position and the vector from the rover to the sun position at the start of the day.

The data were stored in the HDF5 Table format (http://hdfgroup.org) which allows the data to beeasily retrieved and processed. Scripts were written to display the sun elevation, PUP illumination andLER illumination as a strip chart as well as saving the data to a comma delimited �le for importing tospreadsheets.

The Shackleton Crater site was about 10 km North of the South Pole of the moon. The traverse was todrive in a 20km square loop with 5km sides. Shackleton Crater is an elevated terrain feature to the southof the site. The Malapert Mountain site was on the northern plain of Malapert about 10 km north of theMalapert peak. The same traverse, a drive in a 20km square loop with 5km sides, was performed at thissite. The simulations were all begun at 10:00 am on Dec 4, 2023. Data from the simulations are shown onFigure 15 for the simulations at the Shackleton Crater site and Figure 16 for the Malapert Mountain site.

At sites close to the poles, the sun is always low on the horizon. At Shackleton Crater at the SouthPole of the moon, the highest elevation of the sun is about 0.034 radians (about 2 degrees). At MalapertMountain at a latitude of 85 degrees South, the highest elevation of the sun is about 0.106 radians (about6 degrees). It is not surprising then that the results showed that the terrain greatly in uences the solarpanel illumination - more so than the lunar day cycle. There were signi�cant terrain features near these sites(Shackleton and other crater rims at the polar site and Malapert peak near the Malapert site) that obscureillumination by the sun.

12 of 15

American Institute of Aeronautics and Astronautics

0 5 10 15 20 25 30 35 40 45 50 55 60� 6 � 10�2

� 4 � 10�2

� 2 � 10�2

2 � 10�5

2 � 10�2

4 � 10�2

6 � 10�2

8 � 10�2

0:1

0:12

0:14

0:16

0:18

time (days)

Sun

ele

vatio

nangle

(in

radia

ns)

sun elevation

(a) Sun Elevation

0 5 10 15 20 25 30 35 40 45 50 55 600

0:1

0:2

0:3

0:4

0:5

0:6

0:7

0:8

0:9

1

1:1

1:2

1:3

1:4

1:5

time (days)

Illu

min

atio

nratio

LER solar panel

PUP solar panel on LER

PUP solar panel on ground

(b) Illumination Ratio

Figure 15: Sun elevation and solar panel illumination at Shackleton Crater.

13 of 15

American Institute of Aeronautics and Astronautics

0 5 10 15 20 25 30 35 40 45 50 55 60� 6 � 10�2

� 4 � 10�2

� 2 � 10�2

2 � 10�5

2 � 10�2

4 � 10�2

6 � 10�2

8 � 10�2

0:1

0:12

0:14

0:16

0:18

time (days)

Sun

ele

vatio

nangle

(in

radia

ns)

sun elevation

(a) Sun Elevation

0 5 10 15 20 25 30 35 40 45 50 55 600

0:1

0:2

0:3

0:4

0:5

0:6

0:7

0:8

0:9

1

1:1

1:2

1:3

1:4

1:5

time (days)

Illu

min

atio

nratio

LER solar panel

PUP solar panel on LER

PUP solar panel on ground

(b) Illumination Ratio

Figure 16: Sun elevation and solar panel illumination at Malapert Mountain.

14 of 15

American Institute of Aeronautics and Astronautics

IV. Conclusion

Recent developments in LSOS have been described in this paper. New surface system elements andterrain models, and procedures for use in simulating mission scenarios have been developed. The resultsfrom the analyses and simulations have been fed back to teams at other NASA centers to assist in the designand planning of missions. LSOS has demonstrated that high-�delity dynamics simulation is a powerful toolto assist during the concept development and planning stages of space missions.

Work on the development of LSOS continues. The general approach pursued in the development ofthe family of dynamics simulators at JPL can be easily adapted to simulate a variety of space applicationsincluding missions to near-Earth objects, and landing and surface operations on planetary and other spacebodies. As NASA considers new mission objectives and develops plans using new designs of transport systemsto new space environments, our simulation capability is well-positioned to adapt to and address NASA’s newrequirements. In preparation for this change, LSOS is transitioning to a more general project and softwarepackage named Surface Exploration Operations Simulator (SEOS).

V. Acknowledgments

This work was carried out at the Jet Propulsion Laboratory, California Institute of Technology, undera contract with the National Aeronautics and Space Administration. We thank our sponsor, Doug Craigfrom NASA Headquarters, Bob Gaskell at the Planetary Science Institute and our collaborators at theUnited States Geological Survey (USGS), NASA Glen Research Center, NASA Langley Research Center,NASA Johnson Space Center, NASA Ames Research Center, NASA Marshall Space Flight Center, and JetPropulsion Laboratory for support in the development of LSOS.

References

1Nayar, H., Balaram, J., Cameron, J., Jain, A., Lim, C., Mukherjee, R., Peters, S., Pomerantz, M., Reder, L., Shakkottai,P., and P., S. W., \A Lunar Surface Operations Simulator," Proceedings of the Simulation, Modeling, and Programming forAutonomous Robots 2008 (SIMPAR 2008), Venice, Italy, November 2008, pp. 65{74.

2Nayar, H., Balaram, A. J. J., Cameron, J., Lim, C., Mukherjee, R., Pomerantz, M., Reder, L., Myint, S., Serrano, N., andWall, S., \Recent Developments on a Simulator for Lunar Surface Operations," Proceedings of the AIAA SpaceOps Conference2009 , AIAA, Pasadena, CA, September 2009.

3Jain, A. and Man, G., \Real-time simulation of the Cassini spacecraft using DARTS: functional capabilities and thespatial algebra algorithm," 5th Annual Conference on Aerospace Computational Control , Pasadena, CA, August 1992.

4Biesiadecki, J., Henriquez, D., and Jain, A., \A Reusable, Real-Time Spacecraft Dynamics Simulator," 6th DigitalAvionics Systems Conference, Irvine, CA, October 1997.

5Jain, A., Guineau, J., Lim, C., Lincoln, W., Pomerantz, M., Sohl, G., and Steele, R., \ROAMS: Planetary Surface RoverSimulation Environment," International Symposium on Arti�cial Intelligence, Robotics and Automation in Space (i-SAIRAS),Nara, Japan, May 2003.

6Jain, A., Balaram, J., Cameron, J., Guineau, J., Lim, C., Pomerantz, M., and Sohl, G., \Recent Developments in theROAMS Planetary Rover Simulation Environment," IEEE Aerospace Conference, Big Sky, Montana, March 2004.

7Balaram, J., Austin, R., Banerjee, P., Bentley, T., Henriquez, D., Martin, B., McMahon, E., and Sohl, G., \DSENDS- A High-Fidelity Dynamics and Spacecraft Simulator for Entry, Descent and Surface Landing," IEEE Aerospace Conference,Big Sky, Montana, March 2002.

8Jain, A., Cameron, J., Lim, C., and Guineau, J., \SimScape Terrain Modeling Toolkit," Second International Conferenceon Space Mission Challenges for Information Technology (SMC-IT), Pasadena, CA, July 2006.

9Gaskell, R., Husman, L. E., Collier, J. B., and Chen, R. L., \Synthetic Environments for Simulated Missions," IEEEAerospace Conference, Big Sky, Montana, 2001.

10Pivtoraiko, M., Knepper, R. A., and Kelly, A., \Di�erentially constrained mobile robot motion planning in state lattices,"Journal of Field Robotics, Vol. 26, No. 3, 2008.

11Ambrose, R., \Human-Robotics Interactions: Field Test Experiences from a collaborative ARC, JPL and JSC Team,"AIAA NASA 3rd Space Exploration Conference, Denver, CO, February 2008.

12Cooke, D., Yoder, G., Coleman, S., and Hensley, S., \Lunar Architecture Update," AIAA NASA 3rd Space ExplorationConference, Denver, Colorado, February 2008.

13Weisbin, C. R., Mrozinski, J., Lincoln, W., Elfes, A., Shelton, K., Hua, H., Smith, J. H., Adumitroaie, V., and Silberg,R., \Lunar Architecture and Technology Analysis Driven by Lunar Science Scenarios," Systems Engineering Journal , Vol. 13,No. 3, 2010.

14NAIF, \SPICE Toolkit," http://naif.jpl.nasa.gov, 2010.

15 of 15

American Institute of Aeronautics and Astronautics