HR001121S0004_RACER_QA_20201120_v2.docx

DARPA TTO Broad Agency Announcement Robotic Autonomy in Complex Environments with Resiliency (RACER)

HR001121S0004

Initial Questions and Answers November 20, 2020

IN THE EVENT OF ANY INCONSISTENCY BETWEEN THE ANSWERS PROVIDED

HEREIN AND THE SOLICITATION, THE SOLICITATION SHALL TAKE PRECEDENCE

Initial Questions and Answers by Topic Area:

Proposers Day

Q1: Is this attendee list the primary partnering mechanism? I missed the first part of the telecon

A1: Yes, the Proposers Day attendee list has been posted as an attachment to the RACER BAA.

Q2: Will a Proposers Day attendee list be available?

A2: Yes, the Proposers Day attendee list has been posted as an attachment to the RACER BAA.

Q3: Will the Proposers Day slides be available after the presentation?

A3: The Proposers Day slides have been posted as an attachment to the RACER BAA.

Q4: Will there be a download of the Proposers Day presentation during the meeting or will it be sent out separately?

A4: No, the Proposers Day slides have been posted as an attachment to the RACER BAA.

Abstracts

Q5: Should the abstract response include a ROM? If so, do you want a ROM for both Phase 1 and Phase 2?

A5: A ROM is not required for the abstract. Please refer to RACER Section IV.B.1 for the abstract format.

Q6: The BAA states that the page limit is 5 however the bracketed numbers for abstract sections total 6. Is 5 pages the limit for the abstract?

A6: Bracketed numbers before each section denote recommended page limits for the proposal (RACER BAA Section IV.B.2). The bracketed numbers do not apply to the abstract.

Q7: The instructions for the abstract indicate that we should address the following key areas AND that we should follow the general format of section II in the Technical and Management volume:

My question is whether or not we also need to address all of the information/ instructions included in sections A-D of "section II" of the technical and management volume (which seems to require much more detail than the key areas listed in the abstract instructions)?

At this time, we are planning on only addressing the key areas listed in the abstract submission section of the BAA (generally formatting this to follow section II of the tech. volume), based on the BAA guidelines - is this the correct approach?

Any advice you can provide would be greatly appreciated.

A7: This is a correct approach for the abstract as recommended in Section IV.B.1. Proposers are free to use whatever approach they believe works best for them.

Awards

Q8: Are the three anticipated awards for all Phase 1 performers or just platform-based teams?

A8: Yes, up to 3 awards are anticipated for platform-based teams under this BAA.

Q9: Can you clarify that that the upcoming BAA is only Phase 1?

A9: Per RACER BAA Section I.C, "This BAA solicits proposals for Phase 1."

Q10: Is all of the $19.5M budget available for funding performers or does it also have to cover Gov't-side support expenses?

A10: Yes, the total amount anticipated to be awarded, $19.5M, is for performers. It does not have to cover Gov't-side support expenses.

Q11: how does early RACER solicitation relate to (ii) simulation and (iii) long range planning solicitations? are they coupled? how so?

A11: Each BAA is an independent solicitation.

Eligibility & Teaming

Q12: Are current performers on this technology considered eligible on RACER?

A12: Yes, Performers on other contracts are eligible to propose.

Q13: Can team composition change between Phase 1 and Phase 2

A13: Yes, team composition is unconstrained between Phase 1 and Phase 2.

Q14: On page 47 of the RACER BAA, it states:

"Collaborative efforts/teaming are encouraged. Interested parties should submit a one-page profile with their contact information, a brief description of their technical capabilities, and the desired expertise from other teams, as applicable."

How shall the one-page profile be submitted? On the baa.darpa.mil <http://baa.darpa.mil> submission site, there are only options to submit an abstract or a full proposal. Thanks.

A14: The one-page profile can be submitted by emailing it to HR001121S0004@darpa.mil as an attachment with "One-Page Profile" as the subject line. These must be received by the question deadline and they will be published along with the Q&A.

Q15: We're on a team that is planning to propose to the recently released BAA for RACER. But we're also interested in the "Simulation-Developed Autonomy and Toolsets" opportunity that was mentioned in the RACER Proposers' Day, if and when a subsequent BAA is released. Do you anticipate there being any constraints on a single org participating in both the physical and virtual tracks of the program?

A15: DARPA anticipated releasing a separate simulation BAA, hopefully soon. There will be no constraints on organizations participating in both BAAs.

Q16: Omitted

General

Q17: Are improvements in perception capability (using provided sensors) a focus of RACER, or is that out of scope?

A17: DARPA is interested in improvements in perception capabilities. However, DARPA anticipates perception capability is only one area of improvement that will be required to reach the program metrics.

Q18: will ARL be primary agent for transition from RACER to Army?

A18: At this time, no primary agent for transition has been selected.

Q19: From an acquisition point of view, what are your thoughts on long-term software upgrades independent of electronics hardware lifecycles?

A19: Opinion: Software upgrades that are independent of electronics hardware lifecycles would be desirable to rapidly and continuously update autonomy software.

Q20: Are you interested in a partial / niche technology proposal or only complete solution proposals?

A20: The current RACER BAA referenced is interested in complete solutions to achieve Phase 1 metrics.

Focus

Q21: Are multi-vehicle operations as important as single AGV operations?

A21: No, RACER is focused on providing foundational autonomy for single UGV mobility.

Q22: Could you elaborate on the complexity of the tasks that such a platoon should perform?

A22: No, RACER is focused on providing foundational autonomy for single UGV mobility.

Q23: Do you have a sense of manned - unmanned vehicle ratios in formation?

A23: No, we do not have a sense of manned - unmanned vehicle ratios in formation. RACER is focused on providing foundational autonomy for single UGV mobility.

Q24: Do you think that adversarial machine learning are potential threat to consider?

A24: This is not a focus of this RACER BAA.

Q25: How does this capability tie into AI for Small Unit Maneuver?

A25: There is no tie to AI for Small Unit Maneuver. RACER is focused on providing foundational autonomy for single UGV mobility.

Q26: It's possible that RCVs will autonomously operate better than humans in some ways, and worse in others. Would this create problems for transition? Or is it a higher priority to have RCVs try to emulate human driving more directly?

A26: Yes, we anticipate this. Our goal for transition is to provide a reliable autonomous movement and maneuver for the Army, to include understanding its limits and performance. For maneuver, we seek to use the terrain to drive like Soldiers, but this RACER BAA is focused on movement.

Q27: Could you talk about the role you see the autonomous subsystems have in engagement/combat; or is the current focus primarily on movement/transport?

A27: RACER is focused on providing foundational autonomy for single UGV mobility. A future global planning and tactics BAA is anticipated. Autonomy for engagement/combat is not a focus of this RACER BAA.

Q28: What unit size will these vehicles be attached to? (Platoon? Battalion?) Is the RCV-light "light" enough to be attached to only a platoon?

A28: The RACER program does not include consideration of the unit size these vehicles will be attached to nor whether the RCV-light is "light" enough to be attached to only a platoon. RACER is focused on providing foundational autonomy for single UGV mobility.

Other Programs

Q29: Are there plans to transition technology from the DARPA SubT Challenge?

A29: No, there are no plans to transition technology from the DARPA SubT Challenge

Q30: How does RACER nest with AFC Project Convergence demonstration goals? Specifically, “collaborative teaming and autonomous maneuver of air and ground platforms?”

A30: RACER is not currently part of the AFC Project Convergence demonstrations. RACER is DARPA program to develop a foundational capability for single UGV autonomy.

Q31: How will RACER inform experimentation in support of RCV Phase 2, ATEC safety testing, the build of Phase 2 light and medium RCV platforms, and virtual experimentation of RCV platforms to inform an RCV decision point in FY22.

A31: RACER is not currently part of the RCV program. RACER is a DARPA program to develop a foundational capability in single UGV autonomy.

Q32: Will groups be working closely with the DCIST CRA? Or will awardees be independent from that?

A32: The RACER awardees will be independent from DCST CRA. Proposers can identify anticipated benefits from cross collaboration with other programs.

Global Planning and Tactics

Q33: Anything to share on prior wartime damage, presence of adversaries.

A33: Not at this time.

Q34: How will “autonomous mobility” account for non-terrain features of the environment? Specifically, the enemy, friendly forces, and commander’s acceptable level of risk?

A34: RACER intends to provide foundational autonomy for single UGV mobility.

Q35: What are your expectations regarding robotic use of terrain to achieve cover and concealment coming out of this?

A35: This is not a focus of this RACER BAA.

Q36: Will field experiments include potentially hostile areas to be autonomously avoided by the platform?

A36: This capability will not be emphasized in Phase 1 but may be incorporated for Phase 2.

Q37: when do you anticipate global planning BAA to be out?

A37: There is no anticipated date for the future global planning and tactics BAA at this time.

Q38: It sounds like the vision is a common architecture for several platforms, so is relaying information from other UGVs in the area of operation about their observations of the terrain, threats, obstacles, mapping etc. important?

A38: This is not a focus of this RACER BAA. RACER is focused on providing foundational autonomy for single UGV mobility.

Environment

Q39: Are all-weather impacts a concern?

A39: All-weather impacts are a specific concern. RACER anticipates testing throughout the year. Please refer to the RACER BAA for the anticipated DARPA-hosted field experiment locations. RACER does not anticipate researching specific weather conditions. Daytime conditions are anticipated.

Q40: How much of a focus is on withstanding all kinds of weather conditions (e.g., fog, snow, etc.)

A40: Weather is not a focus. RACER anticipates testing throughout the year. Please refer to the RACER BAA for the anticipated DARPA-hosted field experiment locations. RACER does not anticipate researching specific weather conditions. Daytime conditions are anticipated.

Q41: Are you interested in Cold Regions Complex Terrain capabilities?

A41: We are not specifically interested in cold terrain, though it could be encountered. RACER anticipates testing throughout the year. Please refer to the RACER BAA for the anticipated DARPA-hosted field experiment locations. RACER does not anticipate researching specific weather conditions. Daytime conditions are anticipated.

Q42: Anything to share on environmental challenges, e.g., weather, nighttime ops?

A42: RACER anticipates testing throughout the year. Please refer to the RACER BAA for the anticipated DARPA-hosted field experiment locations. RACER does not anticipate researching specific weather conditions. Daytime conditions are anticipated.

HMI

Q43: Will RACER solutions be required to interface with Common Robotic System–Individual?

A43: No, RACER does not have requirements to interface with Common Robotic System-Individual. Human interaction is not a focus of this RACER BAA.

Q44: What sort of input or instruction level should the vehicle handle? In other words: How do you envision the way soldiers communicate the strategy to move, engage, etc. to the autonomous vehicle?

A44: Please refer to the RACER BAA for information on how courses will be provided via waypoints. Human interaction is not a focus of this RACER BAA.

Maneuvering

Q45: Can you describe for the group in more detail the difference between movement and maneuver?

A45: A definition can be found in COL Sponslers portion of the Proposers Day briefing. Movement = go from a to b. Maneuver is use the terrain to accomplish a movement.

Q46: How will the focus on “off-road” maneuver translate to maneuver in a complex urban environment?

A46: No translation to a complex urban environment is planned. The RACER BAA is focused on the off-road environment.

Metrics

Q47: How much consideration is given to "correctness-by-design" versus robust performance during field tests in Phase 1?

A47: "Correctness-by-design" is not a consideration. Please refer to BAA Section I.D, Program Metrics and Performer Evaluation.

Q48: Will the metrics deal with simply forward speed, or is time required to get from waypoint to waypoint really what's important?

A48: Please refer to BAA Section I.D, Program Metrics and Performer Evaluation.

Q49: Given the target off-road domain, agility demand, and autonomy focus, will there be substantial emphasis on robust mobility behaviors for autonomously getting out of tough situations (stuck vehicle, excessive traction loss, etc.)?

A49: Not exclusively. RACER is focused on metrics for average speed over a course. While getting out of tough situations is not a specific focus of the RACER program, being able to get out of tough situations will improve average speed and help complete experiment runs.

Safety

Q50: Will human intervention be needed on the platform to address safety concerns?

A50: Performers will not need to plan for a safety driver on the platform. DARPA and performers will be able to intervene with the system through an add on capability.

Q51: Will there be safety measures built into the platform by-wire systems (driver over-ride, e-stops, wireless stop...) to facilitate safety during development?

A51: Yes, safety measures are anticipated to be built into the platform.

Security

Q52: Can you advise if foreign nationals are able to attend the project events and work on the integrated system for this project?

A52: Foreign nationals can attend project events during the unclassified, non-CUI portion of the events. The complete, assembled autonomy stack software code that is developed under the RACER program will be CUI.

Q53: Would the software stack be available under ITAR or CUI, or FOUO ?

A53: The optional baseline autonomy stack will be unclassified. Please refer to the Security Classification Guide for the RACER program security requirements.

GFX

Q54: What is the data collection architecture?

A54: Please refer to RACER BAA Section VIII.C.3 for information on the GFX

Q55: What is the definition of GFX?

A55: The RACER BAA uses the abbreviation GFX to collectively represent Government Furnished Equipment (GFE) and Government Furnished Information (GFI)

GFX - Dataset

Q56: Is the data in the dataset labeled in some way?

A56: Details for the anticipated GFX are outlined in the RACER BAA. Features such as labeling are anticipated.

Q57: How much vehicle data will be available in real time (e.g., encoders, engine data)?

A57: Please refer to RACER BAA Section VIII.C.3.a for information on the baseline sensor package. Data from these sensors is anticipated to be provided in real time.

GFX - Modifying

Q58: Can we add more compute to the platform if necessary?

A58: No, not unilaterally. Per the RACER BAA Section VIII.C, "Performers are permitted to request modifications or enhancements to the GFX. Should DARPA approve a request, the modifications or enhancements will be applied to the GFX of all performers."

Q59: Will vehicle modifications be allowed?

A59: No, not unilaterally. Per RACER BAA Section VIII.C, "Performers are permitted to request modifications or enhancements to the GFX. Should DARPA approve a request, the modifications or enhancements will be applied to the GFX of all performers."

GFX - Stack

Q60: Do teams have to use the DARPA-provided software or can teams use their own autonomy stack?

A60: Teams are welcome to use their own autonomy stack. For details of the DARPA-provided software, please refer to the RACER BAA Section VIII.C.3.

Q61: How does the ARL stack relate to ROS-M?

A61: Please refer to RACER BAA Section VIII.C.3.

Q62: Is there a common operating system or common computing environment beyond ROS-M?

A62: Please refer to the RACER BAA Section VIII.C.3 for information on the baseline autonomy stack that is anticipated to be provided as part of the GFX.

Q63: Is there a description of the DARPA-provided software and autonomy stack that I can consult in order to develop my proposal?

A63: Yes, please refer to RACER BAA Section VIII.C.3.

Q64: What license will be distributed with the RACER GFX software?

A64: The licensing specifics have not yet been determined. Performers will be able to use the optional baseline autonomy stack code throughout the program.

Q65: Will there be updates on the baseline autonomy stack over the course of the program? Will there be drivers for new sensors?

A65: An optional baseline autonomy stack will be provided. It is possible updates to the optional baseline autonomy stack or its components may be made over the course of the program. There will be drivers for new sensors that DARPA chooses to add to the sensor package.

Q66: Would we be able to take a look at the codebase before submitting a proposal?

A66: No. Please refer to RACER BAA Section VIII.C.3 for a description of the autonomy stack.

Q67: If a company has developed applicable software that is not currently running on ROS, is DARPA still interested in receiving a response? Will their software be required to be ROS-compliant?

A67: Yes, DARPA is interested in receiving a response. Per the RACER BAA, use of the baseline autonomy stack is optional. There is no requirement for ROS-compliance. Note that the onus will be on the performer to ensure its applicable software functions on the GFX vehicles. In addition, Section I.E.2, Deliverable, states "DARPA requires the complete autonomy stack and all algorithm source code be provided to the RACER Code Repository."

GFX - Vehicles

Q68: Are the RCV specs negotiable or fixed?

A68: Please refer to the RACER BAA for information on anticipated GFX.

Q69: Can we obtain the maintenance requirements for the MRZR to aid in pricing?

A69: The vehicle has not yet been selected. Therefore, this information is not available.

Q70: Can you address vehicles for Phase 1 & Phase 2?

A70: Please refer to RACER BAA Sections VIII.C.1 and VIII.C.2 for information on the vehicles.

Q71: Do we assume that the vehicle platforms are available and ready for development at the kick-off date?

A71: Please refer to RACER BAA Section VIII.C.1 for information on anticipated vehicle availability.

Q72: Is autonomous reverse operation implemented as part of the GFX?

A72: Reverse is anticipated to be implemented on the GFX vehicles.

Q73: It sounds like to achieve robustness and fast development you would need significant stress testing to identify and fix anomalies before fielding. How is the program planning to meet their stress testing needs?

A73: DARPA will provide platforms, data and baselines as part of the GFX per RACER BAA Section VIII.C. No stress testing is planned.

Q74: What are the assumptions of the vehicle dynamics? Path feasibility will depend on the vehicle dynamics and the terrain it is capable of navigating.

A74: Please see the RACER BAA for information on the anticipated RACER platforms. A dynamics model is anticipated to be provided part of the GFX.

Q75: When will the outfitted vehicles be ready for use?

A75: Please refer to RACER BAA Section VIII.C.1 for information on anticipated vehicle availability.

Q76: Will each MRZR already be equipped with the sensors and computing hardware when delivered? Will the on-board software already be installed? Will the full up autonomous vehicle (i.e. integrated platform, sensors, computers and the Baseline Autonomy Stack) be tested prior to shipment?

A76: It is planned that LTATVs will be already equipped with the sensors and computing hardware. It is planned that the on-board software will already be installed. It is anticipated that there will be acceptance testing prior to shipment.

Q77: Will the platforms have active suspension technology? Will they be able to sense suspension travel and individual wheel odometry?

A77: In Phase 1 the system will not have active suspension. In Phase 2 they may. Wheel odometry sensing will be provided.

Q78: Will you provide multiple vehicles to each prime for test and evaluation?

A78: Yes, details for anticipated GFX are outlined in the RACER BAA. Risk with platform performance and the availability for uptime should be properly balanced in proposals.

Sensors

Q79: Are sensors fixed or are steering and zooming decisions in RACER’s scope?

A79: Sensors are anticipated to be fixed.

Q80: Are there plans to add a Barometer to the sensor system that has been proposed for the GFX? If not, can we request to install one as part of the sensor systems for the vehicle?

A80: Thank you for the suggestion. We will take this request into consideration.

Q81: Can you comment on the importance of sensors? Software is vital, but it relies on sensor data.

A81: Yes, sensors are important. Sensors are not a developmental item in RACER. Please refer to the RACER BAA for information on the anticipated sensors.

Q82: Can you suggest an example LWIR make and model as was done for the other sensors?

A82: At this time, we cannot suggest an example LWIR make and model. We are in the process of finalizing the baseline sensors.

Q83: Do new sensor requests need to be articulated in proposals or prior to?

A83: New sensor requests can be articulated in the proposal.

Q84: Does the sensor platform include an IMU? And are there any vehicle diagnostic sensors available, such as wheel speed sensors, engine RPM, etc.?

A84: Please refer to the RACER BAA Section VIII.C.3 for information on the anticipated baseline sensor package.

Q85: There seems to be discrepancies regarding stereo camera placement and count. Page 10, Figure 3 states “two pair in front and rear, one pair on either side.” Page 49 states that 3 stereo cameras will be placed in the front and there is only a provision for the 4th, rear-facing camera. What is meant by “provision for” and what is the likely placement of the cameras?

A85: Thank you for pointing out the discrepancies. We are in the process of finalizing the baseline sensors. The configuration could be either one of these configurations or a different one.

Q86: With moisture content being such a challenge, has any attempt been made to integrate sensors that can detect soil moisture content?

A86: No. Moisture content sensors will not be provided.

Q87: I think there could be significant value to adding LWIR sensors at least in the forward direction. They should have a view of the ground in front of the vehicle up to the horizon, with at least a 90 degree wide combined field of view. This would help with navigation at night, and aid classification of objects.

A87: Thank you for the suggestion. We are in the process of finalizing the baseline sensors.

Q88: Is the simulator software open sourced ?

A88: No, the simulator software will not be open sourced. An optional baseline simulator software will be provided as part of the GFX.

Q89: In response to your ask for recommended modifications to the RACER GFX sensor suite during the Proposers’ Day, we’d like to request a multispectral (or at least Near-IR) camera to facilitate detecting vegetation and water. Something along these lines would be great: https://micasense.com/rededge-mx/

A89: Thank you for the suggestion. We appreciate your input.

Sensors - Active

Q90: Do you have any stealth concerns, active sensors versus passive sensors to achieve autonomy?

A90: No, RACER does not have an active/passive detection metric. Please see the RACER BAA for information on the anticipated sensors.

Q91: How do you see the need to limit emissions for autonomy. Is radar out? Lidar out? what else is too detectable?

A91: RACER is not constrained by emissions limits. Please refer to the RACER BAA for information on the anticipated sensors.

Q92: Not using active sensors limits emissions but also degrades information available to the system. Is sparingly use of active sensors acceptable?

A92: Yes, the use of active sensors is acceptable. Full time use is acceptable. Please refer to the RACER BAA Section VIII.C.3 for information on the anticipated baseline sensor package.

Simulation

Q93: Are you planning to use M&S yourself or are you expecting the autonomy software developer to do so?

A93: The autonomy software developers are anticipated to use M&S, though this is not required. An optional M&S environment is anticipated to be provided as part of the GFX. The use of this GFX M&S is optional (repeated for emphasis). Please see the RACER BAA for detailed information on GFX.

Q94: Do you plan to stick with the Unity-based simulation?

A94: A optional baseline Unity-based simulation is being offered as part of the GFX. Performers are not required to use this Unity-based simulation.

Q95: Is simulation in both the RACER BAA effort, and the upcoming Simulation BAA?

A95: Stand-alone simulation opportunities are anticipated to be part of a separate, future simulation BAA. That does not preclude simulation use on this RACER BAA, but it is not the primary focus of this RACER BAA. That does not preclude proposers from using simulation tools. No reason to assume performers cannot use simulations.

Q96: Since the simulation-focused track will be the subject of a separate BAA, can you discuss the relationship between that simulation BAA and the RACER BAA? Will field testing results be made available for model validation?

A96: As part of the GFX, DARPA intends to provide initial datasets to the performer teams. RACER BAA performers and Simulation BAA performers will be provided opportunities for dialogue, especially in relation to Phase II. GFX data and GFX platform models, will be expanded and/or refined as appropriate. It is not anticipated that individual performer data will be shared with other performers unless there is agreement to do so.

Q97: Will DARPA provide development tools for stimulating the autonomy stack with the simulated sensor inputs?

A97: Yes, with the Unity sim. We regularly run the stack together with sim on a Dell XPS15 laptop with an i7 and GTX1050. This does not include running many of the CNN-based perception capabilities and instead using ground-truth segmentation and object detection. Using a capable GPU (we use an eGPU) would let the perception also be run at the same time. Please refer to RACER BAA Section VIII.C.3.

Q98: Will there be an opportunity to add capabilities to the simulator?

A98: Yes, there are no restrictions on adding capabilities to the simulator.

Q99: What capabilities are available for vehicle simulation, tire-terrain interaction for soft soil in the simulation platform?

A99: The current state of the simulator is chiefly focused on perceptual data generation with less emphasis on physics fidelity. The physics is currently what is included with the Unity engine and not any separate physics libraries. Detailed tire-terrain interaction for soft soil is not modeled at this time.

Field Experiments

Q100: How many vehicles of each type are performers required to transport to the DARPA Field Experiment sites for each Phase? Is there a maximum number?

A100: There is no required number of vehicles to be transported to the DARPA-hosted field experiments. There is no maximum number.

Q101: Is there assumptions that we could make about the networking infrastructure ?

A101: Please refer to the RACER BAA for information on anticipated networking infrastructure for the DARPA-hosted field experiments.

Q102: Will DARPA provide continuous access to test ranges?

A102: No. DARPA will provide access to them as indicated in the RACER BAA Section II.F, DARPA Hosted-Field Experiments.

Q103: Will the vehicles include a standardized telemetry system for transferring data back to the team in real-time, either for development or evaluation purposes?

A103: Yes, a standardized, real-time telemetry system is anticipated to be included.

Q104: Will the waypoints be physical fiducials present in the environment?

A104: No, waypoints will be provided as GPS coordinates. Please refer to RACER BAA Section I.E.1

Q105: Could you give some more information about the terrain and its constraints

A105: Please refer to the RACER BAA for information on the anticipated terrains.

Field Experiments - Allowable

Q106: How important is GPS-denied navigation capability to your teamed autonomous operations in needs in off road conditions?

A106: Please refer to the RACER BAA for information on GPS conditions.

Q107: How important is it to not rely on precomputed terrain maps?

A107: Please refer to the RACER BAA for information on map reliance. Reduced map reliance is anticipated in Phase 2.

Q108: Will historical information be allowed to be used? I.e. 2nd runs would have stored data from 1st run?

A108: This is specifically not allowed. Please refer to RACER BAA Section I.E.1

Field Experiments - Performer

Q109: The 5th paragraph of Evaluation Criterion A.1 states that “The Government will review the proposer’s approach for independent assessment of performer-hosted demonstrations…” This is the first and only mention of bidders needing to provide a capability for conducting an independent assessment of their own demonstrations. To help bidders properly quote such a capability can DARPA provide additional information on their expectations for this role and what qualifies as “independent”?

A109: "Independent assessment" in this context is meant to be assessment independent of DARPA. This could instead have been written, "The Government will review the proposer's approach for self-assessment during performer-hosted demonstrations."

Q110: What are DARPA's expectation regarding the physical experiments that performers may propose to demonstrate capabilities?

A110: DARPA does not have specific expectations regarding the physical experiments that performers may propose to demonstrate capabilities. Performers should propose experiments that they believe will demonstrate capabilities.