BAA12-02 Phoenix Amendment 1 Jan 20 2012.pdf

Broad Agency Announcement

Phoenix Technologies

Tactical Technology Office (TTO)

DARPA-BAA-12-02

December 22, 2011

Table of Contents:

Part I: Overview Information………………………………………….…………………..…… Part II: Full Text of Announcement Sec. I: FUNDING OPPORTUNITY DESCRIPTION… Sec. II: AWARD INFORMATION……………………………………….……….…….27 Sec. III: ELIGIBILITY INFORMATION………………………….…….………...…

A. Eligible Applicants B. Procurement Integrity, Standards of Conduct, Ethical Considerations, and

Organizational Conflict of Interest C. Cost Sharing/Matching

Sec. IV. APPLICATION AND SUBMISSION INFORMATION…………….….….…30 A. Address to Request Application Package B. Content and Form of Application

Submission Sec. V. APPLICATION REVIEW INFORMATION……………………...……..…

A. Evaluation Criteria B. Review and Selection Process

Sec. VI. AWARD ADMINISTRATION INFORMATION…………….…..….....…..…44 A. Selection Notices B. Administrative and National Policy Requirements C. Reporting D. Electronic Systems

Sec. VII. AGENCY CONTACTS………………………………………..…………...…51 Sec. VIII. OTHER INFORMATION……………………………………….……..…….52

A. Intellectual Property B. Non-Procurement Contract Proposers – Noncommercial and Commercial

Items (Technical Data and Computer Software) C. All Proposers – Patents

APPENDIX 1: FREND Technical Interface Information………………………………………55

APPENDIX 2: Servicer/Tender Bus to Toolbelt Interface Information ….………….…………61

Part I: Overview Information

Federal Agency Name – Defense Advanced Research Projects Agency (DARPA), Tactical

Technology Office (TTO) Funding Opportunity Title – Phoenix Technologies Announcement Type – Initial announcement Funding Opportunity Number – Broad Agency Announcement DARPA-BAA-12-02 Catalog of Federal Domestic Assistance Numbers (CFDA) – Not Applicable Dates o Posting Date: 22 December 2011 o Questions Due Date: 5 January 2012 o Proposal Due Date: 6 February 2012

Description of the funding opportunity: The goal of the Phoenix program is to develop and demonstrate technologies to cooperatively harvest and re-use valuable components from retired, non-operating satellites in geosynchronous orbit (GEO) and demonstrate the ability to create new space systems at greatly reduced cost. Phoenix seeks to demonstrate around-the-clock, globally persistent communication capability for warfighters more economically, by robotically removing and re-using GEO-based space apertures and antennas from de-commissioned satellites in the graveyard or disposal orbit. The Phoenix program envisions developing a new class of small ‘Satlets’, or nano satellites, which could be sent to the GEO region more economically as a “ride along” on a commercial satellite launch, and then attached to the antenna of a non-operational cooperating satellite robotically, essentially creating a new space system. A payload orbital delivery system, or PODS, will also be designed to safely house the Satlets for transport aboard a commercial satellite launch as a hosted payload. A separate on-orbit ‘tender,’ or satellite servicing spacecraft is also expected to be built and launched into GEO. Once the tender arrives on-orbit, the PODS would then be released from its ride-along host and link up with the tender to become part of the satellite servicer’s ‘tool belt.’ The tender plans to be equipped with grasping mechanical arms for removing the Satlets and components from the PODS using unique robotic tools to be developed in the program. The traditional process of designing, developing, building and deploying space technologies is long and expensive. Through Phoenix, DARPA seeks to hasten the insertion of emerging technologies into space system development at much lower cost.

Total amount of money to be awarded - Approximately $36M Anticipated individual awards – Multiple awards are anticipated.

Types of instruments that may be awarded -- Procurement contract, other transaction.

Any cost sharing requirements - None Agency Technical contact -

Mr. David Barnhart

DARPA/TTO

ATTN: DARPA-BAA 12-02

3701 North Fairfax Drive Arlington, VA 22203-1714

FAX: 703-812-3303

EMAIL: DARPA-BAA-12-02@darpa.mil

Part II: Full Text of Announcement

I. FUNDING OPPORTUNITY DESCRIPTION

DARPA often selects its research efforts through the Broad Agency Announcement (BAA) process. The BAA will appear first on the FedBizOpps website, http://www.fbo.gov, then the agency website, http://www.darpa.mil/Opportunities/Solicitations/TTO_Solicitations.aspx. It is anticipated that multiple BAA’s will be provided for this program. A bidder’s library with relevant information to the Phoenix project is located at https://www.schafertmd.com/conference/phoenix2011/. The following information is provided to those wishing to respond to this BAA.

Program Introduction The goal of the Phoenix program is to develop and demonstrate technologies to cooperatively harvest and re-use valuable components from retired, nonoperating satellites in GEO and demonstrate the ability to create new space systems at greatly reduced cost. Phoenix seeks to demonstrate around-the-clock, globally persistent communication capability for warfighters more economically, by robotically removing and re-using GEO-based space apertures and antennas from de-commissioned satellites in the graveyard or disposal orbit.

Background High persistence and bandwidth are required for many vital communications missions. A comparison of satellite constellations at low earth orbit (LEO), medium earth orbit (MEO), and geostationary orbit (GEO); fleets of unmanned aerial vehicles (UAV); and unmanned airships, reveals that satellites in the GEO regime provide the most compelling cost-benefit scenario. This is due to the combined effects of persistence enabled at the high GEO altitude and the communications performance gain provided by large radio frequency (RF) apertures. However, the cost of conventional GEO assets is very high relative to lower persistence airborne solutions.

The challenge is to provide ubiquitous GEO-based performance (i.e., the persistence resulting from the high altitude plus the RF gain from a very large antenna) at the cost point of small or nano-satellites or even approaching the cost of a UAV drone.

Retired GEO satellites have already incurred the highest costs in a space system mission life cycle: fabrication, launch, and deployment. With over 1,300 satellites launched to GEO since the 1960’s, it estimated over $300B worth of hardware and approximately 20,000 kg of apertures are in the GEO belt today1. Satellites are retired for a variety of reasons—end of normal lifecycle, exhaustion of fuel, equipment failures, obsolescence—however, typically their mechanical antennas or apertures have no electronics or moving parts that can fail and thus are expected to last many multiples of the original satellite’s lifetime on-orbit. These apertures provide high

1 FAA Commercial Space Transportation historical records. Aperture mass is estimated by taking 1% of GEO satellite launch mass and aggregating.

radio frequency performance gain that can support multiple DoD needs, and their position in GEO translates to high persistence over large areas of the Earth’s surface. In order to take advantage of the high gain and persistence of GEO apertures and the costs already sunk in getting them to GEO, Phoenix will demonstrate repurposing existing apertures in the GEO belt.

The concept behind Phoenix will foster techniques and technologies for unmanned re-use on-orbit2. DARPA expects during the course of the project to understand current policy or legal issues associated with space law that may limit future commercialization of on-orbit servicing activities. Discussions on existing space law guidelines within existing Treaties on use of outer-space, commercial aspects of space salvage, and issues related to indemnification and liability of on-orbit assets relative to themselves or each other may be held during the various phases of the project.

The program will culminate with an on-orbit demonstration in 2015-2016 of at least one successful aperture repurposing demonstrations using a robotic GEO spacecraft. The on-orbit demonstration will take place in both the GEO and super-GEO (or graveyard) orbit, with precise orbit parameters and selection of candidate retired satellites to be determined, and will be approximately six months duration, with a potential subsequent residual capability of up to 48 months.

The Phoenix objective is to develop the techniques and technologies to demonstrate the ability to create a functional communications system using a repurposed GEO aperture. Enabling concepts include:

a) Demonstrate a new concept in satellite design and manufacturing where the concepts of “cellularization” and “morphological reconstruction” are applied to a new satellite construct named a “Satlet”;

b) Demonstrate the ability to launch and dispense on-orbit small mass systems at a high tempo via commercial satellite hosted ride-alongs using a new construct named a payload orbital delivery system or PODs;

c) Demonstrate use of an on-orbit robotic space vehicle capable of reconstituting retired cooperative satellites on-orbit, with a secondary ability to function as a communications relay for the re-purposed antenna(s) named the “Servicer/Tender”;3

Notional Demonstration Scenario Description The DARPA Phoenix demonstration has a number of progressively challenging goals. The entire aperture servicing demonstration sequence is proposed to be executed in a low inclination graveyard orbit to mitigate any potential harm to high value satellite elements in the actual GEO belt. Prior to Phase 1 of the project a Government science team will identify a set of candidates that conform to multiple constraints to include adequate coordination authority, estimated level of rotation or tumble, location in the graveyard orbit at lowest possible Delta-V required from

2 “Can Do versus Do it Yourself”, D. Barnhart, Space News Commentary, Feb 19, 2003, www.spacedaily.com/news/oped-03p.html 3 “Servicer” refers to the GEO capable spacecraft with robotic systems onboard that executes traditional servicing functions, by providing a set of tools and techniques that enables a much larger set of missions and activities on-orbit to an existing satellite system. “Tender” refers to a GEO capable spacecraft that provides support to existing on-orbit systems in the form of standoff RF relay, power beaming, movement of the on-orbit system to various orbital locations, etc.

GEO orbit, relative aperture size, etc. It is anticipated that one full sequence listed below will be performed, with the goal for two sequences on two separate retired satellites, with various size apertures (from 1.5 meter and higher). The successful completion of these on-orbit demos constitute the high-level objective of the program, from which performers are expected to derive system-, subsystem-, and component level objectives.

An initial notional set of demonstration scenarios and mission objectives are outlined below for reference in the BAA solicitations.

1. A demonstration “POD” will be built and loaded into a commercial communications satellite prior to the Servicer/Tender launch. (This POD may carry hardware for use in the baseline Phoenix demonstration mission).

OBJECTIVE: Validation of standards for PODs development, and integration into existing commercial communications satellite(s).

2. The separate Servicer/Tender spacecraft will be integrated and launched to GEO at an orbital location near the POD hosting satellite (launch to be provided by GFE launch services provider). It will then rendezvous to within approximately 1 km of the commercial POD carrier GEO satellite and hold.

OBJECTIVE: Verify operations of Servicer/Tender bus and systems, verify initial validation of the rendezvous proximity operations (RPO) sensor suite and onboard software to a large object (i.e. communications satellite), verify the ability to perform mission operations and flight coordination with a commercial communications satellite.

3. The POD host GEO communications satellite carrier will then execute an “ejection” of a

Phoenix POD while the Servicer/Tender is on station and in view. The Servicer/Tender will then execute a rendezvous maneuver (as needed) to the dispensed POD now in free flight, grapple it with its robotic arm(s)/tool(s), and store it in an onboard tool belt.

OBJECTIVE: Verify Front End Robotics Enabling Near-term Demonstrations (FREND)4 robotic arm operational ability, verify any end effector tool(s), verify ability to capture and store POD safely onto the Servicer/Tender, verify operator in-the-loop tele-presence systems on the ground using suitable interfaces and multiple onboard sensors, verify robust operation of the RPO sensor suite to be used for both large objects (i.e. GEO communications satellite) and small objects (i.e. the POD), verify interaction between a payload operations facility and team and mission operations facility and team, and flight coordination with a commercial communications satellite operations center.

4. The Servicer/Tender will then maneuver away from the POD host GEO satellite carrier via onboard propulsion, execute a maneuver to a GEO Graveyard orbit location (detailed after Phase 1 kickoff), and rendezvous with existing pre-coordinated non-functional

4 The FREND program designed, developed, and demonstrated a robotic arm with a representative capture end effector and control algorithm, which when integrated into a payload system for a servicer spacecraft, would support rendezvous and capture of space assets. See Appendix 1.

cooperating5 retired satellite. Rendezvous maneuvers will be executed to bring the Servicer/Tender to waypoints increasingly closer to the existing satellite asset. The notional waypoints start at ~40 km, and decrease to ~100 m range.

OBJECTIVE: Verify operational capability for the Servicer to execute safe propulsive maneuvers and rendezvous to an existing satellite in a different orbit, verify operation of the RPO sensor suite and software, verify operation of the primary mission operations facility and team.

5. The Servicer/Tender will then close to ~ 1.5 meters to the retired satellite and use the

FREND robotic arm(s) and Phoenix-developed tool(s) to grasp it. Once there, the Servicer/Tender will install a representative Satlet on the body of the retired satellite from the onboard toolbelt.

OBJECTIVE: Verify use of FREND arm(s) and tool(s) for robotic capture of another space object, safe interaction between the payload and mission operations facility and teams, ability for Servicer/Tender to affect positive control on a new kinematic static mass, validate the new coupled dynamics and Servicer/Tender control capability, ability to place a Satlet onto a representative surface on the retired satellite, and ability for the Satlet to grasp and hold onto a separate surface.

Additionally verify the overall concept of operations for opening PODs, pulling Satlets from POD’s, and using multiple arms and tools simultaneously or in conjunction with each other.

6. The Servicer/Tender will then use FREND arm tools to install Satlets around the structure(s) of an existing aperture on the retired satellite. (This step may include the Servicer/Tender having to undock and re-dock to a different point on the retired satellite to allow the FREND arm to reach the aperture, as appropriate). Satlets will then be activated while on the aperture still attached to the retired satellite for test operation, then turned off. The Servicer/Tender will then grapple the boom holding the aperture and use appropriate tool(s) remove the boom from the retired asset.

OBJECTIVE: Validate ability to grasp, release, maneuver, then re-grasp a satellite using the Servicer/Tender sensors and primary robotic arms, validate ability to perform multiple robotic and local situational awareness functions to install Satlets on an existing aperture. Validate the operational capability of Satlets on a retired aperture, the ability to change out tools during a complex robotic operation, ability to use a tool to remove an aperture from existing satellite, and ability to robotically control multiple kinematic masses at one time via a single spacecraft.

7. The Servicer/Tender will then release the retired satellite from its grasp. The Servicer/Tender will maneuver away with the aperture in tow to a suitable distance from the retired satellite. The Satlets will then be re-activated while still attached to the

5 “Cooperating” in this concept means that the DARPA demonstration will conform to the legal laws and guidelines in existing Treaties for use of outer space, and will coordinate with a known country or commercial entity in securing permission to operate near and repurpose any retired satellite component.

aperture, to verify basic functionality, then the Servicer/Tender will release aperture to become free-flying.

OBJECTIVE: Validate ability of the retired aperture to collect RF energy and re-transmit the collected energy to the Tender, and validate the ability to open then close a link with an existing ground communications site. Verify that the Satlets can function aggregated to provide basic attitude control of the now released aperture.

It is envisioned that a “front room/backroom” style flight operations architecture be considered to facilitate both the early ground test, validation and training requirements, as well as actual on-orbit operations. For the bus this is traditionally a single operations center (i.e. front room) to command/control the bus as it would any other GEO orbiting spacecraft. These operations are envisioned to be basic stationkeeping within an orbit, health and status of the Servicer/Tender and associated systems, power balancing, consumable budgets, etc. Typically low rate communications are utilized for these functions. For the payload it is envisioned that a separate payload/tele-robotic location and communications link be enabled (i.e. backrooms) that would interface with the number of degrees of freedom (N-DOF) ground test validation facilities early on the program for training and validation of tele-presence protocols, and during actual on-orbit operations with the bus operations center directly. It is possible that both could be co-located, or be connected via wired or internet connectivity. Figure 1 below shows notional consideration in the operations and interface between them.

Figure 1 Notional Concept of Interaction between Bus/Payload/N-DOF Facilities

The Phoenix program will adhere to existing US and international standards for orbital debris mitigation in all phases of the proposed scenario. Special attention needs to be considered by performers to avoidance of inadvertent space debris generation either by releasing a component or tool into free space or by allowing any waste product of a process used on Phoenix such as particulate generation from de-attaching an aperture to escape into free orbit.

Program Scope The program will be executed in multiple technical segments solicited through a series of broad agency announcements (BAAs). The program features multiple technical areas with varying degrees of interface and integration requirements to each other. Figure 2 shows a Notional Technical Interface Matrix for reference to the various elements, where all team members on the Phoenix program will cooperate during the first Phase of the project on defining the mechanical, electrical and robotic interfaces in detail to provide system success.

The Government intends to utilize a DARPA owned spacecraft bus and previously developed FREND arm(s) as foundation elements for development of the Phoenix mission. At this time DARPA intends to provide the Servicer/Tender spacecraft bus and robotic payload integration, along with definition and coordinated selection of candidate retired communications satellites and their apertures for use on the demonstration mission. The integration of these elements is intended to be done at one or more Government facilities selected by DARPA.

This present BAA concentrates on seven (7) technical areas. Proposers can combine multiple technical areas into their proposals as long as adequate technical and cost visibility is provided.

DARPA reserves the right to select any or all proposed solutions inside a particular proposal for integration into the entire program.

One or more subsequent BAA’s will focus on integration of the technologies developed under this BAA, along with additional elements, that will culminate in a flight demonstration. The program follows a phased approach where Phase 1 is notionally 14 months to achieve preliminary design level maturity and prototype demonstration(s); Phase 2 is notionally 26 months where all hardware components achieve at a minimum critical design level maturity and all flight hardware assembled, qualified and integrated into the Servicer/Tender prior to environmental test and ready for launch by the end of Phase 2; and Phase 3 is launch and operational phase of the project notionally 6-12 months (with residual capability up to 48 months). Figure 3 shows the notional overall program timeline and identification of all technical elements.

Figure 2. Notional Technical Interface Matrix (provided for information only)

Figure 3. Notional Program Timeline (in Government FY)

Deliverables specific to a technical area are described in each section below. The milestone reviews in Phase 1 ( identified as A, B, and C in Figure 3) will be conducted in the form of principal investigator (PI) meetings at which all performers across the various technical areas will be present. Proposers are referred to Section VI.B.1 for additional information on project meetings. At each of the milestone reviews the performer is expected to provide a technical data package on their element(s) containing applicable software source code, libraries, executables, test cases, and software documentation, along with drawings, models, blueprints, circuit diagrams, data sets, specifications, and documentation developed in the course of performance for their technical areas.;

Proposers are also referred to Section VI.C. of this BAA for additional reporting requirements.

This BAA is intentionally structured in the form of multiple independent technical areas to facilitate participation by small and non-traditional performers, as well as academic and other not-for-profit institutions. Proposers may respond to only those technical areas that are within their scope of competency. Proposers choosing to respond to multiple technical areas as a system should delineate technical and cost between technical areas for DARPA to evaluate. Proposers choosing to respond to multiple technical areas that are not linked as a system should submit separate proposals to each technical area.

To further facilitate the development of robust and ubiquitous industry-wide standards and promote a space servicing “global commons,” international participation in this solicitation is welcomed. The designation of technologies developed under this BAA with respect to export control regulations is to be determined. As a precaution, all proposers should plan, immediately upon award, to commence implementation of a technical assistance agreement (TAA) to encompass all U.S. and non-U.S. awardees under this

BAA.

For purposes of costing, delivery of all hardware and software elements for integration into the Phoenix program will be at a Government facility in the Washington DC area.

Technical Elements The following technical elements are solicited in this BAA along with proposal requirements (Figure 4):

Figure 4: Technical Elements in DARPA-BAA-12-02

T ec h A re a fo r D

A R

P A

-B A

A

2-

Program Element of a w ar d s A n ti ci p at ed

Proposal requirements

FREND compatible tools and software (End effectors etc.)

Multiple (~4)

Proposers are to prepare a proposal for a base period (Phase 1) with a period of performance of 14 months.

Proposers must include a priced option for Phase 2 with a 26 month period of performance. Proposers must also include a priced option for Phase 3 with a 6 month base period of performance and optional 6 month period.

* Tech Area 4, Toolbelt (or Toolcaddy) will conclude with Phase 2; Phase 3 proposal is not required.

Tele-robotic operations and software support

Multiple (~2)

Next generation hyper-dexterous manipulator

Single

Toolbelt (or Toolcaddy)*

Single

Cellularized Satellites (i.e., Satlets)

Multiple (~4)

Proposers are to prepare a proposal for a 14 month Phase

1. Prior to the end of Phase 1 (~90 days), the government will provide updated proposal guidance for Phase 2 proposals to all Phase 1 performers. Phase 2 proposals will be evaluated based on the same criteria as phase 1 proposals. Proposals will be due 45 days prior to the end of Phase 1.

6 PODS

Multiple

(~2)

Commercial Hosted Dispensed Payloads Study and Interface Definition

Single

Proposers are to prepare a proposal for a 9 month Phase 1 study. Study results will be provided open source at the conclusion of the study and content will be used to inform future Phoenix activities in follow on BAA’s.

Technical Area 1: FREND compatible tools and software Phoenix robotic tools (i.e. end effectors, graspers, grippers, cutters etc.) will provide the capability for both performing mechanical actions as well as collecting information as required relative to the notional demonstration scenario description. The tools provide the ability for the FREND arms (see section labeled “APPENDIX 1: FREND Technical Interface Information”) to meet the specific grasping requirements at the designated points on the orbital components and perform work on them. The work may include, but not be limited to: grasping and opening the PODs; grasping, extracting and possibly re-grasping Satlets and other tools; grasping the to-be-re-purposed satellite well enough to assure positioning in 6 degrees-of-freedom (DOF); positioning and attaching appropriate Satlets to the aperture in designated locations; testing the repurposed aperture before release; removing the aperture (i.e. through cutting, unbolting, etc.) from the candidate satellite to release it and operate independently.

Capabilities at a High Level:

Tools are necessary to match the capabilities of the FREND arm to the task of repurposing. Tools are expected to be either grasped and used by an existing FREND gripper or to replace the existing FREND gripper and attach directly to the FREND interface (Appendix 1).

Typical tools that are notionally expected to be needed include grippers of several kinds to grasp PODs, Satlets, and structural components at designed grasp points or ad hoc points on any necessary component and perform actions. Tools may include but not be limited to such special-purpose devices as grippers, saws, wire-shearing devices, cameras to give specialist views of any operation, bolt driver/remover and other ancillary capability as needed (e.g. special fixtures as an aid to assembling Satlets to the aperture, etc.). The tools may attach mechanically and electrically to the FREND tool interface or may be grasped by one of the other grippers interfaced to FREND.

Tools will be under software control via the FREND arm control computer for both action and returning sensor values for tasks such as inspection and for interfacing to ground control. Each tool needs a software module to be delivered for installation into the Servicer/Tender for command, control and sensing. The tools and their actions will be under the local control of the software, hierarchically starting from the FREND arm electronics, the Servicer/Tender, and the ground Payload Control Operations Center.

Software actions include verifying that the mechanical action completed properly and returned sufficient information to allow Ground Operations to build a remedial plan.

Proposers can propose additional tools or combinations of tools envisioned to provide both flexibility and cost efficiency for the Phoenix notional demonstration scenario and objectives.

Challenges/Considerations:

DARPA envisions the tools will need to incorporate the ability to react to unexpected conditions and events on-orbit as encountered during the notional demonstration scenario objectives. The proposer is encouraged to describe risk mitigation work from other potential fields (e.g. deep sea oil drilling, remote hospital room operations) and how the proposer might apply these to Phoenix operations for space.

Considerations in the functioning of FREND compatible tools may include but not be limited to:

Ability to react to unexpected conditions and events on-orbit that may be encountered during the notional demonstration scenario objectives.

Physical size of the fully extended and stowed tool.

Variability in the expected geometric shape and size hardpoints on the retired satellite for grasping and holding.

Variability in the expected geometric shape and size hard points on an antenna

(i.e. 2-5” square tubular or 1-3” dia. cylindrical tubular section) that would need to be grasped and cut/severed.

Associated wiring and thermal blanketing that may be present on the antenna support sections.

Variability of required grip forces which depend on qualities such as inherent strength of antenna or structural brackets, size of the antenna, or satellite grasping.

Ability of the tool(s) to continue to grasp either the antenna support bracket or the retired satellite, post-sever, for extended duration.

Ability to release antenna post-sever with the lowest relative rates The number of mate/demate/sever cycles the tools can perform.

Ability to work through and/or mitigate differential static charge levels between various charged state structural elements and between grasp and re-grasp cycles to the same or different structural elements.

Ability to mitigate any debris byproducts on-orbit based on any of the tool processes.

During program development it is expected that the tools will be integrated to the primary robotic FREND arm(s) and go through a full demonstration cycle— i.e. manipulate a prototype POD, remove Satlet from a prototype POD, place a Satlet onto a representative aperture structural hard point, and grapple a representative hard point on a host satellite— at a Government specified ground test and integration facility.

The proposers will provide an acquisition profile that meets the deliverables described in the following table:

Table 5: Deliverables for Technical Area One (FREND compatible tools and software) Milestone Deliverables Phase 1 Milestone deliverable packages identified under Program Scope

(Figure 3) PDR-level design package for each tool proposed.

Prototype of at least one tool proposed by each performer, to be used in ground demonstrations directly or in-directly coupled with the

FREND arm.

Phase 2 CDR-level design package for each tool proposed.

Delivery of individual tools and their software for systems integration to FREND and to the FREND control computer.

Phase 3 A suitable training package for operators and support to mission operations for each tool (base and option).

Technical Area 2: Tele-robotic operations and software support DARPA is seeking proposals to support various levels of tele-robotic/tele-presence control and command sequencing software compatible with the FREND arm tools.

Phoenix tele-presence software and algorithms will enable a human operator on the ground to remotely command and control the robotic systems on the Servicer/Tender.

For proposal purposes, the tele-presence approach and operator work load should be consistent with 8 hour ground crew shifts, nominal 2 shifts per day.

Capabilities at a High Level:

Tele-presence suite (software and associated hardware on the ground) capable of a minimum of 12 months of operations.

Provide human operator with sufficient, timely feedback to prevent inadvertent contact between any on-orbit flight objects outlined in the notional demonstration scenario.

Provide human operator with sufficient, timely feedback to enable successful on-orbit operations outlined in the notional demonstration scenario (i.e. POD capture and stow, retired satellite capture and release, Satlet retrieval and installation, tool changeout, aperture detachment, etc.).

Proposers can propose additional functions envisioned to provide flexibility and robustness in Phoenix demonstration objectives.

The proposer should consider potential tele-presence challenges that will be encountered during Phoenix demonstration based on the notional scenario. The proposer will explain their vision for the tele-presence system and specifically consider the following items:

Specific techniques for controlling high DOF robotic systems that experience time delays due to space communication with a limited situational awareness or perspective.

Minimum and optimum bits/second required by any high performance RF communications capability for the proposed system. An analysis on maximum latency effects on human-in-loop operations relative to a command uplink and downlink video communications system would be required.

Special design considerations for secure communications link if one is required.

Recommended degree of autonomous versus manual capability required.

Recommendations for the on-orbit robotic system(s) self-safe decision process in the event of a dropout of the tele-presence command link.

Ability to provide the Phoenix mission director capability to override any operator command sequence (i.e. for immediate abort or safehold) from the ground.

Identify any required human-in-the-loop (HITL) feedback mechanisms (i.e.

tactile, visual, electrical, RF, etc.) and justification for inclusion.

Minimum video frames per second for successful operations.

The proposer should explain scenarios for the operator’s training timeline integration with any N-DOF test facility and the Phoenix mission operations center for their particular tele-presence solution system. The proposer may describe training and operator risk mitigation work from other fields and projects and how these might apply to the Phoenix tele-presence suite.

The proposers will provide an acquisition profile that meets the deliverables described in the following table:

Table 6: Deliverables for Technical Area Two (Tele-robotic operations and software support) Milestone Deliverables Phase 1 Milestone deliverable packages identified under Program Scope

(Figure 3) Algorithm and software architecture for tele-presence operations for a representative set of ground human-in-the-loop (HIL) control hardware.

PDR-level design of HIL hardware to include software interconnect architecture with FREND.

Demonstration (via ground-based simulation or prototype hardware) of projected robotic operations on elements of the notional demonstration scenario.

Phase 2 CDR-level design package for HIL software and hardware proposed.

Delivery of flight software and/or algorithms, and HIL hardware for integration into the payload and robotics ground operations center.

Phase 3 On-orbit support for the base and option periods.

Technical Area 3: Next generation hyper-dexterous manipulator DARPA is interested in exploring next generation highly (or hyper) dexterous manipulator mechanisms, as either primary or secondary robotic elements to support the Phoenix mission. DARPA is interested in the potential exploitation of existing advances in robotic manipulators that would establish expanded operational capabilities of an arm with a different geometry than FREND in the course of the Phoenix demonstration. This may be needed for actions beyond those envisioned in the notional demonstration scenario, to include but not be limited to: penetrating a confined volume to perform a task beyond FREND’s capabilities, providing stand-off lighting capability, or carrying a camera to a position to obtain a specific additional view of the robotic work space, etc.

Arm types could take many forms—snake-like, hyper-redundant, multi-redundant—and may have many more degrees of freedom than the minimal 6, capable of threading around obstacles. The arm would be required, at a minimum, to come equipped with a camera and/or light or other type of situational awareness sensor. The hyper-redundant arm might itself be carried by a FREND tool, attach to a FREND interface (substituting for a tool), or be attached directly to the Servicer/Tender. The arm would be required to receive commands through its interface and pass any sensory data and situational awareness information back to the Servicer/Tender, utilizing existing FREND command interfaces.

Capabilities at a High Level:

Carry a tool, camera or light and be capable of threading into tight areas as needed involving any on-orbit objects as described or anticipated in the notional demonstration scenario.

Ability to aggregate individual modules to increase strength, length or reach.

Ability to mitigate collisions of any part of the hyper-redundant arm with any of the on-orbit elements or components envisioned for the Phoenix on-orbit operations notional demonstration scenario.

Ability to operate semi-autonomously in inverse kinematic mode to support the human operator and minimize the control load.

Accepts control functions via the Servicer/Tender or FREND control electronics.

A plan is required to demonstrate a high TRL and space compatibility to match the operational lifetime of the Servicer/Tender.

In addition, proposers can propose additional functions not identified here. Technologies that require timelines beyond the Phoenix delivery schedule for robotic manipulators are beyond the scope of this BAA.

Challenges/Considerations:

Considerations on the hyper-dexterous manipulator may include (but are not restricted to):

Balance between reliability, space-qualification, and cost for a hyper-redundant arm.

Performing position and resolved rate control via inverse kinematics on an arm with a high number of degrees of freedom.

Ability for the arm to operate properly with individual module failures (or several single point failures, i.e. no failures in two consecutive modules).

The proposers will provide an acquisition profile that meets the deliverables described in the following table:

Table 7: Deliverables for Technical Area Three (Next generation hyper-dexterous manipulator) Milestone Deliverables Phase 1 Milestone deliverable packages identified under Program Scope

(Figure 3) PDR-level design package of Phoenix-specific hyper-redundant technology/sensor.

Prototype demonstration of multiple modules acting together (goal), for test with FREND interface electronics.

Phase 2 CDR-level design package including software.

Prototype delivery of at least one system level suite capable of integration to the FREND electronics and prototype arm system (as required) for demonstration on the ground in concert with other Phoenix robotic payloads.

Flight delivery of at least one system level suite to be integrated for flight.

Phase 3 Provide base plus option period of orbital support.

Technical Area 4: Toolbelt and/or Toolcaddy To accommodate the disparate number of various robotic and supporting elements, including POD’s, and potentially the RPO payload and high performance communications components, DARPA is seeking innovative concepts on the development of a “toolbelt” (or payload interface platform) for the Servicer/Tender (see section labeled “APPENDIX 2: Servicer/Tender Bus to Toolbelt Interface Information”).

The concept of the toolbelt is meant to provide a structural platform, gantry, docking station or shelf whereby multiple elements can be secured within reach of the primary robotic arms. Elements to secure include the PODs already attached prelaunch, or after they are captured from the host communications satellite, Satlets (as required), a toolcaddy or tool-storage location or a multiple number of expected tools to perform the Phoenix demonstration. It is possible that the toolbelt design and development may take advantage of the POD’s geometry, or be built in concert with the POD’s configuration and operation (see Technical Area 6).

Table 8: Deliverables for Technical Area Four (Toolbelt and/or Toolcaddy)

Phase 1 Milestone deliverable packages identified under Program Scope (Figure

3) PDR-level design package of toolbelt that shows technical detail and integration to existing spacecraft bus.

Phase 2 CDR design package.

Toolbelt hardware delivery and integration support.

Tech Area 5: Cellularized Satellites (i.e., Satlets)

Repurposing an existing on-orbit aperture in a cost effective manner requires that the cost of the replacement system must be markedly lower than a replacement satellite itself. A compilation of historical data for satellite production indicates a simple relationship where both satellite cost (excluding launch) and performance capability increase with satellite and payload aperture mass. This cost-mass-performance relationship also extends to the time required to develop and deliver the particular space-capable system. Further, an analysis of satellites developed from the 1960’s onward indicates that all share nearly identical morphology (where we take morphology to mean the overall form of spacecraft elements, especially the technological principles employed). Static spacecraft morphology is not only observed through time, but is also observed across all satellite size/mass scales. (An example of static morphology is seen in comparing a large satellite Reaction Wheel Assembly [RWA] to Cubesat RWA; they both employ the same spinning wheel methodology, albeit at much different scales of size and power.) The Phoenix program postulates that the existing cost-mass-performance-time relationship can be decoupled by re-defining satellite morphology; that is, by re-evaluating the typical functional subsystem elements of command and data handling C&DH, power, thermal, attitude control, etc. Phoenix aims to achieve this by demonstrating cellularized satellite architecture based on specialty “cells” 6.

The concept of standardized cellular satellite construction is intended to take advantage of two precepts: physical and electrical aggregation of very small elements to create variable size/performance components for different mass spacecraft; and non-traditional aerospace commercial off the shelf (COTS) manufacturing.

Physical and electrical aggregation is similar to the buildup of both performance and structure that occurs in biological systems (i.e. coral reefs). The ability to aggregate very small, scalable elements capable of physical and/or electrical performance variability is an area of interest for Phoenix. Aggregation can be either in two or three dimensions from a structural standpoint, with consideration for the size of the ‘cell’ and the force needed to physically connect as a design factor. The use of today’s COTS high volume manufacturing techniques in many structural and electronic systems may provide economies of scale and cost measured against the typical satellites its subcomponents, often custom-designed and manufactured in single-digits. As an example, an Apple iPhone (or other variant) uses internal processing and memory chips that in general are more powerful than today’s satellite computer systems and at a much lower cost point, specifically because it is mass produced. One concept then is to understand how aggregating components that make up smart phones could provide scales of performance translatable to the space arena.

DARPA is interested in the extent of cellularization. The goal under Phoenix is to allow performers to disaggregate typical space vehicles into as many or as few cardinal pieces as required, and through careful examination and teaming with both traditional and non-traditional manufacturing entities, generate an approach to produce a cellular satellite

6 “Reconfigurable Cellular Satellites Maintained by Space Robots”, H. Tanaka, N. Yamamoto, T. Yairi and K. Machida, Journal of Robotics and Mechatronics Vol. 18, No. 3, 2006 architecture capable of achieving order of magnitude cost reduction for aperture repurposing compared to the direct replacement satellite.

The term “Satlet” is intended to define either a single cellularized subsystem or component element (i.e. a wireless power cell or a propulsion cell) or a single standalone cell-based system. The extent of cellularization possible for satellites can vary between the following two extremes (using the Satlet definition):

(a) Single Function Satlets. Each Satlet can incorporate one individual satellite subsystem function and aggregate multiple units to increase the required performance (i.e. spatially distributed miniature RWA’s that together provide total momentum control, or “stacked” RWA’s that accomplish the same functional performance aggregation).

(b) System Satlets. Each Satlet constitutes a complete stand-alone system that contains requisite individual subsystems such as command and data handling, power, thermal control, data sharing, attitude control, propulsion, etc., that can be aggregated together in a single geographically co-located entity to serially increase performance with increased numbers. (A simple example might be today’s Cubesat, which is a system Satlet without the ability to aggregate performance.)

A related area of investigation is to determine and demonstrate how the viability of the cell based morphology affects the overall test and qualification process when applied to a variety of traditional mass satellites using aggregation. The Satlet may challenge existing qualification approaches to allow much lower cost and time to develop a space vehicle using these aggregated cells, where, as an example, the resultant aggregated satellite qualifies only one cell (whatever architecture is proposed) and then extrapolates that qualification sequence to all other similarly assembled cells. The onus will be to prove that this methodology offers an equal or higher level of robustness and failure compensation versus cost to develop than traditional space systems with this approach.7 The technology to do this for spacecraft is basically unknown. Phoenix postulates that by Satlets “assembling in space” the aggregated systems will not undergo extensive in-space systems qualification; thus only each cell needs space qualification, offering potential savings in final system-level qualification and testing on the ground.

Capabilities at a high level:

A minimum set of Satlet functional variants are envisioned to support the notional Phoenix demonstration scenario. These are listed below.

Able to act as a collector of the RF energy from the aperture, and retransmit these reflected signals either back to the ground (to a ground antenna) and/or in bent pipe mode up to 1 km at a minimum of 128kbps to the Servicer/Tender. This

7 As an example, IBM proved this concept in the 1970’s with the introduction of “field merge” for large computer systems. There the system was assembled for the first time in the customer’s office in full view.

It required full qualification of the modules before the merge.

Satlet(s) functional variant would most likely be located at the RF collector location of the candidate aperture.

Able to stabilize up to a 100kg aperture to within +/- 10 degrees as aggregated performance, distributed across the requisite number of Satlets (specified by their individual performance). These Satlet variants would need to have flexibility to grapple multiple points on a candidate aperture and provide aggregated momentum control over linear and non-linearly spaced two and three-dimensional locations to conform to varying aperture geometries.

Able to provide momentum dumping through simple non-toxic traditional consumable systems, commensurate with the momentum generating Satlet variants to allow up to 6 months of operations for the repurposed aperture.

Considerations on Satlets may include, but are not restricted to:

Each Satlet must have a suitable grapple fixture(s)—dependent upon the available tools or grapple end effectors available via Task 1—that will be compatible with the Servicer/Tender FREND arm to allow for placement on aperture structure.

Compatability (electrically and mechanically) with suitable fixtures to the PODs while on/in the host satellite and while on the Servicer/Tender.

The Satlet must consider stability against the aperture structure (at variable orientation) and ability to grapple and hold as a permanent mechanism (i.e. no power required).8

Inter-Satlet communication to share both state of health and information related to the aggregated performance must be considered.

Individual Satlets must consider how to obtain, generate, or share power to the level required to support functions embedded in each of the Satlets.

Table 9: Deliverables for Technical Area Five (Cellularized Satellites (i.e., Satlets))

Phase 1 Milestone deliverable packages identified under Program Scope (Figure

3) CDR-level design package of Satlet, morphology and architecture identified, antenna grapple system, intra-satellite communications, power, Satlet to ground communications, Satlet to Servicer communications, detailed software development plan, Satlet qualification, verification and validation plan. A business projection

8 Note: While the Satlet must be able to grasp a suitable antenna structure, the Satlet grapple fixture could use the Servicer/Tender arm to provide the mechanical power or leverage as the grappling transfer power (i.e. a mechanical screw or wormgear could be effected by the Arm tools, instead of the Satlet having to provide the power to affect the grapple.)

analysis report on production costs for proposed Satlet(s) architecture should be included.

Prototype Satlet built and bench top demonstration.

Demonstration of aggregated performance (either via hardware or analysis) of Satlets for a specific variant.

Prototype Satlet to antenna grapple system bench top demonstration.

Phase 2 and 3 full proposal with cost as outlined in the proposal guidance provided prior to the end of Phase 1.

Phase 2 and 3 deliverables are notional. Satlet performers will receive updated proposal guidance for Phase 2 and 3…