Statement of Work - Functional Specifications

Modeling of LASR Digital Twin – LASR Facility

Introduction:

The Laboratory for Autonomous Systems Research (LASR), Code 1700 of the Naval Research

Laboratory (NRL) provides facilities, equipment and other resources that enable research in the fields of robotic and autonomous systems (RAS), communication and navigation, human robot interaction and machine learning. To better support this research, the LASR facility requires a high-fidelity digital twin of its facilities, equipment and platforms.

Scope:

This document describes the minimum technical specifications, performance standards and delivery requirements for a digital twin of the facilities and assets at LASR to be developed by the vendor and delivered to the Naval Research Laboratory, Washington, DC.

Delivery:

The Digital Twin and associated software will be delivered and uploaded to computers in the

Laboratory for Autonomous Systems Research at the Naval Research Laboratory, Washington DC

20375.

Description:

The Digital Twin will accurately model and simulate the physical environments and various assets within the LASR facility, providing NRL researchers with an easily accessible tool for simulating robotic and autonomous system (RAS) behaviors in realistic digital environments. The Digital Twin shall enable controlled exploration and extensive test and evaluation of RAS across a wide range of conditions in a cost-effective manner not afforded by the physical environment.

1 System Specifications:

1.01 The Digital Twin shall utilize the latest tools and services within the NVIDIA Omniverse

Digital Tools and Environment to implement and operationalize the concept.

1.02 The Digital Twin shall include the following components:

1.02.1 Virtual environments of four distinct high bay spaces (outlined below in 1.03.1) with physical properties and behavior parameterized by real world or proxy sensor values

1.02.2 RAS platform models (outlined in 1.04.1) with physical properties, sensors, actuators, and manipulators included as modular components

1.02.3 Tools, plug-ins and microservices to support anticipated functionalities including, but not limited to, model import and synthesis from environment scans, model update scripts, automated test and validation scripts, and user interfaces

1.02.4 Validation of the model performance that ensures behaviors and observations in the virtual environment are acceptable approximations of performance in the real physical environment.

1.03 Environment Models Specification:

1.03.1 Models shall be built of LASR environments including four physical spaces within the

LASR facility including:

1.03.1.1 Desert High Bay (DHB), a simulated arid terrain environment used for evaluating autonomous ground vehicles and sensors with overall room dimensions of approximately 44 ft × 30 ft × 28 ft. Within the DHB, there is a 25 ft × 18 ft sand pit filled with approximately 2.5 ft of sand, and floor-to-ceiling simulated rock walls ~18 ft high x 35 ft long. The DHB presents a large open volume which, in addition to the sand pit and rock walls, contains structural elements, experimental infrastructure, and overhead equipment that must be modeled.

1.03.1.2 Littoral High Bay (LHB), with simulated coastal and shallow-water environments for testing maritime and amphibious autonomous systems, which has approximate dimensions of 54 ft × 76 ft × 28 ft. Within the LHB, there is a 45 ft × 25 ft pool approximately 5.5 ft deep with a 16-channel directional wave generator. The

LHB presents a large open volume and, in addition to the pool, contains structural elements, experimental infrastructure, and overhead equipment that must be modeled.

1.03.1.3 Prototyping High Bay (PHB), a reconfigurable experimental space with approximate dimensions of 150 ft × 75 ft × 30 ft used for the development and evaluation of autonomous systems including aerial vehicles, ground vehicles, and human-system interaction experiments. The PHB presents a large open volume containing various structural elements, experimental infrastructure, and overhead equipment including, but not limited to, windows and doors, wall and ceiling mounting members, modular wall structures, lighting, speakers, cameras, overhead crane, and tables and chairs, that must be modeled.

1.03.1.4 Tropical High Bay (THB), a greenhouse environment designed to replicate a

Southeast Asian rainforest ecosystem with overall room dimensions of approximately

60 ft × 40 ft × 46 ft. The THB contains dense tropical vegetation with multi-level canopy structure, natural terrain including a waterfall, stream and pond, rain and fog generation systems, and temperature and humidity control, that must be modeled.

1.03.2 The models will utilize scans of the environments provided in E57 and OBJ file formats to the vendor by NRL.

1.03.3 During model creation, evaluations will be performed to ensure the provided scan data matches the actual environments. Identified issues and inaccuracies will either be corrected, with the vendor either performing manual edits to the scan files or requesting rescans from

LASR staff.

1.03.4 The models shall create and label separate components within each environment for distinct elements and features, and shall annotate those components with physical attributes include color and other material properties that are parameterized based on known material property data, vendor observations and NRL user input.

1.03.5 Components within the environments to model shall include, but are not limited to:

1.03.5.1 terrain (flooring, sand, rocks, mud, water)

1.03.5.2 wave generation system

1.03.5.3 trees and other plants

1.03.5.4 various wall, ceiling and window surfaces

1.03.5.5 water tanks

1.03.5.6 overhead cranes

1.03.5.7 tables, chairs and shelving

1.03.5.8 lights

1.03.6 The model component parameters shall be capable of tuning and additional modification by the end user and system administrators.

1.03.7 The models shall be provided in OpenUSD format compatible for use in Omniverse libraries and microservices.

1.03.8 The models shall be delivered and uploaded to a dedicated host computer at NRL’s

LASR facility, and integrated with Omniverse libraries and microservices.

1.04 RAS Platforms Model Specification:

1.04.1 Models shall be developed of commercially available RAS platforms that will be deployed in the LASR environments including at least one ground vehicle and one underwater vehicle to be specified by NRL users in discussion with vendor.

1.04.2 The models shall include all relevant properties to accurately capture the dynamics of the RAS platforms. These properties include, but may not be limited to:

1.04.2.1 mass and volume

1.04.2.2 centers of mass and buoyancy

1.04.2.3 moments of inertia

1.04.2.4 joint and actuator dynamics

1.04.2.5 friction and drag representations

1.04.2.6 control authority

1.04.2.7 embedded sensor representations

1.04.3 The models shall accurately represent the appearance of the physical RAS in shape, color and texture.

1.04.4 The models, comprising sensors, actuators and manipulators, shall all be modular allowing for components to be added or removed from a platform.

1.04.5 The models shall be provided in OpenUSD format compatible for use in Omniverse libraries and microservices.

1.04.6 The models shall be delivered and uploaded to a dedicated host computer at NRL’s

LASR facility, and integrated with Omniverse libraries and microservices.

1.05 Utilities and Helper Modules Specification:

1.05.1 A suite of tools (utilities, plug-ins and helper functions) that support configuration and testing of the system shall be developed to include:

1.05.1.1 Observations logging for debugging and fine tuning the physics models.

1.05.1.2 Command line interface, visual interface, and configuration files for changing simulation and model parameters.

1.05.1.3 Graphical user interface for setting parameters and scenario configurations.

1.05.2 The tools shall be provided in OpenUSD format compatible for use in Omniverse libraries and microservices.

1.05.3 The tools shall be delivered and uploaded to a dedicated host computer at NRL’s LASR facility, and integrated with Omniverse libraries and microservices.

1.06 Test and Validation Specification:

1.06.1 Any data from observations of platform-environment interactions collected by NRL personnel and provided to the vendor prior to final delivery of the Digital Twin shall be used to validate and appropriately tune the platform and environment models.

1.06.2 Data used for validation and tuning may include, but is not limited to, platform and environment sensor measurements and outputs, and RAS commands and control inputs.

1.06.3 For each test case for which observations are provided, a test script shall be developed and executed to simulate the same test case in the Digital Twin and record the simulated effects and observations.

1.06.4 For each test case, discrepancies between the physical and virtual environments will be corrected and a new simulation completed in the Digital Twin demonstrating improvement in accuracy.

2 Documentation:

2.01 The vendor shall supply a complete digital set of technical and user documents with the

Digital Twin upon delivery to include:

2.01.1 System Specifications

2.01.2 Code Documentation and Annotation

2.01.3 Test Results and Analysis

2.01.4 Final Report and Presentation of Findings/Results

2.01.5 Operation Manuals

2.01.6 Maintenance Manuals

3 Project Planning and Support:

3.01 Vendor will participate in an initial kick-off meeting to establish a detailed plan, schedule and tasks for the vendor to perform in creation of the Digital Twin.

3.02 Vendor will develop a software module description for the Digital Twin based on establish functional requirements. This software module description will consist of tools, plugins and microservices to support functionalities including, but not limited to, model import and synthesis from scans, model update scripts, automated test and validation scripts, and user interfaces for model edits, among others.

3.03 Vendor will complete any necessary paperwork for facility and computer system access.

3.04 Vendor will periodically, at intervals of no less than one month, meet with NRL LASR staff to review progress, request feedback, and plan next steps of Digital Twin development.

3.05 Vendor will make timely requests for data from NRL LASR staff to facilitate validation and modification of Digital Twin models.

3.06 Upon contract award and through final delivery and acceptance of the Digital Twin, the vendor must provide technical support to users testing early versions of the Digital Twin made available by the vendor.

4 Final Acceptance:

4.01 Final acceptance of the Digital Twin shall occur once the delivered models, tools and documentation that satisfy the requirements of this specification are uploaded and tested on

LASR hardware and any identified deficiencies have been resolved.

Questions:

1. Are there non-commercial barriers that could be removed (e.g., Government clauses) or modifications to the requirement (e.g, contract-type) that would improve how your company delivers these R&D services to the DoD?

2. Does your company offer the same R&D services for this requirement to commercial/non-

Government customers for similar applications?

2.a. If so, does your company offer commercial pricing for these same R&D services for similar applications (e.g, catalog or market pricing)?

3. Does your company identify these R&D services requirements as being specific to the

Government or does your company primarily identify these DoD-specific requirements as commercial?

4. Does your company currently possess a Governmentwide contract capable of fulfilling this requirement? If yes, please provide the applicable contract number.

5. Indicate whether your company can fulfill this requirement commercially?

Submission Instructions:

Please DO NOT include any classified information. Interested parties should provide written responses to the Sources Sought Notice, and the attached Statement of Work to the Contract

Specialist: Daniel St. Denis, daniel.l.stdenis.civ@us.navy.mil.

In accordance with FAR Subpart 10.001, this market research is conducted solely to inform the

Government's acquisition strategy and participation in this market research is entirely voluntary.

Your decision to respond or not respond to this Sources Sought Notice will have no bearing on your eligibility for or evaluation in any future solicitation related to this requirement. Non-response will not be considered negatively in any acquisition decision.