Proposer Information Pamphlet (PIP)kosecka/LAGR/1_LAGRPIPMay4.doc · Web viewProposer Information Pamphlet for Learning Applied to Ground Robots. i Sheet1. Chart1. Constants. L

Proposer Information Pamphlet for Learning Applied to Ground Robots

LAGR

Learning Applied to Ground Robots

Proposer Information Pamphlet (PIP)

for

Broad Agency Announcement 04-25

Defense Advanced Research Projects AgencyInformation Processing Technology Office

3701 North Fairfax DriveArlington, VA 22203-1714

i


TABLE OF CONTENTS

1 PROGRAM OBJECTIVES....................................................................................................................1

2 PROGRAM DESCRIPTION...............................................................................................................2

2.1 PHASE I..........................................................................................................................................22.2 PHASE II.........................................................................................................................................3

3 TEST AND EVALUATION................................................................................................................3

3.1 TEST PROCESS...............................................................................................................................33.1.1 Learning from Experience........................................................................................................33.1.2 Learning from Examples..........................................................................................................33.1.3 Controlled Tests........................................................................................................................4

3.2 PLATFORM.....................................................................................................................................43.2.1 Mobile Robot............................................................................................................................43.2.2 Sensor Payload.........................................................................................................................53.2.3 Autonomous Driving System.....................................................................................................53.2.4 Application Programmer Interface..........................................................................................5

3.3 TEST FACILITY...............................................................................................................................63.4 SCORING........................................................................................................................................7

3.4.1 Definitions................................................................................................................................73.4.2 Run Score..................................................................................................................................83.4.3 Total Score................................................................................................................................9

4 PROGRAM SCOPE...........................................................................................................................10

4.1 LEARNING METHODOLOGIES.......................................................................................................104.2 MONOCULAR VISION...................................................................................................................104.3 INNOVATION................................................................................................................................104.4 REPORTING..................................................................................................................................114.5 COOPERATION..............................................................................................................................114.6 TRAINING DATA AND OBJECT CODE...........................................................................................11

5 GENERAL INFORMATION............................................................................................................11

6 SUBMISSION PROCESS..................................................................................................................12

7 NEW REPORTING REQUIREMENTS/PROCEDURES.............................................................13

8 PROPOSAL FORMAT......................................................................................................................14

8.1 COVER PAGE................................................................................................................................148.2 VOLUME I. TECHNICAL...............................................................................................................148.3 VOLUME II. COST.......................................................................................................................178.4 ORGANIZATIONAL CONFLICT OF INTEREST.................................................................................17

9 EVALUATION AND FUNDING PROCESSES..............................................................................17

10 Administrative Addresses.....................................................................................................................18

11 ATTACHMENT – SPINNER DOCUMENT……………………………………………………19

ii


1 PROGRAM OBJECTIVES

The Defense Advanced Research Projects Agency (DARPA) Information Processing Technology Office (IPTO) is soliciting proposals for a new program in Learning Applied to Ground Robots (LAGR). The goal of the LAGR program is to develop a new generation of learned perception and control algorithms for autonomous ground vehicles, and to integrate these learned algorithms with a highly capable robotic ground vehicle. Furthermore it is intended that the learning methods developed in this program will be broadly applicable to autonomous ground vehicles in all weight classes and in a wide range of terrains.

Current systems for autonomous ground robot navigation typically rely on hand-crafted, hand-tuned algorithms for the tasks of obstacle detection and avoidance. While current systems may work well in open terrain or on roads with no traffic, performance falls short in obstacle-rich environments. In LAGR, algorithms will be created that learn how to navigate based on their own experience and by mimicking human teleoperation. It is expected that systems developed in LAGR will provide a performance breakthrough in navigation through complex terrain.

The overall autonomous performance of a robotic ground vehicle also depends on that vehicle’s inherent mobility: the greater the vehicle’s inherent mobility, the fewer objects that will act as obstacles. In order to create vehicles with high inherent mobility, DARPA developed the Unmanned Ground Combat Vehicle (UGCV) program. One of the vehicles produced by that program, Spinner (see Attachment), uses its terrain-adaptability and strength to traverse terrain that would stop most other vehicles. In LAGR, learning-based perception and navigation will be combined with the inherent mobility of Spinner to yield an autonomous vehicle with extraordinary capability.

Most current systems for autonomous ground vehicle navigation perform the following algorithmic sequence: First, a 3D model of the world is created for the space in the vicinity of the vehicle. Stereo cameras or laser rangefinders (LADAR) are usually used for this purpose. Next, pattern recognition algorithms identify particular kinds of obstacles that exist in the 3D model. Then, the 3D model and the identified obstacles are projected onto a 2D map that specifies areas that are either safe or dangerous for the vehicle to traverse. Using this map, a path-planning algorithm determines the best route for the vehicle to follow. Finally, commands are sent to actuators to move the vehicle in the direction specified by the path planner.

Because of the inherent range limitations of both stereo and LADAR, current systems tend to be “near-sighted,” and are unable to make good judgments about the terrain beyond the local neighborhood of the vehicle. This near-sightedness often causes the vehicles to get caught in cul-de-sacs that could have been avoided if the vehicle had access to information about the terrain at greater distances. Furthermore, the pattern recognition algorithms tend to be non-adaptive and tuned for particular classes of obstacles. The result is that most current systems do not learn from their own experience,

1


so that they may repeatedly lead a vehicle into the same obstacle, or unnecessarily avoid a class of “traversable obstacles” such as tall weeds.

LAGR will address the shortcomings of current robotic ground vehicle autonomous navigation systems through an emphasis on learned autonomous navigation.

2 PROGRAM DESCRIPTIONThe program will proceed in two eighteen-month phases. In Phase I, learned navigation methods will be developed in a sub-scale test environment using small vehicles equipped with a standard computing and sensor suite. In Phase II, methods developed in Phase I will be ported to the Spinner vehicle, and development of learning methods will continue using the small vehicles, with new results ported to Spinner as they become available.

2.1 Phase IIn Phase I, performers will be issued as Government Furnished Equipment (GFE) one, or possibly two identical robotic vehicle systems (see Platform section, below). Each vehicle will be equipped with an autonomous driving system that represents the current state of the art. This system will serve as the baseline standard of performance against which the various learning approaches will be measured.

By the end of Phase I, performers will be expected to have developed learning methods that allow their learned navigation systems to surpass the performance of the baseline system. To be allowed to continue into Phase II, performer teams will be required to provide software enabling the small LAGR vehicle to achieve a travel speed 10 percent higher than the baseline system. For example, if the baseline system achieves 12.5 cm/s then the learned system must travel about 14 cm/s using the exact same vehicle on the

2


exact same course under the exact same conditions. Similarly, if the baseline system achieves 25 cm/s, then the learned system must travel about 28 cm/s. Performers’ systems will also be required to demonstrate various aspects of learning (see the Test and Evaluation section below).

2.2 Phase IIIn Phase II, performers are expected to refine their learned navigation systems so that they achieve approximately twice the speed of the baseline system. In the two examples above, this would correspond to average speeds of 25 and 50 cm/s.

In addition, performers will be provided with training data from the Spinner vehicle. They will be required to use this training data with the learning methods they developed in Phases I and II to provide control commands for Spinner in a software environment similar to the one used on the small vehicles.

3 TEST AND EVALUATIONProgress in Phases I and II will be measured quantitatively through a series of competitions conducted at the LAGR Test Facilities (LTF). A DARPA-designated team independent of the developer teams will conduct the competitions.

3.1 Test Process

3.1.1 Learning from ExperienceCompetitions will measure the ability of the performer systems to learn from experience. These competitions will take place about once a month, starting three months into the period of performance.

Developers will send their developed control software in the form of object code to the LTF. There, operators will load the software onto a vehicle functionally identical to the GFE vehicles distributed to developers. Then, the operators will command that vehicle to travel from a start waypoint to a goal waypoint through an obstacle-rich environment, and measure the performance of the system on multiple runs.

It is expected that performance will improve from one run to the next as the performer systems become familiar with the terrain and obstacles on the course. The systems will be able to store information gathered during a run using non-volatile storage on the vehicle. This information will be available so that later runs may profit from the experience gained in earlier runs.

3.1.2 Learning from ExamplesIn addition to the Learning from Experience activity, other competitions will measure the ability of the performer systems to learn from examples. These competitions will take place about every six months.

3


Prior to the competition, the LTF will acquire teleoperation training data of sensor input and human operator-generated actuator commands. This training data will contain examples of new classes of obstacles or course characteristics. Performers will be required to provide the LTF with software that runs under Linux that can process this training data, producing control software that can then be loaded onto the test vehicles.

The format of the training data will be documented by the LTF at least four weeks before a competition. The format of the competitions will be the same as the Learning from Experience competitions, except that in order to do well, performers will have to have learned from the new training data.

3.1.3 Controlled TestsDuring a competition between multiple developer teams, the test course, the start waypoint, the goal waypoint, and the weather and terrain conditions (to the extent possible) will not be varied.

Over the runs by one developer team, the vehicle and the loaded control software will not be varied.

As necessary, the LGT will vary the testing order so as to give no systematic advantage or disadvantage to any performer team.

3.2 PlatformThis section presents the current understanding of the platform to be provided as GFE. The platform is under development and has not yet left the prototype stage, so changes are anticipated. Therefore, the parameters stated in this section shall be considered tentative, preliminary, approximate, and subject to change at any time.

Conceptually, the platform consists of two primary subsystems: a mobile robot, and a sensor payload.

3.2.1 Mobile RobotThe mobile robot consists of a mobile base (see table below) and low-level command and control software.

Parameter Value

Length 70 cm

Width 50 cm

Height 40 cm

Weight, no primary batteries 130 lb

Weight, with primary batteries < 190 lb

Ground clearance 14 cmBattery 26AH 12V (Qty 2)

4


Max speed 1.75 – 2.5 m/s

Max slope > 20 deg

Weatherproof Splash-proof

The chassis consists of a differential drive mechanism with dual 24V DC motors, each equipped with fail-safe brakes. The mobile base can be physically pushed around by manually activating a clutch.

Easy-grip handles will be mounted on the chassis to facilitate carrying by two people.

The battery system has been specified to sustain continuous driving at 1 m/s for 1 hour, and intermittent driving at 0.5 m/s for 3 hours.

3.2.2 Sensor PayloadEnvironmental sensors will include a commercial stereo camera system, infrared range sensors with an operating range of approximately 1 m, and bumper-activated switches. The stereo system will consist of two binocular systems, providing a field of view of well over 100 degrees. Because of this large field of view, a pan/tilt mechanism is not planned.

Localization sensors will include WAAS-enabled GPS, and an Inertial Measurement Unit with a 3-axis gyro/compass.

The payload will feature a number of high-end workstations running Linux, including a 1 GHz low-power embedded board to serve as low-level controller interface, a 1.4 GHz Pentium-M to perform sensor processing, and a system for logging sensor inputs and output commands to actuators.

Communications devices will include wireless Ethernet, and a standalone radio-frequency (RF) remote that can be used to control the robot even if the computers are off.

3.2.3 Autonomous Driving SystemAutonomous driving software on the vehicle consists of a modular, baseline navigation system developed and demonstrated by the DARPA PerceptOR program, and ported to the LAGR platform. Components will include a range-from-stereo module, an obstacle detection module, a path-planning module, and a vehicle actuator control module.

Performers should be able to substitute their own software for any of the software modules furnished with the vehicle, excepting the vehicle actuator control module.

3.2.4 Application Programmer InterfaceAn Application Programmer Interface (API) will provide software interfaces to the vehicle’s sensors and actuators.

5


Low-level interfaces will enable (a) direct control of drive motors, brakes, and lights, (b) access to time-tagged raw data from all sensors, including the mobile base sensors (for example, wheel encoder data) and the payload sensors (for example, stereo images), and (c) command of self-diagnostics and reporting status results.

Mid-level interfaces will support (a) command of velocity and path curvature, (b) access to filtered data from the pose server, (c) access to processed sensor data such as depth maps, and (d) access to vehicle and sensor states.

High-level interfaces will enable (a) command of path following, and (b) access to processed sensor data for obstacle detection and discrimination.

3.2.5 Innovative ApproachAs one example of an innovative approach, performers could develop methods that work exclusively with image-based representations of space, rather than with commonly employed Euclidean representations such as two-dimensional cost maps or their 2.5-dimensional and three-dimensional variants. An image-based representation may enable an innovative approach to "draw" the route taken in training runs directly on the training images acquired. These drawn routes then become training examples. Extracting the training routes might be accomplished by playing the training images in reverse, andtracking how image patches appear in earlier images. Note that in this example, most of the Autonomous Driving System described in section 3.2.3 is replaced by a learned system. Further note that the approach described here differs from the traditional machine vision task that seeks to "label" the objects in an image. The particular example described in this paragraph is not necessarily a preferred approach; it is simply given here to illustrate the kind of innovative approaches that are sought by this BAA.

3.3 Test FacilityThe LAGR Test Facility (LTF) consists of test courses on outdoor terrain, and a pool of the small LAGR vehicles. Course length will typically be on the order of 100 m, and is expected to vary.

The LTF will contain diverse terrain, ranging from easily traversable to untraversable. The materials, objects, and obstacles will be of sub-scale sizes where possible, so that they present the same level of difficulty to the small LAGR vehicle that full-scale objects and obstacles will present to Spinner.

The course will be fixed during a competition. Between competitions, the courses will definitely vary, becoming progressively more challenging and possibly longer. Once the systems master static terrain, more challenging conditions (for example, moving objects) may be introduced.

Courses will be laid out so that much of the terrain will be visible from the start point. As one possible example, a course might be sited in a concave, bowl-shaped area. Systems

6


that perform visual scene analysis may be able to learn to exploit the “long sight lines” and use that to increase their travel speed.

The goal point may be marked by a visual beacon, that is, a distinctive feature. As one possible example, a beacon might be a sphere painted bright orange and mounted at the top of a 3 m tall stake. Systems that perform visual scene analysis may be able to learn to perform “visual servoing” to reach the goal, and use that to increase their travel speed versus straightforward waypoint navigation.

3.4 ScoringThe approach to scoring emerges from two principles:

Reward Course Completion. The score for any finisher shall be higher than the score for any non-finisher, no matter how fast the vehicles travel.

Reward Higher Speed. For finishers, the score shall be higher for the faster traveler. (Non-finishers should focus first on completing the course, and second on increasing travel speed.)

3.4.1 DefinitionsBefore describing how the score will be calculated, first consider the following definitions of distances, course completion, and times.

Definition of Distances Dr and Ds. Let Dr represent the Euclidean distance from the position at the conclusion of the run to the goal position. Let Ds represent the Euclidean distance from the start position to the goal position.

Definition of Course Completion Fraction F. The fraction of the course completed is defined by

F = 0 if Dr>Ds , = 1-(Dr/Ds) otherwise.

Consideration of a few special cases illustrates this definition. If the vehicle ends up farther from the goal than it was at the start, then Dr>Ds, so

F=0. If the vehicle ends up at the same distance from the goal as it was at the start, then

Dr=Ds, so F=0. If the vehicle ends up exactly on the goal, then Dr=0, so F=1. If the vehicle ends up closer to the goal than it was at the start, but not right at the

goal, then Dr<Ds, resulting in 0<F<1. Thus, in all cases, 0≤F≤1.

Definition of Distance L. The course length L of the shortest traversable path depends on the course. For a course with no obstacles, L=Ds, that is, the shortest traversable path is just the Euclidean distance between the start and goal positions. For a course with obstacles, the vehicle must maneuver around them, thus increasing its travel distance so that L>Ds .

7


Definition of Time Tmax. The maximum time Tmax allowed to complete a run is determined by the course and by the logistics of the testing process. In order to conduct some number of runs per day, a fixed amount of time will be allocated for each run, including run-time plus all setup, teardown, ingress, egress, and administrative pauses.

Definition of Time Tmin. The minimum time Tmin to complete a run is determined by the length of the shortest traversable path and the maximum vehicle speed Vmax as Tmin = L/Vmax.

3.4.2 Run ScoreThe score S for a run is computed as a function of three parameters: the fraction F of course completed, the shortest traversable path length L, and the elapsed time T (Tmin≤T ≤Tmax). The score is

S = FL/T .

Note that the score has units of speed. Further note that the actual distance traveled is not material for the score; instead, what matters is the distance “made good.”

Case 1: The vehicle completes the course, so F=1. The best possible score in this case occurs when the system reaches the goal point in the minimum amount of time (T=Tmin), and the worst possible score occurs when the system reaches the goal point in the maximum allowable time (T=Tmax).

Case 2: The vehicle does not complete the course, so 0≤F<1. In this case, T will be assigned to be equal to Tmax One possible reason for not completing the course is that time expired. Another possible reason is that the vehicle was Emergency stopped (E-stopped) by the LTF staff, for example because the vehicle created a safety hazard, the vehicle endangered itself, or the vehicle left the authorized test area.

Note that in Case 2, the score depends only on the value of F. The best possible score in this case occurs when the system comes within ε of completing the course, that is, when F=1-ε. The worst possible score occurs for F=0. Observe that the worse score for Case 1, namely S=L/Tmax, is higher than the best score for Case 2, namely S=(1-ε)L/Tmax. This proves that systems that finish the course always earn scores higher than systems that fail to finish, no matter how fast they travel. Thus, this specification places a premium on course completion.

The graph below illustrates the scores for the following initial conditions: a shortest traversable path of 100 m, a vehicle with a top speed of 2 m/s, and a maximum time of 500 s. Together, the course length and top vehicle speed lead to a minimum time of 50 s. The graph plots score as a function of time for four different values of F, with no e-stop penalties.

8


For F=1, the maximum score is 2 m/s and the minimum is 0.2 m/s. As the travel time decreases, the score increases non-linearly, thus rewarding faster travel.

For F=0.99, the score is 0.198 m/s, slightly less than the minimum score for the case of F=1. For F=0.5, the score is 0.1 m/s, and for F=0, the score is 0.

3.4.3 Total ScoreThe score Sbar for N runs is the average score

Sbar = (S1 + S2 + … + SN) / N.

Present plans call for N=3 (subject to change at any time).

It follows from the definition of the total score that to achieve a high overall score for a competition, a performer will want to do as well as possible on the initial runs while learning from initial runs and improving on subsequent runs. In particular, use of the average will tend to discourage the strategy of using the first run to slowly and thoroughly explore the terrain, and then using that experience to enable sensational subsequent runs.

9


4 PROGRAM SCOPE

4.1 Learning MethodologiesPerformers will develop methods for training their vehicles to navigate between arbitrary waypoints. Performers are encouraged to use whatever learning methodologies they believe will be most effective.

One potential training method is “learning from example.” In this method, logs are created as the vehicle is remotely controlled or teleoperated by a human driver. Recorded sensor input is paired with the concurrent human operator’s actuator commands. The vehicle’s control system is then trained to mimic the human’s actions in response to the sensor input.

Another potential training method is “reinforcement learning” where the vehicle is allowed to travel autonomously, adjusting its behavior to achieve best progress to the goal waypoint.

4.2 Monocular VisionWhile it is expected that performers will often use stereo disparity cues for determining the range and bearing of obstacles, the resolution of the stereo system likely will be inadequate to range objects that are more than approximately 10 meters beyond the vehicle. Competition courses will be designed to reward behavior in which control decisions are made using information for objects beyond the range obtainable using stereo parallax.

One approach performers are encouraged to take is to employ optical flow and motion parallax for longer range perception. In addition, performers are highly encouraged to use and create methods for image interpretation and understanding that will allow their systems to make inferences about the terrain from single, monocular images. Image understanding approaches will be critical for obtaining good performance when objects of interest lie beyond the range of even motion parallax.

To foster non-stereo methods for image-based navigation, about two competitions will be held each year in which one camera on the vehicle is disabled. It is also possible that in some cases the frame rate of the single operating camera will be reduced so that navigation will not be able to rely on optical flow or motion parallax and will only be possible by employing some method of image understanding.

4.3 InnovationProposed research should investigate innovative approaches and techniques that lead to or enable revolutionary advances in the state-of-the-art. Proposals are not limited to the specific strategies listed above, and alternative visions will be considered. However, proposals should be for research that substantially contributes towards the goals stated. Specifically excluded is research that primarily results in minor evolutionary improvement to the existing state of practice or focuses on special-purpose systems or narrow applications.

10


4.4 ReportingIn addition to participating in all scheduled competitions, performers must participate in any Principal Investigator meetings held as part of the LAGR program. At these meetings, it is expected that each performer will report on the design and implementation of the learning methods, in enough detail that practitioners skilled in the art can replicate them. It is anticipated that these reports will include analysis of why the system made key decisions during test runs, analysis based in part upon data collected and logged during the test runs.

Performers will be required to submit quarterly reports documenting their LAGR activities and progress. At the end of each Phase performers will be required to submit to DARPA a comprehensive summary report. See Section 7 – REPORTING REQUIREMENTS/PROCEDURES.

4.5 CooperationCooperation between performers is encouraged. Cooperation can include, but is not restricted to, sharing training data, as well as learning algorithms and sensor data processing software. Prior to tests, performers must disclose any software they have incorporated from other performers into their systems as well as any training data that they received.

4.6 Training Data and Object CodeDARPA may provide a repository for training data that may be shared among performers.

Further, DARPA may provide a repository for the object code submitted to the LTF prior to each competition. This object code may be shared among performers. Prior to tests, performers must disclose any object code they have incorporated, whether directly or indirectly into their systems.

5 GENERAL INFORMATION Proposals not meeting the format described in this pamphlet may not be reviewed. Proposals MUST NOT be submitted by fax or e-mail; any so sent will be disregarded. This notice, in conjunction with the BAA 04-25 FedBizOpps Announcement and all references, constitutes the total BAA.

A Frequently Asked Questions (FAQ) list may be provided. If so, it will be found on the DARPA/IPTO Solicitation page at http://www.darpa.mil/ipto/solicitations/solicitations.htm.

No additional information is available, nor will a formal Request for Proposal (RFP) or other solicitation regarding this announcement be issued. Requests for same will be disregarded.

All responsible sources capable of satisfying the Government's needs may submit a proposal that shall be considered by DARPA. Historically Black Colleges and Universities (HBCUs) and Minority Institutions (MIs) are encouraged to submit

11


proposals and join others in submitting proposals. However, no portion of this BAA will be set aside for HBCU and MI participation due to the impracticality of reserving discrete or severable areas of this research for exclusive competition among these entities.

The Government anticipates that proposals submitted under this BAA will be unclassified. In the event that a proposer chooses to submit a classified proposal or submit any documentation that may be classified, the following information is applicable. Security classification guidance on a DD Form 254 will not be provided at this time since DARPA is soliciting ideas only. After reviewing incoming proposals, if a determination is made that the award instrument may result in access to classified information, a DD Form 254 will be issued and attached as part of the award. Proposers choosing to submit a classified proposal must first receive permission from the Original Classification Authority to use their information in replying to this BAA. Applicable classification guide(s) should be submitted to ensure that the proposal is protected appropriately.

6 SUBMISSION PROCESS This Broad Agency Announcement (BAA) requires completion of a BAA Cover Sheet for each Proposal prior to submission. This cover sheet can be accessed at the following URL:

http://www.dyncorp-is.com/BAA/index.asp?BAAid=04-25

After finalizing the BAA Cover Sheet, the proposer must print the BAA Confirmation Sheet that will automatically appear on the web page. Each proposer is responsible for printing the BAA Confirmation Sheet and attaching it to every copy. The Confirmation Sheet should be the first page of the Proposal. If a proposer intends on submitting more than one Proposal, a unique UserId and password must be used in creating each BAA Cover Sheet. Failure to comply with these submission procedures may result in the submission not being evaluated.

Proposers must submit the original and 3 copies of the full proposal and 2 electronic copies (i.e., 2 separate disks) of the full proposal (in PDF or Microsoft Word 2000 for IBM-compatible format on a 3.5-inch floppy disk, 100 MB Iomega Zip disk or cd). Mac-formatted disks will not be accepted. Each disk must be clearly labeled with BAA 04-25, proposer organization, proposal title (short title recommended) and "Copy ___ of 2". The full proposal (original and designated number of hard and electronic copies) must be submitted in time to reach DARPA by 12:00 PM (ET) June 17, 2004, in order to be considered during the initial evaluation phase. However, BAA 04-25, LAGR will remain open until 12:00 NOON (ET) April 29, 2005. Thus, proposals may be submitted at any time from issuance of this BAA through April 29, 2005. While the proposals submitted after the June 17, 2004 deadline will be evaluated by the Government, proposers should keep in mind that the likelihood of funding such proposals is less than for those proposals submitted in connection with the initial evaluation and award schedule. DARPA will acknowledge receipt of submissions and assign control numbers that should be used in all further correspondence regarding proposals.

12


Restrictive notices notwithstanding, proposals may be handled for administrative purposes by support contractors. These support contractors are prohibited from competition in DARPA technical research and are bound by appropriate non-disclosure requirements. Input on technical aspects of the proposals may be solicited by DARPA from non-Government consultants /experts who are also bound by appropriate non-disclosure requirements. However, non-Government technical consultants/experts will not have access to proposals that are labeled by their offerors as “Government Only.” Use of non-government personnel is covered in FAR 37.203(d).

7 REPORTING REQUIREMENTS/PROCEDURESThe Award Document for each proposal selected and funded will contain a mandatory requirement for submission of DARPA/IPTO Quarterly Status Reports and an Annual Project Summary Report. These reports, described below, will be electronically submitted by each awardee under this BAA via the DARPA/IPTO Technical - Financial Information Management System (T-FIMS). The T-FIMS URL will be furnished by the Government upon award. Detailed data requirements can be found in the Data Item Description (DID) DI-MISC-81612A available on the Government's ASSIST database (http://assist.daps.dla.mil/quicksearch/). Sample instructions that specify how information in the DID may be collected (content and frequency requirements) can be found in Appendix A. An outline of T-FIMS report requirements is as follows:

(a) Status Report: Due at least three (3) times per year – Jan, Apr, & Oct (1) Technical Report

a) Project General Information b) Technical Approach

- Accomplishments- Goals- Significant changes / improvements

c) Deliverables d) Transition Plane) Publications f) Meetings and Presentations g) Project Plan h) Near term Objectives

(2) Financial Report(3) Project Status / Schedule

(b) Project Summary (PSum): Due once each fiscal year in July

(1) All Sections of the Status Report (2) QUAD Chart

a) Visual Graphic b) Impactc) New Technical Ideasd) Schedule

13

http://assist.daps.dla.mil/quicksearch/


8 PROPOSAL FORMATProposals shall consist of a cover page, a technical volume, and a cost volume. The submission of other supporting materials—including bibliographies, technical papers, and research notes—along with the proposal is strongly discouraged.

A "page" is 8-1/2 by 11 inches with type not smaller than 12 point, and with text on one side only.

8.1 Cover PageThe cover page shall be a single page containing the following information.1. BAA number2. Proposal title3. Lead Organization submitting proposal4. Contractor's type of business, selected from among the following categories:

"WOMEN-OWNED LARGE BUSINESS," "OTHER LARGE BUSINESS," "SMALL DISADVANTAGED BUSINESS [Identify ethnic group from among the following: Asian-Indian American, Asian-Pacific American, Black American, Hispanic American, Native American, or Other]," "WOMEN-OWNED SMALL BUSINESS," "OTHER SMALL BUSINESS," "HBCU," "MI," "OTHER EDUCATIONAL," "OTHER NONPROFIT", or "FOREIGN CONCERN/ENTITY."

5. Other team members (if applicable) and type of business for each6. Technical point of contact to include: salutation, last name, first name, street

address, city, state, zip code, telephone, fax (if available), electronic mail (if available)

7. Administrative point of contact to include: salutation, last name, first name, street address, city, state, zip code, telephone, fax (if available), electronic mail (if available)

8. Total funds requested from DARPA, and the amount of cost-share (if any)9. Summary of the costs of the proposed research, including total base cost, estimates of

base cost in each year of the effort, estimates of itemized options in each year of the effort, and cost sharing if relevant;

10. Date proposal was prepared

8.2 Volume I. TechnicalThis volume provides the detailed discussion of the proposed work necessary to enable an in-depth review of the specific technical and management issues. Specific attention must be given to addressing both the risk and payoff of the proposed work that make it desirable to DARPA.

The Technical Volume shall not exceed 30 pages, and shall include sections A through J, each beginning on a new page. Maximum page lengths for each section are shown in braces { } below, where applicable.

A. Innovative claims for the proposed research{1 Page}. This page is the centerpiece of the proposal and should succinctly describe the unique proposed contribution.

14


B. Proposal Roadmap{1 Page}. The roadmap provides a top-level view of the content and structure of the proposal. It contains a synopsis (or “sound bite”) for each of the nine areas defined below. It is important to make the synopses as explicit and informative as possible. The roadmap must also cross-reference the proposal page number(s) where each area is elaborated. The nine roadmap areas are:

1. Main goals of the proposed research (stated in terms of new, operational capabilities for assuring that critical information is available to key users).

2. Tangible benefits to end users (i.e., benefits of the capabilities afforded if the proposed technology is successful).

3. Critical technical barriers (i.e., technical limitations that have, in the past, prevented achieving the proposed results).

4. Main elements of the proposed approach. 5. Rationale that builds confidence that the proposed approach will overcome the

technical barriers. ("We have a good team and good technology" is not a useful statement.)

6. Nature of expected results (unique/innovative/critical capabilities to result from this effort, and form in which they will be defined).

7. The risk if the work is not done. 8. Criteria for scientifically evaluating progress and capabilities on an annual basis. 9. Cost of the proposed effort for each performance year.

C. Statement of Work {3 Pages}. Detailed statement of work, written in plain English, outlining the scope of the effort and citing specific tasks to be performed, references to specific subcontractors if applicable, and specific contractor requirements.

D. Research Objectives {2 Pages}1. Problem Description. Provide concise description of problem area addressed by

this research project. 2. Research Goals. Identify specific research goals of this project. Identify and

quantify expected performance improvements from this research. Identify new capabilities enabled by this research. Identify and discuss salient features and capabilities of developmental hardware and software prototypes. Provide a set of metrics and success criteria for the concepts proposed under Phase I.

3. Expected Impact. Describe expected impact of the research project, if successful, to problem area.

E. Technical Approach: 1. Detailed Description of Technical Approach {10 Pages}. Provide detailed

description of technical approach that will be used in this project to achieve research goals. Specifically identify and discuss the innovative aspects of the LAGR technical approach. Note: An optional technical viewgraph summary in MS Power Point format (maximum of 8 viewgraphs) may also be included as part of the Technical Volume and will not be considered as part of the volume page count.

15


2. Comparison with Current Technology {2 Pages}. Describe state-of-the-art approaches and the limitations within the context of the problem area addressed by this research.

F. Schedule and Milestones1. Schedule Graphic {1 Page}. Provide a graphic representation of project schedule

including detail down to the individual effort level. This should include but not be limited to, a multi-phase development plan, which demonstrates a clear understanding of the proposed research; and a plan for periodic and increasingly robust experiments over the project life that will show applicability to the overall program concept. Show all project milestones. Use absolute designations for all dates.

2. Detailed Individual Effort Descriptions {3 Pages}. Provide detailed task descriptions for each individual effort and/or subcontractor in schedule graphic.

G. Deliverables Description {2 Pages}. List and provide detailed description for each proposed deliverable. Include in this section all proprietary claims to results, prototypes, or systems supporting and/or necessary for the use of the research, results, and/or prototype. If there are no proprietary claims, this should be stated. The offeror must submit a separate list of all technical data or computer software that will be furnished to the Government with other than unlimited rights (see DFARS 227.) Specify receiving organization and expected delivery date for each deliverable.

H. Technology Transition and Technology Transfer Targets and Plans {1 Page}. Discuss plans for technology transition and transfer. Identify specific military and commercial organizations for technology transition or transfer.

I. Personnel and Qualifications {3 Pages}. List of key personnel, concise summary of their qualifications, and discussion of proposer's previous accomplishments and work in this or closely related research areas. Indicate the level of effort to be expended by each person during each contract year and other (current and proposed) major sources of support for them and/or commitments of their efforts. DARPA expects all key personnel associated with a proposal to make substantial time commitment to the proposed activity.

J. Facilities {1 Page}. Description of the facilities that would be used for the proposed effort. If any portion of the research is predicated upon the use of Government Owned Resources of any type, the offeror shall specifically identify the property or other resource required, the date the property or resource is required, the duration of the requirement, the source from which the resource is required, if known, and the impact on the research if the resource cannot be provided. If no Government Furnished Property is required for conduct of the proposed research, the proposal shall so state.

8.3 Volume II. CostCost proposals are subject to no page limits, and shall provide a detailed cost breakdown of all direct costs, including cost by task, with breakdown into accounting categories (labor, material, travel, computer, subcontracting costs, labor and overhead rates, and

16


equipment), for the entire contract and for each calendar year, divided into quarters. Where the effort consists of multiple portions that could reasonably be partitioned for purposes of funding, these should be identified as contract options with separate cost estimates for each.

Offerors should expect to participate in teams and workshops to provide specific technical background information to DARPA, attend semi-annual Principal Investigator (PI) meetings, and participate in numerous other coordination meetings via teleconference or Video Teleconference (VTC). Funding to support these various group experimentation efforts should be included in technology project bids

Offerors requiring the purchase of information technology (IT) resources as Government Furnished Property (GFP) MUST attach the following information:

1. A letter on Corporate letterhead signed by a senior corporate official and addressed to Dr. Larry Jackel, PM LAGR, DARPA/IPTO, stating that you either can not or will not provide the information technology (IT) resources necessary to conduct the said research.

2. An explanation of the method of competitive acquisition or a sole source justification, as appropriate, for each IT resource item.

3. If the resource is leased, a lease purchase analysis clearly showing the reason for the lease decision.

4. The cost for each IT resource item.

IMPORTANT NOTE: IF THE OFFEROR DOES NOT COMPLY WITH THE ABOVE STATED REQUIREMENTS, THE PROPOSAL WILL BE REJECTED.

8.4 Organizational Conflict of InterestAwards made under this BAA may be subject to the provisions of the Federal Acquisition Regulation (FAR) Subpart 9.5, Organizational Conflict of Interest. All offerors and proposed subcontractors must affirmatively state whether they are supporting any DARPA technical office(s) through an active contract or subcontract. All affirmations must state which office(s) the offeror supports, and identify the prime contract number. Affirmations should be furnished at the time of proposal submission. All facts relevant to the existence or potential existence of organizational conflicts of interest, as that term is defined in FAR 2.101, must be disclosed in Section II, I. of the proposal, organized by task and year. This disclosure shall include a description of the action the Contractor has taken, or proposes to take, to avoid, neutralize, or mitigate such conflict.

9 EVALUATION AND FUNDING PROCESSES Proposals will not be evaluated against each other, since they are not submitted in accordance with a common work statement. DARPA's intent is to review proposals as soon as possible after they arrive; however, proposals may be reviewed periodically for administrative reasons. For evaluation purposes, a proposal is the document described in Proposal Format. Other supporting or background materials submitted with the proposal will be considered for the reviewer's convenience only and not considered as part of the proposal.

17


Evaluation of proposals will be accomplished through a scientific review of each proposal using the following criteria, which are listed in descending order of relative importance:

(1) Overall Scientific and Technical Merit: The overall scientific and technical merit must be clearly identifiable and compelling. The technical concepts should be clearly defined and developed. The technical approach must be sufficiently detailed to support the proposed concepts and technical claims. Evaluation will also consider the effectiveness of the system integration and management plan.

(2) Innovative Technical Solution to the Problem: Offerors should apply new and/or existing technology in an innovative way that supports the objectives of the proposed effort. The proposed concepts and systems should show breadth of innovation across all the dimensions of the proposed solution. Offerors must also specify quantitative experimental methods and metrics for measuring progress of the effort.

(3) Potential Contribution and Relevance to DARPA/IPTO Mission: The offeror must clearly address how the proposed effort will meet the goals of the undertaking and how the proposed effort contributes to significant advances to DARPA/IPTO.

(4) Offeror's Capabilities and Related Experience: The qualifications, capabilities, and demonstrated achievements of the proposed principals and other key personnel for the primary and subcontractor organizations must be clearly shown.

(5) Plans and Capability to Accomplish Technology Transition: The offeror should provide a clear strategy and plan for transition to military forces (and commercial sector, where applicable). Offerors should consider involving potential military transition partners, as appropriate, in any proposed experiments, tests and demonstrations. Offerors should also provide a plan for transition of appropriate technology components and information to the user community.

(6) Cost Realism: The overall estimated costs should be clearly justified and appropriate for the technical complexity of the effort. Evaluation will consider the value of the research to the government and the extent to which the proposed management plan will effectively allocate resources to achieve the capabilities proposed.

The Government reserves the right to select all, some, or none of the proposals received in response to this solicitation and to make awards without discussions with offerors; however, the Government reserves the right to conduct discussions if the Source Selection Authority later determines them to be necessary. Proposals identified for funding may result in a contract, grant, cooperative agreement, or other transaction depending upon the nature of the work proposed, the required degree of interaction between parties, and other factors. If warranted, portions of resulting awards may be segregated into pre-priced options.

10 Administrative AddressesThe administrative addresses for this BAA are:

18


Fax: 703-741-7804 Addressed to: DARPA/IPTO, BAA 04-25

Electronic Mail: [email protected]

Electronic File Retrieval: http://www.darpa.mil/ipto/Solicitations/solicitations.htm

Mail to: DARPA/IPTOATTN: BAA 04-253701 N. Fairfax DriveArlington, VA 22203-1714

19

http://www.darpa.mil/ipto/Solicitations/solicitations.htm


11 Attachment – Spinner Information

20

Documents

Proposer Information Pamphlet (PIP)kosecka/LAGR/1_LAGRPIPMay4.doc · Web viewProposer Information Pamphlet for Learning Applied to Ground Robots. i Sheet1. Chart1. Constants. L