NASA Volatiles Investigating Polar Exploration Rover (VIPER) is a planned Lunar mission conducted via a remotely commanded robot to prospect for water ice. Operational decisions for rover driving and instrument commanding will be compressed to minute-scale timeframes. VIPER requires scientists to make decisions like those delegated to Apollo astronauts, on the same time scales, remotely from Earth.

The VIPER rover is 2.5m tall and 1.5m in length and width. Cameras are used for navigation, imaging and to generate point clouds used for terrain correction. To support prospecting, the rover carries a Neutron Spectrometer System (NSS), a Near-Infrared Volatiles Spectrometer System (NIRVSS), a Mass Spectrometer (MSOLO), and a drill (TRIDENT) which analyzes the drill cuttings.

Many software packages and custom tools were developed and repurposed to support mission operations and were required to interoperate. Data must be aggregated and searchable via location and time. We developed the Map Server to store data from multiple inputs, to rebroadcast data and events, and to provide a flexible API for access.

Data flows over multiple protocols. All data going to and from the rover will be sent over the Deep Space Network (DSN) using the CCSDS protocol.

Protocols that the Map Server supports include:
• Robotic telemetry from Rover Ground Software sent over ROS (open source Robot Operating System)
• HTTP requests from various tools including
o OpenMCT for time-controlled visualization in a web browser
o MMGIS (built on Leaflet and Three.js) for map visualization within OpenMCT
o VIPER Lunar route planning tool written in C#
o Eclipse (Java) commanding tool for robot operators and engineers
• REDIS to integrate with Manual Alignment image adjustment tools which uses OpenLayers
• YAMCS to integrate with OpenMCT and receive CCSDS data

Raster maps: During development, we were faced with mapping challenges. The ideal map projection is an offset polar stereographic lunar projection to support accurate metric measurements near the south pole of the Moon. Base GeoTIFF maps were created from imagery generated by the Lunar Reconnaissance Orbiter Camera (LROC), focusing on the area to be explored, and reprojected into our custom projection. We use LunaSERV (Arizona State University) as the backbone for storing and serving base maps and other raster map layers, since LunaSERV supports this Lunar map projection and the WMS protocol. We leverage GDAL to do GeoTIFF manipulation, both to correct and enhance base maps and to generate rasters on the fly.

Data import and export: Map Server supports data export as WMS layers and GeoJSON. Members of the science team use external tools such as MATLAB, ArcGIS, JMP and Excel to do deeper analysis of the data.

Implementation details: We developed Map Server as a set of Docker containers, to easily control configuration and deployment. Postgres with PostGIS is our database, extended to have our custom map projection for efficient queries and reprojection. The HTTP API was written in Python using Flask and SQLalchemy. We utilized libraries such as shapely and pyproj.

Challenges: Some of the instrument data will be collected while the rover is driving, and it will be used by the science team to interpret what elements are in various areas. The rover’s plan might include repeated coverage of interesting areas. As the instrument data is received, it will be aggregated and run through complex filters to generate heat maps. Since the Map Server must provide these heat maps as layers for the various tools to use for visualization, we started with an approach of creating GeoTIFF raster layers. However, since the rover revisits overlapping regions or corrects its location, we often have to re-aggregate and recompute heat maps, which proved too compute intensive to deliver for real time analysis. To solve this issue, we turned to PostGIS. By storing the raw data with timestamp and location in the database, we can configure MMGIS/Leaflet to automatically pass the visual map bounds and zoom level to Map Server’s API, which uses PostGIS queries to aggregate the data on the fly and generate GeoJSON to display in MMGIS. With this approach, the data can be dynamically controlled and delivered on time.

Lessons learned: A complex mission with many interconnected systems using different protocols absolutely relies on centralized services to unify data and translate between various protocols. Each software system is typically developed focusing on its own needs and requirements, which may include Earth-based WGS84 latitude and longitude projections, local coordinate systems from a defined origin, or another projection entirely. By carefully defining our own projection and properly installing it in systems that support map projections (PostGIS, LunaSERV) we can leverage the capabilities of those systems to support the varying needs of the client software. VIPER’s Map Server could not have been developed on time and in budget without free and open source software.