Unmanned Ground Vehicle Tactical Behaviors 

Technology Assessment

by Marshal A. Childers, Barry A. Bodt, Susan G. Hill, Richard Camden, 

Robert M. Dean, William F. Dodson, Lyle G. Sutton, and Leonid Sapronov

ARL-TR-4698 January 2009

Approved for public release; distribution is unlimited.
NOTICES

Disclaimers

The findings in this report are not to be construed as an official Department of the Army position unless 

so designated by other authorized documents.

Citation of manufacturer’s or trade names does not constitute an official endorsement or approval of the

use thereof.

Destroy this report when it is no longer needed. Do not return it to the originator.
Army Research Laboratory

Aberdeen Proving Ground, MD 21005-5069

ARL-TR-4698 January 2009

Unmanned Ground Vehicle Tactical Behaviors 

Technology Assessment

Marshal A. Childers

Vehicle Technology Directorate, ARL

Barry A. Bodt

Computational and Information Sciences Directorate, ARL

Susan G. Hill

Human Research and Engineering Directorate, ARL

Richard Camden

L3/MPRI Corporation

Robert M. Dean, William F. Dodson, and Lyle G. Sutton

General Dynamics Robotics Systems

Leonid Sapronov

Robotic Research LLC

Approved for public release; distribution is unlimited. 
ii

REPORT DOCUMENTATION PAGE Form Approved 

OMB No. 0704-0188

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering 

and maintaining the data needed, and completing and reviewing the collection information. Send comments regarding this burden estimate or any other aspect of this collection of information, 

including suggestions for reducing the burden, to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0704-0188), 1215 Jefferson 

Davis Highway, Suite 1204, Arlington, VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to 

comply with a collection of information if it does not display a currently valid OMB control number. 

PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS. 

1. REPORT DATE (DD-MM-YYYY)

January 2009 

2. REPORT TYPE 

Final 

3. DATES COVERED (From - To) 

4–14 February 2008 

4. TITLE AND SUBTITLE 

Unmanned Ground Vehicle Tactical Behaviors Technology Assessment 

5a. CONTRACT NUMBER 

5b. GRANT NUMBER 

5c. PROGRAM ELEMENT NUMBER 

6. AUTHOR(S) 

Marshal A. Childers, Barry A. Bodt, Susan G. Hill, Richard Camden,* 

Robert M. Dean,† William F. Dodson, † Lyle G. Sutton,† and Leonid Sapronov‡ 

5d. PROJECT NUMBER 

0602618A H03 

5e. TASK NUMBER 

5f. WORK UNIT NUMBER 

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 

U.S. Army Research Laboratory 

AMSRD-ARL-VT-RP 

Aberdeen Proving Ground, MD 21005-5069 

8. PERFORMING ORGANIZATION 

 REPORT NUMBER 

ARL-TR-4698 

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S) 

11. SPONSOR/MONITOR'S REPORT 

 NUMBER(S) 

12. DISTRIBUTION/AVAILABILITY STATEMENT 

Approved for public release; distribution is unlimited. 

13. SUPPLEMENTARY NOTES 

*

MPRI, A Division of L-3 Communications, Aberdeen Proving Ground, MD 21005 

†

General Dynamics Robotics Systems, 1234 Tech Ct., Westminster, MD 21157 

‡

Robotic Research LLC, 814 W. Diamond Ave., Ste. 301, Gaithersburg, MD 20878

14. ABSTRACT 

During 4–14 February 2008, the U.S. Army Research Laboratory and General Dynamics Robotic Systems conducted an 

unmanned systems tactical behaviors technology assessment at three training areas of Ft. Indiantown Gap, PA. The purpose of 

the assessment was to examine the ability to use sensed information to locally orient an unmanned ground vehicle (UGV) in 

order to obtain line of sight for an onboard reconnaissance surveillance target acquisition system to scan a sufficient portion of 

a named area of interest (NAI) and the impact of advances in deliberative layer planning technologies to enhance autonomous 

mobility in a relevant environment. The assessment was an opportunity to evaluate the performance of the technologies in a 

relevant environment and to provide useful feedback to the engineers for continued development. The results show that the 

algorithms successfully enabled the UGV to autonomously maneuver to a position that provided sufficient coverage of an NAI 

and that the interplay of path-planning algorithms at multiple levels has a significant impact on the ability of a UGV to 

maneuver in a relevant environment. 

15. SUBJECT TERMS

unmanned ground vehicle, UGV, tactical behavior, RSTA, perception, path planning, robotics, autonomous control 

16. SECURITY CLASSIFICATION OF: 

17. LIMITATION 

OF ABSTRACT 

UL 

18. NUMBER 

OF PAGES 

86 

19a. NAME OF RESPONSIBLE PERSON

Marshal A. Childers 

a. REPORT 

UNCLASSIFIED 

b. ABSTRACT 

UNCLASSIFIED 

c. THIS PAGE 

UNCLASSIFIED

19b. TELEPHONE NUMBER (Include area code) 

(410) 278-8810 

Standard Form 298 (Rev. 8/98) 

Prescribed by ANSI Std. Z39.18 
iii

Contents

List of Figures vi

List of Tables viii

Acknowledgments ix

1. Introduction 1

1.1 Technology Assessment..................................................................................................1

1.2 Background .....................................................................................................................1

1.3 Purpose of This Report....................................................................................................2

2. Tactical Behaviors Using Observation Posts and RSTA 2

2.1 Background .....................................................................................................................2

2.2 Previous XUV OP Finding and RSTA Operations.........................................................3

2.3 The 2008 OP and RSTA Tactical Behavior Assessment Approach ...............................4

2.4 OP Courses Used in the 2008 Assessment......................................................................5

2.5 Experimental Design .......................................................................................................7

2.6 OP Finder Operation .......................................................................................................8

2.7 The 2008 Assessment Operations ...................................................................................9

2.8 Data Collection..............................................................................................................11

2.8.1 SMI Log Sample .................................................................................................11

2.8.2 Mosaic Sample ....................................................................................................12

2.8.3 Mosaic Metadata Sample ....................................................................................12

2.8.4 Screenshot Sample ..............................................................................................12

2.8.5 Plan Description Sample .....................................................................................13

2.9 Data Reduction..............................................................................................................13

2.9.1 Run Identifiers.....................................................................................................13

2.9.2 Dependent Measures ...........................................................................................14

2.9.3 RSTA Picture Analysis .......................................................................................14

2.9.4 Accepted Runs.....................................................................................................14

2.10 Human Factor Discussion .............................................................................................14

2.10.1 OP Finder and HMP Human Factor Observations............................................17
iv

2.10.2 RSTA Human Factor Observations...................................................................18

2.11 General Observations....................................................................................................20

2.11.1 Weather Effects.................................................................................................20

2.11.2 XUV Azimuth at OP .........................................................................................21

2.11.3 OP Finder Improves the Quality of the Location Selected as an OP ................21

2.11.4 Algorithm Reporting vs. RSTA Picture Analysis.............................................28

2.11.5 OP Finder Works...............................................................................................29

2.11.6 Scan Size Relevance..........................................................................................31

2.11.7 OP Location Variance .......................................................................................31

2.11.8 Algorithm Performance.....................................................................................31

2.11.9 Variable Ranges ................................................................................................33

2.11.10 Elevation Calculations......................................................................................33

2.11.11 Silhouettes........................................................................................................33

2.12 Recommendations Resulting From the OP Finding/RSTA Technical Assessment......33

2.12.1 General ..............................................................................................................33

2.12.2 OP Finder and HMP Human Factor Recommendations...................................33

2.12.3 RSTA Human Factor Recommendations..........................................................34

2.12.4 Experimentation Methodology Recommendations...........................................36

2.13 Conclusions From the OP Finding/RSTA Technical Assessment ................................36

3. The Interplay of Information Planning at Multiple Levels for UGV Mobility 36

3.1 Background ...................................................................................................................36

3.2 The 2008 Interplay of Multiple-Level Planning Assessment Approach.......................38

3.3 Autonomous Maneuver Courses Used in the 2008 Assessment ...................................39

3.3.1 Area A1 ...............................................................................................................39

3.3.2 Area B9C.............................................................................................................40

3.3.3 Area B12..............................................................................................................41

3.3.4 Area C4................................................................................................................42

3.4 Experimental Design .....................................................................................................43

3.5 The 2008 Assessment Operations .................................................................................43

3.6 Data Collection..............................................................................................................44

3.6.1 SMI Log Sample .................................................................................................44

3.6.2 ACC Log Sample ................................................................................................44

3.6.3 Screenshot Sample ..............................................................................................46

3.7 Data Reduction..............................................................................................................46

3.7.1 Area A1 Data.......................................................................................................46

3.7.2 Area B9C Data ....................................................................................................49
v

3.7.3 Area B12 Data .....................................................................................................49

3.7.4 Area C4 Data .......................................................................................................51

3.8 Observations..................................................................................................................52

3.8.1 General ................................................................................................................52

3.8.2 The Interplay of Planning at Multiple Levels .....................................................52

3.8.3 BIP.......................................................................................................................53

3.8.4 FCI.......................................................................................................................53

3.9 Recommendations From the Interplay of Multiple-Level Planning Assessment..........53

3.9.1 General ................................................................................................................53

3.9.2 Interplay of Perceptive and Deliberative Planners..............................................54

3.9.3 BIP.......................................................................................................................54

3.9.4 FCI.......................................................................................................................54

3.9.5 Technology Assessment......................................................................................54

4. Summary 55

Appendix A. A Potential Process for Observation Post (OP) Finding 57

Appendix B. Summary Data for Information Planning Runs 63

Distribution List 71
vi

List of Figures

Figure 1. XUV with RSTA system.................................................................................................5

Figure 2. NAI the “Hill” had a road in front of a tree line at 250 m...............................................6

Figure 3. NAI the “Swamp” was behind a tree line with a priori data. ..........................................6

Figure 4. NAI C4 had a road below a ridge line at 1–1.4 km.........................................................7

Figure 5. NAI the “Barn” included the ARL building and road at 1.0 km.....................................7

Figure 6. Silhouettes. ......................................................................................................................9

Figure 7. OP finder process (1 of 3). ..............................................................................................9

Figure 8. OP finder process (2 of 3). ............................................................................................10

Figure 9. OP finder process (3 of 3). ............................................................................................10

Figure 10. An example from an SMI log collected for each run. .................................................11

Figure 11. Mosaic of NAI from OP on the “Hill.” .......................................................................12

Figure 12. An example of RSTA mosaic metadata collected for each run...................................12

Figure 13. Screen shot of SMI following a mission at the “Swamp” OP.....................................13

Figure 14. An example of a plan description collected for each run. ...........................................13

Figure 15. Fog at NAI...................................................................................................................20

Figure 16. Rain and fog at NAI. ...................................................................................................20

Figure 17. XUV at OP pointing away from NAI..........................................................................21

Figure 18. Initial decision at OP. ..................................................................................................22

Figure 19. Final decision with repositioning. ...............................................................................22

Figure 20. Initial decision at OP (algorithm A). ...........................................................................23

Figure 21. Final decision with repositioning (algorithm A). ........................................................24

Figure 22. Initial decision at OP (algorithm B). ...........................................................................24

Figure 23. Final decision with repositioning (algorithm B). ........................................................25

Figure 24. Initial decision at OP (RSTA picture analysis). ..........................................................26

Figure 25. Final decision with repositioning (RSTA picture analysis). .......................................26

Figure 26. Initial decision at OP – algorithm A (RSTA picture analysis)....................................27

Figure 27. Final decision with repositioning – algorithm A (RSTA picture analysis).................27

Figure 28. Initial decision at OP – algorithm B (RSTA picture analysis). ...................................28

Figure 29. Final decision with repositioning – algorithm B (RSTA picture analysis). ...............29

Figure 30. OP finder performance across all 57 runs. ..................................................................29

Figure 31. RSTA picture analysis mean coverage........................................................................30
vii

Figure 32. RSTA picture analysis mean coverage (Hill data removed). ......................................30

Figure 33. OP finder performance vs. scan size. ..........................................................................31

Figure 34. OP finder performance vs. scan size vs. algorithm. ....................................................32

Figure 35. Difference in algorithm performance. .........................................................................32

Figure 36. XUV software architecture showing the ACC component. ........................................38

Figure 37. Assessment layout for area A1. ...................................................................................40

Figure 38. Tarp structure used to create cul-de-sac in area A1. ...................................................40

Figure 39. Assessment layout for area B9C..................................................................................41

Figure 40. Assessment layout for area B12. .................................................................................42

Figure 41. Assessment layout for area C4. ...................................................................................43

Figure 42. Excerpt from SMI log file. ..........................................................................................45

Figure 43. Excerpt from ACC log file. .........................................................................................46

Figure 44. Sample screenshot captured at the end of each mission (black area on map

indicates no available a priori map data). ................................................................................47

Figure 45. Depiction of scenario with FCI and perceptive level planning power struggle. .........50

Figure A-1. The multistep observation post finding process begins with stopping short of the 

operator input OP to scan for possible enemy at the OP. If no enemy is sighted, then the 

XUV transverses a route that allows adding midrange obstacles to the map. .........................59

Figure A-2. The multistep process continues with a LADAR scan of the NAI and a report to 

the operator of the percent coverage. A RSTA image is taken and displayed to the 

operator. The five “top” Ops are displayed to the operator. If the operator judges that the 

current position is good, then the OP finding is completed. If it is not good, then the OP 

finding process continues.........................................................................................................59

Figure A-3. If the operator judges that the current position is not good, then the operator 

selects a new OP from the choice of five presented on the SMI. The XUV will then 

move to the selected new OP and stops, pointed toward the NAI...........................................60

Figure A-4. At this new OP, the process is repeated. The operator is presented with a RSTA 

scan of the NAI and five new “top” OPs and makes a decision on the OP. The process 

repeats until the operator is satisfied with the new OP............................................................60

Figure A-5. This proposed multistep OP finding process has a number of features presented....61
viii

List of Tables

Table 1. The 2006 pilot study objectives........................................................................................3

Table 2. The 2006 pilot study observations....................................................................................4

Table 3. The 2006 experimental objectives. ...................................................................................8

Table 4. Accepted OP finder/RSTA runs. ....................................................................................15

Table 5. Run schedule for area A1................................................................................................48

Table 6. Run schedule for area B9C. ............................................................................................50

Table 7. Run schedule for area B12..............................................................................................51

Table 8. Run schedule for area C4................................................................................................52

Table B-1. Summary data for area A1 runs. .................................................................................64

Table B-2. Summary data for area B9C runs................................................................................66

Table B-3. Summary data for area B12 runs. ...............................................................................68

Table B-4. Summary data for area C4 runs. .................................................................................69
ix

Acknowledgments

The authors are indebted to the engineers and technicians from General Dynamics Robotic 

Systems, including Brad Stuart, Susan Thornton, Pablo Pombo, Stacey Cape, Dan Myers, Mike 

Carpenter, Mike Hardesty, and Kenny Dunlap, and Robotic Research engineers Alberto Lacaze 

and Nenad Uzunovic for their technical and operational expertise in preparing and conducting 

the experiment.

The authors thank Derek Scherer from the U.S. Army Communications-Electronics Research, 

Development and Engineering Center for assisting with the data collection during the technology 

assessment and for reviewing this report.

Photographs courtesy of Robert Stenberg (L3/MPRI).
x

INTENTIONALLY LEFT BLANK.
1

1. Introduction

1.1 Technology Assessment

Unmanned ground vehicle tactical behavior is a continuing area of technology research and 

development. As the technology progresses, it is necessary to assess the technology in terms of 

the capability it provides to the Soldier. Data from assessments also conveys a state of the 

technology that the research community can use to track the progression of the technology over 

time.

As the ability for unmanned ground vehicles to perform complex tactical behaviors approaches,

there is a corresponding need to develop the methods and infrastructure required to assess these 

technologies in a relevant environment. The U.S. Army Research Laboratory (ARL) is working 

towards establishing means by which to assess unmanned technology, specifically in the area of 

autonomous tactical behaviors.

1.2 Background

The unmanned ground vehicle used in this tactical behaviors assessment was the experimental 

unmanned vehicle (XUV), described in other reports.

1

 1 Camden, R.; Bodt, B.; Schipani, S.; Bornstein, J.; Runyon, T.; French, F.; Shoemaker, C.; Jacoff, A.; Lytle, A. Autonomous 

Mobility Technology Assessment Final Report; ARL-TR-3471; U.S. Army Research Laboratory: Aberdeen Proving Ground, 

MD, 2005.

Each XUV is approximately 1588 kg 

(3500 lb), has four-wheel drive, and four-wheel steering. It is equipped with a suite of advanced 

technology in perception and intelligent control and an operator control unit (OCU) interface. 

Prior to 2007, this system was capable of traversing terrain in a relevant environment wherein the 

XUV followed, within a specified path tolerance, a route plan generated from course a priori data 

(deliberative layer planning). As designed, the exhibited behavior included reliance on 

autonomous mobility sensors and underlying algorithms to detect, classify, and react to local 

terrain features in an attempt to follow the prescribed path (perceptive layer planning). The 

resolution and accuracy of the a priori data used to generate the route path was often insufficient 

to enable the XUV to navigate without requiring it to negotiate scenarios, such as cul-de-sacs, 

from which the XUV could not autonomously extricate itself. The motivation for the recent 

work is to enable the XUV to use the best information available from multiple sources and to 

bridge the deliberative and perceptive-level planning such that the unmanned ground vehicle has 

the ability to use terrain features to tactical advantage including finding a suitable position from 

which to employ onboard reconnaissance surveillance target acquisition (RSTA) sensors for 

observing a named area of interest and planning its way out of untraversable situations and 

avoiding entering into those situations. The Robotics Program Office of ARL and General 

Dynamics Robotics Systems (GDRS) has engaged in exploratory assessments of technologies
2

that support these motivations. 2,3

1.3 Purpose of This Report 

 These exploratory assessments have provided opportunities to 

frame scenarios, protocol, infrastructure, and metrics for continued technology assessment while 

providing current data feedback for the architecture developers.

The purpose of this report is to document the results of an unmanned system tactical behaviors 

assessment conducted by ARL and GDRS on 4–14 February 2008. The purpose of the 

assessment was to examine the ability to use sensed information to locally orient the platform in 

order to obtain line of sight for an onboard RSTA system to scan a sufficient portion of a named 

area of interest (NAI); and, the impact of advances in deliberative layer planning technologies to 

enhance autonomous mobility in a relevant environment. The first purpose is addressed in the 

assessment of observation post finding and use of RSTA in section 2. The second purpose is 

addressed in the discussion of the interplay of information planning at multiple levels in section 

3. A summary and references are provided in sections 4 and 5.

2. Tactical Behaviors Using Observation Posts and RSTA

2.1 Background

Observation posts (OP), sometimes called observation points, are used to conduct reconnaissance 

and surveillance tasks, which are part of the RSTA function. OPs are locations from which 

Soldiers can observe enemy locations or movements as well as locate potential targets. There are 

many aspects to finding and occupying a good OP, as discussed in various Army field manuals 

(e.g., FM 3-20.98, Reconnaissance Platoon4

 2

Hill, S. G.; Bodt, B. A Field Experiment of Autonomous Mobility: Operator Workload For One and Two Robots. 

Proceedings of the 2007 ACM/IEEE Conference on Human-Robot Interaction (HRI’07), 169–176, 2007. 3 Childers, M.; Bodt, B.; Hill, S. G.; Dean, R.; Dodson, W.; Sutton, L. Assessing the Impact of Bi-directional Information 

Flow in Unmanned Ground Vehicle Operation: A Pilot Study; ARL-TR-4411; Aberdeen Proving Ground, MD, 2008. 4 Field Manual (FM) 3-20.98. Reconnaissance Platoon, Department of the Army, December 2002.

). Two important aspects of a good OP are (1) being 

able to see what you want to see and (2) to not be seen by the enemy.

For the purposes of exploring tactical behaviors for unmanned ground vehicles, we used the 

example of autonomously finding and occupying an OP. At the OP, the RSTA system on the 

XUV would, first, automatically take a mosaic (i.e., stitched photograph) of the previously 

identified NAI. The mosaic is then sent to an operator via the Soldier machine interface (SMI) 

within the OCU high-mobility, multipurpose, wheeled vehicle (HMMWV) located distant from 

the autonomous XUV. It is important to note that currently, the identification of a good OP is 

based solely on the amount of visibility to the area of interest. The selection of an OP which 
3

cannot be seen by the enemy will be addressed as the autonomous tactical behavior capability 

evolves.

2.2 Previous XUV OP Finding and RSTA Operations

When the capability to perform OP finding and RSTA operations autonomously by the XUV was 

in the concept phase, a pilot study for OP/RSTA operations was conducted from 17–20 April 

2006 at Fort Indiantown Gap, tactical maneuver area Bravo. A factorial design with four 

replicate runs was planned using noncommissioned officers from the U.S. Army Unit of Action 

Maneuver Battle Lab at Fort Knox, KY, as operators. The portion of the pilot study relating to 

OP/RSTA activities was primarily to demonstrate the capabilities in a field environment. An 

outline of the 2006 pilot study is given in table 1.

Table 1. The 2006 pilot study objectives.

Principle Factors

• Operator configurations: one operator/two robots, two operators/two robots

• Observation point (OP3, OP5)

• Display (screen, tablet)

Main Questions Addressed

• Assess span of control from one operator to two overseeing two robots

• Assess scalability of display (vehicle-mounted 18-in screen vs. 10-in portable tablet)

• Assess autonomous mobility changes in terms of speeds and interventions since TRL6

• Demonstrate analysis of OP location and mobility planner when occupying OP

• Demonstrate live RSTA

Twenty-four XUV runs were conducted during which the operator controlled one or two XUVs,

using either the HMMWV OCU or a tablet OCU. The XUV moved on one of two routes to an 

OP. Enroute to the OP, the XUV encountered preplanned, simulated targets at designated 

locations on the route. The operator was required to assess the target using the RSTA interface 

on the OCU. On arrival at the OP, the plan included the requirement for the XUV to scan the OP 

and find a suitable location providing visibility to the NAI. The observations resulting from this 

pilot study are in table 2. The 2006 pilot study is documented further in Hill and Bodt.

2

Following the pilot study, research was continued to improve the OP planning capability and the 

high-maneuverability planner (HMP) for small, precise XUV movements. Work also continued 

on a new stabilized RSTA system which would provide vastly increased capabilities over the 

RSTA used in the 2006 pilot study.
4

Table 2. The 2006 pilot study observations.

Operator Performance Observations

• Monitoring role during autonomous OP finding missions

• One operator could manage two robots (depending on mission specifics)

• Workload increased in two robot missions (over one robot)

• Communications network played a critical role in performance

• Critical information elements: communications network status, robot status, and RSTA 

camera icon

Human Factors Engineering Observations

• Screen and tablet both usable by Soldiers

• Specific suggestions made by Soldiers—image lists, teleop control for tablet, tying camera 

icon to image, etc.

Training Issues Observations

• Understand latency issues

• Understand bandwidth issues

• Understand robot behavior

Future Considerations

• Mission complexity (define, measure, manipulate)

• Collaboration (e.g., sharing robots among operators)

• Add and refine operator measures

2.3 The 2008 OP and RSTA Tactical Behavior Assessment Approach

The 2008 assessment was planned as a follow-up to the 2006 pilot study because of several key 

technology upgrades:

• Two OP finder algorithms had been further developed and integrated with a more capable 

HMP for precise relocations at the OP.

• A stabilized, multiple field of view (FOV) RSTA system had been completed and deemed 

ready for use.

The 2008 assessment activity included a number of XUV runs that comprised a short, preplanned 

mission, consisting of a start point, no more than one waypoint, and an OP, with an automatic 

RSTA of a NAI. At the OP, the OP finder algorithms used sensed data from a scan performed 

with the onboard laser detection and ranging (LADAR) sensor in order to identify locations from 

which the RSTA camera would have a large percentage (defined for each run) of the NAI 

visible. The HMP planned paths for the XUV to move to the identified OP. This was a 

successive operation in which an acceptable OP would be identified automatically, the XUV 

would move to that location; then a new sweep would either confirm that this was a good OP, or 

that this was not a good OP (based on new information from that point). If the location was not a 

good OP, the OP finder algorithms and HMP would repeat the process. After successive moves, 

either a good OP would be identified and occupied, or no good OP was found, or the planner was 

unable to move successfully to the identified good OP. All this activity was automatic; there was 

no operator input to the OP finder or HMP. The XUV with RSTA system is shown in figure 1.
5

Figure 1. XUV with RSTA system.

Once the XUV stopped moving (in either a good or a not good OP location), an automatic 

(preplanned) RSTA was taken. Each algorithm reported the success or failure to achieve a good 

OP. A good OP is defined as a location with visibility to the NAI exceeding a threshold value 

(usually 70% or 90%) considering all obstacles within the specified range of the LADAR (either 

20 or 40 m for this assessment). The operator would look at the RSTA image on the SMI, 

identify targets, and take additional RSTA images as desired to clarify his assessment of the 

visibility to the NAI and the identification of targets. This completed the mission run. Data 

collected included the SMI log, all RSTA images, RSTA metadata in extensible markup 

language (XML) files, the mission plan, and a screenshot from the end of the run. Activities 

throughout each run were manually collected by an observer. Each run lasted on the order of 

10 min. 

2.4 OP Courses Used in the 2008 Assessment

Four OP courses were selected to provide a variety of challenges in the way of near-field 

obstacles, distance to OP, differences in elevation, and availability of a priori feature data. Each 

course consisted of a short XUV move to an OP that overlooked a NAI. The NAI was populated 

with recognizable features such as silhouettes evenly spaced along a horizontal line, road 

intersections, a portable toilet, or other available recognizable features. 

To provide small variations in the OP locations, several closely spaced OPs were used at each 

site, normally within 10 m of the nearest OP. The notion was to determine sensitivity to original 

OP location. The four courses were (1) an OP at the crest of a small hill overlooking a roadway 

at 200 m (figure 2), (2) an OP behind a row of trees in a low-lying marshy area at 100 m

(figure 3), (3) an OP at the intersection of two trails looking up at a road and assembly area
6

Figure 2. NAI the “Hill” had a road in front of a tree line at 250 m.

Figure 3. NAI the “Swamp” was behind a tree line with a priori data.

900–1400 m away (figure 4), and (4) an OP among bushes and trees overlooking a building and 

road 1000 m away (figure 5). 

Silhouettes used as targets in the NAI were green plywood with painted white heads and white 

numbers (figure 6). The objective was to ensure that the targets were readily visible to the 

operator, if the targets were within the operator’s FOV and not obscured behind trees or other 

obstacles. The detection of the targets was not intended to challenge the ability of the operator to 

see and report, if indeed the targets were visible within the RSTA image.
7

Figure 4. NAI C4 had a road below a ridge line at 1–1.4 km.

Figure 5. NAI the “Barn” included the ARL building and road at 1.0 km.

2.5 Experimental Design

The original notion was to run four replicate runs for each algorithm against a specific NAI. The 

original OP location for each of the four runs would be altered by 10 m or so. If time permitted, 

an additional four runs for each algorithm would be done. The objectives for the experiment are 

presented in table 3. For numerous reasons, the original experimental plan could not be 

followed. The scope of the experiment was widened to explore several new variables, including 
8

levels of the visibility threshold value needed for achievement of a good OP, and the scan size,

which is the area in which the OP finder looks for a new OP. It was decided that two levels of 

visibility threshold would be used (70% and 90%). A fourth OP-NAI combination (the “Barn”) 

was added to expand the variety of OP locations used. At each location, we attempted to run a 

balanced number of runs but were precluded by weather and technical challenges. Seventy-two 

runs were completed with data collection.

Table 3. The 2006 experimental objectives.

Principal Factors

• OP finder – two independent technical approaches

• OP characteristics – range to NAI and size of NAI

Threshold - % of coverage of the NAI required to achieve a “good OP” (70%, 90%)

• Scan size – the area in which the OP finder searched for a “good OP” (20 m2, 40 m2)

• End point tolerance – distance from the new OP that HMP was required to achieve

Main Questions Addressed

• How well can the OP finder find a location near the OP that yields good intervisibility to the NAI taking 

into account only locally sensed obstacles?

• Each OP finder reported if threshold intervisibilty requirement was met (Y/N)

• Intervisibilty (coverage) was estimated from the RSTA scans taken at new OP

• How close to the new OP does HMP need to come?

Other Aspects Assessed

• RSTA operations

2.6 OP Finder Operation

Two OP finders were used in the experiment, OP finders “A” and “B.” The two OP finders were 

independent of each other; only one OP finder was used on each run. Both worked 

operationally the same. Their goal was to find a location near the OP which provided a measure 

of visibility to the NAI, which exceeded a threshold value. When the XUV came within the 

30-m waypoint tolerance of the OP, it automatically stopped and performed a wide-area LADAR 

scan. At that point the one of the OP finders was invoked and searched for one or more locations 

within an area defined by the scan size, which exceeded the visibility threshold. If at least one 

new good OP was found, the list of good OPs was passed to the HMP, which selected the new 

OP with the least mobility cost. If the current XUV location was one of those good OPs, the 

autonomous mobility portion of the scenario was completed and the RSTA scan of the NAI was 

automatically invoked. If the current location of the XUV was not a good OP, the HMP then 

moved the XUV to the new OP location (actually within x meters of the new OP, x being a 

variable set to 3 m). The process was then repeated beginning with a new wide-area LADAR 

scan. If, at any time, the OP finder could not find a good OP within an area defined by the scan 

size, the autonomous mobility portion of the scenario was completed and the RSTA scan of the 

NAI was automatically invoked. Figures 7–9 illustrate the OP finder process. 
9

Figure 6. Silhouettes.

Figure 7. OP finder process (1 of 3).

OP finder A considered both the information from the LADAR scan as well as any a priori data 

on obstacles between its location and the NAI. OP finder B considered only the information 

from the LADAR scan.

2.7 The 2008 Assessment Operations

The XUV was positioned at the start point, usually about 50–60 m from the OP. A plan was 

generated which took the XUV directly to the OP via one or more waypoints. At the OP, the 

plan commanded a RSTA scan of the NAI. The run configuration was checked (scan size, OP 

finder, etc.) and the plan was executed from the SMI in the HMMWV OCU. The XUV 

proceeded toward the OP until it came within the 30 m waypoint tolerance of the OP. At that 

point, the XUV halted and did a wide LADAR scan of area in front of the XUV. The OP finder 
10

Figure 8. OP finder process (2 of 3).

Figure 9. OP finder process (3 of 3).
11

used the LADAR returns to find one or more locations within an area defined by the scan size,

which exceeded the threshold. For 20 m, the planner algorithm would identify good OPs using 

only the closest 20 m of the LADAR scan. A list of OPs that met the threshold (e.g., 70%) 

would be made and the HMP would plan to one of the good OPs (not necessarily the best OP, it 

just had to meet the threshold). For the 40 m, the planner would identify good OPs using 40 m 

of the LADAR scan. A list of OPs that met the threshold would be made. If one of the good 

OPs was within 20 m, the HMP would choose an OP within 20 m and move to it. If there was no 

good OP within 20 m, but there was a good OP within 40 m, the HMP would move towards the 

perimeter of the original scan area and have a moving 20 m distance in which it could identify 

and plan to a good OP that satisfied the threshold. Again, it was not necessarily the best OP, just 

one meeting the criterion. Based on which direction the HMP moved towards the edge of the 

20 m, it would pick an OP to which it could plan. The area size that the HMP moves in can be 

changed, but this requires modification to the code. Therefore, for this assessment it was a given 

parameter. For the HMP, there is a trade-off on distance and amount of time it takes to make the 

plan.

2.8 Data Collection

Data collected included the SMI log, all RSTA images, RSTA metadata in XML files, the 

mission plan, and a screenshot from the end of the run. Activities throughout each run were 

manually collected by an observer. 

2.8.1 SMI Log Sample

A small sample from the SMI log is given in figure 10. The SMI log contains some indications 

of button pushes and actions from the data that is used by the SMI.

00:10:36.78 s1 XUV3 working towards wp 1

00:10:58.81 s1 XUV3 backing up

00:10:59.31 s1 XUV3 done backing up

00:11:22.79 s1 Button pressed [RSTA] ((select|view|show|display|look at|change to|switch to)

rsta[ display| view]) = selected

00:11:28.85 s1 Wca: XUV3 Advisory, Ready to Continue

00:11:28.85 s1 XUV3 state change Waiting

00:11:29.37 s1 selected mosaic 03400001

00:11:29.37 s1 XUV3 recon report

00:11:29.37 s1 Wca: XUV3 Advisory, Received RECON report

00:11:34.78 s1 Button pressed [] (zoom in) = unselected

00:11:56.44 s1 Button pressed [Mosaic: ] (mosaic) = selected

Figure 10. An example from an SMI log collected for each run.
12

2.8.2 Mosaic Sample 

The RSTA images were primarily mosaics, which are a series of images stitched together to 

make a single continuous image. The mosaics can be taken using different FOVs. An example 

of a mosaic with targets is given in figure 11. 

Figure 11. Mosaic of NAI from OP on the “Hill.” 

2.8.3 Mosaic Metadata Sample 

For each mosaic, there is some descriptive data about the each image that is stored in an XML 

file external to the SMI application itself. The descriptive data, including such items as the file 

name and field of view, are called metadata. An example of the mosaic metadata is given in 

figure 12. 

- <SMI> 

- <Recon muid="0x3400001" parent="0x00000000" back="0x03400001" camera="0" 

fov="20.1" host="148.33.195.21" file="m_0x03400001.jpg" 

localPath="Missions\SWAMP\rsta\Mosaic0x03400001.jpg" ftpStatus="3" left="0.20" 

right="0.67" top="0.22" bottom="6.13" name="03400001" activity="4" complete="100" 

created="1202412120" updated="4167632" active="0"> 

<utm zone="18" easting="361914.19" northing="4478621.50" elevation="-196.66" /> 

</Recon> 

</SMI> 

Figure 12. An example of RSTA mosaic metadata collected for each run. 

2.8.4 Screenshot Sample 

Figure 13 shows an example of a screen shot of the final map view of the SMI that was collected 

for each run. 
13

Figure 13. Screen shot of SMI following a mission at the “Swamp” OP. 

2.8.5 Plan Description Sample 

A plan description for each run was stored in an XML file external to the SMI application. The 

plan file was collected for each run. A sample of the plan description is shown in figure 14. 

- <SMI> 

<Plan muid="0x3200047D" name="plan 1" status="3" planError="" created="1202397400" 

updated="1202397400">(ramp XUV (move-on-route max-speed 4.40 (tolerance 30.00) 

(route waypoints (Z18N 4478721.0 361409.8 213.0 0x0) ) ) )</Plan> 

</SMI> 

Figure 14. An example of a plan description collected for each run. 

2.9 Data Reduction 

After the assessment was completed, the data collected were compiled into usable forms. These 

data are described in the following subsections. 

2.9.1 Run Identifiers 

Each run was given an identifying number and was characterized by several independent factors: 

• OP finder algorithm used (A or B) 

• OP course (one of the four courses) 

• Threshold (% of visibility criterion, usually 70% or 90%, with a few 60% or 80%) 
14

• Scan size (20 or 40 m)

• Specific OP location (several at each course)

2.9.2 Dependent Measures 

Four primary dependent measures were obtained for each run. The first was a “yes” (Y) or “no”

(N) for each run as to whether a good OP had been reported by the OP finder software. The 

second measure was the number of repositions that were made for each run, i.e., the number of 

times the XUV moved to a new OP position. The third was the number of targets reported by the 

operator at the time of the first automatic RSTA image appearing. Finally, the fourth measure 

was obtained from the RSTA images after the assessment was completed; this resulted in the 

RSTA picture analysis estimate of the percentage observed of the NAI.

2.9.3 RSTA Picture Analysis 

The RSTA picture analysis was an effort to obtain an independent estimate of the amount of 

coverage of the NAI that was actually observed within the RSTA photograph (i.e., the actual 

threshold). Two independent raters estimated the amount of coverage of the NAI (from 0% to

100%), ratings were compared and a final coverage estimate (in percent) was achieved. Since 

the LADAR scan for OP finding only used the scan size (i.e., 20 or 40 m) in which to search, the 

RSTA picture analysis only considered occluded views in the 20- or 40-m range (whichever is

appropriate for each run). That is, if there were trees occluding the view to the NAI within 20 m

(or 40 m) of the XUV (the RSTA picture origin), then they were considered as blocking the 

coverage of the NAI. However, if trees were located in the distance (further than the 20 or 

40 m), those trees were not considered as blocking the coverage of the NAI. The RSTA picture 

analysis yielded an estimate of coverage for each run.

2.9.4 Accepted Runs

Because of a variety of extraneous occurrences, a number of the 72 runs were not suitable for use 

in any data analysis. These reasons included heavy snow and fog obscuring RSTA pictures, 

emergency stops (E-stops), software crashes, and RSTA failures. Thus, only the 57 remaining 

runs in table 4 were included in the data analysis.

2.10 Human Factor Discussion

A number of human factors observations were made during the technical assessment of the OP 

finders and HMP. As part of this assessment, the RSTA functions were used and observations 

made. 
15

Table 4. Accepted OP finder/RSTA runs.

Run Algorithm Site Threshold Tolerance

Scan 

Size NAI

No. 

Repositions

Good 

OP

No. 

Targets

Coverage

Estimate

9 B Hill 70 3 20 A (left) 0 N 3 40

11 B Hill 70 3 20 A (left) 4 Y 3 80

12 B Hill 70 3 20 A (left) 2 Y 2 20

13 A Hill 70 3 20 A (left) 0 Y 2 30

14 A Hill 70 3 20 A (left) 0 Y 2 30

16 A Hill 70 3 20 A (left) 1 Y 2 70

17 A Hill 70 3 20 B (right) 0 Y 6 60

18 A Hill 70 3 20 B (right) 0 Y 2 20

19 A Hill 70 3 20 B (right) 0 Y 0 20

20 A Hill 70 3 20 B (right) 1 Y 3 50

21 B Hill 70 3 20 B (right) 4 Y 8 80

22 B Hill 70 3 20 B (right) 1 Y 8 80

23 B Hill 70 3 20 B (right) 1 Y 4 70

24 B Hill 70 3 20 B (right) 9 Y 7 90

25 B Swamp 70 3 20 A 0 N 1 20

26 B Swamp 70 3 20 A 0 N 3 20

27 B Swamp 70 3 20 A 0 Y 0 0

28 B Swamp 70 3 20 A 3 N 4 30

29 A Swamp 70 3 20 A 0 N 1 20

30 A Swamp 70 3 20 A 0 N 2 20

33 A Swamp 70 3 20 A 0 N 5 60

34 A Swamp 70 3 20 A 0 N 3 80

35 A Swamp 70 3 20 A 0 Y 7 80

37 B Swamp 70 3 20 A 1 Y 4 70

38 B Swamp 70 3 20 A 1 Y 6 80

39 B Swamp 70 3 20 A 0 Y 6 80

41 A C-4 70 3 20 B 1 Y 0 40

42 A C-4 70 3 20 B 1 Y 0 60

43 A C-4 70 3 20 B 0 Y 0 100

45 B C-4 70 3 20 B 0 Y 0 100

46 B C-4 70 3 20 B 0 Y 0 50

47 B C-4 70 3 20 B 0 Y 0 100

50 A Swamp 70 3 20 A 0 N NA 0

51 A Swamp 70 3 20 A 0 N NA 0

52 A Swamp 70 3 20 A 0 N NA 0
16

Table 4. Accepted OP finder/RSTA runs (continued).

Run Algorithm Site Threshold Tolerance

Scan 

Size NAI

No. 

Repositions

Good 

OP

No. 

Targets

Coverage 

Estimate

53 A Swamp 70 3 40 A 2 Y NA 80

54 A Swamp 70 3 40 A 2 Y NA 40

55 A Swamp 80 3 40 A 3 Y NA 80

56 A Swamp 90 3 40 A 1 Y NA 50

59 A Hill 70 3 40 B (right) 2 Y NA 50

61 B Hill 70 3 40 B (right) 4 N NA 50

64 B Hill 60 3 40 B (right) 5 N NA 60

65 A Hill 70 3 40 B (right) 0 Y NA 30

66 A Hill 80 3 40 B (right) 1 Y NA 20

67 A Hill 90 3 40 B (right) 0 Y NA 20

68 A Hill 90 3 40 B (right) 4 Y NA 50

69 B Hill 70 3 40 B (right) 5 Y NA 30

70 B Hill 70 3 40 B (right) 6 Y NA 100

80 B B-OP 70 3 40 Barn 0 Y NA 90

82 A B-OP 70 3 40 Barn 0 Y NA 100

83 A B-OP 90 3 40 Barn 0 N NA 80

84 A B-OP 70 3 40 Barn 0 N NA 0

85 A B-OP 90 3 40 Barn 0 N NA 50

86 B B-OP 70 3 40 Barn 1 Y NA 100

87 B B-OP 90 3 40 Barn 1 Y NA 70

88 B B-OP 70 3 40 Barn 2 Y NA 60

90 A B-OP 70 3 40 Barn 1 Y 0 60

As discussed earlier, the assessment activity included a number of runs that comprised a short, 

preplanned mission, consisting of a start point, no more than one way point, and an OP with an 

automatic RSTA of an NAI. This mission was executed by the XUV. The two OP finder 

algorithms were used to identify locations from which the RSTA camera would have a large 

percentage (defined for each run) of the NAI visible. The HMP planned paths for the XUV to 

move to the identified OP. This was a successive operation in which an acceptable OP would be 

identified automatically, the XUV would move to that location; then a new sweep would either 

confirm that this was a good OP or that this was no longer a good OP (based on new information 

from that point). If no longer a good OP, the OP finder algorithms and HMP would try to 

identify and move to a better location. After successive moves, either a good OP would be 

identified and occupied or no good OP was found or the planner was unable to move

successfully to the identified good OP. All this activity was automatic; there was no operator 

input to the OP finder or HMP.
17

Once the XUV stopped moving (in either a good or a not good OP location), an automatic 

(preplanned) RSTA was taken. The operator would look at the RSTA image on the SMI, 

identify targets, and take additional RSTA images as desired. This then completed the mission 

run and data were saved for later analysis. Each run lasted on the order of 10 min.

The operators were technical assessment team members. The analysis of the OP finder and HMP 

are addressed separately. These observations are from a user/operator perspective and are 

presented in two major parts: (1) observations on the OP finder and HMP part of the mission 

and (2) observations about using the RSTA functions and resulting images.

2.10.1 OP Finder and HMP Human Factor Observations

1. OP finder status messages to the operator are inadequate. Currently, when the XUV 

achieves the OP given in the mission plan (within whatever point tolerance is set), the 

XUV immediately starts using the OP finder software. This is indicated on the status bar 

on the SMI by showing “sweeping OP,” indicating that the LADAR is now sweeping to 

obtain data for the OP finder algorithms. No other status information on the OP scanning 

process is sent to the operator. 

2. This tactical behavior and the required interplay between XUV and operator are not well 

defined. The OP finding tactical behavior assessed here demonstrated the ability to execute 

scripted behaviors that would identify a location meeting a visibility threshold and then 

move to that identified location. The operator was not involved in these scripted behaviors, 

other than to make an initial identification of a possible observation point. Now that this 

ability has been demonstrated, future tactical behavior implementation should be defined 

thoughtfully to include the potential role of the operator, the operational requirements of 

the Soldier, and the expertise that the Soldier could contribute to achieving the goals of the 

tactical behavior.

3. Software developers remained and were required to be in-the-loop during the technology 

assessment. Currently several parameters were set for each run by the software developers. 

The question becomes if these parameters should be adjustable for operators and what the 

appropriate range of the parameters should be. Additional work needs to be done on 

defining how the OP tactical behavior will work and what options will be available to the 

operator. For near-term technical assessments, the operator should be able to set those 

parameters for each run and receive the information on good/not good OP location and 

repositioning. All this data should be included within the SMI log.

4. Status messages are ambiguous or incomplete. There are a number of operator messages 

that can be displayed, some requiring intervention and others providing status information 

only. Initially, these messages were aimed toward mobility—to explain why the XUV 

wasn’t moving. As other messaging is implemented, for example sweeping OP and other 

messages associated with OP tactical and RSTA functions, an individual message could 
18

possibly have some ambiguous meanings. For example, the current status “pause” 

indicates a pause in mobility. 

However, as other functions are executed (like RSTA) could “pause” also be interpreted as a 

pause in the execution of another task? Stated another way, are there any messages that are 

possibly misinterpreted or ambiguous as the ability of the operator to control additional functions

increases? As new functions and capabilities increase, it would be useful to revisit the entire set 

of messages to ensure that status and intervention messages are clear and useful to the operator.

2.10.2 RSTA Human Factor Observations

1. RSTA “blue lines” did not convey the information which was intended. Blue lines, 

forming an angle, are placed on the map view when a RSTA has been taken. This gives an 

indication of the angular coverage (i.e., the reconnaissance straight line) across which a 

RSTA mosaic has been taken. Multiple blue lines will be displayed and overlay each 

other; it is difficult to distinguish among them and to make “pairs” of the lines. The blue 

lines do not extend to the NAI to see if the reported RSTA coverage is the same as what

was intended. Each pair of blue lines is not associated with a particular mosaic, through 

labeling or other means, so it is difficult to check the map view vs. the actual image. 

Therefore, the blue lines are not as useful as they could be. 

2. RSTA image file names were not unique and had no meaning to the operator. Currently, 

the image file names are assigned by the SMI to each individual image. The current file 

names are not meaningful to the operator, with the exception of the sequence numbering at

the end. So, for example, a mosaic image could be called Mosaic0×03400014 and the next 

in sequence is called Mosaic0×03400015. Snapshots and chips are named in a similar way. 

Some mosaics also have a letter at the end, e.g., Mosaic0×03400001B. Operators can 

currently change the mosaic name on the RSTA screen, but it does not change the file 

name under which the image is stored. We also observed that the same file names are used 

for different images, when RSTA images are taken on different days, times, and missions 

over a number of runs. 

3. Status of RSTA operation and images not readily apparent to the operator. In the recent 

technical assessment, the operator would infer a RSTA picture was taken by the “pause” 

status during the OP tactical behavior. A camera icon appears and a RSTA mosaic 

rectangle shows on the RSTA screen and gives a percentage complete indication for 

downloading the image from the XUV to the SMI. The operator would then open the 

image for display on the SMI.

Some RSTA scans that required a mosaic would stop before the mosaic had been completed. No 

indication of the premature stop was given to the operator nor indicated on the mosaic. No other 

information about the premature stop was given. Also, it would be helpful to have information 

on the status of the RSTA operation. Currently, the taking of a RSTA scan is inferred; 
19

sometimes transmission of images is affected negatively by the communications network and 

status (picture taken? picture available? picture complete?) is not readily available. With 

additional information, the operator might choose to take another RSTA scan in the same or 

different location.

4. Mosaic and submosaics processes were confusing to the operator. There are multiple 

FOVs available, ranging from 1.3° to 20°. Each mosaic is a set of multiple images of a 

particular FOV stitched together to make one larger image. The top level is 20° FOV. 

Within each FOV, the operator can manually zoom in to different levels to see the image. 

A submosaic is when a smaller area within the original mosaic is chosen, by drawing a box 

around it, and a series of images are stitched together to make an image. The submosaic 

can be taken using the same or a different FOV.

Several observations were made. Currently, you can take a submosaic only from the original 

mosaic, i.e., you cannot identify a submosaic on a zoomed in image. This then requires the 

operator to remember what kind of image is being viewed and to (possibly) click on another 

image or to unzoom in order to get a submosaic. An operator should be able to execute a 

function, like a submosaic, from any location and not have to remember a current image state or 

how to get to a required image state. 

Another observation is that the FOV changes automatically to the next lower level after a mosaic 

is taken. For example, if an automatic RSTA is taken at 20° FOV, the FOV button is 

automatically changed to the 10° FOV choice. This can be confusing to the operator, especially 

since there is no other easily accessible data that provides information about a particular image 

and FOV for that image.

Finally, the box used to choose the area for a submosaic can be drawn outside of the original 

mosaic image. It could be misinterpreted that drawing the submosaic box outside of the mosaic 

photo could capture an image outside the original mosaic (it can’t).

5. RSTA mosaic failed on occasion because of memory allocation problems and failed to 

inform the operator of the failure. Currently there are memory limitations within the SMI 

for the size of the RSTA images that can be taken. The few times that the limits were 

exceeded, the RSTA failed by just stopping, showing 0% complete and hanging up at that 

point. No additional information was given to the operator. The XUV had to be rekeyed. 

The times when the memory limits were reached seemed to be related to taking long (i.e., 

wide) scans at narrow FOVs.

Possible alternatives should be explored, such as increasing memory, providing guidance to the 

operator on allowable images, and including real-time status messaging on submosaic limits. 

Also, possible ideas expressed by a RSTA software developer include “poor man’s stitching” 

where the mosaic is imprecisely put together, trading speed with precision and memory. Another
20

idea was to divide the single mosaic into multiple smaller images—this might become a decision 

that the operator could make.

6. Manual RSTA is very difficult on the RSTA SMI. Currently, for manual RSTAs, a set of 

boxes attached by a line is presented on the RSTA map screen when manual RSTA is 

chosen. These boxes are very difficult to manipulate on the small RSTA map screen, in 

many cases being almost hidden behind the XUV icon. The manipulation was particularly 

difficult when the NAI was a longer distance away, on the order of >1 km away. For the 

view we had, the XUV icon always had to stay on the RSTA screen, which then required 

the map be zoomed out to a scale where features were small. The boxes were difficult to 

place on exact locations when the map was such a small scale. Even if the XUV did not 

have to be on the same map, you might want the XUV and the NAI displayed together to 

get a sense of what you were investigating.

2.11 General Observations

2.11.1 Weather Effects

On a number of runs, rain and snow clouded the lens cover of the RSTA system and interfered 

with the quality of the RSTA picture and with the proper creation of a mosaic. This limited the 

number of runs in which meaningful data and pictures could be collected. Examples of RSTA 

images taken during rain and fog are shown in figures 15 and 16.

Figure 15. Fog at NAI.

Figure 16. Rain and fog at NAI.
21

2.11.2 XUV Azimuth at OP 

On several occasions, the XUV arrived at the new OP on an azimuth pointing away from the 

NAI, making the wide-area LADAR scan ineffective in determining the suitability of the new 

OPs. This yielded false OP finder algorithm results since no obstacle could be seen between the 

XUV and the NAI. An example of a screen shot that shows the XUV (the numbered rectangle) 

pointing away (to the bottom of the screen) instead of towards the NAI (the orange line) is 

shown in figure 17. 

Figure 17. XUV at OP pointing away from NAI. 

2.11.3 OP Finder Improves the Quality of the Location Selected as an OP 

The data analysis shows that the OP finder algorithms improve the quality of selection of an OP 

location. 

2.11.3.1 Algorithm Reported Results. There were 57 runs used in this data analysis. Using the 

algorithm-reported results, when the XUV arrived at the originally designated OP, that location 

was a good OP on 16 of the 57 runs (28%) (figure 18). The initial location for 13 of 57 runs 

(23%) was not a good OP, and the OP finder could not find an alternate OP that met the 

threshold requirements for visibility to the OP. The remaining 28 runs continued on with the OP 

finder looking for an acceptable OP location. 
22

Figure 18. Initial decision at OP.

When OP finder was invoked and repositioning took place, an additional 25 of 28 good OPs

(89%), reported by the algorithm were found (figure 19). Thus, when the OP finder could find 

an acceptable OP, the HMP was successful in moving the XUV to a location with acceptable 

visibility to the NAI. 

Figure 19. Final decision with repositioning.
23

Overall, 41 of the 57 runs (72%) resulted in a good OP as reported by the algorithms. 

Performance by individual algorithms is shown next.

2.11.3.2 Algorithm A Reported Results. Using the algorithm A reported results on 32 runs,

when the XUV arrived at the originally designated OP, that location was a good OP on 10 of the 

32 runs (31%) (figure 20). The initial location for 10 of the 32 runs (31%) was not a good OP, 

and OP finder A could not find an alternate OP that met the threshold requirements for visibility 

to the OP. The remaining 12 runs continued on with OP finder A looking for an acceptable OP 

location.

Figure 20. Initial decision at OP (algorithm A).

When OP finder A was invoked and repositioning took place, an additional 12 of the 12 good 

OPs (100%), reported by the algorithm, were found (figure 21). Thus, when OP finder A could 

find an acceptable OP, the HMP was successful in moving the XUV to that location where there 

was acceptable visibility to the NAI. 

Overall, 22 of the 32 runs (69%) resulted in a good OP as reported by algorithm A.

2.11.3.3 Algorithm B Reported Results. Using the algorithm B reported results, when the XUV 

arrived at the originally designated OP, that location was a good OP for six of the 25 runs (24%) 

(figure 22). The initial location of three of the 25 runs (12%) was not a good OP, and OP finder 

B could not find an alternate OP that met the threshold requirements for visibility to the OP. The 

remaining 16 runs continued on with OP finder B looking for an acceptable OP location.
24

Figure 21. Final decision with repositioning (algorithm A).

Figure 22. Initial decision at OP (algorithm B).

When OP finder B was invoked and repositioning took place, an additional 13 of 16 good OPs

(81%), reported by the algorithm, were found (figure 23). Thus, when OP finder B could find an 

acceptable OP, the HMP was successful in moving the XUV to that location where there was 

acceptable visibility to the NAI. 
25

Figure 23. Final decision with repositioning (algorithm B).

Overall, 19 of the 25 runs (76%) resulted in a good OP as reported by algorithm B.

2.11.3.4 RSTA Picture Analysis Results. The RSTA picture analysis somewhat tempers the 

results reported by each algorithm. Using the same 57 runs, the RSTA pictures were analyzed 

and coverage of the NAI estimated. Using the RSTA picture analysis of the OP locations, when 

the XUV arrived at the originally designated OP, that location was a good OP for eight of the 57

runs (14%) (figure 24). The initial location for 21 of the 57 runs (37%) was not a good OP, and 

the OP finder could not find an alternate OP that met the threshold requirements for visibility to 

the OP. The remaining 28 runs continued on with the OP finder looking for an acceptable OP 

location.

When the OP finder was invoked and repositioning took place, an additional 13 of 28 good OPs 

(46%), analyzed by the RSTA pictures, were found (figure 25). Thus, when the OP finder could 

find an acceptable OP, the HMP was successful in moving the XUV to that location where there 

was acceptable visibility to the NAI. 
26

Figure 24. Initial decision at OP (RSTA picture analysis).

Figure 25. Final decision with repositioning (RSTA picture analysis).

Overall, 20 of the 57 runs (37%) resulted in a good OP based on the RSTA pictures.

2.11.3.5 Algorithm A RSTA Picture Analysis Results. Using the RSTA picture analysis results, 

when the XUV arrived at the originally designated OP, that location was a good OP for four of 

the 32 runs (13%) (figure 26). The initial location for 16 of the 32 runs (50%) was not a good 

OP, and OP finder A could not find an alternate OP that met the threshold requirements for 

visibility to the OP. The remaining 12 runs continued on with OP finder A looking for an 

acceptable OP location.
27

Figure 26. Initial decision at OP – algorithm A (RSTA picture analysis).

When OP finder A was invoked and repositioning took place, an additional three of 12 good OPs

(25%), based on analysis of the RSTA pictures, were found (figure 27). Thus, when OP finder A 

could find an acceptable OP, the HMP was successful in moving the XUV to that location where 

there was acceptable visibility to the NAI. 

Figure 27. Final decision with repositioning – algorithm A (RSTA picture analysis).
28

Overall, seven of the 32 runs (22%) resulted in a good OP by algorithm A based on the RSTA 

picture analysis.

2.11.3.6 Algorithm B RSTA Analysis Results. Using the RSTA picture analysis results, when 

the XUV arrived at the originally designated OP, that location was a good OP for four out of the 

25 runs (16%) (figure 28). The initial location of five out of the 25 runs (20%) was not a good 

OP, and OP finder B could not find an alternate OP that met the threshold requirements for 

visibility to the OP. The remaining 16 runs continued on with the OP finder looking for an 

acceptable OP location.

Figure 28. Initial decision at OP – algorithm B (RSTA picture analysis).

When the OP finder was invoked and repositioning took place, an additional 10 of 16 good OPs

(63%), based on analysis of the RSTA pictures, were found (figure 29). Thus, when OP finder B 

could find an acceptable OP, the HMP was successful in moving the XUV to that location where 

there was acceptable visibility to the NAI. 

Overall, 14 of the 25 runs (56%) resulted in a good OP by algorithm B based on the RSTA 

picture analysis.

2.11.4 Algorithm Reporting vs. RSTA Picture Analysis

The assessment of visibility to the NAI made by both algorithms is optimistic compared to 

RSTA picture analysis. Based on all runs, algorithm A’s performance drops from 69% 

self-reported good OPs to 22% RSTA picture analysis good OPs. Algorithm B’s performance 

drops from 76% self-reported good OPs to 56% RSTA picture analysis good OPs (figure 30). 

This indicates that the reported NAI coverage is not well calibrated to the actual coverage, 

assuming that the RSTA picture analysis yields more accurate coverage estimates.
29

Figure 29. Final decision with repositioning – algorithm B (RSTA picture analysis).

Figure 30. OP finder performance across all 57 runs.

2.11.5 OP Finder Works 

In general, OPs reported as good OPs had better coverage than those that were not good OPs, 

both when the good OP was reported by the algorithm (algorithm reported) or determined on the 

basis of the RSTA picture analysis. An algorithm reported good OP (“Y”) yielded better 

coverage (algorithm A = 52%, algorithm B = 71%) of the NAI, as estimated by the RSTA 

picture analysis, than an algorithm reported “N” (algorithm A = 31%, algorithm B = 37%) 

(see figure 31).
30

Figure 31. RSTA picture analysis mean coverage.

When the runs from the Hill OP are removed from the data, the RSTA picture analysis yields 

similar results between algorithms, based primarily on the low RSTA analysis coverage of 

algorithm A on the runs at the Hill OP (figure 32). 

Figure 32. RSTA picture analysis mean coverage (Hill data removed).
31

2.11.6 Scan Size Relevance

When repositioning was required to achieve the requested coverage threshold, there is no 

compelling evidence that scan size was a significant factor. Based on the algorithm-reported

results, scan size of 40 m may achieve better results; however when measured against the RSTA 

picture analysis, the results trend in the opposite direction and are inconclusive. This is shown in 

figure 33.

Figure 33. OP finder performance vs. scan size.

When further examined, based on individual algorithms, the difference between 20- and 40-m

scan size when the algorithm reported results, was primarily due to algorithm A’s performance 

where 40-m scan size significantly improved the chances of finding a good OP (figure 34).

2.11.7 OP Location Variance

Finding a good OP may be dependent on the “goodness” of the original OP selection input by the 

operator. OPs input by the operator actually used in the planned runs were varied slightly 

(±10 m) around the original OP. There were several instances when the variation of the OP 

location seemed to the data collectors and operator to result in differing levels of visibility 

achieved by the OP finder. This observation is not supported strongly by data, but the robustness 

of the OP finder with regard to original OP location as input by operator should be explored in 

future assessments.

2.11.8 Algorithm Performance

Algorithm B performed better than algorithm A in achieving good OPs in both methods of 

determining a good OP (for Y or N responses, and in the RSTA picture analysis) (figure 35).
32

Figure 34. OP finder performance vs. scan size vs. algorithm.

Figure 35. Difference in algorithm performance.
33

2.11.9 Variable Ranges

Results did not indicate the correct ranges of values for threshold and scan size. End point 

tolerance was not varied and hence not evaluated.

2.11.10 Elevation Calculations

Differences in elevation calculations between the RSTA camera on the XUV, obtained through

the XUV navigation system and the elevation of the NAI obtained from a priori data, may have 

affected the quality of the RSTA picture if the a priori data was significantly different from the 

actual and the NAI was close to the OP. 

2.11.11 Silhouettes

Silhouettes with white heads were more easily seen in the RSTA pictures than silhouettes with 

red, yellow, or orange heads. 

2.12 Recommendations Resulting From the OP Finding/RSTA Technical Assessment

2.12.1 General

1. Continue improvements of both OP finder algorithms. Both approaches performed 

sufficiently well to continue their advancement.

2. Calibrate the OP finder visibility estimation on a static, well-defined test area prior to next 

field experiment.

3. When stopping at a new OP after a repositioning, the HMP should leave the XUV pointing 

to within 45° of the center of the NAI.

4. Generate a more complete OP finder definition (see appendix A). The current approaches 

are initial efforts and a more refined definition can be generated based partially on what has 

been learned during this assessment.

2.12.2 OP Finder and HMP Human Factor Recommendations

1. In the near term, implement appropriate operator status messages used for OP finders onto 

the SMI. Report these messages (at least the change in state of the messages) in the SMI 

log for further analysis. Whether these status messages need to be displayed in the long 

term, as the behavior becomes more sophisticated and reliable, is an open question (see 

section 2.10.1).

Define OP tactical behavior process and the required interplay between XUV and operator. 

Identify which parameters should be available to operators for their decision and use. Implement 

the choices and appropriate messaging into the SMI. 
34

As the OP tactical behavior is further developed, determining the best process for “OP finding” 

will include active consideration of the part that the operator will play in assessing the adequacy 

of the identified OPs. Certainly there are circumstances when a given XUV location is “good

enough” for a particular purpose; other times when more precision is required by the operator. It 

is probable that an interplay between the OP finder/HMP and the operator will need to occur—

the XUV will find a location that satisfies its internal OP finder/HMP software criteria, present 

that to the operator who may, in turn, find that location “good enough” or provide revised 

parameters for another try, or even teleoperate. The possible interactions between the operator 

and the SW/HW should be explored, identified and a good process defined and implemented via 

the SMI. One potential process to define the OP tactical behavior is presented in appendix A.

2. Remove software developers from being in-the-loop during the next assessment. For nearterm technical assessments, the operator should be able to set those parameters for each run 

and receive the information on good/not good OP location and repositioning. All this data 

should be included within the SMI Log.

3. Revisit all status messaging to ensure status messages are clearly interpretable by the 

operator. There are a number of operator messages that can be displayed, some requiring 

intervention and others providing status information only. Initially, these messages were 

aimed toward mobility—to explain why the XUV wasn’t moving. As other messaging is 

implemented, for example, sweeping OP and other messages associated with OP tactical 

and RSTA functions, an individual message could possibly have some ambiguous 

meanings. For example, the current status “pause” indicates a pause in mobility. However, 

as other functions are executed (like RSTA) could “pause” also be interpreted as a pause in 

the execution of another task? Stated another way, are there any messages that are possibly 

misinterpreted or ambiguous as the ability of the operator to control additional functions 

increases? As new functions and capabilities increase, it would be useful to revisit the 

entire set of messages to ensure that status and intervention messages are clear and useful 

to the operator.

2.12.3 RSTA Human Factor Recommendations

1. Revise the display and use of RSTA “blue lines.” The RSTA blue lines (defined in section 

2.10.2) are not as useful as they could be. Recommend examining how the blue lines could 

be improved for operator use. 

2. Make image file names meaningful and unique. All images need to be given a unique 

name and file name meaningful to the operator, such as a date-time-group or vehicle stamp. 

3. Make status of RSTA operation and images available to operator. Include easily accessible 

and meaningful metadata for each RSTA image within the SMI. Explore the range of 

issues concerning RSTA image management. Metadata that is easily accessible and readily 

understandable by Soldiers is needed for RSTA images and should be available within the
35

SMI. The images should also be able to be easily accessible, categorized, manipulated, and 

compared. Perhaps time/date stamps should be superimposed on the images themselves (as 

current commercial technology does). Labels should be meaningful. Applications are 

currently available that allow keywords and other data to be associated with each image 

and provide the ability to sort and display images.

Whether or not all of this is included within the current SMI is an open question. However, these 

kinds of “image management” issues should be explored if RSTA functions are to be integrated 

into the XUV operator tasks. First, operator functions required for image and reconnaissance 

management should be identified. Seeing how commercial software handles these required 

functions is another useful step. Exploring alternative interface ideas and integration of these 

ideas with other XUV functions will also be needed.

4. Revise particular FOV and submosaics elements. An operator should be able to execute a 

function, like a submosaic, from any location and not have to remember a current image 

state or how to get to a required image state. 

Do not decrement the FOV automatically after taking a mosaic. For example, if an automatic 

RSTA is taken at 20° FOV, the FOV button is automatically changed to the 10° FOV choice. 

This can be confusing to the operator, especially since there is no other easily accessible data that 

provides information about a particular image and FOV for that image.

Limit the designation of a submosaic to an area within the original mosaic. The box used to 

choose the area for a submosaic can be drawn outside of the original mosaic image. It could be 

misinterpreted that drawing the submosaic box outside of the mosaic photo could capture an 

image outside the original mosaic (it can’t).

5. Address memory limitations for RSTA images within SMI. Workarounds should be 

explored, such as increasing memory, providing guidance to the operator on allowable 

images, include real-time status messaging on submosaic limits. Also possible ideas 

include a “poor man’s stitching” where the mosaic is imprecisely put together, trading 

speed with precision and memory.5

 5Pombo, P. General Dynamics Robotic Systems, Westminster, MD. Personal communication, 11 February 2008.

 Another idea was to divide the single mosaic into 

multiple smaller images—this might become a decision that the operator could make.

6. Make manual RSTA operations easier. The manual RSTA assignment needs to be made 

easier. If the RSTA map view is primarily for manual RSTAs, perhaps the map should be 

larger or other ways should be provided to examine manual RSTAs from a map view. This 

is particularly critical when the RSTA boxes are used for elevation data, as they are for 

RSTA and OP finding tasks.
36

2.12.4 Experimentation Methodology Recommendations

1. Include both OP finders, visibility threshold, scan size and end point tolerance, and OP 

location variance as variables in the next technology assessment.

2. When operating in rain or snow, operations SOP should include cleaning the RSTA lens 

cover.

2.13 Conclusions From the OP Finding/RSTA Technical Assessment

The OP finders and the HMP combined to successfully demonstrate that locally sensed terrain 

and feature data can be successfully utilized to find and move the XUV to an OP location with 

improved visibility to the NAI. Recommendations for improved performance and follow-on 

assessments were made.

3. The Interplay of Information Planning at Multiple Levels for UGV 

Mobility

3.1 Background

In FY 2003, ARL and GDRS conducted, with testing oversight by the National Institute of 

Standards and Technology, an extensive three-site experiment of an autonomous navigation 

system (ANS).1 The ANS relied on perceptive level planning to achieve a manually 

predetermined route of way points in rolling desert, rolling vegetated and urban terrain. This 

system was capable of traversing terrain while following a route plan, within a specified path 

tolerance, that was generated from course a priori data (deliberative layer planning). In this 

instantiation, the XUV relied on autonomous mobility sensors and underlying algorithms to 

detect, classify, and react to local terrain features in an attempt to follow the prescribed path 

(perceptive layer planning). The Future Combat Systems used this study as part of the 

evaluation that led to a Technology Readiness Level 6 designation for the ANS. Interim 

advances in the Soldier machine interface (SMI) have greatly simplified manual route planning, 

while perception algorithms and hardware continued to mature. More recent developments in 

the architecture allow for deliberative planning in a move toward tactically intelligent behaviors. 

Higher-level deliberative planning draws on the objective of the operation and the global map of 

a priori information, which consists of elevation and terrain feature data for the area of 

operations in order to develop a long-range path plan. Deliberative planning consists of separate 

layers to independently assess costs for traversing terrain in the context of mission constraints to 

include point-to-point mobility, time to arrive, coverage of co-combatants, exposure to potential 

threats, and presence of confirmed threats. Those layers are combined using a weighted heuristic 

into a single planning layer for use by the route planning algorithm. Different weight 

combinations map into various tactical concepts, which allow the user to specify explicit choices
37

such as “prefer roads” or “stealth”; weights can be individually set during experimentation. 

Deliberative and perceptive level planning are integrated through the field cost interface (FCI).

Perceptive planning generates local paths for the vehicle to follow at a rate of ~5 Hz. The 

maximum planning distance for local paths is 60 m, which is limited by the range of the 

vehicle’s sensors. The perceptive-level planner follows the long-range plan by navigating to the 

first route point that is more than 60 m away from the vehicle. When the vehicle is within 60 m

of the current route point, the perceptive layer planner picks a point in its search graph closest to 

the route point and selects the cheapest out of all possible trajectories from the vehicle to that 

point. The cheapest trajectory is chosen based on its cost, which takes into consideration several 

parameters, such as length, terrain complexity, presence of obstacles, and others. With this 

approach, the vehicle attempts to follow the long-range plan as closely as it can because the 

vehicle is always trying to get to some point on the plan. If the operator does not initiate a 

replan, the long-range plan does not change throughout the course of the mission.

FCI is a feature that provides a bridge between deliberative layer planning and perceptive layer 

(local) planning by generating a so-called “cost field,” a set of costs to get from any point on a 

60-m radius circle centered at the vehicle to the next waypoint (specified by the operator). The 

perceptive planner provides the set of costs to get from the vehicle’s location to all points along 

the perimeter of the sensor range. To choose where to go, FCI combines these two costs: the 

cost to get from where the vehicle is to some point on the sensor range perimeter (call that point 

A); and the cost to get from A to the next mission waypoint. FCI tells the vehicle to navigate to 

the point along the perimeter of the sensor range that yields the cheapest combination of local 

and long-range costs. So FCI permits navigation to virtually any point on the sensor range 

perimeter. This is the key difference between FCI and the perceptive layer planner. Unlike the 

perceptive layer planner, FCI does not provide a set of long-range route points for the perceptive 

planner to follow but continually follows the point on the sensor range perimeter that possesses 

the cheapest local and long-range combined cost. The advantage of FCI is that it does not force 

the vehicle to follow a fixed long-range plan, giving it more flexibility to deviate from moving 

directly toward the goal in order to avoid local obstacles. Therefore, FCI acts as a guide for 

XUV mobility.

In order to tie the different planners together, the XUV has an onboard autonomous command 

and control (ACC) component. Figure 36 shows where the ACC fits into the XUV software 

architecture. The ACC allows the XUV to remain aware of the mission and global environment 

by providing an interface between the world model of a priori elevation and terrain feature data, 

the perception level of autonomous mobility, the low-level XUV control (via the XAC), and the 

status of the XUV. The ACC also provides the XUV with the ability to adapt to its environment 

without Soldier intervention.
38

Figure 36. XUV software architecture showing the ACC component.

The motivation for the assessment work is to enable the XUV to use the best information 

available from multiple sources (best information planning [BIP]) and to bridge the deliberative 

and perceptive-level planning such that the unmanned ground vehicle has the ability to use 

terrain features to tactical advantage including planning its way out of untraversable situations 

and avoiding entering into those situations. For the present technology assessment, BIP is 

confined to the use of sensed data flowing up from the perceptive level to update the deliberative 

planning map and replanning at the deliberative level based on the updated map. The XUV did 

not have a “data gathering mode” where it explicitly traversed the terrain and performed full 

scans with its LADAR to gain complete knowledge of the surroundings. The information 

obtained on local obstacles for BIP purposes was derived from the primary autonomous mobility 

sensor, the LADAR, as the XUV traversed terrain. Therefore, sensed obstacles were only 

acquired where the XUV happened to “look.”

3.2 The 2008 Interplay of Multiple-Level Planning Assessment Approach

In order to assess the impact of the perceptive and deliberative planning, and of the interplay of 

these two technologies, on the ability of the XUV to maneuver through relevant terrain, a series 

of four evaluations were conducted at Ft. Indiantown Gap in training areas A1, B9C, B12, and 

C4. The first approach was to leverage structured environment in areas A1, B9C, and B12, 

where a combination of run conditions could be exercised and the resultant behavior from the 

XUV observed. The second approach was to operate in area C4 and allow the XUV more
39

latitude in path selection in order to determine if the FCI would enable the XUV to find 

alternative routes to the goal in the event that the original route plan could not be achieved.

This assessment of information planning technologies consisted of one XUV, one operator using 

an OCU, a safety chase vehicle with a driver and a safety officer (with an E-stop radio), and a 

data recorder for noting observations for each run. All runs consisted of a starting waypoint and 

an ending waypoint with no intermediate waypoints provided. In the cases where a priori 

elevation and feature data were used in the generation of an initial route plan, the planner 

generated route points to be achieved along that route. Feature data used in the assessment 

consisted of tree lines, some roads, and “no-go” areas that contained features which could harm 

the XUV (e.g., water hazards, stumps). In the event that the XUV could not plan a route around 

an obstacle or out of a cul-de-sac, the XUV autonomously backed up to gain a better perspective 

of the environment and subsequently attempted to use perceptive level planning to find a suitable 

path. This programmed behavior was attempted up to three times with the distance of the 

backup increasing with each attempt (5, 10, and 15 m). If after the third backup the XUV was 

still unable to plan a route beyond the obstacle, the condition was referred to as “maximum 

backups” whereupon the operator was notified to intervene. Options for operator intervention 

depended on run configuration. In runs that were based on perceptive level planning, the 

operator was required to teleoperate the vehicle past the most immediate obstacle and then 

reexecute the original route plan from that location. For runs that included deliberative level 

planning, the operator initiated a 15 m backup and the generation of a new route plan based on 

data sensed from the local area and a priori elevation and feature data.

3.3 Autonomous Maneuver Courses Used in the 2008 Assessment

3.3.1 Area A1

Area A1 is characterized by relatively flat terrain, with open ground being more grassland; trees 

and brush occur in patches and dense woods and marshy areas are present. Figure 37 shows the 

course layout for area A1 which consisted of natural and man-made obstacles, as well as some a 

priori feature data for marshy and wooded areas. The condition depicted in the figure shows a 

planned straight path that is ~300 m long that runs between the start point, A, and end point, B, 

which is expected for a run that does not rely on any a priori data. For the condition where the 

initial route plan is generated based on a priori elevation and feature data, the planned route 

directed the XUV to weave through a course of obstacles. The man-made obstacles consisted of 

an apparatus constructed of tarps, stakes, and cables in order to present a wall through which the 

XUV would not plan. Figure 38 is a picture of one of these structures that, in conjunction with 

nearby natural obstacles, creates an impenetrable cul-de-sac. This structure induced into the 

course was intended to highlight the path choices made by the XUV in order to facilitate

interpretation of the selected routes and minimize the number of E-stops due to the XUV 

attempting to drive through sparsely wooded and/or marshy areas.
40

Figure 37. Assessment layout for area A1.

Figure 38. Tarp structure used to create cul-de-sac in area A1.

3.3.2 Area B9C

The portion of area B9C used in this assessment consists of a relatively flat, open area of 

approximately three acres that contains numerous shipping containers arranged in such a way as 

to simulate a small military operations on urbanized terrain (MOUT) site. Figure 39 is a sketch 

of the MOUT site which is constructed from steel, dry freight shipping containers of two lengths, 

20 and 40 m, and with a cross section that is 8 × 8 ft.
41

Figure 39. Assessment layout for area B9C.

The start and end points for each run are depicted as A and B, respectively, and the initial path 

for all runs was the dashed straight line path shown in orange. No a priori feature data was used 

for this portion of the assessment and therefore, none of the MOUT site features were used 

during the generation of route plans. In order to bound the problem, a boundary line, shown in 

the figure as a blue dashed line, was entered into the a priori data to prevent the XUV from 

planning a route that circumvented the MOUT site. Although for this scenario it would appear 

that the better route to the goal is to avoid the containers altogether, this option was removed so 

that we might assess the ability of multilevel mobility planning technologies to enable the XUV 

to plan a way out of a cul-de-sac. Additional man-made obstacles in the form of construction 

barrels, and eventually the tarps used in area A1, were added to create mobility obstructions. 

The geometry of the MOUT site layout was tight with respect to the XUV turning radius. This 

area did afford multiple alternative routes that were available to the XUV in order to achieve the 

end point.

3.3.3 Area B12

The mobility planning technologies were also assessed in a portion of training area B12. 

Figure 40 shows the area of operations which contains open fields, tree lines, and unimproved 

trails. This area provided another opportunity to create a cul-de-sac in a more open environment 

in comparison to that of area B9C. A combination of tarps, construction barrels, and HMMWVs 
42

were used to block the initial planned path of the XUV (figure 40). The width of the cul-de-sac 

was ~50 m which provided plenty of room for the XUV to maneuver. The planned route was the 

straight line path shown in orange and was ~400 m in length. The alternative route, shown in 

green, was a traversable route to the goal over an unimproved trail that was part of the a priori 

data.

Figure 40. Assessment layout for area B12.

3.3.4 Area C4

Area C4 is characterized by rolling vegetated terrain, unimproved trails, and improved trails. 

The off-trail terrain was dense and posed the additional challenge to mobility of numerous tree 

stumps as a result of clear cutting activity. The motivation for using the selected portion of this 

training area was to assess the multilevel path planning technologies in a less structured 

environment. Figure 41 shows the area of operations with the planned route as a straight line 

path between the start and end points and ~500 m long. Boundary lines were established in the a 

priori data parallel to the planned path along the road to the right and to the left at ~200 yd from 

the planned path. These boundaries were necessary to prevent the XUV from planning and 

maneuvering on the road and among the tree stumps, respectively. Additionally, a no-go area 

was established around a pond that was within the boundary lines. A no-go area is defined in the 

perceptive layer map such that the area may be considered for route planning at the deliberative 

layer, but the vehicle will not enter the area due to the restriction at the perceptive level.
43

Figure 41. Assessment layout for area C4.

3.4 Experimental Design

The assessment conducted in each of the described areas was based on a schedule of runs which 

varied the available conditions. Primarily the available parameters for variation in run conditions 

included slight variation of the start and end locations, inclusion/exclusion of available a priori 

elevation and feature data, and the inclusion/exclusion of the BIP and FCI path planning 

technologies. Limitations due to the weather and/or difficult terrain imposed constraints on the 

number of possible parameter variations and will be discussed in the Observations section (3.8) 

of this report.

3.5 The 2008 Assessment Operations

The configuration for each run was established by an engineer prior to the start of the run using a 

laptop computer to run configuration script files and transmit the appropriate configuration 

commands to the XUV via a wireless local area network link. Each run began with the XUV 

located at the start point and oriented towards the end point. The operator used the OCU to 

generate a route plan using one waypoint for the start location, one waypoint for the end location,

and a cross-country route type, which resulted in a straight line route (except for part of the area 

A assessment wherein a priori data was used) that was through tree lines and other impenetrable
44

obstacles for at least a portion of the route. The reason for establishing a planned route that did 

not consider available elevation and feature data was twofold. Firstly, it is realistic to expect that 

map data available to maneuver forces could contain errors due to limitations of resolution and 

inaccurate/missing features. The second reason to prescribe such a route was to challenge the 

XUV to use its autonomous mobility capabilities and the multilevel path-planning technologies 

to execute a suitable path to the goal.

Upon receiving the route plan and the command to execute, the XUV proceeded to maneuver 

towards the goal. During the runs, the XUV sent status update messages to the OCU that 

indicated to the operator the current command being executed, error messages, and system 

diagnostic data (e.g., fuel level). A complete log file of this information was captured and saved 

for each run performed. In the event that the XUV encountered an obstacle in its path, the 

procedure was for the XUV to autonomously attempt to maneuver around the obstacle in order to 

proceed. In order to facilitate finding a suitable path around obstacles, the assessment protocol 

required the XUV to follow the previously described backup procedure in an attempt to gain a 

better perspective for the perception sensors. If the XUV found a suitable path around an 

obstacle, the system would autonomously execute that path. If, after three attempts to backup,

the XUV was unable to find a path, then an operator intervention request was sent to the OCU 

and the previously described intervention procedure followed.

In the event that an emergency stop was declared due to potential for unsafe operation, at that 

point the end of the run was declared. In some instances, for the sake of completeness and/or 

troubleshooting, the XUV was teleoperated past the trouble spot and the run resumed.

3.6 Data Collection

Data collected included the SMI log, ACC log, mission plan, and a screenshot from the end of 

the run. Observations on the behavior of the XUV and the interaction of the operator were 

manually collected by the data recorder.

3.6.1 SMI Log Sample

Figure 42 shows an excerpt from the SMI log for one run. The SMI log provides a record of the 

instructions sent by the operator from the SMI to the XUV and messages sent to the operator.

3.6.2 ACC Log Sample

An excerpt from the ACC log file for one of the multilevel path-planning runs is shown in 

figure 43. The table reflects the messaging between the various parts of the control software 

architecture.
45

00:10:48.26 s1 Button pressed [Select Plan] (select plan) = selected

00:10:51.26 s1 selected plan area_C_road_route

00:10:51.97 s1 Button pressed [Select] (select) = unselected

00:10:54.27 s1 Button pressed [Assign] (assign) = selected

00:10:56.95 s1 selected asset XUV11

00:10:57.33 s1 Button pressed [Assign] (assign) = unselected

00:11:42.12 s1 XUV11 sent: (ramp XUV

(move-on-route max-speed 4.40

(tolerance 30.00)

(radius 28.09)

(route cross-country

(Z18N 4478774.0 362267.6 204.0 0x3)

(4478781.5 362265.1 205.0 0x4000000)

(4478786.0 362261.1 204.9 0x4000000)

(4478818.0 362231.1 204.4 0x4000000)

(4478875.0 362180.3 205.9 0x4000000)

(4478938.0 362126.9 206.6 0x4000000)

(4478948.0 362121.5 207.1 0x4000000)

(4479062.5 362061.1 212.4 0x4000000)

(4479113.0 362036.9 213.3 0x4000000)

(4479133.0 362031.1 213.5 0x4000001)

(4479138.0 362026.1 213.4 0x4000001)

(4479148.0 362011.9 213.3 0x4000001)

(4479213.0 361916.1 213.9 0x4000000)

(4479223.0 361897.2 214.6 0x4000000)

(4479262.0 361833.3 223.0 0x1)

00:11:42.12 s1 Button pressed [Execute Plan] (execute plan) = unselected

00:11:42.68 s1 XUV11 working towards wp 1

00:11:42.68 s1 XUV11 state change Running

00:11:46.86 s1 Wca: XUV11 Caution, - Vehicle is out of path bounds!

00:12:05.04 s1 XUV11 working towards wp 2

00:12:25.40 s1 Wca: XUV11 Caution, - Vehicle is out of path bounds!

00:12:25.54 s1 XUV11 backing up

00:12:26.04 s1 XUV11 done backing up

Figure 42. Excerpt from SMI log file.
46

15:39:17.01661 | 0 | XACConnection.cpp[501]::ReadXuvStatus XUV Status buffer WAS read

15:39:17.01666 | 0 | XACConnection.cpp[678]::ProcessIncomingMessage stat msg received

15:39:17.01684 | 0 | XACConnection.cpp[324]::ListenFunc: Calling ReadAndProcess() for sensed data.

15:39:17.01825 | 0 | smi_mi.cpp[243]::InterpretMessage Incoming Unit ID: 8404747

15:39:17.01838 | 1 | MessageAdapterInterface.cpp[259]::ListenFunction Message Adapter external message 

interpretation and send was successful

15:39:17.01999 | 1 | KBModuleLoader.cpp[270]::Execute knowledgebase executed 2 rules

15:39:17.02015 | 0 | tr_interface.cpp[564]::OnReceive thread pid 5280

15:39:17.02022 | 0 | tr_interface.cpp[603]::OnReceive received Unit message -> notifying geoplanner

15:39:17.02044 | 0 | smi_mg.cpp[99]::GenerateMessage Not sending object to SMI because it has not changed....

15:39:17.02051 | 0 | MessageAdapterInterface.cpp[295]::OnReceive Message Adapter external message 

generation, externalMessage was NULL

15:39:17.02060 | 0 | tr_interface.cpp[1038]::FillBso muid: 8404747, name; XUV11, affil: 1, lookup: 0

15:39:17.02067 | 0 | tr_interface.cpp[1110]::FillBso filled bso from registered asset type

15:39:17.02077 | 0 | tr_interface.cpp[1148]::FillBso filled bso is: Bso::

Id: 8404747, Name: XUV11, NatoType: 66, PlanType: NONE, Affil: FRND,

Height: 2.00, Active: 1, 18 363377.69E 4475508.00N El: 143.33

Orientation:: 

heading: 174.875428, pitch: -0.630254, roll: -2.234535, Sensor:: Type: 0, range: 1500.000000, GetRange(): 

1500.000000, hfov: 360.000000, vfov: 180.000000, 0 0.00E 0.00N El: 2.00 Orientation:: heading: 0.000000, 

pitch: 0.000000, roll: 0.000000,

15:39:17.02088 | 0 | tr_interface.cpp[845]::NotifyGeoplannerFacade Updating bso to geoplanner.

15:39:17.23182 | 1 | KBModuleLoader.cpp[273]::Execute knowledgebase executed 0 rules

15:39:17.94799 | 0 | XACConnection.cpp[328]::ListenFunc: Returned from ReadAndProcess().

15:39:17.99955 | 0 | NMLConnectionInterface.cpp[640]::ReadNML reading

Buffer xlpdata

Figure 43. Excerpt from ACC log file.

3.6.3 Screenshot Sample

At the end of each run, an image, referred to as a screenshot, of the OCU screen was saved to 

disk (see figure 44). This image provides a record of the planned path, the path traveled by the 

XUV, and any imposed boundaries, a priori tree line data, and no-go areas.

3.7 Data Reduction

Dependent measures for each run included the number of backups, number of times maximum 

backups was reached, number of E-stops for each type (administrative E-stop or safety E-stop), 

number of required teleoperations, and, in the case where BIP and/or FCI were included, an 

indication of whether or not the planning technology helped the XUV to proceed.

3.7.1 Area A1 Data

The schedule of runs anticipated for area A1 over two days of experimentation is shown in 

table 5. The six independent variables for this run schedule include (1) the inclusion of a prior 

elevation and feature data in the initial route plan formulation (indicated in the planner column), 

(2) the inclusion of BIP, (3) the inclusion of FCI, (4) the location of the start point (A1 or A2), 

(5) the location of the end point (B1 or B2), and (6) the presence of a known threat.
47

Figure 44. Sample screenshot captured at the end of each mission (black area on map indicates no 

available a priori map data). 

The conditions at the time of the assessment were such that moisture in the ground coupled with 

a warming trend caused the areas surrounding the marshy portion of area A1 to become 

increasingly muddy with each run. This condition resulted in two deleterious effects on the 

ability to conduct the assessment. The first effect was the wheel slippage of the XUV due to the 

mud. Encoders on each wheel of the XUV are used to determine the relative position of the 

vehicle with respect to the objects perceived. As a result of the wheel slippage, the map which 

contains the data for those obstacles became smeared such that both the magnitude and location 

of obstacles are incorrect. The resultant behavior is the XUV attempts to avoid the numerous 

obstacles in the map that are actually nonexistent. The second effect on the ability to conduct the 

assessment was a loss of chase vehicle traction, also due to the mud. As the conditions 

worsened, the safety operator was required to initiate numerous E-stops in order for the chase 

vehicle to catch up to the XUV.
48

Table 5. Run schedule for area A1.

Block Run Planner

Global

Map BIP FCI Threat A B Block Run Planner

Global

Map BIP FCI Threat A B

1 1 Off Null On Off None A1 B1 3 23 Off Off Off Off None A2 B2

1 2 Off On On On None A1 B1 3 24 On On Off Off None A2 B2

1 3 On On On Off None A1 B1 4 25 Off Off Off Off None A2 B2

1 4 On On Off On None A1 B1 4 26 Off Null On Off None A2 B2

1 5 On On On On None A1 B1 4 27 Off On Off On None A2 B2

1 6 Off Off Off Off None A1 B1 4 28 On On On Off None A2 B2

1 7 On On Off Off None A1 B1 4 29 On On Off Off None A2 B2

1 8 Off On Off On None A1 B1 4 30 On On On On None A2 B2

2 9 On On Off Off None A2 B1 4 31 On On Off On None A2 B2

2 10 Off On Off On None A2 B1 4 32 Off On On On None A2 B2

2 11 Off Off Off Off None A2 B1 5 33 Off On Off On None A1 B1

2 12 On On Off On None A2 B1 5 34 On On Off Off None A1 B1

2 13 Off On On On None A2 B1 5 35 Off On On On None A1 B1

2 14 On On On Off None A2 B1 5 36 Off Null On Off None A1 B1

2 15 Off Null On Off None A2 B1 5 37 Off Off Off Off None A1 B1

2 16 On On On On None A2 B1 5 38 On On On Off None A1 B1

3 17 On On Off On None A1 B2 5 39 On On On On None A1 B1

3 18 On On On On None A1 B2 5 40 On On Off On None A1 B1

3 19 Off On On On None A1 B2 6 41 On On On On One A1 B1

3 20 Off On Off On None A1 B2 6 42 On On On On One A1 B1

3 21 Off Null On Off None A1 B2 6 43 On On On On Three A1 B1

3 22 On On On Off None A1 B2 6 44 On On On On Three A1 B1
49

After 1.5 days of operations in area A1, six accepted runs were accomplished. In addition to 

these accepted runs, a number of runs were reexecuted in order to complete a full run in the 

presence of technical complications. Appendix B to this report contains summary data for each 

run performed in areas A1, B9C, B12, and C4. Table B-1 provides a summary of measured data 

for all of the runs performed in area A1.

3.7.2 Area B9C Data

The assessment conducted in area B9C revealed several interesting things about the interplay of 

the perceptive and deliberative planners and the autonomous mobility of the XUV. Table 6

shows the run schedule that was used for this area and over two days in the field, data was 

obtained for eleven accepted runs plus four reexecute runs. The problem with map smearing 

again appeared during this technology assessment however the cause was not due to sloppy 

terrain conditions as was the case for area A1. The main challenge in area B9C was the 

relatively narrow corridors resulting from the close layout of the shipping containers, which 

constrained XUV mobility requiring numerous backups in attempt to find a path. During the 

successive backups over the same path, the height map in the perceptive layer exhibited an 

artificial growth of obstacles on the ground plane, which reached the minimum obstacle height 

and thus influenced the XUV to avoid those obstacles. The tight geometry also prevented the 

XUV from being able to turn around in the cul-de-sac and executing the new path. On one run it 

was shown that when the XUV was able to turn around, the new path based on updated map data 

enabled the XUV to achieve the goal autonomously. Another interesting situation that occurred 

in the cul-de-sac involved FCI. When the XUV attempted to follow a new path, which ran back 

within the XUV sensor range, down the next side corridor (see figure 45) and around to the goal, 

the lowest cost action for the XUV to continue was to go forward (through the obstacle to the 

yellow dot) in order to proceed along the new path. Cost is measured in meters to go around an 

obstacle. The XUV attempted to move forward based on the deliberative plan but could not 

succeed because the perceptive level planning detected the obstacle and would not proceed. The 

resultant behavior was the XUV moving forward to find a path, backing up when no path 

through the obstacle could be found, and repeating this behavior until maximum backups was 

reached. Table B-2 contains summary data from all runs performed in area B9C.

3.7.3 Area B12 Data

The technology assessment conducted in the portion of area B12 yielded seven accepted runs and 

one reexecuted run over 1.5 days in the field. As a result, several interesting behaviors were 

exhibited by the XUV. The runs schedule for area B12 is provided in table 7. The need for 

planning technologies that enable the XUV to avoid, or extricate itself from, obstructed pathways 

was exemplified during this portion of the technology assessment. During the runs where only 

the perceptive layer was used (e.g., run 1), the XUV, when faced with an obstructed path, would 

continually perform a figure eight pattern in search of a path through the obstacle. However 

when BIP was enabled (e.g., run 3) and given sufficient room to maneuver, the XUV 
50

Table 6. Run schedule for area B9C.

Run Planner

Global

Map BIP FCI A B

1 Off Off Off Off A1 B1

2 Off Off Off Off A1 B1

3 Off On On Off A1 B1

4 Off On On Off A1 B1

5 Off On On On A1 B1

6 Off Off Off Off A1 B1

7 Off Off Off Off A1 B1

8 Off On On Off A1 B1

9 Off On On Off A1 B1

10 Off On On On A1 B1

11 Off On On On A1 B1

Figure 45. Depiction of scenario with FCI and perceptive level planning power struggle.

demonstrated that when faced with an obstructed route it had the ability to apply BIP to plan and 

execute an alternative route to avoid the obstruction and continue to the end point. The behavior 

that was observed in area B9C wherein the perceptive layer detected obstacles yet the 

deliberative layer planned through those same obstacles was also seen during the assessment in 

area B12. It was apparent during more than one run that the priority given to either the 

perceptive layer or the deliberative layer to drive mobility has a significant influence on the 

ability of the XUV to maneuver in the presence of obstructed pathways. Technical difficulties 

with the FCI demonstrated the need for further refinement to increase the robustness of that 

technology. Table B-3 contains summary data for the runs performed in area B12.
51

Table 7. Run schedule for area B12.

Block Run Planner

Global

Map BIP FCI Threat A B

1 1 Off Null On Off None A1 B1

1 2 Off On On On None A1 B1

1 3 On On On Off None A1 B1

1 4 On On Off On None A1 B1

1 5 On On On On None A1 B1

1 6 Off Off Off Off None A1 B1

1 7 On On Off Off None A1 B1

1 8 Off On Off On None A1 B1

2 9 On On Off Off None A2 B1

2 10 Off On Off On None A2 B1

2 11 Off Off Off Off None A2 B1

2 12 On On Off On None A2 B1

2 13 Off On On On None A2 B1

2 14 On On On Off None A2 B1

2 15 Off Null On Off None A2 B1

2 16 On On On On None A2 B1

3 17 On On Off On None A1 B2

3 18 On On On On None A1 B2

3 19 Off On On On None A1 B2

3 20 Off On Off On None A1 B2

3 21 Off Null On Off None A1 B2

3 22 On On On Off None A1 B2

3 23 Off Off Off Off None A1 B2

3 24 On On Off Off None A1 B2

3.7.4 Area C4 Data

The schedule of runs for area C4 is shown in table 18. After 1.5 days of assessment, 11 accepted 

runs and one reexecuted run were performed. The results for this portion of the assessment are 

provided in table B-4. During the runs in area C4, a significant amount of time was devoted to 

finding suitable planned routes that the XUV could execute. The terrain in this area provided 

few opportunities for the XUV to explore for alternative routes due to the presence of hazardous 

stumps and debris. The minimum height at which an object is classified as an obstacle is a 

parameter that is defined in the perceptive layer planner code and can be changed prior to 

running in a given type of terrain. For area C4, the setting for the minimum obstacle height 

determined whether the XUV would drive over the stumps, as in the case when the minimum 

obstacle height setting is too high (e.g., 1 m) or move very slowly and across only sparse terrain, 

as in the case when the minimum obstacle height setting is low (e.g., 0.5 m). It was 

demonstrated that when the XUV entered a long, narrow path leading to a cul-de-sac, BIP 

provided an exit plan, but the XUV could not negotiate a turn around in order to pursue the new 

path. 
52

Table 8. Run schedule for area C4.

Block Run Planner

Global

Map BIP FCI Threat A B

1 1 Off Null On Off None A1 B1

1 2 Off On On On None A1 B1

1 3 On On On Off None A1 B1

1 4 On On Off On None A1 B1

1 5 On On On On None A1 B1

1 6 Off Off Off Off None A1 B1

1 7 On On Off Off None A1 B1

1 8 Off On Off On None A1 B1

2 9 On On Off Off None A2 B1

2 10 Off On Off On None A2 B1

2 11 Off Off Off Off None A2 B1

2 12 On On Off On None A2 B1

2 13 Off On On On None A2 B1

2 14 On On On Off None A2 B1

2 15 Off Null On Off None A2 B1

2 16 On On On On None A2 B1

3 17 On On Off On None A1 B2

3 18 On On On On None A1 B2

3 19 Off On On On None A1 B2

3 20 Off On Off On None A1 B2

3 21 Off Null On Off None A1 B2

3 22 On On On Off None A1 B2

3 23 Off Off Off Off None A1 B2

3 24 On On Off Off None A1 B2

3.8 Observations

3.8.1 General

The scenarios posed to the XUV during the nine days of assessing route planning technologies in 

four locations enabled the research team to discover and confirm abilities and deficiencies of the 

path planning technologies. In addition, there were numerous technical difficulties that arose 

during the time in the field that the technical staff will have opportunity to address prior to the 

next assessment.

Weather and rough terrain posed a significant challenge to obtaining a quantity of meaningful 

data. Furthermore, the balance between choosing a minimum obstacle classification height, that 

takes into account the need to provide safety for the XUV and enable the XUV to maneuver offroad, is an area that requires further investigation.

3.8.2 The Interplay of Planning at Multiple Levels

The interplay between the perceptive and deliberative planners was shown to have a significant 

impact on the behavior of the XUV when attempting to maneuver in the presence of obstructed 

pathways. The challenge is that if the perceptive layer is too conservative in the way that it 
53

identifies obstacles, path planning of the XUV will likely result in avoiding pathways that the 

XUV could traverse; however, if the deliberative layer has the final say in the executed route, the 

XUV is likely to enter into terrain that could potentially damage the vehicle. More work is 

required in developing the ability of the XUV to seamlessly use sensed and a priori data to 

efficiently maneuver in this type of terrain.

3.8.3 BIP

BIP planning provided a path that would enable an exit to man-made and natural cul-de-sacs that 

otherwise the XUV could not have overcome. It was shown that when mobility was confined 

such that the XUV could not turn around in the cul-de-sac, it was unable to execute a new path.

3.8.4 FCI

The FCI provided freedom to the XUV to search for suitable paths to the goal as designed. 

However, more effort is required to provide a reasonable set of scenarios and a corresponding 

data set that will provide insight as to the effectiveness of this technology to enable the XUV to 

avoid obstructed pathways. The LADAR has a maximum range of 60 m and the surrounding 

terrain frequently obstructs the XUVs line of sight. This limitation prevents FCI from planning 

around obstacles beyond the LADAR sensor range. This is important since the ACC portion of 

FCI plans from 60 m out to the next way point. With a longer range sensor, FCI (with BIP) 

should be able to foresee cul-de-sac conditions and, as a result, avoid entering them.

3.9 Recommendations From the Interplay of Multiple-Level Planning Assessment

3.9.1 General

1. Investigate additional scenarios for evaluating the interplay of multilevel planning 

technologies. Although a variety of terrain was used in this assessment, the scenarios used 

to evaluate the interaction between the perceptive and deliberative planning layers were 

limited to two situations. A greater variety in scenarios is recommended to better 

determine the performance and efficacy of these technologies.

2. Consider alternatives to backup procedures. The current method of using three consecutive 

backups prior to calling the operator to intervene is time consuming and of questionable 

benefit. It is recommended that the backup procedure be updated to consider current 

capabilities in XUV mobility.

3. Develop algorithms that enable the XUV to maneuver in the presence of confining terrain 

features. In situations where a new plan based on sensed data requires the XUV to perform 

sharp turns in order to begin traversing the new path, this requires greater mobility than the 

current implementation provides.
54

4. Leverage hardware-in-the-loop simulations. Prior to a field assessment, the algorithm 

developers need an opportunity to run a number of scenarios in order to perform a 

parametric study on the effect of the various run configurations. This will increase the 

effectiveness of the field assessments and better prepare the technology for evaluation.

5. Remove software developers from being in-the-loop during the next assessment. The 

establishment of necessary parameters for each run should be performed by the operator. 

This should include the ability to specify a minimum obstacle height. Furthermore, no 

parameters that affect the performance of the underlying algorithms should be changed 

during the course of a run.

3.9.2 Interplay of Perceptive and Deliberative Planners

Continue to work on the interaction between the perceptive layer and deliberative layer planners. 

The handoff between the perceptive and deliberative planning layers requires further attention. 

A method is required to ensure that available terrain feature information is used appropriately by 

both layers so that the vehicle does not avoid a path that affords safe mobility and can effectively 

identify when a path is blocked or is too narrow that mobility becomes inherently unsafe.

3.9.3 BIP

Increase the autonomy with which the XUV uses BIP. It is recommended that planning based on 

sensed information be automated for the next assessment by removing the step that requires the 

operator to initiate a replan. The implications of this automation for the operator will need to be 

explored in future assessments. Also, it is recommended that the XUV actively perform a more 

complete scan of the environment, as it traverses terrain, in order to improve the quality of a new 

deliberative plan that is based on sensed information.

3.9.4 FCI

More effort is required to determine the efficacy of the FCI. The robustness of this technology to 

perform as designed during field experimentation must improve in order to assess its influence 

on vehicle behavior. It is further recommended that simulation be leveraged to better understand 

the numerous parameters that influence the performance of the FCI.

3.9.5 Technology Assessment

1. Continue to investigate available areas for future assessments. More effort is required to 

identify and use available terrain for assessments of these mobility planning technologies. 

If the fidelity of the suggested software-in-the-loop simulation is sufficient to accurately 

represent terrain features and elevation, that effort may be leveraged to estimate the impact 

of terrain selection for future field experimentation.
55

2. Establish useful metrics for unmanned ground vehicle performance. In order to assess the 

ability of an unmanned ground vehicle to maneuver in a tactical manner through relevant 

terrain, a set of criteria is required to measure performance. Although summary data as 

that provided in appendix B can be used to draw some limited qualitative conclusions, a 

means to quantitatively measure the ability of the vehicle to behave in a way that would 

benefit the Soldier is warranted.

4. Summary

During 4–14 February 2008, ARL and General Dynamics Robotics Systems conducted an 

assessment of technologies designed to enable tactical unmanned ground vehicle behaviors. The 

assessment provided data taken in a relevant environment that demonstrated the ability to use 

sensed information to locally orient the platform in order to obtain line of sight for an onboard 

RSTA system to scan a sufficient portion of a named area of interest and the impact of advances 

in deliberative layer planning technologies to enhance autonomous mobility in a relevant 

environment.

The OP finders and the HMP combined to successfully demonstrate that locally sensed terrain 

and feature data can be successfully utilized to find and move the XUV to an OP location with 

improved visibility to the NAI. Both approaches for finding a suitable OP performed sufficiently 

well to continue their advancement.

As a result of this technology assessment, it was shown that the interplay between the perceptive 

and deliberative planning layers plays an important role in vehicle path planning but requires 

further development. More refinement is required in order for the XUV to seamlessly use sensed 

and a priori data to efficiently maneuver in relevant terrain.

Specific recommendations for the methodology and functionality of select technologies were 

provided to facilitate enhancement of future field activities. The information and experience 

provided to the software developers and the designers as a result of the 2008 technology 

assessment will be applied to focus research in vehicle path planning, improve the functionality 

of technology components, and improve the quality of future technology assessments.
56

INTENTIONALLY LEFT BLANK.
57

Appendix A. A Potential Process for Observation Post (OP) Finding
58

Following the February 2008 assessment described in the body of this report, an informal 

discussion was held with an active duty Army Master Sergeant to discuss potential alternatives 

for implementing an automated process for observation post finding. Figures A1–A5 graphically 

summarize the resulting process.

The first step of the process is the experimental unmanned vehicle (XUV) stops short of the 

operator-input OP and takes an automatic reconnaissance surveillance target acquisition (RSTA)

scan so that the operator can check the proposed area for enemies and see the general area for 

possible places for concealment (see figure A-1). At that location, the XUV traverses a path that 

enables the system to obtain mid-range obstacles from the structure from motion (SFM) 

algorithms. The XUV then moves to the approximate OP given by the operator. The operator 

should be given status messages when XUV has stopped and presents RSTA for checking 

enemies and concealment as well as when the SFM movement is taking place.

At this location, the XUV laser detection and ranging (LADAR) will do a scan and calculate the 

percent coverage of the named area of interest (NAI) and take a RSTA image (it might be helpful 

to have the linear NAI projected on the RSTA image.) Also at this time, the next “top five” OP 

locations are calculated based on some combination of coverage percent, the cost to make an 

autonomous move to the location (autonomous mobility costs using the high-mobility planner) 

(see figure A-2). The coverage percent, RSTA image, and the new “top five” OP locations are 

presented to the operator. If he judges the current location to be a good OP, then the process of 

OP finding is completed. If not, the operator chooses the next OP from the “top five” list and the 

XUV moves to that location (see figure A-3). (It might be helpful to the operator if the next “top 

five” OPs could be projected onto the given RSTA image.) Appropriate choice selection options 

and status messages need to be presented to the operator as this process proceeds.

This process is repeated, presenting information to the operator and he deciding if a good OP or 

not based on the presented RSTA images and identified “top five” potential OPs (see 

figure A-4). The OP finding process is complete when the operator has chosen an OP and 

proceeds with his RSTA and other tasks.

This is a potential OP finding process that puts the operator at the center of decision making, 

with the XUV providing automated information and moving autonomously based on the operator 

decisions. Figure A-5 presents some notes that add to the graphical summary of 

figures A-1–A-4. Of particular note is that a threshold criterion of coverage percent becomes 

irrelevant because coverage percent for every point is calculated and the operator chooses if a 

move to a new point is required.
59

Figure A-1. The multistep observation post finding process begins with stopping 

short of the operator input OP to scan for possible enemy at the OP. 

If no enemy is sighted, then the XUV transverses a route that allows 

adding midrange obstacles to the map.

Figure A-2. The multistep process continues with a LADAR scan of the NAI and 

a report to the operator of the percent coverage. A RSTA image is 

taken and displayed to the operator. The five “top” Ops are 

displayed to the operator. If the operator judges that the current 

position is good, then the OP finding is completed. If it is not good, 

then the OP finding process continues.

NAI Alpha

SP

100% 100% 80%

65% 70%

60%

• Stop

1.Do scan of NAI, report % coverage at own 

location to operator

2.Take a RSTA picture of NAI (project NAI 

onto RSTA picture?)

3.Display on SMI map the five top new OPs 

based on {Coverage, AM cost, and 

Concealment}

• Operator decides if Good OP based 1 -3.

• Y- done, do the RSTA 

• N-go to next slide

OP Planner: Find a location near the OP where visibility to the NAI is 

acceptable to the operator.

NAI Alpha

SP

OP

Stop, take RSTA scan to observe 

OP for possible enemy. Distance 

based on terrain and line -of-sight

Traverse route that enables SFM 

determination of mid -range 

obstacles. Mid -range obstacles 

added to map
60

Figure A-3. If the operator judges that the current position is not good, then the 

operator selects a new OP from the choice of five presented on the 

SMI. The XUV will then move to the selected new OP and stops, 

pointed toward the NAI.

Figure A-4. At this new OP, the process is repeated. The operator is presented with a 

RSTA scan of the NAI and five new “top” OPs and makes a decision on the 

OP. The process repeats until the operator is satisfied with the new OP.

NAI Alpha

SP

100%

90%

80%

65%

70%

• Stop

1.Do scan of NAI, report % coverage at own 

location to operator

2.Take a RSTA picture of NAI (project NAI 

onto RSTA picture?)

3.Display on SMI map the five top new OPs 

based on {Coverage, AM cost, and 

Concealment}

• Operator decides if Good OP based 1-3.

• Y- done, do the RSTA 

• N-repeat the process

80%

• Operator decides if Good OP

• Y- previous slide

• N-Highlight recommended new OP on 

SMI

• Operator selects new OP (from choice of 

5) via SMI

• HMP moves XUV to new OP, stops 

with XUV pointed toward NAI

NAI Alpha

SP

100%

100%

80%

Project new OPs

70% 65%

onto RSTA picture?
61

Figure A-5. This proposed multistep OP finding process has a number of features presented.

Proposed OP Finding Process

•Process only stops when operator is satisfied

•Operator gets knowledge of % coverage at his location, looks at RSTA scan, 

and next best choices to decide if the current location is a good OP.

•Always get the top five OPs, regardless of threshold. Top five new OPs are 

picked based on some combination of % coverage, autonomous mobility cost to get 

there, and % concealment .

•Threshold becomes irrelevant. Process does not stop when no good OP can 

be found.

•Operator in-the-loop adds:

•Can see mid-range obstacles

•Can pick OP with best possible concealment

•Immediate judgment on % coverage reported

•Picks from five best new OPs
62

INTENTIONALLY LEFT BLANK.
63

Appendix B. Summary Data for Information Planning Runs
64

Table B-1. Summary data for area A1 runs.

Run Technicalities E-Stops

E-Stop Reason

(Occurrence)

Maximum

Backups

Backup

5 m

Backup 

5 & 10 m

BIP

Replan Outcome Observations

1 Obstacles expansion not 

turned on, second replan 

failed to generate a route. 2 Admin (2) 1 0 2 2

Fault declared due to 

replan malfunction —

3 Orthogonal line between 

XUV location and planned 

path is snapping to old 

planned path.

0 NA 0 1 0 0

Mission completed 

without incident

Planned path 

based on a priori 

feature data 

inadvertently 

avoided manmade obstacles

4 AM board stopped working 

(required a rekey of the 

XUV). 0 NA — — — NA

Fault declared due to 

AM board failure —

4a

— 1

Tree branch 

pushed XUV 

mushroom 

button 1 0 0 NA

End mission declared 

due to expiration of 

range time

Operator 

teleoped XUV 

out of cul-de-sac

5 (1) Adjusted start & end 

points to bias planned path 

towards man-made obstacle. 

(2) Decision to not clear the 

AM map upon a backup (code 

change). (3) Error “Move 

Check Point B1: loop 

detected.” (4) Applied 

second 15-m backup at the 

end of second maximum 

backup condition. 1

XUV charging 

tarps 2 0 0 1

XUV charged tarps 

therefore end of

mission. Fault 

declared due to 

procedural change —

5a (1) Procedural change: if 

XUV approaches worst mud, 

will declare end of mission. 

(2) Restarted ACC and OCU.

0 NA — — — —

Declared a fault: 

twice, immediately 

after execution, 

received 

“Done...Pause” 

messages —

5b FCI and ACC crashed after 

5-m backup. 0 NA 1 1 — 1

Fault declared due to 

FCI and ACC crashes —

5c ACC crashed after 10-m 

backup. 0 NA 1 0 1 1

Fault declared due to 

ACC crash —
65

Table B-1. Summary data for area A1 runs (continued).

Run Technicalities E-Stops

E-Stop Reason

(Occurrence)

Maximum

Backups

Backup

5 m

Backup 

5 & 10 m

BIP

Replan Outcome Observations

5d Power problem with E-stop 

radio required XUV to be 

rekeyed.

2

E-stop radio 

power problem 

(1); Admin (1)-

XUV entering 

muddy area 2 — 2 2

After operator 

initiated a second 

15-m backup, XUV 

successfully 

replanned and 

negotiated past the 

man-made cul-de-sac —

6

— 0 NA 1 — 1 NA

As expected for a 

perceptive-only 

planning run, the 

operator was required 

to intervene by 

teleoperating the 

XUV out of and 

around the obstacle —

16

— 3

Admin (1)-Estop radio power 

problem; Admin 

(1)-E-stop 

antenna was 

knocked off of 

XUV; Admin 

(1)-HMMWV 

cannot keep up 

with XUV due 

to mud 1 1 1 1

Worsening mud 

conditions precluded 

continuing the run —

Note: ACC = autonomous command and control, AM = autonomous mobility, BIP = best information planning, FCI = field cost interface, NA = not applicable, OCU = operator control unit, and XUV = experimental unmanned 

vehicle.
66

Table B-2. Summary data for area B9C runs.

Run Technicalities E-Stops

E-Stop Reason

(Occurrence)

Maximum

Backups

Backup

5 m

Backup 

5 & 10 m

BIP

Replan Outcome Observations

1

— 1

Operator, while 

teleoperating, 

was backing 

XUV towards 

container 1 0 0 NA

After operator teleoperated 

vehicle out of man-made 

cul-de-sac, vehicle 

negotiated containers on to 

goal

Vehicle took a 

route to lower road 

and approached 

cul-de-sac from 

opposite direction 

than expected

1a Moved start point slightly 

north to bias planned path 

towards cul-de-sac. 0

—

1 0 0 NA

Same as run 1

Construction 

barrels used as 

obstacles for runs 

1–3b

2 — 0 NA 1 1 0 NA Same as run 1 —

3 Deliberative layer planned 

through obstacles (barrels).

0 NA 2 0 0 2

After the XUV reached 

max backups, it backed 

out of cul-de-sac and 

replanned; mission ended 

because new plan went 

through obstacles

Apparent conflict 

between perceptive 

layer planning 

(will not plan 

through barrels) 

and deliberative 

layer (will plan 

through barrels)

3a Same as run 3.

0 NA 1 0 0 1 Same as run 13

Decision to place 

HMMWV behind 

barrels to increase 

density of 

obstruction

3b Deliberative layer planned 

through southern barrels; 

adjusted barrels.

1

XUV backing 

towards 

container 2 0 0 2 —

Placing the 

HMMWV behind 

the northern barrels 

worked; decision 

to use tarps on both 

obstacles to 

increase density

3c Wind blew obstacles (tarps)

down.

1

Admin-obstacle 

down — — — —

Mission ended soon after 

start due to obstacle 

blowing over —

4

— 2

Admin (1); 

XUV was 

backing towards 

container (1) 1 0 0 0

XUV became pinned in 

front of container

Geometry of 

MOUT site is tight 

form XUV to turn 

around

5 Pause due to pendant being 

jostled; XUV backing up with 

no obstacles in its path. 0 NA 1 1 1 1

End of mission called due 

to map smearing —
67

Table B-2. Summary data for area B9C runs (continued).

Run Technicalities E-Stops

E-Stop Reason

(Occurrence)

Maximum

Backups

Backup

5 m

Backup 

5 & 10 m

BIP

Replan Outcome Observations

6 Pause due to pendant being 

jostled.

1

XUV was 

backing towards 

truck 1 1 0 NA

After operator teleoperated 

vehicle out of cul-de-sac 

and reoriented away from 

cul-de-sac, XUV 

navigated to goal —

7

— 0 NA 2 0 1 NA

After repeated attempts by 

XUV to approach 

obstacles, operator 

teleoperated vehicle out of 

and past cul-de-sac; XUV 

navigated from there to 

goal —

8 Cleared map because of 

smearing, after 5-m backup; 

OCU stopped responding to 

teleop commands.

0 NA 2 1 0 2

New plan went out of culde-sac and around to goal; 

XUV would not turn 

around; required operator 

to teleop out and around 

cul-de-sac

Numerous attempts

to enter and back 

out of cul-de-sac 

caused map 

smearing. Suspect 

that when the new 

path calls for a Uturn within the 

sensor range, XUV 

cannot negotiate

9 Map smearing.

1

Admin (2)-map 

clearing 3 0 0 2

Thrice XUV planned a 

way out of cul-de-sac but 

could not execute plan

XUV cannot 

follow new path 

because it cannot 

turn around in 

cul-de-sac

10 Map smearing; FCI crash.

1 Admin 4 0 0 2

XUV avoiding nonexistent 

obstacles due to map 

smearing; attempts made 

to reorient by teleop failed 

to enable autonomous 

extrication

XUV cannot 

execute new path 

plans due to 

confined geometry

11 Map smearing.

2

Admin (1)-FCI 

cost ring not 

appearing; 

Accidental (1) 1 0 0 0 —

End of mission 

called because 

clear that XUV 

could not negotiate 

cul-de-sac due to 

geometry and map 

smearing

Note: BIP = best information planning, FCI = field cost interface, MOUT = military operations in urban terrain, NA = not applicable, OCU = operator control unit, and XUV = experimental unmanned 

vehicle.
68

Table B-3. Summary data for area B12 runs.

Run Technicalities E-Stops

E-Stop Reason

(Occurrence)

Maximum

Backups

Backup

5 m

Backup 

5 & 10 m

BIP

Replan Outcome Observations

11 Engine stopped; pause due to 

pendant being jostled.

3

Engine off (1); 

XUV heading 

for obstacles (2) 1 0 0 1

XUV became stuck in culde-sac, operator initiated 

replan, and XUV followed 

new route out of finger 

and on to goal —

12 ACC malfunction. Cost 

normalizations were manually 

varied by engineer during run.

2

XUV headings 

for guide wires 

attached to 

obstacles (2) 0 0 0 NA

FCI planned through 

obstacles, perceptive 

planning detected 

obstacles and would not 

proceed

Scaling between 

and normalization 

of local costs 

(within sensor 

range) and global 

costs (outside of 

sensor range) 

needs work

18 Error “Goto planner died”.

1

XUV headed for 

water hazard 0 0 0 0

Declared a fault because 

perceptive planner crashed —

18a FCI giving good Goto points 

on either side of red (blocked) 

points.

0 NA 0 1 0 0

End of mission declared 

because engineers 

suspected problem with 

FCI —

21 Map smearing.

1

XUV backing 

into log 2 0 1 1

Given room to maneuver, 

XUV performed figure 

eight patterns in front of 

obstacles searching for a 

path through; upon replan 

the new path went out of 

and around cul-de-sac.

Map smearing 

prevented XUV 

from executing 

new path

22

— 3

Admin (2); 

XUV stuck in a

rut 3 0 1 1 Same as run 21 —

23

— 1

XUV was 

heading for a 

rough area 1 0 0 NA

XUV continually turning 

circles in front of obstacles 

trying to find a path 

through —

24

— 2

XUV sliding 

down slope 

towards large 

puddle (1); XUV 

ridge in to rough 

area 0 0 0 NA

Rain mixed with snow on 

ground made maneuver 

difficult in this terrain —

Note: ACC = autonomous command and control, BIP = best information planning, FCI = field cost interface, NA = not applicable, and XUV = experimental unmanned vehicle.
69

Table B-4. Summary data for area C4 runs.

Run Technicalities E-Stops

E-Stop Reason

(Occurrence)

Maximum

Backups

Backup

5 m

Backup 

5 & 10 m

BIP

Replan Outcome Observations

1 Pause due to pendant being 

jostled.

4

Unknown (1); 

Admin (2); 

XUV backing 

into trees (1) 4 0 0 3

XUV unable to extricate itself 

from a natural cul-de-sac

Entrance to cul-desac was long and 

narrow such that 

two consecutive 

15-m backups 

insufficient to give 

room for XUV to 

turn around

3 Pause due to pendant being 

jostled.

4

XUV headed for 

obstacles (2); 

unknown (1); 

XUV did not 

backup when 

commanded (1) 0 0 0 0

Planned route contained density 

of stumps that were likely to 

damage XUV; end of mission 

declared and new route sought —

3a Pause due to pendant being 

jostled.

1 Unknown 1 0 0 1

After operator initiated a 

second 15-m backup, XUV 

successfully executed new plan —

4

— 2

XUV headed for 

rocks and logs 

(2) 0 0 0 NA

End of mission declared due to 

potential of rocks and logs to 

damage XUV

Pile of debris does 

not exceed 

minimum obstacle 

height setting, 

therefore not 

registered in 

perceptive layer

5

— 2

Unknown (1); 

XUV headed for 

debris pile 0 0 0 0

End of mission declared due to 

XUV heading for same debris —

6 Time-out mode.

3 Unknown (3) 3 0 0 NA

Operator intervention required 

to extricate XUV from natural 

cul-de-sac; end of mission 

declared when operator chose 

to teleop XUV into rough area 

wherein XUV could not 

proceed —
70

Table B-4. Summary data for area C4 runs (continued).

Run Technicalities E-Stops

E-Stop Reason

(Occurrence)

Maximum

Backups

Backup

5 m

Backup 

5 & 10 m

BIP

Replan Outcome Observations

7

— 2

Conservative 

safety call (1); 

XUV headed for 

trees (1) 0 0 1 NA

XUV headed towards trees and 

end of mission declared for Estop —

9

— 1

XUV headed for 

concrete slab 0 0 0

NA Height of concrete slab less 

than min. obstacle height; end 

of mission declared for E-stop —

11

— 1

XUV headed for 

concrete slab 0 0 0

NA

Same as run 9 —

12 Min. obstacle height adjusted 

from 1.5 m to 1 m; bad speed 

control loop; SMI hangup 

(can’t save screenshot). 0 NA 2 1 0

NA Operator teleoperated vehicle 

past obstacles on two 

occasions; planner crashed —

14 Communications between 

ACC and XUV dropping out 

(subsequently found due to 

downed comms antenna on 

truck). 1

XUV headed for 

tree branches 2 0 0

2

Replans generated route around 

cul-de-sac; XUV could not 

maneuver in terrain of new 

route —

15

— 1

XUV headed for 

concrete slab 0 0 0 0 Same as run 9 —

16

— 1

XUV headed for 

concrete slab 0 0 0 0 Same as run 9 —

Note: ACC = automomous command and control, BIP = best information planning, NA = not applicable, SMI = Soldier machine interface, and XUV = experimental unmanned vehicle.
NO. OF 

COPIES ORGANIZATION 

71

 1 DEFENSE TECHNICAL 

 (PDF INFORMATION CTR 

 only) DTIC OCA 

 8725 JOHN J KINGMAN RD 

 STE 0944 

 FORT BELVOIR VA 22060-6218 

 1 DIRECTOR 

 US ARMY RESEARCH LAB 

 IMNE ALC HR 

 2800 POWDER MILL RD 

 ADELPHI MD 20783-1197 

 1 DIRECTOR 

 US ARMY RESEARCH LAB 

 AMSRD ARL CI OK TL 

 2800 POWDER MILL RD 

 ADELPHI MD 20783-1197 

 1 DIRECTOR 

 US ARMY RESEARCH LAB 

 AMSRD ARL CI OK PE 

 2800 POWDER MILL RD 

 ADELPHI MD 20783-1197 

ABERDEEN PROVING GROUND

 1 DIR USARL 

 AMSRD ARL CI OK TP (BLDG 4600) 
NO. OF NO. OF

COPIES ORGANIZATION COPIES ORGANIZATION

72

1 DIRECTOR

US ARMY RESEARCH LAB

AMSRD ARL CI IA

S YOUNG

2800 POWDER MILL RD

ADELPHI MD 20783-1197

1 DIRECTOR

US ARMY RESEARCH LAB

AMSRD ARL SE EE

B STANN

2800 POWDER MILL RD

ADELPHI MD 20783-1197

1 TDCD US ARMY ARMOR CTR

W MEINSHAUSEN

BRANDENBURG STN RD BLDG 2197

FORT KNOX KY 40121-5000

1 CDR ARMY RSCH OFC

4300 S MIAMI BLVD

RESEARCH TRIANGLE PARK

NC 27709

1 CDR HQ TRADOC

SCIENCE & TECHLGY DIV

ATFC DS

LTC FOSTER

FT MONROE VA 23651-5850

1 CDR US ARMY TRADOC

ANALYSIS CTR

ATRC WBA

J GALLOWAY

WSMR NM 88002

1 US ARMY RDECOM-TARDEC

AMSRD TAR R/MS 264

J JACZKOWSKI

WARREN MI 48397-5000

1 USASOC HQ AOFD CDT

S FORMAN

2929 DESERT STORM DR

FORT BRAGG NC 28310

1 AVIATION APPLIED TECH DIR

AMSRD AMR AA I

K ARTHUR

BLDG 401 LEE BLVD

FORT EUSTIS VA 23604-5577

1 J S ALBUS

100 BUREAU DR

MS 8230

BLDG 220 RM 123

GAITHERSBURG MD 20899

1 CARNEGIE MELLON UNIV

ROBOTICS INST

A STENTZ

5000 FORBES AVE

PITTSBURGH PA 15213

6 GENERAL DYNAMICS ROBOTICS SYS

K BONNER

W BORGIA

D RODGERS

W DODSON

L SUTTON

R DEAN

1234 TECH CT

WESTMINSTER MD 21157

1 DIRECTOR

US ARMY RESEARCH LAB

AMSRD ARL VT LD

M NIXON

6 E TAYLOR ST

BLDG 1244C RM 250A

HAMPTON VA 23681-2199

1 DIRECTOR

US ARMY RESEARCH LAB

NASA GLENN RSRCH CTR

AMSRD ARL VT ET

M VALCO

21000 BROOKPARK RD MS 501-2

CLEVELAND OH 44135-3127

APG MD 21005

ABERDEEN PROVING GROUND

2 COMMANDER

US ARMY DEVELOPMENTAL

TEST CMD

TEDT TMA

C TURNER

TEDT TMA

B GERMAN

RYAN BLDG
NO. OF

COPIES ORGANIZATION

73

18 DIR USARL

AMSRD ARL CI IC

B BODT

AMSRD ARL HR SC

K COSENZO

S HILL

AMSRD ARL HR SE

T KELLEY

AMSRD ARL CI HM

J NEALON

AMSRD ARL VT UV

H EDGE

M FIELDS

G HAAS

J PUSEY

S WILKERSON

AMSRD ARL VT RP

M CHILDERS (8 CPS)
74

INTENTIONALLY LEFT BLANK.